Introduction to O-RAN

O-RAN’s concepts and architectures use a split-RAN concept. There are eight known ways to functionally split the RAN; each one proposes splitting the processing so that different parts of the protocol stack process on different hardware. Figure 2 summarizes the eight options.

^{Figure 2: RAN Split Options (Source: NGNM 2018).}

As shown in Figure 2, O-RAN uses option 7-2, which splits the physical layer (PHY) into a high-PHY and a low-PHY. For option 7-2, the uplink (UL), CP removal, fast Fourier transform (FFT), digital beamforming (if applicable), and prefiltering (for physical random access channel [PRACH] only) functions all occur in the RU. The rest of the PHY is processed in the DU. For the downlink (DL), the inverse FFT (iFFT), CP addition, precoding functions, and digital beamforming (if applicable) occur in the RU, and the rest of the PHY processing happens in the DU. 2G, 3G, and 4G use Common Public Radio Interface (CPRI), which is passed on an option 8 split.

Moving to the 7-2 split reduces traffic between the DU and RU. O-RAN has specified a version of the 7-2 split. Figure 3 illustrates the 7-2 split, as well as how other parts of the protocol stack are split between the CU and the DU. The 7.2x split is the best balance between bringing this technology to market quickly and deployment cost. It reduces confusion about split specifics while making traffic reduction gains and improvements. Some 5G systems use evolved CPRI (eCPRI) as the DU-RU interface. eCPRI offers a vendor-specific split between the high and low PHY. Thus, you can optimize for traffic or flexibility by supporting multiple splits, accommodating different deployment environments due to unique antenna physical environments. With this comes the freedom to cost-optimize for connections specific to different operators.

^{Figure 3: Protocol Layer Split Between CU, DU, and RU for Option 7.2.}

For new 5G RAN architectures, the 3GPP has defined and standardized on a new interface, the F1 interface, for communication between the CU and the DU. When the CU and the DU are physically split, it is called a higher-layer split (HLS). While not defined by the 3GPP, the lower-layer interface between the DU and the RU is called a lower-layer split (LLS). You can configure the CU and DU in relation to each other and in relation to RUs in several ways. Figure 4 diagrams various RAN configurations. Note that the F1 interface is delay tolerant, while the DU-to-RU interface needs to be low latency. Given the challenges of creating low-latency interfaces, the rest of this paper details a central RAN with a lower-layer split use case.

^{Figure 4: RAN Functional Unit Location Flexibility (Source: NGMN, 2018.}

The interface between the DU and RU also is known as the fronthaul (FH) interface. The FH interface, one of the most demanding system interfaces, is very latency sensitive. Where the DU and RU come from the same manufacturer, most systems use CPRI or eCPRI (5G only) as the FH interface. While CPRI originally was intended as an open interface, in practice, each vendor implemented it in a slightly different way to work with their own hardware, rendering multivendor interoperability difficult or impossible. While not encouraging an open, white-box hardware architecture, you can more easily achieve tight synchronization between the DU and RU. When the DU and RU are from one vendor, they are matched in terms of when to send and when to receive (the only variation being the distance between DU and RU).

​One of O-RAN’s two goals is to create more open ecosystems, which requires defining a new FH interface. One of the seven O-RAN working groups, working group 4 (WG4), is dedicated to defining this interface. Called the Open Fronthaul Interfaces Workgroup, its objective “is to deliver truly open fronthaul interfaces, in which multivendor DURRU interoperability can be realized.” Figure 5 shows how the proposed DU-to-RU interface exchanges information in different planes. While the seven different flows—plus additional management (M)-plane flows—may seem daunting, at a higher level, there are only three data types (I/Q data, timing and sync data, and command and control information) across four total planes (control, user, sync, and management).

^{Figure 5: Lower Layer Fronthaul Data Flows (Source: O-RAN).
Note: M-Plane Flows Not Represented Here.}

Compared to CPRI, there are significant differences in how the I/Q data is transferred, packed, and unpacked in the FH interface, since CPRI is based on an option 8 split. The option 8 split splits the network at the RF, so the I/Q samples have not undergone any PHY processing (FFT/iFFT). As networks evolved in the later stages of 4G and early 5G, eCPRI sought to reduce traffic caused by the increase in antennas and sampling rate (multiple samples per antenna) used in massive multiple-input and multiple-output (MIMO). System traffic overwhelmed the physical connection, and connections that can accommodate the traffic are expensive to implement.

​To reduce traffic across this interface, eCPRI moves certain parts of the PHY into the RU and adds compression algorithms. However, which pieces of the PHY are moved into the RU does not follow any specific split and differs from vendor to vendor. This scenario could be a competitive advantage to some vendors, and a way to potentially reduce the link cost for operators. Since part of the lower-level PHY functions are in the RU, the DU must inform the RU how to perform these functions. This instruction creates a different command-and-control interface between eCPRI and O-RAN’s FH interface as well, but having vendor-specific splits perpetuates a service provider vendor lock. O-RAN’s open FH interface aims to standardize on which pieces of the PHY are moved into the RU by using the 7.2x split so that you can integrate hardware from different vendors.​

As WG4 works to finalize an FH interface, they must consider how to test it. For systems containing a DU and RU from different hardware vendors, system integrators and vendors need the ability to validate that the DU and RU interface properly. This type of testing is commonly referred to as interoperability testing. O-RAN is investigating how to test an O-RAN-compliant system. Figure 6 is an O-RAN diagram showing what a test setup might look like for testing an O-RAN-DU (O-DU) and O-RAN-RU (O-RU) with an O-RAN-CU (O-CU) and a UE, which could be emulated or commercial. There is a test point to look at the interface between the CU and DU, and one to look at the RU RF input/ output, but the DU and RU are combined as the device under test (DUT). This leaves the FH interface between the DU and RU untested when using active stimulus and only considered for passive monitoring.

^{Figure 6: O-RAN Test Setup, Active (Left) and Passive (Right) (Source: O-RAN).}

There are two kinds of active testing to consider for the FH interface: protocol testing and parametric testing. O-RAN has shown that protocol testing is necessary for test-case validation and troubleshooting. Having test tools to validate designs during development is key to interfacing successfully with other O-RAN-compliant devices. After the design is finalized and DUs and RUs enter the validation and production stages, parametric tests make sure that each unit performs as expected.

​​The RU is a critical component of the O-RAN base station. It provides the low PHY layer, connecting UEs to the RAN. On the other end, it provides a connection through the O-RAN FH interface to the DU. The RU is a scalable component, so many RUs can connect to a single DU and a given RU having multiple antennas to connect to multiple UEs simultaneously. This configuration means it is also the most numerous component in the base station with the most test points; as such, fast test times become critical to operational efficiency. NI has kept these considerations in mind and has created validation and production test solutions able to meet these requirements.

O-RAN RU Validation

​By NI partnering with Spirent, we have created a solution for comprehensive validation of O-RAN RUs. With a fully automated single GUI that controls the UE, RF channel emulator, RU (DUT), DU, CU, and core (EPC/5GC), the collaboration between NI and Spirent provides users with end-to-end functional and performance testing and full capabilities for RU validation, all in one integrated and connected test platform.

^{Figure 7: RU Validation Block Diagram with Spirent and NI.}

Key Features:

1. Fully automated single GUI that controls UE, RF channel emulator, RU (DUT), DU, CU, and core (EPC/5GC)
2. Real-time live network emulation for DU, CU, core, and UE
3. Real-time data plotting for data performance (KPI) and over-the-air messages
4. O-RAN Alliance TIFG End-to-End Test Specification Section 4 and 5 functional and performance testing
5. Advanced O-RU sensitivity performance testing for benchmarking O-RU performance and near-far dynamic range testing
6. Fully integrated hardware based on the PXI platform for scalable, high-performance instrumentation

O-RAN RU Production Test

NI’s O-RAN RU Production Test Solution provides fast and efficient test during RU manufacturing. With RF and digital DUT control under the same test and automation interface, superior timing and synchronization with NI instrumentation, real-time fronthaul link, and high-throughput DU emulation, this solution provides efficient, fast, and cost-effective RU production test.

Together with NI Partners, this solution enables lower overall test cost and can shorten time to market.

^{Figure 8: O-RAN RU Production Test Block Diagram.}

Key features:

1. High-throughput DU emulation record and playback
2. Integrated DUT control
3. O-RAN and traditional RAN test cases for production test
4. Adapt to evolving wireless standards with PXI VSTs
5. Fast test times with four-layer RU with listed measurements
6. Cost-effective test platform with a small footprint

O-RAN maintains three goals:

• Creating a smarter RAN that takes advantage of the ability to virtualize pieces of the network for maximum efficiency gains
• Supporting white-box hardware for multivendor network solutions
• Creating standardized interfaces between network components

By delivering on these key initiatives, O-RAN aims to evolve networks to be more future-proof and incorporate 5G-promised features and use cases, such as URLLC. The FH interface in particular is challenging because of the low latency required for DU-to-RU communications. O-RAN’s WG4 is making progress to define this interface, and companies are beginning to build O-RAN-compliant RUs to connect to other O-RAN-compliant hardware. Being able to validate and test the DU-RU interface is important in both the design and validation stages, as well as in production test, as this new technology comes to market. By offering IOT testing hardware and software, as well as comprehensive RU validation and production test solutions, NI can help accelerate bringing new O-RAN-compliant RUs to market. When O-RAN is widely adopted and used in 5G networks remains unclear; however, as of now, the alliance is working actively to implement new interfaces and is seeking ways to use multivendor hardware solutions to build new networks for the sake of improving and advancing cellular network infrastructure.