VoLTE S1 handover completion (3/3)

After the UE confirms the completion of the S1 handover in a new cell, the target eNB initiates the completion procedure by sending towards the network. The completion procedure involves the SGW and PGW replacing the downlink S1 bearer from the source eNB to the source eNB releasing the UE associated resources and lastly, the release of Indirect Forwarding Tunnels by the SGW.

Figure 1. S1 handover procedure - complete

[12] The target eNB sends the Handover Notify to the MME notifying that the UE has been identified in the target cell and S1 handover has been completed.

• E-UTRAN CGI: globally identifies a cell and composed of PLMN identity and Cell identity.
• TAI: uniquely identify a Tracking Area and composed of PLMN identity and TAC (Tracking Area Code). 

Figure 2. Handover Notify

[13] The MME sends the Modify Bearer Request to the SGW requesting to switch the media path from the source eNB to the target eNB. The switch of media path from the SGW is done by updating the S1 bearer tunneling end point.

• Indication: includes various application flags. Refer to section 7.2.7 “Modify Bearer Request” in [TS 29.274].
• Bearer Context: identifies the bearer to be modified. It is composed of EPS Bearer ID and S1 eNB F-TEID sub elements.

In this practice, there are three bearers, i.e., bearer id = 5,6,7. The bearer 5 and 6 belongs to the internet APN, meanwhile the bearer 7 belongs to the IMS APN. The MME sends multiple Modify Bearer Request for each APN.

Note that in the following message, the value of F-TEID is set to 0x018088ed. This value is the one that was sent by the target eNB in step [4] Handover Request Acknowledge where it represents the tunneling end point of the target eNB for the downlink S1 bearer. Now, the MME deliver this value to the S-GW so the S-GW can use this value as a new target end point for the media path. As such, the downlink media path on S1 bearer is switched from the source eNB to the target eNB.

Figure 3. Modify Bearer Request for bearer 7

The following message shows the Modify Bearer Request for the bearer 5 and 6. In the same as described in the above, the value of F-TEID is set to 0x018008ed and 0x018048ed for bearer 5 and 6, respective. They are the same values as were sent by the target eNB in step [4] Handover Request Acknowledge where they represent tunneling end points of the target eNB for the downlink S1 bearer.

Figure 4. Modify Bearer Request for bearer 5 and 6

Note that the Modify Bearer Request is also sent by the SGW to the PGW which is not depicted here. The SGW and PGW are logically separated but in many cases, they are deployed on the same platform.

[14] The Modify Bearer Response sent from the PGW to the SGW and from the SGW to the MME.

• Cause: indicates the result of modifying the requested bearer.
• Bearer Context: identifies the bearer that has been modified. It is composed of EPS Bearer ID, Cause and S1 eNB F-TEID sub elements.

Note that in the following message, the value of F-TEID is set to 0x005b8422. This value is the one that was sent by the MME to the target eNB in step [3] Handover Request where it represents the tunneling end point of the SGW for the uplink S1 bearer. The tunneling end point values of SGW is created when the UE attaches the network at the very beginning. Upon S1 handover, the MME sends this value to the target eNB and the target eNB establishes uplink S1 bearer to the SGW using this value. At this moment, the source eNB also has uplink S1 bearer connection with the SGW with the same tunneling end points. As both source eNB and target eNB can send traffic to the SGW, there is no change that the data sent by the UE gets lost during handover procedure.

Now, the SGW sends this TEID to the MME for the downlink S1 bearer informing the tunneling end point for the downlink S1 bearer.

Figure 5. Modify Bearer Response for bearer 7

The same principal is applied to the following message which is for bearer 5 and 6.

Figure 6. Modify Bearer Response for bearer 5 and 6

[15] The MME requests the release of UE-associated S1 logical connections over S1 interface by sending UE Context Release Command. The source eNB releases its resources related to the given UE.

• UE S1AP ID Pair: contains the UE S1AP identifiers. It is composed of MME UE S1AP ID and eNB UE S1AP ID
• Cause: indicates the reason for this command. Refer to section 9.2.1.3 “Cause” in TS36.413 for the detail.

Figure 7. UE Context Release Command

[16] The source eNB confirms the release of UE-associated S1 logical connections over S1 interface by sending UE Context Release Complete.

• MME UE S1AP ID: uniquely identifies the UE association with the S1 interface within the MME.
• eNB UE S1AP ID: uniquely identifies the UE association with the S1 interface within the eNB.

Figure 8. UE Context Release Complete

[17] The MME requests the SGW to delete the Indirect Forwarding Tunnels by sending Delete Indirect Data Forwarding Tunnel Request.

Figure 9. Delete Indirect Data Forwarding Tunnel Request

[18] The SGW responds with Delete Indirect Data Forwarding Tunnel Response to the MME.

Figure 10. Delete Indirect Data Forwarding Tunnel Response

Red Mouse

REFERENCES

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

[2] 3GPP TS29.274, “Evolved General Packet Radion Service (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); Stage3”, v13.2.0, Jun 2015

[3] 3GPP TS36.411, "Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol (S1AP)", v13.0.0, Jun 2015

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

Bearer level event and VoLTE call setup failure

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

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

Fig 1. PCC architecture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Red Mouse

REFERENCES

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

VoLTE: 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