GPRS Tunnelling Protocol
From Wikipedia, the free encyclopedia
| The five-layer TCP/IP model |
|---|
| 5. Application layer |
|
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · RTP · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS (and SSL) · SDP · SOAP · GTP · STUN · NTP · (more) |
| 4. Transport layer |
| TCP · UDP · DCCP · SCTP · RSVP · ECN · (more) |
| 3. Network/internet layer |
| IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · IPsec · ARP · RARP · RIP · ICMP · ICMPv6 · IGMP · (more) |
| 2. Data link layer |
| 802.11 (WLAN) · 802.16 · Wi-Fi · WiMAX · ATM · DTM · Token ring · Ethernet · FDDI · Frame Relay · GPRS · EVDO · HSPA · HDLC · PPP · PPTP · L2TP · ISDN · ARCnet · LLTD · (more) |
| 1. Physical layer |
| Ethernet physical layer · RS-232 · SONET/SDH · G.709 · Optical fiber · Coaxial cable · Twisted pair · (more) |
GPRS Tunneling Protocol (or GTP) is an IP based protocol used within GSM and UMTS networks. It can be used with UDP or TCP. GTP version one is used only on UDP. There are in fact three separate protocols, GTP-C, GTP-U and GTP'.
GTP-C is used within the GPRS core network for signalling between GPRS Support Nodes (GGSNs and SGSNs). This allows the SGSN to activate a session on the users 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 it is largely a completely separate protocol. It can be used for carrying charging data from the "Charging Data Function" of the GSM or UMTS network to the "Charging Gateway Function". In most cases, this should mean from many individual network elements such as the GGSNs to a centralised computer which then delivers the charging data more conveniently to the network operator's billing center.
Contents |
[edit] General Features of the GTP protocol
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
GTPv1 headers contain the following fields
| + | Bits 0-2 | 3 | 4 | 5 | 6 | 7 | 8-15 | 16-23 | 24-31 | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Version | Protocol Type | Reserved | Next Extension Header | Sequence Number | N-PDU Number | Type | Total Length | ||||||||||||||||||||||||
| 32 | TEID | |||||||||||||||||||||||||||||||
| 64 | Sequence Number | N-PDU number | Next Extension Header | |||||||||||||||||||||||||||||
- Version
- The first header field in a GTP packet is the 3-bit version field. For GTPv1, this has a value of 1 (hence the name GTPv1).
- 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 (E)
- a 1-bit value that states whether there is an Extension Header optional field.
- Sequence Number (S)
- a 1-bit value that states whether there is a Sequence Number optional field.
- N-PDU number (PN)
- a 1-bit value that states whether there is a N-PDU number optional field.
- Type
- A 8-bit field that states the packet type.
- Length
- A 16-bit field that states the length of the packet being encapsulated by GTP (not including the GTP header itself, but including the optional fields).
- Tunnel Endpoint Identifier (TEID)
- A 32-bit 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
- 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:
| + | Bits 1-7 | 8-23 | 24-31 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Total Length | Contents | ||||||||||||||||||||||||||||||
| ... | ... | |||||||||||||||||||||||||||||||
| ... | Contents | Next 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] Connectivity Mechanisms
Apart from the common message structure, there is also a common mechanism for verifying connectivity from GSN to GSN. This uses two messages.
- echo request
- echo response
As often as every 60 seconds, a GSN can send an echo request to each 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 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.
[edit] GTP-U - GTP User Data Tunnelling
GTP-U is, in effect a relatively simple IP based tunnelling protocol which permits many tunnels between each set of end points. When used in the UMTS, each subscriber will have one or more tunnel, one for each PDP context they have active plus, possibly separate tunnels for specific connections with different Quality of service requirements.
The separate tunnels are identified by a TEID (Tunnel Endpoint Identifier) in the GTP-U messages, which should be a dynamically allocated random number. If this random number is of cryptographic quality, then it will provide a measure of security against certain attacks. Even so, the requirement of the 3GPP standard is that all GTP traffic, including user data should be sent within secure private networks, not directly connected to the Internet.
[edit] GTP' - Charging Transfer
The GTP' (pronounced GTP prime) protocol is used to transfer charging data to the Charging Gateway Function. GTP' uses TCP/UDP port 3386.
[edit] Within the GPRS Core Network
- see also GPRS Core Network
GTP is the primary protocol used in the GPRS core network. It is the protocol which allows end users of a GSM or UMTS network to move from place to place whilst continuing to connect to the Internet as if from one location at the GGSN. It does this by carrying the subscriber's data from the subscriber's current SGSN to the GGSN which is handling the subscriber's session. Three forms of GTP are used by the GPRS core network.
- 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 a GPRS Roaming Exchange (GRX).
The "Charging Gateway Function" (CGF) listens to GTP' messages sent from the GSNs on 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 standardised 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 Radio Access Network, 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 RNC.
[edit] Protocol Stack
| ???? |
| IP (user) |
| GTP |
| UDP |
| IP |
| Layer 2 (e.g. WAN or Ethernet) |
GTP-U Protocol Stack |
All variations of GTP are transported over 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 tunnelling protocol on one port. Version 1 is actually effectively two protocols, one for control (called GTP-C) and one for user data tunnelling (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.
[edit] Historical GTP Versions
The original version of GTP (version 0) had considerable differences from the current version (version 1).
- the tunnel identification was non random
- options were provided for transporting X.25
- the fixed port number 3386 was used for all functions (not just charging as in GTPv1).
- TCP was allowed as a transport option instead of UDP, but support for this was optional
- subscription related fields such as Quality of Service were more limited
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 in standardisation
GTP was originally standardised within ETSI (GSM standard 09.60). With the creation of the UMTS standards this was moved over to the 3GPP 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 standardised formats for the charging data it transfers.
[edit] Notes
- ^ 3GPP TS 29.060 section 6 see bibliography for reference information
- ^ 3GPP TS 29.060 section 6 see bibliography for reference information
[edit] Bibliography
- GSM standard 09.60, ETSI, 1996-98, this standard covers the original version 0 of GTP.
- 3GPP TS 29.060 V6.9.0 (2005-06), 3rd Generation Partnership Project, 650 Route des Lucioles - Sophia Antipolis, Valbonne - FRANCE, 2005-06. This is the primary standard defining all of the GTP variants for GTP version 1.
- 3GPP TS 32.295 V6.1.0 (2005-06), 3rd Generation Partnership Project, 650 Route des Lucioles - Sophia Antipolis, Valbonne - FRANCE, 2005-06. This standard covers using GTP for charging.
