Few concepts in wireless infrastructure have been promoted as confidently as Open RAN. The pitch was straightforward: break the radio access network into interoperable components, define open interfaces between them, and operators would no longer be tied to a single equipment supplier. More vendors would compete for their business, costs would fall, and innovation could move at something closer to software speed rather than waiting for the next generation of a proprietary base station.
It was an appealing argument. After several years of commercial deployment, however, there is enough real-world evidence to ask a more practical question. What did operators gain from Open RAN, and what did they have to take on in return?
The first concern was performance, and on that point Open RAN has made substantial progress. Early multi-vendor deployments often trailed integrated RAN systems by 15% to 25% on important performance measures. Today, that gap is generally closer to 5% to 10%. It has not disappeared, but for many parts of the network it is no longer large enough to rule out the architecture.
Commercial deployments have also moved beyond laboratory demonstrations. AT&T is roughly halfway toward its goal of carrying 70% of its wireless traffic on open-capable platforms and has completed live calls using third-party radios. That was an important proof point because the radio interface was where many of the original doubts were concentrated. Rakuten Mobile continues to support millions of subscribers across a broad collection of suppliers, while Dish built a national greenfield network around a cloud-native, disaggregated model. In other words, Open RAN works, but the more complicated question is what it takes to make it work.
The Interface That Does the Real Work
The architecture’s defining technical break occurs at the lower-layer functional split known as Option 7-2x. This split sits inside the physical layer, between the distributed unit (O-DU) and the radio unit (O-RU). High-PHY functions remain in the O-DU, while low-PHY functions such as FFT and iFFT processing, cyclic-prefix insertion and removal, and PRACH filtering move into the O-RU. In the Category B implementation, the radio also handles digital beamforming and precoding.
The two units communicate over an eCPRI-based Ethernet fronthaul, usually operating at 10 or 25 Gbit/s. That is a major departure from the fixed-rate CPRI links used in earlier centralized-RAN systems.
There is a real benefit to this arrangement. Option 7-2x transports frequency-domain data for each spatial layer rather than sending time-domain samples for every antenna port. Block floating-point compression further reduces the load. Together, these techniques can cut fronthaul bandwidth by as much as a factor of five compared with CPRI.
That difference matters enormously in a 64T64R massive-MIMO radio operating at 3.5 GHz. With a typical eight- to 16-layer configuration, the system can remain within the 25-Gbit/s Ethernet class instead of requiring an impractical amount of dedicated fiber for every antenna stream.
This is one of the places where disaggregation clearly earned its keep. What received less attention in the original sales pitch was how unforgiving the interface becomes once all of those functions are separated.
A Budget Measured in Microseconds
Open fronthaul operates under a one-way transport-latency budget of about 100 microseconds. For ultra-reliable low-latency traffic, the budget can fall to 50 microseconds. That compares with roughly one millisecond across the midhaul and approximately 10 milliseconds across the backhaul.
Those numbers leave little margin for error. Light travels through single-mode fiber at roughly five microseconds per kilometer, so the latency allowance quickly becomes a distance limit as well. Every switch, router, accelerator and other active device along the route consumes part of the remaining budget.
Synchronization is even less forgiving. In a TDD network, cells must remain aligned to within approximately ±1.5 microseconds at the antenna. Achieving that requires individual elements in the fronthaul timing chain to operate within tolerances measured in tens of nanoseconds.
That normally means deploying the full timing-support profile defined by ITU-T G.8275.1, with PTP-aware boundary or transparent clocks at every node and Synchronous Ethernet providing the underlying frequency reference. None of this is ordinary packet-network engineering. It is hard real-time systems work.
In an integrated base station, much of that responsibility belonged to one supplier. In an Open RAN deployment, the operator or its systems integrator must make equipment from several companies behave as though it came from one engineering organization. That transfer of responsibility is arguably the most important consequence of disaggregation.
It also appears in two areas that received far less attention during Open RAN’s early promotion: power and security.
The Power Penalty
The power penalty is measurable. Open RAN equipment can still consume roughly 15% to 20% more energy than an equivalent integrated system. Some of that increase comes from the processing and transport overhead created by standardized interfaces. Some comes from virtualization itself.
In a dense network, higher power use can consume much of the savings that operators expected to receive from greater supplier competition. For an industry that increasingly treats energy per bit as a central design constraint, this is not a minor issue.
A More Complicated Security Picture
Security presents an equally complicated tradeoff. Disaggregation does not necessarily create complexity from nothing. It moves complexity into different parts of the system. The same is true of the attack surface. Every newly exposed interface becomes another boundary that must be authenticated, protected, monitored, and maintained.
These interfaces include the open fronthaul between the O-DU and O-RU, F1 between the DU and CU, E2 and A1 between the RAN and its near-real-time and non-real-time RAN Intelligent Controllers, and O1 and O2 into the management and cloud environments.
The open fronthaul alone includes control, user, synchronization and management planes, each with its own vulnerabilities. The synchronization plane is a particularly useful example because it shows how security and physical-layer performance can collide.
An attacker does not necessarily have to defeat encryption to disrupt a TDD network. Flooding the master clock with excessive PTP traffic may be enough to push synchronization beyond the ±1.5-microsecond alignment requirement. Once that happens, TDD operation can fail.
The management plane can also be exposed to interception or man-in-the-middle attacks when the fronthaul is inadequately protected. Encrypting that traffic seems like the obvious answer, but it comes at a price. MACsec and similar protections introduce latency and jitter into a transport path that may have only 100 microseconds to spare.
Fronthaul encryption is therefore not simply a security box that can be checked without consequence. It is a system-level engineering decision that must be balanced against timing and performance requirements.
The RAN Intelligent Controller introduces another concentration of risk. The near-real-time RIC operates over the E2 interface on control loops ranging from about 10 milliseconds to one second and can host third-party xApps. That makes it valuable operationally, but it also creates an attractive target.
Researchers have already identified numerous denial-of-service scenarios involving the RIC, individual cells and ordinary control protocols. Signaling-storm attacks, for example, can overwhelm network resources without relying on particularly exotic methods.
A multi-vendor network also inherits a broader supply-chain problem. Its security is only as strong as the weakest supplier, software component or development practice in the system. Once the RAN becomes software-defined and cloud-based, it acquires many of the same patching, dependency-management and software-supply-chain risks that have affected the wider IT industry for years.
This does not mean Open RAN is inherently insecure. The O-RAN Alliance has made substantial progress in security specifications, threat modeling and interface protection. A properly implemented zero-trust architecture is entirely achievable.
The distinction is that security does not arrive automatically with the architecture. It must be designed, tested and continuously maintained by the operator. A traditional base-station supplier delivered much of that work inside an integrated product. Open RAN gives the operator more flexibility, but it also hands back responsibility for verifying that numerous independent implementations behave correctly at every boundary.
Reconciling the Contradiction
This helps explain what can otherwise look like a contradiction. Open RAN continues to attract major commercial commitments, yet operator surveys often show that it has fallen in priority compared with the enthusiasm of several years ago.
Both trends can be true. The operators making the most progress are generally those that treated Open RAN as a serious systems-integration program. They brought interoperability, timing, cloud operations and security expertise in-house and funded those capabilities accordingly.
Operators that expected standardized interfaces to produce an almost plug-and-play marketplace have had a different experience. They found that the interfaces solved only part of the problem and that the remaining integration burden was considerably heavier than advertised. Some have responded by slowing deployments, narrowing their ambitions, or relying more heavily on a lead vendor.
For the RF and microwave industry, the lesson is straightforward: an interface specification is the beginning of the engineering process, not the end.
A radio unit can conform to a specification and still fail to interoperate smoothly with another supplier’s distributed unit. Two products can interoperate and still fail to meet nanosecond-level synchronization requirements across a multi-vendor timing network. Even a properly synchronized system may still consume too much power or expose unacceptable security risks.
The Radio’s Job Hasn’t Changed — Its Context Has
Meanwhile, the O-RU must continue to solve the same RF problems it always faced. Its GaN Doherty amplifiers must meet linearity and efficiency targets. Digital predistortion and crest-factor reduction must allow those amplifiers to operate close to saturation without degrading signal quality. A 64-element array must be calibrated accurately and kept calibrated as operating conditions change.
A virtualized O-DU running Layer 1 functions on commercial off-the-shelf servers must handle demanding workloads such as forward-error correction and LDPC encoding and decoding. General-purpose processors are not especially efficient at these tasks compared with the purpose-built silicon used in a conventional baseband unit.
Hardware acceleration can close much of the gap, but that introduces another set of design decisions. Operators must choose between look-aside and inline accelerators, each of which has different implications for latency, power consumption, throughput and software complexity. Packetized fronthaul adds more overhead, and an O-Cloud built around general-purpose computing remains less efficient than fixed-function hardware in many operating conditions.
The difference is that the radio now performs those tasks as one element in a much larger multi-vendor system. Its timing, transport and security constraints are increasingly determined outside its enclosure.
Open RAN did deliver the supplier diversity it promised. What it did not do was eliminate the hardest engineering problems. It moved many of them from the equipment vendor’s integration laboratory into the operator’s network.
The industry would have set more realistic expectations if it had said that plainly from the beginning.