中文
Open RAN (O-RAN) doesn’t just bring a completely different technical approach to RAN deployments – it is also transforming decision-making and buying behavior. This new pursuit sees operators globally each chasing specific efficiencies, performance, and capabilities. Still, only 36% believe O-RAN is mature enough for scale deployments in overall system performance, according to Heavy Reading. The rest will need to be convinced otherwise.
Whether gearing up for rollouts or waiting eagerly to see if O-RAN can deliver on its promise, the path forward will be defined by the testing and validation work currently under way. Only then will the O-RAN solutions be ready for deployment and their full potential realized.
This testing is set to throw yet another curveball at operators. Whereas one RAN box was previously tested as a whole, testing processes must now be broken down at the radio unit (RU), distributed unit (DU) and centralized unit (CU) levels. They must also be tested comprehensively, in an array of configurations, with a mix of hyper-realistic and emulated traffic.
In a previous post about O-RAN testing strategies, we walked through the high-level, multi-step O-RAN testing process. In this post, we’ll go deeper on the technical front. Industry standards and guidelines are a starting place, but our conversations with customers have truly revealed the stringent level of testing support that will be required for success – and the much-needed confidence to move ahead.
As we’ve covered before, operators will need to conduct isolation testing of each component, followed by adjacency testing where pairs of the components are tested together, then finally full, end-to-end testing. Throughout, test and validation will be done for compliance and conformance (which is critical for inter-operability in a multi-vendor environment), understanding of performance under certain load conditions, behavior in a range of scenarios, ability to support specified traffic volumes, impact on deployment in different 5G bands, and more.
Breaking down test requirements for O-RAN
Four key test areas within the O-RAN framework that are essential for achieving a comprehensive performance evaluation are:
Open Radio Unit (O-RU) Testing: The O-RU transmits and receives radio frequency signals and performs amplification and digitization. The O-RU is located near the antenna or integrated into it. Wrap-around testing of the O-RU is critical to ensure interoperability in multi-vendor environments. The O-RU needs to be validated for its 7-2x split conformance, performance, adversarial scenarios, mobility, and end-to-end functional tests. These aspects need to be tested across a myriad of frequencies, bandwidths, and capabilities such as TDD/FDD, MIMO, and carrier aggregation. An O-RU needs to be validated for its performance under various real-world channel conditions including impairments. In addition, sensitivity and dynamic range in multi-users scenarios must be tested, as it will directly impact cell coverage range and total capacity of the cell.
Open Distributed Unit (O-DU) Testing: The O-DU performs the real-time baseband processing functions and contains the lower layers of the protocol stack (high physical layer, MAC, and RLC). The O-DU connects to the O-RU over the 7-2x interface, to the O-CU over the F1 interface, and to the non-real-time and near-real-time RIC over the O1 and E2 interfaces respectively. An O-DU can be located near the cell site or at the edge. An O-DU can be virtualized or containerized and run on commercial off-the-shelf (COTS) hardware. An O-DU needs to be tested for its interoperability with the O-RU and O-CU, scale, capacity, performance, throughput, and various mobility scenarios. In addition, an O-DU needs to be validated for various applications and services like VoNR, video over NR, data, and emergency services.
Open Central Unit (O-CU) Testing: The O-CU handles the higher layers of the protocol stack like SDAP, RRC, and PDCP, which require less time-sensitive packet processing. The O-CU connects to O-DU over the F1 interface and the core network over N2/N3 interfaces. The O-CU also connects to other O-CUs over the Xn interface or eNodeBs over the X2 interface for mobility. An O-CU can be virtualized or containerized and run on commercial off-the-shelf (COTS) hardware. An O-CU needs to be tested for interoperability with the O-DU and core network. An O-CU can support thousands of O-DUs and hundreds of thousands of UEs, and hence needs to be validated for high scale, performance, capacity, and throughput.
RAN Intelligent Controller (RIC) Testing: A RIC hosts software applications that provide RAN orchestration, optimization, and automation. A RIC supports both non-real-time (non-RT) or near-real-time (near-RT) platforms. The near-RT RIC needs to be tested for interoperability with the O-CU and O-DU over E2 interface and various xApps providing features like optimization, per UE load balancing, mobility management, QoS management, edge services, interference management, and radio resource management. The non-RT RIC needs to be tested for interoperability with the O-CU and O-DU over the O1 interface and non-real-time functions such as health checking, alarms, fault management, performance management, and lifecycle management.
Test and assurance is critical for an open ecosystem
It cannot be overstated how important it is to be able to test each O-RAN component individually and in a range of environments, from cloud-native infrastructure to simple COTS hardware. Yes, this means loads of complexity and cycles. Operators will need to be able to pinpoint exactly where problems are lurking. They’ll need to know for sure that these new components deployed in new environments will deliver as intended.
This is where the importance of end-to-end O-RAN testing comes into play. This has been a significant area of investment and advancement on the innovation front.
It will be possible for operators to emulate every component of new networks in any configuration. They’ll be able to test with real-world applications and servers via one-arm and two-arm configurations, capturing QoE metrics along the way. And once this testing starts, it will never stop. Continuous, automated testing will ensure that software updates, emerging security vulnerabilities, new applications, or any other number of current unknowns do not wreak havoc in the live network.
The good news is that we’re early in the O-RAN testing cycle. But don’t delay. Many in the industry predict we’re somewhere between one and three years away from multi-vendor maturity. Now is the time to put a testing plan of action in place because once this market really starts moving, it’s going to progress quickly.
