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

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: PDN connectivity request vs handover

The PDN connectivity procedure is to request the setup of a default EPS bearer  to a PDN[TS24.301]. The PDN can either be the default PDN or an additional PDN. When it is the default PDN, the UE establishes the default EPS bearer as a part of the process of initial attach. If it is a subsequent PDN, this procedure will establish additional default EPS bearer with that PDN. As such the UE supports multiple default EPS bearers in multiple PDNs.

When the PDN connectivity procedure does collide with the handover procedure, the EPS shall be able to handle the situation based on the principle of best effort. The MME may pause the bearer creation procedure and resume when the handover is completed or the MME shall reattempt the E-RAB setup request after the handover is completed[TS23.401].

The following is the case where the PDN connectivity procedure collides with the X2 handover.

The above is the case the PDN connectivity request is sent for the second PDN. In this example, the MME proceeds the activation of the default EPS bearer by sending the Activate default EPS bearer Context request over S1AP while the X2 handover is in progress at the eNB. The eNB rejects the E-RAB Setup request with its cause value set to "X2-handover-triggered". Upon receiving the rejection to the E-RAB Setup request, the MME shall wait until the X2 handover is completed. Once it is completed, the MME re-attempts the activation of the default EPS bearer request. The following shows the S1AP procedure where the E-RAB setup request is rejected while subsequent PDN connectivity procedure.

The same mechanism is also applied to the S1 handover case as shown below.

In this case, the MME requests activation of the default EPS bearer as a normal procedure before receiving the Handover Required while the eNB already sent the Handover Required and subsequently receives the Activate default EPS bearer Context request. If the handover is only in preparation stage, the eNB may be able to cancel the handover and continues the E-RAB setup procedure. Instead, in this example, the eNB rejects the E-RAB setup request with its cause value set to "S1 intra system handover triggered". Upon rejection, the MME hold the state until the S1 handover is completed and resumes by reattempting the activation of the default EPS bearer.

NOTE the MME may pause between the step #b and the setp #6  as it is already aware of the S1 handover in progress. However, from implementation point of view, it looks better to pause after the setp #6 as it is a common place both for S1 and X2 handover.

If the timer at MME expires and the PDN connectivity couldn't be completed, it is expected that the UE reattempts the PDN connectivity procedure. In order to request connectivity to an additional PDN, the UE shall start timer T3482 after sending PDN connectivity request and enter the state of PROCEDURE TRANSACTION PENDING[TS24.301]. The T3482 stops when the UE receives the Activate default EPS bearer Context request or if expires, the UE reattempts the PDN connectivity procedure.

Red Mouse