Of late, open radio access network (O-RAN) has emerged as a buzzword in the global telecom domain. Telecom operators across the globe are warming up to the idea of building O-RANs that are programmable, agile and flexible to facilitate innovative use cases. O-RAN builds on the foundation laid by 3GPP and includes new functions and open, interoperable interfaces. Unlike traditional RAN, O-RAN decouples hardware and software, thus giving operators more flexibility to deploy and upgrade their network architecture. Decoupling the hardware and software functions reduces the time-to-market, making it quicker to deploy open networks as compared to traditional ones.

While Open RAN has several benefits, there are also certain risks in its deployment, which cannot be undermined. Mo­re­over, owing to the interoperability feature of Open RAN, testing of these networks is also riddled with challenges. Th­us, as the industry evolves towards O-RAN networks, it is important that a risk-based approach, along with efficient testing stra­tegies, is adopted in order to adequately address the security concerns regarding this new technology.

A look at the security and testing challenges faced while working with open networks…

Security concerns with O-RAN and means to mitigate them

Virtualisation and cloud platforms have the potential to utilise hardware resources better between different applications. How­ever, they may also introduce security risks. In fact, recently discovered vulnerabilities such as Meltdown and Spectre re­ve­al that there could be increased security risks in sharing of hardware resources.

Industry analysts have highlighted that O-RAN can be implemented as a multivendor network, and each one of the applications can come from a different vendor. This sourcing of applications from multiple places creates a situation, where each application exposes the application programming interface (API) to the services it provides, raising potential security risks.

Further, it has been pointed out that since O-RAN network deployment would be heterogeneous, some apps would reside on cell sites, others in an operator’s private cloud and some outside the operator’s private cloud, for example, on an HCPcloud. Analysts note that this deployment strategy replaces the prevailing security model, in which the operator RAN is secured via a security perimeter. Such a deployment strategy assumes a zero-trust network.

According to Ericsson, in the case of virtualisation and cloud environments, there are many layers that need to be con­si­dered to ensure that the trust chain is maintained between applications and the underlying hardware. The authentication process is the base for establishing a secure communication channel, but it must trust the layers underneath to attest that the node, layer or data set has not been compromised. Further, as there are different layers between the hardware, its security functions and the application, there is a need for standardised interfaces and APIs to use the hardware security functions and allow them to attest to and validate the layers above.

How to mitigate the security risks

Keeping in view the security threat posed by O-RAN deployments, it is important to implement key best practices in any complex multivendor environment. This en­ab­les vendors and network providers to minimise the exponential impact of certain th­reats and quickly respond if new vulnerabilities are found.

Secure O-RAN systems may require additional security measures, a trusted stack for software and hardware, and interoperability between vendors with a common understanding. Also, secure network operations are essential for any implementation, with top priority given to protecting the confidentiality, integrity and availability of customer data.

To establish a secure and trusted communication channel (confidentiality and in­­­tegrity protected) between two end-po­ints, it is imperative to first authenticate each side. For this, a unique identifier and one or more credentials that are kept sec­ret are needed. To protect the credentials in a computer environment, hardware security functionalities such as a trusted platform module, a hardware security mo­dule and secure enclaves are used to establish a hardware root of trust.

The concerns arising from multiple sources of applications can perhaps be addressed by making sure that each app is secured from the network and from other apps. In this architecture, security will be built into each telco app, which will be responsible for its own security.

Challenges in the open networking testing ecosystem

Prior to deploying a cloud network or infrastructure, carrying out test and trials in a lab is beneficial for operators as it all­ows them to test networks that are still in the development phase. Network testing helps operators to ensure that networks will be highly optimised upon deployment, thus minimising risks and potential lo­ss­es. This is particularly im­por­tant for smaller operators in early sta­ges of network deployment.

Industry experts have highlighted that given the amount of test cases operators and network equipment manufacturers need to go through, the amount of testing re­quired is much greater with O-RAN. With more combinations of vendors, the cy­cle time for testing every software re­le­a­se, every regression, and implementing testing automation increases dramatically.

Interoperability testing is necessary for all O-RAN components. According to EDN Research, among all components, di­gital units (DUs) present the maximum challenges. For instance, management plane (M-plane) implementation can cause issues because the DU expects certain parameters when the M-plane is implemented and stops working if these conditions are not met. This can be a significant challenge because the YANG models that help manage the radio units feature more than 6,000 parameters, with less than 3 per cent of them mandatory. In addition, network vendors implement custom protocols. Further, as per EDN, owing to the flexibility of the O-RAN specification for the bring-up se­q­uence, some DUs skip the get-schema pro­cess or stop working if the radio unit (RU) behaviour is different from their expectations. DUs can also stop operating if certain protocol options are mi­ssing. For example, some DUs stop operating if the dynamic host configuration protocol options are not exactly what they had expected.

EDN also noted that the O-RAN spe­cifications include many implementations for the control plane (C-plane) and the user plane (U-plane), and the mapping of the­se planes changes depending on the type of RU. The variety of protocol implementations creates a significant challenge from a testing standpoint. Apart from this, validating fronthaul timing is critical.

Overcoming interoperability testing challenges

The O-RAN movement is gaining mo­me­ntum. Companies building equipment based on O-RAN standards are facilitating rapid improvements in the specification. The greater flexibility brought in by O-RAN also represents a paradigm shift for mobile network operators that now need to put the various network elements to­gether. Ensuring that the components so­ur­ced from different vendors work together seamlessly has become a top priority. In­teroperability testing can be challenging, especially for the DU, due to high flexibility in protocol implementations and the need for tight synchronisation with the RU. Testing solutions that provide broad capabilities to cover RUs from different vendors are critical to succeed at O-DU interoperability testing.

Access to the latest testing tools and re­­sources throughout the life cycle of an O-RAN network can help operators en­sure that network performance issues are identified and resolved quickly to meet their KPI goals. These include tests for functionality, performance, reliability and resilience; subsystem wraparound tests; system-level tests; protocol compliance for open interfaces and protocols; and performance monitoring of open interfaces and protocols to ensure optimum operation.