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