GPRS Tunnelling Protocol (GTP) is a group of IP-based communications protocols used to carry general packet radio service (GPRS) within GSM, UMTS, LTE and 5G NR radio networks. In 3GPP architectures, GTP and Proxy Mobile IPv6 based interfaces are specified on various interface points. 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 1 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.
Header
GTP version 1 GTPv1 headers contain the following fields:
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. Different types of messages are defined in 3GPP TS 29.060 section 7.1 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:
Extension 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, so the length of the extension must always 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.
GTP version 2 It is also known as evolved-GTP or eGTP. GTPv2-C headers contain the following fields:
There is no GTPv2-U protocol, GTP-U in LTE also uses GTPv1-U.
Version It is a 3-bit field. For GTPv2, this has a value of 2. 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. Message length This field shall indicate the length of the message in octets excluding the mandatory of the GTP-C header (the first 4 octets). The TEID (if present) and the Sequence Number shall be included in the length count.
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 the active connections to it will be 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.
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 eGTP-C (or, GTPv2-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.
… excerpt ends here. Continue reading the full article.
