Bearer level event and VoLTE call setup failure

The application layer needs to be aware of bearer level status as the EPS bearer is tightly coupled with the application session and some events in an EPS bearer can affect the application session handling and resource management. For instance, when the VoLTE call session is about to be established, the IMS core establishes the logical connection with the UE. Meanwhile, the EPS will prepare for the EPS bearer through which signaling and payload will flow. If the EPS bearer is disconnected somehow (e.g., due to connection loss, user inactivity), the IMS core needs to be informed of it so the corresponding application session shall be handled accordingly. The PCC architecture handles the binding relations between the application session, PCC rules and the EPS bearers as is described in "Bearer binding and Session binding".

The following diagram shows the Policy and Charging Control (PCC) architecture that controls the EPS bearer related QoS policies and is used to request the bearer level event reporting and deliver the bearer events to application layer.

Fig 1. PCC architecture

[1] Upon receiving the request for voice call (i.e., SIP INVITE), the P-CSCF triggers the Authentication-and-Authorization Request (AAR) towards the PCRF containing the service information like source/destination ip addresses and ports, codec information, etc. The AAR also accommodates the list of events that the P-CSCF wants to be informed of.

[2-3] The PCRF generates the PCC rule for this application session and sends Re-Authorization Request (RAR) which contains the PCC rules.

[4] The EPC binds the received PCC rules and the EPS bearers so it can map the IP flow to the corresponding EPS bearer.

[5] When there is an event occurred that corresponds one of events listed in the received parameters, the P-GW reports the event to the PCRF by sending the Credit-Control Request (CCR) towards the PCRF.

[6] The PCRF unbinds the AF session from the IP-CAN and sends the Re-Authentication Request (RAR) or the Abort-Session Request (ASR) to the P-CSCF reporting the occurred event. Upon receiving the RAR or ASR, the P-CSCF may release or update the application session by sending appropriate error response to end points.

NOTE Refer to procedures described in "Voice Call Setup" and "dedicated EPS bearer creation" for the detail.

The following flow shows the voice call setup procedure where the voice session is about to establish but fails due to the error event occurred in the EPS bearer.

NOTE The step #1 to step #8 follows the normal procedure for VoLTE call setup as described in "dedicated EPS bearer creation".

[1-2] While VoLTE call setup procedure, the P-CSCF receives the SIP INVITE and 183 Session In Progress with SDP offer and SDP answer, respectively.

[3] The P-CSCF triggers the binding procedure by sending AAR towards the PCRF. The AAR includes the list of events that it wants to be informed of.

[4-6] The PCRF sends the PCC rule to the SGW/PGW so it can enforce the rule for the incoming IP flow. The SGW/PGW binds the received PCC rules with an EPS bearer and responds with the RAA towards the PCRF and in turn, the PCRF responds with the AAA towards the P-CSCF.

[7-8] The SGW/PGW initiates the EPS bearer creation procedure by sending the Create Bearer Request towards the MME. The MME request to activate the EPS bearer by sending Activate EPS bearer context request towards the eNB. The E-RAB Setup request over S1AP interface which delivers the NAS message to the eNB includes the list of E-RAB to be setup.

[9] Upon receiving the AAA from the PCRF, the P-CSCF proceeds the call setup procedure by sending the 183 Session In Progress which contains the SDP answer.

[10] In this example, the eNB responds with the error response with its cause value set to "multiple-E-RAB-ID-instances" which is the case when the eNB receives the same E-RAB ID as the one that already does exist.

Skimming over the trace history on S1AP interface, there was an attempt to delete the E-RAB but failed due to a problem in a radio interface, which is followed by X2 handover several times. It is suspected that the MME might have deleted the E-RAB ID anyway without considering the failure response and later on, re-assigned the same value for E-RAB in the E-RAB Setup Request while the eNB is still maintaining the value as the E-RAB release procedure has failed.

[11] The MME rejects the request for bearer creation by sending the Create Bearer Response to the SGW/PGW with its cause value set to "No resource available".

[12] The MME also initiates the E-RAB release procedure for the concerned E-RAB ID.

[13] Meanwhile, the SGW/PGW may internally revoke the bearer binding and informs the bearer event to the PCRF by sending CCR with its Charging-Rule-Report AVP set to RESOURCE_ALLOCATION_FAILURE.

[14] The PCRF informs the P_CSCF of the received bearer event by sending ASR with its Abort-cause AVP set to BEARER_RELEASED in this example. The ASR is sent when all the service data flows regarding the AF session are deleted. Otherwise, the PCRF would send RAR.

[15-16] The P-CSCF responds with the ASA and the PCRF with CCA.

[17, 21] Upon receiving the event report indicating the bearer release, the P-CSCF abort the call processing by sending the 503 Service Unavailable. The UE responds with the SIP ACK and releases all the resources regarding this application session.

[18-19] The P-CSCF sends the Session-Termination-Request towards the PCRF indicating that the application session has been terminated.

[20] The eNB responds to the E-RAB Release Command by sending the E-RAB Release Response towards the MME.

Red Mouse

REFERENCES

[1] 3GPP TS 29.213, "Policy and Charging Control signalling flows and Quality of Services (QoS) parameter mapping", v12.3.0, Mar 2014
[2] 3GPP TS 29.214, "Policy and Charging Control over Rx reference point", v13.2.0, June 2015
[3] TS 36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v13.0.0, June 2015

VoLTE: Bearer binding and Session binding

The LTE supports the PCC(Policy and Charging Control) architecture for QoS control applied to service data flow. In the PCC architecture, the PCRF(Policy and Charging Rules Function) takes the role of a central network component interacting with P-CSCF, SPR(Subscription Profile Repository) and the EPC. The PCRF is always involved in the activities of EPS bearer creation by generating the PCC(Policy and Charging Control) rules and provisioning them to PDN GW(i.e., PCEF). In order to generate PCC rules, the PCRF needs to gather service data flow information from the P-CSCF and possibly the subscription information from the SPR. As the PCC rule shall be applied from the access network to the EPC core with consistency, the PCRF needs to be able to maintain the relations of different sessions over different interfaces across the IP-CAN, EPS bearer and applications, in which the binding mechanism becomes a basic concept.

NOTE In this article, it is assumed that the S5 between the SGW(Serving GW) and PGW(PDN GW) is using GTP, where the PGW becomes the end point of the GTP tunnel.


I. Session binding

The session binding is an association of the AF session information to one and only one IP-CAN session [TS23.203]. Th AF(Application Focus) session is defined as a service level session such as IMS service session that is established by the application level signaling protocol offered by the AF that requires a session-setup with explicit session description before the use of the service[TS29.214].

The IP-CAN session information is obtained by the PCRF during the UE initial attach procedure.
When the UE performs the initial attach to the LTE network, the PGW triggers the CCR-I towards the PCRF. The CCR-I contains the IP-CAN related AVPs such as Framed-IP-Address, IP-CAN-Type, RAT-Type, Called-Station-Id, AN-GW-Address. The following is an example of CCR-I captured over Gx.

• Framed-IP-Address: The valid routable IPv4 address that is applicable for the IP Flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP-CAN session binding[TS29.214].
• Freamed-IPv6-Prefix: A valid full IPv6 address that is applicable to an IP flow or IP flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP-CAN session binding[RFC4005,RFC3162].
• IP-CAN-Type: Type of Connectivity Access Network in which the user is connected[TS29.212]. 
• RAT-Type: The Radio Access Technology that is currently serving the UE[TS29.212].
• Called-Station-Id: APN [TS29.212].

The service data flow information is obtained while the service session is set up. Upon UE request for VoLTE call setup, the SIP INVITE is delivered to the P-CSCF(i.e., AF) with an SDP offer. The SDP offer includes media session information such as 5-tuples(source ip address, destination ip address, source port, destination port and protocol), codec information, etc. Upon receiving the SIP INVITE, the P-CSCF interprets the received SDP contents into diameter AVPs and triggers the AAR towards the PCRF. The following shows an example of SDP contents included in the SIP INVITE.

NOTE It would be possible for the P-CSCF to trigger AAR once when the 183 Session In Progress is received(SDP answer) in order to reduce diameter traffic.

The following is an example of diameter AAR over Rx which includes the service data flow information.

• Media-Sub-Component: contains the requested bitrate and filters for the set of IP flows identified by their common Flow-Identifier[TS29.212].
• Flow-Description: defines a packet filter for an IP flow with the following information[TS29.212].
• Flow-Status: describes whether the IP flow(s) are enabled or disabled[TS29.214].
• Max-Requested-Bandwidth-UL/DL: Indicates the maximum requested bandwidth in bits per second for an uplink/downlink IP flow[TS29.214].
• RS-Bandwidth: indicates the maximum required bandwidth in bits per second for RTCP sender reports within the session component[TS29.214].
• Codec-Data: contain codec related information known at the AF[TS29.214].

Upon receiving the AAR, the PCRF binds the service data flow information received from the P-CSCF to a specific IP-CAN session received from the PGW.


II. Bearer Binding

The bearer binding is the association of the PCC rule and the QoS rule (if applicable) to an IP-CAN bearer within that IP-CAN[TS23.203]. Upon user's request for voice call, the SIP signals will flow through the EPS bearer of QCI=5 and there will be additional EPS bearer newly established to transfer voice traffic. In the same way as described in the previous section, the PCC rules are generated and provisioned to the PGW by the PCRF. The PGW enforces PCC rules accordingly by performing gating control over service data flow.

The PCC rule contains various parameters that can be used to control service data flow such as Flow-Information, Flow-Status, QoS, etc. The following snapshot shows an example of PCC rule contained in the diameter RAR over Gx for voice traffic.

Upon receiving the RAR, the PGW triggers the EPS bearer creation procedure by sending the Create Bearer Request to the MME. The Create Bearer Request contains the TEID for GTP-U created by the PGW and QoS parameters(QCI, MBR, GMBR) as well. In return, the corresponding response from the MME, Create Bearer Response, contains the allocated EBI(EPS Bearer ID) and the TEID for GTP-U created by the eNB. As an end point of the GTP Tunnel, the PGW shall maintain the relations between EPS bearers and PCC rules. The following is an example of Create Bearer Response captured over GTPv2.

***

The session binding and the bearer binding are basic concepts to understand how different type of sessions are related with each other over different interfaces within the PCC architecture. The IP-CAN session to which the UE is attached is bound with the AF session by the PCRF and the service data flow for that AF session is used to generate the PCC rules. These PCC rules are used to map the specific service data flow to a certain EPS bearer which belongs to that IP-CAN session.

Thanks to this binding relations, one event at one place makes a ripple effect to the other, thereby the LTE core can maintain the consistent status for the same UE. If the UE releases an AF session, the corresponding PCC rules for the service data flow belonging to that AF session are removed and in turn, the EPS bearer for that PCC rules will also be released. If the UE detaches from the network, the IP-CAN session will be released and in turn, all the AF session and EPS bearers belonging to the same IP-CAN will also be released.

Red Mouse