Monday, February 23, 2009


After a long time I have found time to write something. Lately I have been reading GTPv2 for control plane. I got a transfer in my project and I will be testing one our products for GTP v2. This would be our companies entry into wireless segment (LTE), though we have GTP v1 already built in. So GTPv2-C can be found in 3GPP TS 29.274 v8.0.0 (Release 8). GTPv1-U can be found in 3GPP TS 29.281 v8.0.0 (Release 8). A combination of this control plane and user plane will be used in LTE. Our customers are most interested in performace testing of their devices, so we implement these two protocols and will give them a flexibility to run wide range of L7 protocols over the tunnels. Note that all this goes in single box. Isn't it interesting? Coming back to GTPv2-C, it will be used in EPC signalling interfaces S3,S4,S5,S8,S10,S11 and S16. Here is the general format of GTPv2-C Where: - if T = 0, TEID field is not present, k = 0, m = 0 and n = 5. - if T = 1, TEID field is present, k = 1, m = 5 and n = 9. - Bits 6-8 represent the Version field. - Bit 5 is spare, the sender shall set it to zero and the receiver shall ignore it. - Bit 4 represents the TEID flag (T). - Bits 3-1 are spare, the sender shall set it to zero and the receiver shall ignore it.

More Notes:

GTP v2-C messages shall be sent per UE on S3 , S10 and S16 interfaces GTP v2-C messages shall be sent per PDN Connection on S4 and S11 interfaces apart from the following exclusion Following GTP v2-C messages are sent per UE on S2 and S11 interfaces: - Downlink Data Notification/Acknowledgement - Stop paging

Traffic Flow Template information element is to specify the TFT parameters and operations for a PDP context.

My interests: - TS 29.281 v8.0.0 : GTPv1-U - TS 29.274 v8.4.1: GTPv2-C - TS 23.401 v8.4.2: GPRS enhancements for EUTRAN Access - TS 36.300 v8.6.0: EUTRAN Overall description. Stage2 - TS 29.060 v8.6.0: GTP across Gn and Gp interfaces I have some confirmation from our test tool. One traffic activity can create one PDP context. Other traffic activity may create secondary PDP context or use the existing context. Usually in mobiles we see only http traffic flowing, so there wont be a secondary PDP context created most of the times. Now I even have a confirmation from our test tool that secondary PDP are UE initiated. Correct?? Wrong? May be? But it makes sense now. One PDP context per traffic activity with particular traffic flow template. Super Cool. Then how does it work in LTE? Open Questions: How will the direct tunneling implemented in LTE? WIll there be a direct user plane tunnel established between eNodeB and PDN-GW? Do we still have PDP Contexts in GTPv2-C?Do we still have PDP contexts in GTP v2-C? How are secondary PDP contexts and dedicated bearers established? Are they network initiated or UE initiated?

I will write more about the protocol as I keep reading. Right now I have to go and train a guy for my older project.

March 14th : - Yesterday I had an eureka moment. I was not sitting in a bath tub though. My job project accelerated and we are expecting the software QA drop to be ready soon. Now GTP V2 is the bread and butter of LTE and I have to test our software for protocol conformance. Unfortunately there is no such tool. Even wireshark doesn't support version 2. So, my idea was to start writing a small custom tool which opens the V2 packet and reads the data and throws out pass of fail based on what it read.

But after a google search and second look at wireshark I found that people have started developing dissectors for GTP V2. Thats an incredible news. Even I found initial dissectors for GTP V2. I downloaded the source code and compiled. Hurray! Now my wireshark understand GTP C V2. Not entirely though. It just identifies the version field. Looks like there has to be lot of work done. I wrote to the dissector developer extending my help for testing the code. Haven't heard back though, but lets hope for the best. If you have any such ideas or anything to share just shoot a comment or email me santoshdornal at gmail dot com.

March 16th : AMBR : - Aggregate Maximum BIt Rate

This parameter refer to aggregate maximum bit rate for non-GBR flows.

APN-AMBR : THis is a subscription parameter stored per APN in HSS. This refers to maximum bit rate that can be consumed for all no GPR SDF's/SDF aggregates for this APN. This parametr is enforced by PDN-GW in downlink and by both UE and PDN-GW in uplink.

UE-AMBR: This parameter refers to maximum bit rate followed for all the non-GBP SDF's/SDF for this UE. This parameter is enforced in both uplink and downlink.

March 27th : Modify Bearer Request

I was wondering how is direct tunneling implemented in LTE. Well, there is a message called modify bearer request which doest it. Once the create session message is sent ,it is immediately followed by Modify Bearer request message indicating the user plane. Of-course this a control signal so this will be transmitted on S11 interface indicating S1-U interface. Now S1-U is manadatory, since DTI is by default in LTE, modify bearer request is mandatory alike GTP v1 where updated message is explicitly sent.


Pratik M. said...

You wrote:

Open Questions: Please comment if you know more about them.
- Is GTPv2-C compatible with GTPv1-C? Infact, will there be any compatibility issues here?

GTPv2-C is not backward compatible with GTPv1 at a protocol level. But there is some form of compatibility at the application above them, since their end goal is the same.

A Rel-8 SGSN and an PDN-GW would need to speak both GTPv1 and GTPv2-C to allow handovers between EUTRAN and UTRAN/GERAN covered by older SGSNs.

-With GTPv2-C coming in should the existing SGSN (GERAN/UTRAN) updated? How will be the interoperablity among the SGSN and S-GW?

The current (pre-Release-8) SGSNs speak GTPv1 and cannot talk to a SGW. The Release-8 SGSN speaks GTPv2 and inter-operates with MME+SGW.

Santosh said...

Thanks Pratik! I guess Release 8 is ready, atleast the specs. I was going through T2 23.401 and it addresses the communication between SGSN and SGW.

Manish said...

How will the direct tunneling implemented in LTE? WIll there be a direct user plane tunnel established between eNodeB and PDN-GW?

>>>>> Yes for user plane MME will be bypassed. SAE Gateway = S Gateway + P (PDN) Gateway. Direct tunnel is establish between eNodeB and SAE gateway. I will explore about eNodeB to P GW.


Do we still have PDP Contexts in GTPv2-C?Do we still have PDP contexts in GTP v2-C?

>>>>>> As per understanding now PDP context is replaced with session. We have similar message like create Session Request, Modify session request etc. NSAPI is replaced with EBI. Not sure about dedicated bearer.

Network initiated session establish is supported. SAE GW will send downlink data notification to MME and UE will start session establishment.

Regards and Keep Smiling

Santosh said...

Thanks Manish!

bsd said...

Guys, does GTP-C contain Cell Global Identifier on the Gn interface ?

Santosh Kumar Dornal said...

Yes there is.

3GPP TS 29.060 - 7.7.51 User Location Information

Anonymous said...

Santhosh, have a small out of context quick query. what are the contents of downlink data notification message?
precisely, what is the input given to the MME by SGW to trigger a particular UE back into active state?

Santosh Dornal said...

There are no contents in DDN except for cause. The GTP teid in the header is used to identify the UE.

3GPP TS 29.274 Section 7.2.11