Open RAN works. Multi-vendor radio networks are in commercial service and the component-level economics are real. What is less discussed is where the integration effort actually goes, because it is not evenly distributed across the architecture. A small number of interfaces absorb most of the time.
Compliance is not interoperability
The central misunderstanding is that standards compliance implies interoperability. It does not. A specification defines mandatory behaviour and leaves a large surface of optional features, implementation choices and timing tolerances. Two fully compliant implementations can fail to work together because each made a defensible choice at a point the specification did not constrain.
This is normal engineering, not vendor bad faith. But it means interoperability has to be tested and proven per combination, and that the test effort scales with the number of vendor pairs rather than the number of vendors.
Where the time goes
Fronthaul. The radio-to-distributed-unit interface, carried over eCPRI, is the most timing-sensitive part of the system. Delay budgets, synchronisation and the split of function between radio unit and distributed unit are where the hardest problems live. Fronthaul over a transport network rather than dark fibre multiplies this.
Management and configuration. Making units from different suppliers appear in one management system, with consistent configuration semantics and alarm meanings, is unglamorous and consumes more calendar time than the radio interface does. An alarm that means one thing on one vendor’s unit and something different on another’s is how operations teams lose confidence in a network.
Performance counters. If counters are not harmonised, you cannot compare cells across vendors, which means you cannot optimise the network as one network. This is usually discovered during optimisation, which is late.
The RAN intelligent controller. Where deployed, the interface between the controller and multi-vendor radio units is new ground and should be treated as such in the programme plan.
Coexistence with the legacy estate. Almost no operator deploys Open RAN on a clean site. Neighbour relations, handover, and shared transport and power with the incumbent estate are part of the integration scope whether or not anyone budgeted for them.
What to require contractually
Three things make the difference between an Open RAN programme that converges and one that does not.
A named integration owner with acceptance accountability. Not a coordinator. A party that signs against end-to-end KPIs and resolves vendor disagreement at its own cost.
An interoperability test campaign before volume deployment. Proven vendor combinations, on real transport, under load, at coverage boundaries — before the purchase order for a thousand sites.
Harmonised management and counters as an acceptance item. Written into the contract, tested, and signed off. Not assumed.
The honest trade-off
Open RAN lowers unit cost and raises integration cost. For a tier-one operator with a large in-house RAN organisation, that trade is usually favourable because the integration capability already exists. For everybody else, the trade is only favourable if the integration cost is carried by someone contractually obliged to carry it.
That is the whole question. The technology is not the risk. The ownership of the seams is.