F1AP (F1 — CU ↔ DU) in 5G NR
F1 Setup and UE context management between the gNB-CU and gNB-DU.
When a gNB is split into a central unit and one or more distributed units, the wire between them is the F1 interface, and F1AP is the control protocol that drives it. It is how the gNB-CU — which owns RRC and PDCP — commands the gNB-DU, which owns RLC, MAC and the physical layer. Everything on F1 flows from one fact: the DU cannot read RRC, so the CU has to reach into it over a standardised contract. F1AP is that contract, defined in TS 38.473 with the interface framed by TS 38.470.
Introduction
F1AP (F1 Application Protocol) is the application-layer signalling protocol on the F1 interface inside a disaggregated gNB, specified in TS 38.473. It connects the gNB-CU (central unit) to its gNB-DU(s) (distributed units) and is what makes the CU/DU split behave as one logical gNB to the outside world.
F1AP matters because 5G, unlike LTE, standardises the gNB as a split node: the expensive, centralisable functions (RRC, SDAP, PDCP) live in the CU, and the real-time radio functions (RLC, MAC, PHY) live in DUs near the antennas. That split only works if the two halves can talk over an open, multi-vendor interface. F1AP is that interface's control plane — it brings cells into service, manages every UE the DU serves, and shuttles RRC across the seam.
It is best understood as the one-layer-down sibling of NGAP. Where NGAP lets the whole gNB talk to the 5G core, F1AP lets the two pieces of the gNB talk to each other — same ASN.1/SCTP family, same per-UE two-identifier pattern, but bounded entirely inside the RAN node.
On this page
Why F1AP is needed
In plain words: think of the CU as a head chef writing the menu and the DUs as line cooks at the stations. The head chef decides what the dish is (RRC, security, QoS) but never touches a pan; the line cooks own the heat, timing and plating (RLC/MAC/PHY) but do not invent the menu. A dish needs both halves — so the kitchen runs on order tickets passed back and forth in a fixed format: the chef sends down a ticket, the cook fills in the parts only they know (cooking times, which burner) and sends it back, and the chef finalises the plate. F1AP is that ticket system, and the half-built RRCReconfiguration is the ticket.
Concretely, splitting the gNB creates a problem the protocol has to solve: no single node holds a complete picture of a UE. The CU owns RRC and PDCP, so only it can encode or decode the RRC message and cipher the traffic; the DU owns RLC/MAC/PHY, so only it knows the radio-bearer parameters (CellGroupConfig) and the real-time cell load for admission control. To configure a UE you must combine both. F1AP is the standard that lets the CU command the DU, lets the DU report what only it knows, and carries RRC across the gap — all in a vendor-neutral way so a CU and DU from different suppliers interoperate.
The signalling protocol on the F1 interface between one gNB-CU and its gNB-DU(s). It manages cells and the interface, and it manages every UE that the DU serves — but it never processes RRC itself.
The CU/DU split lets one CU centralise RRC and PDCP for many DUs — pooling, simpler mobility, flexible placement of the expensive central functions. F1AP is the standard so a CU and DU from different vendors interoperate.
F1-C is F1AP over SCTP. RRC messages ride across as opaque RRC-Container IEs. Per-UE work is bound to a UE-association keyed by a pair of IDs: gNB-CU UE F1AP ID + gNB-DU UE F1AP ID.
What F1AP Is
F1AP is the application-layer signalling protocol spoken between a gNB-CU and a gNB-DU. It is the direct analogue, one layer down, of NGAP on the NG interface: where NGAP lets the gNB talk to the 5G core, F1AP lets the two halves of a disaggregated gNB talk to each other. It carries the control plane, F1-C; the paired user plane F1-U is plain GTP-U tunnelling of user data.
Like NGAP and the rest of the family, F1AP is defined in ASN.1 and encoded with aligned PER, and its work is organised into elementary procedures (an initiating message plus, for class 1 procedures, a defined success/failure response). That shared grammar is why the CU/DU seam feels so much like the RAN/core seam: the same extensibility and criticality machinery, the same class discipline, the same two-ID association pattern — just bounded inside the gNB.
The signalling protocol on the F1 interface between one gNB-CU and its gNB-DU(s). It manages cells and the interface, and it manages every UE that the DU serves — but it never processes RRC itself.
The CU/DU split lets one CU centralise RRC and PDCP for many DUs — pooling, simpler mobility, flexible placement of the expensive central functions. F1AP is the standard so a CU and DU from different vendors interoperate.
F1-C is F1AP over SCTP. RRC messages ride across as opaque RRC-Container IEs. Per-UE work is bound to a UE-association keyed by a pair of IDs: gNB-CU UE F1AP ID + gNB-DU UE F1AP ID.
Layer ownership drives everything: the CU terminates RRC and PDCP; the DU terminates RLC, MAC and PHY. So on F1, RRC is never "spoken" — it is carried. The DU relays an RRC PDU to or from the CU inside an F1AP container, and the CU is the only entity that actually encodes or decodes it. Almost every quirk of F1AP is a consequence of that single division of labour. See CU/DU/RU Split.
The CU/DU Functional Split
Before the protocol makes sense you have to know exactly where the protocol stack is cut. A monolithic gNB runs the whole radio stack — RRC, PDCP, RLC, MAC, PHY — in one box. The disaggregated gNB cuts that stack between PDCP and RLC. This is the "higher-layer split" (option 2 in the 3GPP study), and it is the split F1 standardises.
| Node | Layers it terminates | Responsibilities |
|---|---|---|
gNB-CU | RRC, SDAP, PDCP | Encodes/decodes all RRC; ciphering and integrity; QoS-flow to DRB mapping; hosts the NG and Xn interfaces toward core and neighbours; makes admission and mobility decisions. |
gNB-DU | RLC, MAC, PHY | Owns the cell radio: scheduling, HARQ, segmentation/ARQ, the physical channels; builds the lower-layer CellGroupConfig; serves and broadcasts the cell; hosts the radio-side F1-U tunnel endpoint. |
Two consequences follow immediately and shape the whole protocol. First, because PDCP lives in the CU, all user data must reach the CU: the F1-U tunnel carries PDCP PDUs down to the DU (which puts them on RLC) and up from the DU. Second, because RRC lives in the CU but the radio-bearer configuration lives in the DU, no single node can build a complete RRCReconfiguration. The CU owns the RRC message; the DU owns the CellGroupConfig (the RLC/MAC/PHY parameters) that must go inside it. F1AP therefore has to shuttle a half-built RRC message between the two — which is precisely what the UE-context procedures do.
Choosing the split between PDCP and RLC (rather than higher or lower) is a deliberate trade-off. Keeping PDCP in the CU centralises ciphering and the packet-duplication/reordering point — useful for dual connectivity and for anchoring mobility — while leaving the latency-critical RLC/MAC/PHY loop in the DU, close to the antenna, where HARQ and scheduling must run on microsecond timescales. It also keeps the F1 transport requirements modest compared with a lower (intra-PHY) split, so the CU can sit in an edge or regional site over ordinary IP transport. The finer functional splits inside PHY belong to the fronthaur between DU and RU, not to F1.
One CU, many DUs — but not the reverse: a gNB-DU connects to exactly one gNB-CU, while a gNB-CU may serve many DUs. Each DU-to-CU link is one F1 interface with its own SCTP association. That asymmetry is why pooling and centralisation live in the CU.
The F1 Interface: F1-C and F1-U
Like NG, F1 separates cleanly into a control plane and a user plane, each with its own transport.
F1-C (control plane). F1AP messages ride SCTP over IP between the CU and the DU. SCTP is chosen for the same reasons as on NG and Xn — reliable, ordered-per-stream delivery with multi-streaming to avoid head-of-line blocking, and built-in path redundancy. A single SCTP association carries both the non-UE-associated common signalling (cell management) and every per-UE association multiplexed together. RRC PDUs are passed transparently as RRC-Container IEs; the DU never parses them.
As on NG, the transport has fixed anchors worth knowing: F1AP uses the registered SCTP port 38472 and its own SCTP Payload Protocol Identifier, so F1AP chunks are unambiguous in a capture. The common (non-UE) procedures conventionally use SCTP stream 0, and UE-associated signalling is distributed across the other streams so per-UE flows do not head-of-line-block one another.
F1-U (user plane). Downlink and uplink user data between CU and DU travel as GTP-U, one tunnel per DRB (identified by a GTP-U TEID plus transport-layer address, exchanged as UP Transport Layer Information during UE-context setup). Riding on top of GTP-U is the NR user-plane protocol (TS 38.425): it adds per-PDU sequence numbers and, crucially, DL Data Delivery Status — flow-control feedback the DU sends back to the CU reporting how much buffer it has and which PDCP PDUs it has successfully delivered or lost. That feedback lets the CU's PDCP pace its downlink toward the DU so the DU's RLC buffers neither starve nor overflow. It is also how PDCP knows what to retransmit after a lower-layer failure.
Spec anchors: F1 general principles and the interface architecture are in TS 38.470; F1AP procedures and messages in TS 38.473; the NR user-plane protocol (sequence numbering and DL data-delivery status / flow control on F1-U) in TS 38.425.
Interface Management: Setup, Configuration, SI & Paging
These procedures manage the interface and the cells behind it, independent of any single subscriber. They are the non-UE-associated part of F1AP.
F1 SETUP REQUEST / F1 SETUP RESPONSE. When the SCTP association comes up, the DU initiates — it knows its own radio, so it speaks first. It sends F1 SETUP REQUEST carrying its gNB-DU ID, an optional gNB-DU Name, and a Served Cells List. For each served cell the list gives the NR Cell Global Identity (NCGI), the physical cell id NR-PCI, the supported frequency bands, the Tracking Area Code, the list of broadcast PLMNs (the served PLMNs), and the lower-layer System Information the DU generates. The CU decides which of those cells to bring into service and replies with F1 SETUP RESPONSE carrying a Cells to be Activated List. Only activated cells serve UEs. On error the CU returns F1 SETUP FAILURE with a Cause and possibly a Time To Wait.
Note the direction, because it is the opposite of NG: on F1 the DU initiates setup (it owns the cells and must advertise them), whereas on NG it is the gNB that initiates toward the AMF. The NR Cell Global Identity the DU reports is itself the PLMN ID plus a 36-bit NR Cell Identity, the globally unique name of each cell — which is why it is exactly what the DU later attaches to a UE's first uplink RRC so the CU knows which cell the UE is on.
Configuration updates. After setup, either side can reconfigure. GNB-DU CONFIGURATION UPDATE lets the DU add, modify or remove served cells or report a cell's status; the CU acknowledges with GNB-DU CONFIGURATION UPDATE ACKNOWLEDGE. In the other direction GNB-CU CONFIGURATION UPDATE lets the CU activate or deactivate cells and adjust parameters, acknowledged by the DU. This keeps the two nodes' view of the cell inventory in step as the network evolves.
System information. The split of SI mirrors the split of layers. The DU broadcasts everything on the air and owns the parts that are pure lower-layer scheduling, but the CU — as the owner of RRC — provides the RRC-encoded SI containers (for example the SIB1/other-SI content produced by RRC) which the DU then schedules and broadcasts. On-demand SI requests that arrive from a UE are relayed to the CU so RRC can decide what to send.
Paging. Paging originates above the DU. The CU sends a PAGING message over F1AP to the DU(s) that serve the cells in the paging area, carrying the UE's paging identity, the paging DRX and the list of cells to page in. The DU turns that into the actual paging PDCCH/PCCH transmissions at the correct paging occasions. The DU is the transmitter; the CU is the decision-maker.
Who owns the cell: the DU serves cells, generates the lower-layer configuration, and physically broadcasts; the CU activates cells and provides the RRC-level content. This is the same pattern as SI and paging — radio execution in the DU, policy and RRC in the CU.
UE-Associated Signalling and F1AP IDs
Everything that concerns one specific UE is UE-associated signalling, and it all hangs off a UE-association that exists in both nodes. Exactly as on NG and Xn, a UE with context in both ends is addressed by a pair of identifiers, one allocated by each end:
| Identifier | Allocated by | Meaning |
|---|---|---|
gNB-DU UE F1AP ID | gNB-DU | Identifies the UE association on the DU side of this F1 interface. First allocated when the DU forwards the UE's initial RRC. 32-bit. |
gNB-CU UE F1AP ID | gNB-CU | Identifies the UE association on the CU side. Allocated once the CU has created a context for the UE. 32-bit. |
The two IDs together form the key that lets each node find the right UE state for an incoming message; every UE-associated F1AP message after context creation carries both. The very first uplink message is the exception: INITIAL UL RRC MESSAGE TRANSFER carries only the gNB-DU UE F1AP ID, because the CU has not yet created its half of the context. The CU allocates its gNB-CU UE F1AP ID in response and includes both from its first downlink message onward. From then on the pair is stable for the life of the UE's stay on that DU.
The same design recurs on every 3GPP RAN interface, and lining them up makes the pattern obvious: RAN/AMF UE NGAP ID on NG, the source/target UE XnAP IDs on Xn, and gNB-CU/gNB-DU UE F1AP ID here. In each case the "first message carries one ID, all later ones carry the pair" rule holds, for the same reason — the second node has not yet minted its half when the association is born.
Why a pair, not one ID: each node allocates its own identifier from its own space, so neither has to coordinate identifier ranges with the other. A message names the sender's known ID and the receiver's ID so the receiver can index straight into its own context table — the same design used by AMF/RAN UE NGAP ID on NG.
UE Context Setup, Modification & Release
The UE-context procedures are how the CU tells the DU to reserve, change, or free the lower-layer resources for a UE — the RLC entities, MAC configuration, logical channels and radio bearers that only the DU can build. This is where the split's second consequence — the split-built RRC message — is resolved.
UE CONTEXT SETUP REQUEST / RESPONSE. The CU asks the DU to configure the UE by sending UE CONTEXT SETUP REQUEST with an SRBs to be Setup List and a DRBs to be Setup List. Each DRB entry carries its QoS Flow mapping, the 5QI and priority describing the QoS to honour, and the CU-side UL UP Transport Layer Information — the GTP-U endpoint the DU should send uplink user data to over F1-U. The DU admits what it can (admission control lives here, because only the DU knows its radio load), allocates the RLC/MAC resources and its own DL F1-U endpoint, and replies with UE CONTEXT SETUP RESPONSE. That response includes the DRBs Setup List (with the DU's DL GTP-U TNL info) and, critically, a DU To CU RRC Information container holding the CellGroupConfig — the block of RLC/MAC/PHY parameters the CU must fold into the RRC message it will send the UE.
UE CONTEXT MODIFICATION REQUEST / RESPONSE. Later changes reuse the same shape: add, modify, or remove SRBs/DRBs; change the RRC configuration; move the UE between cells at the same DU; or trigger a fresh CellGroupConfig. There is also a DU-initiated UE CONTEXT MODIFICATION REQUIRED for when the DU itself needs the CU to react (for example the DU wants to release a bearer). The CU almost always piggybacks an RRC-Container so the reconfiguration reaches the UE in the same step.
UE CONTEXT RELEASE COMMAND / COMPLETE. When the UE leaves — goes idle, hands over, or fails — the CU sends UE CONTEXT RELEASE COMMAND and the DU frees all RLC/MAC resources and its F1-U tunnels, confirming with UE CONTEXT RELEASE COMPLETE. A DU that detects a radio-link failure can prompt this with UE CONTEXT RELEASE REQUEST.
The CellGroupConfig handshake: the DU knows RLC/MAC/PHY, so it produces the CellGroupConfig and returns it in DU To CU RRC Information. The CU, which owns RRC, embeds that block into the RRCReconfiguration (or RRCSetup) it then sends the UE. Neither node can build the complete RRC message alone — this handshake is the heart of the split.
RRC Message Transfer across the Split
With a context in place, F1AP's steady-state job is tunnelling RRC. Because the DU cannot read RRC, every RRC PDU crosses F1 wrapped in an F1AP message as an opaque RRC-Container.
INITIAL UL RRC MESSAGE TRANSFER. When a UE completes random access and its Msg3 arrives at the DU carrying an RRCSetupRequest, the DU cannot process it. It allocates a gNB-DU UE F1AP ID and forwards the RRC PDU up to the CU inside INITIAL UL RRC MESSAGE TRANSFER, and — this is the DU adding value it uniquely holds — it also attaches the NR Cell Global Identity of the serving cell and the C-RNTI it assigned. The CU decodes the RRCSetupRequest, allocates a gNB-CU UE F1AP ID, and the UE association now exists on both sides.
DL RRC MESSAGE TRANSFER / UL RRC MESSAGE TRANSFER. After that, every RRC PDU crosses F1 tunnelled in these two messages. The CU sends downlink RRC — RRCSetup, RRCReconfiguration, SecurityModeCommand and so on — in DL RRC MESSAGE TRANSFER, tagged with an SRB ID that tells the DU which signalling radio bearer to deliver it on. The DU relays uplink RRC — RRCSetupComplete, RRCReconfigurationComplete, measurement reports — up in UL RRC MESSAGE TRANSFER. The RRC-Container is opaque to the DU throughout; the DU only routes it and manages the SRB.
The SRB ID tag matters more than it looks. It is how the DU knows whether an incoming container is SRB0 (over CCCH, before security), SRB1 or SRB2 (over DCCH) — and therefore which logical channel and RLC entity to put it on — without ever decoding the RRC inside. The DU is a router keyed on SRB ID; the CU is the only reader of the payload. This is the exact division the whole split depends on.
The figure below follows a UE from random access to an active radio bearer, showing how F1AP relays RRC while the CU sets up the UE context in the DU — the whole split working as one machine.
Key F1AP Procedures at a Glance
Pulling it together: the table lists the procedures that carry the bulk of F1 traffic, grouped into non-UE (interface/cell management) and UE-associated (per-subscriber). Direction uses DU→CU, CU→DU, or CU↔DU where either end may initiate.
| Procedure / Message | Type | Direction | Purpose & key IEs |
|---|---|---|---|
F1 SETUP REQUEST/RESPONSE | Non-UE | DU → CU | Bring up the interface. DU reports gNB-DU ID, Served Cells List (NCGI, PCI, served PLMN, SI); CU returns Cells to be Activated List. |
GNB-DU CONFIGURATION UPDATE | Non-UE | DU → CU | DU adds/modifies/removes served cells or reports cell status. |
GNB-CU CONFIGURATION UPDATE | Non-UE | CU → DU | CU activates/deactivates cells or changes parameters. |
PAGING | Non-UE | CU → DU | CU asks DU to page a UE in listed cells; UE paging identity, DRX, paging cell list. |
INITIAL UL RRC MESSAGE TRANSFER | UE | DU → CU | First uplink RRC (Msg3). gNB-DU UE F1AP ID, NCGI, C-RNTI, RRC-Container = RRCSetupRequest. |
DL/UL RRC MESSAGE TRANSFER | UE | CU ↔ DU | Tunnel RRC PDUs. SRB ID, opaque RRC-Container. |
UE CONTEXT SETUP REQUEST/RESPONSE | UE | CU ↔ DU | Set up SRBs/DRBs at the DU. SRBs/DRBs to be Setup List, 5QI, UL UP TNL, DU To CU RRC Information (CellGroupConfig). |
UE CONTEXT MODIFICATION REQUEST/RESPONSE | UE | CU ↔ DU | Add/change/remove bearers or configuration mid-session; refresh CellGroupConfig. |
UE CONTEXT RELEASE COMMAND/COMPLETE | UE | CU ↔ DU | Free the UE's RLC/MAC resources and F1-U tunnels at the DU. |
Q. Which layers live in the CU and which in the DU, and why does that shape F1AP?
A. The CU owns RRC, SDAP and PDCP; the DU owns RLC, MAC and PHY. Because the DU cannot process RRC, F1AP tunnels RRC PDUs as opaque RRC-Container IEs, and the CU is the only side that encodes or decodes them.
Q. What transports carry F1-C and F1-U?
F1-C is F1AP over SCTP (registered port 38472). F1-U is user data over GTP-U (one tunnel per DRB), with the NR user-plane protocol (TS 38.425) on top for sequence numbering and DL data-delivery-status flow control.
Q. Why is F1 SETUP initiated by the DU, and what does each side contribute?
The DU serves the cells and knows their radio parameters, so it advertises its Served Cells List (NCGI, PCI, served PLMN, SI). The CU makes the policy decision and returns a Cells to be Activated List. Only activated cells serve UEs.
Q. What is DU To CU RRC Information and why is it needed?
It is the lower-layer CellGroupConfig the DU builds (RLC/MAC/PHY parameters) and returns in UE CONTEXT SETUP RESPONSE. The CU folds it into the RRCReconfiguration/RRCSetup it sends the UE — neither node can build the complete RRC message alone.
Q. Which F1AP IDs address a UE, and why only one in the first uplink message?
A UE is addressed by the pair gNB-CU UE F1AP ID + gNB-DU UE F1AP ID, each allocated by its own node. INITIAL UL RRC MESSAGE TRANSFER carries only the DU's ID because the CU has not yet created its context; the CU allocates its ID and includes both from its first downlink onward.
Q. How does paging work across the split?
The CU decides to page and sends a PAGING message over F1AP to the DUs serving the target cells, with the paging identity, DRX and cell list. The DU transmits the actual paging at the correct paging occasions — decision in the CU, radio execution in the DU.
LTE ↔ NR
F1AP is one of the clearest cases where NR added something LTE never standardised, so the comparison is mostly about what is new.
LTE ↔ NR: the classic LTE eNB is monolithic — RRC, PDCP, RLC, MAC and PHY all sit in one node, so there is no internal open interface and no F1AP. NR standardises the higher-layer (option 2) CU/DU split, and F1AP (TS 38.473) is the control protocol for it. F1AP is deliberately modelled on the same NGAP/XnAP family LTE's S1AP/X2AP belong to — ASN.1 over SCTP, elementary procedures, the two-ID UE association — so the mechanics feel familiar even though the interface itself has no LTE-era equivalent. (An analogous split interface, W1, was later defined for the ng-eNB that attaches an LTE radio to 5GC, but the standalone LTE eNB has nothing like it.)
The user-plane story is likewise NR-specific: the NR user-plane protocol (TS 38.425) with its DL data-delivery-status flow control exists because PDCP-in-CU and RLC-in-DU are now in separate boxes with real transport between them — a situation the monolithic eNB never had.
Summary
F1AP is the control-plane contract on the F1 interface inside a disaggregated gNB, defined in TS 38.473 and carried on SCTP. It exists because NR splits the gNB between PDCP (in the CU) and RLC (in the DU), so no single node holds a complete UE picture: the CU owns RRC/SDAP/PDCP and all policy, the DU owns RLC/MAC/PHY and the real-time radio.
Everything on F1 follows from that. RRC is never spoken on F1, only carried as an opaque RRC-Container tagged with an SRB ID; the DU serves and broadcasts cells while the CU activates them; UE work is bound to the gNB-CU UE F1AP ID + gNB-DU UE F1AP ID pair; and the signature move — the CellGroupConfig handshake, where the DU returns DU To CU RRC Information that the CU folds into the RRC message — is what lets two half-informed nodes build one complete configuration.
Read F1AP as NGAP's one-layer-down sibling with the same grammar, and the CU/DU seam becomes just another well-defined contract: policy and RRC on one side, radio execution on the other, and a precise set of messages stitching them into a single logical gNB.
Where to go next
F1 is one seam of a disaggregated gNB. See the full disaggregation picture in CU/DU/RU Split, follow the CU's interface toward the core in NGAP, and see what the tunnelled RRC messages actually do in RRC Procedures.