5G CU-DU Split Explained
The CU-DU split is one of the most important architectural features of 5G. It allows the gNB to be divided into multiple logical units, enabling flexible deployment, cloud-native design, and scalable radio access networks.
A gNB may consist of a gNB-CU and a gNB-DU, and in more advanced deployments the CU itself may be split into gNB-CU-CP and gNB-CU-UP. This architecture is the foundation for Cloud RAN, vRAN, and many O-RAN-aligned deployment models.
Quick facts
| What it is | The CU-DU split divides the gNB into centralized and distributed functional units. |
|---|---|
| Main units | The split starts with gNB-CU and gNB-DU, and the CU may be further split into CU-CP and CU-UP. |
| Main interfaces | F1 connects CU and DU, while E1 connects CU-CP and CU-UP. |
| Why it matters | It enables cloud RAN, virtualization, independent scaling, and more flexible RAN deployment models. |
| Control and user separation | CU-CP handles control-heavy work, while CU-UP handles user-plane processing when the CU is further split. |
| Engineering value | This is one of the highest-value 5G architecture concepts for cloud-native RAN, O-RAN, and transport planning. |
CU-DU split in 5G architecture
What is the CU-DU split?
The CU-DU split divides the gNB into centralized functions and distributed functions. The simplest mental model is:
- CU for higher-layer processing
- DU for lower-layer, time-critical radio processing
This split is the architecture move that makes 5G much more deployment-flexible than older monolithic RAN designs. Once the gNB is decomposed, operators can place central and distributed functions where they make the most sense for transport, latency, capacity, and operational scale.
gNB-CU (Central Unit)
The gNB-CU is responsible for higher-layer protocol functions and the more centralized side of gNB behavior.
- RRC
- SDAP
- PDCP
- mobility control
- connection management
On the interface side, the CU is the part of the split gNB that reaches toward the 5G Core over NG, toward the DU over F1, and toward the CU-UP over E1 when the CU is further split.
gNB-DU (Distributed Unit)
The gNB-DU handles lower-layer radio functions and the more timing-sensitive side of the access network.
- RLC
- MAC
- PHY
- scheduling
- HARQ-related processing
This is why the DU usually stays closer to the radio site than the CU. If the CU is the centralized logic side, the DU is the real-time execution side.
CU-CP and CU-UP split
In advanced deployments, the CU is split further into separate control-plane and user-plane units.
| Unit | Main role |
|---|---|
| CU-CP | Handles RRC, signaling control, mobility management, and the control-facing side toward the AMF. |
| CU-UP | Handles user data processing and the user-facing side toward the UPF. |
The reason to split the CU is practical: independent scaling of control and user plane, better resource utilization, and more efficient behavior for traffic-heavy services.
F1 interface (CU to DU)
The F1 interface connects the CU and DU. It is split into F1-C for control coordination and F1-U for user-plane transport.
| Part | Typical role | Typical transport view |
|---|---|---|
| F1-C | Control coordination, bearer and context handling between CU and DU. | F1AP over SCTP/IP |
| F1-U | User-plane transport between CU and DU. | GTP-U over UDP/IP |
This interface is one of the key foundations of split-gNB deployment. If the CU-DU split is the architecture idea, F1 is the interface that makes the idea operational.
E1 interface (CU-CP to CU-UP)
The E1 interface connects the CU-CP and CU-UP when the central unit is itself split.
In architecture terms, E1 is what allows control-plane instructions, session treatment, and user-plane coordination to stay aligned across the two halves of the central unit.
The simple transport picture is E1AP over SCTP/IP. Operationally, E1 matters whenever the split-CU model is used and signaling or user traffic appears to diverge.
Why CU-DU split is important
| Reason | Why it matters in practice |
|---|---|
| Cloud RAN | Lets operators centralize CU functions in data centers while keeping DUs closer to cell sites. |
| Scalability | CU and DU resources can be scaled more independently than in a monolithic node. |
| Low latency | Time-sensitive radio handling stays on the DU side while centralized logic remains on the CU side. |
| Cost efficiency | Centralized processing can reduce duplication and allow shared infrastructure across multiple DUs. |
| Flexibility | Supports virtualized RAN, vendor disaggregation, and more deployment choices than fixed monolithic RAN designs. |
CU-DU split vs LTE architecture
| Feature | LTE eNodeB | 5G gNB |
|---|---|---|
| Architecture | Mostly monolithic | Split-friendly CU and DU model |
| Flexibility | Limited | High |
| Cloud-native fit | No native split-first model | Designed for cloud-oriented decomposition |
| Key interfaces | S1, X2 | NG, Xn, F1, E1 |
Deployment models
The CU-DU split does not force one single deployment style. Operators can place the pieces differently depending on transport capability, latency targets, and traffic patterns.
- Centralized CU: CU in a regional data center, DU at the cell site.
- Distributed CU: CU placed closer to the DU for tighter latency needs.
- Edge CU-UP: user-plane part of the CU positioned near the edge for faster application handling.
CU-DU split and O-RAN
The CU-DU split aligns closely with O-RAN thinking because it supports open interfaces, vendor separation, and more modular deployment models.
That does not mean CU-DU split and O-RAN are the same thing, but CU-DU is one of the architectural building blocks that makes open and disaggregated RAN designs practical.
CU-DU split and end-to-end flow
The split becomes easiest to understand when you follow the control and user paths separately.
| Plane | Simple path |
|---|---|
| Control plane | UE → DU → CU-CP → AMF |
| User plane | UE → DU → CU-UP → UPF → Data Network |
Common troubleshooting areas
| Area | Typical problems |
|---|---|
| CU and DU | F1 failures, synchronization issues, or basic CU and DU misconfiguration. |
| CU-CP and CU-UP | E1 issues, user plane not established, or control and data behavior drifting apart. |
| Performance | Latency between CU and DU, packet loss on F1-U, poor transport sizing, or scaling mismatches. |
FAQ
What is CU-DU split in 5G?
It is the division of the gNB into centralized and distributed units, typically a gNB-CU and a gNB-DU.
What is the difference between CU and DU?
The CU handles higher-layer and more centralized functions, while the DU handles lower-layer and time-critical radio processing.
What is the F1 interface?
F1 connects the CU and DU, with F1-C for control coordination and F1-U for user-plane transport.
What is the E1 interface?
E1 connects CU-CP and CU-UP when the central unit is further split into separate control-plane and user-plane functions.
Why is CU-DU split important?
It enables cloud-native, scalable, and flexible RAN deployment, including Cloud RAN, vRAN, and O-RAN-aligned designs.
Key takeaways
- 5G introduces a CU-DU split architecture for the gNB.
- The gNB can be divided into CU and DU, and the CU can be further split into CU-CP and CU-UP.
- F1 and E1 are the main interfaces that enable this architecture.
- The split is a major enabler for Cloud RAN, scalability, and flexible deployment models.
- Understanding the CU-DU split is essential for reading modern 5G RAN, virtualization, and O-RAN-style deployment designs.
References
- 3GPP TS 38.401 - NG-RAN architecture description Primary NG-RAN architecture reference for gNB, CU, DU, NG, Xn, and split-gNB structure.
- 3GPP TS 38.460 - E1 general aspects General E1 architecture reference for CU-CP and CU-UP split deployments.
- 3GPP TS 38.470 - F1 general aspects General F1 architecture reference for CU and DU interconnection.
- 3GPP TS 23.501 - System architecture for the 5G System (5GS) 5GS architecture reference for N2, N3, QoS, control-plane and user-plane separation.