9 GTP-U

29.0603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaceRelease 17TS

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

From release 8 onwards, the normative specification of the user plane of GTP version 1 is 3GPP TS 29.281 [41]. All provisions about GTPv1 user plane in the present document shall be superseded by 3GPP TS 29.281 [41].

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.

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]. The GGSN shall fragment, reject or discard T-PDUs, depending on the PDP type and implementation decisions, directed to the MS if the T-PDU size exceeds the maximum size. The decision if the T-PDUs shall be fragmented or discarded is dependent on the external packet data network protocol.

9.1 GTP-U Protocol Entity

The GTP-U protocol entity provides packet transmission and reception services to user plane entities in the GGSN, in the SGSN and, in UMTS systems, in the RNC. 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. Therefore no two remote GTP-U endpoints shall send traffic to a GTP-U protocol entity using the same TEID value except for data forwarding as part of the SRNS relocation or Intersystem Change procedures.

9.1.1 Handling of Sequence Numbers

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

The GTP-U protocol entity must reorder out of sequence T-PDUs when in sequence delivery is required. This is optional at the SGSN in UMTS. 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.

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 GSN or RNC 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.

9.2 GTP-U Service Access Points and Primitives

The GTP-U protocol entity offers packet Transmission services between a pair of GTP-U tunnel endpoints. The tunnel between two GTP-U endpoints is established via control plane procedures defined in protocols such as GTP-C and RANAP. The control of GTP-U resource allocation and tunnel set-up takes place via the GTP-U-CONTROL SAP. The GTP-U packet transmission (and packet reception) services are accessed via the GTP-U-UNIT-DATA SAP.

Figure 65: The GTP-U-Control SAP and GTP-U-DATA SAP

9.2.1 GTP-U-CONTROL SAP

The GTP-U-CONTROL SAP is used by a control plane entity to control the allocation of GTP-U resources and associate them to an identifier (the TEID) a user plane entity uses to access them via the GTP-U-UNIT-DATA SAP. It also defines in which way to control tunnel establishment. In particular, it provides means to control the GTP-U packet reception clause and the GTP-U packet transmission clause. The RX and TX suffix is used in the following to discriminate between primitives used to control the reception clause and primitives used to control the transmission clause.

9.2.1.1 GTP-U-CONTROL-RX primitives

Table 50

Primitive	Parameters	Reference
GTP-U-CONTROL-RX-SETUP.request	QoS info; IP address; TEID	9.2.1.1.1
GTP-U-CONTROL-RX-SETUP.confirm	Result	9.2.1.1.2
GTP-U-CONTROL-RX-RELEASE.request	TEID	9.2.1.1.3
GTP-U-CONTROL-RX-RELEASE.confirm	–	9.2.1.1.4
GTP-U-CONTROL-RX-ERROR.indication	Cause	9.2.1.1.5

9.2.1.1.1 GTP-U-CONTROL-RX-SETUP.request

This primitive is used to allocate packet reception resources according to a QoS profile specified via the "QoS" parameter. These resources are to be associated to a tunnel endpoint identified via the TEID specified in the "TEID" parameter. In case this TEID is already being used, this shall be interpreted as a resource modification request.

The "IP address" parameter is used to identify the IP address of the remote GTP-U protocol entity where the GTP-U tunnel is terminated. This implicitly identifies the path being used. The knowledge of the path being used is necessary in order to send ECHO messages used to detect path failure.

9.2.1.1.2 GTP-U-CONTROL-RX-SETUP.confirm

This primitive acknowledges the corresponding resources set up request. Any information to report is delivered in the parameter "Result", which may be used to indicate set up failure and the reason of the failure.

9.2.1.1.3 GTP-U-CONTROL-RX-RELEASE.request

This primitive is used to dispose the resources associated to a tunnel identified by TEID.

9.2.1.1.4 GTP-U-CONTROL-RX-RELEASE.confirm

This primitive acknowledges the corresponding resources release request.

9.2.1.1.5 GTP-U-CONTROL-RX-ERROR.indication

This primitive is used to indicate to the controlling entity any error conditions detected on the GTP-U reception clause. The error condition is specified in the parameter "Cause".

9.2.1.2 GTP-U-CONTROL-TX primitives

Table 51

Primitive	Parameters	Reference
GTP-U-CONTROL-TX-SETUP.request	QoS info; IP address; TEID	9.2.1.2.1
GTP-U-CONTROL-TX-SETUP.confirm	Result	9.2.1.2.2
GTP-U-CONTROL-TX-RELEASE.request	TEID; IP address	9.2.1.2.3
GTP-U-CONTROL-TX-RELEASE.confirm	–	9.2.1.2.4
GTP-U-CONTROL-TX-ERROR.indication	Cause	9.2.1.2.5

9.2.1.2.1 GTP-U-CONTROL-TX-SETUP.request

This primitive is used to allocate packet transmission resources according to a QoS profile specified via the "QoS" parameter. These resources are to be associated to a tunnel endpoint identified via the TEID specified in the "TEID" parameter. In case this TEID is already being used, this shall be interpreted as a resource modification request.

9.2.1.2.2 GTP-U-CONTROL-TX-SETUP.confirm

This primitive acknowledges the corresponding resources set up request. Any information to report is delivered in the parameter "Result", which maybe used to indicate set up failure and the reason of the failure.

9.2.1.2.3 GTP-U-CONTROL-TX-RELEASE.request

This primitive is used to dispose the resources associated to a tunnel identified by TEID and the IP address of the remote GTP-U protocol entity where the tunnel is terminated.

9.2.1.2.4 GTP-U-CONTROL-TX-RELEASE.confirm

This primitive acknowledges the corresponding resources release request.

9.2.1.2.5 GTP-U-CONTROL-TX-ERROR.indication

This primitive is used to indicate to the controlling entity any error conditions detected on the GTP-U Transmission clause. The error condition is specified in the parameter "Cause".

9.2.2 GTP-U-UNIT-DATA SAP and Primitives

The GTP-U-UNIT-DATA SAP is used to send and receive T-PDUs in an unacknowledged mode. Sequence numbers and system dependent info is conditionally passed to the user plane entity using the GTP-U-. This information is identified as "Other info" in the following.

Table 52

Primitive	Parameters	Reference
GTP-U-UNIT-DATA.request	DATA; TEID; IP address; Other info (note)	9.2.2.1
GTP-U- UNIT-DATA.indication	DATA; TEID; Other info (note)	9.2.2.2
NOTE: It is conditionally present (only if the TEID is associated to tunnels providing in sequence delivery, see clause 9.1.1).

9.2.2.1 GTP-U-UNIT-DATA.request

This primitive is used to send a T-PDU (DATA) by means of a specific GTP-U layer resource (tunnel) identified by the parameter TEID and the IP address where the tunnel is terminated. Other info may be conditionally present and transmitted together with T-PDUs.

9.2.2.2 GTP-U- UNIT-DATA.indication

A T-PDU (DATA) is received from a GPT-U peer entity and delivered to a user plane entity. The T-PDU is associated to the to the PDP or RNC context identified by TEID (that is the Tunnel Endpoint ID). Other info may be conditionally present and delivered together with T-PDUs.

9.3 Protocol Stack

The GTP-U protocol is used to transmit T-PDUs between GSN pairs (or between an SGSN and an RNC in UMTS), encapsulated in G-PDUs. A G-PDU is a packet including a GTP-U header and a T-PDU. The Path Protocol defines the path and the GTP-U header defines the tunnel. Several tunnels may be multiplexed on a single path. The frames have the following general structure.

Figure 66: GTP-U – Protocol Stack (GTP-U over the Iu in brackets)

9.3.1 Usage of the GTP-U Header

The GTP-U header shall be used as specified in clause 6 with the following details:

– Version shall be set to decimal 1 ("001").

– Protocol Type flag (PT) shall be set to "1".

– If the Sequence Number flag (S) is set to "1" the sequence number field is present and meaningful otherwise it is set to "0". For GTP-U messages Echo Request, Echo Response, Error Indication and Supported Extension Headers Notification, the S flag shall be set to "1".

– N-PDU Number flag (PN): the GTP-U header contains a meaningful N-PDU Number field if the PN flag is set to 1.

– Message Type shall be set according to table 1. The value 255 is used when T-PDUs are transmitted. The value 1 and 2 are used for "Echo" messages. The value 26 is used for "Error Indication" message. The value 31 is used for "Supported Extension Headers Notification" 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.

– Sequence Number: This field is meaningful if and only if the S field is set to 1. Its presence is defined in clause 6. The handling of this field is specified in clause 9.1.1. It shall be used in order to decide whether or not to discard a received T-PDU, as specified in clause 9.3.1.1 Usage of the Sequence Number or as a transaction identity for GTP-U signalling messages having a response message defined for a request message. For GTP-U message, Supported Extension Headers Notification and Error Indication the Sequence Number shall be ignored by the receiver.

– N-PDU Number: This field is meaningful if and only if the PN flag is set to 1. Its presence is defined in clause 6. In this case, the old SGSN (or RNC) uses it, at the Inter SGSN Routeing Area Update procedure (or SRNS relocation), to inform the new SGSN (or RNC) of the N-PDU number assigned to T-PDU. If an N-PDU number was not assigned to the T-PDU by PDCP, or if the T-PDU is to be transferred using unacknowledged peer-to-peer LLC operation, then PN shall be set to 0.

– TEID: Contains the Tunnel Endpoint Identifier for the tunnel to which this T-PDU belongs. 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.

9.3.1.1 Usage of Sequence Number

The sending GGSN and SRNC shall use 0 for the value of the Sequence Number of the first G-PDU in a tunnel, only during the PDP context activation, and shall increment the Sequence Number for each following G-PDU. The value shall wrap to zero after 65535.

The receiving GGSN and SRNC shall set the content of a counter to zero, only during the PDP context activation. When the receiving GGSN and SRNC receives a valid G-PDU, it shall increment this counter by one. This counter shall wrap to zero after 65535. It defines the "Expected Sequence Number".

Based on the received and Expected Sequence Number values, the receiving GGSN and SRNC may decide whether or not to discard the received G-PDU. Annex A (Informative) describes a method to determine whether a received G-PDU is valid.

The receiving GGSN and SRNC shall reorder the incoming T-PDUs in sequence if the Reordering Required flag in the PDP context is set. In this case, if needed, the receiving GGSN and SRNC shall take into account a maximum number of valid received frames and a maximum elapsed time to assume that a G-PDU was lost.

The G-PDU sequence numbers allocated by the GGSN (down-link) and SRNC (uplink) are kept unchanged irrespective of the number of GTP tunnels the PDU is transferred over. Therefore, SGSN shall use on the Iu interface for down-link PDUs the G-PDU sequence number received from the GGSN, and shall use on the Gn interface for uplink PDUs the G-PDU sequence number received from the SRNC. In case of SRNS relocation and intersystem change, the SRNC and SGSN shall tunnel PDUs without changing the G-PDU sequence numbers.

9.4 Tunnelling between SGSNs

T-PDUs, stored in the old SGSN and not yet sent to the MS, shall be tunnelled to the new SGSN as a part of the Inter SGSN Routeing Update procedure described in 3GPP TS 23.060 [4]. Some T-PDUs may still be on their way from the GGSN to the old SGSN because they have been sent before the tunnel change. These T-PDUs shall also be tunnelled to the new SGSN.

For intersystem SRNS Relocation, the establishment of the GTP tunnel(s) for the forwarding of G-PDUs is as described in the 3GPP TS 23.121 [17] and in the 3GPP TS 23.060 [4] specifications.

For PS Handover, the establishment of the GTP tunnel(s) for the forwarding of G-PDUs is as described in the 3GPP TS 43.129 [37].

9.5 Tunnelling between Source RNC and Target RNC

For the 3G-3G SRNS Relocation, the establishment of the GTP tunnel for the forwarding of G-PDUs between source and target RNC, is as described in the 3GPP TS 23.121 [17] and in the 3GPP TS 23.060 [4] specifications.

9.6 Tunnelling between GGSNs

GTP shall not specify tunnelling between GGSNs. Transfer of MS-to-MS traffic between GGSNs shall use the Gi interface.