Fully Qualified Tunnel Endpoint Identifier

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.

Key Features

• Globally unique identifier combining TEID and IP address
• Mandatory for GTP tunnel establishment and management
• Used across multiple interfaces (e.g., S1-U, S5/S8, N3, N9)
• Supports mobility through dynamic endpoint updates
• Enables multiple bearers per UE with separate F-TEIDs
• Extensible to include IPv6 and interface type information

Evolution Across Releases

Defining Specifications