ETSI TS 129 281 V15.7.0 (2020-01)

TECHNICAL SPECIFICATION
Universal Mobile Telecommunications System (UMTS);
LTE;
5G;
General Packet Radio System (GPRS)
Tunnelling Protocol User Plane (GTPv1-U)
(3GPP TS 29.281 version 15.7.0 Release 15)

3GPP TS 29.281 version 15.7.0 Release 15 1 ETSI TS 129 281 V15.7.0 (2020-01)

Reference
RTS/TSGC-0429281vf70
Keywords
5G,LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 2 ETSI TS 129 281 V15.7.0 (2020-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 3 ETSI TS 129 281 V15.7.0 (2020-01)
Contents
Intellectual Property Rights . s
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
1 Scope . 6
2 References . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 General . 9
4.1 GTP Path . 9
4.2 GTP-U Tunnels . 9
4.2.1 GTP-U Tunnel description . 9
4.2.2 IP transport. 9
4.2.3 GTP-U Tunnel IP transport . 10
4.2.4 Ingress GTP tunnel (GTPv1-U sending endpoint) . 10
4.2.5 Egress GTP tunnel (GTPv1-U receiving endpoint) . 10
4.2.6 MBMS IP Multicast Distribution of the User Plane Data . 10
4.3 GTP-U Protocol Entity . 11
4.3.0 General . 11
4.3.1 Handling of Sequence Numbers . 11
4.4 Protocol stack . 12
4.4.0 GTP-PDU Stacks . 12
4.4.1 UDP/IP . 12
4.4.2 UDP header and port numbers . 13
4.4.2.0 General . 13
4.4.2.1 Echo Request Message . 13
4.4.2.2 Echo Response Message . 13
4.4.2.3 Encapsulated T-PDUs . 13
4.4.2.4 Error Indication . 13
4.4.2.5 Supported Extension Headers Notification . 13
4.4.2.6 End Marker . 13
4.4.3 IP header and IP addresses . 13
4.4.3.1 Echo Request Message . 13
4.4.3.2 Echo Response Message . 13
4.4.3.3 Encapsulated T-PDUs . 14
4.4.3.4 Error Indication . 14
4.4.3.5 Supported Extension Headers Notification . 14
4.4.3.6 End Marker . 14
4.5 Transmission Order and Bit Definitions . 14
4.6 New Functionality . 14
5 GTP-U header . 14
5.1 General format . 14
5.2 GTP-U Extension Header . 16
5.2.1 General format of the GTP-U Extension Header . 16
5.2.2 Extension Header types . 17
5.2.2.1 UDP Port . 18
5.2.2.2 PDCP PDU Number . 18
5.2.2.2A Long PDCP PDU Number . 18
5.2.2.3 Service Class Indicator . 19
5.2.2.4 RAN Container . 20
5.2.2.5 Xw RAN Container . 20
5.2.2.6 NR RAN Container . 21
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 4 ETSI TS 129 281 V15.7.0 (2020-01)
5.2.2.7 PDU Session Container . 21
6 GTP-U Message Formats . 21
6.1 General . 21
6.2 Presence requirements of Information Elements . 22
7 GTP-U Messages . 22
7.1 General . 22
7.2 Path Management Messages. 22
7.2.1 Echo Request . 22
7.2.2 Echo Response . 23
7.2.3 Supported Extension Headers Notification . 23
7.3 Tunnel Management Messages . 23
7.3.1 Error Indication . 23
7.3.2 End Marker . 24
8 Information Elements . 25
8.1 Information Element Types . 25
8.2 Recovery. 25
8.3 Tunnel Endpoint Identifier Data I . 26
8.4 GTP-U Peer Address . 26
8.5 Extension Header Type List . 26
8.6 Private Extension . 27
9 Error Handling . 27
9.1 Protocol Errors . 27
9.2 Path Failure . 27
10 Security. 27
11 Reliable Delivery of Signalling Messages . 27
12 GTP Parameters . . 28
12.1 General . 28
12.2 Timers . 28
12.3 Others . 28
13 Tunnelling Scenarios . 28
13.1 General . 28
13.2 Tunnelling between SGWs . 28
13.3 Transfer of the user plane data between PDN GWs . 28
13.4 Tunnelling between SGSNs . 29
13.5 Tunnelling between Source RNC and Target RNC . 29
13.6 Transfer of the user plane data between GGSNs . 29
13.7 Tunnelling between RNC and eNodeB . 29
13.8 Tunnelling between SGSN and eNodeB . 29
13.9 Tunnelling between Source eNodeB and Target eNodeB . 29
13.10 Tunnelling between SGSN and RNC . 29
13.11 Tunnelling between SGSN and SGW . 30
13.12 Tunnelling between SGW and eNodeB . 30
13.13 Tunnelling between SGW and RNC . 30
13.14 Tunnelling between SGW and SGSN . 30
Annex A (Normative): PDU session user plane protocol over N9 . 31
Annex B (informative): Change history . 32
History . 34

ETSI
3GPP TS 29.281 version 15.7.0 Release 15 5 ETSI TS 129 281 V15.7.0 (2020-01)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 6 ETSI TS 129 281 V15.7.0 (2020-01)
1 Scope
The present document defines the user plane of GTP used on:
- the Gn and Gp interfaces of the General Packet Radio Service (GPRS);
- the Iu, Gn and Gp interfaces of the UMTS system;
- the S1-U, S11-U, S2a, S2b, X2, S4, S5, S8, S12, M1 and Sn interfaces of the Evolved Packet System (EPS);
- the F1-U, Xn, N3 and N9 interfaces of the 5G System (5GS);
This definition ensures full backwards compatibility with RNC, SGSN and GGSN implementations according to release
7 of 3GPP TS 29.060 [6].
NOTE: Releases previous to Release-8 have used 3GPP TS 29.060 [6] as normative definition of the user plane
of GTP. This shall be considered when essential corrections are included in the present document or in
pre-release-8 version of 3GPP TS 29.060 [6].
Fallback from GTPv1-U to GTPv0-U shall not be supported. Therefore, 3GPP Rel-8 and onwards GTPv1-U entity
should not listen to the well-known GTPv0 port 3386. If GTPv1 entity listens to the GTPv0 port, the entity shall silently
discard any received GTPv0-U message.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 23.003: "Numbering, addressing and identification".
[3] 3GPP TS 23.007: "Restoration procedures".
[4] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[5] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".
[6] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP)
across the Gn and Gp interface".
[7] 3GPP TS 29.274: "3GPP Evolved Packet System; Evolved GPRS Tunnelling Protocol for EPS
(GTPv2)".
[8] 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data
Record (CDR) transfer".
[9] IETF RFC 768 (STD 0006): "User Datagram Protocol", J. Postel.
[10] IETF RFC 791 (STD 0005): "Internet Protocol", J. Postel.
[11] IETF RFC 4291: "IP Version 6 Addressing Architecture".
[12] 3GPP TS 33.210: "3G security; Network Domain Security (NDS); IP network layer security".
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 7 ETSI TS 129 281 V15.7.0 (2020-01)
[13] 3GPP TS 23.121: "Architectural requirements for Release 1999".
[14] 3GPP TS 43.129: "Packet-switched handover for GERAN A/Gb mode; Stage 2".
[15] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification", Standards Track
[16] 3GPP TS 25.413: "UTRAN Iu interface RANAP signalling".
[17] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[18] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional
description; Stage 2".
[19] IETF RFC 4604 (2006): "Using Internet Group Management Protocol Version 3 (IGMPv3) and
Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast".
[20] IETF RFC 4607 (2006): "Source-Specific Multicast for IP".
[21] 3GPP TS 33.102: "3G Security; Security architecture".
[22] 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE): Security architecture ".
[23] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".
[24] 3GPP TS 36.323: "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data
Convergence Protocol (PDCP) specification".
[25] 3GPP TS 36.425: "E-UTRAN X2 interface user plane protocol".
[26] IETF RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers".
[27] 3GPP TS 36.465: "Evolved Universal Terrestrial Radio Access (E-UTRAN) and Wireless LAN
(WLAN) Xw interface user plane protocol".
[28] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[29] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".
[30] 3GPP TS 38.425: "NG-RAN; NR user plane protocol".
[31] 3GPP TS 38.415: "NG-RAN; PDU Session User Plane Protocol".
[32] 3GPP TS 33.250: "Security assurance specification for the PGW network product class".
[33] 3GPP TS 23.527: "5G System; Restoration Procedures".
[34] 3GPP TS 38.300: "NR; NR and NG-RAN Overall Description; Stage 2".
[35] 3GPP TS 38.323: "NR; Packet Data Convergence Protocol (PDCP) specification".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
Common Tunnel Endpoint Identifier (C-TEID): Unambiguously identifies a tunnel endpoint in the receiving GTP-U
protocol entity for a given UDP/IP endpoint. The sending end side of a GTP tunnel locally assigns the C-TEID value
used in the TEID field and signals it to the destination Tunnel Endpoint using a control plane message.
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 8 ETSI TS 129 281 V15.7.0 (2020-01)
GTP-U Message: GTP-U (user plane) messages are either user plane messages or signalling messages. User plane
messages are used to carry user data packets between GTP-U entities. Signalling messages are sent between network
nodes for path management and tunnel management.GTP-U peer: node implementing at least one side of any of the
GTP user plane based protocols. RNC, SGSN, GGSN, eNodeB, SGW, ePDG, gNB, N3IWF, UPF, PGW or TWAN or
MME.
GTP-U Tunnel: A GTP-U tunnel is identified in each node with a TEID, an IP address and a UDP port number. A
GTP-U tunnel is necessary to enable forwarding packets between GTP-U entities.
GTP-U Tunnel Endpoint: A GTP-U tunnel endpoint identifies a user plane context (e.g EPS bearer, PDU session or a
RAB) for which a received GTP-U packet is intended. A given GTP-U tunnel endpoint may receive GTP-U packets
from more than one source GTP-U peer (See clause 4.3.0).UDP/IP Path: Connection-less unidirectional or
bidirectional path defined by two end-points. An IP address and a UDP port number define an end-point. A UDP/IP
path carries GTP messages between network nodes related to one or more GTP tunnels.
GTP-PDU: GTP Protocol Data Unit (PDU) is a GTP-U message, which may be either a G-PDU or a signalling
message.
G-PDU: User data packet (T-PDU) plus GTP-U header, sent between GTP network nodes.
Signalling Message: A GTP-U message (GTP-PDU that is not a G-PDU) sent between GTP network nodes. These may
be Path Management messages or Tunnel Management messages.
T-PDU: A user data packet, for example an IP datagram, sent between a UE and a network entity in an external packet
data network. A T-PDU is the payload that is tunnelled in the GTP-U tunnel.
Tunnel Endpoint Identifier (TEID): Unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol
entity for a given UDP/IP endpoint. The receiving end side of a GTP tunnel locally assigns the TEID value the
transmitting side has to use. The TEID values are exchanged between tunnel endpoints using control plane message.
Trusted WLAN Access Network: see 3GPP TS 23.402 [23].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
C-TEID Common Tunnel Endpoint IDentifier
EN-DC E-UTRA-NR Dual Connectivity
ePDG Evolved Packet Data Gateway
GSN GPRS Support Node
GGSN Gateway GPRS Support Node
G-PDU GTP encapsulated user Plane Data Unit
GTP GPRS Tunnelling Protocol
GTP-C GTP Control
GTP-U GTP User
IE Information Element
IGMP Internet Group Management Protocol
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
MME Mobility Management Entity
PDU Packet Data Unit
PGW PDN Gateway
QoS Quality of Service
RANAP Radio Access Network Application Part
RNC Radio Network Controller
SGSN Serving GPRS Support Node
SGW Serving Gateway
TEID Tunnel Endpoint IDentifier
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 9 ETSI TS 129 281 V15.7.0 (2020-01)
T-PDU Transport PDU
TWAN Trusted WLAN Access Network
UDP User Datagram Protocol
UTRAN UMTS Terrestrial Radio Access Network
4 General
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].
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 10 ETSI TS 129 281 V15.7.0 (2020-01)
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 2460 [15].
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 2460
[15] 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 2460 [15] 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 2460 [15] 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 MBMS IP Multicast Distribution of the User Plane Data
GTP-U Multicast Tunnels are 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, as
specified in TS 23.246 [18]. 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 is 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. There is one C-TEID allocated per MBMS bearer service.
The destination IP address in the outer GTPv1-U IP header is 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 TS 23.246 [18], it shall join the IP multicast group as specified in IETF
RFC 4604 [19] and IETF RFC 4607 [20].
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 11 ETSI TS 129 281 V15.7.0 (2020-01)
The characteristics for point-to-multipoint GTP-U Multicast Tunnels used for MBMS 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, and 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
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 12 ETSI TS 129 281 V15.7.0 (2020-01)
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.

T-PDU
G- PDU
GTPv1-U Header
UDP/IP
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 2460 [15].
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].
ETSI
3GPP TS 29.281 version 15.7.0 Release 15 13 ETSI TS 129 281 V15.7.0 (2020-01)
4.4.2 UDP header and port numbers
4.4.2.0 General
For the messages described below, the UDP Source Port (except as specified for the Echo Response message) may be
allocated either statically or dynamically by the sending GTP-U entity.
NOTE: Dynamic allocation of the UDP source port can help balancing the load in the network, depending on
network deployments and network node implementations.
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 d
...