5G Testing: What Is O-RAN? – Part 2
2020-06-30 | 9 min read
In a previous blog, I covered the organization, terminology, and core principles for open radio access network (O-RAN), the operator-led alliance that defines the next-generation radio access network (RAN) architecture. In this post, I will cover high-level technical aspects.
First, a quick overview of the O-RAN working groups is necessary.
Figure 1. O-RAN Alliance working groups
O-RAN includes nine groups, each focused on a specific area, as follows:
- WG1: use cases and overall architecture
- WG2: RIC, non-RT aspects, and A1 interface
- WG3: RIC, near-RT aspects, and E2 interface
- WG4: NGFI interface specification
- WG5: Key interfaces and stack reference design
- WG6: Cloudification and MANO enhancement
- WG7: White-box hardware
- WG8: stack reference design
- WG9: Open x-haul transport
In addition, the Test & Integration Focus Group (TIFG) is responsible for defining the overall approach for testing and integration. TIFG is working with the O-RAN Test Integration Center (OTIC) to establish centers around the world for O-RAN components compliance certification.
Now, off to the O-RAN architecture. The fronthaul becomes much more challenging with 5G. With 4G LTE, a centralized baseband unit (BBU) connected to a remote radio head (RRH) through the CPRI interface. The data rate between the BBU and the RRH was sufficient because of the total bandwidth and few antennas. A lot more data needs to go back and forth in 5G because of higher bandwidths and more antenna ports due to the use of massive multiple-input multiple-output (MIMO) technology.
This has led to the development of two solutions – high-level split (HLS) and low-level split (LLS). HLS is a two-box solution with most of the processing moving to the edge. The interface between the DU+RU to the centralized unit is the F1 interface. Alternatively, LLS moves more processing to the center and keeps the antenna to the edge.
With O-RAN, three distinct components emerge- the radio unit (O-RU), the distributed unit (O-DU), and the centralized unit (O-CU). The O-RU sits at the edge. The O-DU sits in the middle and performs some of the processing. O-RAN involves both HLS and LLS. The interfaces are standardized. Operators can use different vendors for the CUs, DUs, or RUs. The components are much more interoperable and the protocols are clearly defined, with WG5 focusing on the F1 interface and WG4 on the fronthaul.
Figure 2. Evolution to O-RAN
5G will bring about a bandwidth explosion in the fronthaul. The typical bandwidths for LTE channels are 10 or 20 MHz. A CPRI interface between the BBU and the RHH means line rates ranging anywhere between 600 Mb/s and 10 Gb/s, depending on the bandwidth and the number of MIMO channels. A 10-MHz bandwidth channel translates into a line rate of 614 Mb/s. Eight 10-MHz channels require about 5 Gb/s. Ten 20-MHz channels require slightly more than 10 Gb/s. CPRI can easily address these requirements. The interface is prominent between the BBU and the RRH in LTE.
In 5G however, the bandwidth increases to 100 MHz or more bandwidth and 8 antennas in many cases. This translates into line rates in the 28 Gb/s range between the RU and the BU. Greater bandwidths such as 500 MHz means more than 140 Gb/s. At such bandwidth, massive MIMO increases the line rate to 2 Tb/s. 2 Tb of traffic over CPRI is untenable. Functional splits address this challenge.
Figure 3. 5G RAN functional splits
RUs are typically located at the antennas. The connectivity between the RUs and DUs is commonly known as the fronthaul interface. Typically, the distance between the two is about 10 km. That distance is also based on very low latency requirements for transporting packets back and forth between the two (in the range of 100 ¼s). An eCPRI interface is used instead of a CPRI interface to reduce the bandwidth requirements. You can move all the physical layer functionality into the RUs. The bandwidth requirements reduce tremendously, with only about 3 to 4 Gb of bandwidth requirements between the DU and RU, but RU complexity increases tremendously.
Option 8 provides an alternative. It puts all the physical layer functionality into the DUs, only keeping the antennas at the edge. This is like the LTE architecture with the connectivity through a CPRI interface. With 5G, the bandwidth requirements increase significantly though. Even a nominal scenario requiring 200 or 300 Gb of transport between the DUs and RUs is untenable.
Option 7.2 provides an optimal split between the DUs and RUs. The PHY is broken into two, low-PHY and high-PHY. The low-PHY stays in the RUs and the high-PHY stays in the DUs. As a result, the bandwidth required on the fronthaul interface is about 20 Gb for 100 MHz bandwidth with some MIMO capabilities involved.
Moving from the DUs to the CU typically means an upper layer split (Option 2). The processor intensive functionality moves into the CU while the remaining part of the stack stays in the DU. The MAC and RLC, along with the high-PHY, stay in the DU. You can split at the control level with an interface between the DU and the CU. The data requirements are about 100 Gb between the DU and CU and there is a slightly higher latency requirement in the ms range. The distance requirement between the CU and the DUs is about 80 km.
Finally, the backhaul interface, which is the connection point for the CU to either the 4G network in the case of nonstandalone (NSA), or the 5G core network in the case of standalone (SA), has a much higher distance requirement in the 200-km range. The latency requirements are also much less stringent, in the order of 40 ms.
The migration toward more open fronthaul interfaces comes with many challenges. You will need to test more units and perform peer emulation for the O-DUs and O-RUs. You will also need to conduct conformance, interoperability, and performance testing for all these components. The new functional splits increase RU complexity and require new test capabilities. Timing between the RF and digital domains becomes critical. Setting up connectivity, passing on control and user data, and looking at huge amounts of data going back into the core network in the backhaul is protocol-intensive. 5G standards and O-RAN specifications also continue to evolve. Solutions to overcome these challenges exist though. You can explore Keysight's O-RAN test solutions and try them here.
You can also learn more about 5G technologies, challenges, and solutions at www.keysight.com/find/5G.