The GPRS Tunneling Protocol ( GTP ) is a group of IP-based communication protocols used to carry common radio package services (GPRS) in GSM, UMTS and LTE networks. In the 3GPP architecture, GTP-based and Proxy Mobile IPv6 interfaces are set at various interface points.
GTP can be decomposed into separate protocols, GTP-C, GTP-U, and GTP '.
GTP-C is used in the GPRS core network to signal between the GPRS support nodes (GGSN) gateway and serves the GPRS support node (SGSN). This enables SGSN to enable session on behalf of the user (activation of PDP context), to disable the same session, to adjust the quality of service parameters, or to update session for newly arrived customers from other SGSN.
GTP-U is used to carry user data in a GPRS core network and between a radio access network and a core network. The transported user data may be packaged in IPv4, IPv6, or PPP formats.
GTP '( GTP prime ) uses the same message structure as GTP-C and GTP-U, but has independent functions. It can be used to carry charging data from the data charging function (CDF) from GSM or UMTS network to the charging gate (CGF) function. In many cases, this means from many individual network elements such as GGSNs to a centralized computer that sends data more easily to a network operator's billing center.
Different GTP variations are implemented by RNCs, SGSNs, GGSNs and CGFs in 3GPP networks. GPRS mobile stations (MSs) connected to SGSN without knowing GTP.
GTP can be used with UDP or TCP. UDP is either recommended or mandatory, except for X.25 tunneling in version 0. GTP version 1 is only used in UDP.
Video GPRS Tunnelling Protocol
General features
All GTP variants have certain features in common. The message structure is the same, with the GTP header following the UDP/TCP header.
Header
GTP version 1
The GTPv1 header contains the following fields:
- Version
- This is a 3-bit field. For GTPv1, it has a value of 1.
- Protocol Type (PT) Ã,
- 1-bit value that distinguishes GTP (value 1) from GTP '(value 0).
- Backed up
- 1-bit backup field (should be 0).
- Flag of extension header (E)
- a 1-bit value stating whether there is an additional optional header field.
- The flag number (S)
- a 1-bit value stating whether there is an optional field of Order Number.
- N-PDU number flag (PN)
- a 1-bit value stating whether there is an optional field of N-PDU number.
- Message Type
- an 8-bit field showing the type of GTP message. Different types of messages are defined in 3GPP TS 29.060 section 7.1
- Message Length
- 16-bit field indicating the length of the payload in bytes (the remaining packets follow the mandatory 8-byte GTP header). Includes optional fields.
- Tunnel endpoint identifier (TEID)
- A 32-bit (4-octet) field used to multiply different connections in the same GTP tunnel.
- Order number
- 16-bit field (optional). This field exists if either the E, S, or PN bits are active. Fields should be interpreted only if bit S is active.
- N-PDU number
- 8-bit fields (optional). This field exists if either the E, S, or PN bits are active. Fields should be interpreted only if the PN bit is active.
- The next extension header type
- 8-bit fields (optional). This field exists if either the E, S, or PN bits are active. Fields should be interpreted only if bit E is active.
The Next Extension headers are as follows:
- Length
- 8-bit fields. This field specifies the length of the header of this extension, including the length, content, and sub column of the next extension, in a 4-octet unit, so the length of the extension should always be a multiple of 4.
- Content
- the contents of the extension headers.
- Next extension header
- 8-bit fields. This specifies the next extension type, or 0 if there is no subsequent extension. This allows chaining of several subsequent extension headers.
GTP version 2
It is also known as evolved-GTP or eGTP. The GTPv2-C header contains the following fields:
No GTPv2-U protocol, GTP-U in LTE also uses GTPv1-U.
- Version
- This is a 3-bit field. For GTPv2, it has a value of 2.
- Flag Piggybacking
- If this bit is set to 1 then another GTP-C message with its own header must be at the end of the current message. There is a limit to what types of messages can be billed depending on what the top-level GTP-C messages are.
- TEID flag
- If this bit is set to 1 then the TEID column will be between message length and sequential number. All messages except Echo and Echo replies require TEID to be present.
- Message length
- This field should indicate the message length in the octet is not mandatory from the GTP-C header (4 first octets). TEID (if any) and Order Number must be entered in a long count.
Connectivity mechanism
Regardless of the general messaging structure, there is also a common mechanism for verifying connectivity from one GSN to another GSN. It uses two messages.
- echo request
- an echo response
Often every 60 seconds, GSN can send an echo request to any other GSN that has an active connection. If the other end does not respond it can be considered down and the active connection to it will be deleted.
Apart from the two messages mentioned earlier, no other messages are common throughout the GTP variant which means that, for the most part, they effectively form three completely separate protocols.
Maps GPRS Tunnelling Protocol
GTP-C - GTP Control
The GTP-C protocol is the control section of the GTP standard. When a customer requests a PDP context, SGSN will send a create a PDP context request of a GTP-C message to a GGSN that provides details of customer requests. The GGSN will then respond by making a PDP context response a good GTP-C message will give details of the PDP context is actually enabled or will show failure and provide a reason for that failure. This is a UDP message on port 2123.
The eGTP-C protocol (or, GTPv2-C) is responsible for creating, maintaining and removing tunnels on multiple Sx interfaces. It is used for the management of aircraft control lines, tunnel management and mobility management. It also controls forwarding relocation messages; Context of SRNS and create tunnel forward during handover between LTE.
GTP-U - GTP tunneling user data
GTP-U is, essentially a relatively simple IP-based tunneling protocol that allows multiple tunnels between each set of end points. When used in UMTS, each customer will have one or more tunnels, one for each PDP context they have active, and may have separate tunnels for dedicated connections with different quality terms of service.
Separate tunnels are identified by TEID (Tunnel Endpoint Identifier) ​​â € <â €
The GTPv1-U protocol is used to exchange user data through GTP tunnels across the Sx interface. IP packets for the EU are encapsulated in the GTPv1-U packet and in-tunnel between P-GW and eNodeB for transmission with respect to UE interfaces above S1-U and S5/S8.
GTP' - charging transfer
The GTP protocol is used to transfer fill data to the Gateway Filling Function. GTP 'using TCP/UDP 3386 port.
Inside the core GPRS network
GTP is the main protocol used in GPRS core network. This is a protocol that allows end users of GSM or UMTS networks to move from one place to another while continuing to connect to the Internet as if from a single location in GGSN. This is done by bringing customer data from the current SGSN subscribers to the GGSN handling subscriber sessions. Three forms of GTP are used by the GPRS core network.
- GTP-U for user data transfers in separate tunnels for each PDP context
- GTP-C for control reasons including:
- setting and deleting the PDP context
- GSN capability verification
- update; for example, because customers move from one SGSN to another.
- GTP 'for the transfer of charging data from GSNs to the charging function.
GGSNs and SGSNs (collectively known as GSN) listen to GTP-C messages on UDP port 2123 and for GTP-U messages on port 2152. These communications occur in one network or may, in the case of international roaming, occur internationally, roaming GPRS (GRX).
The Gaming Functionality (CGF) listens to GTP messages sent from GSN on TCP/UDP port 3386. The core network sends charging information to the CGF, usually including the activation time of the PDP context and the quantity of data that has been transferred by the user end. However, communications that occur in one network are less standardized and may, depending on the vendor and configuration options, use exclusive encoding or even a fully proprietary system.
Use in the IPSPS interface
GTP-U is used on IuPS between GPRS and RAN core networks, but the GTP-C protocol is not used. In this case, RANAP is used as a control protocol and establishes a GTP-U tunnel between SGSN and radio network controllers (RNC).
Stack Protocol
GTP can be used with UDP or TCP. GTP version 1 is only used in UDP.
In 2004 there were two predefined versions, version 0 and version 1. Version 0 and version 1 were very different in structure. In version 0, the signaling protocol (the protocol that governs the tunnel by enabling the PDP context) is combined with the tunneling protocol on one port. Version 1 is actually effective two protocols, one for control (called GTP-C) and one for users data tunnels (called GTP-U).
GTP-U is also used to transport user data from RNC to SGSN on UMTS network. However, in this case signaling is done using RANAP instead of GTP-C.
Historical GTP Version
The original version of GTP (version 0) has considerable differences from the current version (version 1):
- non-random tunnel identification; The
- option is provided to transport X.25;
- fixed port number 3386 is used for all functions (not just charging as in GTPv1);
- TCP is allowed as a transport option, not UDP, but support for this is optional;
- subscription-related fields such as more limited service quality.
A non-random TEID in version 0 represents a security issue if an attacker has access to a roaming partner network, or can find some other way to send a remote packet to a GPRS backbone. Version 0 is no longer in use and is replaced by version 1 on almost all networks. Fortunately, however, the use of different port numbers allows easy blocking of version 0 via a simple IP access list.
GTP Standardization
GTP was originally standard in ETSI (standard GSM 09.60). With the creation of this UMTS standard was transferred to 3GPP which, in 2005 defended it as 3GPP 29.060 standard. GTP 'uses the same message format, but usage is specifically covered in 32,295 standard along with the standard format for the charging data to be transferred.
Then TS 29.060 version no longer uses interlock GTPv1/v0 so there is no fallback if GSN does not support higher version.
GTPv2 (for packaged services that evolved) went into drafts in early 2008 and was released in December of that year. GTPv2 offers fallback to GTPv1 via an earlier "Unsupported Version" mechanism but does not explicitly offer support for fallback to GTPv0.
See also
- Proxy Mobile IPv6
- Mobile IP
Note
References
- GSM Standard 09.60, ETSI, 1996-98, this standard includes the original version of 0 GTP.
- 3GPP TS 29.060 V6.9.0 (2005-06) , 3rd Generation Partnership Project, 650 Routes des Lucioles - Sophia Antipolis, Valbonne - FRANCE, 2005-06. This is the main standard that defines all GTP variants for GTP version 1.
- 3GPP TS 32.295 V6.1.0 (2005-06) , 3rd Generation Partnership Project, 650 Routes des Lucioles - Sophia Antipolis, Valbonne - FRANCE, 2005-06. This standard includes the use of GTP to charge.
- 3GPP TS 29.274 V8.1.0 (2009-03) , 3rd Generation Partnership Project, 650 Routes des Lucioles - Sophia Antipolis, Valbonne - FRANCE, 2009-03. GTPv2 to evolve GPRS.
External links
- The 3GPP website, home of the GTP standard
- Free open source implementation and GPRS Tunneling Protocol version 2 (GTPv2) or Evolved GTP (eGTP)
Source of the article : Wikipedia