The importance of O-RAN Open Fronthaul Specification
If we are to believe certain prominent wireless vendors, the idea of opening up the radio access network (RAN) is novel and untested. They say open networking in the RAN won’t be ready for hardened commercial use for another five to ten years. They warn that to safeguard the business, Mobile Network Operators (MNOs) should stick with proprietary RAN technologies for at least the next five years and dip their toes into the open networking waters with small pilot projects that can’t hurt broader network operations. These vendors might even provide an open Software Developer Kit (SDK) that allows operators to toy around with new service development in a sandbox, effectively relegating open networking projects to a sanitized lab where operators or their customers can’t benefit directly.
Open and programmable networking isn’t new
Open and programmable networks have been at the heart of wired network transformation for the last fifteen years. In the Fujitsu optical transport business, we’ve worked with customers and their Software-Defined Networking (SDN) and Network Function Virtualization (NFV) projects for over a decade. In 2015 we launched the Virtuora Network Control Solution that uses SDN/NFV and several open technologies.
Not only has the industry been at this for a quite a while, but Fujitsu open networking solutions have been in production networks for many years.
Over in 5G transport preparations, looming bandwidth problems in 4G LTE and 5G fronthaul were addressed by advances in centralized architecture and software with evolved cloud RAN architecture that exploded onto the wireless business scene in 2016 at Mobile World Congress. 5G techniques like flexible slot-based frameworks, a scalable OFDM air interface, advanced channel coding, and massive MIMO, began to gain real market traction. Major wireless operators all over the world joined forces to launch the xRAN Forum in 2016.
Two years later, the xRAN Forum merged with the C-RAN Alliance to form The O-RAN Alliance. The xRAN Fronthaul Specification 1.0 was released the following April. All of this was over five years ago. Today, the O-RAN Alliance includes over thirty operators and hundreds of vendors all over the world. A technical steering committee (made up of wireless professionals) supervises eleven working groups with even more wireless professionals that spans the entire O-RAN architecture. In the case of O-RAN Application Programming Interface (APIs), Working Group 4 (WG4), the Open Fronthaul Interfaces workgroup continuously publishes specifications that address control, user, synchronization, the management plane, YANG models, interoperability, and testing specifications for the fronthaul interface. WG5 does the same for IOT.
O-RAN specifications are ready for production networks
My colleague Rob Hughes believes that RAN resource dedication and market timing have enough inertia and inevitability for open networking capabilities to create real industry disruption right now. We’ve written many blogs and articles on O-RAN and our O-RAN partnerships. The remainder of this blog will expand on those ideas and create context for O-RAN Open Fronthaul and complementary application interfaces like 3GPP F1.
The O-RAN Fronthaul Specification and the gNB
The O-RAN Fronthaul Specification defines how the traditional black box cell site can be disaggregated and virtualized for optimal fronthaul/midhaul/backhaul capacity, speed, and latency in next-generation cellular networks. The specification defines a disaggregated and virtualized gNB (next generation node B) using the 3GPP 7.2x functional split, which splits the physical layer (PHY) into PHY-high and PHY-low.
The O-RAN functional split describes one or more physical radio units (RUs) at the cell site, and a virtualized central unit (CU) and distributed unit (DU) running on white box servers at the edge, in either a central office or a cloud. Traditional RAN black boxes at the cell site have a radio frequency (RF) block, a physical (PHY) block, and four other entities that form the RAN protocol stack:
- Medium Access Control (MAC)
- Packet Data Convergence Protocol (PDCP)
- Radio Link Control (RLC)
- Service Data Adaptation Protocol (SDAP)
Disaggregated and virtualized gNB
The O-RAN Fronthaul Specification details how to disaggregate and partially virtualize the RAN protocol stack, dividing capabilities between a physical cell site and a virtual gNB. The physical (PHY) block of the traditional cell site is split into “low” and “high” capabilities, with PHY-low capabilities residing on the RU and the PHY-high capabilities installed on a virtual DU. Upper layers of the NG RAN protocol stack are processed by a virtual CU.
- The RU contains radio frequency (RF) and PHY-low capabilities and resides at the cell site. The RU performs orthogonal frequency division multiplexing (OFDM) phase compensation, downlink inverse FFT and CP insertion for frequency-to-time conversion, and uplink FFT and CP removal. It also provides beamforming and Analog/Digital Conversion (DAC/ADC). There are two types of RUs: Category A and Category B. Category A RUs are a good fit for low frequency and latency-insensitive services. Category B RUs provide MIMO precoding protocols that supports null steering and spatial multiplexing. RU/DU is considered the fronthaul segment of the network.
- The DU is software that provides PHY-high capabilities. It includes precoding, the layer map, modulation, scrambling, and Resource Element mapping (RE mapping). It also provides Radio Link Control (RLC) and Media Access Control (MAC) protocols. The DU resides on a server in an edge data center, central office, or cloud. DU/CU is considered the midhaul segment of the network.
- The CU is software that provides processing for Packet Data Convergence (PDCP), Service Data Adaptation (SDAP), and Radio Resource Control (RRC). It resides on a server in an edge data center, central office, or the cloud, and can be co-located with the DU, but it doesn’t have to be. The CU is connected to the 5G core, which is considered the backhaul segment of the network.
These components form a single disaggregated system for a gNB, spanning the xHaul network segments.
All O-RAN compliant components are “open-open”, meaning that their interfaces are open and they use O-RAN-defined standard application programming interfaces.
A vendor can legitimately claim to be open if they expose their interfaces. However, if their open interfaces do not use open standards, DevOps must use a proprietary Software Development Kit (SDK) to create new services that connect and integrate components from individual vendors. Imagine a 5G multivendor network with 100 vendors whose interfaces are open, but not standard. DevOps would need basic knowledge of 100 different SDKs to connect components for a single network service that used all the available components. They would need a mastery of those 100 SDKs to integrate those components and maintain a single vendor’s capabilities and advantages.
It certainly can be done with metric tons of radio engineers and software development teams, but what if there’s a better way?
The F1 interface and O-RAN Open Fronthaul
Real-time information powered by Artificial Intelligence (AI) and Machine Learning (ML) enables more granular control, automation, and deployment optimization in the NG RAN, which reduces downtime while increasing customer satisfaction and revenue. Open interfaces are needed to surface multivendor telemetry and data analytics to make them useful to AI/ML. The O-RAN Software Community (SC) SDK enables open interface integrations in an NG RAN that leverages the O-RAN architecture.
The O-RAN Fronthaul Specification complements the 3GPP intra-RAN F1 interface. The F1 interface connects a CU to one or more DUs of a disaggregated gNB. This API enables the functional split of the PHY-low and PHY-high blocks between the RU and DU and, in some configurations, allows the DU to control the RU. O-RAN Fronthaul protocols allows one DU to control RUs in the same cell but owned by multiple carriers.
O-RAN Open Fronthaul command planes
In addition to providing connections and capabilities, the Open Fronthaul (FH) command planes deliver minimal jitter for communications between DUs and RUs that match the requirements of Ultra-Reliable Low Latency Communications (URLLC). This is critical to advanced networking capabilities like dynamic network slicing. O-RAN Open Fronthaul includes:
- Control Plane (CP): the CP is used to issue commands for scheduling, beam forming, and coordinating data transfers, by using Ethernet L1 & 2, VPN, IP, UDP, and CPRI/ROE protocols. The CP sits on the CU and connects to the CU-UP via the E1 interface, and to the DU via the F1-c interface.
- User Plane (UP): the UP transfers I/Q data between DU and RU within strict time constraints. The UP sits on the CU and is connected to the DU via the F1-u interface.
- Synchronization plane: the S-plane handles time, frequency, and synchronization between the DU and RU. S-plane synchronization uses PTP/SyncE with Ethernet L1 and L2 protocols.
- Management plane: The M-plane uses Ethernet L1 and 2, VPN, IP, TCP, SSH, and NETCONF protocols. It is installed on the RU and the DU. The M-plane connects the gNB to the Service Management and Orchestration (SMO) framework, which manages the RUs and DUs hierarchically or in a hybrid mode.
By now, it’s obvious that the only way to effectively operate and contain costs in a next generation cellular network is to implement automation and management that extends deep into the RAN. It also requires careful planning to ensure that the transport network will provide sufficient capacity and performance as the 5G+ network grows. Check out my colleague Joe Mocerino’s blog, 5G Transport Toolbox For Centralized RAN, to see how to build a transport ecosystem that minimizes the time and operational costs of building out reliable 5G transport.
The next blog in this series on open RAN software and APIs will discuss how the O-RAN SMO framework orchestrates and operates all these pieces efficiently, where it keeps all the data it collects, and how it uses that data to inform and optimize network automation. Until then, watch this video with David Allabaugh to learn how we can unwind RAN complexity with Service Management & Orchestration.