X2 – based handovers – take 2

Posted: March 22, 2010 in technical
Tags: , , , , , , , , , , ,

So, in the previous post I have bluntly copy-pasted from the TS 23.401. Now, I have tried to also get a shiny capture of at least part of that conversation, more exactly, on the S11/S4 interface, the one between the MME and the SGW.

In the X2-based handover the MME never changes, it is the anchor point of the X2 handover. SGW may change or not, as per TS 23.401.

A. The scenario below depicts the case where the SGW does not change, in an X2 handover. The session creation and deletion are the same as before; what is different is the Modify Bearer Request and Modify Bearer Response messages.


As you can see, the SGW does not change, it is the same, MME also does not change, only eNodeBs change. The UE travels from source eNB to target eNB. The X2-based handover assumes that there is an X2 link/interface between these 2 eNBs.

The message exchange is the following


— At first, the downlink and uplink data of this UE flows from the (only) SGW through the source eNB, then the UE.

At this point, the UE already has a number of bearers created, at least the default one, created using the initial Modify Bearer Request – Modify Bearer Response sequence:





* I have assumed here the is the S11-MME IP of the MME entity, and the is the S11-MME IP of the SGW.

* is the GTP-c IP of the source eNB, and is the GTP-c IP of the target eNB.

— While the UE moves towards the margin of the source eNB range, source eNB, target eNB and UE prepare the handover. At this point, the source eNB knows it can no longer contact the UE, therefore it forwards the dowlink data it receives from the SGW, to the target eNB, which, in turn, forwards the data to the UE. At this point, the UE already forwards the uplink data to the new eNB.

— What remains to be done is to tell the SGW that the user-plane path changed. This is triggered by the target eNB, via a Path Switch Request message sent to the (only) MME. The MME then sends a Modify Bearer Request message to the SGW. This message contains the F-TEID of the user-plane having as IP address the IP of the target eNB, instructing the SGW to forward all the data for this user/bearer to this eNB. The SGW forwards this message on S5/S8 to the PGW. If the confirmation is received with Request Accepted Cause, then the SGW forwards the reply to the MME. Immediately after this, any new downlink data is forwarded by the SGW to the target eNB.




* As you can see the TEIDs of the user-plane don’t change, only the F-TEID IP of the path.

* The outer TEIDs are also the same, all that changes is the F-TEID inside the Bearer Context. This handover should be seamless for the user-plane traffic, it’s TEID should not change and packets should not be lost on the way.

— The MME sends a Path Switch Request Ack to the target eNB to acknowledge the handover.

— The latest message comes from the target eNB to the source eNB, letting it know that it can release resources for that UE.

B. When doing X2-based handover with SGW relocation, the things are a bit more complicated, because a new session needs to be created between the (only) MME and the target SGW. This means the scenario would look like this:


Here as well, the user-plane traffic would be forwarded from the source eNB to the target eNB temporarily, then, once the EPS signaling updates all the states on the target SGW, the downlink will also take place through the target SGW.


— Before starting the EPS signaling, the UE already forwards the uplink data to the target eNB, which then forwards it to the source SGW via the S1-U interface (as the target SGW is not yet in place).

— After the Patch Switch Request from the target eNB to the MME, the MME looks for an appropriate SGW to deal with the new target eNB user-plane path. The MME finds this to be the target SGW and initiates a Create Session Request to this new entity. If the target SGW replies, the session is created, allowing the downlink data from the PGW to be forwarded to the target eNB, via the target SGW.

— At this point, the MME send a Path Switch Request Ack to the target eNB, so that the uplink data from the UE can now be forwarded from the target eNB to the target SGW.

— In the end, the target eNB signals to the source eNB to release resources for this UE and the MME deletes the session with the source SGW.

  1. Kris says:

    EGTP is in trouble now. Look out, here comes Cristina :D!

  2. ranjith says:

    Excellent post, short but quite revealing.Throws a lot of leads, thanks for that.All the best for all your endeavors

  3. Yuanliang Zhang says:

    Hi, Cristina, in the post,
    ” As you can see the TEIDs of the user-plane don’t change, only the F-TEID IP of the path.”

    I can understand that the F-TEID on both the MME and SGW side won’t change if the MME and SGW be the same one after handover. But for the eNodeB, I wonder if the same TEID can be kept after handover to the target eNodeB since target eNodeB has no info about the TEIDs on the source eNodeB, and it may have already assigned the same TEIDs to other UEs.

    Please let me know your thoughts, thanks!

    • @Yuanliang: hey. Mwell, if I understand correctly, after doing some more reading, the TEIDs for control-plane are not necessarily the same, so this is a mistake in my post.
      I mean, although I haven’t found written anywhere in TS 29.274, nor in TS 23.401 (only to these two I have looked at) how the eNBs allocate these TEIDs, it seems pretty reasonable that they may very well allocate same TEIDs for their current UEs. So, in a handover case, they would have to allocate different control-plane TEIDs for newly-arrived UEs in handover scenarios.
      I will further ask around and come back today with update if I get new info on this.

  4. Yuanliang Zhang says:

    Hi, Cristina, thanks for the reply.

    Not sure if I got you correctly. For the X2 based handover without SGW change, My understanding is that the TEID-C should be kept the same, as there is no IE in the modify bearer request (response) message to change the TEID-C. But for TEID-U at the eNodeB side, the story is different. It may not be possible to synchronize the source and target eNodeB. For the TEID-U at the MME, SGW, my understanding is that it is reasonalbe to kept unchanged but it is implementation dependent.
    Please correct me if I’m wrong.

  5. @Yuanliang: hey, sry for the late reply. I barely now got to talk to the others and take a closer look at the Spec. The TEIDs are not necessarily kept, they are allocated by the target eNB – as you have “suspected” as well. My post is specific to what we have, so I apologize for not being complete.

    So, for the control-plane TEIDs, whatever the handover case, the eNB has no impact, as it is only concerned with the user-plane. The management is therefore done in the MME – which, of course, will not mangle the TEIDs of its UEs, but separate them and create different ones for each UE.

    As for the user-plane TEIDs, I read in 23.401 – S1-handover case, step 9, that the target eNB allocates the TEIDs for the UEs, then the MME is informed about this. So, the source and target eNBs are “kept in sync” by the MMEs, so that the TEIDs don’t overlap. Of course, as you said, it is not a must for them to be the same.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s