Description
The F1-U interface is the user plane counterpart to the F1-C within the 3GPP disaggregated gNB architecture. It provides the data path for user traffic between the CU's user plane component (CU-UP) and the DU. The interface is designed to carry encapsulated user data packets using the GPRS Tunneling Protocol for the user plane (GTP-U) over a UDP/IP transport layer. This tunneling mechanism allows for the multiplexing of data flows from multiple UEs and bearers over a single F1-U association between a CU-UP and a DU.
Operationally, for each established Data Radio Bearer (DRB), one or more GTP-U tunnels are set up over the F1-U interface. The CU-UP, which houses the PDCP layer for the user plane, performs functions like header compression, ciphering, and integrity protection. It then forwards the processed PDCP Protocol Data Units (PDUs) to the DU via the appropriate GTP-U tunnel. The DU, responsible for the RLC, MAC, and PHY layers, receives these PDCP PDUs, segments them if necessary (at RLC), schedules them for transmission (at MAC), and finally sends them over the air interface to the User Equipment (UE). The reverse path is followed for uplink data.
The architecture of the F1-U is defined to be independent of the F1-C, allowing the user plane traffic to be routed over potentially different network paths for optimization. This separation is crucial for enabling high-throughput, low-latency data delivery. The interface supports data forwarding during handover procedures to minimize data loss. Furthermore, the F1-U's design aligns with network slicing requirements, as different QoS flows can be mapped to different DRBs and subsequently transported over the F1-U with appropriate prioritization within the transport network.
Purpose & Motivation
The F1-U interface was developed to facilitate the user plane separation mandated by the CU-DU split in 5G. In monolithic 4G eNBs, user data processing and radio transmission were tightly coupled within the same hardware, limiting deployment options. The F1-U enables the physical and logical separation of the user plane processing function (in the CU-UP) from the radio transmission/reception function (in the DU).
This separation solves several key problems. It allows network operators to centralize user plane processing in cost-effective data centers (CU pools), achieving statistical multiplexing gains and simplifying the implementation of advanced features like edge computing. The DUs can remain as simpler, potentially mass-produced radio units deployed at cell sites. This architecture reduces fronthaul bandwidth requirements compared to a more stringent split like CPRI, as the F1-U carries partially processed packet data rather than raw IQ samples.
The creation of the F1-U, alongside the F1-C, was motivated by the need for RAN virtualization and cloudification. By defining a standard packet-based user plane interface, 3GPP enabled the CU-UP to be implemented as a Virtual Network Function (VNF) or Cloud Native Network Function (CNF) on commercial off-the-shelf servers. This drives down costs, increases service agility, and paves the way for AI/ML-based optimization in the RAN. The F1-U is thus essential for realizing the economic and performance promises of 5G networks, including support for enhanced Mobile Broadband (eMBB) and Ultra-Reliable Low-Latency Communications (URLLC) services.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (4 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-15, normative work from Rel-17.
In Release 17, the F1-U interface was enhanced to support multicast and broadcast services (MBS), introducing the use of shared F1-U tunnels for Multicast Radio Bearer (MRB) with Point-to-Multipoint (PTM) transmission. The release also clarified the definition and management of a Multicast F1-U Context within the gNB-DU, which can consist of multiple MRB contexts and corresponds to one or several F1-U tunnels. Furthermore, procedures were specified for the gNB-DU to trigger the establishment of F1-U resources and to signal Radio Link Outage/Resume notifications over the F1-U interface.
In Release 18, a specific enhancement for the F1-U interface introduced procedures for MBS (Multicast Broadcast Service) failure recovery, as indicated by the correction of the "MBS F1-U failure Recovery" mechanism. The release also further detailed the use of F1-U for signaling Radio Link Outage and Resume notifications via Data Delivery Status (DDDS) PDUs for individual data radio bearers. Furthermore, it elaborated on the management of F1-U tunnels for MBS sessions, including the criteria for establishing shared or UE-dedicated tunnels for multicast and broadcast services.
- Correction of MBS F1-U failure Recovery - option 1 TS 38.401CR0392
In Release 19, the primary update for the F1-U interface was a correction to its stage 2 specification concerning AI/ML (AIML). This release further clarified the use of F1-U for signaling Radio Link Outage and Resume notifications via the DDDS PDU and detailed procedures for migrating F1-U tunnels during IAB-node handover or redundant path addition.
- Correction on AIML F1-U stage2 TS 38.470CR0170
Explore further
Broader topics and technologies where F1-U plays a role.
Defining Specifications
3GPP specifications that define or reference F1-U, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 38.401 vj10 | NG-RAN Architecture Specification | Rel-19 |
| TS 38.470 vj10 | F1 Interface Introduction | Rel-19 |