How to Set a Winning Open RAN Testing Strategy

We've previously explored the additional burdens operators are contending with as they embark on yet another new tech journey. This will be no small effort. Research and Markets project that the Open RAN market is expected to cross $32 billion by 2030 with a growth rate of 42% for a forecast period between 2022 and 2030.

For an increasing number of operators, the move to Open RAN (O-RAN) environments is a necessary one that will deliver cost savings and flexibility. They want to capitalize on multi-vendor environments, launch new services in new regions, and further diversify networks to meet emerging market needs. Time and cost requirements to make this a possibility will be significant. This means setting a defined roadmap guided by a comprehensive, continuous testing strategy.

It’s time to toss the old testing playbook

Testing in traditional mobile network environments has essentially become “rinse and repeat.” The functions and applications were well-defined and proprietary vendor environments kept performance and interoperability challenges to a minimum.

The immaturity and unpredictability of O-RAN tech will force operators out of this comfort zone, demanding ongoing attention. They’ll never truly be done testing as more vendors, software updates, deployment environments, security considerations, and open interfaces continuously define a new norm.

Testing requirements will also vary based on deployment objectives. New consumer services are just the tip of the iceberg. Operators will be standing up new offerings at the network edge, launching private networks and expanding geographic coverage. These objectives will need to map back to performance and quality-based testing principles. After all, it is far less costly to discover an issue in the lab, than in the field, after it’s already begun negatively impacting user experiences.

In our O-RAN testing discussions with customers, we’re steering teams away from decisions that could prove to be testing pitfalls. For instance, relying on vendors to continue conducting testing (due to concerns about vendor neutrality), or jumping straight into end-to-end testing before first validating individual components. Even in situations where interoperability is established, performance and capacity testing will also be critical to ensure that end-to-end stacks are ready to perform at scale. Finally, testing in both normal and more unique conditions will be a must to mitigate unwelcome surprises down the line.

O-RAN testing strategies for success

Varying objectives and individual situations mean no two O-RAN testing strategies will look alike. But the most successful strategies will include the core phases below while managed through a single user interface (UI) enabling the user to review KPIs and measurements and troubleshoot logs across all emulators and domains. We previously covered examples of decision-making that take place during some of these phases in our earlier post. Now, let’s dive deeper into what actually occurs from a testing perspective.

1. Isolation or “wraparound” testing

In this phase, a nodal network function like open Central Unit (CU) or open Radio Unit (RU) is wrapped with emulated traffic, representing a range of real-world conditions that might exist in the field. The goal is to confirm individual components can handle expected traffic and functionality. As noted above, these components will also need to be tested at peak performance and capacity levels to ensure they do not become a weak link.

2. Progressive or “adjacency” testing

Here, a combination of network functions is tested together. Perhaps an RU and Distributed Unit (DU), or possibly a DU and CU are surrounded with traffic. Various radio environments are also emulated, along with varying levels of capacity and performance. In this phase, operators aren’t just testing for interoperability, but interoperability at scale. They’re getting a first look at how critical components will perform together in the field. By this stage, issues are already beginning to arise with individual vendors sorting bug fixes, interoperability challenges, and any network bottlenecks that may be discovered. These hiccups should be expected as even open standards will be subject to interpretation, with unique implementations needing to be fine-tuned in the lab.

3. End-to-end testing

All individually tested functions are tested together along with the core network, pumping realistic traffic throughout the entire system. Different 3GPP procedures are validated, quality of service is measured for specific applications, and load conditions are monitored once again. Inevitably, further issues will arise, but operators will be close to getting their O-RAN solution into the field.

4. Continuous integration, continuous deployment, continuous testing

Truthfully, there is no “final” stage of O-RAN testing. Operators will need to adopt a continuous integration, continuous deployment, and continuous testing (CI/CD/CT) approach. In other words, their work on this front will be ongoing as new updates, patches, security vulnerabilities, and vendors enter the picture. To this end, automation will be a cornerstone of any successful O-RAN testing strategy. This is needed in the lab to reduce costs, reduce test time, and also provide a framework for CI/CD/CT deployment. An increasing volume of test cases may be perceived as challenging, but with next-gen lab and test automation, the time and cost can be addressed while also increasing test coverage and reducing failures in the field. One of O-RAN’s core promises is faster service rollouts. This will only be possible with automated testing environments that are paired with automation tech that continuously works to uncover performance-impacting issues in real-time.

Looking for more O-RAN testing strategies? Download our eBook How to Test Open RAN to learn more.