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 creates bindings. The algorithm, employed by the binding mechanism, may contain elements specific for the kind of IP-CAN.
The binding mechanism includes three steps:
PCC rule authorization and QoS rule generation, if applicable.
Session binding is the association of the AF session information to one and only one IP-CAN session.
The PCRF shall perform the session binding, which shall take the following IP-CAN parameters into account:
The UE IPv4 address and/or IPv6 network prefix;
The UE identity (of the same kind), if present.
The information about the packet data network (PDN) the user is accessing, if present.
For an IP-CAN session to the dedicated APN for UE-to-Network Relay connectivity (as defined in TS 23.303) and using IPv6 prefix delegation (i.e. the assigned IPv6 network prefix is shorter than 64) the PCRF shall perform session binding based on the IPv6 network prefix only. A successful session binding occurs whenever a longer prefix received from an AF matches the prefix value of the IP-CAN session. PCRF shall not use the UE identity for session binding for this IP-CAN session.
The PCRF shall identify the PCC rules affected by the AF session information, including new rules to be installed and existing rules to be modified or removed.
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 22.214.171.124, 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 NW mode.
In UE/NW bearer establishment mode, for PCC rules that 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 Annex.
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 existing PCC. 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.
For an IP-CAN, where the PCRF gains no information about the uplink IP flows (i.e. the UE provided traffic mapping information contains no information about the uplink IP flows), the binding mechanism shall assume that, for bi-directional service data flows, both downlink and uplink packets travel on the same IP-CAN bearer.
Whenever the service data flow template or the UE provided traffic mapping information change, the existing authorizations shall be re-evaluated, i.e. the authorization procedure specified in this clause, is performed. The re-evaluation may, for a service data flow, require a new authorization for a different UE provided mapping information.
Based on PCRF configuration or AF instructions (as described in clause 6.1.5) dynamic PCC rules may have to be first authorized for the default QCI/default bearer (i.e. bearer without UE provided traffic mapping information) until a corresponding UE resource request occurs.
A PCC rule for a service data flow that is a candidate for vSRVCC according to TS 23.216 shall have the PS to CS session continuity indicator set.
For the authorization of a PCC rule the PCRF shall take into account the IP-CAN specific restrictions and other information available to the PCRF. Each PCC rule receives a set of QoS parameters that can be supported by the IP-CAN. The authorization of a PCC rule associated with an emergency service and Restricted Local Operator Services shall be supported without subscription information (e.g. information stored in the SPR). The PCRF shall apply policies configured for the emergency service and Restricted Local Operator Services.
When both a Gx and associated Gxx interface(s) exist for an IP-CAN session, the PCRF shall generate QoS rules for all the authorized PCC rules in this step. The PCRF shall ensure consistency between the QoS rules and PCC rules authorized for the same service data flow when QoS rules are derived from corresponding PCC rules.
When flow mobility applies for the IP-CAN Session, one IP-CAN session may be associated to multiple Gateway Control Sessions with separate BBRFs. In this case, the PCRF shall provision QoS rules only to the appropriate BBERF based on IP flow mobility routing rules received from the PCEF.
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 (see clause 5.1). 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.
The Bearer Binding Function may also be located in the PCRF as specified in Annex A and Annex D (e.g. for GPRS running UE only IP-CAN bearer establishment mode).
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 set of QoS parameters assigned in step 2, as described in clause 126.96.36.199, to the service data flow is the main input for bearer binding. The BBF should not use the same bearer for rules with different settings for the PS to CS session continuity indicator.
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.
Requirements, specific for each type of IP-CAN, are defined in the IP-CAN specific Annex.
Whenever the QoS authorization of a PCC/QoS rule 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. The BBF should, if the PCRF requests the same change to the ARP/QCI value for all PCC/QoS Rules with the bearer binding to the same bearer, modify the bearer ARP/QCI value as requested.
Reporting refers to the differentiated IP-CAN resource usage information (measured at the PCEF/TDF) being reported to the online or offline charging functions.
The PCEF/TDF shall report usage information for online and offline charging.
The PCEF/TDF shall report usage information for each charging key value.
For service data flow charging, for the case of sponsored data connectivity, the reports for offline charging shall report usage for each charging key, Sponsor Identity and Application Service Provider Identity combination if Sponsor Identity and Application Service Provider Identifier have been provided in the PCC rules.
The PCEF shall report usage information for each charging key/service identifier combination if service identifier level reporting is requested in the PCC/ADC rule.
The TDF shall report usage information for each charging key/service identifier combination if service identifier level reporting is requested in the ADC rule.
For the case where the BBF locates in the PCEF, charging information shall be reported based on the result from the service data flow detection and measurement on a per IP-CAN bearer basis.
For the case where the BBF is not located in the PCEF, charging information shall be reported based on the result from the service data flow detection and measurement, separately per QCI and ARP combination (used by any of the active PCC rules). In case 2a defined in clause 7.1, charging ID is provided to the BBERF via the PCRF if charging correlation is needed.
A report may contain multiple containers, each container associated with a charging key, charging key and Sponsor Identity (in case of sponsored connectivity) or charging key/service identifier.
The credit management applies for online charging only and shall operate on a per charging key basis. The PCEF should initiate one credit management session with the OCS for each IP-CAN Session subject to online charging, unless specified otherwise in an IP-CAN specific annex. Alternatively, the PCEF may initiate one credit management session for each IP-CAN bearer as defined in the applicable annex. The TDF should initiate one credit management session with the OCS for each TDF Session subject to online charging.
The PCEF/TDF shall request a credit for each charging key occurring in a PCC/ADC rule. It shall be up to operator configuration whether the PCEF/TDF shall request credit in conjunction with the PCC/ADC rule being activated or when the first packet corresponding to the service/the application is detected. The OCS may either grant or deny the request for credit. The OCS shall strictly control the rating decisions.
During IP-CAN session establishment and modification, the PCEF shall request credit using the information after applying policy enforcement action (e.g. upgraded or downgraded QoS information), if applicable, even though the PCEF has not signalled it yet in the IP-CAN.
It shall be possible for the OCS to form a credit pool for multiple (one or more) charging keys, applied at the PCEF/TDF, e.g. with the objective of avoiding credit fragmentation. Multiple pools of credit shall be allowed per IP-CAN bearer/TDF session. The OCS shall control the credit pooling decisions. The OCS shall, when credit authorization is sought, either grant a new pool of credit, together with a new credit limit, or give a reference to a pool of credit that is already granted for that IP-CAN bearer/TDF session. The grouping of charging keys into pools shall not restrict the ability of the OCS to do credit authorisation and provide termination action individually for each charging key of the pool. It shall be possible for the OCS to group service data flows/applications charged at different rates or in different units (e.g. time/volume/event) into the same pool.
For each charging key, the PCEF/TDF may receive credit re-authorisation trigger information from the OCS, which shall cause the PCEF/TDF to perform a credit re-authorisation when the event occurs. If there are events which can not be monitored in the PCEF/TDF, the PCEF/TDF shall provide the information about the required event triggers to the PCRF. If information about required event triggers is provided to the PCRF, it is an implementation option whether a successful confirmation is required from the PCRF in order for the PCEF/TDF to consider the credit (re-)authorization procedure to be successful. The credit re-authorisation trigger detection shall cause the PCEF/TDF to request re-authorisation of the credit in the OCS. It shall be possible for the OCS to instruct the PCEF/TDF to seek re-authorisation of credit in case of the events listed in Table 6.1.
The OCS has limited the validity of the credit to expire at a certain time.
The service data flow identified by a PCC Rules or the application identified by an ADC Rule has been empty for a certain time.
The UE has moved to another operators' domain.
The QoS of the IP-CAN bearer has changed.
Change in type of IP-CAN
The type of the IP-CAN has changed.
Location change (serving cell)
The serving cell of the UE has changed.
Location change (serving area) (see note 2)
The serving area of the UE has changed.
Location change (serving CN node) (see note 3)
The serving core network node of the UE has changed.
Change of UE presence in Presence Reporting Area (see note 4)
The UE has entered or left a Presence Reporting Area
This list is not exhaustive. Events specific for each IP-CAN are specified in Annex A, and the protocol description may support additional events.
A change in the serving area may also result in a change in the serving cell, and possibly a change in the serving CN node.
A change in the serving CN node may also result in a change in the serving cell, and possibly a change in the serving area.
The Presence Reporting Area(s) is provided by the OCS to the PCEF/TDF. The maximum number of PRA(s) per UE per PDN connection is configured in the OCS. The OCS may have independent configuration of the maximum number for Core Network pre-configured PRAs and UE-dedicated PRAs. The exact number(s) should be determined by operator in deployment.
If the Location change trigger is armed, the PCEF shall activate the relevant IP-CAN specific procedure which reports any changes in location to the level indicated by the trigger. If credit-authorization triggers and event triggers require different levels of reporting of location change for a single UE, the location to be reported should be changed to the highest level of detail required. However, there should be no request being triggered for credit re-authorization to the OCS if the report received is more detailed than requested by the OCS.
The OCS determines at credit management session establishment/modification, based on local configuration, if the UE is located in an access type that supports reporting changes of UE presence in Presence Reporting Area. If the access type supports it, the OCS may subscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the credit management session.
When activating reporting for change of UE presence in Presence Reporting Area, the OCS provides all of the PRA Identifier(s) to be activated for Core Network pre-configured Presence Reporting Area(s) and additionally all of PRA Identifier(s) and the list(s) of its elements for UE- dedicated Presence Reporting Area(s). (See Table 6.4 in clause 6.4 for details of the PRA Identifier(s) and the list(s) of elements comprising each Presence Reporting Area). If OCS is configured with a PRA identifier referring to the list of PRA Identifier(s) within a Set of Core Network predefined Presence Reporting Areas as defined in TS 23.401, it activates the reporting of UE entering/leaving the individual PRA in the Set of Core Network predefined Presence Reporting Areas without providing the complete set of individual PRAs.
The OCS may change (activate/modify/remove) the Presence Reporting Area(s) to be reported by providing the updated PRA Identifier(s) to PCEF. For UE dedicated PRAs, the OCS may also change the list(s) of Presence Reporting Area elements related to the PRA Identifier(s).
The OCS may unsubscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the credit management session.
The OCS may be notified during the life time of a credit management session that the UE is located in an access type where local OCS configuration indicates that reporting changes of UE presence in Presence Reporting Area is not supported. If so, the OCS unsubscribes to Change of UE presence in Presence Reporting Area, if previously activated.
Some of the re-authorization triggers are related to IP-CAN bearer modifications. IP-CAN bearer modifications, which do not match any credit re-authorization trigger (received from the OCS for the bearer) shall not cause any credit re-authorization interaction with the OCS.
If the PCRF set the Out of credit event trigger (see clause 6.1.4), the PCEF/TDF shall inform the PCRF about the PCC/ADC rules for which credit is no longer available together with the applied termination action.