Skip navigation
Like what you’re reading?

How automated testing can help address the Open RAN deployment challenges

Strategic Product Manager, Life Cycle Services, Service Area Networks

Automated testing enables Open RAN deployment

Strategic Product Manager, Life Cycle Services, Service Area Networks

Strategic Product Manager, Life Cycle Services, Service Area Networks

Contributor (+1)

The major attractions of Open RAN are the possibilities of cloudification, intelligent automation and open interfaces. This freedom of choice also bring some challenges, especially when it comes to design, integrate, test, deploy, support, life cycle manage and operate a multivendor RAN. The challenges origin mainly from the new software architecture, openness and multivendor solutions. Automated testing is important to ensure smooth interoperability and are among the key enablers to secure efficiency, streamlined, and agile ways of working.

Open RAN deployment challenges can be divided into three main categories

In the previous blog “How pre-staging can help address the Open RAN deployment challenges”, we talked about the importance of pre-staging solutions. The Ericsson pre-staging solution reduces the risk and complexity by taking disaggregated Open RAN deployment as close as possible to ‘first time right’, giving Communication Service Providers (CSPs) and field crews the confidence that they can complete this otherwise complex and time-consuming challenge. 

Once the Open RAN is deployed and carries live traffic, we enter the multivendor life cycle management challenge. This is when the multivendor infrastructure products need to be updated & upgraded with new software and patches. Automated testing is a continuous work during the whole life cycle of the networks. This requires CSP solution to have release planning, integration & validation before the actual SW upgrade on site.

Open RAN automated testing - now more essential than ever

Ensuring robust interoperability among network components is important, and Open RAN multi-vendor deployments require solution validation to ensure optimized and high-performing networks. Due to the openness principle, addressing security concerns in a multi-supplier environment demands rigorous security controls and verification. 

As they are often provided by different suppliers, each network element in the Open RAN architecture has a standalone life-cycle management roadmap, making interoperability between vendors an underlying challenge. For that reason, it is crucial for CSPs to consider a holistic end-to-end (E2E) evaluation of the upgrade patches in their lab to validate the solution.

Cloudification is another key element of the Open RAN, as it opens up the introduction of microservice design to the networks.  It also demands more frequent upgrades, and as a result an increased testing and verification cadence.

CSPs and their technology vendors spend a lot of time and resources validating new releases of software in lab prior to applying a new feature to their networks. CSPs have rigorous procedures to take them through different scopes of testing, all to ensure that new versions do no harm before rolling them out in the live network. Consequently, this cumbersome testing and verification process need to be transformed and automated, so it does not hinder CSPs from rolling out new features and security patches in a cadence they need.

CSPs are increasingly transforming their networks toward cloud-native and disaggregated architectures, which demand more sophisticated and advanced scenarios for validation. An increase in testing cycles is an almost inevitable consequence of this diversification and openness.

The telco industry is still on a journey of transformation as it tries to effectively leverage agility, DevOps and continuous software delivery. Continuous Integration/Continuous Deployment (CI/CD) is the most reliable way to streamline and automate the process and improve workflow. DevOps and CI/CD transformation efforts are among the primary drivers when introducing automated testing, and a very promising market is emerging due to this transformation.

Operations Automation Technology
DevOps, Agile, System integration, Life cycle management Automation plays a vital role in curbing the complexity. Cloudification, Open interfaces, Network programmability and AI management.

Fig: Open RAN Dynamics

Open RAN Automated Testing - Operational Requirements

As already established, Open RAN requirements have a huge impact on testing, and this can prolong lab and verification activities. New releases from suppliers need to be continuously delivered, integrated, verified, validated, and deployed, and all of this has a major impact on operations and life-cycle management on all layers of the architecture stack. Open RAN is not only about the new technology itself - it is also to a great extent related to new ways of working and developing new skill sets and processes.

DevOps, and in particular CI/CD services, will help to achieve higher service agility in the software life cycle and ensure efficient ways of working. CSPs should ensure they have a robust pipeline of CI/CD software processes in place, as well as streamlined procedures for continuous integration, testing, and commercial deployments of new microservices to ensure unforeseen conflicts do not arise.

Fig: Key factors impacting testing in Open RAN

Fig: Key factors impacting testing in Open RAN

Open RAN Automated Testing – Automation requirements

The move toward cloud-native network functions allows microservices-level patches to be introduced more quickly, and this will require more agile testing to verify software changes. Manual testing consumes more resources and time, and validation requirements and test combinations that must be addressed are increasing.

In an Open RAN ecosystem, automation plays a significant role in the operator journey toward cloud-native, becoming a strategic priority for an efficient adoption of a cloud-native architecture.

Automated testing is a strategic move, and a game-changer for CSPs toward a more efficient lab verification process. Open RAN testing is more efficient if it includes a high degree of automated testing. Automated testing also improves testing lead-times dramatically, giving CSPs the confidence to plan for the roll-out of new versions more often.

The only viable path for a successful and sustainable Open RAN journey is a continuous framework that includes multi-vendor testing and end-to-end testing after software delivery from each vendor. The ecosystem needs to centralize the activities and ensure that the testing scope of the CSP’s lab is kept optimized.

Fig: Continuous automated testing added value.

Fig: Continuous automated testing added value.

Faster, more frequent releases

The ecosystem shift to RAN technology, driven by cloud-based architecture, leads to a more dynamic environment, and cloud-native RAN architecture disaggregate RAN functions from the underlying hardware with a layered architecture. Components are built from microservices that each have their own independent life cycle. Thus, the demand for an E2E solution validation cycle and workload is increasing in Open RAN when compared to Integrated RAN delivered by single vendor. However, the concept of pre-integrated Open RAN /Cloud RAN solutions is the best bet out there, and more and more CSPs are going down this path to lower the E2E solution validation cycle and workload.

Open RAN provides greater flexibility, but it also adds complexity. Instead of one software release every few months by a single RAN vendor, in Open RAN each vendor has many releases, all on different cadences. CSPs need to keep track of the software life-cycle management of each vendor independently, and that increases the demands on the software testing cycle and solution validations even more.

The illustartion below is comparing the Open RAN vision with mix and match compared to purpuse built RAN (Integrated RAN). The trend on the market is to go for the concept of pre-integrated Open RAN/Cloud RAN solutions as we mentioned above.

Fig: Independent multi-vendor release lifecycle

Fig: Independent multi-vendor release lifecycle

Open RAN testing criteria and methodology

Open RAN testing has three main pillars: conformance, interoperability, and end-to-end testing. Each pillar represents a set of testing scenarios and methodologies to ensure the Open RAN products deliver on specification as single units and in combination with other components.

Depending on the CSP’s strategy for how they are going to build their Open RAN network, all or part of the testing use cases have to be conducted in the CSP’s lab to ensure multi-vendor interoperability. Regardless of how many vendors are involved, the final solution must be validated so that Open RAN pieces work together as an integrated system.

Ahead of CSP lab trials, each vendor will test their products in internal integration and verification to ensure they conform to specifications. Once the product passes the conformance test, interoperability tests need to be conducted between vendors – for example O-RU from one vendor and O-DU from another. In this case, the interoperability and performance of the products that are combined into a system must be tested for the CSPs’ unique deployment scenarios.

Lastly, end-to-end testing provides confidence for CSPs, but continuous testing is the key to ensuring the system continues to deliver the best possible performance.

Fig: Open RAN testing scenarios
eyJjb29yZGluYXRlcyI6eyJsZWZ0IjozNy43MywidG9wIjoxMS4wNX0sImRlZmluaXRpb25zIjp7InRpdGxlIjoiQ29uZm9ybWFuY2UgdGVzdGluZyIsIm1lc3NhZ2UiOiI8dWw+PGxpPkZyb250IEhhdWwgY29uZm9ybWFuY2UsIENVLXBsYW5lLCBNLXBsYW5lLCBTLXBsYW5lPC9saT48bGk+Ty1DbG91ZCBDb25mb3JtYW5jZSwgTm90aWZpY2F0aW9uIEFQSSwgQUFMLCBPMjwvbGk+PC91bD4iLCJsaW5rIjoiIiwiY29sb3IiOiJXaGl0ZSIsIm1lZGlhSHRtbE1hcmt1cHMiOltdLCJvcmdhbml6YXRpb24iOltdLCJhbHRUZXh0IjoiQ29uZm9ybWFuY2UgdGVzdGluZyIsInZpZGVvRGF0YSI6bnVsbH0sInJlYWRhYmxlVHlwZSI6InBvaW50In0=
eyJjb29yZGluYXRlcyI6eyJsZWZ0Ijo1MC45MywidG9wIjo5MS45OH0sImRlZmluaXRpb25zIjp7InRpdGxlIjoiSW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIChJb1QpIiwibWVzc2FnZSI6Ijx1bD48bGk+T3BlbiBGcm9udGhhdWwgSW9ULCBDVS1wbGFuZSwgTS1wbGFuZSwgcy1wbGFuZTwvbGk+PGxpPlN0YWNrIElvVDwvbGk+PGxpPk8tQ2xvdWQgSW9UPC9saT48L3VsPiIsImxpbmsiOiIiLCJjb2xvciI6IkJsYWNrIiwibWVkaWFIdG1sTWFya3VwcyI6W10sIm9yZ2FuaXphdGlvbiI6W10sImFsdFRleHQiOiJJbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgKElvVCkiLCJ2aWRlb0RhdGEiOm51bGx9LCJyZWFkYWJsZVR5cGUiOiJwb2ludCJ9
eyJjb29yZGluYXRlcyI6eyJsZWZ0Ijo3Mi43MywidG9wIjoxOC42M30sImRlZmluaXRpb25zIjp7InRpdGxlIjoiRW5kIHRvIGVuZCB0ZXN0aW5nIiwibWVzc2FnZSI6Ijx1bD48bGk+RnVuY3Rpb25hbDwvbGk+PGxpPlBlcmZvcm1hbmNlPC9saT48bGk+TG9hZCBhbmQgc3RyZXNzPC9saT48bGk+U2VjdXJpdHk8L2xpPjxsaT5TdGFiaWxpdHk8L2xpPjxsaT5Sb2J1c3RuZXNzPC9saT48bGk+RW5lcmd5IEVmZmljaWVuY3k8L2xpPjxsaT5SdXNlIENhc2VzPC9saT48L3VsPiIsImxpbmsiOiIiLCJjb2xvciI6IkJsYWNrIiwibWVkaWFIdG1sTWFya3VwcyI6W10sIm9yZ2FuaXphdGlvbiI6W10sImFsdFRleHQiOiJFbmQgdG8gZW5kIHRlc3RpbmciLCJ2aWRlb0RhdGEiOm51bGx9LCJyZWFkYWJsZVR5cGUiOiJwb2ludCJ9

Fig: Open RAN testing scenarios.

End-to-end testing: In Open RAN testing scenarios, end-to-end testing is most critical where the whole O-RAN system is System Under Test (SUT) and can be perceived as an integrated black box. End-to-end network testing should be performed regularly as part of the testing routine in the lab environment before the software is deployed.

The end-to-end test environment is a subset of O-RU (Open-Radio Unit), O-DU (Open-Distributed Unit), O-CU (Open Centralized Unit), and RAN Intelligent Controller (RIC), with control functions linked to RF channel emulator, real or simulated UE (User Equipment) and core network endpoints. There are many end-to-end use cases for testing, including performance, load and stress, security, etc.

For example, Open RAN increases security risks due to the multi-vendor environment. Open interfaces lead to more points of entry and therefore make interfaces more prone to attacks and security breaches. End-to-end security should be tested by emulating different types of attacks to ensure each network function has enough protection.

Open RAN Fronthaul Interoperability Testing: Open RAN demands a long list of requirements on O-DU and O-RU interoperability of different vendors. Defining the standard test configuration, IOT profiles and interoperability test cases is key to reducing overall costs and resources and coordinating efforts between vendors.

O-RU and O-DU integration from different vendors is a complex project. Interoperability involves testing the fronthaul interface in terms of M-Plane, S-Plane, C-Plane and U-Plane, independently or establishing calls to test across multiple planes. This requires system-level testing to validate the interoperability of O-DU and O-RU of the same or different vendors as an integrated system.

Simultaneously, it is neither economical nor efficient to test every vendor with every other vendor and in every scenario. This is highly dependent on CSPs where they will choose a certain vendor as RAN software (O-DU/O-CU) supplier and another as Radio (O-RU) supplier. Therefore, the testing scenario should be tailor-made for the CSP’s custom solution and network topology.

O-Cloud Interoperability Testing: Interoperability testing can be comprised of different components. System Under Test (SUT) for O-Cloud IOT refers to O-Cloud Platform, namely CaaS (Container as a Service), O-DU or O-CU, non-real time RIC and all interfaces defined in between.

The purpose of O-Cloud interoperability testing is to ensure that the cloud platform integrates with RAN CNF (Cloud Native Function) and ORAN defined interfaces/APIs, and synchronization interfaces that it’s able to deliver with no compromise in 5G network performance.

User experience field automated testing

After validation of new software upgrades in CSP’s lab, operators take a decision to roll out new network features into the larger live network, taking next step to introduce new technology in the FOA (First Office Application) or CD (Continuous Deployment) zone, as it has been called.

What actually matters after all the lab validation testing is the performance of networks. In the field, the complete Open RAN system performance needs to be verified and analyzed. That includes a handful of cell site performance measurements, KPI monitoring, optimization, and benchmarking.

To efficiently verify Open RAN performance, field test equipment must be able to conduct the testing over the air interface. This would be a limited number of lab testing scenarios duplicated for the field, with focus on regression testing to ensure network performance is at its utmost after the new software upgrade. This will give CSPs the opportunity to evaluate the software quality in a small-scale but real live network before the mass roll-out decision.

The importance of choosing the right test service provider

With so many testing service providers in the market, it’s important to choose the right test automation partner as it will have great impact on the CSP experience of adopting Open RAN. Particularly in the early years of Open RAN introduction, while the multi-vendor setup still has a long way to reach a certain level of maturity, a reliable service provider is a key to success.

Trusted partners that provide automated testing environments make it possible for collaboration among vendors to solve issues more quickly and speeding up deployment.

RAN expertise and experiences: Although there are many systems integration (SI) and test automation companies that can provide integration and testing services, RAN vendors are more competitive in the Open RAN testing scenario. RAN vendors are major vendors in CSP networks and by having RAN expertise, CSPs have more trust in RAN vendors to run multi-vendor lab validation.

Automation and agility: A multi-vendor Open RAN brings a huge number of validation scenarios with a high frequency of new software releases. Not only should the test execution be automated to continuously boost efficiency, it also should be integrated with an orchestrated pipeline to streamline all testing activities.

Auto-generation of all documents from test planning, execution, and summary reporting in the dashboard with a zero-touch approach is essential to get maximum benefit from this automation.

Testing as a service model: It’s important to have an end-to-end testing service strategy with an agile service delivery process throughout the whole life-cycle management. Among others a service model will contribute to:

  • Centralizing key processes and optimizing the end-to-end lifecycle of the service.
  • Improving accessibility and team collaboration.
  • Reusing global assets such as global test cases to create synergy to have efficient solution.
  • One-stop-shop testing service to avoid underlying complexity.

To truly embrace the power and versatility of Open RAN, CSPs need to automate as much of their software testing as possible; once this is up and running, software can be updated smoothly and regularly, making the most of the investments in hardware and software.

Read more

The future of RAN services

How pre-staging can help address the Open RAN deployment challenges

Open RAN

The Ericsson Blog

Like what you’re reading? Please sign up for email updates on your favorite topics.

Subscribe now

At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.