Walking the floor at Mobile World Congress last February, there could be no doubt that the age of Open Radio Access Networks (Open RAN) had officially arrived. Just six years since 3GPP first described a next-generation RAN architecture,1 a sprawling Open RAN ecosystem has emerged. Stakeholders across the industry, from traditional network equipment providers and chipmakers to device manufacturers, new startups and independent software vendors were showing off groundbreaking Open RAN solutions. It was everything that advocates for open radio interfaces could have hoped for, except for one thing; real-world deployments.
The promise of Open RAN remains alluring as ever. By virtualizing and disaggregating the RAN and opening it up to new vendors and software-defined architectures, we should see a long list of benefits: increased competition, lower costs, innovative new service models and more. It’s why every major communication service provider (CSP) is now conducting some sort of Open RAN trial. Almost all of these initiatives, however, remain stuck in proof-of-concept.
What’s preventing Open RAN from progressing through the “peak of inflated expectations” in the Gartner Group’s Hype Cycle, beyond the “trough of disillusionment” (where many CSPs find themselves today), to viable, productive solutions? In a word, complexity. Open RAN brings so many new architectural components, along with such radically different technical and operational requirements, there were always going to be open questions about how to proceed. Less appreciated, however, was just how much work would be needed to answer these questions. The only way to turn Open RAN hype into real-world deployments is with thorough, comprehensive testing. But technology as revolutionary as Open RAN demands a revolution in testing. Right now, CSPs and vendors are still grappling with what that transformation entails.
NAVIGATING THE NEW NORMAL
Open RAN will eventually take hold in production networks in some form; the rewards are too great to ignore. Beyond any benefits from vendor competition, Open RAN introduces a degree of architectural and business flexibility that hasn’t existed before. By breaking out base stations into independent components: radio unit, centralized unit, distributed unit and RAN intelligent controller potentially from different vendors, operators gain the freedom to architect access networks in new ways, a key enabler of 5G densification. At the same time, Open RAN lets CSPs position closed-loop control intelligence and even third-party applications right where devices connect, enabling new use cases and revenue models.
At this point, it’s hard to imagine future telecom networks that don’t provide this kind of flexibility. Before we get there, however, CSPs and vendors will need to overcome the many challenges that come with a disaggregated, software-driven RAN. Among the biggest of these challenges is integrating and testing all these newly independent components. The whole premise of an open, plug-and-play RAN is that you should be able to choose functions from different vendors and assemble them into a single, high performing system. That’s a huge change from yesterday’s RAN, where radio technologies came largely pretested and integrated from the vendor. If you’re with a CSP lab team, it’s now your job to patch together this collection of virtualized multivendor software functions into a production-ready infrastructure. That’s a considerable effort. Among other challenges, you’ll need to address:
Many more things to test and model: Open RAN involves many disparate parts and pieces, potentially from different vendors, all interworking seamlessly under high traffic loads in mission-critical enterprise customer environments. And by the way, many of these components and in some cases, vendors, are basically brand-new. It’s now your responsibility to validate their interoperability, performance and conformance with standards. You’ll need a broad range of new instruments and emulators and the ability to test each function in isolation, in tandem with adjacent components and as part of an end-to-end system.
Extreme performance requirements: The ability to support next-generation capabilities like ultra-low latencies will play a central role in enabling new 5G use cases and revenue models. But it also makes the RAN, already the most performance-sensitive part of the network, even more so. To deliver on next-generation services and service-level agreements (SLAs), you will need to assure that every element of every network function performs and interworks as expected, within much tighter latency windows, in a more dynamic and unpredictable environment, under real-world conditions.
Lack of mature tools: While CSPs already have an impressive array of Open RAN technology options, there remains a distinct lack of focused, integrated solutions to effectively test them. Even at the level of methodology, there is still no normalized, industry-wide approach. Test and emulation products that can provide all the necessary capabilities, much less in a way that makes testing simple, repeatable and scalable, don’t yet exist. Instead, Open RAN deployments typically involve test companies dispatching engineers onsite to develop custom test bed solutions. This typically involves a great deal of manual setup, making the process expensive as well as fraught with errors. It’s also only a temporary solution; as you update Open RAN software and hardware, those precisely tuned custom test beds won’t be usable for long.
This is only a partial summary of what’s needed to deploy a production Open RAN system and unfortunately, most existing testing tools can’t help. Even in labs with sophisticated emulation and testing capabilities, most instruments were designed for previous 3GPP specifications. They don’t account for the partitioning mandated by the Open RAN Alliance (O-RAN) specification, or the fact that it breaks traditional interfaces. So even if you limit such tools to piecemeal testing of individual functions, you can’t trust that you are getting an accurate representation of how they will behave in the field.
ADOPTING MODERN SOFTWARE METHODOLOGIES — READY OR NOT
Beyond the need for new testing approaches, virtualizing and opening up the RAN brings far-reaching new operational requirements, particularly around software and change management. In a multivendor Open RAN, you can expect a constant flow of software updates and firmware upgrades at multiple layers, all released on different vendor timelines, far more frequently than in the past. Every time any vendor in the environment pushes out a new release, you’ll need to repeat the whole testing effort of validating capacity, compliance and performance of the new function in isolation, as well as in adjacency testing and across the end-to-end system. Unfortunately, as more vendors enter the picture, the process only gets more complicated.
The only way to contend with so much complexity is with an automation-first approach. That implies a continuous integration/continuous delivery/continuous testing (CI/CD/CT) pipeline spanning the lab, preproduction and ultimately, production environments. CSPs have long discussed such methodologies in preparation for 5G core networks. For the kind of plug-and-play multivendor architecture that Open RAN envisions, however, a CI/CD/CT approach becomes mandatory. It’s the only way to consume, test and deploy software updates in a reasonable time frame and at a manageable cost. Even more important, it’s the only way to be confident that each new combination of functions and software versions in this constantly changing environment is safe to push into production.
DEVELOPING OPEN RAN-READY TESTING AND EMULATION
With so many challenges to overcome, we shouldn’t be surprised that production Open RAN deployments continue to lag. In fact, those making the most progress today are often doing so in baby steps, starting with “partial” Open RAN solutions that use virtualized, standards-compliant components, but all provided by one vendor. For now, this model allows operators to move forward with Open RAN using more deployment-ready solutions, without having to take on a full multivendor integration effort and without having to transition to automated CI/CD/CT software methodologies, yet.
Most CSPs recognize, however, that they can’t put off these changes forever. A viable Open RAN, really, a viable next-generation telecom network, will require continuous testing and integration, whether it’s a plug-and-play architecture or not. Fortunately, we already know what a next-generation approach to testing should look like. Indeed, leading testing providers in this space can now deliver on many of its elements. Emerging Open RAN testing solutions will feature:
Advanced emulation: Lifelike, scalable emulation is essential for effective testing, especially in highly dynamic, disaggregated Open RAN architectures. The industry is developing a new generation of emulation tools designed specifically for these environments. These tools can emulate real-world network conditions for all Open RAN components in isolation, in adjacency testing and as part of end-to-end systems with stringent performance requirements. They can scale up emulated users, applications, data rates and other factors to model real-world network conditions, including unexpected impairments. Such capabilities will benefit vendors as well as CSPs. After all, you can’t develop viable DU solutions, for example, if you can’t emulate all the other pieces of an Open RAN system.
Ease of use: Configuring all the different test instruments and emulators necessary to validate an Open RAN system is not easy and each configuration must be precise and repeatable to avoid problems in regression testing. Trying to accomplish that by patching together point test instruments and disparate emulators is almost impossible. Emerging Open RAN testing solutions will expose a comprehensive set of Open RAN testing and emulation capabilities under a single, common UI.
Automation: Automation might have been aspirational in the past, but it’s a basic requirement for many aspects of Open RAN operations, including testing. By starting with a common UI for all emulation and testing capabilities, new solutions make it possible to automate tasks across the testing lifecycle. They provide a framework to automatically configure instruments and emulators to their precise settings and accelerate time to results. To accommodate constant change in next-generation environments, these tools will also enable engineers to bring up any previously defined test, change parameters and run it again, in minutes instead of hours or days.
“Lab-to-live” scalability: Legacy testing models were designed with the assumption that lab and production environments existed in largely separate worlds, managed by separate teams. In a software-driven network, however, they converge into a single continuum that demands continuous, comprehensive testing. Emerging solutions will be able to scale CI/CD/CT processes across the lab-to-live lifecycle, from test bed to preproduction and, ultimately, production. They will provide a framework where every change or update in the network triggers automatic testing to revalidate interoperability and performance.
Alignment with business requirements: Traditional testing tools tend to focus overwhelmingly on technical parameters. Such tooling will always be important, but too often, legacy test approaches seem largely isolated from business-level concerns. Emerging approaches promise more solution-oriented options, with test and measurement tools that tie directly to business outcomes. Ultimately, you will be able to thoroughly test your Open RAN, in the lab and at scale, at different performance intervals aligned to the specific SLAs and KPIs of your business.
LOOKING AHEAD
Clearly, much work remains to be done and many questions answered before we see mass deployments of Open RAN, whether in single-vendor implementations or full plug-and-play architectures. But we can already draw one important conclusion; RAN architectures can’t evolve in isolation. Testing approaches must evolve right alongside them to make these new architectures and technologies field ready. If you are relying on test and emulation solutions designed for a legacy world, proceed with caution. It’s only with comprehensive data derived from automated testing frameworks, ideally in the proof-of-concept phase, that you can accurately assess the performance and suitability of Open RAN for your business.
The good news is that a new generation of testing solutions is already emerging to help both CSPs and vendors advance Open RAN evolution, with fewer expensive missteps. As more organizations adopt such frameworks, we should expect to see Open RAN deployments accelerate. Operators will find they can transition to new RAN architectures and performance requirements more quickly and cost-effectively. Vendors will be able to promise repeatable results at scale and deliver them. And as an industry, we can all stop hearing about the potential of Open RAN and actually start monetizing it.
References
- “NG-RAN; Architecture Description,” 3GPP, Reference 38.401, Web: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3219.