Cloud RAN changes where and how radio processing runs. To understand a proposal, separate the placement of functions, the software and hardware model, and the interfaces between suppliers. Each answers a different design question.
Separate four architectural ideas
| Term | Main question | Evidence to request |
|---|---|---|
| Centralized RAN | Where is processing pooled? | Function placement and transport distances. Centralization alone says little about software or interfaces. |
| vRAN | Which radio functions run as virtualized software? | Supported compute, accelerators, software versions and real-time performance. |
| Cloud-native RAN | How are functions deployed and operated on cloud infrastructure? | Lifecycle management, observability, resilience, scaling and validated platform combinations. |
| Open RAN | Which interfaces and functions support an open, interoperable design? | Named interface/profile versions, integration testing and accountability across vendors. |
3GPP’s Open RAN overview explains the relationship between 3GPP and O-RAN work. O-RAN Alliance specifications extend modular architecture and interfaces. Virtualizing software and opening interfaces can occur together, but neither property proves the other.
Read the radio-to-core path
- Antenna / radio unit (RU)
- Distributed unit (DU)
- Central unit (CU)
- 5G core and data network
In a common split, RU–DU transport is called fronthaul, DU–CU transport midhaul, and RAN–core transport backhaul. Names and functional boundaries depend on the chosen split; this is a logical architecture, not a fixed geographic layout.
3GPP’s 5G system overview describes a gNB split into a CU and one or more DUs linked by F1. The CU handles higher-layer work, while the DU performs lower-layer functions with tighter timing. An RU/DU split introduces another boundary whose bandwidth and timing requirements depend on the implementation.
Ask the designer to mark the actual interfaces and physical sites. “At the edge” could mean a cell site, aggregation building or regional facility. Distance matters through the transport delay, jitter, reliability and available bandwidth that the selected functions can tolerate.
Check the transport and compute budget
RAN workloads are demanding. They are latency-sensitive, compute-intensive, and tied to precise timing. Cloud RAN needs specialized cloud infrastructure with acceleration, synchronization, optimized networking, real-time performance, observability, resilient transport, and careful integration with radios and operations systems.
Fronthaul is often the hardest constraint. Moving low-layer radio information between radio units and processing sites can require high bandwidth and strict timing. If the transport network is expensive, unavailable, or unreliable, centralization loses its advantage. Successful Cloud RAN design starts with realistic transport engineering rather than assuming every function can move freely.
| Design area | Ask for | Why it matters |
|---|---|---|
| Transport | Measured or engineered delay, variation, capacity and protection paths | A low-layer split may stress an existing transport network. |
| Synchronization | Clock source, distribution and holdover design | Radio coordination and selected services depend on timing. |
| Compute | CPU/accelerator, memory, NIC and validated software combination | General cloud capacity is not interchangeable with a tested real-time radio platform. |
| Resilience | Failure domains, spare capacity, restart and upgrade behavior | Pooling may concentrate the impact of an outage. |
| Energy and cost | Site plus transport plus compute measurements under the same load | Moving processing can move costs rather than remove them. |
Compare proposed designs at the same traffic level, service target and redundancy requirement. A claim about server efficiency should identify whether radio power, cooling, transport and idle resources are included. Confirm how additional cells change both normal utilization and recovery capacity.
Use a placement example to expose tradeoffs
A useful historical example is Nokia and Orange’s 2018 trial in Poland, which described distributed radio processing with time-sensitive functions nearer the site. Treat it as evidence of that tested architecture, not a universal prescription for placement.
Make integration and operations part of the design
Cloud-native RAN makes automation more practical because functions can be deployed, scaled, monitored, and updated through software pipelines. RAN intelligent controllers and AI-assisted operations can help optimize energy use, detect anomalies, tune parameters, manage traffic, and support service assurance.
Automation still needs guardrails. Radio networks affect emergency communications, business services, mobile broadband, public safety, and critical infrastructure. Automated changes need testing, rollback, policy controls, security review, and human oversight for high-impact actions. A more programmable RAN is useful when it is also more observable and accountable.
Request a supported bill of materials and a clear incident owner. If the radio, acceleration hardware, cloud platform and orchestration come from different suppliers, determine who reproduces faults and validates upgrades. Open interfaces create opportunities for supplier choice; interoperability and support still require evidence.
For automation, define the measured objective, allowed action range, rollback condition and human escalation. A new optimization should be compared with the prior configuration under equivalent conditions. Core routing and application placement introduces separate service-level decisions above the radio architecture.