CU

Control Unit

Radio Access Network →
Introduced in Rel-8 Also in: Management

CU is a functional entity in the 3GPP RAN architecture responsible for managing control plane functions, enabling centralized control and coordination in a split RAN.

Category
Radio Access Network
Introduced
Rel-8
Where
Services › Codecs
Also touches
1 segments
Specifications
7 specs
CU Description Purpose Detected Changes Specifications

Description

The Control Unit (CU) is a logical node defined within the 3GPP Next Generation Radio Access Network (NG-RAN) architecture, specifically as part of the gNB (5G NodeB) or ng-eNB. It represents the centralized control plane entity in the disaggregated RAN model. The CU is responsible for hosting the Radio Resource Control (RRC) protocol and the Service Data Adaptation Protocol (SDAP) for the control plane. It performs critical functions such as connection management, mobility management, radio bearer control, and inter-cell interference coordination. By centralizing these intelligence-heavy functions, the CU enables more efficient resource pooling and coordination across a wider geographical area covered by multiple Distributed Units (DUs).

Architecturally, the CU connects to the 5G Core Network (5GC) via the NG interface and to one or more DUs via the F1 interface, as standardized in 3GPP. The F1 interface is further split into the F1-C (control plane) and F1-U (user plane) parts. The CU terminates the F1-C interface, through which it sends control messages to configure and manage the DUs. This split architecture allows the CU to be deployed in a more centralized location, such as a regional data center, while DUs remain at cell sites. The CU can be implemented as a software function running on commercial off-the-shelf (COTS) hardware, facilitating network function virtualization (NFV) and cloud-native principles.

From an operational perspective, the CU handles the non-real-time layer 3 protocols and functions. When a User Equipment (UE) initiates a connection, the CU is responsible for the RRC procedures, including broadcast of system information, paging, RRC connection establishment, reconfiguration, and release. It makes handover decisions based on measurement reports from the UE and coordinates the handover execution with the source and target DUs. The CU also manages the Quality of Service (QoS) flows by mapping them to Data Radio Bearers (DRBs) in coordination with the core network's Session Management Function (SMF). Its centralized nature is crucial for implementing advanced features like Coordinated Multi-Point (CoMP) transmission/reception and Dual Connectivity (DC).

The introduction of the CU is a fundamental shift from the monolithic base station design. It decouples the evolution of control plane software from the hardware-dependent, real-time processing of the physical layer and parts of the MAC layer, which reside in the DU. This separation provides significant deployment flexibility. Network operators can choose a CU-DU split based on fronthaul latency and bandwidth constraints, with options for a more centralized CU (supporting many DUs) or a more distributed deployment. The CU's software-based nature also simplifies upgrades, scaling, and the introduction of new services, making it a cornerstone for open RAN (O-RAN) initiatives and network slicing in 5G.

Purpose & Motivation

The CU was introduced to address the limitations of traditional, integrated base stations (NodeBs and eNodeBs) which bundled all radio protocol layers into a single, site-located unit. This monolithic architecture made networks rigid, difficult to scale, and costly to upgrade. The primary motivation for creating the CU was to enable a more flexible, efficient, and cost-effective RAN through functional disaggregation. By separating the control plane (CU) from the user plane and lower-layer processing (DU), operators gain the ability to centralize intelligence, pool resources, and leverage cloud economics. This split is essential for meeting the diverse and demanding requirements of 5G, such as enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC).

Historically, each base station operated largely independently, with coordination limited to standardized interfaces like X2 in LTE. This made network-wide optimization and the implementation of advanced features like coordinated scheduling complex and inefficient. The CU-centric architecture provides a natural point for centralized control and optimization algorithms that can manage radio resources across dozens or hundreds of cell sites simultaneously. It solves the problem of inefficient resource utilization and suboptimal interference management in dense network deployments. Furthermore, it addresses the operational expenditure (OPEX) challenge by allowing software updates and new feature rollouts to be applied centrally at the CU, rather than requiring manual updates at every cell site.

The creation of the CU was also driven by the industry's move towards virtualization and open interfaces. It enables the RAN to align with the broader telco cloud transformation, where network functions are software-defined and run on general-purpose hardware. This openness, exemplified by the standardized F1 interface between CU and DU, fosters multi-vendor interoperability and innovation. It allows operators to source CU and DU software from different suppliers, breaking vendor lock-in and promoting a competitive ecosystem. Ultimately, the CU exists to future-proof mobile networks, providing an architectural foundation that is scalable, agile, and capable of supporting evolving service demands and new technological paradigms like network slicing and AI-driven RAN optimization.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (19 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-15.

Rel-15 6 changes

In Release 15, the specification introduced clarifications for intra-gNB-CU handover procedures and the associated term synchronization within the Central Unit. This included defining the control mechanisms for mobility events handled entirely within a single gNB-CU's control plane domain. The updates focused on the CU's role in managing these internal handovers and ensuring proper synchronization of state information.

  • Security mechanism for UE Parameters Update via UDM Control Plane Procedure TS 33.501CR0484
  • Clarifications to: Linking increased home control to subsequent procedures TS 33.501CR0081
  • Mobility - Clarification in intra-gNB-CU handover TS 33.501CR0302
  • Intra-gNB-CU term synchronization TS 33.501CR0377
  • Upgrade to change control version TS 28.304
  • Upgrade to change control version TS 28.305
Rel-16 2 changes

In Release 16, the CU function was enhanced to support extended notification control for GBR QoS flows, particularly for URLLC. A new "GBR required as soon as possible" attribute was introduced for Xn/N2 handover signaling, allowing the target RAN node to perform admission control and, if unsuccessful, establish the flow with a best-effort level while the RAN continues attempts to restore the required QoS. This provides better monitoring and control of QoS for URLLC flows during handover.

  • KI#7: Extending notification control for QoS flow setup and handover TS 23.725CR0011
  • New Solution for Key Issue #7-URLLC Always on Control for the GBR QoS Flow TS 23.725CR0015
Rel-17 2 changes

In Release 17, enhancements for the Control Unit (CU) function included clarifications on control-plane and user-plane procedures, particularly for managing QoS during handovers. A key introduction was a new QoS attribute for Xn/N2 signalling to indicate that a GBR flow is "required as soon as possible" during handover preparation, prompting the target RAN node to perform specific admission control. These changes refined the interaction between RAN nodes to better support the monitoring and restoration of QoS for flows, especially under URLLC requirements, while keeping procedures under change control.

  • Clarifications on the control-plane and user-plane procedures TS 33.501CR1374
  • Under change control TS 26.962
Rel-18 5 changes

In Release 18, key CU enhancements included the introduction of a new IAB inter-CU topology adaptation procedure for managing Integrated Access and Backhaul nodes. Furthermore, control-plane procedures for Multicast/Broadcast Services (MBS) were specified, expanding the CU's role in managing multicast sessions. These updates provided the CU with new capabilities for dynamic network reconfiguration and support for evolving service types.

  • Control-plane procedure in MBS TS 33.501CR1599
  • Control-plane procedure in MBS TS 33.501CR1620
  • IAB inter-CU topology adaptation procedure TS 33.501CR1774
  • [IAB][Rel-18] IAB inter-CU topology adaptation procedure TS 33.501CR1879
  • UDR control flag for NSWO TS 33.501CR1987
Rel-19 4 changes

In Release 19, the new work for the Control Unit (CU) function introduced a specific security procedure for inter-CU LTM (Link Traffic Management). Additionally, updates were made to clarify the security handling for scenarios where the CU is acting as a Master Node (MN) while the Secondary Node (SN) remains unchanged, ensuring consistency in the control plane procedures.

  • Security procedure for inter-CU LTM TS 33.501CR2153
  • Editorial change on Security handling in Control Plane CIoT 5GS Optimization TS 33.501CR2096
  • Security handling where CU is acting as MN and SN is unchanged TS 33.501CR2165
  • Update to security handling when CU is acting as MN and SN is unchanged TS 33.501CR2188

Explore further

Broader topics and technologies where CU plays a role.

Defining Specifications

3GPP specifications that define or reference CU, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.725 vg20 Study on URLLC Architecture Enhancements Rel-16
TR 26.926 vj00 Traffic Models & Quality Evaluation for Media/XR in 5G Rel-19
TR 26.962 vj00 ITT4RT Operation and Usage Guidelines Rel-19
TS 28.304 vj00 PEE Parameters Control & Monitoring Requirements Rel-19
TS 28.305 vj00 PEE Control & Monitoring IRP Information Service Rel-19
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TS 43.064 vj00 GPRS Radio Interface Lower-Layer Functions Rel-19