F1AP in 5G-NR

F1 Application Protocol (F1AP) is the control‑plane bridge between gNB‑CU and gNB‑DU in 5G‑NR. It manages DU onboarding, cell inventory, UE context, RRC message transport, paging, inactivity, and resets. Paired with F1‑U for user plane, it is the backbone of disaggregated/O‑RAN deployments.

Why F1AP Matters

F1AP is not just a control protocol; it is the operational contract between a centralized brain (gNB‑CU) and distributed muscles (gNB‑DU). When you disaggregate the gNB, you split where intelligence (RRC/PDCP policy, mobility, QoS orchestration) resides from where time‑critical execution (RLC/MAC/PHY scheduling, HARQ, PRACH handling) happens.

F1AP ensures both sides:

• Discover each other cleanly (F1 Setup) and keep an accurate inventory of cells (DU Config Update, Cell Activate/Deactivate).
• Establish and evolve UE context end‑to‑end (SRB/DRB creation, security, DRX, BWP, carrier aggregation knobs).
• Ferry RRC reliably (Initial UL, DL/UL RRC Message Transfer) so the CU can drive configuration while DU keeps radio timing.
• Optimize control‑plane load via RRC Inactive and fast Resume, saving battery, air‑time, and CU/DU cycles.
• Recover fast from faults (UE‑associated/Full Reset), preserving service continuity.
• Close the loop: DU measurements → CU analytics/xApps → RRC Reconfiguration back via F1, enabling adaptive BWP, beam recovery parameters, slice QoS enforcement, and energy‑save.

What is F1?

F1 is composed of two logical planes that travel over IP:

F1‑C (Control Plane): F1AP over SCTP/IP between CU‑CP ↔ DU.
You use it for:

• Bring‑up & topology: F1Setup, gNB‑DU Configuration Update, gNB‑CU Configuration Update, Cell Activate/Deactivate.
• UE life‑cycle: UE Context Setup/Modification/Release with SRB/DRB lists, security, DRX, BWP, SCells.
• RRC ferrying: Initial UL RRC Message Transfer, DL/UL RRC Message Transfer, optional RRC Delivery Report.
• State efficiency: UE Inactivity Notification, UE Context Suspend/Resume, Paging.
• Fault handling: Reset (UE‑associated or Full) and Error/Warning Indication.

F1‑U (User Plane): GTP‑U/UDP/IP between CU‑UP ↔ DU.
It carries:

• DRB user traffic encapsulated with F1‑U sequence numbers.
• Delivery feedback & pacing hints: Highest delivered PDCP SN (per DRB), lost F1‑U packets, desired buffer size (per DRB), and minimum desired buffer (per UE). These fields let CU‑UP pace PDCP intelligently toward the DU scheduler.

Functional Split (Option‑2)

• CU: PDCP (SRB/DRB), SDAP, RRC, NGAP.
• DU: RLC, MAC, PHY, beam execution, HARQ, PRACH

Where it fits with O‑RAN:

• F1 remains 3GPP‑standard between CU↔DU.
• O‑RAN adds Open Fronthaul (DU↔RU, split 7.2x C/U/S planes) and E2 (CU↔RIC for xApp/rApp policy).
• In practice, xApps adjust policies at CU; all UE‑facing changes still ride F1 as RRC messages toward the DU for on‑air execution.

F1‑C Procedures

F1 Setup & Configuration Updates

Admit a DU under a CU and synchronize served cells & capabilities. CU may send Cells‑to‑Activate, Available PLMN List, and CU System Information (to broadcast). DU may reconfigure NR‑PCI and other cell params per CU policy. Use Config Updates to add/modify/delete cells cleanly.

UE Context Management procedures

UE context management on F1 keeps the CU’s policy state and the DU’s radio state in lockstep,covering SRBs/DRBs, security, DRX/BWP, and measurement/config controls. It operates through CU-initiated Setup/Modification/Release and DU-initiated Modification Required/Release Request, each returning precise per-item success/failure causes for deterministic behavior. The result is mid-session optimization without full re-establishment and clean teardown that prevents zombie contexts or state drift.

UE CONTEXT SETUP (CU↔DU)

• CU→DU: UE CONTEXT SETUP REQUEST creates the UE’s radio context in the DU (SRB/DRB, security, DRX/BWP, etc.).
• DU→CU: UE CONTEXT SETUP RESPONSE returns per-item success/failure and causes.
• Result: UE-associated logical F1 connection becomes active; DU is ready to serve the UE.

UE CONTEXT RELEASE (DU-initiated)

• DU→CU: UE CONTEXT RELEASE REQUEST when DU needs to drop the UE (e.g., RLF, local failure, maintenance).
• CU tears down policy/state and coordinates clean release of F1 resources.
• Keeps core/state in sync—no zombie UE context at the CU.

UE CONTEXT RELEASE (CU-initiated)

• CU→DU: UE CONTEXT RELEASE COMMAND instructs DU to free radio/F1 resources for that UE.
• DU→CU: UE CONTEXT RELEASE COMPLETE confirms teardown finished on the DU side.
• Used for idle moves, HO cleanup, policy changes, or fault recovery.

UE CONTEXT MODIFICATION (CU-initiated)

• CU→DU: UE CONTEXT MODIFICATION REQUEST updates SRBs/DRBs, DRX, BWP/SCells, QoS mapping, etc.
• DU→CU: UE CONTEXT MODIFICATION RESPONSE reports per-item success/failure with causes.
• Enables mid-call optimization without full release/re-setup.

UE CONTEXT MODIFICATION REQUIRED (DU-initiated)

• DU→CU: UE CONTEXT MODIFICATION REQUIRED asks CU to adjust context due to DU/local radio conditions.
• CU→DU: UE CONTEXT MODIFICATION CONFIRM accepts (or rejects) and finalizes the change.
• Let’s DU signal needs (e.g., resource pressure, config mismatch) while CU stays in control.

RRC Ferrying (DL/UL)

RRC ferrying on F1 is how the CU and DU exchange RRC PDUs reliably. The Initial UL RRC Message Transfer from the DU carries the first Layer-3 message to the CU and, if needed, establishes the UE-associated logical F1 connection. Subsequent control flows use DL/UL RRC Message Transfer in both directions for messages like RRC Setup, Reconfiguration, Resume, and MeasurementReport. When required, the DU sends an RRC Delivery Report to the CU as an explicit acknowledgment that a downlink PDCP PDU carrying RRC was delivered over the air.

• When: DU → CU after the DU transmits a downlink RRC PDU to the UE (sent if reporting is configured/requested).
• What it carries: UE F1AP IDs and a reference to the delivered PDU (e.g., PDCP/RRC info), with status/cause to confirm success.
• Why it matters: Lets the CU confidently advance procedures/timers (e.g., after RRC Setup/Reconfig) or trigger recovery if delivery isn’t reported.

Paging & Inactivity / Resume

In F1, paging and inactivity work together to keep control-plane lean without losing responsiveness. The CU initiates paging toward selected cells, tagging each request with DRX and priority; the DU then pages only the cells in the Paging Cell List, honoring the DRX to match the UE’s listening cycle. When the DU detects prolonged silence, it sends a UE Inactivity Notification, after which the CU may Suspend the UE context to RRC Inactive, freeing DU resources while retaining the essentials for a quick comeback. On wake-up (e.g., MO-data), the UE sends RRCResumeRequest to the DU; the DU triggers UE Context Resume Request to the CU, and the CU restores SRBs/DRBs/security and returns RRCResume via DL RRC Message Transfer for immediate service. Proper tuning is key: align Paging DRX with suspend thresholds and avoid over-aggressive inactivity timers that cause ping-pong between Connected and Inactive. The result is lower signaling load, better UE battery life, and near-instant resume perceived by the user.

Reset (Partial vs Full)

In F1, Reset is the clean-state lever for faults, config churn, or UE list mismatches. A UE-associated Reset targets only the listed UEs—both CU and DU release F1 resources/IDs for those UEs and the peer ACKs with the same UE list order. A Full Reset clears all UE contexts on the interface; after that, replay DU Configuration (cells/resources) if needed. By rule, any parallel per-UE procedures on that F1 interface (except another Reset) are aborted to guarantee a deterministic recovery.

F1AP setup procedure

The F1AP setup procedure brings a gNB-DU under control of a gNB-CU and aligns their cell inventory and transport, so the CU can start managing UE contexts and policies. It starts with the DU advertising who it is and what cells it serves; the CU accepts and may immediately tell the DU which cells to activate and what PLMNs/System Information to broadcast. Next, both sides reconcile any differences via configuration updates—first from the DU (what it really has), then from the CU (what it wants active/deactivated, plus any transport-association tweaks). Acks on each step confirm the authoritative view. After cells are active, the network can proceed with neighbor (Xn/X2) setup. If anything goes out of sync, a Reset (UE-associated or full) cleans state, followed by replay of configuration so inventories match again.

• From DU to CU — F1SetupRequest: The DU identifies itself, advertises served cells, shares versions and transport details.
• From CU to DU — F1SetupResponse: The CU accepts, returns its identity/versions, and may order cell activation plus PLMN/System Info.
• From DU to CU — gNB-DU Configuration Update: The DU reports cells to add/modify/delete and status.
• From CU to DU — gNB-CU Configuration Update Acknowledge: The CU confirms which DU inventory changes are accepted.
• From CU to DU — gNB-CU Configuration Update: The CU mandates cells to activate/deactivate and may change transport associations.
• From DU to CU — gNB-DU Configuration Update Acknowledge: The DU confirms the CU’s policy push and flags any activation/TNL issues.
• Optional — Neighbor setup (Xn/X2): Performed after cells are on-air to enable inter-gNB mobility.
• If needed — Reset in both directions (DU ↔ CU): Either side can trigger Reset; the peer acknowledges, then config is replayed to re-align state.

F1‑U Procedures

On the F1 user plane (F1-U), the CU-UP sends and receives user data to/from the DU using GTP-U tunnels per DRB. The DU decapsulates to RLC/MAC/PHY (DL) and encapsulates uplink back to CU-UP, while control feedback about delivery and buffering travels on F1-C so the CU can pace PDCP intelligently. This keeps QoS (via SDAP→DRB mapping) and latency stable across the CU↔DU split.

• F1-U runs over GTP-U/UDP/IP between the CU-UP and DU, with one TEID per DRB in typical deployments.
• In downlink, the CU-UP encapsulates PDCP PDUs in GTP-U and the DU forwards them to RLC/MAC/PHY for transmission to the UE.
• In uplink, the DU reassembles at RLC/MAC and sends user data via GTP-U to the CU-UP for PDCP and SDAP processing.
• SDAP maps QoS flows to DRBs, and the DU scheduler enforces the 5QI priorities and delay budgets.
• Over F1-C, the DU reports highest delivered PDCP SN, any lost F1-U packets, and desired or minimum desired buffers so the CU-UP can adjust its send rate.
• The DU can buffer downlink data for UEs in RRC Inactive, and new downlink arrival may trigger paging or resume.
• During intra-CU mobility, new F1-U tunnels are created toward the target DU and optional data forwarding reduces loss.
• Stable operation requires CU↔DU RTT near 5–10 ms, correct MTU/IPsec settings, careful TEID management after DU restarts, and continuous monitoring of DU buffer and lost-packet indicators.

F1AP is the control-plane protocol that connects the Central Unit (CU) and Distributed Unit (DU) in a 5G gNB, forming the backbone of the disaggregated RAN and O-RAN architecture. Operating over the F1-C interface (F1AP/SCTP/IP) and paired with F1-U (GTP-U/UDP/IP) for user data, it enables smooth coordination between the CU (handling PDCP/RRC logic) and DU (handling RLC/MAC/PHY execution). The article explains how F1AP manages DU onboarding, cell configuration, UE context setup/modification/release, RRC message transport, paging, inactivity handling, and resets. It also details how F1-U supports user-plane traffic flow with delivery status feedback that allows PDCP pacing at the CU. Together, these functions enable scalability, mobility, energy efficiency, and QoS assurance across multi-DU networks. Diagrams illustrate F1 setup, UE context flows, and user-plane feedback paths, offering both procedural clarity and real-world operational insights.

References

• 3GPP TS 38.473 – NG-RAN; F1 Application Protocol (F1AP).
• 3GPP TS 38.470-38.472 – F1 general, F1-C, and F1-U architecture and transport.
• 3GPP TS 38.401 – NG-RAN; Architecture description.
• 3GPP TS 38.300 – NR and NG-RAN overall description.
• O-RAN WG4 Specifications – Open Fronthaul and transport control framework between DU and RU.