4 General

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

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

4.1 GTP Path

For the definition of UDP/IP Path and GTP Endpoint, see 3GPP TS 29.060 [6].

4.2 GTP-U Tunnels

4.2.1 GTP-U Tunnel description

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 signalled to the peer GTP-U entity using a control plane protocol like GTPv1-C, GTPv2-C, RANAP or S1-AP.

In what follows we refer to the outer GTPv1-U IP packet as the IP packet that carries a GTPv1-U packet. The inner IP packet in a GTPv1-U packet (T-PDU) is either

– An IP packet sent to the UE/MS in the downlink direction over one or more tunnels from the external network identified by the APN.

– An IP packet sent from a UE/MS in the uplink direction over one or more tunnels to the external network identified by the APN.

NOTE 1: Not all tunnels in 3GPP networks will necessarily be GTPv1-U,

NOTE 2: The inner MTU size of the GTPv1-U tunnel is typically not the same as the outer MTU size of the IP path carrying the outer IP packets.

The maximum size of a T-PDU that may be transmitted without fragmentation by GGSN or the MS is defined in 3GPP TS 23.060 [4].

4.2.2 IP transport

According to IETF RFC 791 [10], any IPv4 router in the backbone may fragment the outer IPv4 GTPv1-U packet with a flag of DF=0.

Unnecessary fragmentation should be avoided when possible due to the following;

– Fragmentation is bandwidth inefficient, since the complete IP header is duplicated in each fragment.

– Fragmentation is CPU intensive since more fragments require more processing at both GTPv1-U endpoints and IP routers. It also requires additional memory at the receiver.

– If one fragment is lost, the complete packet has to be discarded. The reason is there is no selective retransmission of IP fragments provided in IPv4 or IPv6.

Recommendations on how to set the default inner MTU size at the PDN GW and UE/MS to avoid IP fragmentation of both inner IP packets (in the PDN GW or UE/MS) and outer IP packets in the backbone are specified in clause 9.3 of 3GPP TS 23.060 [4].

4.2.3 GTP-U Tunnel IP transport

Functionality for IP transport and IP fragmentation at a RAN node on the Iu interface or S12 is defined in 3GPP TS 25.414 [16].

Functionality for IP transport and IP fragmentation at an eNodeB on the S1-U and X2 interface is defined in 3GPP TS 36.300 [17].

Functionality for IP transport and IP fragmentation at an NG-RAN on the N3 and Xn interface is defined in 3GPP TS 38.300 [34].

The outer GTPv1-U packet layer shall support IPv4 as defined by IETF RFC 791 [10] and should support IPv6 as defined by IETF RFC 8200 [36].

The following text as well as clauses 4.2.4 and 4.2.5 apply only to core network GTPv1-U endpoints.

GTPv1-U tunnel endpoints do not need to change the hopcount/TTL or to perform any IP routing functions in respect to inner IP packet other than the functions explicitly stated here. However, other co-located functions may do so. For example, the GGSN/PGW/UPF may change the hopcount/TTL as the IP datagram enters/leaves the Gi/SGi/N6 interface from/to the GTPv1-U tunnel interface and IP packets may be discarded or rejected at any point by a co-located function due to local policy and/or QoS (the policy enforcement point).

4.2.4 Ingress GTP tunnel (GTPv1-U sending endpoint)

An inner IP packet shall be encapsulated at the GTPv1-U sender with a GTP header, UDP and IP header. If the resulting outer IP packet is larger than the MTU of the first link towards the destination GTPv1-U endpoint, fragmentation of the IP packet shall be performed by the sender as per IETF RFC 791 [10] for an outer layer of IPv4 and IETF RFC 8200 [36] for an outer layer of IPv6. The GTPv1-U sender should preferably fragment the IP packet to the smallest MTU of any link between GTPv1-U sender and GTPv1-U receiver.

Fragmentation policy of the inner datagram is implementation dependent but shall interwork with IETF RFC 791 [10] for inner IPv4 datagrams and IETF RFC 8200 [36] for inner IPv6 packets.

4.2.5 Egress GTP tunnel (GTPv1-U receiving endpoint)

The GTPv1-U receiving endpoint packets shall reassemble any IP fragments in datagrams received from the GTPv1-U sending endpoint as per IETF RFC 791 [10] for outer IPv4 datagrams and as per IETF RFC 8200 [36] for outer IPv6 datagrams. The IP reassembly buffer in the receiving endpoint shall be at least the inner MTU size plus the size of the tunnel headers (outer IP header, outer UDP header, and GTP header, including any GTP extension headers).

The completely reassembled IP packet shall then be passed to the IP/UDP/GTPv1-U layers to extract the inner IP packet which is then processed further according to the receiving node’s functionality.

4.2.6 IP Multicast Distribution of User Plane Data for MBMS and MBS

4.2.6.1 General

In GPRS and EPS, MBMS data may be delivered between the GGSN and RNC, or between the MBMS GW and the eNodeB or RNC, using IP multicast transport, as specified in clause 6.5 of 3GPP TS 23.246 [18].

In 5GS, MBS data may be delivered between the 5GC and NG-RAN using 5GC Individual MBS traffic delivery (applicable only to multicast MBS sessions) and/or 5GC Shared MBS traffic delivery (applicable to broadcast and multicast MBS sessions), as specified in clause 4.1 of 3GPP TS 23.247 [40]. The user plane from the MB-UPF to NG-RANs (for 5GC Shared MBS traffic delivery) and the user plane from the MB-UPF to UPFs (for 5GC Individual MBS traffic delivery) may use IP multicast transport via a common GTP-U tunnel per MBS session, or use unicast transport via separate GTP-U tunnels at NG-RAN or at UPF per MBS session, as specified in clause 6.7 of 3GPP TS 23.247 [40].

Specific requirements for IP multicast distribution of user plane data are specified in clause 4.2.6.2.

4.2.6.2 IP multicast distribution of User Plane Data

When using IP multicast transport, GTP-U Multicast Tunnels shall be used for unidirectional transfer of the encapsulated T-PDUs from one GTP-U Tunnel Endpoint acting as an IP multicast source to multiple GTP-U Tunnel Endpoints acting as IP multicast listeners. The Common Tunnel Endpoint ID (C-TEID) which is present in the GTP header shall indicate which tunnel a particular T-PDU belongs to. The C-TEID value to be used in the TEID field shall be allocated at the source Tunnel Endpoint and signalled to the destination Tunnel Endpoint using a control plane protocol, i.e. GTPv1-C and RANAP, GTPv2-C and S1-AP, 5GC SBIs and/or NGAP. One C-TEID shall be allocated per MBMS bearer service or per MBS session.

The destination IP address in the outer GTPv1-U IP header shall be an address in the multicast address range as specified in IETF RFC 4607 [20].

If the RNC decides to receive IP multicast packets, then the RNC shall join the IP multicast group as specified by IETF RFC 4604 [19] and IETF RFC 4607 [20].

If the eNodeB supports MBMS as specified in 3GPP TS 23.246 [18], it shall join the IP multicast group as specified in IETF RFC 4604 [19] and IETF RFC 4607 [20].

If the gNB supports MBS as specified in 3GPP TS 23.247 [40], it shall join the IP multicast group as specified in IETF RFC 4604 [19] and IETF RFC 4607 [20].

The characteristics for point-to-multipoint GTP-U Multicast Tunnels used for MBMS or MBS are the same as for a point-to-point GTP-U Tunnels unless specified otherwise. The differences are specified in clause 7.1.

4.3 GTP-U Protocol Entity

4.3.0 General

The GTP-U protocol entity provides packet transmission and reception services to user plane entities in the RNC, SGSN, GGSN, eNodeB, SGW, ePDG, PGW, TWAN, MME, gNB, N3IWF, UPF and MB-UPF. The GTP-U protocol entity receives traffic from a number of GTP-U tunnel endpoints and transmits traffic to a number of GTP-U tunnel endpoints. There is a GTP-U protocol entity per IP address.

The TEID in the GTP-U header is used to de-multiplex traffic incoming from remote tunnel endpoints so that it is delivered to the User plane entities in a way that allows multiplexing of different users, different packet protocols and different QoS levels. The GTP-U protocol supports the possibility for one GTP-U tunnel endpoint to receive packets from multiple remote GTP-U endpoints. This may be used in the following scenarios:

– Tracking Area Update procedure with Serving GW change and data forwarding as specified in clause 5.3.3.1A of 3GPP TS 23.401 [5], if the above capability is supported by the receiving eNB;

– Dual connectivity in 5GC as specified in clause 5.11.1 of 3GPP TS 23.501 [28], where the master and secondary NG-RAN may be assigned the same uplink F-TEID of the UPF by the SMF for uplink traffic of the same PDU session; and

– IPv6 multihoming scenario as specified in clause 5.6.4.3 of 3GPP TS 23.501 [28], where the downlink traffic from multiple PDU Session Anchors of the same PDU session may be assigned the same N9 F-TEID of the branching point UPF by the SMF.

4.3.1 Handling of Sequence Numbers

This functionality is provided only when the S bit is set to 1 in the GTP-U header.

For PGW, SGW, ePDG, eNodeB, TWAN, MME, gNB, N3IWF, and UPF, the usage of sequence numbers in G-PDUs is optional, but if GTP-U protocol entities in these nodes are relaying G-PDUs to other nodes, then they shall relay the sequence numbers as well For all other cases, the PGW, SGW, ePDG, eNodeB, TWAN, MME, gNB, N3IWF and UPF should set the "S" flag to 0 in the GTPv1 header which then indicates that the sequence number is not used in the T-PDU.

An RNC, SGSN or GGSN shall reorder out of sequence T-PDUs when in sequence delivery is required. This is optional at the SGSN for UTRAN access. The GTP-U protocol entity shall deliver to the user plane entity only in sequence T‑PDUs and notify the sequence number associated to each of them. The notification of the sequence number is not necessary at the GGSN, but it is mandatory at the SGSN and RNC. The user plane entity shall provide a sequence number to the GTP-U layer together with T-PDUs to be transmitted in sequence. GTP-U protocol entities at the GGSN may optionally generate autonomously the sequence number, but should be able to use sequence numbers provided by the user plane entity. The sequence number is handled on a per GTP-U Tunnel (that is TEID) basis. During relocations and handovers, if a buffered packet is forwarded from the source to the target GTP-U protocol entity along with PDCP T-PDU extension headers, the source of the T-PDU may be considered different and may not relay the sequence numbers.

When the sequence number is included in the GTP-U header, a user plane entity acting as a relay of T-PDUs between GTP-U protocol entities, or between PDCP (or SNDCP) protocol entities and GTP-U protocol entities, shall relay the sequence numbers between those entities as well. In this way it is possible to keep consistent values of sequence numbers from the GGSN to the UE (MS in GPRS) by relaying the sequence number across the CN GTP-U bearer, the Iu GTP-U bearer and the Radio bearer (via PDCP or SNDCP N-PDU numbers). This functionality is beneficial during SRNS relocation.

For GTP-U signalling messages having a response message defined for a request message, Sequence Number shall be a message number valid for a path. Within a given set of continuous Sequence Numbers from 0 to 65535, a given Sequence Number shall, if used, unambiguously define a GTP-U signalling request message sent on the path (see clause Reliable delivery of signalling messages). The Sequence Number in a signalling response message shall be copied from the signalling request message that the GTP-U entity is replying to. For GTP-U messages not having a defined response message for a request message, i.e. for messages Supported Extension Headers Notification and Error Indication, the Sequence Number shall be ignored by the receiver.

4.4 Protocol stack

4.4.0 GTP-PDU Stacks

The protocol stack for a GTP-PDU G-PDU is shown in Figure 4.4-1. The protocol stack for a GTP-PDU signaling message is shown in Figure 4.4-2.

Figure: 4.4-1 G-PDU Protocol Stack

NOTE: T-PDU may contain an IP Datagram, Ethernet or unstructured PDU Data frames as specified in 3GPP TS 23.501 [28].

Figure: 4.4-2 Signalling Message Protocol Stack

4.4.1 UDP/IP

UDP/IP is the only path protocol defined to transfer GTP messages in the version 1 of GTP.

A GTPv1-U peer shall support the User Datagram Protocol (UDP) as defined by IETF RFC 768 [9] shall be used.

A GTPv1-U peer shall support IPv4 as defined by IETF RFC 791 [10] and should support IPv6 as defined by IETF RFC 8200 [36].

The DSCP marking as defined by IETF RFC 2474 [26] shall be set:

– based on the QCI, and optionally the ARP priority level, of the associated EPS bearer, as described in clause 4.7.3 of 3GPP TS 23.401 [5];

– based on the 5QI and ARP of the associated 5G QoS Flow, as described in clause 5.7.1.6 and clause 5.7.1.7 of 3GPP TS 23.501 [28].

4.4.2 UDP header and port numbers

4.4.2.0 General

For the GTP-U messages described below (other than the Echo Response message, see clause 4.4.2.2), the UDP Source Port or the Flow Label field (see IETF RFC 6437 [37]) should be set dynamically by the sending GTP-U entity to help balancing the load in the transport network.

When using GTP-U over IPv6 (see IETF RFC 8200 [36]), the UDP checksum shall not be set to zero by the sending GTP-U entity unless it is ensured that the peer GTP-U entity and the path in-between supports UDP zero checksum.

NOTE 1: GTP-U entities complying with an earlier version of the specification or on path IPv6 middleboxes can implement IPv6 as specified in IETF RFC 2460 [15] and discard UDP packets containing a zero checksum.

NOTE 2: How a sending GTP-U entity knows whether the peer GTP-U entity and the path in-between supports UDP zero checksum is out of scope of this specification.

4.4.2.1 Echo Request Message

The UDP Destination Port number for GTP-U request messages is 2152. It is the registered port number for GTP-U.

4.4.2.2 Echo Response Message

The UDP Destination Port value shall be the value of the UDP Source Port of the corresponding request message.

The UDP Source Port shall be the value from the UDP Destination Port of the corresponding request message.

4.4.2.3 Encapsulated T-PDUs

The UDP Destination Port number shall be 2152. It is the registered port number for GTP-U.

4.4.2.4 Error Indication

The UDP destination port for the Error Indication shall be the user plane UDP port (2152).

NOTE: In network deployments including non-GTP-aware stateful firewalls, those firewalls must be configured to allow response messages coming from a different UDP port and IP address than the triggering message.

4.4.2.5 Supported Extension Headers Notification

The UDP destination port for the Supported Extension Headers Notification shall be the user plane UDP port (2152).

4.4.2.6 End Marker

The UDP Destination Port number shall be 2152. It is the registered port number for GTP-U.

The UDP Destination Port and UDP Source Port shall be the same as those of the corresponding GTP-U tunnel for which the End Marker message is sent.

4.4.2.7 Tunnel Status

The UDP destination port for the Tunnel Status shall be the user plane UDP port (2152).

4.4.3 IP header and IP addresses

4.4.3.1 Echo Request Message

The IP Source Address shall be an IP address of the source GTP-U entity from which the message is originating.

The IP Destination Address in a GTP request message shall be an IP address of the destination GTP-U entity.

4.4.3.2 Echo Response Message

The IP Source Address shall be copied from the IP destination address of the GTP request message to which this GTP‑U entity is replying.

The IP Destination Address shall be copied from the IP Source Address of the GTP request message to which this GTP‑U entity is replying.

4.4.3.3 Encapsulated T-PDUs

The IP Source Address shall be an IP address of the source GTP-U entity from which the message is originating.

The IP Destination Address shall be an IP address of the destination GTP-U entity.

4.4.3.4 Error Indication

The IP source address shall be an address of the source GTP-U entity from which the message is originated

The IP destination address for Error Indication shall be the source address of the GTP-PDU that is the cause for this GTP-U entity to send this message.

4.4.3.5 Supported Extension Headers Notification

The IP Source Address for the Supported Extension Headers Notification shall be copied from the IP destination address of the GTP message that triggered the GTP-U entity to send this message.

The IP Destination Address for the Supported Extension Headers Notification shall be copied from the IP source address of the GTP message that triggered the GTP-U entity to send this message.

4.4.3.6 End Marker

The IP Source Address shall be an IP address of the source GTP-U entity from which the message is originating.

The IP Destination Address shall be an IP address of the destination GTP-U entity.

The IP Destination Address and IP Source Address shall be the same as those of the corresponding GTP-U tunnel for which the End Marker message is sent.

4.4.3.7 Tunnel Status

The IP Source Address shall be an IP address of the source GTP-U entity from which the message is originating.

The IP Destination Address shall be an IP address of the destination GTP-U entity.

The IP Destination Address and IP Source Address shall be the same as the corresponding GTP-U tunnel (to send G-PDU) for which the Tunnel Staus message is sent.

4.5 Transmission Order and Bit Definitions

As specified in 3GPP TS 29.060 [6], clause 5.

4.6 New Functionality

With regard to the previous releases, the present specification may define some new functions. Such new functions shall ensure full backwards compatibility with Pre-Rel-8 nodes conforming to 3GPP TS 29.060 [6]. If the new functions are specified with the Extension Headers, bits 8 and 7 of the Extension Header Type shall be set to 0, 0 respectively or 0, 1 respectively. If the new functions are specified with Information Elements, such Information Elements shall be TLV-encoded and optional.