F-TEID

Fully Qualified Tunnel Endpoint Identifier

Identifier →
Introduced in Rel-8

F-TEID is a data structure that uniquely identifies a GTP tunnel endpoint by combining a TEID with an IP address, enabling routing of user data between network nodes in 3GPP systems.

Category
Identifier
Introduced
Rel-8
Where
Core Network › 5G Core
Specifications
5 specs
F-TEID Description Purpose Related Classification Detected Changes Specifications

Description

The Fully Qualified Tunnel Endpoint Identifier (F-TEID) is a cornerstone data structure in 3GPP mobile networks that enables the establishment and management of GPRS Tunnelling Protocol (GTP) tunnels. A GTP tunnel is a logical path used to carry user plane traffic (e.g., IP packets) between network nodes, such as between an eNodeB and a Serving Gateway (SGW) or between a SGW and a Packet Data Network Gateway (PGW) in 4G, or in 5G interworking scenarios. The F-TEID uniquely identifies one end of such a tunnel by comprising two mandatory components: the Tunnel Endpoint Identifier (TEID) and the IP address of the node hosting that tunnel endpoint. The TEID is a 32-bit locally significant value chosen by the receiving endpoint, but when paired with the IP address, the F-TEID becomes globally unique, allowing the sending endpoint to address packets precisely.

In operation, during procedures like Attach, Handover, or Bearer Establishment, network nodes exchange F-TEIDs in GTP control messages (e.g., Create Session Request/Response). For instance, when a SGW establishes a GTP tunnel with a PGW, the PGW allocates a TEID for its endpoint and sends its F-TEID (TEID + PGW IP address) to the SGW. The SGW then uses this F-TEID as the destination for all user data packets it sends towards the PGW within that specific bearer's tunnel. Conversely, the SGW provides its own F-TEID to the PGW for the reverse direction. This bidirectional exchange ensures that both ends know exactly where to send traffic. The F-TEID may also include optional fields like the IPv6 address or the Interface Type (e.g., S1-U, S5/S8), providing additional context.

The F-TEID's role is critical across multiple interfaces: S1-U between eNodeB and SGW, S5/S8 between SGW and PGW, and even in 5G for N3 (between gNB and UPF) and N9 (between UPFs) when GTP-U is used. It supports mobility by allowing tunnel endpoints to be updated during handovers—the target node provides a new F-TEID, and the source node redirects traffic accordingly. It also enables multiple bearers per user equipment (UE), as each bearer has its own dedicated F-TEIDs. In 5G, while PFCP and F-SEID are used for N4 control, GTP-U with F-TEIDs remains prevalent for user plane tunneling, ensuring backward compatibility and seamless interworking with 4G networks.

Purpose & Motivation

The F-TEID was created to solve the problem of uniquely identifying tunnel endpoints in a scalable, routable manner within GTP-based mobile networks. Prior to its formalization, tunnel management could be ambiguous if only a locally significant TEID was used, especially in networks with multiple nodes or complex routing. By combining the TEID with an IP address, the F-TEID ensures that GTP packets can be correctly routed across IP networks to the intended destination node, even in large, distributed deployments. This was essential for the evolution from 3G to 4G EPC, where user and control plane separation and increased data demands required robust tunneling mechanisms.

Its introduction in Release 8 with the Evolved Packet System (EPS) addressed the limitations of earlier tunneling identifiers that were less structured. The F-TEID standardized how tunnel endpoints are advertised and used, facilitating interoperability between equipment from different vendors. It supports network evolution by being extensible (e.g., adding IPv6 support) and by working across various interfaces. The F-TEID enables key features like mobility management (handovers between base stations or core nodes), multi-homing, and traffic differentiation through dedicated bearers. In 5G, it continues to be vital for user plane tunneling, particularly in scenarios involving 4G-5G interworking or dual connectivity, ensuring that user data flows seamlessly across heterogeneous network segments.

Classification

Part ofTEID
Related approachesF-SEID

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 3 changes

In Release 15, key clarifications and new procedures for the F-TEID were introduced, including an essential clarification on the CHOOSE bit in the F-TEID Information Element. The release also specified the release of an F-TEID by the UP Function upon the removal of a Packet Detection Rule (PDR) and defined the interface type for an AMF F-TEID alongside a new cause code.

  • Essential clarification on the CHOOSE bit in F-TEID IE TS 29.244CR0122
  • Release of F-TEID by the UP Function upon removal of PDR TS 29.244CR0235
  • Interface Type of an AMF F-TEID and new cause code TS 29.274CR1947
Rel-16 3 changes

In Release 16, the F-TEID function was enhanced to explicitly support its allocation and cleanup procedures at the User Plane (UP) function, as indicated by the new capability for F-TEID allocation at the UP function during Sx association setup. The release also formalized the inclusion of the F-TEID within a Packet Detection Rule (PDR), integrating it more directly into the forwarding control mechanisms for procedures like dedicated bearer activation and deactivation.

Rel-17 1 change

In Release 17, the primary update to the F-TEID function was the introduction of a new interface type, N19mb, for the Fully Qualified Tunnel Endpoint Identifier. This addition expands the set of defined interface types within the F-TEID data structure to support new forwarding scenarios or network functions. The change is documented in the corresponding specification update for the F-TEID.

  • New Interface Type N19mb in F-TEID TS 29.274CR2061

Explore further

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

Defining Specifications

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

SpecificationTitleRelease
TS 23.214 vj00 Control and User Plane Separation for EPC Rel-19
TS 23.527 vj50 5G System Restoration Procedures Rel-19
TS 29.244 vj40 PFCP Specification for Control/User Plane Separation Rel-19
TS 29.274 vj50 GTPv2-C Control Plane Protocol Specification Rel-19
TS 29.532 vj30 MB-SMF Service Based Interface Protocol Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.