Open RAN, and What It Changes for a Buyer
Open RAN splits a radio access network that used to arrive as one supplier's product into parts that can be bought separately: a radio unit, a distributed unit, a centralised unit and a controller, connected by published interfaces. The O-RAN ALLIANCE specifies those interfaces. For an MVNO this is almost never a purchasing decision, because the radio network belongs to the host; what it changes for you is which features your host can adopt, and how quickly.
Open RAN describes an approach to radio access networks that uses specified open interfaces between relevant components. Network disaggregation is the broader separation of functions or hardware and software that were previously delivered as a tightly integrated system. The ideas can be used together, but they describe different architectural choices.
For most MVNOs, Open RAN is primarily a feature of the host operator's infrastructure rather than a component they directly purchase. It becomes more directly relevant when a business participates in private-network deployment or operates radio infrastructure under an appropriate arrangement. Evaluate the approach through service performance, integration capability and lifecycle cost, not through the assumption that openness automatically makes a network cheaper or simpler.
On this page
- History and Evolution of Radio Network Disaggregation
- Core Utility and Functionality of Open RAN
- What is Open RAN Used For?
- Key Functions and Architectural Components
- Technical Integration and Data Model
- Integration with Other Systems
- Technical Data Model and Key Interfaces
- Ownership for MVNOs and IoT Companies
- Why Consider Open RAN?
History and Evolution of Radio Network Disaggregation
Radio access networks have traditionally been delivered through integrated supplier systems, even though mobile networks already used many standardised interfaces. Virtualisation introduced additional separation between software and computing hardware. Open RAN initiatives extend the focus on interoperable interfaces and a broader supplier ecosystem across parts of the radio architecture.
The O-RAN ALLIANCE develops specifications covering relevant architecture, interfaces and processes. Open RAN is also used more broadly as an industry term. Distinguish a general architectural claim from conformance to a particular specification and version. A supplier should identify what is implemented and which component combinations have actually been tested.
Core Utility and Functionality of Open RAN
Disaggregated and integrated radio access compared
| Feature | Disaggregated | Integrated |
|---|---|---|
| Hardware and software | Sourced separately, often different suppliers | Supplied together as one product |
| Interfaces between the parts | Published, with several implementations | Internal to the supplier |
| Where the intelligence sits | In a controller others can write to | Inside the supplier platform |
| Upgrade path | Per component, in principle | Per platform release |
| Who carries integration | The operator or an integrator | The supplier |
| Fault isolation | Harder: more boundaries to prove | Simpler: one party to call |
What is Open RAN Used For?
The approach can give an operator more choice over how radio-network components are sourced and combined. It can also support programmable management and optimisation. These possibilities matter when the operator has the capability to integrate and operate the resulting system, either internally or through an accountable delivery partner.
Disaggregation changes where responsibilities sit. A traditional supplier may have managed compatibility across a large integrated product. In a disaggregated design, that coordination must still happen, but it may be shared across several organisations. The buyer should identify who owns complete service performance before selecting individual components on price or advertised capability.
Key Functions and Architectural Components
Radio architectures can separate radio units, distributed units and centralised units, with interfaces connecting their responsibilities. The precise split and deployment determine transport and computing requirements. For procurement, the important question is whether the chosen combination supports the intended bands, capacity and features within the available site and transport environment.
O-RAN specifications include interfaces and management concepts that support this separation and control. RAN Intelligent Controller functions can host applications for optimisation within their defined scope. Such capabilities require suitable data, supported control actions and careful operational policies. An intelligent controller should not be assumed to improve performance merely because it is present in the design.
Virtualisation concerns how functions run on computing infrastructure, while openness concerns relevant interfaces and interoperability. A virtualised RAN can still rely on proprietary interfaces. Conversely, an open interface does not imply that every component is open-source software. Keep these distinctions clear when comparing proposals so one attractive label does not stand in for several unproven claims.
Technical Integration and Data Model
Integration with Other Systems
The radio network connects devices to the core and depends on transport, timing, power and management systems. A disaggregated deployment needs these relationships engineered as one service. The core network elements overview provides context for the boundary between access infrastructure and the functions that manage subscriptions and sessions.
Transport requirements depend on the chosen functional split and deployment. Capacity, delay, variation in delay and synchronisation can all matter. A component combination that performs well in a laboratory may not fit an existing site network. Survey and test the actual transport environment before assuming that standardised interfaces make it suitable without changes.
Management integration must connect inventory, configuration, alarms and software lifecycle processes. Operators need to know which versions and settings are active across components. A configuration change in one product can affect the behaviour of another. The integration owner should maintain a tested compatibility baseline and a controlled process for introducing changes.
Technical Data Model and Key Interfaces
The operating inventory should identify sites, cells, radio components, software versions and dependencies. Maintain relationships to transport and power infrastructure. This helps teams determine which customers and services may be affected by a component failure or maintenance activity. Separate supplier inventories are insufficient if no one can assemble the complete service view.
What disaggregation actually separates, and who picks up the integration.
Performance data needs consistent time and context. Measurements from different components should support meaningful correlation rather than merely fill separate dashboards. Agree which service indicators matter and how they are measured. Throughput alone may not capture coverage problems, mobility behaviour or reliability under load.
Security interfaces and management access need explicit ownership. Several suppliers can increase the number of credentials, update channels and administrative tools. Evaluate access control, software integrity and incident response across the whole deployment. Openness can improve visibility into interfaces, but it does not remove the need to configure and maintain secure systems.
Ownership for MVNOs and IoT Companies
What it changes for a wholesale buyer
| Question to the host | Why it is the part that affects you |
|---|---|
| How fast does a new capability reach us | This is the only effect your customers notice |
| Does the coverage plan change | Supplier changes can shift rollout priorities |
| How is a fault isolated now | More boundaries can mean longer incidents |
| Does anything change in our interfaces | Usually no, and you want that confirmed |
| Does the roadmap commitment still hold | Architecture programmes absorb attention |
Why Consider Open RAN?
An MVNO buying wholesale access should focus on the service the host delivers. It may benefit indirectly from host-network innovation, but it generally does not choose the host's radio components. Ask how the architecture affects coverage, performance and change management where relevant, without assuming the wholesale contract grants direct control of the RAN.
The useful question for a wholesale buyer is not whether a host runs Open RAN, but what it lets the host do that matters to you: how quickly a new capability reaches your customers, whether coverage plans change, and whether a supplier change at the radio layer could interrupt your service. Ask about those three, not about the architecture. If you do want to follow the work itself, the alliance publishes which technical group owns which part of the architecture.
An IoT provider or enterprise involved in private networking may have a more direct procurement role. Open RAN can be one option for the access layer, alongside integrated solutions. The guide to mobile cores and private networks helps frame the wider design, but radio and core responsibilities still need separate evaluation.
Advantages and Disadvantages
Advantages:
- Open interfaces can broaden component choice and reduce dependence on a single integrated supplier in selected parts of the network. They can also create opportunities for specialised products and applications. The practical benefit depends on the availability of tested alternatives that meet the operator's requirements and can be supported over the deployment lifetime.
- Disaggregation may allow computing and radio components to evolve on different schedules. This can support more flexible investment where the architecture and contracts permit it. Evaluate that flexibility with an actual upgrade scenario. A theoretical ability to replace one component is less valuable if doing so requires extensive retesting or changes elsewhere in the network.
Disadvantages:
- Integration effort can be substantial. Interface compatibility does not establish feature compatibility or equivalent behaviour under every operating condition. The operator needs testing across mobility, load, recovery and software changes. These costs should be included in the business case rather than treated as work that disappears because the interface is open.
- Performance, energy use and infrastructure requirements also need measurement. General-purpose or virtualised infrastructure does not guarantee lower power consumption or cost for every workload. Compare complete deployments under equivalent conditions, including accelerators, transport and management. Supplier choice is useful only when the resulting service remains practical to operate.
Organizational Impact of Disaggregation
An organisation adopting a disaggregated network needs a clear integration authority. This may be the operator, a lead supplier or a systems integrator. The authority should manage compatibility, testing and cross-supplier incidents. Without it, each component provider can meet its own obligations while the complete service fails to meet the customer's requirement.
Procurement should align the contracts around shared acceptance criteria. Avoid buying components independently and discovering later that no supplier is responsible for the combined result. Define the tested configuration, supported upgrades and evidence required for handover. A certificate or laboratory result should be read within its actual scope rather than treated as universal compatibility.
Operations staff need training and tools that match the new responsibilities. Fault diagnosis may cross radio software, compute infrastructure and transport. Establish joint troubleshooting procedures and access to the relevant evidence. The team should be able to identify a service-impacting issue without manually reconciling incompatible logs from several suppliers during every incident.
Request a trial using the intended configuration and realistic traffic. Include the actual frequency bands, device types and site constraints. Compare lifecycle cost with an integrated alternative, including integration, support and future upgrades. Use the solution provider selection guide to structure a commercially meaningful evaluation.
Redundancy and High Availability
Resilience must account for each component and its shared dependencies. Several software instances can still rely on one power source, timing source or transport path. Identify the failure domains and the surviving capacity after an outage. A distributed architecture can create opportunities for resilience, but it can also introduce dependencies that are easy to overlook.
Test recovery under load and with active devices. Measure service interruption, reattachment behaviour and the effect on the intended applications. Include management-system failures as well as radio-component failures. A network that continues carrying traffic but cannot be safely configured or diagnosed may still create an unacceptable operational condition.
Software upgrades require a tested sequence and rollback plan. Changing one component can affect its peers even when the interface version appears unchanged. Maintain a compatibility record and repeat the relevant service tests after significant changes. Long-term availability depends on disciplined lifecycle management as much as on the initial redundancy design.
Impact of 4G and 5G and Future Networks
Open RAN in 4G Services
Disaggregated approaches can be relevant to LTE deployments, but support varies by product and architecture. Evaluate the actual radio and service requirements rather than assuming the approach is exclusive to 5G. For an MVNO, the wholesale service still needs to meet the same customer-facing requirements regardless of the host's implementation.
Open RAN in 5G Services
5G deployments provide additional opportunities and demands for radio-network design. Capacity, computing and transport requirements should be assessed together. Advanced core capabilities such as network slicing do not follow automatically from an Open RAN purchase. The complete access, transport, core and operational design must support the intended service.
Long Term Network Planning
Open interfaces can support flexibility, but future compatibility should be backed by a maintained roadmap and tested upgrade process. Preserve configuration and performance evidence so alternatives can be evaluated over time. Avoid treating an open architecture as a promise that every future component will be interchangeable without engineering work.
Frequently Asked Questions
Is Open RAN the same as a virtualised RAN?
No. Virtualisation concerns separation of software from its computing hardware. Open RAN concerns specified interfaces and interoperability across relevant components. A deployment can combine both, but one does not automatically establish the other.
Does Open RAN mean open-source software?
No. Products using open interfaces can be proprietary commercial software and hardware. Review licensing and support separately from interface standards. Open-source components may be part of a design, but they are not required by the general label.
Does an MVNO need to buy Open RAN equipment?
Usually the host operator supplies radio access. Direct procurement becomes relevant only where the business has an appropriate role in operating radio infrastructure, such as a private-network project. Start with the actual operating responsibility.
Will disaggregation always reduce cost?
No. Component savings can be offset by integration, transport, testing and operations. Compare complete lifecycle costs under equivalent service conditions. The result depends on the deployment and the organisation's ability to manage it.
Who is responsible for interoperability?
The delivery model should name an integration authority accountable for the combined system. Component suppliers still have responsibilities, but someone must coordinate compatibility, acceptance and cross-supplier incident resolution
Is certification enough to skip a deployment trial?
No. Certification and interoperability evidence are valuable within their stated scope. The intended configuration, devices and site conditions still need validation. Check exactly which versions, interfaces and features were tested.
What should a supplier demonstrate?
Request service performance, management integration and recovery on the proposed component combination. Include realistic load, software changes and site constraints. Compare the result with the required customer outcomes and complete operating cost.
Summary
Open RAN and network disaggregation can broaden design and supplier choices, but they also change integration and operating responsibilities. Their value should be demonstrated through a complete deployment that meets the intended service requirements.
Compare radio, core and integration partners through the MVNO Index provider directory. Request a scoped architecture and representative trial before committing to components or assuming a particular cost advantage.
General Information
