LTE S11 Interface : GTPv2 Code

I had an amazing vacation with family and friends. But past week took the juice out me. Too much was left out at work and I opted for time off at really crucial time of release. O2 must be feeling bad about us for delaying the software. Anyway, since the beginning I always wanted to do some practical stuff with LTE. I started talking to my good friend and colleague Gopal about doing some thing in LTE. We started with writing GTPv1 code, simulation between SGSN and GGSN for a start. Ok, he started writing the code and I was giving him the IE's and stuff. We did something there. Then we started working at LTE. S1-AP was my protocol of choice, we wrote one handover scenario there, though it was pretty crude. By then my friend who is code freak figured out memory management in C. Then I become little well versed with S11 interface of LTE so I started understanding the code he wrote. First problem was figuring out header file. We had to define structures for every IE and allocating memory to each IE was big pain.

Nevertheless we figured it out. Last week I spent couple of hours day to finish the S11 interface. Ok, so what I did in simple words.

I wrote MME, SGW and GTPv2 communication among them. The messages are

• Create session request (MME---->SGW)
• Create session response (SGW---> MME)
• Modify bearer request (MME---->SGW)
• Modify bearer response (SGW---> MME)
• Bearer Resource Command - for dedicated bearer activation (MME---->SGW)
• Create bearer request (SGW---> MME)
• Create bearer response (MME---->SGW)
• Bearer resource command - for dedicated bearer teardown (MME---->SGW)
• Delete bearer request (SGW---> MME)
• Delete bearer response (MME---->SGW)
• Delete session request (MME---->SGW)
• Delete session response (SGW---> MME)

The code is written in C using UDP socket programming. There are three file.

• headers.h -- Contains all IE structures
• MME.c --- This is the client for us, as it initiates the communication
• SGW.c -- Responds to MME.

If you want to try the code you will need a linux box (I would prefer two linux boxes, one to run mme and other to run sgw.)

Compile the code

----- gcc mme.c -o mme

------ gcc sgw.c -o sgw

and run the code. Please note that you will need to run sgw first.

--- ./sgw

--- ./mme

Use tcpdump to capture the packets on localhost.

--- tcpdump -xXvvv -w temp.cap -s 1500 -i l0

If you want to run the code on two linux boxes, you will need to modify the ip address in mme.c. Find the below section in code and change 127.0.0.1 to ip address on which sgw is running.

ggsn.sin_family=AF_INET;

ggsn.sin_port=htons(2123);

ggsn.sin_addr.s_addr=inet_addr("127.0.0.1");

Thats it. Run the programs and capture the packets. You should see all the messages mentioned above. You will need latest development version of wireshark to view the messages. Get it here. Note that wireshark still doesnt dissect the messages completely. Atleast you can see the IE's.

Know limitations : Messages contains IE's which are mandatory and conditional to S11 interface. Create session request doesnt send ULI IE. All the values used in the code are dummy.

I will keep building this code for new messages (mobility next).

There it is guys, have fun and do let me know how it looks. Any changes or suggestions are always welcome.   

Update: Guys, I started a project in google code for this. The code is uploaded there (Look at downloads section). Uploading the code in rapidshare was the most dumbest idea. Rapidshare! for uploading the code? Dah! I must have been really stupid.

Link : http://code.google.com/p/s11interface/

Download it, use it or do what ever you feel like. I have published to code under GNU GPL license. I will keep posting the code in download sections and if you want to share anything(patches) feel free to send it to me. I would be happy to update the patch in source. If any body want to be part of administering let me know. I really have no time to manage it, so I am not looking at version control and stuff.

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.

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.

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.

LTE Attach Procedure

At last I found what I needed. It was always there since beginning but I never found time to read it. So I went through the spec TS 23.401 (GPRS enhancements for EUTRAN) and I found all the call flows required. I started with the initial on, EUTRAN Initial Attach procedure. Now my interests lie in GTP based interfaces (I am avoiding PMIP here) and only on IP side. So I eliminate all the radio signals, S1- MME request response and what I arrive at is the below. A simple diagram depicting initial attach procedure of UE.

  

A UE needs to register with the network to receive services that require registration. This registration is described as network attachment. The always on IP connectivity for UE of the EPS is enabled by establishing a default EPS bearer during Network attachment. The attach procedure may trigger one or multiple dedicated bearer establishment procedures to establish dedicated EPS bearer for that UE. During the attach procedure UE may request for an IP address allocation.

Now lets look at the request/responses and the IE;s that are passed in them. As I said, I am not much of radio guy I will directly jump into

3. Create Default Bearer Request: MME ----> S-GW

MME selects a S-GW and allocate an EPS bearer Identity for default bearer associated with UE. Then it sends Create Default Bearer Request with following IE;s.

• IMSI
• MSISDN
• MME TEID for Control Plane
• PDN GW address
• PDN Address
• APN
• RAT Type
• Default EPS bearer QoS
• PDN Type
• APN-AMBR
• EPS Bearer Identity (EBI)
• Protocol COnfiguration Options
• Handover Indication
• ME identity
• User Location Information (ECGI)
• MS Info Change Reporting Support Indication
• Selection Mode
• Charging Characteristics
• Trace Reference
• Trace Type
• Trigger ID
• OMC identity
• Maximum APN Restriction
• Dual Address Bearer Flag
• Protocol over S5/S8.

Subscribed APN AMBR for the APN is provided in this message. MSISDN is included if the attach type indicates handover. Selection Mode indicates that a subscribed APN was selected. Charging characteristics indicates which kind of charging the bearer context is liable for.

4. Create Default Bearer Request : S-GW -------->PDN-GW

The S-GW creates a new entry in its EPS bearer table and sends a create default bearer request message to PDN GW indicated by the PDN GW address received in the previous step. This message contains

• IMSI
• MSISDN
• APN
• S-GW address for User Plane
• S-GW TEID of the User Plane
• S-GW TEID of the Control plane
• RAT Type
• Default EPS bearer QoS
• PDN Type
• PDN Address
• Subscribed APN-AMBR
• EPS bearer identity
• Protocol Configuration Options
• Handover Indication
• ME Identity
• USer Location Information (ECGI)
• MS Info change Reporting SUpport Indication
• Selection Mode
• Charging Characteristics
• Trace Reference
• Trace Type
• Trigger ID
• OMC Identity
• Max APN Restriction
• Dual Address Bearer Flag.

5. Create Default Bearer Response : PDN-GW ------> S-GW

The P-GW creates a new entry in its EPS bearer context table and generates a charging ID. THe new entry allows the P-GW to route user plane PDU's between the S-GW and the packet data network and to start charging. The PDN-GW returns a create default bearer response with following IE's

• PDN-GW address for the user plane
• PDN GW TEID of the user plane
• PDN GW TEID of the control plane
• PDN Type
• PDN address
• EPS Bearer Identity
• EPS bearer QoS
• Protocol Configuration Options
• Charging ID
• Prohibit payload compression
• APN Restriction
• Cause
• MS Info Change Reporting Action
• APN AMBR

6. Create Default Bearer Response : S-GW --------> MME

S-GW returns a create default bearer response to MME with following IE's.

• PDN Type
• PDN Address
• S-GW address for User Plane
• S-GW TEID for User Plane
• S-GW TEID for control plane
• EPS bearer Identity
• EPS bearer QoS
• PDN GW addresses and TEID's at the PDN GW for uplink traffic
• Protocol configuration options
• Charging ID
• Prohibit payload compression
• APN restriction
• Cause
• MS Info change Reporting Action
• APN-AMBR

These are the Default bearer request and response messages. Watch out more messages.

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.