SoftGGSN for Raspberry Pi

One application that I’ve done some years ago was a GTP dialer for Linux/OSX OS. It’s an application that basically creates a GTP tunnel with a GGSN, and then the IP received in the CreatePDPContext Response is set as tunnel interface in the machine. After that we set the default route to the tunnel interface (keeping always a /32 route for the tunnel endpoint towards the previous default gateway) and we can use the GTP tunnel to send and receive traffic from the internet, or to whatever networks the APN give us connectivity.

It’s different from my SGSN/MME/SGW Emulator because that tool is focused on the control plane side of things, while the GTP dialer is just like a VPN dialer, and the focus is the user plane.

It’s very useful to perform service tests in the GGSN/PGW, since we can use any application in the laptop (ex. web browser), and it also supports all PDP Types (IPv4, IPv6 or IPv4v6).

I have a Raspberry in my house and I was thinking in doing some kind of http/https proxy or implementing some tunneling protocol just to be able to access the internet using my home IP. This way I could for example, use services that are only available in my home country when I’m abroad.

Then I notice that I already had this GTP dialer that is in its own way a tunneling mechanism…. So I come up with the following idea:

What if I do a simple GGSN in my Raspberry Pi that could be used with my GTP dialer? I can be anywhere in the world with my laptop, connected to a Wlan or Ethernet network, and as long I have internet access, I can connect and establish a GTP tunnel to my Raspberry Pi in my house, which will give me a private IP from my internal network, and then all the traffic from my laptop will be sent encapsulated in GTP to the Raspberry IP, and then stripped and NATted in my Home Gateway (HGW) to the internet?

Sounds easy, right?

After this initial idea, I thought that I could extend it and allow more than one connection at the same time (multiple PDPs from different clients), and using DHCP for IP address allocation in the HGW. For example my internal network is the usual 192.168.1.0/24. Most of these addresses are available in the DHCP server of my HGW to be assigned to machines that use my Wlan or Ethernet network. I have a 200Mbits WAN connection to my service provider, but the Raspberry Pi is connected via Ethernet cable with a 100Mbits speed, so I think that up to 10 connections could have a decent bandwidth.

There are several technical issues that need to be addressed:

• If the Raspberry Pi uses its MAC address for all these communications, the DHCP server will assign always the same IP address, so for each one of these PDP requests arriving at the Raspberry Pi, a different MAC address should be used, so that the HGW assigns a different IPs. To forge these MAC addresses, we need a RAW socket for the uplink packets and a RAW socket in promiscuous mode for the downlink packets, since the Raspberry Pi needs to listen and process the packets sent by the HGW to these fictitious MAC addresses.

• The Raspberry needs to track all ARP requests in internal LAN, since it must answers in behalf of all internal IP assigned to the current active PDP sessions, and answer those ARP Request with the correct MAC Address. This can be done with a RAW socket in promiscuous mode.

• The Raspberry Pi needs to track the DHCP timers for all IPs assigned to the PDP sessions. It needs to renew the IP at half the lease time if the PDP is still up, and release the IP when the PDP is deleted.

• Port forwarding for GTP-C and GTP-U must be configured in the HGW (e.g. UDP ports 2123 and 2152)

• The GTP dialer, can be behind a NAT device. In the normal GTP-U operation, uplink packets from a SGSN are sent to UDP port 2152 in the GGSN, and downlink packets are sent from the GGSN to the UDP Port 2152 in the SGSN, and the source port can be any port. This can be problematic, because port 2152 could not be open in the NAT, or if it’s open, it can be assigned to a different internal client that is also behind the same NAT device. To overcome this, the GGSN can detect if the client is behind a NAT by comparing the source IP with the GSN IP Address for Control and Data received in the CreatePDPContext Request message. If they are different, then the client is behind a NAT device, so the GGSN instead of sending the downlink GTP-U packets to UDP port 2152, it will send it to the source port of the GTP-U packets coming from the GTP dialer. Since the GTP dialer uses UDP port 2152 as source port for all uplink GTP-U packets, the NAT translation will guarantee that all downlink packets sent by the GGSN to the source port previously received in the uplink GTP-U packets, will be delivered to the GTP dialer. Since this traffic is UDP, the translation timeout is usually small (5 minutes). So we have the risk that this translation expires, and a new source port is assigned later on. To overcome this, the GGSN needs to always compare the GTP-U source port of the uplink packets, and if it’s different, it should update it in the session table.

The control plane flow for each session establishing is the following:

Next picture, shows the user plane flow of an uplink packet:

You can check this trace that I took in the Raspberry Pi of a session where you can see all these flows.

MME/SGW/SGSN GTPv2 Emulator

This is a new application that I've done recently, that is an evolution from the GTP Emulator that was only GTPv1.

I started to implement only the interface S5/S8 to interact with the PGW, but later on I also added the MME interface S11 and SGSN interface S4 towards the SGW.

This application has the following main interface:

This tab has the SGSN Gn part like the previous GTP Emulator App, with the addition of the UpdatePDPContext message, the SGW part with four GTPcV2 messages, and the MME/SGSN part with five GTPcV2 messages, but for nine types of procedures.

The App is ready to answer to CreateBearerRequest or UpdateBearerRequest sent from the PGW/SGW, even with DedicatedBearers (and with several bearers at the same time), and generally speaking, any message originated from the PGW or SGW nodes (DataDownlinkNotification, DeleteBearerRequest).

In the second tab of this app we have the QOS part, which is the same tab of the GTP Emulator App, plus the 4G part:

In this tab I added also the PCO bytes to send in the CreatePDPContext or CreateSessionRequest, mainly due the lack of space in the main tab.

The third tab is a Log, which shows some relevant information form the messages sent and receive. Here is an example:

The fourth tab is one of the most interesting ones. Is the test tab.

This part of the application allow us to do the following things using some specific CLI that I've created:

• Send any of the supported messages
• Set some specific parameters like QOS, Comon Flags, RAT Type, CGI/SAI/EGCI in these messages
• Set the IPs of the PGW or SGW for the following tests
• Set specific parameters (like the QOS or Event-Triggers) in other two Apps that I also have (OCS and PCRF Server), using an UDP interface and protocol that I've develop specific for this feature

For example the test presented in this next image is the Creation, Update and Delete of PDP Contexts, using different QOS, and different Common Flags values, to test all the possible combinations of a scenario that I needed to test:

Without this app, some of the combinations were impractical to reproduce and some would take a big amount of time. With this app, it toked less than one minute. Just check this cap file of the test above.

For example it's so easy to start a session in 4G, do an update to 3G, then an update to 2G, then an update to 4G, and so on, setting all the parameters accordingly. Things that in real live networks, using real terminals are very hard to achieve, and take lots, and lots of time.

With this tool: just seconds!

Again, this type of tools allow us to set non standard messages just to see how the nodes react to erroneous messages.

GTP Emulator

Due to some requests I have received over the last weeks, I made some changes in the SGSN Emulator application, and just strip it to a simple GTP tool to create and delete PDP contexts, and adding the possibility to insert and setting in the GTP message the most used Information Elements (IE).

This tool has the following interface:

I have kept the same QOS front-end of the SGSN Emulator application, since this can be very useful to test the creation of PDP with any QOS we want:

This tool can be tested using the demo version I have made. 

This demo has some limitations (only mandatory IE, only QOS R97/98 and only one Create/Delete PDPContext a time) but it's fully functional.

GTP Emulator - Demo Version

SGSN Emulator

This is an application that I’ve made in 2010. This application is an emulation of the Gn interface of a SGSN (according to 3GPP 29.060).

It implements GTPv1, mainly the control part GTP-C. In terms of user plane, it accepts GTP-U in the downlink direction, and also implements the echo response mechanism in order to preserve the GTP tunnels.

This app can be used to test every GTP parameter in a CreatePDPContextRequest. I’ve made only options for dynamically setting the QOS Profile, Rat Type and Selection Mode parameters, but other information elements can be easily added (or removed). This way you can test the behaviour of the GGSN in the presence or absence of specific information elements (mandatory or optional), or the presence of specific parameter values in order to reproduce whatever scenarios an operator may want (example: Roaming, interworking between different vendors, reproducing failure scenarios, etc…)

With this application it’s possible to create and delete PDPs dynamically.

It’s possible to define:

• the rate at which the PDPs are created and deleted (the rates can be different);
• the APNs that are sent in the CreatePDPContextRequest;
• the total number of PDPs to create per APN;
• the duration of each PDP per APN;
• the GGSN IP address for each APN;
• the IMSI Range to be used;
• the GTP-C and GTP-U address of the SGSN;
• the daily working interval, and weekdays to start the creation and deletion of the PDPs

During running time it’s possible to check how many PDPs are currently active per APN, and access individual PDP Context information like the ChargingID, or the  EndUserAddress for each IMSI/MSISDN/NSAPI.

The application also provides statistical information in real-time and also cumulative counters for GTP messages and causes received in responses:

The main goal of this application it’s to test the GGSN behaviour under harsh conditions, since we can set a very high creation and deletion signalling rates. 

We can also test other signalling components if they are involved in the activation or deactivation of a specific APN/PDP without having to actually be generating real traffic from the network:

- Gx interface (i.e. PCRF)

- Radius

- Gy interface (i.e. OCS)

- Ga interface (i.e. generation/closure of CDRs for offline billing)

I have made a simpler tool that has some of these functionalities. 
Please check it GTP Emulator.