7 GTP-U Messages

29.2813GPPGeneral Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)Release 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1 General

GTP-U Tunnels are used to carry encapsulated T-PDUs and signalling messages between a given pair of GTP-U Tunnel Endpoints. The Tunnel Endpoint ID (TEID) which is present in the GTP header shall indicate which tunnel a particular T-PDU belongs to. In this manner, packets are multiplexed and de-multiplexed by GTP-U between a given pair of Tunnel Endpoints. The TEID value to be used in the TEID field shall be negotiated for instance during the GTP-C Create PDP Context and the RAB assignment procedures that take place on the control plane.

For IP Multicast Distribution of User Plane Data for MBMS and MBS:

– the TEID value to be used in the TEID field shall be allocated at the source Tunnel Endpoint and signalled to the destination Tunnel Endpoint as specified in clause 4.2.6;

– because of the point-to-multipoint characteristics of IP Multicast Distribution, the path management messages Echo Request and Echo Response, the tunnel management message Error Indication, the message Supported Extension Headers Notification and the message End Marker shall not be used.

User payload is transmitted in G-PDU packets. A G-PDU is a packet including a GTP-U header and a T-PDU. A G-PDU may include extension headers. A G-PDU shall not include any information element.

GTP-U signalling messages are classified into path management messages, defined in clause 7.2 of the present document, and tunnel management messages, defined in clause 7.3 of the present document.

7.2 Path Management Messages

7.2.1 Echo Request

A GTP-U peer may send an Echo Request on a path to the other GTP-U peer to find out if it is alive (see clause Path Failure). Echo Request messages may be sent for each path in use. A path is considered to be in use if at least one PDP context, EPS Bearer, PDU Session, MBMS UE context, or MBMS bearer context uses the path to the other GTP-U peer. When and how often an Echo Request message may be sent is implementation specific but an Echo Request shall not be sent more often than every 60 s on each path. This doesn’t prevent resending an Echo Request with the same sequence number according to the T3-RESPONSE timer.

Even if there is no path in use, a GTP-U peer shall be prepared to receive an Echo Request at any time and it shall reply with an Echo Response. The optional Private Extension contains vendor or operator specific information.

Handling of the Recovery Time Stamp is specified in 3GPP TS 23.007 [3] and 3GPP TS 23.527 [33].

Table 7.2.1-1: Information Elements in an Echo Request

Information element	Presence requirement	Reference
Recovery Time Stamp	Optional	8.7
Private Extension	Optional	8.6

For the GTP-U tunnel setup between two nodes for forwarding user traffic, e.g. between eNodeBs for direct forwarding over X2, Echo Request path maintenance message shall not be sent except if the forwarded data and the normal data are sent over the same path.

7.2.2 Echo Response

The message shall be sent as a response to a received Echo Request.

The Restart Counter value in the Recovery information element shall not be used, i.e. it shall be set to zero by the sender and shall be ignored by the receiver. The Recovery information element is mandatory due to backwards compatibility reasons.

Handling of the Recovery Time Stamp is specified in 3GPP TS 23.007 [3] and 3GPP TS 23.527 [33].The optional Private Extension contains vendor or operator specific information.

Table 7.2.2-1: Information Elements in an Echo Response

Information element	Presence requirement	Reference
Recovery	Mandatory	8.2
Recovery Time Stamp	Optional	8.7
Private Extension	Optional	8.6

7.2.3 Supported Extension Headers Notification

This message indicates a list of supported Extension Headers that the GTP entity on the identified IP address can support. This message is sent only in case a GTP entity was required to interpret a mandatory Extension Header but the GTP entity was not yet upgraded to support that extension header. The GTP endpoint sending this message is marked as not enabled to support some extension headers (as derived from the supported extension header list). The peer GTP entity may retry to use all the extension headers with that node, in an attempt to verify it has been upgraded. Implementers should avoid repeated attempts to use unknown extension headers with an endpoint that has signalled its inability to interpret them.

Table 7.2.3-1: Information Elements in Supported Extension Headers Notification

Information element	Presence requirement	Reference
Extension Header Type List	Mandatory	8.5

7.3 Tunnel Management Messages

7.3.1 Error Indication

When a GTP-U node receives a G-PDU for which no EPS Bearer context, PDP context, PDU Session, MBMS Bearer context, or RAB exists, the GTP-U node shall discard the G-PDU. If the TEID of the incoming G-PDU is different from the value ‘all zeros’ the GTP-U node shall also return a GTP error indication to the originating node. GTP entities may include the "UDP Port" extension header (Type 0x40), in order to simplify the implementation of mechanisms that can mitigate the risk of Denial-of-Service attacks in some scenarios.

Handling of the received Error Indication and the Recovery Time Stamp is specified in 3GPP TS 23.007 [3] and 3GPP TS 23.527 [33].

The information element Tunnel Endpoint Identifier Data I shall be the TEID fetched from the G-PDU that triggered this procedure.

The information element GTP-U Peer Address shall be the destination address (e.g. destination IP address, MBMS Bearer Context) fetched from the original user data message that triggered this procedure. A GTP-U Peer Address can be a GGSN, SGSN, RNC, PGW, SGW, ePDG, eNodeB, TWAN, MME, gNB, N3IWF, or UPF address. The TEID and GTP-U peer Address together uniquely identify the related PDP context, RAB, PDU session or EPS bearer in the receiving node.

The optional Private Extension contains vendor or operator specific information.

Table 7.3.1-1: Information Elements in an Error Indication

Information element	Presence requirement	Reference
Tunnel Endpoint Identifier Data I	Mandatory	8.3
GTP-U Peer Address	Mandatory	8.4
Recovery Time Stamp	Optional	8.7
Private Extension	Optional	8.6

7.3.2 End Marker

7.3.2.1 General

The End Marker message indicates the end of the payload stream on a given tunnel, i.e. a G-PDU that arrives after an End Marker message on this tunnel may be silently discarded. Table 7.3.2.1-1 specifies the information element included in the End Marker message.

If an End Marker message is received with a TEID for which there is no context, then the receiver shall ignore this message.

The optional Private Extension contains vendor or operator specific information.

Table 7.3.2.1-1: Information Elements in End Marker message

Information element	Presence requirement	Reference
Private Extension	Optional	8.6

7.3.2.2 End Marker in EPS

The End Marker message(s) shall be sent after sending the last G-PDU that needs to be sent on a GTP-U tunnel as specified in 3GPP TS 23.401 [5] or after receiving an End Marker Indication as specified in clause 5.7.1 of 3GPP TS 23.402 [23].

The End Marker message(s) shall be sent for each GTP-U tunnel, except for the case of an E-UTRAN Initiated E-RAB modification procedure. During an E-UTRAN Initiated E-RAB modification procedure, the SGW shall send End marker message(s) to the eNodeB on the old S1-U tunnel for the tunnel(s) that are switched, i.e. if the S1 eNodeB F-TEID of the GTP-U tunnel provided by the MME in a Modify Bearer Request or Modify Access Bearer Request is not the same as the one previously stored in the SGW. Each GTP-U tunnel is identified with a respective TEID value in the GTP-U header.

An MME may receive End Marker packets over an S11-U tunnel during the following procedures:

– Inter-MME TAU procedure;

– Establishment of S1-U bearer during Data Transport in Control Plane CIoT EPS optimisation.

The MME shall discard the End Marker packets. The MME may also initiate the release of the corresponding S11-U resources; however the release of the S11-U resources is implementation dependent.

7.3.2.3 End Marker in 5GS

The End Marker message(s) shall also be sent after sending the last G-PDU that needs to be sent on a GTP-U tunnel or after receiving an End Marker Indication as specified in 3GPP TS 23.501 [28] and 3GPP TS 23.502 [29]. End marker packets sent over data forward tunnels in 5GS, for data forwarding between 5GS and EPS, shall be sent with the PDU Session Container extension header including the Qos Flow Identifier of one of the QoS flows mapped to the same E-RAB.

For QoS Flows transferred to and from Secondary RAN Node in Dual Connectivity (see clause 4.14.1 of 3GPP TS 23.502 [29]), end marker packets shall be sent over old tunnel for the transferred QoS flows without the Qos Flow Identifier included as specified in 3GPP TS 37.340 [38].

End Marker messages shall not be sent over the N19 interface.

7.3.3 Tunnel Status

The Tunnel Status message is optional. A GTP-U entity, if it supports the message, may send one or more Tunnel Status message to the peer GTP-U entity to provide the status information related to the corresponding GTP-U tunnel in the sending GTP-U entity. Table 7.3.2.1-1 specifies the information element included in the Tunnel Status message.

If a Tunnel Status message is received with a TEID for which there is no context, or the message is not supported, then the receiver shall ignore this message.

The optional Private Extension contains vendor or operator specific information.

Table 7.3.3-1: Information Elements in Tunnel Status message

Information element	Presence requirement	Reference
GTP-U Tunnel Status Information	Mandatory	8.7
Private Extension	Optional	8.6