The O-RAN Radio Unit: where are we today?
Conformance testing of O-RAN Radio Units (O-RU) was the principal focus of testing at PlugFest 2021 where significant progress was made to improve coverage according to the O-RAN standards. We’re also continuing to see collaborations between test vendors and O-RU vendors at exhibitions such as MWC Barcelona 2022 where the acceleration of compliance is enabling seamless integration with other O-RAN components.
The O-RU is one of the disaggregated O-RAN network elements designed to perform the lower physical layer and RF functions. It interfaces with the O-RAN distributed unit (O-DU) over what is known as the standardised O-RAN fronthaul interface. The O-RU performs its operations in real-time, dealing with high sampling rate IQ data. Its smooth running is essential to the performance of the overall system.
Can the much-needed conformance testing ensure that the O-RU operates as expected? And is this form of testing sufficient to significantly remove the pain points down the road?
With so many elements in the O-RU and each with the potential to be provided by a different vendor, we face the following challenges: can the much-needed conformance testing ensure that the O-RU operates as expected? And is this form of testing sufficient to significantly remove the pain points down the road?
Why go through the O-RU test journey?
One of the aims of the O-RAN Alliance is to provide flexibility to operators to pick and choose from different O-RAN vendors’ components. This is to mitigate a lock-in with the very few traditional gNB players which may limit the competitive landscape and potentially lead to expensive gNBs. However, opening up the market to enhance competition with more players gives operators more choice.
While O-RAN provides added flexibility, it also means that the complexity in testing can increase owing to mixing O-RAN components from different vendors. The test journey can reduce or remove potential issues while integrating with other O-RAN network components, while also providing performance and efficiency improvements in testing overall.
A test journey helps to avoid limitations in the performance of the O-RU by allowing, as an example, the maximum throughput under different sub-carrier spacings, bandwidths and carrier aggregation scenarios to be achieved.
Finally, it ensures that not only does the O-RAN fronthaul semantics and syntax work, but that the 3GPP U-plane data is successfully decoded before any form of E2E testing where issues are more difficult to diagnose.
The challenges of testing the O-RU
There are three key challenges to testing the O-RU:
- Validating the timing and synchronisation between an emulated O-DU and O-RU. This is important as the timing ensures that all aspects of the management, control and user planes are synchronised and eliminates the risk of latencies or lost/dropped packets.
- Ensuring inter-operation of the O-DU with different vendor O-RUs, which are all supposed to operate according to the O-RAN standard. This sounds easy and is one of the key goals with Open-RAN architecture, but in practice, it comes with challenges. Different vendor O-RUs may have different delay profiles, different software implementations and a different performance, meaning they may not plug, play and operate correctly.
- Guaranteeing the performance in a multi-vendor scenario: the latency, maximum throughput and handling of certain features, such as beamforming, may not produce the same performance between two different vendors. Due to the flexibility that the O-RAN standard encompasses, testing must address the complexity of using different vendor combinations while expecting consistent results.
All of these challenges point to a real need for conformance testing to ensure that a standard is widely achieved and accepted by all vendors. However, for the most part, conformance testing alone focuses on the semantics and syntax of the open fronthaul interface. Can this ensure that the O-RU can deliver the expected performance when 3GPP features are implemented? Moreover, is it likely that when 3GPP features are implemented, the operation and performance between the O-RU and O-DU or O-DU/O-CU combination will be as expected? One cannot emphatically say yes!
What does the journey in testing the O-RU look like?
We can see the need for a test journey, but what should that journey look like? The following stages of testing are needed to get the best performance of the O-RU. The result will reduce integration issues, bring efficiency gains between the O-RU and O-DU ahead of E2E testing and finally avoid as much as possible a blame culture, where the O-RAN network components are from different vendors and any problems may see blame passed around.
- Conformance testing is a requisite according to the O-RAN standards and must be done to ensure the proper operation of the O-RAN fronthaul interface, the management, synchronisation, control and user planes. Much of the testing is currently in this phase.
- Direct Performance Testing (DPT) is complementary to conformance testing; however, this goes beyond the O-RAN standards to test at the 3GPP level. With DPT, the O-RU is tested with an emulated O-DU over the 3GPP stack. The advantages of doing this are numerous and enable a much smoother integration with a real O-DU ahead of E2E testing.
- E2E performance testing is where the O-RU, O-DU and O-CU are tested in conjunction with a real or emulated core network. One of the aims is to obtain the best performance across all network components. This is a typical type of test that would be performed by a System Integrator or OTIC laboratory.
- Capacity testing: Once E2E performance testing is done, capacity testing would look to scale the numbers of User Equipment devices (UEs), with carriers as an example. This is a more realistic test that would emulate a real deployment. This type of test would ensure the best Quality of Service (QoS) for each user under different mobility and fading conditions.
Benefits of Direct Performance Testing of the O-RUs
DPT is an additional stage of testing the O-RU, but one that is certainly worth the time and effort to ensure that O-RAN deployments deliver in a way that is comparable to traditional approaches, if not significantly improved.
DPT of the O-RU offers a range of benefits. As previously mentioned, It avoids limitations in the performance of the O-RU. Not only this, but it mitigates pre-integration issues with different vendor O-DUs, which can be painful if the O-RUs and O-DUs are from different vendors.
DPT ensures that the 3GPP physical layer data can successfully be decoded before any form of E2E testing where issues are more difficult to diagnose due to the O-RAN vendor diversity. This gives a very early indication of whether some 3GPP features will operate as expected with emulated UEs, deliver a consistent and repeatable decoding of uplink and downlink data in real-time over a selected 5G stack. This is crucial because the real-time element replicates the real-world operation of the O-RU.
Another benefit of DPT is that it significantly reduces the blame culture we wish to avoid, ahead of integration with other O-RAN network components including E2E testing. Jumping straight to E2E testing after conformance testing can be a premature move that stifles productivity, is expensive and makes diagnosis complicated. This is because if there are performance issues with the O-DU or O-CU or both, these can mask issues arising from the O-RU making diagnosis particularly difficult.
Finally, DPT raises the profile of a vendor O-RU if it has been tested beyond conformance testing. This adds confidence to purchasers of O-RUs because it has been validated over the 3GPP 5G stack.
In the real-world
It’s all very well to argue the benefits of DPT in theory, but let’s look more closely at how in three real-world scenarios adding this step is beneficial to all parties in the ecosystem.
- Ahead of an integration with an O-DU, although conformance testing does test the C and U- plane at the O-RAN level, it does not guarantee that more dynamic C and U-plane data can be decoded successfully with different emulated UEs. For example, if the U-plane data packets are different per UE, the behaviour of the O-RU cannot be predictable in successfully decoding download data with the 3GPP stack.
- While conformance testing does verify the latency over the O-RAN fronthaul interface, it’s not known what the maximum performance would be when interconnected with a real O-RU over the 5G stack. Latencies over the O-RAN fronthaul interface can affect the maximum achievable throughput under different MIMO, sub-carrier spacing and bandwidth capabilities.
- It is inconceivable that System integrators and OTIC laboratories would expect an O-RU connected with an O-DU or O-DU/O-CU combination to just work if based only on conformance tests. By doing DPT over the 3GPP 5G stack, this risk is significantly reduced bringing efficiency gains in integrations and reducing the time cost of testing in later stages.
However, conformance testing shouldn’t be replaced or undermined by DPT, on the contrary, it is a complementary step on the testing journey. Conformance testing is critical from an O-RAN standards viewpoint, however, DPT gives very early, and more detailed indications of further challenges vendors can expect, allowing them to be addressed promptly.
While we are seeing signs of some vendors and integrators adopting DPT of the O-RU to get very early indications of whether the O-RU can reliably decode 3GPP 5G downlink and uplink data, we expect to see more as further progress is made to complete the conformance testing. DPT provides a further layer of testing and troubleshooting which helps to identify very early, issues that conformance testing may not identify. The impact of this is to enable improved efficiency and productivity gains as progress is made throughout the test journey. In the end, this allows O-RAN technologies to live up to the promise of adding network flexibility without headaches.
To learn more about testing the O-RAN Radio Unit please visit: TM500 O-RU Tester | VIAVI Solutions Inc.
* Sponsored Article