BubbleRAN brings cloud-native software design principles to full fruition in Multi-x, the Open RAN solution for telco networks encompassing the 5G RAN stack and the control, management, and automation domains. The compatibility translation between O-RAN and Multi-x architectures proves the built-in flexibility of the design. In this article, we describe major architectural aspects of Multi-x, how it scales across multiple dimensions, hence Multi-x, and the mapping to the O-RAN base architecture, components, and interfaces.

Background: O-RAN Architecture

O-RAN Alliance is a consortium of several global network operators, equipment vendors, and other entities in the RAN supply chain to define and develop standards for open RAN networks. Taken from the O-RAN Official Documentation, the figure below represents the O-RAN architecture.

Two central concepts, xApps and rApps, software applications in the Near-Real Time RAN Intelligent Controller (RIC), and Non-Real Time RIC, respectively, are the software entities provisioned for access to the RAN nodes to enable management and control of these nodes. We have extended the intelligent control capability beyond RAN and into the Core Network for a truly end-to-end network intelligence which we will discuss in other articles.

Modern Cloud-Native Implementation of O-RAN

Even though O-RAN considers cloud native deployments as its primary implementation, it does not provide precise specifications and limits itself to the concept of O-Cloud. BubbleRAN straddles 5G and Cloud-Native domains and Multi-x is our systematic Cloud-Native implementation of O-Cloud with automation, programmability, and scalability capabilities. The term “x” in Multi-x underlines the following design objectives.

• Architecture: Multi-x system MUST support multiple ISA (x86, ARM) from different vendors and should leverage performance-enhancing intrinsics available in each platform (AVX, SSE, …)
• Vendor: Multi-x architecture MUST NOT impose or introduce ANY new restrictions on interoperability of the components defined in O-RAN across different vendors. This includes ANY newly introduced components and SHOULD remain forward-compatible. Vendors may have different requirements on lifecycle control and configuration, where the Multi-x SMO MUST accommodate.
• Version: Multi-x interoperability MUST remain consistent in the face of different versions or implementations of any given component in the architecture.
• Frequency Band: Simultaneous deployment of multiple frequency configurations MUST be possible in the Multi-x architecture. This includes both 4G and 5G options with both FR1 and FR2.
• Cloud: Multi-x implementation MUST NOT restrict any particular cloud hierarchy, including support for multi-cloud, on-prem, hybrid, and bare metal deployments. Bare metal deployment in this context refers to a deployment where no virtualization layer is utilized in the O-Cloud.
• Containerization: A Multi-x implementation MUST NOT restrict any particular choice of containerization technology (Application Containers, Process Containers, System Containers, Sandbox Containers, Unikernel Containers, Lightweight Virtual Machines, etc.), Container Runtime (containerd, CRI-O, runc, runv, etc.), Container Management (Docker, Podman, Kubernetes, Snap, etc.), or build mechanism (Moby Buildx, Docker Build-kit, buildah, etc.) other than established standards such as OCI, CRI, CNI, or CSI to allow interoperability. This suggests that at any point in time any subset of these choices SHOULD be supported. We limit ourselves to use containerization instead of VMs to improve performance and scalability.
• OS: A Multi-x implementation MUST NOT restrict any particular choice of Linux distribution (Ubuntu 18/20/22, CentOS, RHEL, etc.) neither for the machines nor as the base image for the containers. Simultaneous presence of the OSs in a heterogeneous architecture MUST be possible.

Multi-x is the state-of-the-art cloud-native implantation of O-RAN with further extensions for the 5G core and intelligent RAN control, adhering to the same design philosophy. In the BubbleRAN product portfolio, RIC, and Operators all are Multi-x components by design and all the artifacts and images are designed with Multi-x concept and interoperability in mind.

O-RAN Interfaces Supported in BubbleRAN Solution

The following table summarizes the support of O-RAN interfaces in Multi-x. here a better and more cloud native approach is available, we have taken the liberty to follow it and replace the proposed O-RAN standards. This mainly includes metrics and fault control where Kubernetes, Prometheus, and the rest of cloud native software provide scalable, reliable, and efficient alternatives to O-RAN that are already heavily in use and widely developed for several years. The table does not include F1-C, F1-U, E1, O-FH, and the rest of 3GPP interfaces, since they are presumably already fully supported in the platform, conditioned to the support by the corresponding vendors.

• Supported: The interface is supported.
• Defined: The interface is newly defined and available.
• Replaced: The interface is not supported and is replaced by a cloud native alternative.
• Pending: The interface is not supported yet, , and is in planning phase.

In BubbleRAN’s model, Athena plays the role of SMO Framework in O-RAN and ODIN acts as the Non-Realtime RIC providing all the functions to operate the RAN, Core Network (CN), xApps, rApps, data name networks and service at the edge over a Multi-x O-Cloud. Athena realizes FCAPS (Fault, Configuration, Accounting, Performance, and Security) on top of Kubernetes and supports O-RAN interfaces where applicable, according to the table above. It is developed based on the Kubernetes Operator framework, relies on Kubernetes (K8s) as its container orchestrator or Infrastructure Management Framework in O-RAN and can operate on top of any K8s distribution, including Vanilla Kubernetes, Redhat OpenShift, and OpenSUSE Rancher.

Athena’s functionality can be extended using Operators compliant with the Kubernetes Operator Pattern. Several Operators are shipped with BubbleRAN bundles, alongside the framework to develop 3rd-party Operators. In the figure below, three sets of Operators are visible.

• Athena MX-Operators are to provide the basic functionalities to operate the RAN, CN, Edge, and Network Terminals over a Multi-x O-Cloud. The communication between the Operators follows our newly defined O3 interface that is based on Kubernetes Custom Resource Definitions (CRDs) and APIs. The sidecar Manager that comes with each individual element is the distributed part of Athena and provides configuration, day-2 operations, observability, and micro-decisions amongst its several functionalities. It also implements O1 interface to communicate with O-RAN compliant workloads, while supporting ANY non-standard configuration format through plugins. We use K8s ConfigMaps to provide inputs to the Manager, where it may have references to any external configuration source, including web servers (HTTP/HTTPS/FTP), cloud storages, other ConfigMaps, git repositories, OCI registries, and even local files. Instead of O2, we use the K8s APIs to talk with the cloud infrastructure.
• High-level Operators such as Optimization Operator and Slice Operator are examples of higher level Operators that are shipped with BubbleRAN solutions. They rely on Athena for basic functionalities and to build complex logics on top. The 3rd party Operators would be placed in the same logical level and can access peer Operators through the O3 interface. The K8s RBAC rules are applied on O3 to provide access control. Other examples include 3GPP slice controller and scheduler Operators. Refer to our blog post on the Operator Plane for more details.
• Odin NonRT RIC Operator is a specialized Operator to provide RIC functions. It is able to communicate with other Operators via O3 and request deployment of xApps to Athena, based on the declarative CRDs that it provides. Several basic services such as Monitoring or SliceSetControl are implemented in this way and could be consumed by any other Operator or the user. For the sake of forward-compatibility and alignment with O-RAN, it also provides generic CRDs for A1Query and A1Request to discover and request A1 functionalities by the rApps which are either onboarded as other Operators or external components in O-RAN style. Odin implements an extended and cloud native adaptation of A1 interface to communicate with the RIC. Any xApps may also be requested for deployment from Odin.

In Athena, each of the components of RAN or CN are deployed as containers with a sidecar Management container to perform lifecycle control mechanisms for day-2 to day-n, provide extensive observability including custom metrics, and open configuration models. As a result, no restriction is placed on the format of the configuration that the component should implement, whether 3GPP suggested YANG models or any other format. The Manager provides O1-CM plugin for configuring O-RAN compliant components but implements fault management and performance metrics in a cloud native manner (i.e. based on K8s APIs), incompatible with the O-RAN standard. There are several significant drawbacks in O-RAN O1-FM and O1-PM including performance concerns, inability to scale horizontally, and inefficiency in the resource and energy consumption. Fault management is completely automated in Athena and there is no need for manual intervention, while the human operator would be informed through Events, Conditions, and Alarms about what is going on in the system. The performance metrics are collected by Prometheus (mainly) and exposed in a unified manner.

Athena Managers may possibly be extended with plugins to support advanced configuration models that have day-2 implications, for instance, reconfiguring a component without restarting the application or container. Also, any traditional monitoring systems could be performed through observation plugins in the Manager. In that sense, the Manager could consume O1-PM metrics and provide them to Prometheus, where applicable.

Conclusion

BubbleRAN’s Multi-x solution addresses the gaps and challenges of realizing Open RAN to its full potential. With bubbleRAN Multi-x, you’re one click away from one x in multi-x to another one (one deployment to another, one vendor to another). The compatibility translation between O-RAN and Multi-x architectures proves the built-in flexibility of the design, while maintaining all the other features and capabilities outside the scope of Open RAN, such as high performance, flexibility, automation, observability, security, consistency, and scalability.

Any questions?

Contact us and let’s discuss Multi-x capabilities. Learn more about our products