O-RAN democratizes RAN infrastructure into composable hardware and software that encourages more market participation. Sriram Rajagopal, head of systems engineering, EdgeQ, provides a technical deep-dive into the aspects of the critical interface of O-RAN, the front haul, and how it operates.
Amongst the backdrop of 5G, Open RAN (O-RAN) has sparked a crucial conversation.O-RAN democratizes RAN infrastructure into composable hardware and software that encourages more market participation across the entire ecosystem. Indeed, 5G deployments are moving to software-centric architectures to support the different requirements.
This article will provide a technical deep-dive into the aspects of the critical interface of O-RAN, the front haul, and how it operates.
Various industry consortiums, such as the Open RAN Alliance, are defining the different network architectures and the components that comprise them, such as Radio Units (RU), Distributed Units (DU), and Central Units (CU), which have defined interfaces. One of the key interfaces is the fronthaul, which connects the RU to the DU.
O-RAN specifies the Low-Level Split (LLS) architecture for the physical layer in the frequency domain between the RU and the DU. This is a frequency domain interface and helps to reduce the traffic load on the front haul. For massive multiple-input, multiple-output systems (also known as (massive MIMO systems), the interface helps reduce the load on the front haul, as it would have scaled with the number of antennas in the system if it were in the time domain. With the LLS front haul split, this scales only with the number of spatial streams designed for the system, such as 2 or 4 for a non-massive system to 16 or so streams for a massive MIMO system. For example, by doubling the data streams from 4 to 8, you also double the fronthaul throughput. This increase is coming from the front haul having to manage control information of beamforming. Instead, using a time-domain interface per antenna, the front haul becomes 8X and would keep scaling with the number of antennas.
Learn More: How Industry 4.0 and 5G Will Transform Supply Chain Visibility
O-RAN Frequency Representation
The LLS FrontHaul is defined with a protocol called eCPRI, which is a frequency domain enhancement over the Common Public Radio Interface (CPRI). The transport mechanism can be Ethernet with IP/UDP encapsulation. eCPRI headers and data content are the payload in these ethernet frames.
There are four main messages for the eCPRI protocol: Control (or C-plane), UserData (or U-plane), Synchronization (or S-plane) and a separate mechanism for management called the M-plane. Since the LLS split is in the frequency domain, the interface is defined on the basis of resource blocks (RB) or 12 tones and symbols.
As the fundamental structures, data sections identify portions of symbols and portions of resource blocks. The C-plane identifies these data sections and sends a message from the DU to the RU with the data section descriptions and how the RU will process them. The data itself is sent on the U-plane. A typical RB (shown below) reserves some tones for Common Reference signals, some for CSI-RS, some for control, and some for user data.
O-RAN Data Sections
Each of these signals would have some characteristics that separates them. For example, different beams for different kinds of data – Cell Reference Signals (or CRS) need to be sent to all users in the coverage area and hence would need a broad beam. Similarly, the Channel State Information – Reference Signals (CSI-RS) or User Control (PDCCH) may use broad beams, but of different characteristics such as focusing beam on specific elevation.
Hence, data sections are created that have similar characteristics, patterns, or behaviors. They are numbered by the section ID, which is essentially a label for blocks of data that will be processed in RUs. Since the control region would have similar transmission characteristics, they can be clubbed into a single data section.
Subsequent symbols may require different data sections for different user allocations over these symbols. Symbol 3 does not have any Reference signals, but the beamforming applied to user 1 and user 2 may be different, and hence, different sections would need to be defined. Data sections are sent from the DU to RU in order of symbols – so section 2, then 9, then 3, then A, and so on.
Resource Element (RE or individual frequency tones) mask tells which tones in the RB has a beamforming pattern to be applied. Section 3 has a RE pattern for data – as 011011 – so beamforming weight is applied on the tones 1,2,4,5, etc., skipping over the tones 0,3,6, etc. A complementary mask of 100100 are used for cell reference/CSI-RS and are applied a different beamforming. If a particular C-plane is not received, the RU assumes it must send null messages. Since the DU determines the RU’s behavior for downlink and uplink, the C-plane describes the data section for both directions.
The C-plane messages have a few predefined components – Transport Headers, Application Headers, Section headers and extensions. The transport header defines it as an eCPRI packet for a particular RU and stream. The application header describes the overall IQ data region in terms of symbols and RBs. The data sections within this are described in section headers identified by the section ID
The data in the U-plane would not be sent in full precision, which can vary from DU and RU implementations, but instead is sent in a compressed format. A commonly used format is block floating, which compresses data based on a common exponent over a set of 12 tones of an RB. The parameters for this compression are also described for both DL and UL in the C-plane.Â
Learn More: A Safety Net for 5G and Edge: How OOB Network Management Helps Create More Resilient Networks
O-RAN Beamforming Types
Each section ID has beamforming definitions. There are a few methods for beamforming that are supported in O-RAN:
So, when are C-plane and U-plane messages sent from DU to RU? The C-plane defines the data sections for the complete slot and is required by the RU before over-the-air operation of the symbols. Because of this, the DU sends the C-plane message ahead of the slot to the RU. Then subsequent U-plane messages for the corresponding data sections of every symbol are sent serially over time, over the slot, one symbol at the time.Â
Synchronized Telecom Networks need to maintain “over-the-air-timing†at the antennas for every RU. The synchronization can be achieved in several ways. They all use the Precision Timing Protocol (PTP) ITU 8275.1 standard to transfer timing across the network. For direct connections between the DU and RU, the DU obtains timing and acts as a Grand Master of timing for the RU. The DU could have obtained timing from any source, GNSS or PTP. The next configuration is like the first, with multiple switching hops supporting boundary clocks between the DU and RU. In the third option, both RU and DU obtain timing from a Grand Master in the network.
O-RAN Delay Management Model
A front haul interface has multiple variations and is neither synchronous nor perfect. Delay management refers to the practice of DU and RU sending and receiving information at the correct time. This moment is determined by the processing time and the received buffer memory at the DU and RU, as well as by transport delays. O-RAN does not specify the timing or constraints for these, but it does specify how to send and receive based on these factors.
For downlink, there is a specific time when data must be transmitted from the RU. Each RU has fixed processing time and memory for storing incoming packets on the fronthaul. Working backward, the DU must send packets sufficiently ahead of time to allow for network latency, jitter and processing at the RU. However, the DU should not send this information too early in order to avoid the overflow of buffers in the RU. For uplink, there is no strict timing requirement. But after the RU has done its processing, the data packets should be sent early enough so that the DU can close HARQ loops and other processing timing restrictions imposed by higher layers.Â
Not all U-plane data is delay managed. Depending on the content, some of this data is sent immediately and is identified by its stream identities. It may be acceptable to send and receive IQ data with priority in a timely fashion, but for some data, like large volumes of data that comprises a sounding channel, can be sent interspersed over a longer duration to keep the throughput low. In this case, there is no processing timing restrictions.
Learn More: Network Disaggregation Offers Key Benefits to Mobile Operators as 5G Rolls Out
Conclusion
U.S. network operators and telecom vendors overwhelmingly support O-RAN efforts – and understand why and how open, disaggregated, more programmable 5G networks will stimulate greater modularity, end-user innovations, and unprecedented elasticity and fluidity to network design and deployment for the trillions of devices. The softwarization of the network coupled with an open virtualized RAN provides the fertile framework for innovation and architectural re-think at silicon level.
The cellular ecosystem is still fairly fragmented and conventional today. O-RAN solutions will make it possible to scale 5G solutions with efficiency, intelligence, and versatility across a broader swath of hardware and software providers. It will also provide opportunities to lower the barrier to entry for 5G and network reconstitution at the edge. Indeed, O-RAN is a critical space to keep an eye on over the next few years. In fact, according to analyst firm Dell’Oro Group, O-RAN revenues will approach $10B over the 2020-2025 forecast period, which includes hardware, software, and firmware excluding services.
Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.