how to understand TSs – S1 handover with MME and SGW relocation and Indirect Tunneling

Posted: May 6, 2014 in technical
Tags: , , , , , , , , , , , , , ,

At first, I thought I was too noob to understand this stuff. I still consider myself a noob, but the way these TSs are written sometimes really gets on my nerves.

Let’s just consider the case of the S1-based handover with MME relocation and SGW relocation and Indirect Tunneling – meaning there is no X2 link between the source and target eNBs. All I can do for the moment is to look at the S11 interface, because this is the one I have the opportunity to study at this point.

So, the 2 TSs involved in this case, at least at the high  level are TS 23.401 – which describes the message flows between the SAE entities and TS 29.274 – which describes each message and its IEs.

The S1 based handover with MME/SGW relocation and Indirect Tunneling looks something like this:

55123-indir

In order to make this more human-readable, I have considered the following scenario:

mme2

where my UE (UE-1) moves from eNB 30.0.0.1 to eNB 30.0.0.5 (which have an X2 link together) – doing X2 handover (with no MME relocation), then it moves from eNB 30.0.0.5 to eNB 30.0.0.8 (which don’t have an X2 link between them). As you can see from the picture, these 2 eNBs belong to 2 different MMEs and SGWs. This means that, when the UE moves from eNB5 (30.0.0.5) to eNB8(30.0.0.8), it will generate an S1 handover signaling between the source MME – MME1 (30.0.1.1), source SGW – SGW1 (30.0.2.1), target MME – MME4 (30.0.1.4) and target SGW – SGW2 (30.0.2.2). As there is no X2 link between eNB5 and eNB5, the downlink packets coming from the PGW while the UE is in the handover process with reach eNB5, then they will be “reflected” back to SG1, which will then forward them via an “indirect” tunnel to SGW2, which will forward them to the new eNB8, which is in charge of my UE.

The flow is like this (3GPP copy-pasted 🙂 )

ts1

1)  So, as this picture states, once the handover is decided, the source MME sends a Forward Relocation Request to the target MME. This message must at least contain the following mandatory IEs, as per TS 29.274:

– IMSI

– Sender’s F-TEID for Control Plane

– MME/SGSN UE EPS PDN Connections

– SGW S11/S4 IP Address and TEID for Control Plane

– MME/SGSN UE MM Context

2) Then the target MME sends a Create Session Request message to the target SGW, including (M == Mandatory):

– IMSI (M)

– RAT Type – here is E-UTRAN (M)

– Sender F-TEID for Control Plane – here it is the IP address of the source MME: 30.0.1.4 + it’s TEID/GRE Key (this “key” is actually a hexadecimal number on 2 bytes) (M)

– APN Name (M)

– Maximum APN Restriction (M)

– LBI – Linked EPS Bearer ID – indicates the default bearer of the connection – the ID of the default bearer, usually this has value 5 (C)

– PGW S5/S8 Address for Control Plane or PMIP – this is the IP address of the PGW: 20.0.0.1 (C)

3) the target SGW replies to the target MME with a Create Session Response message, containing:

– Cause (M)

– Sender F-TEID for Control Plane – this is the IP address of the target SGW: 30.0.2.2 (C)

– APN Restriction (M)

– Bearer Contexts created (M) – this means that all the bearers that have the OK to be created for the UE in question are going to be present here, in a separate group IE; the IEs within a Bearer Context have the following:

— EBI – EPS Bearer ID (M)

— Cause (M)

— S1-U SGW F-TEID – the IP address of the SGW used for user-plane and a TEID/GRE identifier on 2 bytes – this is usually the same identifier used for the initial traffic of this user, _before_ the handover, let’s just call it Key-A – which is the uplink identifier for the user (C)

— Bearer Level QoS – the new QoS parameters, if they have been changed (C)

** Let’s stop for a second a recap. What do I have at this point? I have an UE (UE-1 in the picture) with an IP address (let’s say: 40.0.0.91). It is attached to the eNB 30.0.0.5, having a default bearer in place with the MME 30.0.1.1 (source) and the SGW 30.0.2.1 (source). This default bearer has an uplink identifier TEID, called as above Key-A, which also has a downlink identifier TEID, called Key-1. Let’s say that what travels in uplink has a key made out of letters, and what travels in downlink has keys made out of numbers 🙂

Ooook, what’s next. Well, as my UE moves to eNB 30.0.0.8, AND there is no X2 link between eNB5 and eNB8, target MME creates an indirect tunnel for the packets. Once the UE has moved to eNB8, the uplink flows directly from this new eNB, to the new SGW and so on. So, the indirect path is for the downlink packets, more precisely, for THOSE downlink packets that have already been routed by the source SGW to the source eNB (eNB5). eNB5 cannot contact eNB8 directly, so it re-routes these packets back to the source SGW, which will also re-route them via this indirect tunnel to the target SGW – which has direct S1-U connectivity to the target eNB to deliver the packets to my dear UE 🙂

How does EPC do that?

4) Target MME (30.0.1.4) sends a Create Indirect Data Forwarding Tunnel Request message to the Target SGW (30.0.2.2), containing all the grouped IEs Bearer Contexts that are to be forwarded this way, this grouped IE being the only Mandatory IE in this message. This Bearer Context IE contains:

— EBI – EPS Bearer ID (M)

— S1-U eNodeB F-TEID for data forwarding – this is the IP address of the target eNB (30.0.0.8) and its associated TEID/GRE key, let’s call it Key -2. This key instructs the target SGW about the destination of the packets for my UE (C)

5) then the Target SGW (30.0.2.2) responds to this message with a Create Indirect Data Forwarding Tunnel Response message. This message has 2 Mandatory IEs: the Cause and the Bearer Contexts grouped IE. This Bearer Context IE has:

— EBI (M)

— Cause (M)

— S1-U SGW F-TEID for data forwarding – this is the IP address of the target SGW and its TEID/GRE identifier – Key-B

6) After this, the target MME sends a Forward Relocation Response message to the source MME, instructing it about the bearers that have been accepted for creation on this indirect path

7) Now, the source MME (30.0.1.1) sends a Create Indirect Data Forwarding Tunnel Request to the source SGW (30.0.2.1), with elements similar to the corresponding message above, except that in this case, the Bearer Context has the TEID/GRE identifiers of the target SGW, contained in the Create Indirect Data Forwarding Tunnel Response from above – Key-B – when source SGW will forward the packets to target SGW, this will be the GRE Identifier used for encapsulating those packets

8) The source SGW responds with a Create Indirect Data Forwarding Tunnel Response message, same as above, but the TEID/GRE ID is the one of the IP address of the source SGW. This ID shall be used for uplink data on the indirect tunnel from the source eNB to the source SGW. Let’s call this ID Key-3.

*** At this point, we have an indirect tunnel created between the following entities:

source eNB (30.0.0.5) -> source SGW (30.0.2.1) : TEID Key-3

source SGW (30.0.2.1) -> target SGW (30.0.2.2) : TEID  Key-B

target SGW (30.0.2.2) -> target eNB (30.0.0.8) : TEID Key-2

At this point, the user traffic is like this:

traffic

1: packets already forwarded by the source SGW to the source eNB are “reflected” by this eNB – use the downlink GRE ID established initially, Key-1

2: the reflected packets from source eNB back to source SGW use the GRE negotiated via the messages above: Key-3

3: packets then travel on the tunnel from source to target SGW, via the TEID/GRE ID: Key-B

4: then the target SGW finally forwards the packets down to the target eNB via GRE ID: Key-2

*** During all this complicated process, the uplink is already using the target eNB as source for the encapsulating tunnel

So, what happens afterwards?

9) the target MME sends a Modify Bearer Request message to the target SGW, describing the newly created tunnels for downlink, not the indirect ones, the usual, direct ones and the target SGW replies with a Modify Bearer Response message in order to acknowledge (or state a cause for rejecting) this

10) the source MME deletes its session from its (source) SGW, using a Delete Session Request /  Delete Session Response pair of messages, carefully indicating the SGW that this is only a “local detach” of the UE, not a complete detach, meaning that the UE just moved and the local information about it is no longer valid, NOT that the UE disappeared from the network and the resources are to be deleted !

11) 12) both pairs of source and target MME/SGW now delete the indirect tunnel by exchanging the Delete Indirect Data Forwarding Tunnel Request / Delete Indirect Data Forwarding Tunnel Response messages.

And everybody is happy.

EXCEPT Me, because there are a lot of misleading and confusing “explanations” in the specs regarding this type of scenarios, like for instance:

a) one spec (TS 23.401) states that the delete session procedure should have Cause and LBI IEs in the Create Session Request message, while TS 29.274 defines these 2 IEs as Conditional, and, as per the condition in place, none of them should appear in this message when the source MME disconnects from the source SGW. Instead, the SGW should look at the Indication Flags in this request: if the Operation Indication is set, then this is a full detach, if the Scope Indication is set, this is a local detach.

b) look at the above flags: shouldn’t it be better to have just 1 flag, and, if it is set, we have a full detach, otherwise we have a local detach?

c) what happens in the S1 handover with no SGW relocation (whether or not the MME is relocated) and Indirect Tunneling? How is that going? Do I still send the two pairs of Create Indirect Data Forwarding Tunnel Request/Response?

and more to come

Advertisements
Comments
  1. Tom says:

    Hey , this is very useful blog , lot lot of useful information.Thanks !!

    Do you have some more post/blog on LTE (OR) can you guide me to list of technical blogs on your site (I had a tuff time in finding the technical section 😦 )

  2. Tom says:

    Thanks for your response !! You got good stuff on HO !! keep up the god work !

  3. Jacky says:

    thanks,
    when target enb has not receive end marker, but it has already reordered the forward data have pdcp sn, can the enb transfer data to ue in spite of the receiving of end marker

  4. Yuanliang Zhang says:

    Hi Jacky,

    In 3GPP 36.300 V9.3.0, there is a statement that
    Target eNB does not have to wait for the completion of forwarding from the source eNG before it begins trasmitting packets to the UE .

    It seems to me that the specs only states that the end marker will be sent in the case of SGW kept unchanged, how about the case of SGW change, there will be no chance for the SGW to detect the path change and send the end marker packet.

  5. sri says:

    hi… i do not understand how the end-marker packets can help in the reordering of packets at the target…

    please provide some clarity…

    thanks…

  6. @sri: hey there
    unfortunately this is not very clear to me either, so I will still ask for the feedback of the other readers…

    In TS 23.401, section 4.4.3.2 Serving Gateway, describes one of the SGW’s functions:
    “sending of one or more “end marker” to the source eNodeB, source SGSN or source RNC immediately after switching the path during inter-eNodeB and inter-RAT handover, especially to assist the reordering function in eNodeB”

    Also:
    in TS 23.401, 5.5.1.1.2 X2-based handover without Serving GW relocation:
    “5. In order to assist the reordering function in the target eNB, the Serving GW shall send one or more “end marker” packets on the old path immediately after switching the path as defined in TS 36.300 [5], clause 10.1.2.2.”

    and TS 36.300, 10.1.2.2 Path Switch:
    “In order to assist the reordering function in the target eNB, the Serving GW shall send one or more “end marker” packets on the old path immediately after switching the path for each E-RAB of the UE. The “end marker” packet shall not contain user data. The “end marker” is indicated in the GTP header. After completing the sending of the tagged packets the GW shall not send any further user data packets via the old path.”

    So, as far as I understand, this is THE LAST packet flowing on the USER-PLANE, which does NOT contain user-plane actual data, last packet that indicates the end of the data flowing on the old path. This happens in the case of the X2 or S1 handovers that do not imply SGW relocation, because the end-markers in question are sent by the (SAME) SGW when the old path ends.
    When we are talking about an SGW relocation, the new SGW will discuss with the old SGW on separate TEIDs, so that it will know how to handle the packets.

    So, these end-markers should be useful to the source eNodeB, so that is knows it can no longer use its uplink, and any other packets it may have (buffered or still come in downlink), it should forward them to the target eNodeB – via X2 (if this one exists, otherwise on the indirect path) and also useful to the target eNodeB, so that it knows that the old path was closed, so it should not receive any more packets on that path.

    Indeed, SRI, I am still now clarified about its “reordering” function, as the actual packet ordering should be a TCP function, not on the GTP level. I will keep reading on this.

  7. Vijay says:

    Awesome info….. Much needed one…. I do follow Santhosh’s Blog and this one was good too…. However it did take me twice or thrice to go through to exactly figure out the technicalities …. Good work !

  8. Mika says:

    Hi
    I don’t understand why the sender’s TEID of the create session request is Source MME ‘s TEID whereas Target MME sends this message. Then I don’t see the usefulness of this information for Target SGW.

    • @Mika: because there is a mistake here. You are correct, that should be the address of the tarhet MME, the actual entity that sends this message: 30.0.1.4. I have updated the description.

  9. Mika says:

    Hi
    I think there is another mistake here. The PGW F-TEID is not sent by the target SGW in the create session response but in the create session request (sent by the target MME).
    Are you ok with that ?

  10. @Mika: actually, it is in both 🙂

  11. Mika says:

    I thought the PGW TEID for control plane is sent only on the S5/S8 interface (between the SGW and the PGW) during an initial attach and not during an handover procedure.

  12. Anand says:

    Excellent explanation. Thanks a lot. Very very helpful explanation.

  13. Tom says:

    I’m a bit confused on how the TEID’s are allocated and used. You talk of uplink keys and downlink keys. From an eNB, is the uplink key the local TEID or remote TEID? And, does the forwarding tunnel have it’s own local and remote TEID or are the original values reused? on one end or the other?

    • @Tom: hey.
      The eNB’s “uplink” key is the remote TEID value (the uplink end of the tunnel). The Indirect Forwarding tunnels have their own TEIDs (only ends that actually need a TEID), which are negotiated via the Create Indirect Tunnel Request/Response exchange.

  14. priya says:

    Hey!!
    Can you please brief about the security context wit respect to S1 based handovers..
    Is the security context re-established or same set of keys are used . (When MME changes)

  15. @priya: 🙂 if you know anything about security, then you must suspect there is no way I can just “brief you in”. if security was something to be taken so lightly, then it wouldn’t be such an issue
    I would need an entire post (for sure more than 1) to go into security. And I don’t plan to do that too soon 😛

    1. What I have though is an older paper I published on security. Here is the link:

    http://www.thinkmind.org/index.php?view=article&articleid=icdt_2011_1_10_20013
    It’s not much, but just to make an idea… Hope it helps 🙂

    2. To answer your question really quickly, then when the MME changes, the set of security keys also changes. Of course, the 4G key hierarchy is pretty big, but in theory you should re-negotiate the NAS keys between the UE and the MME.
    If anybody else is reading this and cares to contradict, please feel free to post – unfortunately, I am too lazy now to look into the TS and confirm for sure 🙂

  16. priya says:

    Thanks a lot cristina.

    As u said the Nas keys between UE and MME need to be renegotiated in case the MME changes then what about the MME context(Security context) that is send in Forward relocation request from Source to Target MME.
    (Ref: 3GPP 23401)
    Can the same keys be reused at MME..

    One more thing I would like to ask …

    Are any UE related Identifiers apart from MME UE S1AP ID passed in Handover Request Msg .

  17. priya says:

    Hi,

    Can someone let me know in which spec will I find Handover Confirm Message (Sent from UE to Target ENB) I have looked into the RRC spec(36331) but couldn’t find it.

  18. zdm says:

    To Yuanliang Zhang, about End Marker in the case of SGW relocated, it is PGW to generate it. See patent: US20100111041. http://www.faqs.org/patents/app/20100111041, where fig4 and fig5 show the flow for delivering EndMarker in the cases of SGW relocated.

  19. zdm says:

    Hi Priya, the RRC messages “RRC Connection Reconfiguration” and “RRC Connection Reconfiguration Complete” in 36.331 are “Handover Command” and “Handover Confirm” messages mentioned in 23.401. It is true that the message name is not same for two specs when talking about the same signalling.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s