O-RAN evolution

The O-RAN is an idea for fully interoperable radio access networks with interface standards meant to transform the RAN industry toward open, intelligent, virtualized, and fully interoperable RAN. O-RAN specifications are driven by the O-RAN alliance, which was founded in 2018 and has become a world-wide operator and vendor community, with 237 mobile network operators and equipment providers as of 2020. The O-RAN alliance is actively working on the standardization of open interfaces, the development of open software including the 3rd Generation Partnership Project (3GPP) protocol stacks, and the testing and integration to support O-RAN member companies to build O-RAN-based 5G networks.

Compared to the 3GPP standard interfaces and architecture, the O-RAN alliance focuses on a disaggregated and fully interoperable RAN architecture. Regarding RAN interface standardization, the 3GPP mainly develops the interface between the mobile and the network node, which is the eNodeB in long-term evolution (LTE) or the gNodeB in 3GPP New Radio technology (NR) and the inter-network node interface. The network node, the eNodeB or gNodeB, has several layers of the 3GPP protocol stacks, but has been working as a monolithic network entity that provides all the radio access services.

The node has components such as the radio unit (RU) and the DU, but they are vendor-specific and connected over proprietary interfaces so that wireless network operators must purchase a whole entity from a single vendor. The O-RAN, however, pursues a goal to have a fully operational and interoperable architecture for RAN, with hardware and software from different vendors. The O-RAN provides an architecture as a foundation of the virtualized and disaggregated RAN on open hardware and cloud. The O-RAN specifications define the interoperable interfaces which fully support the O-RAN open architecture, and complement the 3GPP standards.

This chapter provides the overview of the O-RAN architecture, which consists of the 3GPP-defined RAN components such as the CU, the DU, and the RU, and the O-RAN specific components, such as the RIC and the O-Cloud. The functionality of each component and its interfaces are explained in depth. The last part of this chapter describes layer decoupling, which is the main concept of the O-RAN, and presents flexible deployment options to enable wireless network operators to evolve their networks to meet the demands of end customers.

O-RAN architecture

The O-RAN architecture comprises nine network components and 19 inter-component interfaces. The architecture is based on the 3GPP RAN specifications, and has additional components and interfaces. The following figure shows the entire O-RAN architecture.

O-RAN architecture

The O-CU, the O-DU, and the O-RU extend the corresponding entities defined as the CU, the DU, and the RU in the 3GPP specifications. Providing the 3GPP features and interfaces, they are fully compliant with the 3GPP standards. In addition, they have O-RAN features, including E2 and O1 interfaces, to enhance RAN management and automation and to enable AI/ML-powered RAN optimization. Furthermore, the O-RAN provides a fully open and interoperable fronthaul interface between the O-DU and O-RU. While the legacy fronthaul interface standard, Common Public Radio Interface ( CPRI), needs vendor-specific information to operate, this open fronthaul interface provides full interoperability with the O-DU and O-RU from different RAN vendors to help network operators formulate true multi-vendor strategies.

Besides the O-CU, O-DU, and O-RU, the architecture has three more entities:

• The O-Cloud, or the infrastructure, including server hardware and networks, which is the fundamental layer where all O-RAN functions run.

• The Service Management and Orchestration (SMO) framework, which is a consolidation of a wide variety of management services that provide many network management-like functionalities. In an operator’s network, the SMO may provide management services that go well beyond RAN management, and can include features such as core network management, transport management, and end-to-end network slice management. The Open Network Automation Platform (ONAP) project is one example of the SMO.

• The RIC (non-real-time and near-real-time RICs) is newly introduced by the O-RAN to control radio resources and improve RAN performance by mobility management, admission control, and interference management. Basically, the RIC uses SMO services such as data collection and provisioning of the O-RAN components. The RIC uses data analytics and AI/ML training and inference to determine RAN optimization actions. The RIC further controls and steers the O-CU and the O-DU via quality of service (QoS) policies. With fine-grained data collection and action reports from the O-CU and O-DU, the RIC sends QoS policies to them to allocate radio resources in a more accurate way, and to provide better end user experience.

  The RIC consists of two components: the non-real-time RIC (non-RT RIC) and near-real-time RIC (near-RT RIC). The non-RT RIC supports intelligent RAN optimization by providing policy-based guidance, ML model management, and enrichment information to the near-RT RIC, so the RAN can optimize radio resources. The non-RT RIC creates an inference model from ML training and the near-RT RIC performs RAN optimization actions based on the model. The near-RT RIC controls the O-CU and the O-DU, which allocate resources based on the policies from the near-RT RIC.

The O-RAN also defines interfaces among the O-RAN components.

• First, the E1 and F1, fully compliant with the corresponding 3GPP interface specifications, connect the O-CU Control Plane (CP) and O-CU User Plane (UP), and link the O-CU and the O-DU.

• Second, to support inter-RAN handover and core network communication, the O-RAN defines the X2, Xn, S1, and NG interfaces, which comply with the 3GPP specifications.

• Third, the open fronthaul interface between the O-DU and the O-RU is defined with the control, user, management, and synchronization planes, and comes along with the O-RAN interoperability test specifications.

The O-RAN open fronthaul specification provides wireless network operators the huge advantage of multiple RAN vendors. Regarding the function partitioning of the O-DU and the O-RU, several options were investigated to meet different implementation requirements. One option is to break the RAN physical layer into an upper and lower layer to minimize the required fronthaul bandwidth and transmission latency to the O-RU. The O-RAN chooses the split option 7-2x to support 5G features and frequency bands. Option 7-2x is a part of Option seven, where the physical layer functions up to RE mapping are implemented in the O-DU; the O-RU implements digital beamforming and all the later functions in the downlink. This split option requires fairly reasonable bandwidth and latency, compared to other split options.

Fronthaul split options

The O1, A1, and E2 interfaces are newly introduced in the O-RAN architecture. The O1 interface connects the SMO and the O-RAN components for component management. As all the components expose an O1 interface to the SMO, the SMO directly manages each O-RAN component, called a managed element, in the O-RAN OAM architecture. Working together with the O-Cloud, the SMO provides the entire management services through the O1 interface, which implements instance provisioning, fault supervision, performance assurance, tracing, software version management, and communication surveillance.

The O1 interface further supports non-virtualized elements or physical network elements. To support legacy RUs, the O-RAN OAM architecture allows two management interfaces, so that the RUs can be managed by the O-DU and by the SMO. In this case, the O-DU configures the O-RU and optimizes the operating parameters for a reliable and low-delay connection. The SMO manages the O-RU through the O1 interface, and provides generic component management services including provisioning, fault supervising, and software management.

The A1 and E2 interfaces are used for the RIC functionality. The RIC, as described in the previous section, is a new network component to achieve radio resource and mobility optimization by using AI/ML technologies. For RAN radio resource control, there are three control loops with different latency bands in the O-RAN architecture. The first loop is a closed loop with the O-DU and the UE for immediate radio resource requests and allocations. The second loop is formed with the O-DU and the near-RT RIC. The near-RT RIC provides interactive allocation policies as a function of the current resource allocation status, the user experience and service quality, and the management policy from the non-RT RIC.

The Non-RT RIC is the controller of the last loop, and supplies resource policies and AI/ML trained models to the near-RT RIC by exploiting the gathered statistics and the existing configurations. Although the timing of these control loops is use-case dependent, it is expected that the typical run time in the non-RT RIC control loop is one second or more, the near-RT RIC control loop has a use-case run time of ten milliseconds (ms) to one second, and the last O-DU scheduler loop operates below ten ms. These control loops and their run times over the A1 and E2 interfaces should be considered when the O-RAN components are deployed.

O-RAN management and infrastructure components

The SMO is a consolidation of a wide variety of management services for the wireless network operator. The SMO may provide management services for not only RAN but also core and transport networks to enable the establishment of end-to-end network slices and the automated management of the entire network. For the O-RAN components, the SMO performs the fault, configuration, accounting, performance, and security management. The SMO includes the non-RT RIC services for RAN optimization, and manages the infrastructure through the O2 interface with orchestration and workflow management services.

The ONAP is one of the SMO solutions. Hosted by the Linux Foundation, the ONAP has been implemented in collaboration of the O-RAN and ONAP communities. The ONAP release has aligned with the O-RAN specifications and provides managed services for the O-RAN. The ONAP further contains the non-RT RIC to support the RIC functionalities. The O-RAN Software Community, supported and funded by Linux Foundation and O-RAN, is also developing non-RT RIC features, as well as near-RT RIC and use cases.

The last new component of the O-RAN architecture is the O-Cloud. The O-Cloud manages physical resources like servers, networks, and storages, and hosts the relevant O-RAN functions. The O-Cloud exposes the O2 interface to the SMO, which provides secured communication and enables the SMO to manage the infrastructure and the life cycle of O-RAN network functions. The O2 interface is independent of specific infrastructure implementations in order to work with multiple clouds and bring a multi-vendor environment to wireless network operators.

The O-Cloud should provide physical or logical infrastructure resources and perform workload management for O-RAN network functions. The service of the O-Cloud includes resource discovery and administration, network function provisioning, network function Fault, Configuration, Accounting, Performance, and Security (FCAPS), and software life cycle management. These services are further divided into two classes:

• The infrastructure management.

• The network function deployment.

The Infrastructure Management Services (IMS) communicates with the entity of the SMO, called the Federated O-Cloud Orchestration and Management (FOCOM). The sub-interface between them is defined as the O2-M interface. The second service class, the network function deployment, works with the Network Function Orchestrator (NFO) of the SMO via the O2-D sub-interface.

The IMS is responsible for physical resource allocation based on the request from the SMO and resource tracking and management. The IMS builds physical and logical inventories and shares them with the SMO through the O2-M interface. The SMO receives the inventory information from the IMS, updates its inventory accordingly, and makes a request to allocate a resource based on the inventory updates. The IMS also provisions infrastructure resources and flexibly matches the resource demands of the O-RAN network functions.

This elastic and flexible resource provisioning brings benefits, including agility, scalability, and cost saving. The Deployment Management Services perform deployment lifecycle management. The DMS deploys O-RAN network functions on the assigned resources of the infrastructure. The DMS scales up and down according to the demand of the network function. The DMS also monitors the status of network functions, and performs a proper recovery scheme if a network function is out of service.

To monitor the network functions, the O-RAN defines three types of telemetry data:

• Managed element telemetry.

• Deployment telemetry.

• Infrastructure telemetry.

Managed element telemetry is related to the network function status and collected via the O1 interface. Deployment telemetry monitors the deployed resource status, including CPU, network, and memory usage. It also monitors the ongoing deployment. Infrastructure telemetry monitors the health of the infrastructure components. For example, the telemetry data includes the capacity and resource utilization of the infrastructure. Deployment and infrastructure telemetry data is collected via the O2 interface.

Infrastructure decoupling and deployment flexibility in O-RAN

O-RAN pursues the complete openness in the RAN architecture. The interfaces among the O-RAN components are fully open. For example, the open fronthaul interface between the O-DU and the O-RU has complete functionality and interoperability. All other O-RAN interfaces develop openness with full functional features. From the perspective of infrastructure, O-RAN decouples the infrastructure and O-RAN network functions in pursuit of true network function virtualization as O-RAN defines three layers:

• The hardware layer.

• The middle layer.

• The top layer.

The hardware layer includes server blade and sled, network switches, storages, and so on. The middle layer or cloud stack consists of operating systems, cloud management software, and container or VM management software. The middle layer also includes the accelerator abstraction layer to enable the top layer to exploit accelerators for task offloading and high performance. The top layer comprises the O-RAN network function applications for the O-CU and O-DU.

The infrastructure, or O-Cloud, has the first two layers: the hardware layer and the middle layer. The O-Cloud is a set of hardware and software to provide cloud computing capabilities to host and run O-RAN network functions. The O-Cloud includes compute, networking, and storage components, and also provides specific hardware and software functions such as RAN physical layer accelerators and encryption/decryption accelerators. The O-Cloud may have sub-processors such as SoCs, GPUs, and Field-Programmable Gate Arrays (FPGAs) to enhance complex computations required in the RAN. The O-Cloud manages the hardware and software that belongs to the hardware and middle layers, and exposes the O2 interface and open APIs to the SMO and the O-RAN network functions. The interfaces between the O-Cloud and the O-RAN network functions are open APIs driven by open-source communities such as Kubernetes and Linux.

The hardware layer of the O-Cloud may have the O-Cloud Compute fabric with a collection of physical servers, or the O-Cloud Nodes, and the O-Cloud switch fabric with leaf and spine switches. The O-Cloud Nodes have hardware components such as CPUs, memory, storage, network interfaces, and accelerators. The switch fabric provides connectivity to other O-RAN components like the O-CU and the O-RU. The switch fabric also can be connected to the regional O-Cloud and the time source for GPS synchronization. The diagram from the O-RAN Cloud Architecture specification (O-RAN.WG6.CAD-v02.01) depicts this concept:

O-RAN/O-Cloud function decoupling

The software components of the O-Cloud include the Infrastructure Management Services (IMS) or Deployment Management Services (DMS), which work with the SMO for resource provisioning and function deployment. The O-Cloud also has lifecycle management of O-RAN network functions. Amazon Elastic Kubernetes Service (Amazon EKS) is a good choice to manage the O-RAN network functions. Amazon EKS is a managed Kubernetes control plane service that makes it easy to deploy, manage, and scale containerized applications. Amazon EKS runs native upstream Kubernetes, and is certified to be Kubernetes conformant. Applications running on Amazon EKS are fully compatible with applications running on any standard Kubernetes environment, whether running in on-premises data centers or public or private clouds. In collaboration of Amazon EKS, continuous integration and continuous delivery (CI/CD) pipelines can build automated lifecycle management. This whitepaper discusses lifecycle management in the next chapter.

With infrastructure management and resources, the O-Cloud provides multiple locations of service from cell sites to edge and regional clouds, and flexible deployment options to operators. In 5G networks, ultra-low latency is the key enabler for new services such as autonomous car driving, robot control, virtual reality, and augmented reality. Depending on the latency requirements of the service, the operator deploys O-RAN network functions to the place with the required latency. The O-DU can be either in cell sites or edge clouds, if the edge cloud meets the requirement of transmission latency or distance to the O-RU.

Centralization of the O-DU brings benefits to the wireless network operators in terms of capital expenditures (CAPEX) and operating expenses (OPEX). This centralization enables cluster placement of the O-DU to provide not only pooling of resources, but also easy maintenance and management. Edge clouds further host the O-CU and the user plane function of the core network or user plane function (UPF) to reduce the end-to-end latency to a few milliseconds. If even lower latency is required, the O-DU, O-CU, and UPF can sit in the cell site and provide low round-trip latency of less than one or two ms, as 3GPP and ITU-T defines Ultra-Reliable Low-Latency 5G for Industrial Automation.

AWS provides multiple solutions regarding O-RAN component deployment and open interfaces. The AWS Cloud is the most secure, extensive, and reliable cloud platform, offering over 200 fully-featured services from data centers globally. In addition, AWS Local Zones provide low-latency edge cloud services to allow for single-digit millisecond latency services for end users. AWS also has Amazon EC2 as a compute service, suitable for the O-DU of cell sites, so that operators can have the same experience from the AWS Cloud and a single pane of glass to manage all the infrastructure. The next chapter shows AWS functionalities and components for O-RAN operation on the AWS cloud.