English
Our last post on the move to Open RAN explored the additional burdens operators are contending with as they embark on yet another new tech journey. This will be no small effort. Appledore Research predicts total spend on Open RAN components and services to grow to USD 11.2 billion in 2026¹, with deployments at a majority of cell sites.
For an increasing number of operators, the move to Open RAN (ORAN) 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 Open 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 Open 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.
Open RAN testing strategies for success
Varying objectives and individual situations mean no two testing strategies will look alike. But the most successful strategies will include the core phases below. We previously covered examples of decision making that takes place during some of these phases in our earlier post. Now, let’s dive deeper into what actually occurs from a testing perspective.
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.
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 for 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.
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.
Continuous integration and continuous deployment testing – Truthfully, there is no “final” stage of Open RAN testing. Operators will need to adapt a continuous integration and continuous deployment (CI/CD) 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 Open RAN testing strategy. This is needed in the lab to reduce costs, reduce test time, and also provide a framework for CI/CD 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 Open 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.
In our next post, we’ll cover how to select the best Open RAN testing partner for your deployment needs. In the meantime, be sure to download the Spirent 2021 5G Report highlighting market drivers, insights and considerations for the year ahead for more of our thoughts on what’s to come for Open RAN.
¹Open RAN -Opening the RAN Ecosystem for Competition and Innovation, Appledore Research, Dec 2020
