5 GTP-U header

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

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

5.1 General format

The GTP-U header is a variable length header whose minimum length is 8 bytes. There are three flags that are used to signal the presence of additional optional fields: the PN flag, the S flag and the E flag. The PN flag is used to signal the presence of N-PDU Numbers. The S flag is used to signal the presence of the GTP Sequence Number field. The E flag is used to signal the presence of the Extension Header field, used to enable future extensions of the GTP header defined in this document, without the need to use another version number. If and only if one or more of these three flags are set, the fields Sequence Number, N-PDU and Extension Header shall be present. The sender shall set all the bits of the unused fields to zero. The receiver shall not evaluate the unused fields. For example, if only the E flag is set to 1, then the N-PDU Number and Sequence Number fields shall also be present, but will not have meaningful values and shall not be evaluated.

Always present fields:

– Version field: This field is used to determine the version of the GTP-U protocol. The version number shall be set to ‘1’.

– Protocol Type (PT): This bit is used as a protocol discriminator between GTP (when PT is ‘1’) and GTP’ (when PT is ‘0’). GTP is described in this document and the GTP’ protocol in 3GPP TS 32.295 [8]. Note that the interpretation of the header fields may be different in GTP’ than in GTP.

– Extension Header flag (E): This flag indicates the presence of a meaningful value of the Next Extension Header field. When it is set to ‘0’, the Next Extension Header field either is not present or, if present, shall not be interpreted. When it is set to ‘1’, the Next Extension Header field is present, and shall be interpreted, as described below in this clause.

– Sequence number flag (S): This flag indicates the presence of a meaningful value of the Sequence Number field. When it is set to ‘0’, the Sequence Number field either is not present or, if present, shall not be interpreted. When it is set to ‘1’, the Sequence Number field is present, and shall be interpreted, as described below in this clause.
For the Echo Request, Echo Response, Error Indication and Supported Extension Headers Notification messages, the S flag shall be set to ‘1’. Since the use of Sequence Numbers is optional for G-PDUs, the PGW, SGW, ePDG, eNodeB and TWAN should set the flag to ‘0’. However, when a G-PDU (T-PDU+header) is being relayed by the Indirect Data Forwarding for Inter RAT HO procedure, then if the received G-PDU has the S flag set to ‘1’, then the relaying entity shall set S flag to ‘1’ and forward the G-PDU (T-PDU+header). In an End marker and Tunnel Status messages the S flag shall be set to ‘0’.

– N-PDU Number flag (PN): This flag indicates the presence of a meaningful value of the N-PDU Number field. When it is set to ‘0’, the N-PDU Number field either is not present, or, if present, shall not be interpreted. When it is set to ‘1’, the N-PDU Number field is present, and shall be interpreted, as described below in this clause.

– Message Type: This field indicates the type of GTP-U message.

– Length: This field indicates the length in octets of the payload, i.e. the rest of the packet following the mandatory part of the GTP header (that is the first 8 octets). The Sequence Number, the N-PDU Number or any Extension headers shall be considered to be part of the payload, i.e. included in the length count.

– Tunnel Endpoint Identifier (TEID): This field unambiguously identifies a tunnel endpoint in the receiving GTP‑U protocol entity. The receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID value shall be assigned in a non-predictable manner for PGW S5/S8/S2a/S2b interfaces (see 3GPP TS 33.250 [32]). The TEID shall be used by the receiving entity to find the PDP context, except for the following cases:

– The Echo Request/Response and Supported Extension Headers notification messages, where the Tunnel Endpoint Identifier shall be set to all zeroes.

– The Error Indication message where the Tunnel Endpoint Identifier shall be set to all zeros.

– When setting up a GTP-U tunnel, the GTP-U entity shall not assign the value ‘all zeros’ to its own TEID. However, for backward compatibility, if a GTP-U entity receives (via respective control plane message) a peer’s TEID that is set to the value ‘all zeros’, the GTP-U entity shall accept this value as valid and send the subsequent G-PDU with the TEID field in the header set to the value ‘all zeros’.

Optional fields:

– Sequence Number: If Sequence Number field is used for G-PDUs (T-PDUs+headers), an increasing sequence number for T-PDUs is transmitted via GTP-U tunnels, when transmission order must be preserved. For Supported Extension Headers Notification and Error Indication messages, the Sequence Number shall be ignored by the receiver, even though the S flag is set to ‘1’.

– N-PDU Number: This field is used at the Inter SGSN Routeing Area Update procedure and some inter-system handover procedures (e.g. between 2G and 3G radio access networks). This field is used to co-ordinate the data transmission for acknowledged mode of communication between the MS and the SGSN. The exact meaning of this field depends upon the scenario. (For example, for GSM/GPRS to GSM/GPRS, the SNDCP N-PDU number is present in this field).

– Next Extension Header Type: This field defines the type of Extension Header that follows this field in the GTP‑PDU.

	Bits
Octets	8	7	6	5	4	3	2		1
1	Version			PT	(*)	E		S		PN
2	Message Type
3	Length (1^st Octet)
4	Length (2^nd Octet)
5	Tunnel Endpoint Identifier (1^st Octet)
6	Tunnel Endpoint Identifier (2^nd Octet)
7	Tunnel Endpoint Identifier (3^rd Octet)
8	Tunnel Endpoint Identifier (4^th Octet)
9	Sequence Number (1^st Octet)^{1) 4)}
10	Sequence Number (2^nd Octet)¹⁾ ⁴⁾
11	N-PDU Number^{2) 4)}
12	Next Extension Header Type^{3) 4)}

NOTE 0: (*) This bit is a spare bit. It shall be sent as ‘0’. The receiver shall not evaluate this bit.

NOTE 1: 1) This field shall only be evaluated when indicated by the S flag set to 1.

NOTE 2: 2) This field shall only be evaluated when indicated by the PN flag set to 1.

NOTE 3: 3) This field shall only be evaluated when indicated by the E flag set to 1.

NOTE 4: 4) This field shall be present if and only if any one or more of the S, PN and E flags are set.

Figure 5.1-1: Outline of the GTP-U Header

5.2 GTP-U Extension Header

5.2.1 General format of the GTP-U Extension Header

The format of GTP-U Extension Headers is depicted in figure 5.2.1-1. The Extension Header Length field specifies the length of the particular Extension header in 4 octets units. The Next Extension Header Type field specifies the type of any Extension Header that may follow a particular Extension Header. If no such Header follows, then the value of the Next Extension Header Type shall be 0.

Octets 1		Extension Header Length
2 – m		Extension Header Content
m+1		Next Extension Header Type

Figure 5.2.1-1: Outline of the Extension Header Format

The length of the Extension header shall be defined in a variable length of 4 octets, i.e. m+1 = n*4 octets, where n is a positive integer.

Bits 7 and 8 of the Next Extension Header Type define how the recipient shall handle unknown Extension Types, see Figure 5.2.1-2. The recipient of an extension header of unknown type but marked as ‘comprehension not required’ for that recipient shall read the ‘Next Extension Header Type’ field (using the Extension Header Length field to identify its location in the GTP-PDU).

The recipient of an extension header of unknown type, but marked as ‘comprehension required’ for that recipient, shall:

– If the message with the unknown extension header was a request or a G-PDU, send a Supported Extension Headers Notification to the originator of the GTP-PDU, discard the message and log an error.

Bits 7 and 8 of the Next Extension Header Type have the following meaning:

Bits 8 7	Meaning
0 0	Comprehension of this extension header is not required. An Intermediate Node shall forward it to any Receiver Endpoint
0 1	Comprehension of this extension header is not required. An Intermediate Node shall discard the Extension Header Content and not forward it to any Receiver Endpoint. Other extension headers shall be treated independently of this extension header.
1 0	Comprehension of this extension header is required by the Endpoint Receiver but not by an Intermediate Node. An Intermediate Node shall forward the whole field to the Endpoint Receiver.
1 1	Comprehension of this header type is required by recipient (either Endpoint Receiver or Intermediate Node)

Figure 5.2.1-2: Definition of bits 7 and 8 of the Extension Header Type

An Endpoint Receiver is the ultimate receiver of the GTP-PDU (e.g. an RNC or the GGSN for the GTP-U plane). An Intermediate Node is a node that handles GTP but is not the ultimate endpoint (e.g. an SGSN for the GTP-U plane traffic between GGSN and RNC).

Next Extension Header Field Value	Type of Extension Header
0000 0000	No more extension headers
0000 0001	Reserved – Control Plane only.
0000 0010	Reserved – Control Plane only.
0000 0011	Long PDCP PDU Number. See NOTE 2.
0010 0000	Service Class Indicator
0100 0000	UDP Port. Provides the UDP Source Port of the triggering message.
1000 0001	RAN Container
1000 0010	Long PDCP PDU Number. See NOTE 3.
1000 0011	Xw RAN Container
1000 0100	NR RAN Container
1000 0101	PDU Session Container. See NOTE 4.
1100 0000	PDCP PDU Number [4]-[5]. See NOTE 1.
1100 0001	Reserved – Control Plane only.
1100 0010	Reserved – Control Plane only.
NOTE 1: As an exception to the comprehension rule specified above, for a G-PDU with a Next Extension Header Field set to the value "1100 0000", the SGW shall consider this corresponding extension header as ‘comprehension not required’. NOTE 2: This value shall be used by a source eNB or gNB complying with this release of the specification. NOTE 3: This value shall not be used by a source eNB or gNB complying with this release of the specification. It may be received from a source eNB complying with an earlier release of the specification, i.e. not supporting the extension header value "0000 0011". NOTE 4: For a GTP-PDU with several Extension Headers, the PDU Session Container should be the first Extension Header.

Figure 5.2.1-3: Definition of Extension Header Type

5.2.2 Extension Header types

Extension header types marked as "Reserved – Control Plane only" in figure 5.2.1-3 are not used in the GTP user plane. These extension header types are defined in 3GPP TS 29.060 [6].

The following clauses define the format of the extension header types applicable to the GTP user plane.

5.2.2.1 UDP Port

This extension header may be transmitted in Error Indication messages to provide the UDP Source Port of the G-PDU that triggered the Error Indication. It is 4 octets long, and therefore the Length field has value 1.

		Bits
Octets		8	7	6	5	4	3	2	1
1	0x01
2-3		UDP Port number
4		Next Extension Header Type (note)

NOTE: The value of this field is 0 if no other Extension header follows.

Figure 5.2.2.1-1: UDP Port Extension Header

5.2.2.2 PDCP PDU Number

This extension header is transmitted, for example in UTRAN, at SRNS relocation time, to provide the PDCP sequence number of not yet acknowledged N-PDUs. It is 4 octets long, and therefore the Length field has value 1.

When used during a handover procedure between two eNBs at the X2 interface (direct DL data forwarding) or via the S1 interface (indirect DL data forwarding) in E-UTRAN, bit 8 of octet 2 is spare and shall be set to zero.

When used during a handover procedure between two NG-RANs at the Xn interface (direct DL data forwarding) or via the N3 interface (indirect DL data forwarding), bits 5-8 of octet 2 are spare and shall be set to zero.

NOTE 1: The PDCP PDU number field of the PDCP PDU number extension header has a maximum value which requires 15 bits (see 3GPP TS 36.323 [24]); thus, bit 8 of octet 2 is spare.

NOTE 2: The PDCP PDU number field of the PDCP PDU number extension header has a maximum value which requires 12 bits (see 3GPP TS 38.323 [35]); thus, bit 5-8 of octet 2 are spare.

		Bits
Octets		8	7	6	5	4	3	2	1
1	0x01
2		PDCP PDU number
3		PDCP PDU number.
4		Next Extension Header Type (Note 3)

NOTE 3: The value of this field is 0 if no other Extension header follows.

Figure 5.2.2.2-1: PDCP PDU Number Extension Header

5.2.2.2A Long PDCP PDU Number

This extension header is used for direct X2 or indirect S1 DL data forwarding during a Handover procedure between two eNBs. This extension header is also used for direct Xn or indirect N3 DL data forwarding during a Handover procedure between two NG-RANs. The Long PDCP PDU number extension header is 8 octets long, and therefore the Length field has value 2.

The PDCP PDU number field of the Long PDCP PDU number extension header has a maximum value which requires 18 bits (see 3GPP TS 36.323 [24] and 3GPP TS 38.323 [35]). Bit 2 of octet 2 is the most significant bit and bit 1 of octet 4 is the least significant bit, see Figure 5.2.2.2A-1. Bits 8 to 3 of octet 2, and Bits 8 to 1 of octets 5 to 7 shall be set to 0.

NOTE: A G-PDU which includes a PDCP PDU Number contains either the extension header PDCP PDU Number or Long PDCP PDU Number.

		Bits
Octets		8	7	6	5	4	3		2	1
1	0x02
2		Spare						PDCP PDU number
3		PDCP PDU number
4		PDCP PDU number
5		Spare
6		Spare
7		Spare
8		Next Extension Header Type (Note 1)

NOTE 1: The value of this field is 0 if no other Extension header follows.

Figure 5.2.2.2A-1: Long PDCP PDU Number Extension Header

5.2.2.3 Service Class Indicator

This extension header identifies the service class indicator (SCI) associated with the T-PDU carried by the downlink G-PDU. This information may be used by the A/Gb mode GERAN access for improved radio utilisation (see clause 5.3.5.3 of 3GPP TS 23.060 [4]).

In this version of the specification, this extension header may be transmitted over the Gn/Gp, S5/S8 and S4 interface. An eNodeB, RNC or MME shall ignore this information if received over the S1-U, S12, Iu, S11-U or any other interfaces not defined above, but still shall handle the G-PDU.

NOTE1: This extension header is also sent over the S1-U, S12, Iu interface and S11-U if the SGW receives the Service Class Indicator from S5/S8 for a UE having a user plane connection with an RNC or an eNodeB. This can happen when the PGW does not have an accurate knowledge of the current RAT of the user e.g. after a handover from GERAN to (E)UTRAN.

It is 4 octets long and therefore the Length field has the value 1.

		Bits
Octets		8	7	6	5	4	3	2	1
1	0x01
2		Service Class Indicator
3		Spare
4		Next Extension Header Type (note)

NOTE: The value of this field is 0 if no other Extension header follows.

Figure 5.2.2.3-1: Service Class Indicator Extension Header

If the bit 8 of octet 2 is set to 0, this indicates an operator specific Service Class Indicator value is included. Otherwise, it shall indicate that a standardised SCI is included.

NOTE 2: No standardized SCI value is defined in this release, it is intended to standardize SCIs in a future release.

Bits 8 to 1 of the octet 2 represent the binary coded value of the SCI, applications with similar Radio Resource Management treatment in GERAN shall be represented by the same value.

The octet 2 is coded as shown in Table 5.2.2.3-1.

Bits 8 to 1 of the octet 3 are spare bits and shall be set to zero.

Table 5.2.2.3-1: Service Class Indicator

Service Class Indicator (SCI), octet 2

Bit

0 Operator-specific SCI

Bits

7 6 5 4 3 2 1

0 0 0 0 0 0 0

0 0 0 1 1 1 1 Operator-specific SCIs

0 0 1 0 0 0 0

1 1 1 1 1 1 1 Spare for future use

Bit

1 Standardised SCI

Bits

7 6 5 4 3 2 1

0 0 0 0 0 0 0

1 1 1 1 1 1 1 Spare for future use

5.2.2.4 RAN Container

This extension header may be transmitted in a G-PDU over the X2 user plane interface between the eNBs. The RAN Container has a variable length and its content is specified in 3GPP TS 36.425 [25]. A G-PDU message with this extension header may be sent without a T-PDU.

		Bits
Octets		8	7	6	5	4	3	2	1
1	0xn
2-(4n -1)		RAN Container
4n		Next Extension Header Type (NOTE)

NOTE: The value of this field is ‘0’ if no other Extension header follows.

Figure 5.2.2.4-1: RAN Container Extension Header

5.2.2.5 Xw RAN Container

This extension header may be transmitted in a G-PDU over the Xw user plane interface between the eNB and the WLAN Termination (WT). The Xw RAN Container has a variable length and its content is specified in 3GPP TS 36.465 [27]. A G-PDU message with this extension header may be sent without a T-PDU.

		Bits
Octets		8	7	6	5	4	3	2	1
1	0xn
2-(4n -1)		Xw RAN Container
4n		Next Extension Header Type (NOTE)

NOTE: The value of this field is ‘0’ if no other Extension header follows.

Figure 5.2.2.5-1: Xw RAN Container Extension Header

5.2.2.6 NR RAN Container

This extension header may be transmitted in a G-PDU over the X2-U, Xn-U and F1-U user plane interfaces, within NG-RAN and, for EN-DC, within E-UTRAN. The NR RAN Container has a variable length and its content is specified in 3GPP TS 38.425 [30]. A G-PDU message with this extension header may be sent without a T-PDU.

		Bits
Octets		8	7	6	5	4	3	2	1
1	0xn
2-(4n -1)		NR RAN Container
4n		Next Extension Header Type (NOTE)

NOTE: The value of this field is ‘0’ if no other Extension header follows.

Figure 5.2.2.6-1: NR RAN Container Extension Header

5.2.2.7 PDU Session Container

This extension header shall be transmitted in:

– G-PDUs over the N3 and N9 user plane interfaces, between NG-RAN and UPF, or between two UPFs;

– G-PDUs over the N3mb and N19mb user plane interfaces, between the MB-UPF and NG-RAN, or between the MB-UPF and UPF; and

– in End Marker packets over data forwarding tunnels in 5GS, for data forwarding between 5GS and EPS.

The PDU Session Container has a variable length and its content is specified in 3GPP TS 38.415 [31].

A G-PDU message with this extension header may be sent without a T-PDU, e.g. when the G-PDU message is used as a dummy GTP-U packet for QoS Monitoring per QoS flow as specified in clause 5.33.3.2 of 3GPP TS 23.501 [28], where the PDU Session Container contains QoS Monitoring related parameters. An Intermediate UPF between the PSA UPF and the NG-RAN shall forward any received such G-PDU messages together with the GTP-U PDU Session Container extension header to the next GTP-U entity.

		Bits
Octets		8	7	6	5	4	3	2	1
1	0xn
2-(4n -1)		PDU Session Container
4n		Next Extension Header Type (NOTE)

NOTE: The value of this field is ‘0’ if no other Extension header follows.

Figure 5.2.2.7-1: PDU Session Container Extension Header