UMTS - GPRS Tunneling Protocol

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.

Message Type	Message	Additional Explanation
0	Reserved	Shall never be used (intentionally excluded from protocol, to enforce explicit setting)
1/2	Echo Request/ Response	Used to probe if a GTP version supported by the sending node.
3	Version Not Supported Indication	Contains the latest GTP version supported the sending node.
4/5	Direct Transfer Request/ Response	Used for tunneling signaling message on S101 interface for optimized handover, between HRPD access not and MME
6/7	Notification Request/ Response	Used for tunneling notification on S101 between HRPD access node and MME
25/26	SRVCC PS to CS request	Used to trigger and confirm SRVCC initiation between SGSN/MME and MSC server
27/28	SRVCC PS to CS complete Notification	Used to indicated and confirm completion of SRVCC between MSC server and SGSN/ MME
32/33	Create Session Request	Used to establish connectivity between two nodes
34/35	Modify Bearer Request	Used to modify properties of a single or of multiple bearer, include bearer context information
36/37	Delete Session Request	Tears down GTP control session
38/39	Change Notification request	Used for reporting location information
66/67	Delete bearer command/ failure indication	Instruct nodes to delete bearer and confirm back
68/69	Bearer resource command/ failure indication	Used to allocate or modify resources
73	Stop paging indication	Sent from SGW to the MME or SGSN
95/96	Create bearer request/ response	Instruct nodes to install bearers and confirms back
97/98	Update bearer request	Used to inform the control plane nodes from the user plane about bearer changes

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).

Previous Page Print Page