4 Rx reference point

29.2143GPPPolicy and charging control over Rx reference pointRelease 17TS

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

4.1 Overview

The Rx reference point is used to exchange application level session information:

– and the Application Function (AF); and

– in the 5GS, between the Policy Control Function (PCF) between

the Policy and Charging Rules Function (PCRF) and the Application Function (AF). As defined in the stage 2 specifications (3GPP TS 23.203 [2]), this information is part of the input used by the PCRF for the Policy and Charging Control (PCC) decisions. The PCRF exchanges the PCC rules with the Policy and Charging Enforcement Function (PCEF) and QoS rules with the Bearer Binding and Event Reporting Function (BBERF) as specified in 3GPP TS 29.212 [8].

Policy and Charging Control over Rx interface in the 5GS is specified in annex E.

Signalling flows related to the both Rx and Gx interfaces are specified in 3GPP TS 29.213 [9].

Refer to Annex G of 3GPP TS 29.213 [9] for Diameter overload control procedures over the Rx interface.

Refer to Annex J of 3GPP TS 29.213 [9] for Diameter message priority mechanism procedures over the Rx interface.

Refer to Annex K of 3GPP TS 29.213 [9] for Diameter load control procedures over the Rx interface.

4.2 Rx reference model

The Rx reference point is defined between the PCRF and the AF. The relationships between the different functional entities involved are depicted in figure 4.2.1. The overall PCC architecture is depicted in clause 3a of 3GPP TS 29.213 [9].

Figure 4.2.1: Rx reference model

Figure 4.2.2: Void

4.3 Functional elements

4.3.1 AF

The AF is an element offering applications that require the Policy and Charging Control of traffic plane resources (e.g. UMTS PS domain/GPRS domain resources). One example of an application function is the P-CSCF. The AF shall use the Rx reference point to provide session information to the PCRF.

NOTE: The AFs may be deployed by the same operator offering the IP-CAN or may be provided by external third party service provider.

4.3.2 PCRF

The PCRF (Policy Control and Charging Rules Function) is a functional element that encompasses policy control decision and flow based charging control functionalities. These 2 functionalities are the heritage of the release 6 logical entities PDF and CRF respectively. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The PCRF receives session and media related information from the AF and informs AF of traffic plane events.

The PCRF may check that the service information provided by the AF is consistent with the operator defined policy rules before storing the service information. The service information shall be used to derive the QoS for the service. The PCRF may reject the request received from the AF and as a result the PCRF shall indicate, in the response to the AF, the service information that can be accepted by the PCRF.

The PCRF may temporarily not be able to provide the service delivery that AF requested (e.g. due to RAN user plane congestion). In this case, the PCRF may send a re-try interval information to the AF. The re-try interval indicates when service delivery may be retried by the AF over Rx.

NOTE 1: Additionally, existing bandwidth limitation parameters (e.g. Max-Requested-Bandwidth-DL AVP, Max-Requested-Bandwidth-UL AVP within the Acceptable-Service-Info AVP) provided by the PCRF to the AF in AA-Answer command during the Rx session establishment are available in order to mitigate RAN user plane congestion.

The PCRF may use the subscription information as basis for the policy and charging control decisions. The subscription information may apply for both session based and non-session based services. The subscription specific information for each service may contain e.g. max QoS class and max bit rate.

If the AF requests it, the PCRF shall report IP-CAN session events (including bearer events and events on AF signalling transport) to the AF via the Rx reference point.

The PCRF PCC/QoS Rule decisions may be based on one or more of the following:

– the session and media related information obtained from the AF via the Rx reference point;

– the bearer and subscriber related information obtained from the PCEF over the Gx reference point;

– the bearer and subscriber related information obtained from the BBERF over the Gxx reference point;

– subscriber and service related data the PCRF may be aware of by configuration or through the Sp reference point;

– pre-configured information in the PCRF.

NOTE 2: The details associated with the Sp reference point are not specified in this Release. The SPR’s relation to existing subscriber databases is not specified in this Release.

The PCRF shall provision PCC/QoS Rules to the PCEF/BBERF via the Gx/Gxx reference point.

4.4 PCC procedures over Rx reference point

4.4.1 Initial Provisioning of Session Information

When a new AF session is being established and media information for this AF session is available at the AF and the related media require PCC supervision, the AF shall open an Rx Diameter session with the PCRF for the AF session using an AA-Request command, unless an Rx session has already been established for the AF session (e.g. as per clause 4.4.6.7). If an Rx Diameter session already exists for the AF session, the AF uses the existing Rx Diameter session. The AF shall provide the full IP address of the UE using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP, and the corresponding Service Information within Media-Component-Description AVP(s). The AF shall not include circuit-switched bearer related media in the service information sent to the PCRF. The AF shall indicate to the PCRF as part of the Media-Component-Description whether the media IP flow(s) should be enabled or disabled with the Flow-Status AVP.

NOTE 1: The AF does not need to open an Rx Diameter session with the PCRF, if the SDP payload is only proposing to use a circuit-switched bearer (i.e. "c=" line set to "PSTN" and an "m=" line set to "PSTN", refer to 3GPP TS 24.292 [26]).

NOTE 2: The Rx Diameter session used for an AF session is different from the Rx Diameter session possibly used for the notifications of the status of the AF signalling transmission path. A new Rx Diameter session is established for each new AF session.

The AF may include the AF-Application-Identifier AVP into the AA-Request in order to indicate the particular service that the AF session belongs to. This AVP can be provided at both AF session level, and Media-Component-Description level. When provided at both levels, the AF-Application Identifier provided within the Media-Component-Description AVP will have precedence. The AF may also include an AF application identifier within the AF-Application-Identifier AVP at the AF session level to trigger the PCRF to indicate to the PCEF/TDF to perform the application detection based on the operator’s policy as defined in 3GPP TS 29.212 [8].

The AF may include the AF-Charging-Identifier AVP into the AA-Request for charging correlation purposes. The AF may also include the Specific-Action AVP to request notification for certain user plane events, e.g. bearer termination.

The AF may include the Service-URN AVP in order to indicate that the new AF session relates to emergency or RLOS traffic and additionally it may include the AF-Requested-Data AVP to indicate the information required by the AF. If the PCRF receives the Service-URN AVP indicating an emergency session, the PCRF may apply special policies, for instance prioritising service flows relating to the new AF session or allowing these service flows free of charge. If the Service-URN AVP indicates that the new AF session relates to emergency traffic and the AF-Requested-Data AVP is received, the PCRF shall provide the requested available user information as part of the AA-Answer command.

The AF may include the MPS-Identifier AVP in order to indicate that the new AF session relates to an MPS session. If the PCRF receives the MPS-Identifier AVP indicating an MPS session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MPS session is prioritized as specified in 3GPP TS 29.212 [8]. For Multimedia Priority Service handling for IMS, see Annex A.9.

The AF may include the MCPTT-Identifier AVP in order to indicate that the new AF session relates to an MCPTT session with priority call. If the PCRF receives the MCPTT-Identifier AVP related to that MCPTT session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MCPTT session is prioritized. For the handling of MCPTT session with priority call, see Annex A.13.

The AF may include the MCVideo-Identifier AVP in order to indicate that the new AF session relates to an MCVideo session with priority call. If the PCRF receives the MCVideo-Identifier AVP related to that MCVideo session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MCVideo session is prioritized. For the handling of MCVideo session with priority call, see Annex A.15.

If the QoSHint feature is supported by the AF, the AF may include the Desired-Max-Latency AVP and/or Desired-Max-Loss AVP within the Media-Component-Description AVP to indicate to the PCRF that the related application media has specific latency and/or loss demands.

The AF may include the FLUS-Identifier AVP within the Media-Component-Description AVP in order to indicate to the PCRF that the media flow(s) correspond to a FLUS media stream. Additional QoS information for the treatment of FLUS media may be provided within Desired-Max-Latency AVP and/or Desired-Max-Loss AVP.

The AF may include the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED within the Media-Component-Description AVP in order to indicate to the PCRF that the related media flow is allowed to use the same Allocation and Retention Priority (ARP) as media flows belonging to other AF sessions as described in clause 4.4.8. In this case, if the MCPTT-Preemption is supported, the AF may also include the Pre-emption-Capability AVP containing the suggested pre-emption capability value and the Pre-emption-Vulnerability AVP containing the suggested pre-emption vulnerability value within the Media-Component-Description AVP for the PCRF to determine the ARP values. The AF may also include the Pre-emption-Control-Info AVP containing the pre-emption control information at the AAR command level for the PCRF to perform the pre-emption control as defined in clause 4.5.27 or 4a.5.17 of 3GPP TS 29.212 [8].

The AF may include the Sharing-Key-UL and/or Sharing-Key-DL AVP within the Media-Component-Description AVP in order to indicate that the related media of the new AF session may share resources with other media components in the related direction that include the same value for the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP.

When the AF is a GCS AS, it may include the GCS-Identifier AVP at command level and Reservation-Priority AVP at command level or media component level in order to indicate that the new AF session relates to a prioritized Group Communication session. Based on this information, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the Group Communication session is prioritized as specified in 3GPP TS 29.212 [8].

If the AF provides service information that has been fully negotiated (e.g. based on the SDP answer), the AF may include the Service-Info-Status AVP set to FINAL_SERVICE_INFORMATION. In this case the PCRF shall authorize the session and provision the corresponding PCC/QoS rules to the PCEF/BBERF.

The AF may additionally provide preliminary service information not fully negotiated yet (e.g. based on the SDP offer) at an earlier stage. To do so, the AF shall include the Service-Info-Status AVP with the value set to PRELIMINARY SERVICE INFORMATION. Upon receipt of such preliminary service information, the PCRF shall perform an early authorization check of the service information. For GPRS, the PCRF shall not provision PCC rules towards the PCEF unsolicitedly. However, the PCRF may authorize a PCC/QoS rule request received from the PCEF/BBERF as per 3GPP TS 29.212 [8]. Further, if the AF requests the PCRF to report the access network information together with preliminary service information, the PCRF shall immediately configure the PCEF (or BBERF) to provide the access network information.

For sponsored data connectivity and if SponsoredConnectivity is supported, the AF shall provide the application service provider identity and the sponsor identity to the PCRF by including the Application-Service-Provider-Identity AVP and the Sponsor-Identity AVP in the Sponsored-Connectivity-Data AVP in the AA-Request. Additionally if SponsorChange is supported the AF shall provide an indication whether to enable or not enable sponsored data connectivity to the PCRF by including the Sponsoring-Action AVP set to the applicable value.

NOTE 3: The relationship between the AF and Sponsor is out of scope of this specification. A single AF can serve multiple ASPs and multiple sponsors, An ASP can also be a sponsor.

To support the usage monitoring of sponsored data connectivity, the AF may also include the Granted-Service-Unit AVP in the Sponsored-Connectivity-Data AVP and the Specific-Action AVP set to the value USAGE_REPORT in the AA-Request to request notification when the usage threshold has been reached.

NOTE 4: If the AF is in the user plane, the AF can handle the usage monitoring and therefore it is not required to provide a usage threshold to the PCRF as part of the sponsored data connectivity information.

When SponsoredConnectivity is supported or when SponsorChange is supported and the AF indicated to enable sponsored data connectivity, the following procedures apply:

– If the UE is roaming with the visited access case and the AF is located in the HPLMN or roaming with the home routed case and operator policies do not allow accessing the sponsored data connectivity with this roaming case, the H-PCRF shall reject the service request indicating UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY to the AF.

– If the UE is roaming with the visited access case and the AF is located in the VPLMN, the V-PCRF shall reject the service request indicating UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY to the AF.

When SponsoredConnectivity is supported or when SponsorChange is supported and the AF indicated to enable sponsored data connectivity, if the UE is in the non-roaming case or roaming with the home routed case and the operator policies allow accessing the sponsored data connectivity with this roaming case, the following procedures apply:

– If the PCEF/TDF does not support sponsored connectivity and the required reporting level for that service indicates a sponsored connectivity level according to 3GPP TS 29.212 [8], then the PCRF shall reject the request indicating REQUESTED_SERVICE_NOT_AUTHORIZED.

– If the PCEF/TDF supports sponsored data connectivity feature or the required reporting level is different from sponsored connectivity level as described in 3GPP TS 29.212 [8], then the PCRF, based on operator policies, shall check whether it is required to validate the sponsored connectivity data. If it is required, it shall perform the authorizations based on sponsored data connectivity profiles. If the authorization fails, the PCRF responds to the AF with an AA-Answer including the Experimental-Result-Code AVP set to the value UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY. The profile may include a list of Application Service Providers and their applications per sponsor.

NOTE 5: If the AF is in the operator’s network and is based on the OSA/Parlay-X GW, the PCRF is not required to verify that a trust relationship exists between the operator and the sponsors.

When CHEM feature is supported, the AF includes the Max-PLR-DL AVP and/or Max-PLR-UL AVP within the Media-Component-Description AVP, to indicate the downlink maximum packet loss rate and/or uplink maximum packet loss rate for each payload type. For CHEM feature, see Annex A.18.

When the PCRF receives an initial AA-Request from the AF, the PCRF shall perform session binding as described in 3GPP TS 29.213 [9]. To allow the PCRF to identify the IP-CAN session for which this request applies, the AF shall provide either the Framed-IP-Address or the Framed-Ipv6-Prefix containing the full IP address applicable to an IP flow or IP flows towards the UE. In case of private IP address being used, the AF may provide PDN information if available in the Called-Station-Id AVP for session binding. The AF may provide the domain identity in the IP-Domain-Id AVP for session binding.

NOTE 6: 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. The value provided in the IP-Domain-Id AVP is operator configurable.

NOTE 7: When the scenario described in NOTE 6 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 PCRF fails in executing session binding, the PCRF responds to the AF with an AA-Answer including the Experimental-Result-Code AVP set to the value IP-CAN_SESSION_NOT_AVAILABLE. Further details on how the PCRF identifies suitable IP-CAN sessions can be found in the binding mechanism described in 3GPP TS 29.213 [9].

If the request contains Media-Component-Description Attribute-Value Pair(s) (AVP(s)) the PCRF shall store the received Service Information. The PCRF shall process the received Service Information according to the operator policy and may decide whether the request is accepted or not. The PCRF may take the priority information within the Reservation-Priority AVP into account when making this decision.

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, as defined in 3GPP TS 23.303 [46], the PCRF shall validate the service information based on the service/roaming agreement and the operator policies related to that PDN information.

NOTE 8: The PCRF is not required to be aware of the remote UE.

If the service information provided in the AA-Request command is rejected (e.g. the subscribed guaranteed bandwidth for a particular user is exceeded), the PCRF shall indicate in the AA-Answer command the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED. If the service information provided in the AA-Request command is rejected by the PCRF due to a temporary condition in the network (e.g. the user plane in the cell the user is located is congested), the PCRF may indicate in the AA-Answer the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_TEMPORARILY_NOT_AUTHORIZED (4261). The PCRF may also provide a retry-interval within the Retry-Interval AVP in the AA-Answer command to the AF. When the AF receives the re-try interval within the Retry-Interval AVP, the AF shall not send the same service information to the PCRF again (for the same IP-CAN session) until the re-try interval has elapsed. The PCRF may additionally provide the acceptable bandwidth within the Acceptable-Service-Info AVP in AA-Answer command.

NOTE 9: How the PCRF derives the re-try interval is up to implementation.

To allow the PCRF and PCEF to perform PCC rule authorization and bearer binding for the described service IP flows, the AF shall supply both source and destination IP addresses and port numbers within the Flow-Description AVP, if such information is available.

NOTE 10: In SDP source port information is usually not available.

The AF may specify the ToS‑Traffic‑Class AVP for the described service data flows together with the Flow‑Description AVP.

NOTE 11: The ToS-Traffic-Class AVP can be useful when another packet filter attribute is needed to differentiate between flows. For example, (when EPS bearers are used for group communication services) flows encapsulated and encrypted by a tunneling protocol and thus having their IP five-tuple attributes obscured can be differentiated by the Type of Service (or Traffic Class) value of the outer header.

NOTE 12: The use of ToS‑Traffic‑Class AVP by the AF assumes that no DSCP re-marking is applied from the application to the PGW.

The AF may specify the Reservation-Priority AVP at request level in the AA-Request in order to assign a priority to the AF Session as well as specify the Reservation-Priority AVP at the media-component-description AVP level to assign a priority to the IP flow. The presence of the Reservation-Priority in both levels does not constitute a conflict as they each represent different types of priority. Specifically the Reservation-Priority at the AA-Request level provides the relative priority for a session while the Reservation-Priority at the media-component-description level provides the relative priority for an IP flow within a session. If the Reservation-Priority AVP is not specified the requested priority is DEFAULT (0).

The AF may request notifications of specific IP-CAN session events through the usage of the Specific-Action AVP in the AA-Request command. The PCRF shall make sure to inform the AF of the requested notifications in the event that they take place.

The AF may include the Rx-Request-Type AVP set to INITIAL_REQUEST in the AAR.

The AF may include a Reference Id within the Reference-Id AVP related to a transfer policy negotiated for background data transfer via the Nt reference point as described in 3GPP TS 29.154 [47]. The PCRF shall retrieve the corresponding transfer policy from the SPR based on the Reference Id. If the PCRF can not retrieve the transfer policy, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 0 set to indicate that the transfer policy is unknown. If the time window of the received transfer policy has expired, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 1set to indicate that the transfer policy has expired. Otherwise, if the time window of the received transfer policy has not yet occurred, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 2 set to indicate that the time window of the transfer policy has not yet occurred.

NOTE 13: In the case that the PCRF can not retrieve the transfer policy or the transfer policy expired, the PCRF makes the decision without considering the transfer policy.

NOTE 14: When receiving the reference id from the 3rd party SCS/AS as described in 3GPP TS 23.682 [40], the SCEF (acting as an AF) can provide the reference id together with the sponsored data connectivity information if SponsorChange is supported as described in this clause.

The AF may include the IMS-Content-Type AVP into the AA-Request in order to indicate the type of IMS communication service (e.g. CAT service, 3PTY conference) the AF session refers to.

The AF may include the IMS-Content-Identifier AVP into the AA-Request in order to indicate the particular IMS communication service or communication dialogue that the AF session refers to.

The AF may include the Calling-Party-Address AVP and the Callee-Information AVP into the AA-Request in order to indicate the caller and the callee information that the AF session refers to.

The PCRF shall check whether the received Service Information requires PCC/QoS Rules to be created and provisioned and/or authorized QoS to be provisioned as specified in 3GPP TS 29.213 [9]. Provisioning of PCC/QoS Rules and Authorized QoS to the PCEF/BBERF shall be carried out as specified at 3GPP TS 29.212 [8].

If the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP are provided within the Media-Component-Description AVP, the PCRF may apply the mechanisms for resource sharing as specified at 3GPP TS 29.212 [8].

The PCRF shall reply with an AA-Answer to the AF. The acknowledgement towards the AF should take place before or in parallel with any required PCC Rule provisioning towards the PCEF and shall include the Access‑Network-Charging-Identifier(s) and may include the Access-Network-Charging-Address AVP, if they are available. The AA-Answer message shall also include the AN-GW-Address AVP, if the PCRF has previously requested to be updated with this information in the PCEF. The AA-Answer message shall also include the PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP if the PCRF has previously requested to be updated with this information in the PCEF/BBERF. The AA-Answer message shall also include the IP-CAN-Type AVP. if the PCRF has previously requested to be updated with this information in the PCEF/BBERF. In that case, the AA-Answer message shall also include the RAT type information within the RAT-Type AVP and AN-Trusted AVP when applicable for the specific IP-CAN Type. In addition, if IP flow mobility applies to service data flows as specified in 3GPP TS 29.212 [8], such that a subset of the flows within the AF session are affected, the PCRF shall also include IP-CAN-type and RAT type information (if applicable) to IP flow mobility related flows, if such information is available. The IP flow mobility affected service data flows are included within the Flows AVP at command level. If the PCRF needs to terminate the Rx session before it has sent the AA Answer, the PCRF shall send the AA Answer immediately and before the AS Request.

The behaviour when the AF does not receive the AA Answer, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of this specification and based on operator policy.

If the PCRF fails in installing PCC/QoS rules based on the provided service information due to resource allocation failure as specified in 3GPP TS 29.212 [8] and if requested by the AF, the PCRF shall send an RAR command to the AF with the Specific-Action AVP set to the value INDICATION_OF_FAILED_RESOURCES_ALLOCATION to report the resource allocation failure, the Flows AVP containing the service data flows corresponding to the resources that could not be allocated, and the content version within the Content-Version AVP if it was included when the corresponding media component was provisioned. The AF shall send an RAA command to acknowledge the RAR command.

4.4.2 Modification of Session Information

The AF may modify the session information at any time (e.g. due to an AF session modification or internal AF trigger) by sending an AA-Request command to the PCRF containing the Media-Component-Description AVP(s) with the updated Service Information. The AF shall send an AA-Request command to the PCRF, only after the previous AA-Request has been acknowledged.

The AF may include the Rx-Request-Type AVP set to UPDATE_REQUEST in the AAR.

The AF may include a Reference Id within the Reference-Id AVP related to a transfer policy negotiated for background data transfer via the Nt reference point as described in 3GPP TS 29.154 [47]. The AF shall retrieve the corresponding transfer policy from the SPR based on the Reference Id. If the PCRF can not retrieve the transfer policy, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 0 set to indicate that the transfer policy is unknown. If the time window of the received transfer policy has expired, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 1set to indicate that the transfer policy has expired. Otherwise, if the time window of the received transfer policy has not yet occurred, the PCRF shall include in the AA-Answer the Service-Authorization-Info AVP with the bit 2 set to indicate that the time window of the transfer policy has not yet occurred.

NOTE 1: In the case that the PCRF can not retrieve the transfer policy or the transfer policy expired, the PCRF makes the decision without considering the transfer policy.

NOTE 2: When receiving the reference id from the 3rd party SCS/AS as described in 3GPP TS 23.682 [40], the SCEF (acting as an AF) can provide the reference id together with the sponsored data connectivity information if SponsorChange is supported as described in this clause.

The AF may include the MPS-Identifier AVP in order to indicate that the modified AF session relates to an MPS session. If the PCRF receives the MPS-Identifier AVP, it may take specific actions on the corresponding IP-CAN to ensure that the MPS session is prioritized as defined in 3GPP TS 29.212 [8]. For Multimedia Priority Service handling for IMS, see Annex A.9.

The AF may include the MCPTT-Identifier AVP in order to indicate that the modified AF session relates to the priority adjustment of an MCPTT session. If the PCRF receives the MCPTT-Identifier AVP related to that MCPTT session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MCPTT session is prioritized. For the handling of MCPTT session with priority call, see Annex A.13.

The AF may include the MCVideo-Identifier AVP in order to indicate that the modified AF session relates to the priority adjustment of an MCVideo session. If the PCRF receives the MCVideo-Identifier AVP related to that MCVideo session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the MCVideo session is prioritized. For the handling of MCVideo session with priority call, see Annex A.15.

The AF may include the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP within the Media-Component-Description AVP in order to indicate that the related media of the modified AF session may share resources with other media components in the related direction that include the same Sharing-Key-UL and or Sharing-Key-DL AVP. The AF may modify the conditions for resource sharing by including a new value of the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP for that media component.

When the AF is a GCS AS, it may include the GCS-Identifier AVP at command level and Reservation-Priority AVP at command level or media component level in order to modify the priority of an AF session that relates to a prioritized Group Communication session. Based on this information, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the Group Communication session is prioritized as specified in 3GPP TS 29.212 [8].

If SponsorChange is supported and the AF requests to enable sponsored data connectivity the AF shall provide the application service provider identity, the sponsor identity and an indication to enable sponsored data connectivity to the PCRF by including Application-Service-Provider-Identity AVP, the Sponsor-Identity AVP and the Sponsoring-Action AVP set to the value ENABLE_SPONSORING (1) in the Sponsored-Connectivity-Data AVP in the AA-Request.

If the AF requests to disable sponsored data connectivity the AF shall provide an indication to disable sponsored data connectivity to the PCRF by including the Sponsoring-Action AVP set to the value DISABLE_SPONSORING (0) in the Sponsored-Connectivity-Data AVP in the AA-Request.

To support the usage monitoring of sponsored data connectivity, the AF may also include the Granted-Service-Unit AVP in the Sponsored-Connectivity-Data AVP in the AA-Request.

NOTE 3: If the AF is in the user plane, the AF can handle the usage monitoring and therefore it is not required to provide a usage threshold to the PCRF as part of the sponsored data connectivity information.

When sponsored data connectivity is requested to be enabled the following procedures apply:

– If the UE is roaming with the visited access case and the AF is located in the VPLMN, the V-PCRF shall reject the service request indicating UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY to the AF.

When sponsored data connectivity is requested to be enabled, if the UE is in the non-roaming case or roaming with the home routed case and the operator policies allow accessing the sponsored data connectivity with this roaming case, the following procedures apply:

NOTE 4: If the AF is in the operator’s network and is based on the OSA/Parlay-X GW, the PCRF is not required to verify that a trust relationship exists between the operator and the sponsors.

The AF may include an AF application identifier within the AF-Application-Identifier AVP at the session level to trigger the PCRF to indicate to the PCEF/TDF to perform the application detection based on the operator’s policy as defined in 3GPP TS 29.212 [8].

The AF may include the IMS-Content-Type AVP into the AA-Request in order to indicate the type of IMS communication service (e.g. CAT service, 3PTY conference) the AF session refers to.

The AF may include the IMS-Content-Identifier AVP into the AA-Request in order to indicate the particular IMS communication service or communication dialogue that the AF session refers to.

The AF may include the Callee-Information AVP into the AA-Request in order to indicate the callee information that the AF session refers to.

The PCRF shall process the received Service Information according the operator policy and may decide whether the request is accepted or not. If the updated Service Information is not acceptable (e.g. subscribed guaranteed bandwidth for a particular user is exceeded), the PCRF shall indicate in the AA-Answer command the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED. If the service information provided in the AA-Request command is rejected by the PCRF due to a temporary condition in the network (e.g. the user plane in the cell the user is located is congested), the PCRF may indicate in the AA-Answer the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_TEMPORARILY_NOT_AUTHORIZED (4261). The PCRF may also provide a retry-interval within the Retry-Interval AVP in the AA-Answer command to the AF. When the AF receives the re-try interval within the Retry-Interval AVP, the AF shall not send the same service information to the PCRF again (for the same IP-CAN session) until the re-try interval has elapsed. The PCRF may additionally provide the acceptable bandwidth within the Acceptable-Service-Info AVP in the AA-Answer command.

NOTE 5: How the PCRF derives the re-try interval is up to implementation.

If accepted, the PCRF shall update the Service Information with the new information received. Due to the updated Service Information, the PCRF may need to create, modify or delete the related PCC rules as specified in 3GPP TS 29.213 [9] and provide the updated information towards the PCEF following the corresponding procedures specified at 3GPP TS 29.212 [8]. The procedures to update the Authorized QoS for the affected IP-CAN bearer are also specified at 3GPP TS 29.212 [8].

If the Sharing-Key-UL AVP and/or Sharing-Key-DL AVP are provided within the Media-Component-Description AVP, the PCRF may apply the mechanisms for resource sharing as specified at 3GPP TS 29.212 [8].

The PCRF shall reply with an AA-Answer to the AF. The acknowledgement towards the AF should take place before or in parallel with any required PCC Rule provisioning towards the PCEF and shall include the Access‑Network-Charging-Identifier(s) and may include the Access-Network-Charging-Address AVP, if they are available at this moment and have not been yet supplied earlier to the AF. The AA-Answer message shall include the AN-GW-Address AVP if the PCRF has previously requested to be updated with this information in the PCEF. The AA-Answer message shall also include the PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP if the PCRF has previously requested to be updated with this information in the PCEF/BBERF. The AA-Answer message shall also include the IP-CAN-Type AVP if the PCRF has previously requested to be updated with this information in the PCEF/BBERF . In that case, the AA-Answer message shall also include the RAT type information within the RAT-Type AVP and AN-Trusted AVP when applicable for the specific IP-CAN Type. In addition, if IP flow mobility applies to service data flows as specified in 3GPP TS 29.212 [8], such that a subset of the flows within the AF session are affected, the PCRF shall also include IP-CAN-type and RAT type information (if applicable) to IP flow mobility related flows, if the PCRF has previously requested to be updated with this information in the PCEF. The IP flow mobility affected service data flows are included within the Flows AVP at command level. If the PCRF needs to terminate the Rx session before it has sent the AA Answer, the PCRF shall send the AA Answer immediately and before the AS Request. If the PCRF does not have an existing session for the Rx session being modified (such as after a PCRF failure), the PCRF may reject the request with an AA-Answer with the result code set to DIAMETER_UNKNOWN_SESSION_ID.

If the PCRF installs PCC/QoS rules or modifies existing PCC/QoS rules based on the updated service information and the installation or modification fails due to resource allocation failure as specified in 3GPP TS 29.212 [8] and if requested by the AF, the PCRF shall send an RAR command to the AF with the Specific-Action AVP set to the value INDICATION_OF_FAILED_RESOURCES_ALLOCATION to report the modification failure, the Flows AVP containing the service data flows corresponding to the resources that could not be allocated, and the content version(s) within the Content-Version AVP(s) if it was included when the corresponding media component was provisioned. If the modification of the existing PCC/QoS rules fails, the PCRF may also provide the status of the service information within the Media-Component-Status AVP. The AF shall send an RAA command to acknowledge the RAR command.

NOTE 6: The PCRF will report the Media-Component-Status AVP according to the status reported for the related PCC/QoS rules when the modification fails over the Gx/Gxx reference points as described in 3GPP TS 29.212 [8].

4.4.3 Gate Related Procedures

Depending on the application, in the Service Information provision, the AF may instruct the PCRF when the IP flow(s) are to be enabled or disabled to pass through the IP-CAN. The AF does this by sending the AA-Request message containing the Media-Component- Description AVP(s) that contains the flow status information (in the Flow-Status AVP) for the flows to be enabled or disabled.

In response to this action the PCRF shall set the appropriate gate status for the corresponding active PCC rule(s).

If a Media-Sub-Component AVP under a Media-Component-Description AVP contains a Flow-Usage AVP with the value RTCP, then the corresponding RTCP IP Flows in both directions shall be enabled even if the Flow-Status AVP under the Media-Sub-Component AVP is set to ENABLED-UPLINK, ENABLED-DOWNLINK, ENABLED, or DISABLED.

The PCRF shall reply with an AA-Answer and shall include the Access‑Network-Charging-Identifier(s) available at this moment. The PCRF forwards the AF decision to enable or disable the authorized IP flows.

The behaviour when the AF does not receive the AAA, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of this specification and based on operator policy.

4.4.4 AF Session Termination

When an AF session is terminated, if the AF had received a successful AA-Answer for the initial AA-Request, the AF shall send a Session-Termination-Request command to the PCRF. Otherwise, the AF shall wait for the initial AA-Answer to be received prior to sending the Session-Termination-Request command to the PCRF.

When the PCRF receives a ST-Request from the AF, indicating an AF session termination, it shall acknowledge that request by sending a ST-Answer to the AF. Afterwards, it shall free the resources allocated for the corresponding Service Data Flow(s). In order to do that, the PCRF shall initiate the request for the removal of any related PCC/QoS rules from the PCEF/BBERF and for the update of the Authorized QoS for the affected IP-CAN bearer following the corresponding procedures specified at 3GPP TS 29.212 [8]. However, if the AF requests the reporting of access network information within the ST-Request or if the AF provided a threshold for the sponsored data connectivity, the PCRF shall defer sending the ST-Answer.

If the AF session being terminated corresponds to an MPS session, the PCRF may revoke the actions related to the prioritization of the MPS session in the corresponding IP-CAN as defined in 3GPP TS 29.212 [8]. For Multimedia Priority Service handling for IMS, see Annex A.9.

If the AF session being terminated corresponds to the last Group Communication session for the IP-CAN session, the PCRF may revoke the actions related to the prioritization of the Group Communication session as specified in 3GPP TS 29.212 [8].

If the AF session being terminated corresponds to a session that included the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED within the Media-Component-Description AVP, the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in clause 4.4.8.

For sponsored data connectivity, and if a usage threshold was provided for the sponsored data connection at initial provisioning of session information (clause 4.4.1) or modification of session information (clause 4.4.2) procedures, the PCRF shall provide the usage consumed to the AF. For such purpose, the PCRF shall initiate the IP-CAN session modification procedure according 3GPP TS 29.212 [8] in order to obtain the consumed usage. The PCRF shall send then the ST-Answer to the AF including the Used-Service-Unit AVP for reporting accumulated usage within the Sponsored-Connectivity-Data AVP.

If the AF requires access network information at this step, the AF shall include the Required-Access-Info AVP within the ST-Request command, indicating the required information. In this case, the PCRF shall initiate the IP-CAN session modification procedure according to 3GPP TS 29.212 [8]. The PCRF shall send then the ST-Answer to the AF including the required data within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier AVP (if available), User-Location-Info-Time AVP (if available), UE-Local-IP-Address AVP (if available), UDP-Source-Port AVP (if available), TCP-Source-Port AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available).

If the RAN-NAS-Cause feature is supported and the AF initiated the termination of the AF session, upon reception of the ST-Request command, the PCRF shall initiate the IP-CAN session modification procedure according to 3GPP TS 29.212 [8].

If the RAN-NAS-Cause feature is supported , in all the AF session termination cases , t he PCRF shall send the ST-Answer to the AF including the access network information within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier (if available and Netloc-Trusted-WLAN feature is supported) User-Location-Info-Time AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available). Additionally, if the PCRF received from the PCEF the RAN cause and/or NAS cause, TWAN cause or untrusted WLAN cause, the PCRF shall provide the received cause(s) in the RAN-NAS-Release-Cause AVP in the ST-Answer command.

NOTE: The PCRF will apply the procedures described in 3GPP TS 29.212 [8] to get updated about the outcome of the resource release over Gx reference point in order to get the location and failure cause(s) when applicable.

4.4.5 Subscription to Notification of Signalling Path Status

An AF may subscribe to notifications of the status of the AF Signalling transmission path. To do so, the AF shall open an Rx Diameter session with the PCRF for the AF signalling using an AA-Request command. The AF shall provide the UE’s IP address (using either the Framed-IP-Address AVP or the Framed-Ipv6-Prefix AVP) and the Specific-Action AVP requesting the subscription to "INDICATION_OF_LOSS_OF BEARER" and/or "INDICATION_OF_RELEASE_OF_BEARER". The AF shall additionally provide a Media-Component-Description AVP including a single Media-Sub-Component AVP with the Flow-Usage AVP set to the value "AF_SIGNALLING". The Media-Component-Description AVP shall contain the Media-Component-Number AVP set to "0".

If the procedures in Clause 4.4.5A are not applied, the Media-Sub-Component AVP shall contain the Flow-Number AVP set to "0", and the rest of AVPs within the Media-Component-Description and Media-Sub-Component AVPs shall not be used in this case.

When the PCRF receives an AA-Request as described in the preceding paragraph from the AF, the PCRF shall perform session binding as described in 3GPP TS 29.213 [9] and acknowledges the AAR command by sending an AA‑Answer command to the AF.

PCC/QoS Rules related to AF Signalling IP Flows should be provisioned to PCEF/BBERF using the corresponding procedures specified at 3GPP TS 29.212 [8] at an earlier stage (e.g. typically at the establishment of the IP-CAN bearer dedicated for AF Signalling IP Flows). The PCRF may install the corresponding dynamic PCC/QoS rule for the AF signalling IP flows if none has been installed before.

NOTE 1: Well-known ports (e.g. 3GPP TS 24.229 [17] for SIP) or wildcard ports can be used by PCRF to derive the dynamic PCC/QoS rule for the AF signalling IP flows.

If the Rx Diameter Session is only used for subscription to Notification of Signalling Path Status, the AF may cancel the subscription to notifications of the status of the AF Signalling transmission path. In that case, the AF shall use a Session-Termination-Request (STR) command to the PCRF, which shall be acknowledged with a Session-Termination-Answer (STA) command.

NOTE 2: The Rx Diameter Session created for the AF signalling can also be used when the AF requests notifications of IP-CAN type change, PLMN change, access network information for SMS over IP and/or when the AF provisions AF Signalling Flow Information.

4.4.5A Provisioning of AF Signalling Flow Information

This clause is applicable when IMS restoration is supported according to supported feature ProvAFsignalFlow as described in clause 5.4.1.

An AF may provision information about the AF signalling IP flows between the UE and the AF. To do so, the AF shall make use of an Rx Diameter session already opened with the PCRF if an Rx Diameter session related to the AF signalling is already established. The AF may modify an already open Rx Diameter session related to the AF signalling (e.g. an Rx Diameter session established for the purpose of subscription to notification of signalling path status as described in 4.4.5) or it may open a new Rx Diameter session related to the AF signalling if none exists.

To provision the AF signalling flow information the AF shall provide the UE’s IP address using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP. The AF shall additionally provide a Media-Component-Description AVP including one or more Media-Sub-Component AVP(s) representing the AF signalling IP flows. The Media-Component-Description AVP shall contain the Media-Component-Number AVP set to "0". Each Media-Sub-Component AVP representing an AF signalling IP flow shall contain the Flow-Number AVP set according to the rules described in Annex B and one or two Flow-Description AVP(s) set to the IP flows of the AF signalling. Additionally, the Media-Sub-Component AVP shall include the Flow-Usage AVP set to the value "AF_SIGNALLING", the Flow-Status AVP set to "ENABLED" and the AF-Signalling-Protocol AVP set to the value corresponding to the signalling protocol used between the UE and the AF.

When the PCRF receives from the AF an AA-Request as described in the preceding paragraph, the PCRF shall perform session binding as described in 3GPP TS 29.213 [9] and shall acknowledge the AAR command by sending an AA‑Answer command to the AF.

PCC/QoS Rules related to the AF signalling IP flows could have been provisioned to PCEF/BBERF using the corresponding procedures specified in 3GPP TS 29.212 [8] at an earlier stage (e.g. typically at the establishment of the IP-CAN bearer dedicated for AF Signalling IP Flows). The PCRF shall install the corresponding dynamic PCC/QoS rule for the AF signalling IP flows.

The AF may de-provision the information about the AF signalling IP flows at any time. To do that, if the Rx Diameter session is only used to provide information about the AF Signalling IP flows, the AF shall close the Rx Diameter session by sending a Session-Termination-Request (STR) command to the PCRF, which shall be acknowledged with a Session-Termination-Answer (STA) command. Otherwise, the AF shall remove the IP flows within the Media-Sub-Component AVP by supplying the Flow-Status AVP with value "REMOVED". In both cases, the PCRF shall remove the corresponding dynamic PCC/QoS rule for the AF signalling IP flows.

4.4.6 Traffic Plane Events

4.4.6.1 IP-CAN Session Termination

When an IP-CAN session is terminated, the PCRF shall inform the AF about the IP-CAN session termination by sending an ASR (abort session request) command to the AF on each active Rx Diameter session.

When the AF receives the ASR command, it shall acknowledge the command by sending an ASA (abort session answer) command to the PCRF. After that the AF shall initiate an AF session termination procedure as defined in clause 4.4.4.

Signalling flows for IP-CAN session termination cases are presented in 3GPP TS 29.213 [9].

4.4.6.2 Service Data Flow Deactivation and Resource Allocation Failure

It may happen that one or more PCC/QoS Rules (i.e. Service Data Flows) are deactivated at the PCEF/BBERF at a certain time, either permanently or temporarily or resource allocation for one or more PCC rules is unsuccessful at the PCEF/BBERF when the PCC rule(s) are installed. When the PCRF gets the knowledge that one or more SDFs have been deactivated, (e.g. due to a bearer release or loss of bearer or out of credit condition), or the resource allocation failed the PCRF shall inform the AF accordingly if the AF has previously subscribed using the Specific-Action AVP in the AAR command.

When not all the service data flows within the AF session are affected, the PCRF shall inform the AF by sending an RAR (re-authorization request) command. The RAR command shall include the affected IP Flows encoded in the Flows AVP, the cause encoded in the Specific-Action AVP and the content version of a media component within the Content-Version AVP if it was included when the media component was provisioned.

If the RAN-NAS-Cause feature is supported and the PCRF received the access network information from the PCEF/BBERF due to bearer termination or unsuccessful bearer establishment/modification, the PCRF shall include in the RAR command the access network information within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier (if available and Netloc-Trusted-WLAN feature is supported) User-Location-Info-Time AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available). Additionally, if the PCRF received from the PCEF the RAN cause and/or NAS cause, TWAN cause or untrusted WLAN cause due to bearer termination, the PCRF shall provide the received cause(s) in the RAN-NAS-Release-Cause AVP in the RAR command.

When the AF receives the RAR command, it shall acknowledge the command by sending an RAA (re-authorization answer) command to the PCRF. The AF may also update the session information by sending an AAR (AA-request) command to the PCRF.

If the PCRF receives the AAR command, it shall acknowledge the command by sending an AAA (AA-answer) command to the AF.

When all the service data flows within the AF session are affected, the PCRF shall inform the AF by sending an ASR command on the Rx Diameter session related to the AF session. When the AF receives the ASR command, it shall acknowledge the command by sending an ASA (abort session answer) command to the PCRF. After that the AF shall initiate an AF session termination procedure as defined in clause 4.4.4.

Signalling flows for Service Data Flow Deactivation and Resource Allocation Failure cases are presented in 3GPP TS 29.213 [9].

4.4.6.3 Notification of Signalling Path Status

In the event that the PCRF is notified of the loss or release of resources associated to the PCC/QoS Rules corresponding with AF Signalling IP Flows, the PCRF shall inform the AF about the Loss of the Signalling Transmission path by sending a Re‑Authorization Request (RAR) command to the AF. The RAR shall include the Specific-Action AVP set to the value "INDICATION_OF_LOSS_OF_BEARER" or "INDICATION_OF_RELEASE_OF_BEARER" and the deactivated IP Flow encoded in the Flows AVP.

NOTE: According to the standardized QCI characteristics as defined in 3GPP TS 23.203 [2], the IMS signalling specific PCC rules include a QCI corresponding to a non-GBR bearer. When these guidelines are followed, the INDICATION_OF_LOSS_OF_BEARER will not be reported.

If the RAN-NAS-Cause feature is supported and the PCRF received the access network information from the PCEF/BBERF due to bearer termination, the PCRF shall include in the RAR command the access network information within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier (if available and Netloc-Trusted-WLAN feature is supported) User-Location-Info-Time AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP (if available). Additionally, if the PCRF received from the PCEF the RAN cause and/or NAS cause, TWAN cause or untrusted WLAN cause due to bearer termination, the PCRF shall provide the received cause(s) in the RAN-NAS-Release-Cause AVP in the RAR command.

When the AF receives the RAR command, it shall acknowledge the command by sending an RAA command to the PCRF.

The AF may then decide to terminate the Rx Diameter session used for the notification of the status of the AF Signalling transmission path. The AF may also decide to terminate any other active Rx Diameter session with the PCRF related to the AF Signalling which is not available any longer. In that case, the AF shall then initiate the AF Termination procedure towards the PCRF as defined in clause 4.4.4.

4.4.6.4 IP-CAN type change Notification

If the AF has successfully subscribed to change notifications in UE’s IP-CAN type and RAT type, the PCRF shall send an RAR command when the corresponding event occurs, i.e. when the UE’s IP-CAN type or RAT type changes or becomes available. In this case the RAR from the PCRF shall include the Specific-Action AVP for the subscribed event and include the IP-CAN-Type AVP, RAT-Type AVP (if applicable) and AN-Trusted AVP (if applicable) and AN-GW-Address AVP (if applicable) for the UE’s new IP-CAN/RAT. If the PCRF is informed of an IP-CAN type change due to IP flow mobility as specified in 3GPP TS 29.212 [8], where a subset of the flows within the AF session are affected, the PCRF shall include IP-CAN type and RAT type information (if applicable) to IP flow mobility affected service data flows. The IP flow mobility affected service data flows are included within the Flows AVP at command level.

4.4.6.5 Access Network Charging Information Notification

If the AF has subscribed to a notification about Access Network Charging Information, the PCRF shall provide the Access Network Charging Information in the response, if already known by the PCRF. If not available, the PCRF shall provide the Access Network Charging Information by sending a Re-Authorization-Request (RAR) command when the Access Network Charging Information is received from the PCEF. If different Access Network Charging Information is applicable to the IP-CAN session, the PCRF shall notify the AF about the Access Network Charging Information that applies to each authorized flow. The RAR shall include the Specific-Action AVP set to the value "CHARGING_CORRELATION_EXCHANGE" and shall include the assigned Access‑Network-Charging-Identifier(s) and may include the Access-Network-Charging-Address AVP.

4.4.6.6 Reporting Usage for Sponsored Data Connectivity

When SponsoredConnectivity is supported or when SponsorChange is supported and the AF indicated to enable sponsored data connectivity and the AF provided usage monitoring thresholds for such sponsor to the PCRF when the Rx Diameter session was established or modified, the PCRF shall report accumulated usage to the AF, when

– the PCRF detects that the usage threshold provided by the AF has been reached; or

– the AF session is terminated by the AF;

– the AF disables the sponsored data connectivity; or

– the AF session is terminated by the PCRF due to the IP-CAN session termination, the termination of all the service data flows of the AF session or the home operator policy disallowing the UE accessing the sponsored data connectivity in the roaming case.

When the PCRF detects that the usage threshold has been reached or the AF disables the sponsored data connectivity, the PCRF shall report the accumulated usage as provided by the PCEF/TDF to the AF in a RA-Request (RAR) command with the Specific-Action AVP set to the value USAGE_REPORT; Otherwise, when the AF session is terminated by the AF or the PCRF, the PCRF shall report the accumulated usage as provided by the PCEF/TDF to the AF in ST-Answer (STA) command. The accumulated usage reported by the PCRF corresponds to the usage since the last report to the AF.

The accumulated usage shall be reported in the Used-Service-Unit AVP within the Sponsored-Connectivity-Data AVP.

If the AF receives a RAR command indicating the usage threshold is reached, the AF may terminate the AF session or provide a new usage threshold in the Granted-Service-Unit AVP within the Sponsored-Connectivity-Data AVP to the PCRF in the AAR command. Alternatively, the AF may allow the session to continue without providing new usage threshold in the AAR command.

NOTE: After the PCRF reports the accumulated usage to the AF, the AF can provide a new usage threshold to the PCRF. The monitoring will not start until the PCRF receives the new threshold from the AF and provide it to the PCEF

4.4.6.7 Reporting Access Network Information

If the AF requests the PCRF to report the access network information (i.e. user location and/or user timezone information), the AF shall subscribe to the "ACCESS_NETWORK_INFO_REPORT" within the Specific-Action AVP and shall include the required access network information within the Required-Access-Info AVP. The AF may request the PCRF to report the access network information in conjunction with providing the PCRF with the AF session information, refer to clause 4.4.1. Optionally, the AF may request the PCRF to report the access network information without providing service information (see clause A.10.2). In the latter case the AF establishes an Rx session for the AF session upon requesting the access network information from the PCRF with an AA-Request command, containing information required for the session binding in the Framed-IP-Address AVP, the Framed-Ipv6-Prefix AVP Subscription-Id AVP, the Called-Station-Id AVP and/or the IP-Domain-Id AVP.

The AF may also request the PCRF to report the access network information at Rx session termination. To do so, the AF shall include the required access network information within the Required-Access-Info AVP in the corresponding ST-Request.

When the PCRF receives a request to report the access network information from the AF in an AAR command or in an STR command triggered by the AF, if the PCRF determines that the access network does not support the access network information reporting based on the currently used IP-CAN type or the values of the RAT-Type AVP or the PCEF/BBERF does not support the NetLoc feature as described in clause 5.4.1, the PCRF shall respond to AF with an AAA or STA command including the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED); otherwise, it shall immediately configure the PCEF or BBERF to provide such access network information.

When the PCRF then receives the access network information from the PCEF/BBERF, the PCRF shall provide the corresponding access network information to the AF within the 3GPP-User-Location-Info AVP (if available), TWAN-Identifier AVP (if available), User-Location-Info-Time AVP (if available), UE-Local-IP-Address AVP (if available), UDP-Source-Port AVP (if available), TCP-Source-Port AVP (if available), 3GPP-SGSN-MCC-MNC AVP (if location info is not available) and/or 3GPP-MS-TimeZone AVP in the RAR command if the Rx session is not being terminated or in the STA command if the Rx session is being terminated. If the information is provided in the RAR command, PCRF shall also provide the ACCESS_NETWORK_INFO_REPORT within Specific-Action AVP.

NOTE 1: The PCRF receives the access network information from the PCEF/BBERF if it is requested by the AF previously or the IP-CAN bearer/IP-CAN session is terminated.

When the PCRF receives the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED) from the PCEF/BBERF, the PCRF shall send a RAR command including the Specific-Action AVP set to INDICATION_OF_ACCESS_NETWORK_INFO_REPORTING_FAILURE and the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED) if the AF requested the access network information in an AAR command or send an STA command including the NetLoc-Access-Support AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED) if the AF requested the access network information in an STR command.

NOTE 2: The 3GPP GPRS, 3GPP EPS, Untrusted WLAN and Trusted WLAN support access network information reporting in this release.

The PCRF shall not send an RAR command with the ACCESS_NETWORK_INFO_REPORT value within a Specific-Action AVP to report any subsequently received access network information to the AF, unless the AF sends a new request for access network information.

4.4.6.8 Temporary Network Failure handling

If the PCRF detects that a temporary network failure has occurred (e.g. the SGW has failed for 3GPP-EPS access as defined in clause B.3.14 of 3GPP TS 29.212 [8]) and the AF requests an AF session establishment or modification in an AA-Request command, the PCRF shall respond to the AF with an AA-Answer including the Experimental-Result-Code AVP set to the value TEMPORARY_NETWORK_FAILURE.

If the PCRF detects that a temporary network failure has occurred (e.g. the SGW has failed for 3GPP-EPS access) and the AF requests an AF session termination in a ST-Request command, the PCRF shall respond with successful Result-Code AVP to the AF.

NOTE 1: If the AF includes the Required-Access-Info AVP in the ST-Request command to request the access network information, the PCRF will not include the access network information in the ST-Answer command.

NOTE 2: Actions over Gx/Gxx reference point when there is a temporary network failure are described in 3GPP TS 29.212 [8]. For example, for S-GW Restoration procedures the PCRF will wait for the SGW recovery before deleting the corresponding PCC/QoS rules,according to clause B.3.14 in that specification.

If the PCRF detects that the PCC/QoS rules related to an AF session cannot be installed or modified because there is a temporary network failure (e.g. SGW failed according to clause B.3.14 in 3GPP TS 29.212 [8]) and if requested by the AF, the PCRF shall send a RA-Request command to the AF with the Specific-Action AVP set to INDICATION_OF_FAILED_RESOURCES_ALLOCATION and the content version of a media component within the Content-Version AVP if it was included when the media component was provisioned. If the modification of the PCC/QoS rules fails, the PCRF may provide the status of the related service information within the Media-Component-Status AVP.

4.4.6.9 PLMN information change Notification

If the AF has successfully subscribed to PLMN_CHANGE notification, the PCRF shall send an RAR command when the corresponding event occurs, i.e. when the PLMN where the UE is located has been updated or becomes available. In this case the RAR from the PCRF shall include the Specific-Action AVP set to PLMN_CHANGE and include the 3GPP-SGSN-MCC-MNC AVP for the PLMN where the UE is located.

4.4.7 P-CSCF Restoration Enhancement Support

This clause is applicable when the PCRF-based P-CSCF Restoration Enhancement, as defined in 3GPP TS 23.380 [28], is supported by both P-CSCF and PCRF.

The P-CSCF acting as AF shall send an AAR command including the Rx-Request-Type AVP set to the value PCSCF_RESTORATION (2) to the PCRF in the case P-CSCF Restoration needs to be performed. This AAR shall include the following information required by the DRA or PCRF to find the corresponding IP-CAN session:

– The UE’s IP address as applicable in the Framed-IP-Address AVP or in the Framed-Ipv6-Prefix AVP. If the IP address is not unique (e.g. private IPv4 case), the P-CSCF shall also include the IP-Domain-ID AVP if available.

– If the IP address is not available or if the IP address is not unique and the IP-Domain-ID is not available, the P-CSCF shall include the IMSI in the Subscription-Id AVP and the APN in the Called-Station-Id AVP.

The AF shall also include the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1) in the AAR command, as described in IETF RFC 6733 [52]. As a consequence, the PCRF shall not maintain any state information about this session.

The PCRF shall acknowledge the AAR command by sending an AAA command to the P-CSCF acting as AF and shall include the Auth-Session-State AVP set to NO_STATE_MAINTAINED (1). The PCRF shall send a request for P-CSCF Restoration to the PCEF for the corresponding IP-CAN session.

4.4.8 Priority Sharing Request

If PrioritySharing feature is supported, the AF may include the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED within the Media-Component-Description AVP in order to indicate to the PCRF that the related media flow is allowed to use the same Allocation and Retention Priority as media flows which are assigned the same QCI in the PCRF belonging to other AF sessions for the same IP-CAN session that also contain the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED. If the MCPTT-Preemption feature is supported, the AF may also include the Pre-emption-Capability AVP containing the suggested pre-emption capability value and the Pre-emption-Vulnerability AVP containing the suggested pre-emption vulnerability value within the Media-Component-Description AVP for the PCRF to determine ARP values and include the Pre-emption-Control-Info AVP containing the pre-emption control information at the AAR command level for the PCRF to perform pre-emption control. The AF may also include the INDICATION_OF_FAILED_RESOURCES_ALLOCATION within Specific-Action AVP to request notification for resource allocation failure. Upon reception of this information, the PCRF shall behave as described in 3GPP TS 29.212 [8], clauses 4.5.27 and 4a.5.17. For the handling of MCPTT sessions, see Annex A.13.

NOTE 1: Service data flow deactivation procedures will apply according to clause 4.4.6.2.

NOTE 2: This enhancement avoids the risk that a bearer establishment request is rejected if the maximum number of active bearers is exceeded.

If the AF earlier has indicated a media flow priority sharing to the PCRF by setting the Priority-Sharing-Indicator AVP to PRIORITY_SHARING_ENABLED, the AF may include the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_DISABLED within the Media-Component-Description AVP in order to indicate to the PCRF that the related media flow shall not be part of the mechanism for sharing the Allocation and Retention Priority with other media flows any longer.
If this media flow was in priority sharing with other media flows the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in 3GPP TS 29.212 [8], clauses 4.5.27 and4a.5.17 and handle the media flow excluded from priority sharing according to normal PCC/QoS rule provisioning procedures described in 3GPP TS 29.212 [8], clauses 4.5.2 and 4a.5.2.

If the AF earlier has indicated media flow priority sharing to the PCRF by setting the Priority-Sharing-Indicator AVP to PRIORITY_SHARING_ENABLED for media flows and the AF indicates to remove one or more of the media flows in priority sharing with other media flows, the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in 3GPP TS 29.212 [8], clauses 4.5.27 and 4a.5.17 and handle the media flow removed according to normal PCC/QoS rule provisioning procedures described in 3GPP TS 29.212 [8], clauses 4.5.2 and 4a.5.2.

If the AF session being terminated corresponds to a session that included the Priority-Sharing-Indicator AVP set to PRIORITY_SHARING_ENABLED within the Media-Component Description AVP, if the related media flow(s) was in priority sharing with other media flows the PCRF should readjust the Allocation and Retention Priority for the remaining services sharing Allocation and Retention Priority as described in 3GPP TS 29.212 [8] , clauses 4.5.27 and 4a.5.17 and handle the media flow removed according to normal PCC/QoS rule provisioning procedures described in 3GPP TS 29.212 [8], clauses 4.5.2 and 4a.5.2.

4.4.9 Support for media component versioning

The support of the media component versioning is optional. When the MediaComponentVersioning feature is supported, the AF and the PCRF shall comply with the procedures specified in this clause.

If required by operator policies, the AF shall assign a content version to the media component related to certain service and provide the PCRF within the Content-Version AVP as part of the Media-Component-Description AVP. Upon each media component modification, if the content version was assigned to a media component, the AF shall assign a new content version. In this case, all the content related to that media component shall be included. The content version shall be unique for the lifetime of the media component.

NOTE 1: The AF will include all the content of the media component in each media component modification in order to ensure that the media component is installed with the proper information regardless of the outcome of the bearer procedure related to previous interactions that are not reported to the PCRF yet.

If the PCRF receives the Content-Version AVP including an content version for certain media component, the PCRF will follow the procedures described in 3GPP TS 29.212 [8], clause 4.5.28 and clause 4a.5.18.

When the PCRF is notified about the outcome of the resource allocation related to one content version of a media component as described in clause 4.5.28 or clause 4a.5.18 in 3GPP TS 29.212 [8] and if the PCRF is required to notify the AF, the PCRF shall provide the content version of the media component within the Content-Version AVP corresponding to the value of content version of the PCC/QoS rule and the status of the media component within the Media-Component-Status AVP corresponding to the status of the PCC/QoS rule to the AF as part of the Flows AVP.

The PCRF shall include more than one Content-Version AVPs for the same media component within the Flows AVP in a RAR command if it has received multiple content versions as described in clause 4.5.28 or clause 4a.5.18 in 3GPP TS 29.212 [8].

NOTE 2: The AF will use the content version to identify the media component version that failed or succeed when multiple provisions of the same media component occur in a short period of time. How the AF handles such situations is not specified.

4.4.10 Extended bandwidth support for EPC supporting Dual Connectivity (E-UTRAN and 5G NR)

When the Extended-Max-Requested-BW-NR feature, the Extended-Min-Requested-BW-NR feature, and/or the Extended-BW-E2EQOSMTSI-NR features are supported, extended bandwidth AVPs representing bitrates in kbps shall be used to represent bandwidth values higher than 2^32-1 bps instead of the bandwidth AVPs with a maximum value of 2^32-1 bps that represent bitrates in bps.

For the Extended-Max-Requested-BW-NR feature:

– Extended-Max-Requested-BW-DL/UL AVPs shall be used instead of Max-Requested-Bandwidth-DL/UL AVPs.

For the Extended-BW-E2EQOSMTSI-NR feature:

– Extended-Max-Supported-BW-DL/UL AVPs shall be used instead of Max-Supported-Bandwidth-DL/UL AVPs.

– Extended-Min-Desired-BW‑DL/UL AVPs shall be used instead of Min-Desired-Bandwidth-DL/UL AVPs.

For the Extended-Min-Requested-BW-NR feature:

– Extended-Min-Requested-BW-DL/UL AVPs shall be used instead of Min-Requested-Bandwidth-DL/UL AVPs.

For values lower or equal to 2^32-1 bps AVPs representing bitrates in bps shall be used.

When the Rx session is being established, if the AF supports the corresponding feature (as listed above) and needs to indicate bandwidth values higher than 2^32-1 bps, AVPs representing bitrate in bps shall be provided with value set to 2^32-1 bps and bandwidth AVPs representing bitrate in kbps shall be provided with the actual required bandwidth.

NOTE: When the Diameter session is being established, the originator node does not know yet the features supported by the peer node.

4.4.11 MPS for DTS Control

The support of the MPSforDTS feature is optional. When the MPSforDTS feature is supported as described in clause 5.4.1, the AF and the PCRF shall comply with the procedures specified in this clause.

MPS for DTS is the means for an AF to invoke/revoke the Priority EPS Bearer Service for the default bearer only, i.e. without designating a particular service data flow for priority service. MPS for DTS applies only to non-IMS APNs.

To invoke/revoke MPS for DTS, the AF shall include the MPS-Action AVP in the AAR command. The MPS-Action AVP signals a change to the default bearer and IP flows mapped to the default bearer.

When the MPS-Action AVP is set to ENABLE_MPS_FOR_DTS (1) and included in the AAR command, and if allowed by local policy, the PCRF does not check the user’s MPS subscription details and shall upgrade the QoS of the default bearer to MPS, as specified in 3GPP TS 29.212 [8].

When the MPS-Action AVP is set to AUTHORIZE_AND_ENABLE_MPS_FOR_DTS (2) and included in the AAR command, and if allowed by local policy, the PCRF shall check the user’s MPS subscription details and if valid, shall upgrade the QoS of the default bearer to MPS, as specified in 3GPP TS 29.212 [8]. If the request is not allowed, the PCRF shall reject the request indicating REQUESTED_SERVICE_NOT_AUTHORIZED.

When the MPS-Action AVP is set to DISABLE_MPS_FOR_DTS (0) and included in the AAR command, and if allowed by local policy, the PCRF does not check the user’s MPS subscription details and shall downgrade the QoS of the default bearer to non-MPS priority, as specified in 3GPP TS 29.212 [8].

NOTE: How the AF authorizes the request is out of scope of the present document.

The AF may also include in the AAR command the Specific-Action AVP with the value SUCCESSFUL_QOS_UPDATE to request notification when the PCRF has successfully acted upon the invocation/revocation request indicated in the MPS-Action AVP. The PCRF shall inform the AF of successful MPS for DTS invocation/revocation with a RAR command with the Specific-Action AVP with the value SUCCESSFUL_QOS_UPDATE.

The AF may also include in the AAR command the Specific-Action AVP with the value FAILED_QOS_UPDATE to request notification when the invocation/revocation request indicated in the MPS-Action AVP has failed. The PCRF shall inform the AF of the failure of the MPS for DTS invocation/revocation with a RAR command with the Specific-Action AVP with the value FAILED_QOS_UPDATE.

When the PCRF receives from the AF an AA-Request as described in the preceding paragraphs, the PCRF shall perform session binding as described in 3GPP TS 29.213 [9] and shall acknowledge the AAR command by sending an AA‑Answer command to the AF.

The PCRF shall install the event trigger for the MPS for DTS request using the corresponding procedures specified in 3GPP TS 29.212 [8] if the AF requests the notification.

The AF may use the procedure specified in clause 4.4.12 to establish a priority signalling IP flow between the UE and AF.

4.4.12 Provisioning of MPS for DTS AF Signalling Flow Information

This clause is applicable when MPS for DTS is supported according to the supported feature MPSforDTS as described in clause 5.4.1.

An AF may provision information about the AF signalling IP flows between the UE and the AF. To do so, the AF may modify an already open Rx Diameter session related to the AF signalling (e.g. an Rx Diameter session established for the purpose of DTS control as described in clause 4.4.11) or it may open a new Rx Diameter session related to the AF signalling if none exists.

To provision the AF signalling flow information, the AF shall provide the UE’s IP address using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP. The AF shall additionally provide the MPS-Identifier AVP and a Media-Component-Description AVP including a Media-Sub-Component AVP representing the AF signalling IP flow. The Media-Sub-Component AVP shall include the Flow-Usage AVP set to the value "AF_SIGNALLING" and the Flow-Status AVP set to "ENABLED".

When the PCRF receives from the AF an AA-Request as described in the preceding paragraph, the PCRF shall determine whether the request is accepted or not. If accepted, the PCRF shall perform session binding as described in 3GPP TS 29.213 [9] and shall acknowledge the AAR command by sending an AA‑Answer command to the AF. If rejected, the PCRF shall indicate the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED.

The PCRF shall set appropriate QoS values for the AF signalling IP flow and install the corresponding dynamic PCC rule at the PCEF and the QoS rule at BBERF if applicable.

NOTE: Combining the request for the AF signalling flow with an MPS for DTS invocation/revocation request is not supported in this release.