Open radio access networks (Open RAN) bring new testing responsibilities that service providers haven’t had to contend with before. Learn why Open RAN changes the game for testing and validating network components, and how operators should approach these complex new requirements.
Big changes are coming to service provider’s Radio Access Networks (RAN). After years of closed, proprietary radio technologies, Open RAN has started shaking up the status quo. By disaggregating monolithic RAN technologies and bringing new vendors and architectures into the mix, Open RAN promises new innovations and efficiencies. Industry analysts project real multi-vendor Open RAN maturity in as little as one to three years. So, we should expect to see operators deploying all sorts of groundbreaking new RAN capabilities any minute now, right? Well, not so fast.
Open RAN offers an alternative to proprietary, monolithic radio technologies from one of the handful of vendors. It also, however, shifts the burden of testing and integrating RAN components to you. Suddenly, service provider — not the vendor — must make sure all the multivendor pieces fit together correctly and perform the as expected. If you’re imagining the testing capabilities needed to do that, compared with what many service providers have in place today, you can’t help noticing a significant gap.
Why does Open RAN make network testing and validation so much more complicated? What should the industry do to prepare for tomorrow’s open networks? Let’s take a closer look.
Freedom brings complexity and responsibility
Multi-vendor openness is perhaps the most significant driver for Open RAN. By allowing new startups and third-party software vendors to play in this space, Open RAN aims to bring new ideas and capabilities to operators, along with lower costs from increased competition. Open RAN introduces more discrete RAN vendors and components, makes architecting and validating these networks far more complex.
Service providers have traditionally bought RAN baseband units as a single pre-validated system, likely from a single longstanding vendor. With Open RAN, you source multiple components—Radio Unit (RU), Centralized Unit (CU), Distributed Unit (DU), and RAN Intelligent Controller (RIC). You’re responsible for integrating them, testing them, and validating them.
Even if a vendor labels an Open RAN component “plug-and-play,” that doesn’t necessarily mean “plug and perform.” Yes, the vendor is asserting that their component complies with the standard, but that’s just a starting point. You have no guarantee that different vendors have implemented the standards consistently, that their components will interact the way you expect, or that you won’t discover previously unknown problems under certain conditions. Open RAN is still new, as are many of the components you’ll be using. Even some of the vendors are new to Open RAN. You’ll need to perform exhaustive testing on every component, in multiple configurations, simulating a wide range of load conditions, deployment scenarios, and environmental variables. If there’s a problem, it’s now on you to figure out what’s happening and which vendor needs to help fix it.
Build an Open RAN Testing Strategy
What does a viable Open RAN testing approach look like? At the highest level, it should include:
- Isolation testing to validate standards compliance and performance of each Open RAN component;
- Adjacency testing to validate interoperability between pairs of components;
- End-to-end testing to validate that multi-vendor RAN components function as a unified system.
Performance testing to verify that your Open RAN architecture is hitting the targets you’ve set.
Figure 1. Open RAN functional components need testing for standards compliance, functionality, and interoperability.
If this sounds like a significant effort, it is. So, how should you approach it? Start with thorough, methodical interoperability and performance testing for each element of the architecture (Figure 1).
RU: Typically deployed near the antenna or integrated with it, the RU processes radio signals, amplified them, and digitizes them. It’s the most delay-sensitive component of the RAN, so you’ll want to perform wraparound testing to ensure interoperability with other components. To understand the coverage range and capacity of a cell, you’ll need to test for performance, mobility, and end-to-end functionality across diverse real-world scenarios. That includes testing across multiple bandwidths, frequencies, modulation schemes, and antenna types.
DU: The DU performs real-time baseband processing and handles the lower layers of the protocol stack. This component plays a key role in Open RAN’s flexibility to support different distributed architectures and splits. The DU can be located near the cell site or at the network edge. You’ll want to thoroughly test the DU for capacity, performance, throughput, and mobility. You’ll also need to validate its interoperability with the RU and CU, and its support for diverse voice, video, data, and emergency services.
CU:> The CU performs less time-sensitive processing for higher layers of the protocol stack. It connects to other CUs and, potentially, thousands of DUs and hundreds of thousands of user devices. Therefore, you should thoroughly test this component for performance, throughput, and capacity at massive scales, as well as validating interoperability with DUs and the core network.
RIC: The RIC acts as innovation enabler in Open RAN architectures — a platform to run software from new vendors and startups in the RAN. That software can enable a variety of new capabilities such as automating lifecycle maintenance tasks, optimizing resources, integrating third-party intelligence into customer-facing services, and so on. RICs come in two flavors: near-real-time (near-RT) and non-real-time (non-RT), both of which you should thoroughly test for interoperability with OU and DU components.
This kind of testing doesn’t represent entirely new ground for service providers, but it’s a much bigger effort than was needed in the past. It’s also not a one-time job. Open RAN doesn’t just mean more network components, it means more updates to those components, from different vendors releasing software at their own cadences. So, you’ll need to support this testing effort on an ongoing basis and repeat it every time something in the environment changes.
It’s hard to overstate the value that Open RAN can bring to operators and their customers, but we shouldn’t downplay how big of a change it represents. You need to emulate every part of an Open RAN architecture, test with real-world applications, and automate many aspects of the testing process.
