What is GTP¶

GTP is the Generic Tunnel Protocol, which is a 3GPP protocol used fortunneling User-IP payload between a mobile station (phone, modem)and the interconnection between an external packet data network (suchas the internet).

So when you start a ‘data connection’ from your mobile phone, thephone will use the control plane to signal for the establishment ofsuch a tunnel between that external data network and the phone. Thetunnel endpoints thus reside on the phone and in the gateway. Allintermediate nodes just transport the encapsulated packet.

The phone itself does not implement GTP but uses some othertechnology-dependent protocol stack for transmitting the user IPpayload, such as LLC/SNDCP/RLC/MAC.

At some network element inside the cellular operator infrastructure(SGSN in case of GPRS/EGPRS or classic UMTS, hNodeB in case of a 3Gfemtocell, eNodeB in case of 4G/LTE), the cellular protocol stackingis translated into GTPwithout breaking the end-to-end tunnel. Sointermediate nodes just perform some specific relay function.

At some point the GTP packet ends up on the so-called GGSN (GSM/UMTS)or P-GW (LTE), which terminates the tunnel, decapsulates the packetand forwards it onto an external packet data network. This can bepublic internet, but can also be any private IP network (or eventheoretically some non-IP network like X.25).

You can find the protocol specification in 3GPP TS 29.060, availablepublicly via the 3GPP website athttp://www.3gpp.org/DynaReport/29060.htm

A direct PDF link to v13.6.0 is provided for convenience below:http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/13.06.00_60/ts_129060v130600p.pdf

The Linux GTP tunnelling module¶

The module implements the function of a tunnel endpoint, i.e. it isable to decapsulate tunneled IP packets in the uplink originated bythe phone, and encapsulate raw IP packets received from the externalpacket network in downlink towards the phone.

Itonly implements the so-called ‘user plane’, carrying the User-IPpayload, called GTP-U. It does not implement the ‘control plane’,which is a signaling protocol used for establishment and teardown ofGTP tunnels (GTP-C).

So in order to have a working GGSN/P-GW setup, you will need auserspace program that implements the GTP-C protocol and which thenuses the netlink interface provided by the GTP-U module in the kernelto configure the kernel module.

This split architecture follows the tunneling modules of otherprotocols, e.g. PPPoE or L2TP, where you also run a userspace daemonto handle the tunnel establishment, authentication etc. and only thedata plane is accelerated inside the kernel.

Don’t be confused by terminology: The GTP User Plane goes throughkernel accelerated path, while the GTP Control Plane goes toUserspace :)

The official homepage of the module is athttps://osmocom.org/projects/linux-kernel-gtp-u/wiki

Userspace Programs with Linux Kernel GTP-U support¶

At the time of this writing, there are at least two Free Softwareimplementations that implement GTP-C and can use the netlink interfaceto make use of the Linux kernel GTP-U support:

• OpenGGSN (classic 2G/3G GGSN in C):https://osmocom.org/projects/openggsn/wiki/OpenGGSN
• ergw (GGSN + P-GW in Erlang):https://github.com/travelping/ergw

Userspace Library / Command Line Utilities¶

There is a userspace library called ‘libgtpnl’ which is based onlibmnl and which implements a C-language API towards the netlinkinterface provided by the Kernel GTP module:

http://git.osmocom.org/libgtpnl/

Protocol Versions¶

There are two different versions of GTP-U: v0 [GSM TS 09.60] and v1[3GPP TS 29.281]. Both are implemented in the Kernel GTP module.Version 0 is a legacy version, and deprecated from recent 3GPPspecifications.

GTP-U uses UDP for transporting PDUs. The receiving UDP port is 2151for GTPv1-U and 3386 for GTPv0-U.

There are three versions of GTP-C: v0, v1, and v2. As the kerneldoesn’t implement GTP-C, we don’t have to worry about this. It’s theresponsibility of the control plane implementation in userspace toimplement that.

IPv6¶

The 3GPP specifications indicate either IPv4 or IPv6 can be used bothon the inner (user) IP layer, or on the outer (transport) layer.

Unfortunately, the Kernel module currently supports IPv6 neither forthe User IP payload, nor for the outer IP layer. Patches or otherContributions to fix this are most welcome!

Mailing List¶

If you have questions regarding how to use the Kernel GTP module fromyour own software, or want to contribute to the code, please use theosmocom-net-grps mailing list for related discussion. The list can bereached atosmocom-net-gprs@lists.osmocom.org and the mailmaninterface for managing your subscription is athttps://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs

Issue Tracker¶

The Osmocom project maintains an issue tracker for the Kernel GTP-Umodule athttps://osmocom.org/projects/linux-kernel-gtp-u/issues

History / Acknowledgements¶

The Module was originally created in 2012 by Harald Welte, but nevercompleted. Pablo came in to finish the mess Harald left behind. Butdoe to a lack of user interest, it never got merged.

In 2015, Andreas Schultz came to the rescue and fixed lots more bugs,extended it with new features and finally pushed all of us to get itmainline, where it was merged in 4.7.0.

Architectural Details¶

The TEID in the GTP-U header is used to de-multiplex trafficincoming from remote tunnel endpoints so that it is delivered to theUser plane entities in a way that allows multiplexing of differentusers, different packet protocols and different QoS levels.Therefore no two remote GTP-U endpoints shall send traffic to aGTP-U protocol entity using the same TEID value exceptfor data forwarding as part of mobility procedures.

APN vs. Network Device¶

The GTP-U driver creates a Linux network device for each Gi/SGiinterface.

[3GPP TS 29.281] calls the Gi/SGi reference point an interface. Thismay lead to the impression that the GGSN/P-GW can have only one suchinterface.

Correct is that the Gi/SGi reference point defines the interworkingbetween +the 3GPP packet domain (PDN) based on GTP-U tunnel and IPbased networks.

There is no provision in any of the 3GPP documents that limits thenumber of Gi/SGi interfaces implemented by a GGSN/P-GW.

[3GPP TS 29.061] Section 11.3 makes it clear that the selection of aspecific Gi/SGi interfaces is made through the Access Point Name(APN):

2. each private network manages its own addressing. In general this   will result in different private networks having overlapping   address ranges. A logically separate connection (e.g. an IP in IP   tunnel or layer 2 virtual circuit) is used between the GGSN/P-GW   and each private network.   In this case the IP address alone is not necessarily unique.  The   pair of values, Access Point Name (APN) and IPv4 address and/or   IPv6 prefixes, is unique.

In order to support the overlapping address range use case, each APNis mapped to a separate Gi/SGi interface (network device).

Therefore for a given UE the mapping in IP to PDN network is:

• network device + MS IP -> Peer IP + Peer TEID,

and from PDN to IP network:

• local GTP-U IP + TEID -> network device

Furthermore, before a received T-PDU is injected into the networkdevice the MS IP is checked against the IP recorded in PDP context.