Sunday, July 12, 2009

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.

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...

HiYou should have a look at this projecthttp://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

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?

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!!!

About Me

Networking Geek. Eating, sleeping and walking LTE. Testing is profession but always fascinated by a colourful C code in Vi editor on linux box. Interests are 3G/4G, Wimax, IP routing/switching, Mobile phones, music and ofcourse blogging.
And yeah, what ever I write in this blog is strictly my view and not of my employers!