PCRF <------ Rx Interface ------> AF

Rx Interface - 29.214 

 

Overview  

 

The Rx reference point is used to exchange application level session information between the Policy and Charging Rules Function (PCRF) and the Application Function (AF). Signalling flows related to the both Rx and Gx interfaces are specified in 3GPP TS 29.213  
 

Rx Reference Model:

 

 

Definitions: 

Application Function (AF):

Element offering application(s) that use IP bearer resources

 

    NOTE: One example of an AF is the P-CSCF of the IM CN subsystem.

 

AF Session:

application level session established by an application level signalling protocol offered by the AF that requires a session set-up with explicit session description before the use of the service.  

NOTE: One example of an application session is an IMS session.

 

Binding:

PCRF process of associating IP flows described in AF Service Information with IP-CAN bearers. 

PCC rule:

set of information enabling the detection of a service data flow and providing parameters for policy control and/or charging control

 

service information:

set of information conveyed from the AF to the PCRF over the Rx interface to be used as a basis for PCC decisions at the PCRF, including information about the AF session (e.g. application identifier, type of media, bandwidth, IP address and port number)

 

service data flow:

An aggregate set of packet flows. 

 

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/SBC. The AF shall use the Rx reference point to provide session information to the PCRF. i.e VoLTE/VoIP
 

PCRF  

 

The PCRF (Policy Control and Charging Rules Function) is a functional element that encompasses policy control decision and flow based charging control functionalities. 

 

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.

 

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.

 

PCC procedures over Rx reference point 

Initial Provisioning

• 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 . 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 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 traffic. 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.
   
• 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].
   
• 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 BBEF) to provide the access network information.
• For sponsored data connectivity, 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.
   
• 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.
• 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.
  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 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], subclause 4.5.20, then the PCRF shall reject the request indicating REQUESTED_SERVICE_NOT_AUTHORIZED.
  - If the PCEF 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 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.
  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. 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 the cause for the rejection with the Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED. The PCRF may additionally provide the acceptable bandwidth within the Acceptable-Service-Info AVP.
   
  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: In SDP source port information is usually not available.
  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 PCRF shall check whether the received Service Information requires PCC/QoS Rules to be created and provisioned and/or authorized QoS to be provisioned. Provisioning of PCC/QoS Rules and Authorized QoS to the PCEF/BBERF shall be carried out 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 IP-CAN-Type AVP, if such information is available. In that case, the AA-Answer message shall also include the RAT-Type AVP when applicable for the specific IP-CAN Type (e.g. 3GPP 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 AF shall send an RAA command to acknowledge the RAR command.

  

Rx messages
 

Existing Diameter command codes from the Diameter base protocol RFC 3588 [10] and the NASREQ Diameter application (RFC 4005 [12]) are used with the Rx specific AVPs. An Rx specific Auth‑Application id is used together with the command code to identify the Rx messages.

NOTE 1: The notion of NAS (Network Access Server) is not used here, NASREQ is just used for protocol purposes, not for its functional meaning.

NOTE 2: Some of the AVPs included in the messages formats below are in bold to highlight that these AVPs are used by this specific protocol and do not belong to the original Diameter Base Protocol RFC 3588 [10].

NOTE3: Multiple instances of the Subscription-Id AVP in the AAR or RAR command correspond to multiple types of identifier for the same subscriber, for example IMSI and MSISDN.

5.6.1 AA-Request (AAR) command

The AAR command, indicated by the Command-Code field set to 265 and the ‘R’ bit set in the Command Flags field, is sent by an AF to the PCRF in order to provide it with the Session Information.

Message Format:

<AA-Request> ::= < Diameter Header: 265, REQ, PXY >

                 < Session-Id >

                 { Auth-Application-Id }

                 { Origin-Host }

                 { Origin-Realm }

                 { Destination-Realm }

                 [ Destination-Host ]

                 [ IP-Domain-Id ]

                 [ AF-Application-Identifier ]

                *[ Media-Component-Description ]

                 [ Service-Info-Status ]

                 [ AF-Charging-Identifier ]

                 [ SIP-Forking-Indication ]

                *[ Specific-Action ]

                *[ Subscription-Id ]

                *[ Supported-Features ]

                 [ Reservation-Priority ]

                 [ Framed-IP-Address ]

                 [ Framed-Ipv6-Prefix ]

                 [ Called-Station-Id ]

                 [ Service-URN ]

                 [ Sponsored-Connectivity-Data ]

                 [ MPS-Identifier ]

                 [ Rx-Request-Type ]

                *[ Required-Access-Info ]

                 [ Origin-State-Id ]

                *[ Proxy-Info ]

                *[ Route-Record ]

                *[ AVP ]

5.6.2 AA-Answer (AAA) command

The AAA command, indicated by the Command-Code field set to 265 and the ‘R’ bit cleared in the Command Flags field, is sent by the PCRF to the AF in response to the AAR command.

Message Format:

<AA-Answer> ::= < Diameter Header: 265, PXY >

                < Session-Id >

                { Auth-Application-Id }

                { Origin-Host }

                { Origin-Realm }

                [ Result-Code ]

                [ Experimental-Result ]

               *[ Access-Network-Charging-Identifier ]

                [ Access-Network-Charging-Address ]

                [ Acceptable-Service-Info ]

                [ IP-CAN-Type ]

                [ NetLoc-Access-Support ]

                [ RAT-Type ]

               *[ Flows ]

               *[ Supported-Features ]

               *[ Class ]

                [ Error-Message ]

                [ Error-Reporting-Host ]

               *[ Failed-AVP ]

                [ Origin-State-Id ]

               *[ Redirect-Host ]

                [ Redirect-Host-Usage ]

                [ Redirect-Max-Cache-Time ]

               *[ Proxy-Info ]

               *[ AVP ]

5.6.3 Re-Auth-Request (RAR) command

The RAR command, indicated by the Command-Code field set to 258 and the ‘R’ bit set in the Command Flags field, is sent by the PCRF to the AF in order to indicate an Rx specific action.
 

Message Format:
 

<RA-Request> ::= < Diameter Header: 258, REQ, PXY >

                 < Session-Id >

                 { Origin-Host }

                 { Origin-Realm }

                 { Destination-Realm }

                 { Destination-Host }

                 { Auth-Application-Id }

                *{ Specific-Action }

                *[ Access-Network-Charging-Identifier ]

                 [ Access-Network-Charging-Address ]

                *[ Flows ]

                *[ Subscription-Id ]

                 [ Abort-Cause ]

                 [ IP-CAN-Type ]

                 [ NetLoc-Access-Support ]

                 [ RAT-Type ]

                 [ Sponsored-Connectivity-Data ]

                 [ 3GPP-User-Location-Info ]

                 [ User-Location-Info-Time ]

                 [ 3GPP-MS-TimeZone ]

                 [ 3GPP-SGSN-MCC-MNC ]

                 [ Origin-State-Id ]

                *[ Class ]

                *[ Proxy-Info ]

                *[ Route-Record ]

                *[ AVP ]

5.6.4 Re-Auth-Answer (RAA) command

The RAA command, indicated by the Command-Code field set to 258 and the ‘R’ bit cleared in the Command Flags field, is sent by the AF to the PCRF in response to the RAR command.
 

Message Format:
 

<RA-Answer> ::= < Diameter Header: 258, PXY >

                < Session-Id >

                { Origin-Host }

                { Origin-Realm }

                [ Result-Code ]

                [ Experimental-Result ]

               *[ Media-Component-Description ]

                [ Service-URN ]

                [ Origin-State-Id ]

               *[ Class ]

                [ Error-Message ]

                [ Error-Reporting-Host ]

               *[ Redirect-Host ]

                [ Redirect-Host-Usage ]

                [ Redirect-Max-Cache-Time ]

               *[ Failed-AVP ]

               *[ Proxy-Info ]

               *[ AVP ]

5.6.5 Session-Termination-Request (STR) command

The STR command, indicated by the Command-Code field set to 275 and the ‘R’ bit set in the Command Flags field, is sent by the AF to inform the PCRF that an established session shall be terminated.
 

Message Format:
 

<ST-Request> ::= < Diameter Header: 275, REQ, PXY >

                 < Session-Id >

                 { Origin-Host }

                 { Origin-Realm }

                 { Destination-Realm }

                 { Auth-Application-Id }

                 { Termination-Cause }

                 [ Destination-Host ]

                *[ Required-Access-Info ]

                *[ Class ]

                 [ Origin-State-Id ]

                *[ Proxy-Info ]

                *[ Route-Record ]

                *[ AVP ]

5.6.6 Session-Termination-Answer (STA) command

The STA command, indicated by the Command-Code field set to 275 and the ‘R’ bit cleared in the Command Flags field, is sent by the PCRF to the AF in response to the STR command.
 

Message Format:
 

<ST-Answer> ::= < Diameter Header: 275, PXY >

                < Session-Id >

                { Origin-Host }

                { Origin-Realm }

                [ Result-Code ]

                [ Error-Message ]

                [ Error-Reporting-Host ]

              * [ Failed-AVP ]

                [ Sponsored-Connectivity-Data ]

                [ Origin-State-Id ]

                [ 3GPP-User-Location-Info ]

                [ User-Location-Info-Time ]

                [ 3GPP-MS-TimeZone ]

                [ 3GPP-SGSN-MCC-MNC ]

                [ NetLoc-Access-Support ]

               *[ Class ]

               *[ Redirect-Host ]

                [ Redirect-Host-Usage ]

                [ Redirect-Max-Cache-Time ]

               *[ Proxy-Info ]

               *[ AVP ]

5.6.7 Abort-Session-Request (ASR) command

The ASR command, indicated by the Command-Code field set to 274 and the ‘R’ bit set in the Command Flags field, is sent by the PCRF to inform the AF that bearer for the established session is no longer available.

Message Format:

<AS-Request> ::= < Diameter Header: 274, REQ, PXY >

                 < Session-Id >

                 { Origin-Host }

                 { Origin-Realm }

                 { Destination-Realm }

                 { Destination-Host }

                 { Auth-Application-Id }

                 { Abort-Cause }

                 [ Origin-State-Id ]

                *[ Proxy-Info ]

                *[ Route-Record ]

                *[ AVP ]

5.6.8 Abort-Session-Answer (ASA) command

The ASA command, indicated by the Command-Code field set to 274 and the ‘R’ bit cleared in the Command Flags field, is sent by the AF to the PCRF in response to the ASR command.
 

Message Format:
 

<AS-Answer> ::= < Diameter Header: 274, PXY >

                < Session-Id >

                { Origin-Host }

                { Origin-Realm }

                [ Result-Code ]

                [ Origin-State-Id ]

                [ Error-Message ]

                [ Error-Reporting-Host ]

               *[ Failed-AVP ]

               *[ Redirect-Host ]

                [ Redirect-Host-Usage ]

                [ Redirect-Max-Cache-Time ]

               *[ Proxy-Info ]

               *[ AVP ]