5 Binding Mechanism

29.2133GPPPolicy and charging control signalling flows and Quality of Service (QoS) parameter mappingRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Overview

The binding mechanism associates the session information with the IP-CAN bearer that is intended to carry the service data flow.

For PCC rules with application identifier, and for certain IP-CAN types, up-link traffic can be received on other/additional IP-CAN bearers than the one determined by the binding mechanism (further details provided in clause 6.2.2.2 and the IP-CAN specific annexes of 3GPP TS 23.203 [2]).

The binding mechanism includes three steps as defined in 3GPP TS 23.203 [2]:

1. Session binding.

2. PCC Rule authorization and QoS Rule generation.

3. Bearer binding.

The Session Binding function receives the Session Information and determines the relevant IP-CAN session. With this information the PCC Rule Authorization and QoS Rule generation function runs the policy rules and constructs the PCC rule(s) and if applicable, the QoS rule(s) if the authorization is granted. Finally the Bearer Binding function selects the IP-CAN bearer where the PCC rule(s) or QoS rule(s) should be installed within the IP-CAN session already known.

PCC Rule Authorization and QoS Rule generation function and Bearer Binding function can take place without Session Binding at certain IP-CAN Session events (e.g. IP-CAN Session Establishment).

5.2 Session Binding

Session binding is the association of the AF session information to an IP-CAN session.

When the PCRF accepts an AA-Request from the AF over the Rx interface with service information, the PCRF shall perform session binding and associate the described service IP flows within the AF session information (and therefore the applicable PCC rules) to one and only one existing IP-CAN session. When the PCRF receives an AA-Request from the P-CSCF acting as an AF over the Rx interface for P-CSCF Restoration, the PCRF shall perform session binding and associate the request to the existing IMS PDN connection and perform P-CSCF Restoration for that impacted IMS PDN connection. This association is done comparing the user IP address received via the Rx interface in either the Frame-IP-Address AVP or the Framed-Ipv6-Prefix AVP with the Ipv4 address or Ipv6 prefix received via the Gx interface. The UE Identity if present in the Subscription-Id AVP and the PDN information if available in the Called-Station-Id AVP may also assist on this association. The Domain identity if available in the IP-Domain-Id AVP may also assist on this association, e.g. if other user identity information than the UE IP address is unavailable and the UE IP addresses is not unique for a certain APN.

NOTE 1: The UE IP address is unique per Domain identity.

NOTE 2: The IP-Domain-Id AVP is helpful in the following scenario: Within a PLMN, there are several separate IP address domains, with PCEF(s) that allocate Ipv4 IP addresses out of the same private address range to Ues. The same IP address can thus be allocated to Ues served by PCEFs in different address domains. If one PCRF controls several PCEFs in different IP address domains, the UE IP address is thus not sufficient for the session binding. An AF can serve Ues in different IP address domains, either by having direct IP interfaces to those domains, or by having interconnections via NATs in the user plane between PCEFs and the AF. If a NAT is used, the AF obtains the IP address allocated to the UE via application level signalling and supplies it for the session binding as Framed-IP-Address to the PCRF. The AF supplies an IP-Domain-Id value denoting the IP address domain behind the NAT in addition. The AF can derive the appropriate value from the source address (allocated by the NAT) of incoming user plane packets.

NOTE 3：When the scenario described in NOTE 2 applies and the AF is a P-CSCF it is assumed that the P-CSCF has direct IP interfaces to the different IP address domains and that no NAT is located between P-GW and P-CSCF. How a non-IMS AF obtains the UE private IP address to be provided to the PCRF is out of scope of the present release; it is unspecified how to support applications that use a protocol that does not retain the original UE’s private IP address.

If the Domain identity is not used to assist association, the PCRF will determine that the UE has an IP-CAN session if the IP address (Ipv4 or Ipv6) received over the Rx interface matches the Ipv4 address or Ipv6 prefix received via one or more of the following interfaces: Gx interface and S9 interface, and if the UE identity is used to assist the association, the UE identity received over the Rx interface matches the UE identity received via one or more of the following interfaces: Gx interface and S9 interface.

If the Domain identity is used to assist association, the PCRF will determine that the UE has an IP-CAN session if the Domain identity received over the Rx interface matches the PCEF Identity received via the Gx interface, and the IP address (Ipv4) received over the Rx interface matches the Ipv4 address received via the Gx interface.

For the roaming scenario, the Domain identity may be used for session binding when the AF and PCEF are located in same PLMN, i.e. for the home routed case, the Domain identity may be used by the (H-)PCRF for session binding, and for the visited case, Domain identity could be used by the V-PCRF for session binding.

For an IP-CAN session associated to a dedicated APN for the purpose of offering services to remote UEs via a ProSe UE-to-network relay UE, the PCRF shall use the UE IPv6 prefix alone in the session binding.

NOTE 4: In case the UE identity in the IP-CAN and the application level identity for the user are of different kinds, the PCRF needs to maintain, or have access to, the mapping between the identities. Such mapping is not subject to specification within this TS.

NOTE 5: An Ipv6 address provided over Rx matches an Ipv6 prefix provided over Gx or S9 if the Ipv6 address belongs to the Ipv6 (sub-)network prefix.

NOTE 6: The PCRF derives the PCEF identity from the Origin-Host AVP of the CCR command received from the PCEF. In order to correlate the PCEF Identity and the domain identity received over the Rx interface, the PCRF uses configured mapping between those identities. The Domain Identity is useful for assistance in session binding if the Origin-Host of the Gx CCR command is not modified by intermediate Diameter proxies deployed between the PCEF and the PCRF.

NOTE 7: The PCEF identity is not transported over S9 reference point in the present release. So for the visited access with AF located in HPLMN case, session binding assisted with Domain identity is not supported in the present release. Session binding is still possible based on other available information in addition to the IP address when provided by the AF, according to the current procedures.

If the PCRF uses the Called-Station-Id AVP to assist the association, the PCRF shall apply the procedures in Annex I to match APN information.

As a result from the session binding function, the PCRF identifies what IP-CAN session the current AF session is related with. If the PCRF is not capable of executing the Session Binding, the PCRF shall issue an AA-Answer command to the AF with a negative response.

5.3 PCC Rule Authorization and QoS Rule Generation

The PCRF shall perform the PCC rule authorization and QoS rule generation when the PCRF receives session information from an AF over Rx interface, when the PCRF receives notification of IP-CAN session events (e.g. establishment, modification) from the PCEF over Gx or S9 interface, when the PCRF receives IP-CAN events from the BBERF over Gxa/Gxc interface, or the PCRF receives a notification from the SPR that calls for a policy decision. The PCRF shall also perform PCC Rule Authorization and QoS Rule generation for dynamic PCC Rules already provisioned to the PCEF and dynamic QoS rules already provisioned to the BBERF due to internal PCRF triggers (e.g. policies are included or modified within PCRF).

If the PCRF receives any traffic mapping information from the BBF that does not match any service data flow filter, the PCRF shall also perform PCC and/or QoS rule authorization when the UE’s subscriber profile allows subscription based authorization. In this case, the PCRF shall treat the received traffic mapping information as if it is service data flow filter information.

If the PCRF receives from the AF a reference ID together with the AF session information, the PCRF may provide it to the SPR in order to retrieve the corresponding transfer policy. The PCRF shall derive the PCC rules for the background data transfer according to the retrieved transfer policy.

NOTE 1: A transfer policy is only valid within its time window. The removal of outdated transfer policies from the SPR is up to implementation.

If the PCRF receives information from the SPR for the invocation/revocation of a Priority EPS Bearer service (i.e. the MPS EPS Priority is set/removed or the MPS Priority Level changes while the MPS EPS Priority is set) , then the PCRF should change the QCI/ARP of the dynamic PCC/QoS rules that have the same QCI/ARP as for the present default EPS bearer with the new QCI/ARP assigned to the default EPS bearer unless those PCC rules contain an indication that they have to be bound to the default EPS bearer. If there are active non-MPS services, the QCI/ARP of the PCC/QoS rules related to the non-MPS services shall also be changed.

If the PCRF receives a request from the AF for the invocation/revocation of MPS for DTS (i.e., the MPS-Action AVP is set to enabled or to disabled, see 3GPP TS 29.214 [10]), then the PCRF shall behave according to clause 4.5.19.1 of 3GPP TS 29.212 [9].

If the PCRF receives information from the SPR that invokes/revokes the IMS Signalling Priority or changes the MPS Priority Level while IMS Signaling Priority is enabled, then the PCRF should

– change the ARP of the dynamic PCC/QoS rules applicable to the IM CN signalling

– replace the predefined PCC rules applicable to the IM CN signalling by predefined rules that apply when the IMS Signalling Priority is set according to operator policies

When IMS Signalling Priority is set, the PCRF should keep the ARP assigned to the default EPS bearer higher than the ARP related to the IM CN signalling bearer.

NOTE 2. IMS Signalling Priority only applies to an APN enabled for IMS.

The PCRF assigns appropriate QoS parameters (QCI, ARP, GBR, MBR, etc.) to each PCC or QoS rule. The PCRF takes the information received over Rx into account for determining the appropriate QCI/ARP. If the Rx authorization indicates IMS Multimedia Priority Service, then the PCRF shall allow the prioritization of the MPS session according to clauses 4.5.19.1.3 and 4a.5.14.1.3 in 3GPP TS 29.212 [9] for Gx/Gxx respectively. If the Rx authorization indicates Group Communication Service prioritization as described in 3GPP TS 23.468 [34], then the PCRF shall allow the prioritization of the Group Communication session according to clause 4.5.19 in 3GPP TS 29.212 [9].

The PCRF authorizes the affected PCC rules and /or QoS rules after successful Session Binding. By the authorization process the PCRF will determine whether the user can have access to the requested services and under what constraints. If so, the PCC rules and QoS rules are created or modified. If the Session Information is not authorized, a negative answer shall be issued to the AF by sending an AA-Answer command.

The PCRF assigns an appropriate QCI to each PCC or QoS rule. IP-CAN specific restrictions and other information available to the PCRF (e.g. users subscription information, operator policies) shall be taken into account. Each PCC or QoS rule shall receive a QCI that can be supported by the IP-CAN. 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.

If PrioritySharing feature is supported over Rx reference point as described in 3GPP TS 29.214 [10], the PCRF shall apply the priority sharing procedures as described in 3GPP TS 29.212 [9], subclauses 4.5.27 and 4a.5.17, if applicable.

In roaming scenarios, the V-PCRF may further authorize the rules received from the H-PCRF based on local operator policy. Depending on the local policy, the V-PCRF may change the authorized QoS for the affected rules. If local authorization of the rules fails, the V-PCRF shall issue a negative answer to the H-PCRF.

5.4 Bearer Binding

The Bearer Binding function is responsible for associating a PCC rule and QoS rule (if applicable) to an IP-CAN bearer within the IP-CAN session. The QoS demand in the rule, as well as the service data flow template, is input to the bearer binding. The selected bearer shall have the same QCI and ARP as the one indicated by the PCC or QoS rule.

When Rule-Bound-to-Default-Bearer feature is supported as described in 3GPP TS 29.212 [9], the value included within the Default-Bearer-Indication AVP shall be used as input for the bearer binding instead of the QoS demand in the rule.

NOTE 1: The PCRF provides the appropriate ARP/QCI for both PCC Rules and default bearer QoS so that the PCEF can perform a valid bearer binding. Alternatively, when Rule-Bound-to-Default-Bearer feature is supported, the PCRF can provide the Default-Bearer-Indication AVP within the PCC Rules to indicate that these PCC Rules have to be bound to the default bearer regardless of the provisioned ARP/QCI.

The Bearer Binding Function (BBF) is located either at the BBERF or at the PCEF.

The PCRF shall supply the PCC rules to be installed, modified or removed over Gx interface to PCEF. If there are gateway controls sessions associated with the Gx session, the PCRF shall also supply the QoS rules to be installed, modified, or removed over Gxa/Gxc interface to the BBERF.

When Rule-Bound-to-Default-Bearer feature is supported, the BBF located at the PCEF shall bind to the default bearer the PCC rules that have indicated so.

For the rules that do not contain an indication that they have to be bound to the default bearer, the BBF shall then check the QoS class identifier and ARP indicated by the rule and bind the rule with an IP-CAN bearer that has the same QoS class identifier and ARP. The BBF shall evaluate whether it is possible to use one of the existing IP-CAN bearers or not and, if applicable, whether to initiate IP-CAN bearer modification or not. If none of the existing bearers are possible to use, the BBF should initiate the establishment of a suitable IP-CAN bearer. The BBF should not bind rules with the PS to CS session continuity indicator to the same bearer as the rules without the PS to CS session continuity indicator.

NOTE 2: For an IP-CAN, limited to a single IP-CAN bearer per IP-CAN session, the bearer is implicit, so finding the IP-CAN session is sufficient for successful bearer binding.

NOTE 3: The handling of a rule with MBR>GBR is up to operator policy (e.g. an independent IP-CAN bearer may be maintained for that SDF to prevent unfairness between competing SDFs).

NOTE 4: The QCI and ARP (including the Priority-Level, Pre-emption-Capability and Pre-emption-Vulnerability) are used for the bearer binding. Depending on operator policy, only the QCI and ARP Priority-Level can be used for bearer binding. In such a case, it is left to operator policy to determine whether different PCC rules with the same QCI and ARP Priority-Level but different Pre-emption-Capability and Pre-emption-Vulnerability can be bound to the same bearer.

For an IP-CAN, where the BBF gains no information on what IP-CAN bearer the UE selects to send an uplink IP flow on, 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, the QoS authorization of a PCC/QoS rule or the negotiated traffic mapping information change, the existing bearer bindings shall be re-evaluated. 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 for all PCC/QoS Rules bound to the same bearer, modify the bearer ARP/QCI as requested.

NOTE 5: A QoS change of the default EPS bearer causes the bearer binding for PCC/QoS rules previously bound to the default EPS bearer to be re-evaluated.

During PCC/QoS rules enforcement, if packet filters are provided to the UE, the BBF shall provide packet filters with the same content as that in the SDF template filters received over the Gx/Gxx interface from the PCRF within the Flow-Description or the Flow-Information AVP. The representation/format of the packet filters provided by the network to the UE is access-system dependent and may vary between accesses and also may be different from that of the SDF template filter on the Gx/Gxx interface. The PCRF may control the provisioning of packet filters to the UE, i.e. which filters are required to be sent to the UE, as described in 3GPP TS 29.212 [9].

If PCC rule(s) with application identifier(s) are the only PCC rule(s) that are bound to a bearer which requires traffic mapping information, the PCEF shall derive traffic mapping information based on implementation specific logic (e.g. traffic mapping information that effectively disallows any useful packet flows in uplink direction as described in clause 15.3.3.4 of 3GPP TS 23.060 [3]) and provides it to the UE.

NOTE 6: For GPRS and EPS, the state of TFT packet filters, as defined in 3GPP TS 23.060 [3], for an IP-CAN session requires that there is at most one bearer with no TFT packet filter for the uplink direction.

Requirements specific for each type of IP-CAN are defined in the IP-CAN specific Annex. The Bearer Binding Function may also be located in the PCRF (e.g. as specified in Annex D for GPRS running UE only IP-CAN bearer establishment mode). Selection of the Bearer Binding location shall be based on the Bearer Control Mode selected by the PCRF.