VoLTE S1 handover execution (2/3)

S1 handover preparation procedure includes the decision of S1 handover by the source eNB, allocation of network resources to establish Indirect Data Forwarding Tunnel among two eNBs and common S-GW and establishment of uplink S1 bearer from the target eNB to the S-GW. Once the S1 handover preparation procedure is completed, the MME initiates the S1 handover by sending Handover Command to the UE via the source eNB. The UE executes the handover by detaching from the source eNB and attaching to the target eNB. Meanwhile, the downlink data is forwarded to the target eNB and buffered while the UE handover is in progress. Lastly, the UE informs the target eNB of the fact that the handover has been successfully completed and thereafter, the buffered data and downlink data is forwarded the UE through the target eNB. 

Figure 1. S1 handover procedure - execution

[8] The Handover Command received from the MME is wrapped by the source eNB within the RRC Connection Reconfiguration and sent to the UE. The RRC Connection Reconfiguration is the message to perform logical, transport and physical channel configurations. In this case, it is used to send NAS signaling to the UE to reduce the latency. Upon receiving the Handover Command, the UE detaches from the source eNB and performs handover to the target eNB.

[9] The source eNB stops assigning PDCP-SNs to downlink packets and sends the eNB Status Transfer to the target eNB via MME that contains uplink and downlink PDCP-SN and HFN (Hyper Frame Number) for each respective E-RAB. This procedure is initiated by the source eNB at the moment when it considers the transmitter/receiver status to be frozen. The use of PDCP-SN and HFN is part of overflow control mechanism for radio. The PDCP-SN is the serial number of PDCP packets increasing up to MAX-PDCN-SN. If the number reaches the MAX-PDCP-SN, the HFN is incremented by one. 

• Subject to Transfer Items: contains uplink/downlink PDCP-SN and HFN for each respective E-RAB.
• E-RAB ID: Identifies a radio access bearer for a particular UE. This value remains the same after S1-handover.
• uL-/dL-Count value: contains the PDCP-SN and HFN values
• Received Status of UL PDCP SDUs: indicates the missing and the received uplink SDUs (Service Data Units) for each bearer for which the source eNB has accepted the request from the target eNB for uplink forwarding.

  

Figure 2. eNB Status Transfer

[10] The MME forwards the received PDCP-SN and HFN information to the target eNB by sending MME Status Transfer. Upon receiving the MME Status Transfer, the target eNB does not deliver any uplink packet whose PDCP-SN is lower than the value received in the PDCP-SN in the uL-COUNT value. The target eNB uses the received PDCP-SN in the dL-COUNT value for the first downlink packet for which no PDCP-SN is assigned yet. The downlink traffic received by the source eNB is routed to the target eNB following the Indirect Data Forwarding Tunnel.

[11] After the UE successfully synchronized with the target cell, it sends a Handover Confirm to the target eNB. The Handover Confirm is contained in the RRC Connection Reconfiguration Complete message on RRC. Please note that, at this moment, there is no direct S1 bearer established yet between S-GW and the target eNB. Therefore, the downlink data is sent to the source eNB and forwarded to the target eNB following the Indirect Data Forwarding Tunnel. The uplink data from the UE will be forwarded to the S-GW following the direct S1 interface.

Red Mouse

REFERENCES

[1] 3GPP TS25.331, "Radio Resource Network (RRC); Protocol specification", v12.3.0, Sep 2014

[2] 3GPP TS23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, v12.4.0, Mar 2014

[3] 3GPP TS36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", v12.3.0, Sep 2009

[4] Blog, “How LTE Stuff Works?: RRC Connection Reconfiguration”, Oct 2011

VoLTE S1 Handover preparation (1/3)

While UE crosses the border towards the neighborhood cell, the source eNB determines whether there needs a handover based on the received measurement report from the UE. When there is no established X2 connection with the target eNB, the source eNB determines to perform S1 handover. In this post, the handover preparation phase will be addressed. The handover preparation procedure includes the determination of handover by the eNB, handover request by the MME, the allocation of required resources and establishing the indirect data forwarding tunnels among NEs.

I. Indirect Data Forwarding Tunnel

S1 handover is different from the X2 handover in that the media is anchored by the SGW under the control of MME rather than by eNB. During the S1 handover, a temporary indirect data forwarding tunnel is established between two eNBs via the common SGW. All the media arriving at the source eNB while S1 handover is in progress, which can be uplink data from UE side or the downlink data from the network side, will be re-directed to the target eNB through this indirect data forwarding tunnel and buffered at the target eNB. When the S1 handover is completed, the buffered media at the target eNB is transferred to the UE. The following diagram shows Indirect Data Forwarding Tunnel established between the source eNB and target eNB anchored by the common SGW during S1 handover procedure.

Figure 1. Indirect Data Forwarding Tunnel in S1 handover

II. S1 handover preparation

As a precondition of this practice, the UE has PDN connections with the internet APN and IMS APN and there are three EPS bearers established in total with EPS bearer ID of ‘5’, ‘6’ and ‘7’ and the relocation of SGW/PGW does not occur. The S1 handover procedure is triggered by the source eNB. The MME controls establishing the Indirect Data Forwarding Tunnel by intermediating required data between two eNBs like Bearer Context. The Bearer Context contains EPS bearer ID and their GTP-U TEIDs corresponding to each EPS bearers. The SGW anchors the media transfer between source eNB and the target eNB. As the SGW and two eNBs are involved in the media control, they allocate the required media resources, generate their own GTP-U TEIDs and establishes S1 bearer and indirect data forwarding tunnels based on the GTP-U TEID of the peer node delivered via MME.

Figure 2. S1 handover procedure - preparation

[1] The UE periodically sends a measurement report to the serving eNB. This reporting mechanism is intended for the UE to find out the best cell to communicate with the network. The measurement report may contain the list of neighbor cells, signal strength, current condition, etc.

[2] Based on the received report, the serving eNB determines whether the handover is required and if it is required, the serving eNB selects a target eNB among the list of neighbor eNBs. If there is no X2 connection with the target eNB, the source eNB performs S1 handover and sends Handover Required to the serving MME requesting to prepare for resources at the target. 

•  MME UE S1AP ID: Unique identifier of the UE association over the S1 within the MME
• eNB UE S1AP ID: Unique identifier of the UE association over the S1 within the eNB
• Handover Type: The type of triggered handover in the source side (i.e., intraLTE, LTEtoUTRAN, LTEtoGERAN, UTRANtoLTE, GERANtoLTE)
• Cause: A reason for a particular event for the S1AP. In this practice, the value “Handover Desirable for Radio Reasons” indicates that the cause is related with radio. Refer to section 9.2.1.3 Cause of [TS36.413] for the detail.
• Target ID: The target eNB for the handover. It is composed of “Global eNB ID” and “selected TAI”. The Global eNB ID is composed of PLMN ID (MCC+MNC) and macro eNB-ID identifying the specific eNB of a certain operator in a certain country. The selected TAI uniquely identifies the target Tracking Area i.e., PLMN ID + TAC, identifying a specific tracking area that is served by that eNB.
• Source to Target Transparent Container: Information elements created by the source eNB and transmitted to the target eNB, which contains the RRC related information, E-RAB information, Target Cell-ID and UE History Information as shown in the following bullets.
• RRC Container: RRC Information used by the target eNB during handover preparation including UE capability information. Refer to “HandoverPreparationInformation” in section 10.2.2 “Message definitions” of TS36.331 for the detail.
• e-RABInformationList: The list of eRAB to be handed over. The E-RAB ID identifies a radio access bearer for a particular UE, which makes the E-RAB ID unique over one S1 connection. The “dL-Forwarding-proposed” indicates that the source eNB proposes the list of E-RABs for forwarding of data. In this practice, there are three E-RABs (i.e., E-RAB ID=’5’,’6’ and ‘7’) proposed and they actually represent existing E-RABs of the source eNB. If the target eNB accepts it in the Handover Request Acknowledge, the downlink data received by the source eNB during the handover will be forwarded to the target eNB through the indirect data forwarding tunnel.
• Target Cell ID: Globally unique cell identifier. It is composed of PLMN ID and Cell ID.
• UE-HistoryInformation: The list of cells that a UE has been served by in the active state prior to the target cell.

Figure 3. Handover Required

[3] the MME initiates the procedure by sending the Handover Request to the target eNB requesting to prepare for resources for handover.

•  MME UE S1AP ID: refer to step#2.
• Handover Type: refer to step#2.
• Cause: refer to step#2.
• UE-AMBR: Aggregated maximum bit rates per UE being applicable for Non-GBR bearers.
• E-RAB to be SetupList: A list of E-RAB to be setup where each item contains E-RAB ID, Transport Layer Address, GTP-TEID and E-RAB level QoS parameters as addressed in the following bullets.
• E-RAB ID: Refer to step#2
• The Transport Layer Address : IP address of the source eNB.
• The GTP-TEID : The GTP Tunnel Endpoint Identifier of the SGW towards the source eNB. This has been known to the MME during the initial attach of the UE and used by the source eNB to maintain the S1 bearer with the SGW. Now, the MME intends to take this to the target eNB to replace the existing S1 bearer in the end.
• E-RAB Level QoS Parameters indicates the QoS to be applied to the corresponding E-RAB. It is composed of QCI and ARP. Refer to the section 9.2.1.60 “Allocation of Retention Priority” in TS36.413 for the detail.
• Source to Target Transparent Container: Information elements created by the source eNB and transmitted to the target eNB. Refer to step#2.
• UESecurityCapabilities: Supported algorithms for encryption and integrity protection in the UE.
• HandoverRestrictionList: Roaming or access restrictions for subsequent mobility action for which the eNB provides information about the target of the mobility action towards the UE.
• SecurityContext: Security related parameters to the eNB which are used to derive security keys for user plane traffic and RRC signaling messages and to generate security parameters for the current S1 handover. 

Figure 4. Handover Request

[4] The target eNB allocates all the necessary resources for the admitted E-RABs and establishes uplink S1 bearer with the SGW. The target eNB creates its own GTP TEID for S1 bearers which will be delivered to the SGW later and used by the SGW to establish the downlink S1 bearer (SGWàtarget eNB), thereby replaces that the source eNB. The uplink and downlink GTP-TEID for each admitted E-RABs are also included. These DL/UL GTP-TEIDs are used for indirect media transfer. The target eNB responds with the Handover Request Acknowledge to the MME.

• MME UE S1AP ID: refer to step#2.
• eNB UE S1AP ID: refer to step#2.
• E-RAB Admitted List: The list of E-RAB for which the target eNB admitted to establish. This is composed of E-RAB ID, GTP-TEID, UL/DL GTP-TEIDs and the Transport Layer for each Admitted Item as addressed in the following bullets.
• E-RAB ID : Refer to step#2.
• GTP-TEID indicates GTP Tunneling Endpoint Identifier of the target eNB which will replace the corresponding GTP-TEID of the source eNB in the end (i.e., downlink S1 bearer).
• The DL/UL GTP-TEIDs indicate the Tunneling Endpoint Identifiers of the target eNB for Indirect Data Forwarding Tunnels. The following diagram shows the GTP TEID for indirect data forwarding dedicated for one E-RAB.
•  Target to Source Transparent Container: Information element that is used to transparently pass radio related information from the handover target to the handover source through the MME. The Handover Command is transparently delivered to the source eNB.

  

Figure 5. Handover Request Acknowledge

[5] Upon receiving the Handover Request Acknowledge, the MME sends the Create Indirect Data Forwarding Tunnel Request to the SGW, which contains the Bearer Context for each bearer which was received at step #4 from the target eNB. The Bearer Context represents the attributes of each bearer including bearer identifier and TEIDs as below:

• EPS Bearer ID : Identifier of EPS bearer to be established.
• eNB F-TEID for DL data forwarding: GTP Tunneling Endpoint Identifier created by the target eNB for downlink data forwarding. Refer to step#4 
• eNB F-TEID for UL data forwarding: GTP Tunneling Endpoint Identifier created by the target eNB for uplink data forwarding. Refer to step#4 

  

Figure 6. Create Indirect Data Forwarding Tunnel Request

[6] Upon receiving the Create Indirect Data Forwarding Tunnel Request, the SGW establishes the Indirect Data Forwarding Tunnel towards the target eNB using the received DL/UL eNB F-TEIDs. The SGW allocates its own UL/DL F-TEID for indirect data forwarding tunnel, which is delivered to the source eNB via MME at step #7. The SGW responds to the MME with the Create Indirect Data Forwarding Tunnel Response which contains the Bearer Context of the SGW.

• Cause : Indicates if the Indirect Data Forwarding Tunnel has been created in the SGW. Refer to section 7.2.19 “Create Indirect Data Forwarding Tunnel Response” of TS29.274 for the detail.
• EPS Bearer ID : refer to step #5.
• SGW F-TEID for DL data forwarding: GTP Tunneling Endpoint Identifier created by the SGW for downlink data forwarding.
• SGW F-TEID for UL data forwarding: GTP Tunneling Endpoint Identifier created by the SGW for uplink data forwarding.

  

Figure 7. Create Indirect Data Forwarding Tunnel Response

[7] The MME sends the Handover Command to the source eNB informing that resources for handover has been prepared at the target eNB. Upon receiving the Handover Command, the source eNB establishes Indirect Data Forwarding Tunnel towards the SGW using the received E-RAB Subject to Data Forwarding List, i.e., DL/UL GTP-TEIDs for each E-RAB.

• MME UE S1AP ID: refer to step#2.
• eNB UE S1AP ID: refer to step#2.
• Handover Type: refer to step#2.
• E-RAB Subject to Data Forwarding List : The list of E-RAB items to be used for indirect data forwarding. Each E-RAB Data Forwarding Item identifies the E-RAB context of each E-RAB and it consists of E-RAB ID, DL/UL GTP-TEIDs as addressed below.
• E-RAB ID: Refer to step #2.
• DL/UL GTP-TEIDs : Tunneling End Point Identifier of the SGW created and delivered at step #6 for the Indirect Data Forwarding Tunnel.
• Target To Source Transparent Container: Radio related information transparently delivered to the source eNB through the MME. It was created by the target eNB and sent to the MME at step #4.

Figure 8. Handover Command

Red Mouse

REFERENCES

[1] 3GPP TS25.331, "Radio Resource Network (RRC); Protocol specification", v12.3.0, Sep 2014

[2] 3GPP TS24.301, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage3", v12.4.0, Mar 2014

[3] 3GPP TS24.008, "Mobile radio interface Layer 3 specification; Core network protocols; Stage3", v13.4.0, Dec 2015

[4] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS); Tunneling Protocol for Control Plane (GTPv2-C); Stage3", v13.0.0, Dec 2014

[5] 3GPP TS36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", v12.3.0, Sep 2009

[6] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v12.3.0, Sep 2014

X2 handover

Handover is a process for a UE to transfer its sessions from the current network to another one while it is moving towards a neighbor cell. So, the handover procedure ends up with a new connection between the UE and the new eNB. The intra E-UTRAN handover indicates the case where the SGW and/or MME is not relocated whereas the inter E-UTRAN handover is the case where the SGW and/or MME shall be relocated. In this post, the intra E-UTRAN will be described.

It is a serving eNB that determines whether to initiate the handover procedure or not based on measurement reports received from the UE periodically. When handover is to happen, the serving eNB also chooses the target eNB from the list of neighbor eNBs and the type of handover, i.e., X2 handover or S1 handover. If there is an established X2 connection with the target eNB and it is available at the moment, the source eNB performs X2 handover. Otherwise the eNB will perform the S1 handover.

I. Overall scenario

The X2 handover procedure involves signaling transactions among two eNBs and the MME. The following diagram shows the conceptual flow of X2 handover procedure.

Fig 1. overall scenario - X2 handover

(1) UE periodically sends measurement reports to the source eNB.
(2) The source eNB determines X2 handover and requests X2 handover to the target eNB. The target eNB establishes uplink S1 bearer with the same SGW with which the source eNB has been connected. The source eNB establishes a direct tunnel with the target eNB.
(3) UE handover is successfully performed. Hencefortjh, the buffered media is transferred to the UE from the target eNB.
(4) The target eNB informs the SGW of the fact that the handover has been completed successfully. The SGW establishes downlink S1 bearer with the target eNB.
(6) The SGW switches the media path from the source eNB to the target eNB and releases the old S1 bearer.

II. X2 handover flow

Fig 2. X2 handover call flow

[1] The UE periodically sends a measurement report to the serving eNB. This reporting mechanism is intended for the UE to find out the best cell to communicate with the network. The measurement report may contain the list of neighbor cells, their signal strength and its current condition.

[2] Based on the received report, the serving eNB determines whether the handover is required and if it is required, the serving eNB selects a target eNB among the list of neighbor eNBs with which X2 connection is established. The source eNB requests the target eNB to prepare for handover by sending Handover Request. The message contains the target Cell ID and the UE Context. The following shows some of parameters included in the UE Context.

• UE-AMBR indicates aggregated maximum bit rate for all the bearers of the UE.
• E-RABsToBeSetupList indicates a list of radio access bearer. Each E-RAB is defined by E-RAB ID and corresponding QoS parameters like ARP, QCI, GBR, etc.
• UL GTP TEID indicates the SGW endpoint of the S1 bearer for delivery of uplink packets. It is delivered to the target eNB so the target eNB can establish the UL S1 bearer with the same SGW as like the source eNB. 

Upon receiving the Handover Request, the target eNB allocates required resources to proivde the same quality of service to the UE as the source eNB. The required resources will include resources for RRC to communicate with the UE and resources for S1 bearer to communicate with the SGW. Additionally, the target eNB also allocates a new DL GTP TEID that will be delivered to the source eNB in step#3 and used for direct GTP Tunnel between two eNBs.

[3] The target eNB informs the source eNB about the prepared resources by sending Handover Request Acknowledge.

• E-RABs Admitted List contains the list of E-RABs for which the resources have been allocated. It also contains the DL GTP TEID that identifies the X2 transport bearer that shall be used by the source eNB to forward the downlink packets towards the target eNB.
• E-RABs Not Admitted List contains the list of E-RABs for which resources won't be allocated.
• Target eNB to source eNB transparent container is used by the target eNB to deliver the message to the UE through the source eNB transparently. In this case, it contains the Handover Command which is a command to the UE for handover execution.

Upon receiving the acknowledgement, the source eNB establishes the X2 direct tunnel with the target eNB. Henceforth, the traffic received by the eNB is forwarded to the target eNB and will be buffered until the UE handover is completed.

[4] The source eNB requests the UE to reconfigure the RRC connection by sending RRC Connection Reconfiguration, which also contains Handover Command that was received from the target eNB.

• C-RNTI (Cell Radio Network Temporary Identifier) is a temporary UE identifier assigned by the serving eNB. It is persistent while the UE is connected to that eNB and re-assigned whenever the serving eNB changes.
• DRB-ID (Data Radio Bearer Identifier) is an identifier of the data bearer between UE and the eNB to be established with the target eNB. 

Upon receiving the Handover Command, the UE executes handover from the current eNB to the target eNB.

[5] The source eNB informs the target eNB of the current status of packet transmitter and receiver by sending SN Status Transfer. The message includes the uplink/downlink PDCP SN and HFN.

• PDCP(Packet Data Convergence Protocol) SN indicates the sequence number assigned for each packet data unit.
• HFN (Hyper Frame Number) is used to limit the actual number of sequence number bits that's needed to be sent over the radio. When the PDCP SN reaches the maximum value, the PDCP SN is restarted from zero and HFN is incremented by one. This value shall be synchronized between the UE and the eNB.

[6] After the UE has successfully synchronized to the target cell, it sends a target eNB a Handover Confirm informing that the handover has been completed. The buffered data at the target eNB is forwarded to the UE through the DRB. The uplink data from the UE can also be sent hereafter.

[7] The target eNB creates the S1 eNB GTP TEID and sends the MME the Path Switch Request to inform that the UE has changed the cell.

• ECGI (E-UTRAN Cell Global Identifier) is a globally unique cell identifier to which the UE is camping on.
• TAI (Tracking Area Identity) is a globally unique tracking area identifier.
• E-RAB to be switched indicates the list of EPS bearers to be switched.
• S1 eNB GTP TEID indicates the end point of the GTP Tunnel that will be used by the SGW to identify the target eNB.

[8] Upon receiving the Path Switch Request, the MME requests the SGW to modify EPS bearers by sending Modify Bearer Request per PDN connection. The Modify Bearer Request contains the list of EPS bearers to be modified.

The PGW may need to inform the PCRF of the fact that the UE's location has been updated based on the request from the PCRF when the Gx session was established. Refer to "Bearer level event and VoLTE call setup failure" for basic understanding as to how the bearer level event reporting mechanism is realized within the PCC architecture.

[9] The SGW establishes the downlink S1 bearer with the target eNB and responds with the Modify Bearer Response, which includes the list of successfully modified EPS bearers.

[10] The SGW acknowledges the target eNB by sending Path Switch by sending Path Switch Acknowledge.

[11] The target eNB informs the source eNB that the handover has been completed successfully by sending UE Context Release. Upon receiving the UE Context Release, the source eNB releases all the resources associated with the received UE context.

***

As a result of X2 handover, the UE context that was maintained by the source eNB is moved to the target eNB. The UE's location will be updated (e.g., ECGI, TAI) and the UE's C-RNTI will be re-assigned by the target eNB. The target eNB shall also assign a new eNB S1AP UE ID which will be updated at MME. The S1 bearer between the SGW and the source eNB will be replaced by another S1 bearer between the same SGW and the target eNB, which requires updates of eNB S1 GTP-U TEID. The PCRF may need to update UE's location.

Please note that all these changes does not affect the existing VoLTE session. All the EPS bearers being used to transfer VoLTE signaling and data moves to the target eNB. In case there is an existing voice media session, the voice data arriving at the source eNB while the UE handover is in progress will be transferred to the target eNB through the direct tunnel between two eNBs and buffered at the target eNB. The buffered data is eventually transferred to the UE when the handover is completed. Assuming that the handover takes less than a few milliseconds, the user won't notice a voice cracking.

Red Mouse

REFERENCES

[1] GPP TS23.401, "General Packet Radio Service (GPRS) enhancement for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", v12.4.0, Mar 2014
[2] 3GPP TS36.423, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 application protocol (X2AP)", v13.1.0, Sep 2015
[3] 3GPP TS25.331, "Radio Resource Control (RRC) Protocol specification", v10.0.0, Jun 2010
[4] 3GPP TS36.331, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Radio Resource Control (RRC) Protocol specification", v12.7.0, Sep 2015
[5] 3GPP TS25.323, "Packet Data Convergence Protocol (PDCP) specification (release 9)", v9.0.0, Dec 2012
[6] 3GPP TS36.300, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2", v10.0.0, Jun 2010
[7] EventHelix.com, "LTE X2 handover sequence diagram", 20th Apr 2013
[8] Netmannias, "EMM Procedure 6. Handover over without TAU - Part2. X2 handover", Mar 21th 2014

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