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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (34 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, new procedures were introduced for the F-TEID function, including the explicit release of an F-TEID by the UP Function upon the removal of a Packet Detection Rule (PDR). The release also enabled the establishment of indirect data forwarding tunnels and introduced enhancements for managing GTP-C tunnels per UE over the N26 interface.
- Essential clarification on the CHOOSE bit in F-TEID IE TS 29.244CR0122
- Outer Header Removal for IPv4v6 GTP-U tunnel TS 29.244CR0187
- Clarification on forwarding user plane data via a shared Sx-u tunnel TS 29.244CR0198
- Release of F-TEID by the UP Function upon removal of PDR TS 29.244CR0235
- 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
+ 4 more changes
In Release 16, the F-TEID function was updated to provide explicit clarification and procedures for its allocation and cleanup by gateway user planes, particularly within Packet Detection Rules (PDRs). This included defining F-TEID operations for specific procedures like Dedicated Bearer Activation and traffic forwarding between 3GPP and non-3GPP accesses, as managed via Sx Session Modification Requests. Additionally, the release addressed the removal of N9 forwarding tunnels and refined the interface type specification for traffic endpoints.
In Release 17, the F-TEID function was extended to support the new N19mb interface type for multicast-broadcast service (MBS) user plane forwarding, as indicated in the CR title. Furthermore, clarifications were provided on tunnel information handling, including the behavior for a shared NG-U tunnel in MBS and the definition and format for a Tunnel Password information element. The release also introduced support for establishing an N9 forwarding tunnel between ULCLs controlled by an I-SMF.
- MBS Session Identifier TS 29.244CR0621
- MBS Frequency Selection Area Identifier TS 29.532CR0008
- Ingress Tunnel Address Change Status Event TS 29.532CR0013
- Missing Definition for Tunnel Password IE TS 29.244CR0602
- Two N3 UL CN tunnels information TS 29.244CR0630
- Format of Tunnel Password TS 29.244CR0632
+ 5 more changes
In Release 18, the F-TEID function was enhanced to support new tunneling scenarios and received clarifications on its existing usage. Specifically, new support was defined for establishing N6 tunneling between a V-UPF and a V-EASDF for specific PDU sessions and for managing L2TP tunnel parameters on the SGi interface, including handling tunnel failure. Additionally, the release provided clarifications on the use of F-TEIDs in procedures like indirect downlink data forwarding and within the Local Ingress Tunnel information element.
- N6 tunneling between V-UPF and V-EASDF for HR-SBO PDU sessions with overlapping IP addresses TS 29.244CR0847
- L2TP tunnel failure cause TS 29.244CR0670
- Clarification to the Local Ingress Tunnel IE TS 29.244CR0704
- Flow description within MBS Service Information if MBS data are transported in IP tunnel toward MB-UPF TS 29.244CR0770
- Source/Destination Interface Type for Indirect DL Data Forwarding Tunnels TS 29.244CR0782
- Correct the instance number of the AMF Identifier TS 29.274CR2085
+ 1 more changes
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.
| Specification | Title | Release |
|---|---|---|
| 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 |