UMTS - GPRS Tunneling Protocol

---

---

The generation of GPRS Tunneling Protocol (GTP) was virtually impossible, but is also not desirable to give it for the new system, but, on the other hand, it is quite understandable that the improvements are also needed in order to be able to interact with the world of legacy PS smoothly and support functions needed for the newest system.

GPRS Tunneling Protocol (GTP)

GTP protocol is designed for tunneling and encapsulation of data units and control messages in GPRS. Since its design in the late 1990s, it was put to deploy on a large scale, and solid experience has been gathered.

GTP for Evolved 3GPP system is available in two variants, control and user plane. GTP-C manages the control plane signaling, and it is necessary in addition to the data transfer protocol on the purity of the user, GTP-U; it is called user plane. Current versions, suitable for EPS are GTPv1 US and GTPv2-C.

The peculiarity of GTP is that it supports the separation of traffic within its primary GTP tunnel holder, or in other words, the ability to group them together and treat carriers. The ends of GTP tunnels are identified by TEIDs (Tunnel Endpoint identifiers); they are assigned to the local level for the uplink and downlink by peer entities and reported transversely between them. TEIDs are used on different granularity by specific example PDN connection on S5 and S8 and EU on S3 / S4 / S10 / S11 interfaces.

Control Plane of GPRS Tunneling Protocol

GTPv2-C is used on the EPC signaling interfaces (including SGSNs of at least Rel. 8). For example −

• S3 (between SGSN and MME),
• S4 (between SGSN and Serving GW),
• S5 and S8 (between Serving GW and PDN GW),
• S10 (between two MMEs), and
• S11 (between MME and Serving GW).

Corresponding to this, a typical GTPv2-C protocol data unit like shown in the figure above, the specific part GTP is preceded by IP and UDP headers, it consists of a header GTPv2-C and part containing information GTPv2-C variable in number, length and format, depending on the type of the message. As the echo and the notification of a protocol version is not supported, TEID information is not present. The version is obviously firmly set at 2 in this version of the protocol.

GTP had a complex legacy extension header mechanism; it is not used in most GTPv2-C. The message type is defined in the second byte (so the maximum of 256 messages can be defined for future extensions). Below table provides an overview of messages currently defined GTPv2-C. The length of the message is coded in bytes 3 and 4 (measured in bytes and not containing the first four bytes themselves).

TEID is the ID of the tunnel end point, a single value on the opposite/receiving side; it allows multiplexing and de-multiplexing tunnels at one end in the very frequent cases over a GTP tunnel must be distinguished.

Enhanced GTPv1-U

Only a small but effective improvement was applied to GTP-U, and for that it was not considered necessary to strengthen the number of protocol version. Thus, we still expect GTPv1-U, but at least it’s most recent Rel. 8.

The protocol stack is essentially the same as for GTPv2-C with only the name of the layers and the protocols substituted accordingly. The extension header mechanism is kept in place; it allows inserting two elements if necessary.

• UDP source port of the triggering message (two octets);

• PDCP PDU number − related to the characteristic transfer without loss; in this case, data packets need to be numbered in the EPC (two octets).

The improvement is the ability to transmit an "end market" in the user plane. It is used in the inter-eNodeB handover procedure and gives the indication that the pathway is activated immediately after the data packet, for example, the feature is not necessary to pre-Rel.8 because GTP-U did not end in the radio access node (i.e. not in the BS or NodeB) only a few messages exist. GTPv1-U, and they are listed in the table above.

It is clear that, in fact a very limited kind of signaling is possible via GTPv1-U (echo mechanisms and end labeling). The only message that the transfer of real user data is of type 255, the so-called G-PDU message; the only piece of information it carries, after the header is the original data packet from a user or external PDN equipment.

Not all instances of GTP-U tunnels are listed in the reference architecture (which aimed to capture the associations were no longer living between network nodes); temporary tunnels are possible −

• Between two Serving GWs, applicable for the transfer based on S1, in the case that the service is moved GW;

• Between two SGSNs, corresponds to the previous case, but in the legacy PS network;

• Between two RNCs, applicable for the relocation of the RNC in the 3G PS network (no relation to the EPC, it is mentioned here just for completeness).