VoLTE: E-RAB management vs Handover

The 3GPP TS36.413 addresses the racing condition between UE handover and the E-RAB management procedures. The UE handover occurs based on the measurement parameters sent by the UE whereas the EPS bearer creation as a part of VoLTE call setup procedure in general. When these two independent events occur at the same time, there can be a collision at eNB, as the eNB is involved in both procedures. In this collision state, the eNB has two options to take as follows:


I. Terminating the E-RAB Setup and continues the UE S1 handover

The following flow shows the eNB rejecting the E-RAB setup request and continues the handover procedure. Upon receiving the rejection to the E-RAB setup request with its cause id, e.g., "S1 intra system Handover Triggered", the MME continues the S1 handover procedure. In the meantime, the Create Bearer Request can be postponed temporarily until the handover is completed. If the Serving GW or MME is to be changed, the Create Bearer Request will be rejected with its cause id set to "Temporarily rejected due to handover" and the P-GW may retry the EPS bearer creation procedure after the S1 handover is completed(refer to http://bit.ly/1H4Z7yr for the detail).

II. Cancelling the UE handover and continues E-RAB Setup

The following shows the eNB cancels the S1 handover towards the MME and continues the EPS bearer creation procedure. Upon receiving the Handover Cancel, the MME terminates ongoing Handover Preparation procedure and release any resources associated with the handover preparation. If the eNB does not receive the Handover Cancel Ack, it is assumed that the handover is terminated successfully.

The following shows the eNB cancels the X2 handover to continue the EPS bearer creation procedure according to 3GPP TS36.423. Upon receiving the Handover Cancel, the target eNB releases any resources reserved for the concerned UE context.

III. Service impact
The eNB shall be able to handle the racing condition between two independent events(i.e., E-RAB setup request and handover) either by cancelling the handover or by rejecting the E-RAB setup request. The MME also needs to be able to handle the racing condition either by rejecting the bearer related requests with a corresponding reason (e.g., Temporarily rejected due to handover) or by possibly providing pause-and-resume mechanism itself for bearer related requests in case the handover is in progress. If the bearer related request is rejected, the PGW may realize the retry mechanism(refer to http://bit.ly/1H4Z7yr for the detail). If this type of racing condition is not handled appropriately, there could be frequent call drops or call setup failures based on eNB optimization status resulting in bad user experiences of VoLTE user.


Red Mouse

VoLTE: Understanding of GTP TEID to use in LTE trouble shooting

The GTP(GPRS Tunneling Protocol) is a communication protocol used by the LTE to deliver IP packets within the EPC. The GTP-C is used to deliver the controlling signals over S11 and S5, whereas the GTP-U is used to deliver application payload over S1 and S5. 

I. TEID exchanges

The TEID(Tunnel Endpoint IDentifier) is generated by each node during the initial attach procedure. The Create Session Request includes the S11 MME DL TEID and the S5 SGW DL TEID, which are generated and included by MME and Serving GW respectively. The Create Session Response includes the S5 PGW UL TEID and the S11 SGW UL TEID, which are generated and included by PGW and Serving GW respectively.

The following diagram shows the actual call flow and depicts how the TEID is exchanged between NEs. Upon receiving the Create Session Request, the Serving GW establishes the downlink GTP-C tunnel towards the MME using the received S11 MME DL TEID. In the same way the MME establishes the uplink GTP-C tunnel towards the Serving GW using the received S11 SGW UL TEID. The TEID for GTP-U is included in the body of bearer related messages (e.g., Create Bearer Request/Response, Modify Bearer Request/Response). 

The newly generated TEID is included in the body of each sending message and delivered to the peer node. The peer node perceives the end point of the GTP based on the received TEID. When the message goes through the existing GTP tunnel, the TEID of the peer node will be included in the GTP header of the sending message. The following example shows the TEID included in the Create Session Request being sent from the MME towards the Serving GW. 

In the mean time, the following example shows the TEID included in Create Session Response, where the TEID received from the MME is used in the header and the newly generated TEID of Serving GW is included in the body.

II. TEID lifetime

The life time of the GTP-C session lasts along with the life time of the UE's IP-CAN connection. It starts when the UE attaches to network and ends when the UE detaches from the network. In case there are multiple PDNs , there is only one GTP-C session per UE. The following example shows the lifetime of the same GTP-C session, which is defined by same TEIDs. In this example, there are two Create Session Requests, each for different PDNs. Each Create Session Response is followed by the Modify Bearer Request for establishing default EPS bearers. Lastly, the Create Bearer Request is to establish dedicated EPS bearers.

The lifetime of the GTP-U depends on the attributes of the EPS bearer. The GTP-U connection associated with the default EPS bearer has the same lifetime of that of GTP-C connection, whereas the GTP-U connection associated with the dedicated EPS bearer will be dynamically created and deleted within the lifetime of IP-CAN connection.

III. TEID usage

When there are multiple EPS bearers established for the same APN and there needs to verify if  specific service data flow goes through the right EPS bearer, the TEID can be a useful tool to figure it out. The following example shows the GTP-U packet of the SIP REGISTER being sent from the UE towards the IMS Core. The TEID in the GTP header indicates "0x005b8422".

The following shows the same TEID appears in the body of a Modify Bearer Request. This Modify Bearer Request is for the EPS bearer of QCI=5.

Red Mouse

VoLTE: QCI=1 setup failure when S1 handover is in progress

In a mobile environment, by its nature, the handover may occur while the user is engaged in a VoLTE call session. The UE periodically reports measurements of various parameters to the eNB and the eNB determines whether the handover is required. Once it is determined by the eNB to trigger the handover, the eNB will decide whether to perform X2 handover or the S1 handover. When there is an existing X2AP connection towards the target eNB, the source eNB performs X2 handover. If there is no X2AP connection or the X2 handover attempt has failed for some reasons, the source eNB may trigger the S1 handover.

As to the PGW initiated bearer related requests(e.g., Create/Update/Delete Bearer request) there is no cause-id defined in the 3GPP TS29.274(r8),  Therefore, in this case, the MME may reject the request with the cause-id of reason unspecified. This cause-id will lead to the ripple effect towards the upstream forcing each node on the path to release the corresponding resources. This is shown in the following flow diagram.

Even though the handover is successful in this flow, the error cause of RESOURCE ALLOCATION FAILURE in the CCR over Gx will lead to the PCRF to send RAR(Re-Authentication Request) or ASR(Abort-Session-Request) over Rx with a cause-id of RESOURCE NOT AVAILABLE, and the process will end up with sending the 503 Service Unavailable by the P-CSCF. Upon receiving the 503 Service Unavailable, the UE releases all the resources for the call.

In a circumstance where the eNB is not optimized, the handover might occur relatively often. If this racing condition is not handled properly, the result will lead to bad user experiences for VoLTE as the rejection of the bearer related request may often lead to the VoLTE setup failure for QCI=1 bearer for voice.

In the 3GPP TS29.274(r9), the 3GPP has specified the proper cause value of "Temporarily rejected due to handover in progress" and in the 3GPP TS29.274(r11), "Temporarily rejected due to handover/TAU/RAU procedure in progress". This cause-id value is used by the MME rejecting the bearer related request when the handover results in the relocation of the Serving GW and/or MME. The PDN GW which initiated the bearer related request will be able to consider this error cause value to handle the rejection. 

The following flow shows one example of how to handle the rejected bearer related request. In this flow, the Create Bearer Request is rejected by the MME. The PDN GW may retry the Create Bearer Request based on the operator's policy. 

If there is no need of relocation of MME and/or Serving GW, the MME does not need to respond with the cause-id, rather it can perform store-and-forward way of message handling. In this case, the MME will temporarily store the message and wait for the handover to be completed and if it's done soon enough, the Create Bearer Request can be sent to the UE via the target eNB. How 'soon' is the 'soon enough' time is usually up to the operator's policy.

Red Mouse