wireless channel, and the Unified Endpoint Security (UES). This is a start to test the functionality, but it is also important that the emulators are “real” and can scale in terms of performance, such as data rates, number of users, and features. Second, the Open RAN test solutions must be easy to use to accelerate time to results. Open RAN requires multiple instruments and emulators to test each individual piece separately. Configuring multiple test instruments and emulators is not easy and each configuration must be precise and repeatable, or regression testing will be challenging. Where we are today in our Open RAN journey is that much of this set up is manual and fraught with error. Test solutions (not just point test instruments and disparate emulators) that incorporate a common user interface and expose the test capabilities needed for Open RAN testing simplify the task and are largely nonexistent today. Instead, test companies deploy engineers on-site and “custom” develop solutions that are simply not scalable or have a long shelf-life—meaning that these test beds may not be reused for the eventual updates in either software or hardware.

Lastly, the need for automation for Open RAN testing is critical. Automation not only configures the instruments and emulators to the proper settings but also accelerates the time to result in a repeatable manner. The test engineer brings up the test, changes any parameters for a specific test, and then runs the test. It is important to note that a common user interface (UI) provides the framework for an automation overlay and those two important components of an Open RAN test solution work hand in glove—it is difficult to have one without the other.  

Once an automation framework has been established for an Open RAN test bed, it is vitally important that the automation framework has the power to scale from the lab to pre-production and then ultimately to production. In this way, a true CI/CD pipeline can be instantiated to reduce downtime and also expedite updates, which will inevitably occur in a multi-vendor RAN network implementation, reducing downtime and increasing time to revenue.

The bottom line for testing is that it must be comprehensive, continuous, and exhaustive. This makes manual testing a non-starter, and the only viable path is a continuous testing framework automating testing and revalidating interoperability and performance as each change is made.

Can Open RAN deliver on its promises?

Open RAN will happen—there is too much investment and momentum for it not to succeed. Given the current state of the telecom industry, Open RAN is vitally needed. The question is really: at what level? Will the deployments be largely single vendor, or will truly multi-vendor implementations become a reality? Test solutions must evolve not only for the service operators, but also for the ecosystem. The ecosystem of suppliers needs solutions that are easy to use, easy to configure, and can produce repeatable results at scale. Service operators need test solutions that can produce repeatable results and can extend to the “live” network or the production environment in order to fully assure that their multi-vendor solutions deliver on the promise of not only Open RAN, but also of 5G. Service operators and the ecosystem of RAN suppliers must adopt a more software-centric approach with automation, the linchpin to linking the “Lab” to the “Live.” In this way, new capabilities, features, and performance levels can more cost-effectively transition from the common lab experiment to something that service operators can actually monetize.    

Fools rush in where angels fear to tread

By no means are we “dissing” Open RAN. By all means it has the potential to usher in new use cases and innovation while lowering costs. Crucial questions remain, however, many of which can be answered through comprehensive testing, particularly across the proof-of-concept phase. Their answers will provide the necessary insight for accurately assessing performance and business model suitability as Open RAN transitions from the drawing board to operational reality.

This will be determined by testing the components of Open RAN’s multi-vendor plug-and-play architecture, their interoperability, and their end-to-end performance in the live network. If we achieve positive results matching the sales and marketing claims, not only might we avoid cusswords from the technical team, but Open RAN may well also deliver the benefits expected by network operators and their customers.