ConnectivityElectronicsIndustry 4.0

Open RAN: it’s still early in the game

With all the talk about Open RAN, it’s still in the top of the first inning.

Open radio access networks (Open RAN) have become a hot topic in wireless communications, with many service providers anxious to deploy them in the next few years. Based on virtualizing network functions between the radio and the telecom core, Open RAN will spur innovation, cut costs, and offer greater opportunities for differentiation among both operators and equipment vendors.

Despite the tremendous progress that has been made in such a short amount of time – including the creating of the O-RAN Alliance reference architecture and at least 23 specifications – the industry is still a long way from meaningful Open RAN deployment. In baseball terms, it’s still the top of the first inning with no outs.

The O-RAN Alliance, the ecosystem and standards development organization created to spur the creation of the open interfaces required to make Open RAN work, has just celebrated its third birthday. Yet, its membership has already swelled to nearly 30 operators and more than 260 contributing companies, including network equipment manufacturers (NEMs), software vendors, chipset manufacturers, and test equipment companies, among others. Many of those companies have joined just within the past year. The momentum is only intensifying.

Open, interoperable architectures and virtualization are both core to the definition and vision for Open RAN. Both are within sight but remain works in progress. This article will provide a high-level overview of the status of Open RAN development, with a focus on interoperability and virtualization.

Steadily moving toward interoperability
Dozens of companies throughout the world now develop Open RAN equipment based on the nearly two dozen O-RAN Alliance specifications released so far. Like the emergence of any major disruptive technology, the process of refining these specifications moves at its own glacial pace.

Open RAN protocols and interfaces are being continually refined in the pursuit of the goal of true interoperability. Developing Open RAN equipment requires that the individual components conform to the relevant standards. Conformance testing, which is completed using tools to emulate the other components of the RAN (Figure 1), is nothing new.

RU test setup

Figure 1. Testing a radio for an Open RAN involves emulating the distribution unit (DU) plus generating RF signals and analyzing transmitted signals from the radio.

What is different in Open RAN is the requirement for interoperability testing — making sure that the O-RAN specified individual components work together, as expected. Prior to the Open RAN era, RANs were built almost exclusively from equipment supplied by one of a few vendors. While this eliminated interoperability issues, it limited the operators negotiating power. Furthermore, it stifled innovation by locking out smaller companies that lacked the resources to build a complete RAN. Hence, the Open RAN movement and its pursuit of multi-vendor RANs based on openness, disaggregation, and interoperable interfaces between the various components.

We’re still in the early days in the implementation of the O-RAN Alliance specifications. Though the specifications are highly detailed, vendors still find enough room for interpretations to create interoperability issues. Through interoperability testing, which involves putting various components together and testing them against each other, equipment manufacturers and operators developing Open RANs uncover issues and work out the kinks in the specifications. In some cases, they find that the equipment interoperates as expected. Often, it still does not. These are the growing pains of a young, healthy, and vibrant technology ecosystem.

As with any technology standardization process, ambiguities are discovered and documented. Change requests are made and over time, the standards evolve. They are refined, modified, and improved.

The quest for virtualization
Virtualization is one aspect of O-RAN implementation still under refinement. While the push for RAN virtualization (detailed below) is practically a no-brainer, bringing virtualization to the RAN for the first time adds complexities, including design and test challenges and some impact on performance.

In the not-so-distant past LTE days, the fronthaul was a dedicated fiber connection between remote radio heads and baseband units that ran on a fiber connection and utilized Common Public Radio Interface (CPRI). In Open RAN, the fronthaul runs over Ethernet.

This has an impact on multiple fronts. For starters, the O-RAN Alliance specifications adopted an option for a 7-2 functional split between O-RAN Distributed Units (DUs) and O-RAN Radio Units (RUs). Under this arrangement, data is only transmitted to the RUs if there is real data to transmit — a change from 4G where persistent string of zeros transmit to the radio unit. Those persistent transmissions consume bandwidth. 5G consumes bandwidth only when sending data.

Ethernet lets network operators employ virtualization for switching traffic from one node to another, starting new virtual instances, and utilizing other techniques more associated with cloud computing. Ethernet, however, brings with it its own challenges, including requirements for time-sensitive networking and low latency that still require additional work.

The telecom industry has mostly decided which components of the Open RAN can be virtualized. In some cases, however, the exact implementation is a work in progress.

Open RAN brings with it opportunities to virtualize a large portion of the RAN. The O-RAN Alliance adopted RAN cloudification as one of its key tenets. Cumulatively, operators now invest hundreds of billions of dollars in equipment to build out their 5G networks. Naturally, they want to utilize these resources as efficiently as possible. They don’t want their gear lying around, used only part or even most of the time. Virtualization speaks to the issue because it enables operators to maximize resource utilization by building virtual RANs instead of physical ones.

Several Open RAN components can and will be virtualized (Figure 2).

  • The O-RAN Centralized Unit (CU) is responsible for the packet data convergence protocol (PDCP) layer of the protocol between the network and the handset. Because it handles data exclusively, the CU is ripe for virtualization. Packets can move through a virtual CU in much the same way that data moves through many of the other types of virtual data centers that make up our modern world.
  • The DU is the Open RAN component responsible for baseband processing, scheduling, radio link control (RLC), medium access control (MAC), and the upper part of the physical layer (PHY).
  • The DU can and will be virtualized, but the DU does handle some physical layer signal processing depending the chosen functional split and will require some type of hardware-assisted virtualization. This hardware assistance could occur in an FPGA, a GPU, accelerator card, or ASIC.
  • The RU is responsible for the lower part of the PHY layer processing, (for example, fast Fourier transform (FFT) / inverse fast Fourier transform (IFFT), and beamforming) including the analog components of the radio transmitter and receiver.

Open RAN network architecture

Figure 2. A typical Open RAN architecture from the edge to the network core might use a 7.2 functional split.

At this point, the RU is not considered a candidate for virtualization. One O-RAN Alliance working group is, however, developing a “white box” radio implementation using off-the-shelf components, which would enable anyone to construct a radio without proprietary components.

Virtualized testing could provide a hidden benefit. Because the entire Open RAN will be as virtualized as possible, test tools will likely move to virtualized format. Virtualized testing brings with it the possibility that test tools used in the lab could be deployed on the live network to conduct real time testing.

3GPP recognition
Another significant ongoing challenge to Open RAN is that 3GPP specifications do not recognize multivendor Open RAN. Current 3GPP specifications do not account for an architecture that has a functional split between a DU and RU. 3GPP specifications also do not recognize the RAN Intelligent Controller (RIC), another O-RAN Alliance architecture component that is critical for enabling the virtualization of the RAN.

This is also work in progress. 3GPP is aware that there is a radical change underway in the RAN and since many companies have representatives that sit on both 3GPP and O-RAN Alliance, at some point Open RAN technology will be incorporated into future 3GPP releases.