mmWave & 5G

CU (Central Unit)

Q: What is the difference between CU-CP and CU-UP in a 5G gNB?

In the 3GPP architecture the CU is logically separated into a control-plane part (CU-CP) and one or more user-plane parts (CU-UP). The CU-CP hosts the RRC layer and the control-plane portion of PDCP, terminating signaling toward the device and the 5G core AMF over NG-C. Each CU-UP hosts the SDAP layer and the user-plane portion of PDCP, terminating data bearers toward the UPF over NG-U. They are connected by the internal E1 interface, over which the CU-CP configures and manages bearers on the CU-UP. This split lets an operator scale signaling capacity and data throughput independently, and place CU-UP instances closer to the edge for low-latency services while keeping CU-CP centralized.

Q: What interface connects the CU to the DU, and what latency does it tolerate?

The CU connects to the distributed unit (DU) over the F1 interface, split into F1-C for control and F1-U for user-plane GTP-U traffic. F1 sits at the higher-layer functional split known as Option 2 (the PDCP/RLC boundary). Because PDCP runs above the latency-sensitive HARQ loop, F1 is far more relaxed than fronthaul: typical one-way transport latency budgets are about 1 to 10 ms, allowing the CU to sit tens or hundreds of kilometers from the DU over routed packet midhaul. This contrasts sharply with the lower-layer split between DU and radio unit, where eCPRI fronthaul demands roughly 100 microseconds one-way latency.

Q: Why does the CU host PDCP, and how does that enable dual connectivity?

PDCP is the anchor point for ciphering, integrity protection, header compression, and in-sequence delivery, and it is the layer at which traffic can be routed to more than one lower-layer leg. By placing PDCP in the centralized CU, a single PDCP entity can split a bearer across two DUs or across an LTE eNB and an NR gNB, which is exactly how NR-DC and EN-DC dual connectivity work. The CU performs the PDCP-level routing and reordering so the device sees one logical bearer even when packets arrive over two physically separate cells. Centralizing PDCP also keeps the security anchor in a hardened data-center location rather than at the cell site.

/see-yoo, sen-truhl yoo-nit/

Within a disaggregated 5G gNB, this centralized logical node hosts the higher protocol layers (RRC, SDAP, and PDCP) and connects southbound to one or more distributed units over the F1 interface. The boundary between the two follows the 3GPP higher-layer functional split (Option 2, the PDCP/RLC cut), which is far more latency-tolerant than the lower-layer fronthaul below the DU. The CU is typically separated into a control-plane entity (CU-CP) and one or more user-plane entities (CU-UP) joined by the internal E1 interface, so signaling and data capacity scale independently and run as cloud-native functions in a regional or edge data center.

Hosted layers: RRC, SDAP, PDCP

Southbound interface: F1-C / F1-U

CU-DU latency: ~1 to 10 ms

Where the CU Sits in the Disaggregated gNB

The 5G New Radio base station, the gNB, can be broken into three physical building blocks: the radio unit (RU) at the antenna, the distributed unit (DU) at or near the cell site, and the central unit (CU) hosted further back in the network. This three-way split replaces the monolithic LTE eNB with components that can be sourced, scaled, and located independently. The CU is the most centralized of the three and terminates the protocol stack from the RLC layer upward. It owns the Radio Resource Control (RRC) layer that manages connection setup, mobility, and measurement reporting; the Service Data Adaptation Protocol (SDAP) layer that maps QoS flows to radio bearers; and the Packet Data Convergence Protocol (PDCP) layer that handles ciphering, integrity, and reordering.

Because the F1 interface between CU and DU is defined at the PDCP/RLC boundary, the CU operates above the tight HARQ retransmission loop that lives in the MAC and physical layers. That single architectural choice is what makes centralization practical: F1 traffic can traverse routed IP transport (midhaul) with one-way latency budgets measured in milliseconds rather than the roughly 100 microseconds demanded by fronthaul. A single CU can therefore aggregate dozens of DUs spread across a metro area, pooling baseband-adjacent processing and concentrating the security anchor in a hardened site.

The 3GPP control/user-plane separation (CUPS) carries into the CU itself. The CU-CP runs RRC and the control portion of PDCP and faces the 5G core AMF over the NG-C interface. Each CU-UP runs SDAP and the user portion of PDCP and faces the UPF over NG-U. The two are stitched together by the E1 interface, over which the CU-CP provisions and tears down bearers on the CU-UP. Operators exploit this to keep CU-CP signaling central while pushing CU-UP instances toward the edge for low-latency applications.

Interfaces and Protocol Termination

End-to-end gNB protocol chain:
UE ↔ RU ↔ (fronthaul) ↔ DU ↔ (F1, midhaul) ↔ CU ↔ (NG) ↔ 5G Core

F1 latency budget vs. fronthaul (one-way):
T_F1 ≈ 1 to 10 ms »» T_fronthaul ≈ 100 μs

Practical CU–DU fiber reach (propagation-limited):
d_max ≈ (T_budget × c) / n with n ≈ 1.47 (≈ 5 μs/km one-way)
e.g. T_budget = 1 ms one-way → d_max ≈ 200 km of fiber

Where the F1 split sits at PDCP/RLC (Option 2), c = 3 × 10⁸ m/s, and n is the fiber group index. This counts propagation delay only; switching, framing, and processing further reduce usable reach. The relaxed F1 budget is what permits CU centralization over routed midhaul.

CU vs. DU vs. RU at a Glance

Attribute	CU (Central Unit)	DU (Distributed Unit)	RU (Radio Unit)
Hosted layers	RRC, SDAP, PDCP	RLC, MAC, High-PHY	Low-PHY, RF front end
Northbound interface	NG (to 5G core)	F1 (to CU)	eCPRI / Open FH (to DU)
One-way latency to peer	~1 to 10 ms (F1)	~100 μs (fronthaul)	N/A (edge)
Typical location	Regional / edge data center	Cell site or aggregation hub	At the antenna / mast
Plane separation	CU-CP + CU-UP via E1	Single node	Single node
Implementation	Cloud-native (COTS server)	COTS server + accelerator	Purpose-built RF hardware

Common Questions

Frequently Asked Questions

What is the difference between CU-CP and CU-UP in a 5G gNB?

The CU is logically split into a control-plane part (CU-CP) hosting RRC plus the control portion of PDCP, and one or more user-plane parts (CU-UP) hosting SDAP plus the user portion of PDCP. CU-CP faces the AMF over NG-C; each CU-UP faces the UPF over NG-U. They are joined by the internal E1 interface, letting an operator scale signaling and throughput independently and push CU-UP instances toward the edge while keeping CU-CP centralized.

What interface connects the CU to the DU, and what latency does it tolerate?

The CU links to the DU over F1, split into F1-C for control and F1-U for GTP-U user data. F1 sits at the Option 2 (PDCP/RLC) split, above the HARQ loop, so its one-way transport budget is roughly 1 to 10 ms. That permits routed packet midhaul spanning tens or even hundreds of kilometers, far more relaxed than the ~100 μs eCPRI fronthaul below the DU.

Why does the CU host PDCP, and how does that enable dual connectivity?

PDCP is the ciphering, integrity, header-compression, and reordering anchor, and the layer at which a bearer can be routed to more than one lower-layer leg. Centralizing PDCP in the CU lets one PDCP entity split a bearer across two DUs or across an LTE eNB and an NR gNB, which is how NR-DC and EN-DC work. The CU reorders and routes at PDCP so the device sees a single logical bearer, while the security anchor stays in a hardened site.

Related Terms

← CU Cul-De-Sac Topology →