Binding Mechanism:
The binding mechanism is the procedure that associates a service data flow (defined in a PCC and QoS rule, if applicable, by means of the SDF template), to the IP-CAN bearer deemed to transport the service data flow. For service data flows belonging to AF sessions, the binding mechanism shall also associate the AF session information with the IP-CAN bearer that is selected to carry the service data flow.
The binding mechanism includes three steps:
- Session binding
- PCC rule authorization and QoS rule generation, if applicable
- Bearer binding
1. Session Binding:
Session binding is the association of the AF session information to an IP-CAN session.
The PCRF shall perform the session binding, which shall take the following IP-CAN parameters into account:
- The UE IP address(es).
- The UE identity (of the same kind), if present.
- The information about the packet data network (PDN) the user is accessing, if present.
2. PCC rule authorization and QoS rule generation
PCC Rule authorization is the selection of the QoS parameters (QCI, ARP, GBR, MBR, etc.) for the PCC rules.
The PCRF shall perform the PCC rule authorization for complete dynamic PCC rules belonging to AF sessions that have been selected in step 1, as described in clause 6.1.1.2, as well as for PCC rules without corresponding AF sessions.
Based on AF instructions (as described in clause 6.1.5) dynamic PCC rules can be authorized even if they are not complete (e.g. due to missing service information regarding QoS or traffic filter parameters).
The PCC rule authorization depends on the IP-CAN bearer establishment mode of the IP-CAN session and the mode (UE or NW) of the PCC rule:
- In UE/NW bearer establishment mode, the PCRF shall perform the authorization for all PCC rules that are to be handled in NWmode.
- Otherwise, if PCC rules are to be handled in UE mode or when in UE-only bearer establishment mode, the PCRF shall first identify the PCC rules that correspond to a UE resource request and authorize only these.
The PCRF shall compare the traffic mapping information of the UE resource request with the service data flow filter information of the services that are allowed for the user. Each part of the traffic mapping information shall be evaluated separately in the order of their related precedence. Any matching service data flow filter leads to an authorization of the corresponding PCC rule for the UE resource request unless the PCC rule is already. Authorized for a more specific traffic mapping information or the PCC rule cannot be authorized for the QCI that is related to the UE resource request (the details are described in the next paragraph). Since a PCC rule can contain multiple service data flow filters it shall be ensured by the PCRF that a service data flow is only authorized for a single UE resource request.
The PCRF knows whether a PCC rule can be authorized for a single QCI only or a set of QCIs (based on SPR information or local configuration). If the processing of the traffic mapping information would lead to an authorization of a PCC rule, the PCRF shall also check whether the PCC rule can be authorized for the QCI that is related to the UE resource request containing the traffic mapping information. If the PCC rule cannot be authorized for this QCI, the PCRF shall reject the traffic mapping information unless otherwise stated in an access-specific.
If there is any traffic mapping information not matching to any service data flow filter known to the PCRF and the UE is allowed to request for enhanced QoS for traffic not belonging to operator-controlled services, the PCRF shall authorize this traffic mapping information by adding the respective service data flow filter to a new or an existing PCC rule. If the PCRF received an SDF filter identifier together with this traffic mapping
information, the PCRF shall modify the existing PCC rule if the PCC rule is authorized for a GBR QCI.
The PCC rule that needs to be modified can be identified by the service data flow filter the SDF filter identifier refers to. The requested QoS shall be checked against the subscription limitations for traffic not belonging to operator-controlled services.
If the PCRF needs to perform the authorization based on incomplete service information and thus cannot
associate a PCC rule with a single IP-CAN bearer, then the PCRF shall generate for the affected service data flow an individual PCC rule per IP-CAN bearer that could carry that service data flow. Once the PCRF receives the complete service information, the PCC rule on the IP-CAN bearer with the matching traffic mapping information shall be updated according to the service information. Any other PCC rule(s) previously generated for the same service data flow shall be removed by the PCRF.
3. Bearer Binding:
Bearer binding is the association of the PCC rule and the QoS rule (if applicable) to an IP-CAN bearer within that IP-CAN session. This function resides in the Bearer Binding Function (BBF). The Bearer Binding Function is located either at the BBERF or at the PCEF, depending on the architecture. The BBF is located at the PCEF if GTP is used as the mobility protocol towards the PCEF; otherwise, the BBF is located at the BBERF.
For an IP-CAN which allows for multiple IP-CAN bearers for each IP-CAN session, the binding mechanism shall use the QoS parameters of the existing IP-CAN bearers to create the bearer binding for a rule, in addition to the PCC rule and the QoS rule (if applicable) authorized in the previous step.
The BBF shall evaluate whether it is possible to use one of the existing IP-CAN bearers or not and whether initiate IP-CAN bearer modification if applicable. If none of the existing bearers are possible to use, the BBF should initiate the establishment of a suitable IP-CAN bearer. The binding is created between service data flow(s) and the IP-CAN bearer which have the same QoS class identifier and ARP.
Whenever the QoS authorization changes, the existing bindings shall be re-evaluated, i.e. the bearer binding procedures specified in this clause, is performed. The re-evaluation may, for a service data flow, require a new binding with another IP-CAN bearer.
