What Is Open RAN? The Architecture, the Promise, and the Fine Print
Open RAN in plain terms: what operators are actually trying to achieve, what the architecture changes, and why 'open' does not mean plug-and-play.
Ask ten people in this industry what Open RAN is and you'll get ten answers — a cost-reduction play, a geopolitical supply-chain move, a cloud migration, a new radio standard. Only the last one is definitively wrong.
Open RAN is an architectural approach, not a technology in itself. The radio is still 5G NR. What changes is where the functional boundaries sit, which of them are specified openly, and who is allowed to build each piece.
This article covers the why and the what it's actually like. For the interface-by-interface reference — O1, O2, A1, E2, Open Fronthaul, and how the RIC works internally — see O-RAN Architecture Explained.
Why operators pushed for this
The traditional RAN procurement model looks like this: an operator buys CU, DU, RU, and management from a single supplier as an integrated system, with proprietary interfaces between the parts.
That model has real advantages — one throat to choke, tested end to end, predictable performance. It also has one structural consequence: once you've deployed vendor A at a site, replacing any single component means replacing all of them.
By the mid-2010s that concentration had narrowed to a handful of global RAN suppliers. Open RAN is, at root, the industry's attempt to change that equation by standardising the seams.
The stated objectives are consistent across operator groups:
- Vendor diversity — more suppliers competing for each component
- Faster innovation — a smaller company can build one good radio without building a whole RAN
- Hardware/software decoupling — RAN software on commercial compute rather than purpose-built appliances
- Programmability — a defined place to insert optimisation logic
- Automation — management and orchestration through open, modelled interfaces
Whether Open RAN delivers all of this is a live commercial question. That it changes the architecture is not.
The four ideas underneath it
Disaggregation
The base station gets split into three functional blocks — Central Unit, Distributed Unit, Radio Unit — following the 3GPP split, with O-RAN then specifying the DU-to-RU boundary that 3GPP left open.
Roughly: the O-CU handles higher-layer, less time-critical protocol work. The O-DU handles scheduling, HARQ, RLC, MAC and upper PHY — the hard real-time core. The O-RU handles lower PHY and RF, sitting closest to the antenna.
Open interfaces
Disaggregation on its own achieves nothing if the boundaries stay proprietary. The point of O-RAN's interface specifications is that the seam between vendor A's O-DU and vendor B's O-RU is publicly defined rather than negotiated privately.
The Open Fronthaul between O-DU and O-RU is the defining one — it's the interface that makes a genuinely mixed-vendor cell site conceivable.
Cloudification
Rather than baseband software bound to purpose-built hardware, RAN functions run as workloads on shared infrastructure.
Worth being precise here: cloud-native RAN is not an ordinary IT workload that happens to live in a telco. O-DU processing carries deterministic latency requirements, microsecond-class synchronisation, sustained packet processing, and real-time scheduling constraints. It usually needs hardware acceleration. "It runs on COTS" and "it runs on any server" are very different claims.
Programmability
The RAN Intelligent Controller gives the architecture a defined place to put optimisation logic, split into a Non-RT RIC for longer-timescale policy and analytics, and a Near-RT RIC for faster control.
The applications that run there — rApps in the Non-RT RIC ecosystem, xApps in the Near-RT RIC — are the ecosystem play. The idea is that RAN optimisation becomes something you can buy or build independently of your RAN vendor.
Three things Open RAN is not
It is not a new air interface
5G NR remains the radio technology. A UE cannot tell whether it's attached to an Open RAN or a traditional cell, because from the UE's perspective nothing has changed.
It is not open source
This confusion is common enough to be worth stating flatly.
Open RAN means open specifications and interfaces. A fully compliant O-DU can be entirely proprietary, closed-source, commercial software. Open-source RAN projects exist — the O-RAN Software Community and OpenAirInterface among them — but they're a separate thing that happens to overlap.
It is not plug-and-play
This is where expectations most often break. Two components can both pass conformance testing against the same specification and still not work together well.
Interface compatibility is the easiest of the six. Performance compatibility, timing behaviour under load, and operational integration are where integration programmes actually spend their time. This is precisely why PlugFests, Open Testing and Integration Centres, and certification badges exist — and why systems integration has become a real line item in Open RAN business cases.
Open RAN vs AI-RAN
These get used interchangeably and shouldn't be.
Open RAN changes the shape of the network. AI-RAN changes how it behaves.
They're complementary rather than competing. Open interfaces and the RIC give AI-driven control somewhere sensible to plug in — but you can deploy AI in a traditional RAN, and you can deploy Open RAN with no AI at all.
You don't have to go all the way
One of the more useful things to understand is that Open RAN is a toolbox, not a single mandatory deployment shape. Real networks pick points on a spectrum:
Fully disaggregated — separate O-CU, O-DU, and O-RU, potentially from three suppliers. Maximum flexibility, maximum integration effort.
Partially integrated — open interfaces where they matter most, with an integrated O-DU and O-RU from one vendor. Common in practice, especially where fronthaul timing is unforgiving.
Cloudified without full disaggregation — RAN software on O-Cloud infrastructure, keeping vendor-integrated function boundaries. Captures the operational benefits without taking on multi-vendor radio integration.
Most commercial deployments today sit somewhere in the middle two. That's not a failure of the vision; it's operators sequencing risk.
Integration is the cost nobody budgets
The disaggregation argument assumes that once interfaces are open, components combine freely. They do, eventually. The gap between "the interface is specified" and "these two products work together in a live network" is where Open RAN programmes actually spend their money.
A traditional single-vendor RAN arrives pre-integrated. The vendor has tested its RU against its DU against its CU across the parameter space, and when something fails there is one organisation responsible.
A multi-vendor deployment moves that work to the operator. Interfaces have optional features, and two implementations may each be compliant while supporting disjoint option sets. Timing and synchronisation must be validated end to end. Performance under load, at cell edge, during mobility, with mixed device populations — all of it must be characterised by whoever assembled the system.
This is why Open Test and Integration Centres and plugfests exist, and why systems integrators have become a distinct role. It is also why the early commercial deployments were greenfield operators with no legacy to protect and a willingness to carry integration risk in exchange for supply-chain independence.
The cost is real but front-loaded. It is paid once per combination, not per site — which is precisely why operators converge on a small number of validated combinations rather than mixing freely.
What Open Fronthaul actually demands
Of all the interfaces, Open Fronthaul is where the engineering bites hardest, because it carries the tightest real-time requirements in the entire architecture.
The split 7.2x fronthaul carries frequency-domain samples, and the DU must deliver them to the RU in time for transmission. Latency budgets are in the hundreds of microseconds, and the variation matters as much as the mean — jitter that would be invisible to any application protocol will break the radio.
Synchronisation is the harder half. TDD requires that base stations agree on when the uplink and downlink periods begin, and disagreement between neighbours does not degrade gracefully — it produces direct interference, with one site transmitting into another's reception. The accuracy requirement is measured in the low hundreds of nanoseconds, delivered by PTP with hardware timestamping and, in many deployments, GNSS at the site as a reference.
The practical consequence is that Open Fronthaul turns a vendor-internal cable into a network with engineering requirements stricter than anything else the operator runs. Transport teams accustomed to millisecond-scale service-level agreements find themselves specifying nanosecond-scale ones.
Where it delivers. Supplier choice at the radio layer. A credible path for smaller vendors. Cloud operational models and automated lifecycle management. A standard place to insert optimisation logic. Private and enterprise 5G, where the deployment is small enough that integration risk is manageable and the flexibility genuinely pays.
Where it costs you. Integration complexity scales with the number of vendor combinations, not the number of vendors. Cloud compute must still hit RAN timing budgets. Open Fronthaul synchronisation is genuinely demanding. More interfaces and more software suppliers mean a larger security surface and a longer supply chain to trust. Multi-vendor lifecycle management and fault isolation are harder than calling one vendor. And general-purpose compute is not automatically more energy-efficient than purpose-built silicon — that one surprises people.
None of these are arguments against Open RAN. They're the reason serious deployments run long integration programmes before they run traffic.
Energy is the argument that changed the conversation
Early Open RAN advocacy led with cost and vendor choice. The argument that moved conservative operators was energy, because the RAN consumes the large majority of a mobile network's electricity and most of that is in the radio units and their amplifiers.
Disaggregation helps in a specific way: it makes energy a controllable quantity rather than a fixed property of the equipment. When the RIC can observe load across a region and act on it, capacity layers can be switched off at night, carriers shut down and reopened as demand moves through the day, and antenna elements powered down when the traffic does not need them.
None of that requires Open RAN in principle — a single-vendor system can do the same internally, and several do. What the open architecture adds is that the policy is written once, by the operator, and applies across vendors. An operator running four RAN vendors otherwise implements the same energy strategy four times, in four proprietary systems, with four different sets of limitations.
The savings reported from carrier and cell shutdown are in the tens of percent during low-traffic hours. That is a large enough number to justify programmes that vendor-choice arguments alone never did.
Where it has actually been deployed
The deployment record is more mixed than either advocates or critics usually present, and it splits cleanly by operator type.
Greenfield operators — Rakuten in Japan, DISH in the United States, 1&1 in Germany — built Open RAN networks from nothing. No legacy, no incumbent relationship to manage, and a business case that depended on doing something structurally different. These are the genuine full-stack deployments.
Large incumbents have moved more cautiously and more narrowly. Vodafone's UK programme and Deutsche Telekom's work are real but bounded, often starting in rural areas where the traffic is lower and the risk of a bad outcome is contained.
Everyone else has adopted the parts rather than the whole: virtualised CU and DU from a single vendor, O-RAN-compliant interfaces retained for future optionality, and no multi-vendor mixing at the radio. This gets the cloud-native operational model without the integration burden, and it is by a wide margin the most common outcome.
Reading that record honestly: the architecture is proven, the interfaces work, and the multi-vendor radio market that motivated the whole exercise has developed far more slowly than expected.
If you keep one picture, keep that one. Management and orchestration on top, intelligence in the middle, disaggregated RAN functions and cloud infrastructure underneath, and 5G NR unchanged at the bottom.
Open RAN is best understood as an industry-scale experiment in whether the radio access network can become as software-defined and multi-sourced as the rest of the network stack already has. The architecture is settled. The commercial verdict isn't in yet.
Further reading
- O-RAN Architecture Explained — the interfaces and RIC in detail
- O-RAN ALLIANCE — architecture specifications and working group outputs
- 3GPP TS 38.401 — NG-RAN architecture and the CU/DU functional split