In 5G, the gNB is not a single box. Under the 3GPP higher-layer split (TS 38.401), a Central Unit owns the upper radio-protocol layers, and one or more Distributed Units own the real-time lower ones — RLC, MAC, and PHY. F1-U is the user-plane leg between them, and it carries GTP-U tunnels running the NR User Plane Protocol (NR-U / NRUP, TS 38.425). The CU-UP pushes downlink data toward a radio it cannot see; the DU reports back what it managed to send.
This walkthrough reads a real srsRAN F1-U capture — 37,871 frames over about 82 seconds — and zooms in on a 29-frame window following one voice bearer.
What the capture shows
NR-U is a two-way loop, and the PDU type carries the direction. Type 0, DL User Data, flows CU-UP to DU with a downlink PDCP PDU to put on the air. Type 1, DL Data Delivery Status, flows DU to CU-UP with no user data at all — only the highest transmitted PDCP SN, a desired buffer size, and a final-frame flag.
There is no IP layer to key on. srsRAN writes each frame as a bare GTP-U packet under a Wireshark DLT_USER link type: no Ethernet, IP, or UDP header. Direction comes from the PDU type, never from an address.
The delivery status is timer-driven. The DU repeats the same report roughly every 10 ms even when it has delivered nothing new. On this lightly loaded voice bearer, the status reports vastly outnumber the data frames — a property of this bearer at this load, not of F1-U in general.
Desired Buffer Size is the flow-control knob. Here it holds constant at 6,172,672 bytes (about 5.9 MiB), effectively bottomless for a low-rate voice bearer, so flow control never throttles. On a congested bearer, a shrinking desired buffer is the DU asking the CU-UP to slow down, and it is the first field to check when downlink throughput stalls between CU and DU.
The PDCP SN is the sequence that matters here. This srsRAN build leaves the NR-U sequence number at 0 on every frame, so delivery tracking rides entirely on the PDCP SN the DU echoes back. Correlating those numbers is what pairs a bearer's two tunnels, and it is what identified TEID 0x06 and TEID 0x18 as one DRB.
The full walkthrough follows the window in four beats: the first downlink burst, the delivery-status feedback and its heartbeat, the loop repeating as the sequence number climbs, and the resume after a roughly 90 ms gap. Underneath the PDCP layer sits a second capture entirely — a VoNR call, read in a companion article.
Full walk-through: https://www.eventhelix.com/5G/f1u-nr-u-flow-control/
VisualEther decoded and captioned every arrow in the diagram straight from the raw Wireshark PCAP—no manual diagramming. VisualEther turns a PCAP into a sequence diagram and ships an MCP server so an AI agent can analyze a capture directly. Free Community edition: https://www.eventhelix.com/visualether/download — Live interactive output: https://diagrams.eventhelix.com/visualether/5g-nr-radio/
Top comments (0)