When the first Open Radio Access Network (O-RAN) specification was published in 2019, it promised significant, welcome industry disruption. By opening up previously closed, monolithic radio networks to new vendors and architectures, O-RAN aimed to drive down costs and unlock groundbreaking RAN innovations. Judging from early deployments, the technology looks to be living up to its billing. Yet most operators remain in “wait and watch” mode, with large-scale production deployments still likely a couple years away.
Why the tentativeness? While O-RAN brings much needed flexibility, it also adds significant complexity. Traditional proprietary RAN technologies weren’t always cheap or especially innovative, but they did make things simple for service providers. Need RAN coverage? Buy the infrastructure from one of these two or three mammoth trusted vendors. The vendor handled testing, validation, standards compliance, and everything else. With O-RAN, you’re now taking on much of that effort. And the party responsible for making sure all the disparate pieces work together? If you’re architecting your organization’s RAN, you can look in the mirror.
Why does O-RAN make testing and validation so complicated? And how should we rethink our testing approaches if we want it to truly take off? Let’s take a closer look.
Navigating complexity
RAN testing used to mean validating previously proven architecture from one stalwart vendor. With O-RAN, that architecture is disaggregated into its multiple components - radio unit (RU), distributed unit (DU), centralized unit (CU), RAN Intelligence Controller (RIC), and the underlying cloud infrastructure - potentially (and likely) from different vendors. And you’re basically taking on the role of system integrator yourself.
O-RAN testing needs to encompass isolation testing for each component, adjacency testing of pairs of components working together, and end-to-end testing of the full system. And keep in mind, many of these components, even the vendors themselves, haven’t been around long. So, you’ll need to test them like the brand-new technologies they are. That means:
- Validating standards compliance - especially in multi-vendor environments
- Validating the performance of components, individually and in concert, under different load conditions
- Measuring the behavior of each component and the larger system under different traffic volumes, 5G frequency bands, and environmental variables
- Validating application performance across various deployment options (private cloud, public cloud, and hybrid)
- Managing the rate of changes expected in the network across the horizontal and vertical stacks and ensuring these disparate ORAN components function and perform as one unified network
Breaking down RAN testing
Comprehensive testing for O-RAN deployments should cover four key areas:
- Open Radio Unit (O-RU): The radio unit, typically located near or integrated with the antenna, transmits and receives radio signals - making it most sensitive to latency. It’s therefore essential to perform wraparound testing to ensure interoperability, especially in multi-vendor environments. You’ll also need to validate O-RU components for conformance with the O-RAN specification, as well as their performance, mobility, and end-to-end functionality. And you should test each of those aspects across all the different frequencies, bandwidths, and technologies used in your network. You need to know how the O-RU will behave in challenging environments with impairments or interference. And you need to measure its sensitivity and dynamic range in multi-users scenarios, so you can understand the coverage range and total capacity of the cell.
- Open Distributed Unit (O-DU): Located near the cell site or at the edge, the O-DU handles real-time baseband processing for the lower layers of the protocol stack. You’ll need to thoroughly test for scale, performance, throughput, and diverse mobility scenarios, as well as perform interoperability testing with the O-RU and O-CU. You’ll also need to validate the O-DU for the specific applications it supports: voice and video over 5G New Radio (NR), data, and emergency services.
- Open Central Unit (O-CU): The O-CU is all about scale, as this component can support thousands of O-DUs and hundreds of thousands of user equipment (UE) devices. O-CUs handle less latency-sensitive packet processing for the higher layers of the protocol stack. The O-CU interfaces with multiple components of the network - O-DUs, core network, other O-CUs, eNodeB elements, and more - and needs to be tested for interoperability across all of them.
- RAN Intelligent Controller (RIC): One of the truly revolutionary elements O-RAN introduces is the RIC - a platform to run new RAN software applications, potentially from a variety of vendors. These applications can run the gamut from apps to optimize or automate different aspects of RAN functionality, to third-party location services, spectrum enhancers, and more. O-RAN defines two types of RIC platforms - non-real-time (non-RT) and near-real-time (near-RT) - each with its own unique testing requirements. The near-RT RIC will support apps for things like interference management, mobility and quality-of-service management, UE load balancing, and diverse edge services. Non-RT RICs run less time-sensitive apps for things like health checks, alarms and fault management, lifecycle management, and more. Both need to be tested for O-CU and O-DU interoperability over O-RAN-defined interfaces.
Rethinking testing
It’s a lot to consider - especially when you’ve been relying on RAN vendors to handle most of this on your behalf. And yet, the advantages of O-RAN—lower costs, enhanced functionality and security, groundbreaking software innovations that rewrite the rules for what’s possible in the RAN - are too compelling to ignore. To tap into them though, the industry needs a fresh approach to testing and validation. At the highest level, that entails:
- Recognizing that testing is not a one-time project: Your disaggregated RAN will continually change due to software updates, emerging security issues, vendor changes, and more. You should plan for many more testing cycles and an ongoing effort to validate that every component, in every environment, behaves the way it should.
- Embracing automation: Open disaggregated radio networks are far too complex for yesterday’s manual testing approaches. Ideally, you should be able to emulate every network component, in any configuration, and test with real-world applications and traffic loads using fully automated tools.
- Getting help when you need it: Most operators aren’t equipped to take on a massive new testing effort. That’s why service providers launching early O-RAN deployments almost universally work with specialists who have deep knowledge of these technologies and specifications, and who focus exclusively on network testing and validation.
Ultimately, O-RAN will become the default framework for radio access networks - it really is that transformative. The sooner the industry embraces new approaches to testing and validation, the faster we’ll all benefit from what O-RAN can deliver.
