GTPc V2

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.