Description
The F1 Application Protocol (F1AP) is the core signaling protocol that enables control plane communication between the Central Unit (CU) and Distributed Unit (DU) of a disaggregated 5G gNB. It operates on top of Stream Control Transmission Protocol (SCTP) over IP, providing a reliable transport for its messages. F1AP defines a comprehensive set of Elementary Procedures (EPs), which are the fundamental units of interaction between the CU and DU. These procedures are categorized into Class 1 (requiring a response) and Class 2 (not requiring a response).
The protocol works through the exchange of F1AP messages, each carrying Information Elements (IEs) that contain the necessary parameters for a given procedure. Key functional areas covered by F1AP include: Interface Management (e.g., F1 setup, gNB-DU configuration update, error indication), UE Context Management (e.g., UE context setup, modification, and release), RRC Message Transfer (transparent conveyance of RRC messages between the CU's RRC layer and the UE via the DU), and Bearer Management (controlling the setup and modification of Data Radio Bearers). Furthermore, F1AP handles mobility procedures, such as handover preparation, and system information management, where the CU provides the SI messages to be broadcast by the DU.
From an architectural perspective, F1AP resides in the CU-CP (Control Plane) and the DU. Each F1AP message is associated with a specific UE context (for UE-associated signaling) or with the entire F1 interface (for non-UE-associated signaling). The protocol is designed to be efficient and scalable, supporting the management of thousands of UEs connected to a single DU. Its robust error handling and recovery mechanisms ensure the stability of the F1 interface, which is critical for maintaining service continuity in the RAN.
Purpose & Motivation
F1AP was created to provide a standardized, robust, and feature-rich signaling protocol for the new F1 interface introduced with the 5G CU-DU split. Prior to 5G, the internal communication within a base station was proprietary and vendor-specific, as the eNB was a monolithic entity. The disaggregation of the gNB into CU and DU necessitated an open, interoperable protocol to manage the complex coordination between these two network functions.
The protocol solves the fundamental problem of how a centralized control entity (the CU-CP) can command and manage a distributed radio unit (the DU) that handles the physical layer. It provides the necessary language for all control interactions, from bringing a UE into the network to managing its mobility and quality of service. Without F1AP, the CU and DU from different vendors would be unable to work together, defeating the purpose of an open interface.
Historically, the development of F1AP was influenced by the similar X2AP protocol used for inter-eNB communication in 4G, but it was designed from the ground up to address the specific needs of an *intra*-gNB interface with tighter integration and more comprehensive control. Its creation was motivated by the industry's push towards virtualization, cloudification, and Open RAN. F1AP is the enabling glue that makes the 3GPP-defined functional split practical, allowing operators to deploy flexible, scalable, and cost-effective RAN architectures while maintaining full control over radio resources and user sessions.
Protocol Stack
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (3 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-16.
In Release 16, the F1AP protocol introduced support for positioning procedures over the F1 interface. Furthermore, it was enhanced to support Multicast Broadcast Service (MBS) sessions by defining new MBS-associated logical F1-connections and corresponding identifiers, such as the gNB-CU MBS F1AP ID and gNB-DU MBS F1AP ID. The release also added specific procedures, like enabling multicast reception for UEs in RRC_INACTIVE state and the gNB-CU triggered Multicast Context Modification procedure for retrieving PTM configuration information.
- Positioning support over F1AP TS 38.470CR0061
In Release 17, the F1 Application Protocol (F1AP) was enhanced to support NR Sidelink Relay. This introduced new UE-associated signalling procedures over the F1 interface to manage relay connections, utilizing the existing gNB-CU UE F1AP ID and gNB-DU UE F1AP ID for unique identification within their respective logical nodes.
- (Stage-2 F1AP CR) support for NR Sidelink Relay TS 38.470CR0085
In Release 18, F1AP introduced new procedures to support multicast reception for UEs in the RRC_INACTIVE state, specifically enabling and disabling this reception for a specific multicast MBS session on a per-cell basis. This enhancement includes a gNB-CU triggered Multicast Context Modification procedure for retrieving PTM configuration information from the gNB-DU. Furthermore, the release defined new MBS-associated logical F1-connections, identified by unique gNB-CU MBS F1AP ID and gNB-DU MBS F1AP ID pairs, to manage MBS session contexts separately from UE-associated signaling.
- Correction on general F1AP principles for multicast reception in RRC_INACTIVE TS 38.401CR0403
Explore further
Broader topics and technologies where F1AP plays a role.
Defining Specifications
3GPP specifications that define or reference F1AP, 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 |