Asic designers tackle the O-RAN challenge
Author: EIS Release Date: Oct 26, 2022
O-RAN is a major disruptor for the communications industry and one in which pre-silicon validation is essential, says Dylan McGrath of Keysight Technologies.
The wireless communications industry is moving rapidly from closed, proprietary radio access networks (RANs) to a disaggregated open RAN (O-RAN) that breaks the traditional hardware-centric RAN into several sections (radios, hardware and virtualised functions) using open interfaces based on standards defined by the O-RAN Alliance.
O-RAN represents a major disruption in the wireless industry, enabling mobile network operators to build RANs with a multi-vendor and autonomous supply ecosystem. O-RAN also enables the virtualisation of network functions, which leads to a shorter time to market for new services and functions. It enables network equipment manufacturers to concentrate on specific RAN building blocks, rather than the entire thing.
While this disruption creates exciting opportunities for mobile network operators, network equipment manufacturers and the wireless ecosystem, the shorter time to market creates challenges for chip designers of O-RAN radio unit (O-RU) and distributed unit (O-DU) asics. Shorter design cycles heighten the need to test and validate designs in the pre-silicon stage, because it is here that changes can be implemented more easily and cost-effectively than at the post-silicon validation and debug stage.
Anatomy of the O-RU
In the O-RAN Alliance’s O-RAN architecture, a RAN is disaggregated into the O-DU, O-RU and the O-RAN central unit (O-CU). The architecture defines an F1 interface between the O-CU and the O-DU following one of the two 5G New Radio (5G-NR) split architectures defined by the Third Generation Partnership Project (3GPP), with the front haul interface between the O-DU and the O-RU to follow 3GPP split option 7.2x. These interfaces, defined by the O-RAN Alliance, have been specifically created to avoid the development of proprietary interfaces and enable true multi-vendor interoperability in RAN network design and architecture based on open Ethernet.
In split option 7.2x, the front haul interface transports the quadrature (IQ) samples in the frequency domain. Only the data sub-carriers with user data are transmitted between the O-DU and O-RU over the O-RAN front haul. The functions of the physical layer (PHY) are distributed between the O-DU and the O-RU, therefore the O-RU incorporates a digital front end to handle the low PHY layer (L-PHY) functions (Figure 1).
The O-RU is responsible for lower L-PHY processing as well as the RF interface. The O-RAN model adds signal processing functions on the digital part of the O-RU. The digital part consists of three subsystems: an Ethernet interface; an enhanced common public radio interface/O-RAN layer subsystem to handle the O-RAN control plan messages; and the digital front end performing the IQ signal processing functions.
O-RAN does not have an impact on the architecture of the analogue part of the O-RU. The uplink and downlink RF signal paths and the main function remain the same: digital-to-analogue/analogue-to-digital conversion, analogue up- and down-conversion, analogue beamforming and the front end of the radio transmitter and receiver.
O-RAN front haul protocol
The O-RAN front haul protocol layer sits on top and uses Ethernet as the transport layer. The O-RAN Alliance front haul working group (WG4) specifies and describes in detail the four protocol planes used in the front haul interface. These are the management plane (M-plane), synchronisation plane (S-plane), control plane (C-plane) and user plane (U-plane).
The O-RAN WG4 conformance test specification covers a variety of tests for each of the plane protocols. Conformance tests are generally defined to test one element of the specification at a time with minimum stress on the O-RAN front haul of the O-RU under test, maximising repeatability. Tests cover all the functionalities described in the specification, but not all tests are applicable to all O-RU designs.
Testing the full functionality of an O-RU design requires building complex test cases, because conformance tests focus on one parameter at a time and do not characterise the full functionality and performance of the O-RU. Creating complex test cases requires consideration of multiple parameters, including the number of data flows, the number of Ethernet ports, different O-RAN features and messaging models combinations, the need for 5G-NR and long-term evolution (LTE) interoperability or co-existence, and the relevance of testing simultaneous uplink and downlink transmissions.
Design and test challenges
O-RAN’s standardised front haul interfaces and L-PHY functions enable the development of O-RU asics that provide Ethernet connectivity and transport, O-RAN protocol support, IQ processing functions and interfaces to the DACs.
Keeping up with shortened design cycles and ensuring O-RU asic designs follow O-RAN front haul standards require well-planned, complex test cases in pre-silicon validation. To accelerate the design process, it is particularly important to test the design to the extent of its capabilities at the pre-silicon stage.
Testing an O-RU chip design at full scale requires simulating complex scenarios that cover as many corner cases as possible by sending realistic traffic in conformance with current specifications at the right time over the right interfaces. An O-RU chip design spans from Ethernet ports to interfaces carrying time-domain 5G/LTE signals, therefore it is vital to provide cross-domain support and send traffic from both sides to test how the design reacts to uplink and downlink scenarios, and check decompression, pre-coding, beamforming and cyclical prefix addition functions as well as downlink or uplink buffers.
The pre-silicon test process involves several complicated tasks, such as building signals that conform to the industry standards, simulating traffic on a multitude of carriers and antennas at different frequencies and sample rates, and ensuring parameters comply with the latest 5G specifications. Silicon emulation platforms that can be combined with O-RAN test environments can maximise chipset validation before tape-out.
To facilitate validation of both uplink and downlink operations, an O-RU test environment can simultaneously exercise the chipset with O-RAN traffic stimulus on one end and digitised time-domain 5G or LTE waveforms on the other end. Since time domain IQ interfaces are not standardised, the digitised 5G or LTE time-domain signals need to be transmitted to the device under test by encapsulating them into Ethernet frames.
Once the desired O-RAN traffic flow is ready, the next step is to push the traffic into an emulator loaded with the O-RU chip design. This can be accomplished by sending the C-plane and U-plane in separate stimulus files in synchronisation through a set of protocol specific transaction-based verification sets known as transactors. These transactors enable the rapid creation of system-level test environments for specific designs in the hardware emulator. Transactors include synthesisable bus functional models that are loaded into the emulator, ensuring that the transactor is always synchronised to the emulated design. Each transactor also includes C/C++ APIs (application programming interfaces) to quickly create test benches and drivers to generate real-world traffic and to link to virtual platforms.
Most common pre-silicon test solutions use existing Ethernet transactors that are configured to transmit the stimulus files with no native way of synchronising the C- and U-plane. The synchronisation is calibrated through an elaborate process that is prone to errors. It takes time and resources to ensure that all steps are successfully executed, and the traffic returned by the design is manually captured on all the interfaces, providing no overall visibility on how the traffic flows.
Uplink test scenarios require IQ modulation quality measurements, and the raw digital IQ data returned for uplink scenarios is hard to analyse and validate.
Low-level API commands can help facilitate automated tests by orchestrating the whole process. These commands, however, cannot be natively linked to proprietary tools or tools from different vendors.
Once the traffic is properly prepared, it is possible to use non-native 5G tools to view the signal conformance and strength. This approach is time consuming, however, and focuses on the signal rather than the whole information flow, preventing the discovery of correlation issues and yielding questionable results.
Virtualised solutions for testing O-RAN chipsets do exist. They feature multiple interfaces connecting to the hardware emulator through dedicated Ethernet. These interfaces can be configured for 10G or 25G line speed and support independent traffic (sending and capturing) with options to split the radio-over-Ethernet traffic over more interfaces.
Productive test tools should enable thorough test of designs prior to tape-out and allow developers to emulate designs with O-RAN protocol messages that contain valid 5G NR and LTE waveforms. They should also allow the protocol domain to be linked with the RF domain for analysis.