Bringing performance at scale to Open RAN
A new industry-wide agreement on open fronthaul interfaces enables communication service providers, CSPs, for the first time, to achieve full performance with Open RAN in commercial network deployments at scale.
The newly agreed open fronthaul interface specification Cat-B ULPI* (See below Open Fronthaul interface standard evolution), Uplink Performance Improvement, provides a vast improvement from the earlier standard, referred to here as Cat-B*. Indeed, Cat-B ULPI makes it possible to deploy Open RAN at scale, without compromise on performance, and at optimal fronthaul costs. Making good on its long-term commitment to Open RAN, Ericsson will start migrating its RAN portfolio to Open Fronthaul in 2024.
The Cat-B ULPI predecessor, Cat-B, also referred to as the Cat-B split, was developed, and standardized to enable an interoperable Open RAN. Unfortunately, it came short on delivering the right performance in dense networks with high levels of mobility, as extensive simulations showed. Fronthaul is the most critical interface for performance in Open RAN and Ericsson has long been committed to promoting openness without compromise on performance. Addressing the challenges faced by fronthaul in a manner that provides both the highest level of interoperability and the best possible performance is therefore a no-brainer for Ericsson. And this commitment matches well CSPs’ own ambitions of high performance when deploying Open RAN**.
Together with industry partners within the O-RAN Alliance, Ericsson has actively worked towards defining a new fronthaul interface specification that addresses the shortcomings of the initial Cat-B split for Massive MIMO* (multiple input, multiple output) Radio. In June 2023, an agreement was reached on two new fronthaul interface specifications for Cat-B. Out of those two, the newly standardized Cat-B ULPI-A* lowerlayer split specifications is the interface that best enables deployments in dense environments such as Massive MIMO networks while also providing the highest level of interoperability and minimizing additional fronthaul costs.
Ericsson will introduce both Cat-A and Cat-B on Cloud RAN, purpose-built RAN, and Radio, with prioritization based on customer demand, starting in 2024.
This paper will dive into the Open RAN fronthaul interface, zoom in on the specifics of Cat-B ULPI for Open RAN in dense network environments, as well as on Ericsson’s commitment to high-performing Open RAN.
*Open fronthaul interface standard evolution
Cat-A: Current standard for remote radio units (RRU), refers to the 7-2x Cat-A no-BF-RU split
Cat-B: Current standard for massive Multiple Input, multiple output (M-MIMO) radios, refers to 7-2x Cat-B
Cat-B ULPI: New standard for M-MIMO, refers to ULPI improvements on 7-2x Cat-B, or Cat-B
Cat-B ULPI-A: New standard for M-MIMO, version A, or Class A, refers to 7.2x ULPI with DMRS-EQ
Cat-B ULPI-B: New standard for M-MIMO, version B, or Class B, refers to 7.2x ULPI with DMRS-NEQ
**Source: Heavy Reading O-RAN survey 2023
Open interfaces – A key element in Open RAN
Standardized open interfaces that enable different vendors and components to work together in the most efficient way are a key success factor in building highperforming networks. Fronthaul is one of the most critical interfaces in Open RAN. As it connects the radio units to the network, it is central to the performance of the air interface and the overall efficiency of the Radio Access Network (RAN).
Open and consensus-based development of standards has been one of the telecom industry’s strongest foundations, and a success factor in its evolution.
Standardization has been driven via 3GPP, and in more recent years also via the O-RAN Alliance for the specification of some key Open RAN interfaces.The O-RAN Alliance is a global industry initiative that aims to define the technical specifications and interfaces for RAN. Key members of the O-RAN Alliance include major CSPs, telecom vendors like Ericsson, as well as cloud services and infrastructure players. The standardization of the Open RAN interfaces is building on the foundation set by 3GPP and is fully interoperable with the evolution of the broader network, including Core, Transport and Service Management and Orchestration (SMO).
A key characteristic of Open RAN is that multiple vendors can – and will – co-exist within the RAN domain. To make this happen, interfaces between the different parts of the network must be standardized. That work is conducted by the O-RAN Alliance. It defines standards and interfaces for an Open RAN architecture that enables different vendors and components to work together in the most efficient way. Open interfaces specified by the O-RAN Alliance include interfaces between the RAN and SMO (A1, O1) and the Open Fronthaul interface between the radio unit and the RAN (more specifically the distributed unit), which is also known as the Lower-Layer Split (LLS).
Open RAN architecture
In the O-RAN Alliance architecture, the baseband functions are split into three different logical units, O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU), and O-RAN Radio Unit (O-RU). The O-CU and O-DU can either run on Commercial Off-The-Shelf (COTS) hardware or on purpose-built hardware. The O-CU and O-DU running on COTS hardware are usually referred to as Cloud RAN. The O-RU is most commonly based on specialized hardware (including Application Specific Integrated Circuit, ASIC), field-programmable gate array (FPGA), or Digital Signal Processors (DSP). The O-RAN fronthaul interface is used in both Cloud RAN and Purpose-built RAN. The difference between Purpose-built RAN and Cloud RAN can be seen in figure 1.
Importance of the fronthaul interface
In Cloud RAN, just as in Purpose-built RAN, the standards need to specify in detail which functions should run on which unit to optimize the system. In essence, it means taking the functions necessary for the base station to work and placing them on the different units, O-CU, O-DU, and the O-RU, as seen in figure 2. The different high-level functions must be cleverly distributed between all three units to optimize the performance of the system.
The Higher-Level Split (HLS), also called mid-haul interface, defines which functions the O-CU and O-DU should handle. 3GPP agreed on a split whereby the O-CU handles Layer 3 functions, mainly the Radio Resource Control (RRC) and the Packet Data Convergence Protocol (PDCP), while the O-DU handles Layer 2 functions, including the Radio Link Control (RLC) and Medium Access Control (MAC), as well as the Layer 1 function called High-PHY. The interface between the O-CU and the O-DU, called the F1 interface, as defined by 3GPP has been implemented in the O-RAN architecture.
The Lower-Layer Split (LLS), also called fronthaul interface, splits functions between the O-RU and the O-DU. The LLS is an intra Layer 1 split between the High- PHY in the O-DU and the low-PHY in the O-RU. The LLS, and more specifically the exact split of functions between High-PHY in O-DU and Low-PHY in O-RU, has a major impact on the performance that can be achieved over the air interface. It therefore affects the overall spectral efficiency more than any other open interface in the RAN stack. The next chapters will focus on the fronthaul interface and how the split of functions between O-DU and O-RU impacts the performance and design of the RAN.
Figure 1: Purpose-built RAN and Open RAN
Figure 2: Distribution of functions in O-RAN
The role of the fronthaul interface
Remote radios and Massive MIMO radios require different fronthaul interfaces. As the number of antenna elements and processing power in the radio unit increases, so does the complexity the fronthaul interface needs to handle.
The split of functions across the Lower- Layer split, LLS, can be done in various ways. The optimal split depends on multiple factors including bitrate capacity requirements between the distributed unit (O-DU) and the radio (O-RU), fronthaul latency, radio complexity, and radio performance. There are two primary contexts that need to be considered when defining the LLS: Remote radios and Massive MIMO radios.
Remote radios are usually used in locations with lower traffic needs, for example rural areas. They are connected to antennas with a maximum of eight digital antenna ports. These antennas and radios are straightforward from a fronthaul interface perspective and the need for processing power in the O-RU is lower in comparison to that of Massive MIMO radios. Massive MIMO radios, on the other hand, are used in locations with high-capacity requirements. They support more than eight digital antenna ports. Massive MIMO radios are more complex and require more processing power in the O-RU to handle the more complex beamforming calculations that come with a larger number of digital antenna ports.
The optimal Lower-Layer Split differs between these two categories of radios.
Remote radios can deliver the performance for which they were designed with most functions sitting in the O-DU. With a maximum of eight digital antenna ports and, correspondingly, eight channels between O-RU and O-DU, existing fronthaul capacity in most remote radios is sufficient to transport data across the fronthaul interface. In a Remote Radio scenario, the radios can therefore be simpler compared to M-MIMO radios, with only a limited set of L1 processing functions in addition to the Digital Front End (DFE), while the O-DU performs most of the L1 processing. The standard that was developed for these types of radios is known as the Cat-A split and works fine for Remote Radios deployments.
For Massive MIMO radios, the story is quite different. The higher number of digital antennas–today typically up to 64– means bigger compute needs, especially for beamforming. This compute could take place either in the O-RU or in the O-DU. But running it in the O-DU, as is the case with Cat-A, would require a lot of data to be communicated across the fronthaul interface. This, in turn, would require adding fronthaul transport capacity, in practice adding more fibers between the O-RU and the O-DU, which would be very costly. To address this issue and support Massive MIMO radios, the O-RAN Alliance introduced a new split, the Cat-B split, also known as the 7-2x split. In short, this split places the RF and low-Phy functions in the O-RU, and the high-Phy, MAC and RLC functions in the O-DU. The split does not only place low-PHY in the radio unit, but it also makes the low-PHY handle complex functions, in particular beamforming.
The aim of the Cat-B split was to strike a balance between the processing capabilities of the O-RU and the capacity of the fronthaul interface and to create a clear separation of responsibilities to simplify multi-vendor deployments. Unfortunately, the design choices and compromises made in this split led to a trade-off between high user throughput performance and optimized fronthaul capacity, especially in the uplink for Massive MIMO deployments in environments with high interference, load, and User Equipment (UE) mobility.
Figure 3a & 3b: Split of function in Cat-B – Challenges with beamforming in the O-RU
Two major challenges with beamforming in the O-RU
Loss of channel information: Placing the beamforming function in the O-RU helps reduce the number of streams transmitted to the O-DU but leads to a loss of channel information.
Delay: Beamforming in the O-RU is based on the previous channel information calculated in the O-DU, creating a certain delay
How the split works
Let us look at how the Cat-B split works, technically, as it will help us better understand where performance issues arise, and what a new solution should include to ensure that the right performance can be achieved. A simplified view of the split of functions in the Cat-B standard is depicted on the schematic figure 3a.
The Cat-B split limits the functions placed in the O-RU, placing most of those in the O-DU, in particular the uplink channel estimation, beamforming weight calculations, and the equalizer. These functions are all closely related to the beamforming function running in the O-RU. This means that a lot of data still needs to be communicated across the fronthaul interface. To mitigate the challenge of large data volumes and bitrate in the fronthaul, as depicted in the schematic figure 3b, the standard introduced a beamforming function in the O-RU, which allows the selection of digital streams. The purpose of the beamforming function is to reduce the amount of data to be communicated across the fronthaul interface. Instead of sending data from all digital antenna ports across the interface, the beamforming function creates a set of most relevant beams that generates a reduced number of streams that are transmitted to the O-DU. This solves the bitrate problem in the fronthaul but comes with some inherent drawbacks. The reduction of streams leads to a loss of channel information in both the space and frequency domains, reducing the capability to track channels and suppress interference. Another major challenge with the solution is that beamforming in the O-RU is based on the previous channel information calculated in the, and high spatial variability O-DU; this creates a certain delay, of approximately 10-20ms, which in turn leads to reduced robustness when it comes to interference and best performance when UEs are moving.
To understand why this leads to performance issues, imagine an urban location where Massive MIMO radios are deployed, with many highly mobile UEs and with time-varying inter-cell interference. The radio landscape in this scenario is constantly changing, UEs moving in the environment, and any delay introduced by this split would degrade the accuracy of the beamforming to a point where it is no longer precise enough to ensure the best possible performance. Essentially, it could risk pointing the beams of the Massive MIMO radios to a physical location where the UE no longer is or trying to cancel interference in a frequency that is no longer subject to interference. Performance issues in Massive MIMO networks mean that CSPs cannot deliver optimal performance in environments where uplink performance is critical, such as in stadiums, busy downtown streets, locations with tall buildings, etc.
There were different possible implementations of the Cat-B split but, it proved impossible to simultaneously handle high interference, high mobility and high spatial variability, the exact characteristics of an environment where Massive MIMO radios are usually deployed. When you have a Massive MIMO system, the most sophisticated system you can deploy in the densest urban areas, you want to make sure you can use your spectrum in the best way possible. There should be no limitations on uplink performance. This is why the initially agreed Cat-B standard was not sufficient. Something had to be done about it.
A new interface to deliver performance at scale with full interoperability
The improved fronthaul standard Cat-B ULPI-A can deliver the right performance at scale as it solves the original problem of implementing Massive MIMO Radio on O-RAN with existing fronthaul capacity. Creating a clear separation of responsibilities between O-RU and O-DU also translates into a higher degree of interoperability.
Performance is the primary driver of enduser satisfaction; it is what allows CSPs to optimize the utilization of their muchcoveted spectrum resources and lets them move as many bits as possible with as little hardware and energy as possible. After multiple simulations from different companies , the shortcomings of Cat-B on the uplink in a M a ssive MIMO context were eventually acknowledged, and a Work Item, WI, was initiated within O-RAN in February 2022. The initial objective of the WI was to understand whether the uplink performance issue of Cat-B was big enough to justify developing and standardizing a new architecture. It soon became clear that this was the case.
As part of the WI, two proposals were brought forward to improve the Cat-B Massive MIMO uplink performance: DMRSBF- EQ, referred to here as Cat-B ULPI-A and DMRS-BF-NEQ, referred to as Cat-B ULPI-B.
Cat-B ULPI-A and Cat-B ULPI-B: What’s the difference?
The difference between Cat-B ULPI-A and Cat-B ULPI-B, which both address Uplink Performance Improvement, ULPI, is small but significant. The principal difference is that the Cat-B ULPI-A specification places the equalizer function in the O-RU while the Cat-B ULPI-B specification places it in the O-DU. The difference in placement comes with some implications.
The Cat-B ULPI-A configuration places the equalizer function in the O-RU, which solves the original problem of implementing Massive MIMO Radio in Open RAN with existing fronthaul capacity., while also enabling easy multivendor interoperability thanks to a clear separation of concerns between O-RU and O-DU. Indeed, it allows to minimize the fronthaul bitrate by transmitting only the user data layers between the O-RU and the O-DU. At the same time, Cat-B ULPI-A ensures the highest uplink performance and creates a clear separation of responsibilities between O-RU and O-DU, which translates into a higher degree of interoperability. If you place the equalizer in the O-DU, the Channel Estimation needs to be performed in two different places, and it is necessary to ensure good coordination between O-DU and O-RU to get f ull radio performance. It can get tricky to achieve that level of synchronization when channel estimation algorithms come from two different vendors.
Performance improvements with Cat-B ULPI
The uplink performance based on Cat-B ULPI-A shows a clear advantage compared with Cat-B, as shown in the graph figure 5. It shows how Cat-B ULPI supports a higher maximum cell throughput with a lower uplink fronthaul bitrate. The Cat-B ULPI simulation uses on average between 1 and 4 streams while the Cat-B simulation uses 12 streams. Thanks to its better receiver, Cat-B ULPI can handle more simultaneous users/layers. It supports therefore a higher maximum cell throughput and higher user throughput while having a lower uplink fronthaul bitrate by a factor of at least three in comparison to Cat-B.
The agreement on the improved Cat-B fronthaul specifications, Cat-B ULPI, standardized both version A and B and specified clearly how they would work together. Radio unit vendors can implement either Cat-B ULPI-A or Cat-B ULPI-B but, to ensure interoperability, the standard also specifies that the distributed unit should support both version A and version B radio units. Figure 5 shows Cat-B ULPI’s fronthaul architecture options.
Figure 4: Cell throughput and fronthaul bitrate with Cat-B ULPI vs. Cat-B
Higher maximum cell throughput
Thanks to its better receiver, Cat-B ULPI can handle more simultaneous users/layers. This means Cat-B ULPI supports a higher maximum cell throughput and higher user throughput while having a lower uplink fronthaul bitrate.
Factor 3 fronthaul bitrate reduction
The Cat-B ULPI simulation uses on average between 1 and 4 streams and the Cat-B simulation 12 streams. This means an improvement in mean UE throughput by at least a factor 3 lower fronthaul bitrate with Cat-B ULPI in comparison to Cat-B.
Figure 5: Cat-B ULPI fronthaul architecture options
Ericsson’s commitment to Open RAN
Ericsson has and always will be fully committed to delivering the best performance. We are therefore fully committed to implementing the new standard, as it delivers not only performance at scale but the most interoperable eco-system.
Ericsson has, over the last couple of years, embraced Open RAN, supporting key open interfaces and concepts, such as A1 (Interface for policy guidance) and rAPPS. We will extend our support by adding O1 (Interface for operations and maintenance) and Open Fronthaul to both our Cloud RAN and purpose-built RAN portfolio. Specifically regarding the fronthaul interface to the radios, Ericsson initally focused on supporting our existing radio interfaces. Going forward, Ericsson will open up support for these radio interfaces with Open Fronthaul capabilities based on the Cat-A and Cat-B UPLI specifications.
Ericsson, in collaboration with O-RAN alliance members, has been diligently working to update Open Fronthaul specifications towards an enhanced standard, Cat-B ULPI. This enhancement to the Open RAN fronthaul standard ensures optimal uplink performance with the existing fronthaul capacity. This refined standard augments the interoperability between the O-RU and the O-DU, offering more choices to customers in the RAN ecosystem.
These enhancements—ensuring that the performance levels of the fronthaul interface meet our customers’ needs— enable us to incorporate Open RAN fronthaul into our comprehensive, industryleading radio portfolio, facilitating the development of Open RAN on a larger scale.
At Ericsson, our commitment to supporting open fronthaul is steadfast. Initially, we will introduce support for Open RAN fronthaul in our Cloud RAN solution, incorporating it into the Ericsson O-DU. Subsequently, we will enhance our installed base of latest generation Massive MIMO radios, allowing for the integration and upgrade to Open RAN fronthaul. Our purpose-built RAN solution, equipped with Ericsson’s specialized RAN Compute hardware, will fully support Open RAN fronthaul. Furthermore, all future Ericsson radios will also be designed to incorporate Open RAN fronthaul.
As we prepare to introduce support in upcoming radios, a phased approach has been adopted for migrating to open fronthaul within our radio portfolio. Our planned initiatives include the introduction of the Cat-B ULPI-A standard in Massive MIMO radios and the Cat-A standard in Remote Radios. Ericsson will introduce both Cat-A and Cat-B on Cloud RAN, purpose-built RAN, and Radio, with prioritization based on customer demand, starting in 2024. Ericsson’s market-leading Massive MIMO functions will be available in our open fronthaul Cat-B ULPI implementation. Furthermore, we will also apply one common management and orchestration system built on cloud-native principles for the entire portfolio.
Ericsson’s focus has been, is and will continue to be, performance because this is what matters most for our customers and the users of their networks. This is why we put a lot of effort and focus into the O-RAN Alliance standardization work. The creation of the Cat-B ULPI standard, for which Ericsson has been one of the leading forces, reflects this dedication.
Ericsson has long been a major contributor to the O-RAN Alliance work and we will continue to contribute to the standardization and drive the O-RAN ecosystem forward. Cat-B ULPI is a welcome addition as the performance enhancements it enables in Open RAN will likely help accelerate the take-up of Massive MIMO networks and therefore improve end-user experience in dense urban areas.
Figure 6: Open Fronthaul specification update
Glossary
M-MIMO, Massive MIMO, massive Multiple Input, Multiple Output
A combination of a Massive MIMO radio and a set of Massive MIMO features. A Massive MIMO radio consists of an antenna array tightly integrated with the hardware and software required for the transmission and reception of radio signals, and signal processing algorithms to support the execution of the Massive MIMO features.
O-LLS, Open Lower-Layer split: Also known as Open Fronthaul (OFH)
Layer 1, or fronthaul interface, that splits functions between the O-RAN radio unit (O-RU) and the O-RAN distributed unit (O-DU).
Open RAN, Open Radio Access Network
An industry term for open radio access network architecture. It is a RAN that includes open interoperable interfaces and virtualization and is big data and AI-enabled. It is a multi-supplier RAN solution that allows for the separation - or disaggregation - between hardware and software with open interfaces and virtualization, hosting software that controls and updates networks in the cloud.
O-RAN, the O-RAN Alliance
A global industry initiative founded in 2018 that is defining technical specifications for RAN automation, cloudification, and disaggregation. Ericsson is a key contributor to the O-RAN Alliance and has three Work Group/Focus Group co-chair positions. Among the total 289 O-RAN Alliance contributors, only 15 companies have co-chair positions, and only one other than Ericsson, has three.
O-RU, O-RAN radio unit
Radio hardware unit that converts radio signals sent to and from the antenna into a digital signal for transmission over packet networks. The O-RU handles the digital front end (DFE), the lower PHY layer, and the digital beamforming functionality.
O-DU, O-RAN distributed unit
Software usually deployed on site on a COTS server, normally close to the RU on site. The O-DU runs the RLC, MAC, and parts of the PHY layer.
O-CU, O-RAN central unit
A logical node that split into two logical components, one for the Control Plane (CP), and one for the User Plane (UP). The O-CU hosts protocols such as the radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP).