Rx interface is often overlooked in IMS training, yet from the network core standpoint it is the most important one. It makes possible for IMS to allocate the data resources required for a media session.
As we discussed in VoLTE Policy Control, the Rx Reference point is defined between P-CSCF (referred in spec as AF) and PCRF (the PCC architecture is defined in 3GPP 23.203 and 29.212). Via this interface the P-CSCF provides session information to the PCRF. The PCRF then informs the P-CSCF of traffic plane events. It can also verify that the service information provided by the P-CSCF is consistent with the operator defined policy rules. The service information is used to derive the QoS for the media service.
The PCRF can also reject the request received from the P-CSCF. In that case the PCRF indicates the result in the answer and provides to P-CSCF the service information that can be accepted.
The Rx protocol is defined in 3GPP 29.213, 3GPP 29.214, however information in the post is taken mainly from GSMA IR.92 and FMC.01. The Rx interface enables transport of application level session information from P-CSCF to PCRF. Such information may include:
- IP filter information to identify the service data flow for policy control and/or differentiated charging;
- Media/application bandwidth requirements for QoS control.
- In addition, for sponsored data connectivity:
- the sponsor’s identification,
- optionally, a usage threshold and whether the PCRF reports these events to the P-CSCF,
- information identifying the application service provider and application (e.g. SDFs, application identifier, etc.).
The Rx interface also enables the P-CSCF to subscribe to notifications on IP-CAN bearer (e.g. signalling path status of P-CSCF session).
The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PGW. The PCRF PCC/QoS Rule decisions are based on one or more of the following:
- the session and media related information obtained from the P-CSCF via the Rx reference point;
- the bearer and subscriber related information obtained from the PGW (PCEF) over the Gx reference point;
- the bearer and subscriber related information obtained from the SGW (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 defined towards Subscription Profile Repository (SPR);
- pre-configured information in the PCRF.
The PCC/QoS Rules are provisioned by PCRF to the P/SGW via the Gx/Gxx reference point.
Flows
There are many parameters which can affect the actual Rx flow. Please see 3GPP 29.213 for details. Here we’ll go through the most basic flows so that you get the idea.
VoLTE Attach
Although VoLTE attach is not utilizing the Rx interface, it is directly related to it and therefore it is good to have some understanding on how does the ePC allocates the resources.
During the VoLTE attach procedure the MME performs an Update Location UL to the HSS to retrieve the subscriber profile. Additional information includes the IMSI, MME Identity, ME Identity and MME capabilities and support for IMS Voice over PS session. The HSS confirms the UL to the MME with the related IMSI and subscriber data containing a PDN subscription context with a subscribed QoS profile and subscribed Aggregate Maximum Bit Rate APN-AMBR.
The MME initiates a Create Session Bearer CS request to the SGW to create a default bearer for VoLTE IMS signalling. This message contains the IMSI, MSISDN, IMS-APN, QCI=5, ARP value, the APN-AMBR, user location information (e.g. TAI+ECGI), UE Time Zone, RAT-type (EUTRAN), PCO, etc. The SGW creates a new entry in the EPS Bearer table, allocating a relevant TEID for the control plane and the user plane, which enables it to route GTP control plane traffic between the MME and the PGW, and forwards the request to the PGW.
The PGW allocates an IP Address (which can be IPv4 or IPv6) for the UE and utilizes dynamic PCC to initiate a Credit Control Request CCR to the PCRF to obtain the default PCC rules for the default bearer to be used for IMS signalling. Included in the message are the IMSI, UE IP Address, default bearer QoS parameters (i.e. QCI=5, ARP, APN-AMBR), user location information, time zone information, RAT type (EUTRAN), etc.
The PCRF binds the related policy rules to the IP Address of the default bearer, and responds to the PGW with the default Traffic Flow Template TFT and potentially modified QoS parameters. In the message to the PGW, the PCRF also subscribes to modifications related to the default bearer in the PGW (e.g. RELEASE_OF_BEARER, DEFAULT_EPS_BEARER_QOS_CHANGE, etc.).
The PGW creates a new entry in the EPS Bearer table, allocating relevant TEID for the control plane and the user plane, which enables it to route user plane data between the SGW and the IMS network with the related policy rules obtained from the PCRF applied. The PGW sends a CSR to the SGW with the IP Address for the UE, QoS parameters, PCO, relevant TEID’s for the GTP control plane and GTP user plane, etc.
The PGW maps the IMS-APN received in the request to a pre-configured IMS P-CSCF IP address and inserts this into the PCO. The SGW returns the CSR to the MME. At this stage, the VoLTE UE is attached to the network via a default bearer that is established for IMS Signalling.
VoLTE Registration
As per GSMA VoLTE Implementation Guideline the P-CSCF sends an AA-Request AAR message to the PCRF only optionally. The AAR provides the information about the SIP signalling flows established between the UE and the P-CSCF.
As there is no media session yet, the purpose is to create an application binding to the default bearer (meaning the P-CSCF is requesting to be informed in the event of the default bearer being lost/disconnected in order to trigger an IMS de-registration).
The PCRF performs the binding and responds with a AAA message to the P-CSCF. If the PCRF had not previously provisioned PCC/QoS rules corresponding to the received SIP signalling flows, then the PCRF executes provisioning of PCC/QoS rules from P/SGW.
In the roaming scenario, the visited network P-CSCF passes the message to the visited PCRF and onto home PCRF over the S9 interface if implemented. The deployment of the S9 interface is determined on a mutual operator agreement. It is also possible to use static policy control where the local configuration data is stored in the V-PCRF, in which case the S9 interaction does not occur.
If the AAR message is not sent, which is very common, then IMS relies on other mechanisms to detect loss of the underlying default bearer, i.e., loss of connectivity (e.g. timeouts on trying to signal to the UE for an incoming call or the UE registers in the IMS with a new IP address).
VoLTE to VoLTE Call Establishment – Originating Side
During the MO Call Setup the P-CSCF analyses the SDP in the both SDP Offer (SIP INVITE) and SDP Answer (183 Progess) – the uplink and downlink configuration. Based on that information the P-CSCF sends the AAR message to the PCRF with the related service data (IP address, port numbers, information on media-type using either Framed-IP-Address AVP or Framed-Ipv6-Prefix AVP, and the corresponding Service Information within Media-Component-Description AVPs). The P-CSCF indicates to the PCRF whether the media IP flow(s) should be enabled or disabled with the Flow-Status AVP.
The PCRF authorizes the request and associates the service information with the stored subscription related data containing the information about the allowed service(s), QoS information and PCC Rules information. The PCRF identifies the affected IP-CAN session (e.g. default bearer and initiates a Re-Auth-Request RAR to the PGW to initiate the creation of a dedicated bearer for voice with the related QoS parameters (QCI=1, ARP) and the related traffic flow template). The PCRF also subscribes to modifications related to the dedicated bearer in the PGW (e.g. INDICATION_OF_RELEASE_OF_BEARER, etc.). The PGW acknowledges the RAR to the PCRF, which then acknowledges the AAR message sent from the P-CSCF.
At this point the IMS SIP session and the dedicated bearer used for voice are bound together via PCC. The PGW sends the Create Bearer Request CBR to the SGW to create the dedicated bearer for VoLTE media. This message contains the dedicated bearer identity, Linked Bearer Identity to identify the associated default bearer, the traffic flow template, and the associated QoS parameters (QCI=1, ARP, GBR and MBR), etc.
The SGW sends the request to the MME. The MME sends a Bearer Setup Request BSR message to the eNodeB with the dedicated bearer identity, the traffic flow template, and the associated QoS parameters in order to activate the dedicated bearer for voice traffic.
After the P-CSCF receives AAA, it forwards the 183 message to the UE. The session setup continues with SIP PRACK and SIP UPDATE message exchange.
When the called party’s UE has answered the call, it sends a 200 OK to the calling party UE. After the P-CSCF receives the final 200 OK message, it invokes the PCRF with an AAA message to enable both the uplink and downlink of the dedicated bearer. In turn the PCRF triggers the PGW with a RAR message to enable the media flows at the PGW.
Note, that the call flow above shows the PCRF being invoked only once on receipt of the of the SDP answer. This is sufficient if the UE is using preconditions as mandated in GSMA IR.92. It is also possible to invoke the PCRF twice, i.e. on receipt of both the SDP Offer and SDP Answer. Both options are valid, for details see 3GPP TS 29.213.
VoLTE to VoLTE Call Establishment – Terminating Side
On receipt of the SIP 183 Progress message, the P-CSCF updates the IMS-AGW if applicable with the SDP answer from the UE and sends the AAR message to the PCRF with the related updated service information (IP address, port numbers, information on media-type).
As in the originating case, the PCRF authorizes the request and associates the service information to the stored subscription. The PCRF identifies the affected IP-CAN session (e.g. default bearer) and initiates a RAR to the PGW.
The PGW acknowledges the RAR to the PCRF, which then acknowledges the AAR message sent from the P-CSCF.
On receipt of the AAA response from the PCRF, the P-CSCF will convey the SIP 183 Progress (SDP) message to the S-CSCF.
Then with the final 200 OK for the INVITE the P-CSCF invokes the PCRF with an AAA message to enable both the uplink and downlink of the dedicated bearer to reflect the SDP exchange. In turn the PCRF invokes the P-GW with a RAR message to enable the media flows at the P-GW.
As said when we were discussing the originating side, it is also possible to invoke the PCRF twice, i.e. on receipt of both the SDP Offer and SDP Answer.
VoLTE to VoLTE Call Clearing
To clear a voice call the VoLTE UE sends a SIP BYE message to the P-CSCF. The P-CSCF initiates a Session Termination Request STR to the PCRF to trigger the process of removing the dedicated bearer that was established for the voice media.
The PCRF removes the binding between the stored subscription information and the IMS service data, and initiates RAR to the PGW to remove the dedicated bearer for voice with the related QoS parameters (QCI=1, ARP) and the related traffic flow template.
The Delete Bearer Request DBR, Bearer Release Request BRR, and Reconfiguration Request RRC are utilized to remove the dedicated bearer used for voice traffic.
Then the P-CSCF forwards the SIP BYE message to the S-CSCF. The other party acknowledges the SIP BYE with a 200 OK. At this stage, the VoLTE UE has cleared the call and the dedicated bearer for voice traffic has been removed.
VoLTE Session Modification
The P-CSCF receives the SDP parameters from both SDP Offer and Answer. It identifies the relevant changes in the SDP and sends a AAR for an existing Diameter session and includes the derived updated service information.
The PCRF stores the received updated session information and identifies the affected established IP-CAN Session(s). The PCRF sends RAR to PGW with the new configuration. Due to the updated service information, this step may imply provisioning of PCC/QoS rules or the need to enable or disable IP Flows. The PCRF answers back to P-CSCF with AAA.
If the P-CSCF requested access network information, the PCRF forwards to P-CSCF the access network information received in RAA from PGW. Then also the SDP answer contains the access network information.
VoLTE UE Initiated Detach and IMS Deregistration
In case the P-CSCF requested notifications for default bearer during the Registration procedure (only optional), with de-Deregistration message it sends Session Termination Request STR to PCRF.
The actual release of the default bearer is then triggered by VoLTE Detach Request.
The VoLTE UE initiates a Detach Request to the MME, via the eNodeB. The MME initiates a Delete Session Request DSReq to the SGW, to deactivate the default bearer. The SGW releases the default bearer context information and sends the Delete Session Response DSResp to the MME.
The SGW initiates a Delete Session Request DSReq to the PGW. The PGW acknowledges with the Delete Session Response to the SGW.
The PGW initiates a Credit Control Request CCR to the PCRF to indicate that the default bearer is released. The user location information (i.e. ECGI) and the Time Zone information are included. The MME utilises the Release Access Bearer Request RABReq to release the connection between the SGW and the eNodeB.
The Detach Accept is sent by the MME, and the radio resources between the UE and the eNodeB are removed. At this stage, the VoLTE UE is not attached to the network and the default bearer that was
established for IMS Signalling is removed.
As mentioned this is not a full list of the supported flows. The aim of this article was to outline the basic communication scheme of Rx protocol.
For more details see:
3GPP TS 23.125 – Overall high level functionality and architecture impacts of flow based charging – v 6
3GPP TS 29.211 – Rx Interface and Rx/Gx signalling flows – v 6
3GPP TS 29.212 – Policy and Charging Control (PCC); Reference points
3GPP TS 29.213 – Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping
3GPP TS 29.214 – Policy and charging control over Rx reference point
3GPP TS 29.201 – Representational State Transfer (REST) reference point between Application Function (AF) and Protocol Converter (PC) – 5G
GSMA FCM.01 – VoLTE Service Description and Implementation Guidelines
Real Time Communication 