TEID-U

Tunnel Endpoint Identifier, user plane

Identifier →
Introduced in Rel-8

TEID-U is a unique identifier for user plane GTP tunnels between network nodes that enables multiplexing multiple data flows within one transport connection for correct packet routing and session management.

Category
Identifier
Introduced
Rel-8
Where
Core Network › Evolved Packet Core
Specifications
1 specs
TEID-U Description Purpose Related Classification Detected Changes Specifications

Description

The Tunnel Endpoint Identifier for the user plane (TEID-U) is a fundamental component within the GPRS Tunneling Protocol (GTP) architecture, specifically defined for the user plane (GTP-U). It is a 32-bit field that uniquely identifies a GTP tunnel endpoint on a network node for a specific user's data traffic. When a user equipment (UE) establishes a data session, the network creates GTP tunnels to carry the user's IP packets. For example, in the LTE EPC, a GTP-U tunnel exists between the Serving Gateway (SGW) and the Packet Data Network Gateway (PGW), and another between the SGW and the eNodeB. Each endpoint of these tunnels is assigned a TEID-U by the receiving node. This TEID-U is then communicated to the sending node via control plane signaling (GTP-C), so that when the sender encapsulates user IP packets into a GTP-U header, it populates the TEID field with the receiver's assigned TEID-U. This allows the receiving node to correctly de-multiplex incoming packets and forward them to the appropriate bearer context for the target UE.

The TEID-U operates in conjunction with the user's IP address and the UDP port number for GTP-U (typically 2152). This combination creates a unique socket for tunneled traffic. The TEID-U's primary role is to distinguish between multiple simultaneous GTP tunnels that may share the same transport network layer (IP address and UDP port) between two nodes. For instance, a single SGW may handle thousands of UEs, each with potentially multiple bearers (e.g., default and dedicated bearers). Each bearer requires its own GTP-U tunnel, and thus its own pair of TEID-Us (one for uplink, one for downlink). The local TEID-U value is chosen by the receiving entity and must be unique within the context of that receiving node for the given IP address and UDP port.

Architecturally, the TEID-U is managed by the control plane. During procedures like bearer establishment or modification, the GTP-C messages (e.g., Create Session Request/Response) carry TEID-U information elements. The node initiating the tunnel (e.g., SGW for the S5-U interface towards the PGW) includes its own TEID-U for the uplink direction in the request. The peer node (e.g., PGW) stores this TEID-U for sending downlink packets and generates its own TEID-U for the uplink direction, which it sends back in the response. This bidirectional exchange establishes the tunnel identifiers for both directions. The TEID-U is critical for mobility events like handovers. During an X2-based handover in LTE, the source eNB sends the TEID-U(s) of the data radio bearers to the target eNB in the HANDOVER REQUEST message, allowing the target eNB to begin receiving downlink data from the SGW immediately after the handover, minimizing data loss.

Purpose & Motivation

The TEID-U was created to solve the fundamental problem of multiplexing and routing user data packets within a tunnel-based packet core network, specifically within the 3GPP GPRS and later Evolved Packet System (EPS). Prior to standardized tunneling protocols, alternative packet routing mechanisms might have relied solely on IP routing tables or complex layer 2 circuits, which are inefficient for managing millions of simultaneous, mobile user sessions with specific quality-of-service (QoS) requirements. The GTP protocol, and the TEID-U within it, provides a lightweight, session-oriented overlay that abstracts the user's IP flow from the underlying transport IP network.

Its creation was motivated by the need for scalable and efficient user plane management. By using a simple 32-bit identifier locally scoped to a tunnel endpoint, the network can avoid inspecting the inner IP headers of user packets for forwarding decisions at every hop, improving performance. It enables seamless mobility and session continuity; as a user moves, the network can simply update the TEID-U mapping at the anchoring gateway (e.g., PGW) to point to a new SGW or access node, without disrupting the user's IP session. This design is central to the 'tunnel-based' mobility concept in 3GPP networks, separating the user's stable IP anchor point from the changing radio access points.

Classification

Part ofGTP-U
Related approachesGTP-C

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (12 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-15.

Rel-15 9 changes

In Release 15, the TEID-U function was impacted by the introduction of Control and User Plane Separation (CUPS), enabling the separate selection of SGW-U and PGW-U nodes via GTP-C. Furthermore, the specification reinforced that TEID values must be assigned in a non-predictable manner for PGW interfaces like S5/S8/S2a/S2b to enhance security. These changes were part of broader enhancements to GTP procedures, including support for indirect data forwarding tunnels and configuration transfer over interfaces like S10 and N26.

  • GTP-C Extensions for SGW-U and PGW-U selection with CUPS TS 29.274CR1825
  • Reporting WLAN Location during UE initiated IPsec tunnel update procedure TS 29.274CR1840
  • GTP-C tunnel per UE over the N26 interface TS 29.274CR1853
  • GTP-C messages over the N26 interface TS 29.274CR1854
  • Clarification to GTP-C overload control TS 29.274CR1879
  • Unpredictability of GTP TEID for PGW GTP-C TS 29.274CR1883

+ 3 more changes

Rel-16 1 change

In Release 16, the TEID-U function was enhanced to support IPv4/IPv6 capable GTP-C entities, as indicated by the CR title "IP addressing with IPv4/IPv6 capable GTP-C entities." This update allowed GTP control plane nodes to advertise and use both IPv4 and IPv6 addresses for establishing user plane GTP tunnels, ensuring the TEID-U remains uniquely identified alongside the appropriate IP address and UDP port.

  • IP addressing with IPv4/IPv6 capable GTP-C entities TS 29.274CR1956
Rel-17 2 changes

In Release 17, the TEID-U function was enhanced to support User Plane Integrity Protection for interworking from 5GS to EPS, ensuring secure tunneled payloads. Additionally, new signaling capabilities were introduced, enabling the support of Notify Start Pause of Charging via the User Plane. These updates expanded the role of GTP-U messages to carry specific signaling information elements alongside the traditional T-PDU payload.

  • Support of User Plane Integrity Protection for Interworking from 5GS to EPS TS 29.274CR2033
  • Support of Notify Start Pause of Charging via User Plane TS 29.274CR2010

Explore further

Broader topics and technologies where TEID-U plays a role.

Defining Specifications

3GPP specifications that define or reference TEID-U, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 29.274 vj50 GTPv2-C Control Plane Protocol Specification Rel-19