O-RAN Is Redefining How Radio Is Tested: A Technical Deep Dive


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. Learn more about some essential test areas for a comprehensive performance evaluation.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Learn more about Open RAN testing solutions右箭头图标




标签5G, 移动网络
Anil Kollipara
Anil Kollipara


Anil Kollipara是思博伦网络生命周期测试和服务质量保障业务部的产品管理高级总监,负责5G与Open RAN测试与保障产品组合的战略制订和执行。他在无线与电信行业拥有广泛的背景,并且在为实验室测试、服务保证和网络规划领域构建行业领先产品等方面成就斐然。其专业领域包括无线网络(3G、LTE、5G、Open RAN、VoLTE、VoWi-Fi)中的测试与测量、服务保障以及预测与规范分析。在加入思博伦之前,Anil曾在Netscout、Danaher、Dell和Cerion等顶尖企业工作。他拥有印度孟买大学的学士学位、美国德克萨斯大学阿灵顿分校的电子工程硕士学位及芝加哥大学布斯商学院的工商管理硕士学位。Anil拥有四项与表征和测量电信网络用户体验相关的专利。