Inside F1AP: A UE Registration Across the 5G CU/DU Split

Reading F1AP — the control-plane conversation between a 5G base station's Central Unit and its Distributed Unit — frame by frame in a real OCUDU capture, the open-source 5G CU/DU that grew out of the srsRAN Project and is now a Linux Foundation project. The trace was decoded and annotated with VisualEther, which turns a Wireshark PCAP into a sequence diagram.

💡 Read the walkthrough and the diagram side by side. Open the interactive diagram (or PDF) in a split-screen window so the captions stay in view as you read. In Edge, Chrome, or Firefox, right-click the link and pick your browser's split-screen option (Edge labels it "Open link in split screen window"). On macOS, prefer Chrome or Firefox — Safari has no in-browser split screen. Otherwise, open the diagram in a new tab and snap the two windows side by side.

Overview

In 5G, the gNB is not a single box. Under the 3GPP higher-layer split (TS 38.401), it divides into a Central Unit (CU) that owns the upper radio-protocol layers and one or more Distributed Units (DU) that own the real-time lower layers — RLC, MAC, and the physical layer. The interface between them is F1, and its control plane, F1-C, runs the F1 Application Protocol (F1AP, TS 38.473) over SCTP.

This capture is a complete F1AP conversation from an OCUDU CU + DU (gNB-CU-Name ocudu01, gNB-DU-Name odu0 — the node names are the project's own). OCUDU is the open-source, carrier-grade 5G CU/DU built on the srsRAN Project, now governed under the Linux Foundation and licensed BSD-3-Clause-Open-MPI. In 32 frames, it walks the entire arc of bringing up the interface and then serving one UE:

• F1 Setup brings the F1 interface up before any UE exists.
• One UE's whole registration is then relayed across F1 — RRC connection setup, NAS authentication and security, access-stratum security, capability exchange, and the establishment of a data radio bearer — with the CU acting as the UE's RRC and NAS endpoint and the DU relaying transparently to the air.
• A Public Warning System broadcast is pushed to the cell.
• Finally, the UE is released, and the F1 interface itself is torn down.

One structural fact shapes how the whole trace reads: there is no IP layer. This pcap is a Wireshark "Export PDUs to file" dump — each frame carries the F1AP PDU directly (exported_pdu.prot_name = f1ap) with no Ethernet, IP, or SCTP headers. The two participants, gNB-CU and gNB-DU, are constants; you read the direction of every message from the F1AP procedure itself (which node originates it in TS 38.473), not from an address.

A primer on the CU/DU split

The higher-layer split (TS 38.401) divides the gNB into:

• a Central Unit (CU) that terminates the upper radio-protocol layers — RRC and PDCP — itself split into CU-CP (control plane) and CU-UP (user plane); and
• one or more Distributed Units (DU) that own the lower, real-time layers: RLC, MAC, and PHY.

F1 carries the traffic between them, split into a control and a user plane:

The key to reading F1AP is that the upper layers terminate at the CU and the UE and ride transparently across the DU. RRC and NAS are endpoints at the CU (NAS reaches further, to the AMF behind it); the DU never interprets them. F1AP's job is to carry those RRC/NAS PDUs between CU and DU and, separately, to manage the DU's radio resources for each UE:

F1AP messages come in two families, and this capture exercises both:

Every UE-associated message carries up to two identifiers: the gNB-DU-UE-F1AP-ID (the DU allocates it first, on the very first uplink message) and the gNB-CU-UE-F1AP-ID (the CU adds its own once it owns the UE). Together they correlate the CU's and DU's views of the same UE for the life of the connection.

The flow at a glance

The 32 frames fall into twelve short phases. Two are interface-level bookends (F1 Setup, F1 Removal); one is a cell broadcast; the rest are one UE's registration. The flow drives two UE-side state machines — RRC on the radio and 5GMM in the NAS — and, on the F1 interface itself, one UE F1AP context lifecycle. All three move like this:

The rest of this page walks the capture phase by phase.

Phase 1 — F1 interface bring-up (frames 1–2)

Frame 1 — F1 Setup Request. Before any UE can be served, the DU registers with the CU. It advertises its identity (gNB-DU-ID 0, name odu0) and its full served-cell configuration: PLMN 001-01, cell NR-CGI 0000019b00, PCI 1, 5GS-TAC 7, plus the frequency, SSB, and system-information layout. No UE context exists yet — this is pure interface management, and everything below depends on it. The decoded field tree shows the whole served-cell record the DU hands over:

Frame 1, F1 Setup Request, with the f1ap node opened to F1AP-PDU. Follow initiatingMessage -> F1SetupRequest -> protocolIEs -> GNB-DU-Served-Cells-List -> GNB-DU-Served-Cells-Item -> served-Cell-Information to reach the nRCGI (PLMN plus NR cell identity), the nRPCI and the 5GS-TAC; the gNB-DU-System-Information beside it carries the packed MIB and SIB1.

Frame 2 — F1 Setup Response. The CU (ocudu01) accepts the association and returns the Cells-to-be-Activated list — the served cells it authorizes the DU to switch on. F1 is now up, and this one association carries everything through frame 30.

Phase 2 — RRC connection setup (frames 3–5)

Frame 3 — Initial UL RRC Message Transfer. The UE sends an RRCSetupRequest on the radio CCCH; the DU receives it, allocates a gNB-DU-UE-F1AP-ID (0) and a C-RNTI (0x4601). It then forwards the RRC PDU — with the serving NR-CGI — up to the CU. This is the first UE-associated message, and it opens the UE's context on the CU side. Note the DU UE ID: it is the one identifier present on every UE message through release. The tree carries the two DU-side identifiers beside the embedded RRC, plus the DU's own radio configuration:

Frame 3, Initial UL RRC Transfer. The gNB-DU-UE-F1AP-ID and C-RNTI are among the first entries under protocolIEs, each a single value rather than a nested container. Follow initiatingMessage -> InitialULRRCMessageTransfer -> protocolIEs; the RRCContainer -> UL-CCCH-Message -> rrcSetupRequest -> ue-Identity holds the identity the UE chose, and the DUtoCURRCContainer -> CellGroupConfig holds the RLC/MAC/PHY parameters (rlc-BearerToAddModList, mac-CellGroupConfig, spCellConfig) the DU proposes for the CU to relay.

Frame 4 — DL RRC Message Transfer, RRCSetup. The CU admits the UE and sends the RRCSetup on SRB0, moving the UE off the CCCH and establishing signaling radio bearer SRB1. From here, all RRC travels on SRB1.

Frame 5 — UL RRC Message Transfer, RRCSetupComplete. The UE confirms the setup — and piggybacked inside the RRC message is its first NAS PDU, a 5GMM Registration Request (message type 0x41, still sent in the clear). The RRC connection delivers the UE's registration attempt to the AMF behind the CU. Everything in the next two phases is the network authenticating and securing that registration, relayed transparently over F1. This is the deepest nesting the capture ever shows in the clear — one frame spanning all three layers before Phase 4 ciphers the NAS shut:

Frame 5, UL RRC Transfer — F1AP -> RRC -> plaintext NAS in one frame. Follow initiatingMessage -> ULRRCMessageTransfer -> protocolIEs -> RRCContainer -> PDCP-NR -> NR Radio Resource Control (RRC) protocol -> UL-DCCH-Message -> rrcSetupComplete -> dedicatedNAS-Message -> Non-Access-Stratum 5GS (NAS)PDU -> Plain NAS 5GS Message, where the cleartext registration IEs sit: 5GS registration type, NAS key set identifier, 5GS mobile identity and UE security capability.

Phase 3 — NAS authentication (frames 6–7)

Frame 6 — DL RRC Transfer → NAS Authentication Request. The CU relays a NAS Authentication Request (0x56, plaintext) inside an RRC DL Information Transfer. The CU is a pure NAS pipe here — it wraps the AMF's NAS PDU in RRC and hands it to the DU for radio delivery.

Frame 7 — UL RRC Transfer → NAS Authentication Response. The UE answers the challenge with a NAS Authentication Response (0x57, plaintext) in an RRC UL Information Transfer. Authentication succeeds, which is what lets the network derive keys and turn on security next.

Phase 4 — NAS security activation (frames 8–9)

This is the hinge of the whole flow. security_header_type on the two NAS messages tells the story precisely:

Frame 8 — DL RRC Transfer → NAS Security Mode Command. The network commands NAS security. From here, the UE must protect NAS with the freshly derived keys.

Frame 9 — UL RRC Transfer → NAS Security Mode Complete. The UE's reply is the first message under the new context — integrity-protected and ciphered. From this frame on, Wireshark can confirm a NAS PDU is present and protected but can no longer decode its inner type. Every NAS body after this (frames 15–18, 27–28) is ciphered, and the walkthrough names them by role, not by a decoded type.

Phase 5 — Access-stratum security and the UE's DU context (frames 10–12)

Frame 10 — UE Context Setup Request. NAS security is up; now the CU builds the UE's radio context on the DU. This F1AP message establishes the SRBs and embeds, in its CU-to-DU RRC container, the RRC SecurityModeCommand that activates access-stratum (PDCP-layer) ciphering and integrity on the radio. The data radio bearer is not created here, and neither is the UE's slice (S-NSSAI) — both arrive together at UE Context Modification in Phase 8. The tree makes the F1AP-wraps-RRC nesting concrete: