TEID

Tunnel End Point Identifier

Identifier →
Introduced in Rel-4 Also in: Core Network, Services

TEID is a critical identifier used in GPRS, EPS, and 5GS to uniquely label GTP tunnels between network nodes for routing user data and control messages to the correct endpoints.

Category
Identifier
Introduced
Rel-4
Where
Radio Access Network › NG-RAN (5G)
Also touches
2 segments
Specifications
29 specs
TEID Description Purpose Detected Changes Specifications

Description

The Tunnel End Point Identifier (TEID) is a cornerstone of the GPRS Tunneling Protocol (GTP) used across 3GPP mobile networks from 3G to 5G. It is a 32-bit field present in the header of GTP-U (User plane) and GTP-C (Control plane) packets. Architecturally, a GTP tunnel is a logical point-to-point connection established between two GTP-speaking nodes, such as between a Serving Gateway (SGW) and a Packet Data Network Gateway (PGW) in 4G, or between a UPF and a SMF/UPF in 5G. The TEID uniquely identifies a specific tunnel endpoint at the receiving node. Crucially, both ends of a tunnel have their own local TEID values; the sender sets the TEID value that the receiver has assigned for that particular tunnel or bearer context.

How it works is fundamental to GTP-based mobility. When a Packet Data Protocol (PDP) context in 3G or a PDN connection/EPS bearer in 4G is established, control plane signaling (GTP-C) allocates TEIDs for the user plane tunnels (GTP-U). For example, during an LTE attach procedure, the MME instructs the SGW to create a session, and the SGW allocates a TEID for its downlink side of the S1-U tunnel towards the eNodeB and another for its uplink side of the S5/S8 tunnel towards the PGW. These TEIDs are exchanged via GTP-C messages. Subsequently, every user data packet carries the destination TEID in its GTP-U header. The receiving node (e.g., an eNodeB or a UPF) uses this TEID as a direct lookup key to find the associated bearer context, which contains all necessary information for processing the packet, such as QoS parameters and the next hop.

Its role extends beyond simple addressing. The TEID is the primary mechanism for bearer multiplexing. A single network node (like a SGW) manages thousands of simultaneous tunnels, each for a different UE or different QoS flow. The TEID allows the node to instantly demultiplex incoming GTP packets to the correct internal context without inspecting the inner IP packets. In 5G Core, the principle remains, though the architecture shifts to a service-based interface for control plane, with GTP-U still prevalent in the user plane between UPFs and (R)AN. The TEID's design ensures stateful, connection-oriented forwarding that is optimized for mobility and QoS enforcement across the mobile core network.

Purpose & Motivation

The TEID was created to solve the problem of managing multiple, simultaneous packet data sessions for millions of users in a scalable and efficient manner within mobile core networks. Prior to GPRS, data was primarily circuit-switched, which was inefficient for bursty IP traffic. The introduction of packet-switching required a tunneling mechanism to forward user IP packets between network nodes while preserving the subscriber's session context, QoS, and charging rules as they moved.

The GTP protocol, with the TEID at its heart, was designed to provide this tunneling capability. It addresses key limitations: it decouples the user's IP address (which can change) from the routing within the core network, enables seamless mobility by allowing tunnels to be re-routed as the user moves, and provides a simple, fast lookup mechanism for forwarding planes. The TEID specifically solves the multiplexing problem—allowing a single IP address/port pair on a network node to serve thousands of distinct user sessions. Its creation was motivated by the need for a standardized, robust tunneling protocol that could support the "always-on" IP connectivity model essential for mobile internet services, from early GPRS to modern 5G.

Detected Changes Across Releases

from 3GPP Change Requests

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

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

Rel-15 8 changes

In Release 15, the TEID function was enhanced to support a GTP-C tunnel per UE over the N26 interface and to improve security through the unpredictability of GTP TEIDs for both PGW GTP-C and GTP-U. It also introduced the ability to create and delete indirect data forwarding tunnels and expanded TEID usage for configuration transfer tunnels over the S10 and N26 interfaces. Furthermore, a new interface type for an AMF F-TEID was defined alongside a new cause code.

  • 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
  • Unpredictability of GTP TEID for PGW GTP-C TS 29.274CR1883
  • Create/Delete Indirect Data Forwarding Tunnel TS 29.274CR1881
  • Enhancements to Configuration Transfer Tunnel over S10 and N26 for EN-DC TS 29.274CR1940
  • Interface Type of an AMF F-TEID and new cause code TS 29.274CR1947

+ 2 more changes

Rel-16 4 changes

In Release 16, changes to the TEID function included a correction for IPv6 Flow Label handling specifically for IAB nodes using IPsec tunnel mode, and an update concerning temporary identifier usage during network interworking scenarios. These modifications addressed specific procedural and interface handling details without introducing new core TEID capabilities.

  • Temporary Identifier usage at interworking TS 36.413CR1643
  • Deletion of the test case on TEID TS 33.515CR0005
  • CR to 38.401: Correction on IPv6 Flow Label handling for IAB using IPsec tunnel mode TS 38.401CR0193
  • Correction of connected en-gNB Identifier TS 36.300CR1289
Rel-17 11 changes

In Release 17, the TEID function was enhanced to support new interfaces and multicast services. Specifically, a new Interface Type **N19mb** was introduced in the F-TEID for **GTP-U tunneling**, and clarifications were made for handling shared NG-U tunnels for multicast. Additionally, procedures were introduced to monitor tunnel status, such as notifying a pause of charging and reporting data packet loss per TEID.

  • Add incoming and outgoing GTP data packet loss TEID TS 28.552CR0256
  • GTP-U tunneling for N3mb and N19mb TS 29.281CR0115
  • MBS Frequency Selection Area Identifier TS 29.532CR0008
  • Ingress Tunnel Address Change Status Event TS 29.532CR0013
  • Add one more trigger point to the number of failed DAPS handover preparations performance measurement TS 28.552CR0343
  • Fix editor notes for Tunnel-Password TS 29.061CR0545

+ 5 more changes

Rel-18 3 changes

In Release 18, a specific clarification was made regarding the inclusion of the PGW-C TEID within the Update Bearer Response message procedure. This change addresses the scenario of PDN connection restoration triggered by the PGW. The update provides precise guidance for this bearer management process without altering the fundamental definition or operation of the TEID itself.

  • Correct the instance number of the AMF Identifier TS 29.274CR2085
  • Clarification of satellite identifiers TS 36.300CR1430
  • PGW-C TEID in Update Bearer Response during PGW triggered PDN connection restoration TS 29.274CR2076
Rel-19 1 change

In Release 19, the TEID function was enhanced by introducing fixes for the GTP-U Tunnel Status Information and Recovery Time Stamp Information Elements. This update specifically addressed the procedural handling of these IEs to improve tunnel management reliability. The changes ensured more robust signaling for tunnel status and recovery mechanisms within the core network.

  • Fixing the GTP-U Tunnel Status Information and Recovery Time Stamp IEs TS 29.281CR0134

Explore further

Broader topics and technologies where TEID plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.060 vj00 GPRS Service Description Stage 2 Rel-19
TS 23.527 vj50 5G System Restoration Procedures Rel-19
TS 25.401 vj00 UTRAN Overall Architecture Rel-19
TS 25.413 vj00 Radio Access Network Application Part (RANAP) Rel-19
TS 25.414 vj00 UTRAN Iu Interface User Plane Transport Protocols Rel-19
TR 25.931 vj00 UTRAN Signalling Procedures Examples Rel-19
TS 26.804 vj10 5G Media Streaming Extensions Study Rel-19
TS 28.552 vk10 5G Performance Management Measurements Rel-20
TS 29.060 vj00 GPRS Tunnelling Protocol (GTP) version 1 Rel-19
TS 29.061 vj00 Packet Domain Interworking for PLMN Rel-19
TS 29.119 vj00 GTP for GLR in 3GPP Networks Rel-19
TS 29.274 vj50 GTPv2-C Control Plane Protocol Specification Rel-19
TS 29.276 vj00 EPS S101/S121/S103 Interfaces Stage 3 Rel-19
TS 29.281 vj20 GTPv1-U Protocol Specification Rel-19
TS 29.532 vj30 MB-SMF Service Based Interface Protocol Rel-19
TS 33.515 vk00 5G SMF Security Assurance Specification Rel-20
TS 36.300 vj00 E-UTRAN Radio Interface Protocol Architecture Overview Rel-19
TS 36.413 vj10 S1 Application Protocol (S1AP) Rel-19
TS 36.414 vj00 S1 Interface User Plane Transport Rel-19
TS 36.424 vj00 X2 Interface User Plane Transport Protocols Rel-19
TS 36.444 vj00 M3AP Protocol Specification for M3 Interface Rel-19
TS 36.445 vj00 M1 interface user plane protocol for MBMS Rel-19
TS 38.340 vj00 Backhaul Adaptation Protocol (BAP) Specification Rel-19
TS 38.401 vj10 NG-RAN Architecture Specification Rel-19
TS 38.414 vj00 NG Interface User Plane Protocol Rel-19
TS 38.424 vj00 Xn Interface User Plane Transport Protocol Rel-19
TS 38.474 vj00 F1 Interface User Plane Protocol Rel-19
TS 44.318 vj00 Generic Access Network (GAN) Interface Procedures Rel-19