GPRS Tunnelling Protocol
GPRS Tunnelling Protocol
GPRS Tunnelling Protocol
General Packet Radio Service (GPRS) within GSM, UMTS and LTE networks.
GTP can be decomposed into separate protocols, GTP-C, GTP-U and GTP'. GTP-C is used within
the GPRS core network for signaling between Gateway GPRS Support Nodes (GGSN) and Serving
GPRS Support Nodes (SGSN). This allows the SGSN to activate a session on a user's behalf (PDP
context activation), to deactivate the same session, to adjust quality of service parameters, or to update a
session for a subscriber who has just arrived from another SGSN.
GTP-U is used for carrying user data within the GPRS Core Network and between the Radio Access
Network and the core network. The user data transported can be packets in any of IPv4,IPv6,
or PPP formats.
GTP' (GTP prime) uses the same message structure as GTP-C and GTP-U, but has an independent
function. It can be used for carrying charging data from the Charging Data Function (CDF) of the GSM or
UMTS network to the Charging Gateway Function (CGF). In most cases, this should mean from many
individual network elements such as the GGSNs to a centralized computer that delivers the charging data
more conveniently to the network operator's billing center.
Different GTP variants are implemented by RNCs, SGSNs, GGSNs and CGFs within 3GPP networks.
GPRS mobile stations (MSs) are connected to a SGSN without being aware of GTP.
GTP can be used with UDP or TCP. UDP is either recommended or mandatory, except for
tunnelling X.25 in version 0. GTP version one is used only on UDP.
General features
All variants of GTP have certain features in common. The structure of
the messages is the same, with a GTP header following the UDP/TCP
header.
[edit]Header
[edit]GTP version 1
32 TEID
Next extension
64 Sequence number N-PDU number
header type
Version
It is a 3-bit field. For GTPv1, this has a value of 1.
Protocol Type (PT)
a 1-bit value that differentiates GTP (value 1) from GTP' (value 0).
Reserved
a 1-bit reserved field (must be 0).
Extension header flag(E)
a 1-bit value that states whether there is an extension header
optional field.
Sequence number flag(S)
a 1-bit value that states whether there is a Sequence Number
optional field.
N-PDU number flag(PN)
a 1-bit value that states whether there is a N-PDU number optional
field.
Message Type
an 8-bit field that indicates the type of GTP message.
Length
a 16-bit field that indicates the length of the payload in bytes (rest
of the packet following the mandatory 8-byte GTP header).
Includes the optional fields.
Tunnel endpoint identifier (TEID)
A 32-bit(4-octet) field used to multiplex different connections in the
same GTP tunnel.
Sequence number
an (optional) 16-bit field. This field exists if any of the E, S, or PN
bits are on. The field must be interpreted only if the S bit is on.
N-PDU number
an (optional) 8-bit field. This field exists if any of the E, S, or PN
bits are on. The field must be interpreted only if the PN bit is on.
Next extension header type
an (optional) 8-bit field. This field exists if any of the E, S, or PN
bits are on. The field must be interpreted only if the E bit is on.
Next Extension Headers
are as follows:
... ...
Next
... Contents extension
header
Length
an 8-bit field. This field states the length of this extension header,
including the length, the contents, and the next extension header
field, in 4-octet units. The length must be a multiple of 4.
Contents
extension header contents.
Next extension header
an 8-bit field. It states the type of the next extension, or 0 if no next
extension exists. This permits chaining several next extension
headers.
[edit]GTP version 2
Message
0 Version Piggybacking flag (P) TEID flag (T) Spare Total length
Type
32 TEID (only present if T=1)
64 (32 if
TEID not Sequence number Spare
present)
Piggybacking
flag
If this bit is set to 1 then another GTP-C message with its own
header shall be present at the end of the current message. There
are restrictions as to what type of message can be piggybacked
depending on what the toplevel GTP-C message is.
TEID flag
If this bit is set to 1 then the TEID field will be present between the
message length and the sequence number. All messages except
Echo and Echo reply require TEID to be present.
edit]Connectivity mechanisms
Apart from the common message structure, there is also a common
mechanism for verifying connectivity from one GSN to another GSN.
This uses two messages.
echo request
echo response
As often as every 60 seconds, a GSN can send an echo request to
every other GSN with which it has an active connection. If the other
end does not respond it can be treated as down and active connections
to it deleted.
Apart from the two messages previously mentioned, there are no other
messages common across all GTP variants[3] meaning that, for the
most part, they effectively form three completely separate protocols.
[edit]GTP-C - GTP control
The GTP-C protocol is the control section of the GTP standard. When
a subscriber requests a PDP context, the SGSN will send a create PDP
context request GTP-C message to the GGSN giving details of the
subscriber's request. The GGSN will then respond with a create PDP
context response GTP-C message which will either give details of the
PDP context actually activated or will indicate a failure and give a
reason for that failure. This is a UDP message on port 2123.
The GTP-C protocol is responsible for creating, maintaining and
deleting tunnels on multiple Sx interfaces. It is used for the control
plane path management, tunnel management and mobility
management. It also controls forwarding relocation messages; SRNS
context and creating forward tunnels during inter LTE handovers.
GTP-U for transfer of user data in separated tunnels for each PDP
context
GTP-C for control reasons including:
setup and deletion of PDP contexts
verification of GSN reachability
updates; e.g., as subscribers move from one SGSN to
another.
GTP' for transfer of charging data from GSNs to the charging
function.
GGSNs and SGSNs (collectively known as GSNs) listen for GTP-C
messages on UDP port 2123 and for GTP-U messages on port 2152.
This communication happens within a single network or may, in the
case of international roaming, happen internationally, probably across
aGPRS roaming exchange (GRX).
The Charging Gateway Function (CGF) listens to GTP' messages sent
from the GSNs on TCP/UDP port 3386. The core network sends
charging information to the CGF, typically including PDP context
activation times and the quantity of data which the end user has
transferred. However, this communication which occurs within one
network is less standardized and may, depending on the vendor and
configuration options, use proprietary encoding or even an entirely
proprietary system.
[edit]Use on the IuPS interface
GTP-U is used on the IuPS between the GPRS core network and the
RAN, however the GTP-C protocol is not used. In this case, RANAP is
used as a control protocol and establishes GTP-U tunnels between the
SGSN and the radio network controller (RNC).
[edit]
Protocol stack
????
IP (user)
GTP
UDP
IP
GTP can be used with UDP or TCP. GTP version one is used only on UDP.
As of 2004 there are two versions defined, version 0 and version 1. Version 0 and version 1 differ
considerably in structure. In version 0, the signalling protocol (the protocol which sets up the tunnels by
activating the PDP context) is combined with the tunneling protocol on one port. Version 1 is actually
effectively two protocols, one for control (called GTP-C) and one for userdata tunneling (called GTP-U).
GTP-U is also used to transport user data from the RNC to the SGSN in UMTS networks. However, in
this case signalling is done using RANAP instead of GTP-C.
The non-random TEID in version 0 represented a security problem if an attacker had access to any
roaming partner's network, or could find some other way to remotely send packets to the GPRS
backbone. Version 0 is going out of use and being replaced by version 1 in almost all networks. Even so,
the standard for the newer version states that the older version must be supported by the GSN.
Fortunately, however the use of different port numbers allows easy blocking of version 0 through simple
IP access lists.
[edit]GTP standardization
GTP was originally standardized within ETSI (GSM standard 09.60). With the creation of the UMTS
standards this was moved over to the3GPP which, as of 2005 maintains it as 3GPP standard 29.060.
GTP' uses the same message format, but its special uses are covered in standard 32.295 along with the
standardized formats for the charging data it transfers.
Later versions of TS 29.060 deprecate GTPv1/v0 interworking such that there is no fallback in the event
that the GSN does not support the higher version.
GTPv2 (for evolved packet services) went into draft in early 2008 and was released in December of that
year. GTPv2 offers fallback to GTPv1 via the earlier "Version Not Supported" mechanism but explicitly
offers no support for fallback to GTPv0.
[edit]See also
Proxy Mobile IP
Mobile IP
[edit]Notes