Open radio access network (O-RAN) enables the transformation and virtualization of the RAN for 5G. It brings significant opportunities to network operators, but also spurs new challenges for test engineers. There are many questions about O-RAN in the minds of wireless engineers. This article will explain why the wireless communications industry needs O-RAN, how it works, and what challenges lie ahead.
First off, let’s define O-RAN. It is not a technology per se, but an operator-led alliance formed in February 2018 by five global operators with the desire to migrate away from physical purpose-built hardware to virtual cloud-based software implementations. By specifying discrete components and standardizing interfaces, the alliance enables hosting on white-box hardware and opens the door for operators to work with a plethora of vendors.
They can work directly with RF contract manufacturers, companies that specialize in graphics processing units (GPUs) and field-programmable gate arrays (FPGAs), and even virtual cloud infrastructure providers. With O-RAN, operators can mix and match components and work with specialists to create unique solutions.
The O-RAN Alliance provides the specifications, reference architecture, and interfaces between the RAN components that include the radio unit (O-RU), the distributed unit (O-DU), and the centralized unit (O-CU). Membership has grown tremendously over the past two years. The alliance now includes 24 mobile network operators and 148 other contributors ranging from network equipment manufacturers (NEMs) and chipset manufacturers to companies building stacks and radio elements. You can view the list of members on the organization’s website.
5G needs O-RAN
Now that we’ve defined O-RAN, let’s dive a bit deeper into why the industry needs it. The answer is simple: more data is coming with 5G, which will place significant demands on the front-haul portion of the RAN infrastructure.
In 4G LTE, a centralized baseband unit (BBU) is connected to a remote radio head (RRH) through a common public radio interface (CPRI). The data rate between the BBU and the RRH was sufficient because of the total bandwidth requirements and few antennas. However, in 5G, a lot more data needs to go back and forth. The use of massive multiple-input/multiple-output (MIMO) to increase throughput means higher bandwidths and more antenna ports.
Two solutions have emerged to address the 5G front-haul challenge: high-level split (HLS) and low-level split (LLS). O-RAN involves both HLS and LLS and 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.
Still, 5G will drive a bandwidth explosion in the front-haul. The LTE channels typically only have 10 or 20 MHz of bandwidth. The CPRI between the BBU and the RRH means line rates ranging from 600 to 10 Mbps, depending on the bandwidth and the number of MIMO channels. A single 10-MHz bandwidth channel translates into a line rate of 614 Mbps, eight 10-MHz channels mean about 5 Gbps, and 10 20-MHz channels slightly more than 10 Gbps. CPRI can easily address these requirements, which is why this interface is prominent between the BBU and the RRH in LTE networks.
The situation is drastically different with 5G. Bandwidth increases to 100 MHz or more and the number of antennas grows to eight in many cases, which translates into line rates in the 28 Gbps range between the RU and the BU. Greater bandwidths such as 500 MHz means more than 140 Gbps. At such bandwidth, massive MIMO increases the line rate to 2 Tbps, which is simply untenable over CPRI. Functional splits address this challenge.
How functional splits work
How do the functional splits address this problem in practice? Typically, the distance between the RUs and the DUs is about 10 km, based on very low latency requirements for transporting packets back and forth between the two. An enhanced CPRI (eCPRI) interface reduces the bandwidth requirements by moving all the physical layer functionality to the RUs.
RU complexity increases drastically, though. Option 8 is a split option that provides an alternative by putting all the physical layer (PHY) functionality into the DUs, only keeping the antennas at the edge. This is like the LTE architecture with connectivity through a CPRI interface.
As mentioned earlier, the bandwidth requirements increase significantly with 5G. Even a nominal scenario requiring 200 or 300 Gb of transport between the DUs and RUs is untenable. That’s where Option 7.2 comes in. This split option provides an optimal split between the DUs and RUs. The PHY is broken into low-PHY and high-PHY; low-PHY stays in the RUs and high-PHY in the DUs. As a result, the bandwidth required on the front-haul interface is about 20 Gb for 100 MHz bandwidth with some MIMO capabilities.
Moving from the DUs to the CU typically means an upper layer split or HLS—Option 2. Processor-intensive functionality moves to the CU while the remaining part of the stack, such as the media access control (MAC) and radio link control (RLC) layers, 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 milli-second range. The distance requirement between the CU and the DU is about 80 km.
Other implementation challenges
Let’s not forget about the backhaul interface, the connection point for the CU to either the 4G network in the case of non-standalone (NSA) deployments or the 5G core network in standalone (SA) implementations. This interface has a much higher distance requirement—about 200 km—and less stringent latency needs—40 ms.
What does this all mean from a test perspective? In short, it means that interoperability will be a significant challenge as O-RAN moves from specifications to implementation and deployment. The components not only need to interoperate, but also conform to the specifications. Performance will also be a key area of focus to control the amount of bandwidth between the O-DUs and the O-RUs.
Currently, many engineers are struggling with the device under test (DUT). Very few are adept at both RF and Ethernet, and they are interpreting the specifications differently, leading to different implementations.
Engineers working on O-RUs are dealing with timing issues and often bypass the M-plane. They are also facing clocking and synchronization challenges between the O-RU and the O-DU. Those focusing on O-DUs face processing bottlenecks and similar timing issues as on the O-RU side and also need to ensure that the O-DU can be hosted on virtual and physical appliances.
The O-CU challenges, meanwhile, revolve around scalability, such as how many DUs or UEs can each CU support and at how much throughput. In addition, the separation of the control and user planes of the central unit—Cu-UP and Cu-CP—requires coordination over the E1 interface.
While these challenges can be qualified as early teething problems that will be solved over time, they can have severe consequences. The DU will not proceed if certain protocol options are missing or M-plane parameters are not met, even if they are optional. DUs are also designed to work with specific RU capabilities. A DU typically supports a certain RU category, beamforming model, and compression rate and will stop operating if there is a mismatch.
A lot of aspects must align between the DU and the RU for the whole system to work. The good news is that solutions are available to engineers to overcome these challenges and more will emerge. O-RAN is complex, but it is here to stay.
>> This article was originally published on our sister site, EDN.
|Jessy Cavazos is part of Keysight’s Industry Solutions Marketing team.|
- Helping developers build apps for multi-access edge computing
- Mobile edge computing powering virtualized 5G networks and industry
- New MIPI RF front end spec takes 5G beyond mobile
- 5G’s biggest challenges for communications service providers
- Edging Towards a 5G Future: Mobile Edge Computing
- Deploying 5G Edge Cloud Infrastructure for vRAN
For more Embedded, subscribe to Embedded’s weekly email newsletter.