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

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

E2E VoLTE call flow : detach (UE-initiated)

The UE initiated detach procedure may occur when the UE is turned off or the UE needs to fall back from EPS services to non-EPS services or vice versa. Along with the detach procedure all the allocated resources are released and connections for signaling and bearer are disconnected.

The above figure shows the overall sequence of how the UE and the network releases related resources when the UE detaches. Upon receiving the detach request from the UE(1), the MME releases the EPS bearer context towards the S/PGW(2) and in turn, the bearer binding and the session binding is released over Gx and Rx(3,4). Apart from this procedure, the MME also releases the UE context towards the eNB(5) and the eNB releases RRC connection with the UE(6). Meanwhile, the IMS network is informed of bearer release from the PCRF and proceeds the release procedure of the SIP session(7).

I. EPS bearer release

Fig 1. Detach procedure - EPS bearer release

[1] The UE triggers the detach procedure from the LTE network by sending Detach Request towards the MME.

• Detach Type IE indicates the reason of detach procedure and where the UE is being detached from (i.e., EPS services only, non-EPS services only, both). In this example, the UE is being detached from the LTE network due to switch-off.
• EPS mobile identity IE is set to be GUTI when the UE has a valid GUTI. If the UE does not have the valid GUTI, the EPS mobile identity will be the IMSI.

The GUTI is a globally unique identifier of the UE. It is composed of the M-TMSI, PLMN-ID (MCC+MNC) and MMEI (MMEGI+MMEC). The M-TMSI is assigned by the MME when the UE attaches to the network and remain unchanged until the UE detaches from the network. The following shows the GUTI format and the sample message of Detach Request.

If it is the detach for EPS only or combined EPS/IMSI detach, the MME deactivates the EPS bearer context(s) for this UE locally and enter the state EMM-DEREGISTERED for this UE.

[2-3] The MME requests the S/PGW to delete the corresponding session by sending Delete Session Request. If there are multiple APNs that the UE was attached to, there will be multiple Delete Session Request, one for each APN. The message contains the list of EBIs to be deleted for each APN. In case of detach, all the EBIs belong to that APN shall be included.

Upon receiving the Delete Session Request, the SGW/PGW deactivates the EPS bearer context corresponding to the received EBIs of this UE. The bearer binding relation between EPS bearer and PCC rule is also released. The SGW/PGW responds with the Delete Session Response.

[4] The MME sends Detach Accept only if the Switch off parameter is not "Switch off". Otherwise, this transaction will be spared.

[5] The MME performs MME-initiated UE context release by sending UE Context Release Command to the eNB, which is to release the UE-associated logical connection. In this case, the message contains the cause value of "Detach". Upon receiving the UE Context Release Command, the eNB releases all related signaling and user data transport resources for the indicated UE by the UE S1AP ID.

[6-7] The eNB sends the RRC Connection Release to the UE. In case the RRC connection has not been released already, the RRC Connection Release will be sent as an Acknowledge Mode(AM). After releasing the RRC connection, the UE responds with the RRC Connection Release Complete.

NOTE Whether to use Acknowledge Mode (AM) or UnAcknowledge Mode(UM) is dependent on the requirements for the radio bearer such as packet loss, packet delay, etc. The basic difference between the UM and AM is that the UM would be compared with the UDP where re-transmission control is not provided, whereas the AM is more likely TCP. The detail for this technology may need to be referred to the radio expert.

[8] The eNB responds with the UE Context Release Complete to the MME and releases the S1 signaling connection. This step would be performed without necessarily waiting for the RRC Connection Release Complete from the UE. Upon receiving the UE Context Release Complete, the MME deletes any eNB related information.


II. IMS de-Registration

Once the GTP-C, S1-MME connection and the corresponding S1 bearers have been released, the network starts to release remaining resources and connections towards upstream.

Fig 2. Detach procedure - application level release

[9-10]  The PGW reports the event to the PCRF by sending Credit-Control-Request(CCR). The CCR contains the cause value set to be "TERMINATION-REQ". The "TERMINATION-REQ" is sent only when the IP-CAN session is terminated, i.e., detach. If there are multiple APNs to which the UE attaches, there will be multiple CCRs sent to the PCRF, one for each APN. The PCRF acknowledges with the Credit-Control-Answer(CCA).

[11-12] Upon receiving the CCR from the PGW containing the IP-CAN session termination event, the PCRF releases session binding relation between IP-CAN session and the corresponding AF-session and requests to release the Rx session by sending Abort Session Termination (ASR) to the P-CSCF. The message contains the Abort-cause value of "BEARER_RELEASED". The PCRF acknowledges with the Abort Session Answer (ASA).

[13] Upon receiving the CCR containing the cause value of "BEARER RELEASED", the P-CSCF performs de-registration procedure by sending the SIP REGISTER to the I-CSCF in the UE's home network with its Expires header set to zero. The P-CSCF performs a name-address resolution mechanism for P-Visited-Network-ID header to determine the address of the home network.

[14] The I-CSCF requests the registration state of the received Public User Identity to the HSS by sending the User-Authentication-Request(UAR) with its User-Authorization-Type set to "DE_REGISTRATION". The UAR contains the Public User Identity, Private User Identity, Visited Network Id, etc.

[15] The HSS determines if the user is currently registered and responds with the User-Authentication-Answer(UAA) with the corresponding S-CSCF name (i.e., Server-Name AVP). 

[16] The I-CSCF determines the address of the S-CSCF through the name-address resolution mechanism and sends the SIP REGISTER to that S-CSCF.

[17-18] Upon receiving the SIP REGISTER, the S-CSCF may trigger the 3rd-party de-Registration procedure towards the application server based on the iFC mechanism. On the other hand, the S-CSCF sends the Server-Assignment-Request(SAR) towards the HSS. In this example, the Server-Assignment-Type AVP is set to "USER_DEREGISTRATION_STORE_SERVER_NAME", which indicates that the give Public User Identity is no longer considered as registered and the HSS needs to keep the S-CSCF name after this action. 

[19-20] The 200 OK for the SIP REGISTER is sent towards the P-CSCF.

[21] The S-CSCF may send the SIP NOTIFY towards the UE to inform that the subscription has terminated. The body of the SIP NOTIFY includes the fact that the registration state has also been terminated. This SIP NOTIFY transaction is correlated with the subscription procedure that was done when the UE registered to this IMS network.

***

When it comes to IMS de-registration, it is supposed to happen before LTE attach in a normal situation and it would be a quite natural sequence considering the protocol stack. The UE shall release all the resources relating to applications before it detaches from the network. However, in this example, the UE performs LTE detach first and then the IMS Core initiates the IMS de-registration based on the bearer loss event reported from the PGW. This type of exceptional situation happens more often than not in reality. It can come from incomplete implementation of the VoLTE client in a UE or the UE might not be able to perform IMS de-registration for some reasons.

Red Mouse

REFERENCES

[1] 3GPP TS24.301, "Non-Access Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3", v12.4.0, Mar 2014
[2] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); General Radio Packet Service (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); Stage 3", v9.3.0, Jun 2014
[3] 3GPP TS23.401, "General Radio Packet Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", v12.4.0, Mar 2014
[4] 3GPP TS23.228, "IP Multimedia System (IMS); stage2", v11.4.0, Mar 2012
[5] 3GPP TS29.229, "Cx and Dx interfaces based on the Diameter Protocol; Protocol details", v12.6.0, Jun 2015
[6] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v13.0.0, Jun 2015

[7] Netmanias, "EMM Procedure 2. Detach", Jan 2014

VoLTE: Service Request scenario in IDLE mode

The IDLE state is defined as the state when both RRC state (i.e., eNB and UE signaling connection state) and ECM state (i.e., NAS signaling connection state) are IDLE while the EMM state maintained by the MME is still REGISTERED. This indicates that the UE is logically attached to the LTE network but the physical connection and the corresponding resources have been released from the UE up to the SGW (i.e., DRB and S1 bearer). The UE may fall into the IDLE mode when there hasn't been any activities for a while between the UE and the LTE network or when it is regarded the UE connection is lost.

In order to transfer any data to the UE in the IDLE mode, the MME has to wake up the UE in the first place so the UE can reconnect to the network. While reconnecting to the network, the UE and the network shall recover required resources and connections over RRC, S1AP and S1 interfaces. Once the EPS bearer is recovered, the data buffered in the SGW can be transferred to the UE. The following shows the conceptual sequence of the data transfer to the UE in the IDLE mode.

Fig 1. Conceptual diagram of network initiated service request

I. Network Initiated Service Request

The following flow shows the detailed procedure of how the application payload is delivered to the UE in the IDLE mode. As a precondition, the UE stays in the IDLE mode and the payload (i.e., SIP Message) has arrived at SGW.

Fig 2. VoLTE call flow - network initiated service request 

[1] Upon receiving the data when there is no available S1 bearer at the moment as the UE is in IDLE mode, the SGW sends the Downlink Data Notification (DDN) to the MME to request for paging the UE. The DDN includes the EPS Bearer ID (EBI) stored in the EPS bearer context of the bearer on which the downlink data packet was received over S5 interface.

[2] The MME acknowledges the request by sending Downlink Data Notification Acknowledge.

[3] The MME initiates the paging procedures by sending PAGING message to each eNB that serves cells belonging to the tracking area in which UE is registered.

The following shows paging messages distributed across multiple eNBs that belong to the target TA List.

NOTE As the paging procedure itself can cause heavy traffic in the air, the MME may need to have an optimized paging scheme to minimize the side-effect. After having been awaken, the UE performs RRC connection establishment procedure with the eNB from which the paging was sent.

[4] Once the RRC connection is established, the UE requests the network to establish NAS Signaling connection, radio connection and S1 bearers by sending Service Request towards the MME. The Service Request is delivered wrapped in RRC Connection Complete and Initial UE Message on RRC and S1AP interfaces. The RRC state transits from the RRC-Idle to RRC-Connected.

[5] The MME requests to establish the E-RAB connection by sending the Initial Context Setup Request to the eNB.

• UE-AMBR indicates the maximum aggregated bit rate for non-GBR bearers for the concerned UE.
• E-RAB To Be Setup Item includes the E-RAB information for each EPS bearers to be setup. 

In this example, there are three E-RABs to be setup which is the list of non-GBR bearers. Each E-RAB information contains the E-RAB ID, ARP and the SGW GTP-U TEID.

Upon receiving the Initial Context Setup Request, the eNB executes the E-RAB configuration and creates UE context based on the received parameters. In the meantime, the MME may perform the security setup procedure with the UE for integrity protection and ciphering of signaling data.

[6-7] The eNB requests the UE to establish the DRB by sending RRC Connection Reconfiguration. Once the DRB is established successfully, the UE responds with the RRC Connection Reconfiguration Complete to the eNB.

[8] After the DRB is successfully established, the eNB responds with the Initial Context Setup Response to the MME. The ECM state transits from ECM-Idle to ECM-Connected.

• E-RAB Setup List is a list of E-RABs that has been successfully established, which contains each E-RAB ID and eNB GTP-U TEID.
• E-RAB Failed Setup List is a list of E-RABs that has failed to establish.

[9] The MME requests the SGW to resume the suspended S1 bearer by sending the Modify Bearer Request. If there were multiple APNs to which the UE was connected before falling into IDLE state, there can be multiple Modify Bearer Request sent, one for each APN.

The Bearer Context IE contains the EBI and the eNB GTP-U TEID with which the SGW will establish the S1 bearer towards the eNB. In this example, there are two EBIs one for the default EPS bearer and the other one for dedicated EPS bearer.

[10] The SGW responds with the Modify EPS bearer response containing the resulting cause value for each requested EBI. The Bearer Context IE contains the EBIs and the SGW GTP-U TEID which is the same value that was contained in the Initial Context Setup Request at step #5. 

Once the S1 bearer is recovered, the SGW starts sending buffered data towards the UE. This procedure happens seamlessly without necessarily user interaction.


II. UE Initiated Service Request
In the same way, the UE may initiate the service request procedure in the IDLE to perform the VoLTE call initiation or location update procedures in the IDLE mode.

[1-10] Same as [4-10] in the figure 2. During this procedure, the RRC connection and NAS signaling connection is re-established. The UE context is recovered in MME. The EPS bearer including DRB and the S1 bearer is also re-established.

[11-12] The UE may trigger the TAU procedure by sending Tracking Area Update (TAU) request following the criteria as defined in TS23.401. The TAU contains the UE's current Tracking Area Identifier (TAI) and the ECGI. The last visited TAI is included if the UE has a valid TAI of the last visited tracking area and used by the MME to make a good list of TAI(i.e., TAL) for the UE. The TAL is contained in the TAU Accept.

Please refer to "VoLTE: Tracking Area Update and Combined Attach" for the detail.


Once the EPS bearer is recovered, the UE is able to initiate a voice call setup procedure by sending SIP INVITE. If there is no service data flow for a while, the UE and the network may again fall into the IDLE state.

***

In order to optimize the transactions between the UE and the network, the eNB shall be optimized as to criteria based on which the UE state falls into the IDLE mode. Furthermore the MME shall also provide the optimized scheme for paging schedules considering user experiences. If the paging scheme (i.e., timer values) is too loose, it will aggravate user experiences. If it is too frequent, it will cause heavy traffic in the air.

Red Mouse

REFERENCES

[1] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Services (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); stage 3", v13.0.0
[2] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v12.3.0
[3] Netmanias, "LTE EMM and ECM States", Sep 2013

Updated: Sep 2015

VoLTE : UE initiated voice call release

When the VoLTE call session does exist, either one of users engaged in the call can release the call session by sending SIP BYE towards the IMS network in a normal case. The user's request comes to the IMS network and it makes a chain reaction from the IMS network to EPC and to the UE. The P-CSCF informs the release of the AF session (i.e., SIP session) to the PGW via the PCRF and the PGW initiates the release of allocated resources for that application. The following scenario shows the case where the user requested to end the voice call session.

[1-2] Upon request from the user, the UE sends SIP BYE towards the IMS network to release the existing SIP session.

• Call-ID header is a globally unique identifier of this SIP session. In this context, it will identify the SIP session to be released.
• Route header is a list of IP addresses of intermediary nodes which stays in the signaling path.
• P-Preferred-Identity header indicates the originating user's identity that is preferred by the user to be used.
• P-Access-Network-Info header includes the radio access technologies and cell id.

[3] The P-CSCF sends Session-Terminating-Request (STR) to inform the PCRF that the established session shall be terminated over Rx, which combines the AF session and the IP-CAN session. As a result of this procedure, the session binding between the AF session and the IP-CAN session is terminated.

[4] The PCRF requests to remove the corresponding PCC rule by sending the Re-Auth-Request (RAR) containing the Charging-Rule-Remove AVP to the PGW. In this example, there are two charging rules to be removed for RTP and RTCP as the voice media session is to be released.

[5-6] The PGW unbinds the PCC rules from the corresponding EPS bearer and responds with the Re-Auth-Answer (RAA) to the PCRF. The PCRF unbinds the AF session from the corresponding IP-CAN and responds with the Session-Termination-Answer (STA) to the P-CSCF.

[7] The PGW sends the Delete Bearer Request containing the EPS Bearer Id (EBI) towards the MME.

[8] The MME requests the eNB to deactivate the EPS bearer context by sending Deactivate EPS bearer context request, which is wrapped by the E-RAB Release Command and RRC Downlink Direct Transfer over S1AP and RRC respectively.

Upon receiving the E-RAB Release Command, the eNB releases allocated resources on Uu and S1 for the corresponding E-RAB(s).

[9-10] The eNB sends the RRC Connection Reconfiguration request to release the radio bearer. The UE releases allocated resources on Uu.

[11-12] The UE responds with the Deactivate EPS bearer Context accept to the MME and the eNB responds with the E-RAB Release Response to the MME.

[13] Upon receiving the E-RAB Release Response, the MME updates the ECM and EMM state of the UE and sends Delete Bearer Response to the SGW/PGW. The SGW/PGW releases allocated resources on S1 and S5.

Red Mouse

E2E VoLTE call setup(4/4) - dedicated EPS bearer creation

While SIP signaling is in progress in VoLTE call setup, a dedicated EPS bearer is created for voice media transfer. The dedicated EPS bearer for voice is temporary one as it lasts only during the voice media session which is different from the default EPS bearer in that the default EPS bearer is persistent until the UE is detached from the LTE. The creation of dedicated EPS bearer is triggered by the P-CSCF sending service data information (i.e., AAR) to the PCRF. Once the dedicated EPS bearer is created for voice, there comes two EPS bearer created between the UE and the IMS APN, i.e., a default EPS bearer for SIP signaling and a dedicated EPS bearer for voice media. On top of this, there can be more dedicated EPS bearers created with different PCC rules and QoS according to service types.

I. Introduction

The P-CSCF converts the media information in the SDP into the service data information and sends it to the PCRF. The PCRF performs session binding between IP-CAN session and the Application Session, generates PCC rules and provisions them to the SGW/PGW. The SGW/PGW requests to the MME the creation of dedicated EPS bearer using the received PCC rules. The SGW/PGW also performs bearer binding between PCC rules and the to-be-created IP-CAN bearer. The creation of dedicated EPS bearer procedure is composed of sequential procedures of creating uplink S1 bearer, DRB (Data Radio Bearer) and downlink S1 bearer across UE, eNB and SGW/PGW.

NOTE the S5 interface between SGW and PGW is not depicted in the following practice for simplicity.

II. Creation of a dedicated EPS bearer for voice traffic

The following scenario shows the procedure of creating a dedicated EPS bearer during VoLTE call setup.

Fig 1. dedicated EPS bearer creation

[59] The SGW/PGW generates its own GTP-U TEID and initiates the procedure to create a dedicated EPS bearer by sending Create Bearer Request (CBR) to the MME. The CBR contains Bearer Context information of the dedicated EPS bearer to be created.

• (Linked) EPS Bearer ID: Indicate the default bearer associated with the PDN connection.
• Bearer Context: a set of information for dedicated EPS bearer to be created which contains EPS Bearer ID, Bearer TFT, GTP-U TEID and Bearer QoS.
• EPS Bearer ID : a requested EPS bearer ID to be created and shall be set to '0' at this stage.
• Bearer TFT : the uplink packet filters to be sent all the way down to the UE and applied by the UE when the UE sends out RTP and RTCP packet.
• SGW GTP-U TEID : the identifier of the SGW as an end point of the GTP-U tunnel.
• Bearer QoS : QoS for this dedicated EPS bearer which includes UL/DL MBR, UL/DL GBR and QCI.

Fig 2. IEs in Create Bearer Request

[60] Upon receiving the CBR, the MME allocates the EPS bearer ID and requests the UE to activate the dedicated EPS bearer by sending Activate dedicated EPS bearer context request towards the UE. The message is delivered to the UE being contained in the E-RAB Setup request and the RRC Downlink Direct Transfer over S1AP and RRC interfaces respectively. The E-RAB Setup request contains SGW GTP-U TEID and the E-RAB level QoS parameters e.g., ARP, UL/DL MBR, UL/DL GBR, etc.

• e-RAB ID: unique identifier of the E-RAB for the UE. Please note that the E-RAB ID=’5’ was for the default EPS Beaer with the Internet APN, ‘6’ was for default EPS bearer with the IMS APN and now, it is set to be ‘7’.
• e-RAB level QoS Parameters: QoS to be applied to an E-RAB, which contains QCI, ARP, MBR and GBR of the E-RAB. This is a copy of the received Bearer level QoS at step #59.
• SGW GTP-TEID: the identifier of the SGW at the end of GTP-U tunnel.

Fig 3. IEs in E-RAB Setup Request

  

The following snapshot shows the Active dedicated EPS bearer context request contained in the Non-Access-Stratum (NAS) PDU container.

• EPS QoS: QoS of an EPS bearer context which includes QCI, MBR and GBR of the EPS bearer
• Traffic Flow Template (TFT): the uplink packet filters to be sent all the way down to the UE and applied by the UE when it sends RTP and RTCP packet.
• Linked Transaction Identifier (TI): the identifier of the active PDP context from which PDP address for the new PDP context could be derived.
• Negotiatiated QoS: QoS of a PDP context

  

Fig 4. IEs in Activate dedicated EPS bearer context request

Upon receiving the E-RAB Setup request, the eNB allocates the required resources and establishes uplink S1 bearer with the SGW as part of the E-RAB establishment.

[61-62] The eNB sends the RRC Connection Reconfiguration request to the UE. The UE modifies the radio bearer accordingly and responds with the RRC Conenction Reconfiguration Complete.

[63] The eNB responds with the the E-RAB Setup response to the MME and it contains eNB GTP-U TEID which is allocated by the eNB.

• E-RAB ID: unique identifier of the E-RAB for one UE. This value is originally assigned by the MME and if this is already occupied, the UE can change it.
• eNB GTP-U TEID: the identifier of the eNB at the end of GTP-U tunnel. The eNB newly assigns the GTP-U TEID for this dedicated EPS bearer and it is delivered to the SGW via MME.

  

Fig 5. IEs in E-RAB Setup Response

[64] The UE responds with the Activate dedicated EPS bearer context response to the MME which is wrapped in the RRC Uplink Direct Transfer and S1AP Uplink NAS Transport on RRC and S1AP interfaces respectively.

• E-UTRAN Cell Group Identifier (CGI): globally unique identifier of a cell (PLMN ID + ECI)
• Tracking Area Identifier (TAI): globally unique identifier of a tracking area [PLMN ID + TAC]

Fig 6. IEs in Activate dedicated EPS bearer context response

  

[65] The MME responds to the SGW/PGW by sending Create Bearer Response. The Create Bearer Response contains the eNB GTP-U TEID which was received at step #63. Upon receiving the Create Bearer Response, the SGW establishes downlink S1 bearer towards the eNB.

Fig 7. IEs in Create Bearer Response

II. PDN connectivity and EBI allocation

The following shows the summary of all the procedures shown in the VoLTE call setup procedures, in which steps (1) to (4) are performed at the background automatically.

(1)    UE turend on.

(2)    PDN connection with the Internet APN: the QCI of the default EPS bearer = ‘9’, EBI = ‘5’.

(3)    PDN connection with the IMS APN: the QCI of the default EPS bearer = ‘5’, EBI = ‘6’.

(4)    IMS registration through the default EPS bearer with IMS APN.

(5)    The dedicated EPS bearer creation for voice upon request for VoLTE service: the QCI of the default EPS bearer = ‘1’, EBI = ‘7’.

Fig 8. PDN connection and EBI allocation

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

Last updated: 1 Jan 2016