Sunday, July 12, 2009

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.

9 comments:

Fredrik said...

Hi
You should have a look at this project
http://sourceforge.net/projects/ggsn/
It seems to be quite dead, but have a very nice codebase to extend.
I've been looking at there gtpv1 code in order to extend it with gtpv2 support, but havent got the time for it yeat.....
Br
//Fredrik

Santosh Dornal said...

Yup, that looks good. I am still unable to figure out to which release OpenGGSN is build to support. Release 7?

DJ said...

Hi Santosh,

These blogs are pretty good start for a engineer like me who is new to the field.... Good job.
I have few questions related to the System Simulator settings when we do conformance tests. What should be the optimum reference signal level when we do a data throughput test on a UE? What are the Noise power levels that we need to consider? Can you please guide me?

Thanks
Deepa

Santosh Dornal said...

Hi Deepa

Iam dump and only understand things which flow on wire and has an IP address. :)

To answer you all I can think of is 36 series specs. I remember I saw a spec fo UE conformance tests. That should help. (3GPP TS 36.521)

Out of curiosity:- how much throughput could you get out of UE in your tests?

Santosh

Anonymous said...

Hi,

tried out the code on windows (under cygwin). I had to change strnlen to strlen on line 36 of mme.c.

Maybe you should post to some code hosting sites (like google code or github.com) so other people can easily see individual files and send you patches...

--Amit

Santosh Dornal said...

Sweet idea Amit! Thanks!

I am looking at google code now. I have enhanced the code a bit and will post the new version soon. The idea is to code most of the call scenarios from 3GPP TS 23.401.

Jonas Nylund said...

Have you thought about actualy add support for communication with a real PDN-GW.

Im currenlty looking for a way to simulate clients towards the PDN-GW.

Santosh Dornal said...

No plans right now! :-(

anonymousT said...

@DEEPA


basically when doing simulatuion based testing.... try different sets of test for each burst profile starting from those 64 qams to 16 qams. Determine theoratical throughput based on the solution and compare it with each of the above results!!! There shouldn't be any bottlenecks and vary the time for the throughput test so that u find any possible leaks in the code!

gradually test could be designed which involves mobility scenario with different burst profile tested.... see how the control plane traffic(for each bp change event) affects the performance!!!Also see to that user plane traffic does not face any drops!!

And naturally for real solutions its not possible to do all the above unless u have those sophisticated equipments which simulate radio conditions!!

basic thumb rule have a set of basic test cases called regression t.c's which should always pass with every new release of software irrespective of how big the change is and then move on to test complex real time scenarios!!!