F1AP

F1 Application Protocol

Protocol →
Introduced in Rel-15

F1AP is the application layer protocol for the F1-C interface that defines signaling procedures between a gNB-CU and a gNB-DU for UE management, bearer control, and mobility in a disaggregated 5G RAN.

Category
Protocol
Introduced
Rel-15
Where
Radio Access Network › NG-RAN (5G)
Specifications
2 specs
F1AP Description Purpose Related Classification Detected Changes Specifications

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.

Classification

Part ofF1-C
Specific typesE1APF1-C
Related approachesSCTPRRC

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 2 changes

In Release 15, the F1 Application Protocol (F1AP) introduced support for multiple Transport Network Layer Associations (TNLAs) for the F1 Control Plane (F1-C) interface. This enhancement, clarified through a corresponding Change Request, allows a single gNB-CU-CP and gNB-DU pair to establish multiple SCTP associations for F1-C signalling. This provides improved reliability and load distribution for the control plane connection within the NG-RAN architecture.

  • CR to 38.401 on Multiple TNLAs for F1-C and E1 TS 38.401CR0063
  • Clarify the support for multiple TNLAs for F1-C TS 38.401CR0043
Rel-16 2 changes

In Release 16, F1AP introduced new capabilities for positioning support over the F1 interface and enhanced reliability through a procedure for SCTP association change upon association failure. These additions expanded the protocol's functionality to include location services and improved the robustness of the transport connection between the gNB-CU and gNB-DU.

  • Positioning support over F1AP TS 38.470CR0061
  • SCTP association change when current SCTP association is failed TS 38.401CR0137
Rel-17 2 changes

In Release 17, the F1 Application Protocol (F1AP) was enhanced to support new functionalities for Integrated Access and Backhaul (IAB) and sidelink. Specifically, the protocol was updated to enable the control of NR Sidelink Relay operations over the F1 interface, and corrections were made to the specified protocol stacks for carrying F1-C and F1-U traffic within the IAB network architecture.

  • (Stage-2 F1AP CR) support for NR Sidelink Relay TS 38.470CR0085
  • Correction on protocol stack for IAB TS 38.401CR0242
Rel-18 1 change

In Release 18, the F1AP specification introduced corrections to the general principles for supporting multicast reception for UEs in the RRC_INACTIVE state. This update specifically refined the protocol procedures and handling of UE-associated logical F1-connections to properly accommodate multicast services. The changes ensure that the gNB-CU and gNB-DU can correctly manage the necessary identifiers and signalling for this feature over the F1 interface.

  • 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.

SpecificationTitleRelease
TS 38.401 vj10 NG-RAN Architecture Specification Rel-19
TS 38.470 vj10 F1 Interface Introduction Rel-19