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.

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.

PCRF Diameter Server

This is an application that I’ve made in 2009, that implements a PCRF Diameter Server (Gx interface towards a GGSN/PCEF). 

With this application it’s possible to install and remove Charging Rules in the PCEF. These changes can be made in the CCA or through the RAR mechanism. 

The presence of several AVPs can be also be parameterized.

This app was built based on the OCS Diameter Server app, and was quickly finished (less than a week). 

It can be used to test all the functionalities and behaviours of a PCEF, before doing for example a RFQ/RFP for a PCRF.

I've done recently several upgrades to this app.

The first one, was adding the possibility to define in which answers the AVP Charging-Rule-Install/Remove are sent.

The second big change, was adding a text box in which we can write the AVPs we want to send in the CCA/RAR messages.
The format is the following:

avp,<avp code>,<avp bits>,<vendor id>,<avp type>,<avp value/avp length (for grouped AVPs)>

Example:

#Bearer-Control-Mode
avp,1023,192,10415,32,2

#QOS-information
avp,1016,192,10415,g,44
avp,1040,128,10415,32,2000000
avp,1041,128,10415,32,500000

OCS Diameter Server

This is one of my favourite applications, that I’ve started doing in 2007. It’s an OCS Server (Gy interface towards the GGSN) that is used to do the online charging control of data sessions. Many features have been added along the last years. 

The options that I’ve been incorporating in this application can be used to test almost every scenario that an operator may want to test.

 

Many GGSN fault reports were opened by using this app and many new features could be tested ahead of the developments in the productions OCSs.

Many awkward scenarios can be easily reproduced.

I’ve also incorporated an interface towards an Access Database that implements a rating structure in order to have different behaviours dependent on the subscriber.

Another feature of this app is that it can analyse DIAMETER traces (in cap/pcap format). After processing the file, It then presents all DCCA sessions that are in the trace, with all the ServiceId/RatingGroups CCR/CCA metering per session (total and individually per CCR/CCA).

This information can be exported to a text file, and easily imported to an Excel sheet or any Database for post processing.

The application has information about each CCR received, for each session:

I’ve added also a log tool to easy the analysis of any DIAMETER message or AVP, in case we don’t want to do a trace.