Sunday, May 24, 2009

LTE : Tunnel Identifiers (GTPv2)

From my LTE mind map in the last post, understanding bearers is the most important thing. I must agree with one my readers who pointed out that "MindMap" looks horrific and ugly. I know. I am very bad with sketches and that was the main reason for me to drop off from choosing medical sciences. :) Rest apart, lets get going.

First step in understanding bearers is tunnels. How are tunnels identified? I want to elaborate this post with complete LTE call flow where two activities are running on mobile phone, one is using default bearer and other is using dedicated bearer.

The trick is not to understand the whole message in single gulp. Divide the message into IE's and take up the activity of each IE separately. Note that we are only dealing with mandatory and conditional IE's here. The concentration is on TEID and FTEID fields.

default_bearer.jpg

The above call flow is self explanatory and is pretty simple. We see two fields TEID and FTEID. TEID is the field present in the GTP-C header and using which the tunnel is identified. FTEID is Fully Qualified Tunnel End Point Identifier. This IE is used to send TEID/GRE Key and IP info of sending entity.

Create Session Request is always sent with TEID value set to zero. There are bunch of other messages where TEID value is set to zero and sent. Refer to spec for details. The S-FTEID is senders FTEID. MME sends this field with a TEID value say 0x111 and IP address of it to S-GW.

Once S-GW receives this message it learns the IP address of MME and TEID field to be used in the response. S-GW creates create session Response message with TEID value 0x111 and S-FTEID. S-FTEID value here contains the TEID value,say 0x222, to be used by MME and IP address of the S-GW.

At this stage the control plane for communication between MME and SGW is set. MME uses TEID: 0x222 for sending any control plane info to S-GW and S-GW uses TEID 0x111 to send any control plane info to MME.

Once the control plane is set traffic has to flow. Modify Bearer Request is used to indicate the S1-U interface of eNB. So S-FTEID (S1-U eNB FTEID) value is set to say 0x0a + IP address and sent to S-GW. S-GW replies with its S1-U interface FTEID. At this stage the TEID for the user plane are set. User plane traffic will flow using the TEID's exchanged. Thus the traffic flows on default bearer.

dedicated_bearer.jpg

Bearer Resource Command is used by MME to request for a dedicated bearer. Once S-GW receives bearer resource command it initiates a Create Bearer request. Observe that same TEID field is used which was negotiated earlier. In create bearer request S-GW includes S1-U SGW F-TEID for user plane traffic.

MME sends a Create Bearer Response message with the S1-U eNB FTEID. At this point the a dedicated bearer is created and user plane traffic tunnel is negotiated. Dedicated bearer user plane traffic flows using the TEID's exchanged.

The interface described above is S11. This interface is mapped to S5/S8 and S1-MME interfaces. TEID are used to identify and map the tunnels in various interfaces.

There have been significant changes in the messages from Dec spec to March spec. The above details are with respect to March spec (3GPP 29.274 v8.1.1). I hope I got them correct. Else please correct me.

In next posts I want to look at the EBI fields and QoS. Comments are greatly welcomed.

27 comments:

Manish Panchmatia said...

1 .Excellent

The diagram convey nicely, no need to read the details :)

2. I want clarification. for first message "Create Session Req" Is it possible that MME source IP address will be different from IP address inside F-TEID? It will be useful to MME to balance the load. and next subsequent control plane messages for that tunnel will go to other IP address of MME.

3. This reminds me early days of GTP, GTPv-0 where our TEID was very simple. It was some combination that identify tunnel at Gb interface, directly copied to TEID in GTPv-0 header at Gn interface for UL. Later on, length of TEID become shorter, that is 4 bytes.

4. Still one more clarification. For the 4th message Modify Resp, suppose S-GW can not locate that session that what TEID it will use in header. for failure/rainy day scenario. It can be 0x00 or it can be 0x222 same as req. 0x111 is not possible, as S-GW lost the session.

Santosh Dornal said...

Manish, thanks for the comments.

Yes, Create Session Req can use different source IP address in FTEID field. That would be good way to handle load as you mentioned.

Modify Resp: Interestingly I had same doubt couple of days back. So I did some research. The dec spec says MME will send Modify Bearer req with its FTEID to SGW, so that SGW can use it in response. But things have changed in March version. I went through CR for that change and it says, MME doesnt have to send FTEID in Modify req as SGW already knows the TEID. Having said that I havent found a way to handle if session is lost. I am still not sure if spec really has a answer for this. At this stage i would say the session would be lost. But let me dig more into specs and see what can be found.

Anonymous said...

Hi,

One basic question on Modify Bearer Request. The modify bearer request is initiated by MME whenever a user plane data needs to be sent. Is this correct?
-A-

Santosh Dornal said...

I would say MME sends modify bearer request to indicate User plane. user plane data may or may not be sent after that, upto UE :)

3g4gorwhatever said...

Hey , Very usefull info ...thanks for the information !!

~Jagadeesh

Anonymous said...

I think this is the best explaination about GTP messages. Excellent work! The specifications (29.274) about this subject are terrible evasive. I mean it is unclear in there which event happens at which moment and so on.... Again: excellent work!

Santosh Dornal said...

Thanks!

Anonymous said...

In case, SGW is not able to find the ue-context using the sgw control plane teid sent by mme in msg header(subsequent msgs after create session), is it that sgw will not be sending any response and mme times out and marks failure for those procedures?

Apart from echo messages, all other messages are ue-context specific. What could be the handling on sgw end when it doesnt find a ue-context?

P

Santosh Dornal said...

Yes, you are correct. If MME or SGW doesnt recoginze the messages then they are simply ignored. In this case if SGW or MME is using the wrong TEID's then the messages are to be simply ignored and marked as failures.

Kirill said...

Thanks for the blog, Santosh! I've been following it for last three months and I learned much from it!

I've got a question on this topic: according to 29.274 Create Session Request message should contain "PGW S5/S8 Address for Control Plane or PMIP" on S11 interface during Initial Attach procedure. It has the format of F-TEID.
Which IP should be used here and what is the actual purpose of this parameter

Santosh Dornal said...

Krill

This is the most important IE in create session request. This IE is used by SGW to forward create session request to PGW. It is MMEs job to choose the PGW based on APN and inform about the chosen PGW to SGW in create session request by means of this IE. There are several ways by which MME selects a PGW, but selected PGW FTEID shall be sent in this IE.

Kirill said...

Right! I knew that MME should choose the PDNGW, but I had no courage to realize that it is MME which actually defines the F-TEID of PDNGW. Thanks for the answer!
In this way, TEID=0 and IP address = PDNGW are set by MME here. SGW just transfers the IE further to PDNGW. PDNGW defines its TEID and return it back to SGW.
By the way, looking into your GTP-C realization (http://code.google.com/p/s11interface/), I see that you put 0.0.0.0 address in this IE.

Santosh Dornal said...

Yup. The code is dummy. Its just to understand the message flow over S11 interface. Feel free to change it however you want to. :-)

Ruchi Mehta said...

Nice explanation.
Why cant the S1-U FTEID go in the create session response?

Santosh Dornal said...

Actually, the SGW S1-U FTEID does go in create session response. But eNB S1-U FTEID is indicated to SGW only in modify bearer request.

ija said...

Hi, thanks for the post, but I was confused about the User Plane Traffic MME <-> SGW in sequence diagram since there is no user plane there.

I think I understood it after reading your LTE whitepaper, but I think there is too much things left out especially in the paragraph "Once the control plane...".

Anonymous said...

Hi ,

For a 4G Supported Mobile. If I am attached in 4G network(LTE) and swiched off, Moved back to 3G network and performed a Switch on. Because of some reasons there are some PDP Contexts left on the SGW 4g Network.

Attach request in s4-SGSN contains a delete Session request to be sent to old s4-SGSN/S-GW every time. ( There is a Delete Session request sent every time in the Attach Flow "Refer 3GPP TS 23.060 V8.5.1 " 6.5.3 Section )

Can you please tell me how the Linked EPS Beared Id message IE in GTPv2 (DElete Session Request) should get populated ? AS this is intial attach for 3G I cannot dont have any contexts .. Is this a valid scenario ?

Santosh Dornal said...

Once UE is switched off in 4G,all the context information should be deleted in eNB, MME,SGW, PGW. When UE performs a switch on in 3G, SGSN may contact MME for UE imsi details.

A. Kiran Kumar said...

@Manish : Regarding your 4th question

4. Still one more clarification. For the 4th message Modify Resp, suppose S-GW can not locate that session that what TEID it will use in header. for failure/rainy day scenario. It can be 0x00 or it can be 0x222 same as req. 0x111 is not possible, as S-GW lost the session.

If SGW can not find the session, it can reply with modify bearer response by keeping TEID as 0 in header and appropriate cause. This message (In general responses) can be identified by MME using the Sequence number. This will eliminate retries.

Sumanth said...

Santosh, I must say, a very Excellent blog to understand which is down-to-earth level of explanation.
I have a basic doubt in your call-flows, since i am a new one to LTE and gtpcv2, this doubt may be a silly one:
After Modify Bearer Resp, on which interface the user plane traffic flows: is it on S1-U between E-UTRAN and S-GW directly OR the traffic has to go via MME?

Santosh Dornal said...

MME is never involved in data.data flows between EUTRAN and SGW

PR@S@D D said...

Hi Santosh,

I have one query regarding TEID value in GPDU, Can that value be zero????
i.e GTPU packets PGW <--->SGW<--->eNB
coz GTP Echo Req,Echo Response and GTP Error Indication message should be on TEID zero.

Regards
PRASAD

Santosh Dornal said...

I dont think TEID 0 is allowed for GPDU.

Anonymous said...

Hello
very useful information ,I have doubt if call is up on SGW and after that PGW is restarted with same restart counter and we try to perform s1Reestablish from MME ,PGW will respond (M odify Bearer Response)with cause "context not found" ,what should be behaviour of SGW in this case....?

Santosh Dornal said...

SGW has to forward that Cause to MME. MME should take down the subscriber and perform re-attach.

Anonymous said...

Hi Santosh,
you wrote Create Session Request is always sent with TEID value set to zero.
That's something I was also thinking. But in real life I can see that this is not (always) true.
For the first bearer (default 5) I agree,
but for a further dedicated bearer I saw traces,
which includes instead of zero the S-TEID of the CreateSessionResponse from the default bearer creation!
And the complete signalling for the dedicated bearer running on the same TEID's like the signalling of the default one!

Regards,
ms

Anonymous said...

again concerning TEID 0.
in 29.274 you can read:
... the TEID field shall be present in a GTPv2-C header, but its value shall be set to "0":

- Create Session Request message on S5/S8

- Create Session Request message on S4/S11, if for a given UE, the SGSN/MME has not yet obtained the Control TEID of the SGW.

This confirms what I wrote before.
Best regards
ms