/windancer//04/08/how-to-understand-tss-s1-handover-with-mme-and-sgw-relocation-and-indirect-tunneling.html
转个文章这里。。。省的又google不到。
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 theS1-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 areTS 23.401– which describes the message flows between the SAE entities andTS 29.274– which describes each message and its IEs.
The S1 based handover with MME/SGW relocation and Indirect Tunneling looks something like this:
In order to make this more human-readable, I have considered the following scenario:
where my UE (UE-1) moves from eNB 30.0.0.1 to eNB 30.0.0.5 (which have an X2 link together) – doingX2 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 anS1 handoversignaling 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” tunnelto SGW2, which will forward them to the new eNB8, which is in charge of my UE.
The flow is like this (3GPP copy-pasted)
1) So, as this picture states, once the handover is decided, the source MME sends aForward Relocation Requestto 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 thetarget MMEsends aCreate Session Requestmessage to thetarget 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) thetarget SGWreplies to thetarget MMEwith aCreate Session Responsemessage, 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 foruser-planeand 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 itKey-A– which is theuplinkidentifier 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 adefault bearerin place with the MME 30.0.1.1 (source)and the SGW 30.0.2.1 (source). This default bearer has anuplink identifier TEID, called as aboveKey-A, which also has adownlink identifier TEID, calledKey-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, theindirect 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 aCreate Indirect Data Forwarding Tunnel Requestmessage to theTarget 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 itKey -2. This key instructs the target SGW about the destination of the packets for my UE (C)
5) then theTarget SGW(30.0.2.2)responds to this message with aCreate Indirect Data Forwarding Tunnel Responsemessage. 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, thetarget MMEsends aForward Relocation Responsemessage to thesource MME, instructing it about the bearers that have been accepted for creation on this indirect path
7) Now, thesource MME (30.0.1.1)sends aCreate Indirect Data Forwarding Tunnel Requestto thesource 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 thetarget SGW, contained in theCreate Indirect Data Forwarding Tunnel Responsefrom above –Key-B- when source SGW will forward the packets to target SGW, this will be the GRE Identifier used for encapsulating those packets
Thesource SGWresponds with aCreate Indirect Data Forwarding Tunnel Responsemessage, 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 IDKey-3.
*** At this point, we have anindirect tunnelcreated 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) : TEIDKey-2
At this point, the user traffic is like this:
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) thetarget MMEsends aModify Bearer Requestmessage to thetarget SGW, describing the newly created tunnels for downlink, not the indirect ones, the usual, direct ones and thetarget SGWreplies with aModify Bearer Responsemessage in order to acknowledge (or state a cause for rejecting) this
10) the source MME deletes its session from its (source) SGW, using aDelete Session Request / Delete Session Responsepair 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 theindirect tunnelby exchanging theDelete Indirect Data Forwarding Tunnel Request /Delete Indirect Data Forwarding Tunnel Responsemessages.
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 theCreate Session Requestmessage, 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 theIndication Flagsin 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 theS1 handover with no SGW relocation(whether or not the MME is relocated) andIndirect Tunneling? How is that going? Do I still send the two pairs of Create Indirect Data Forwarding Tunnel Request/Response?
and more to come
