BubbleRAN brings Cloud-Native Open RAN as the solution for the future telco ecosystem, delivering sustainable and automated networks with minimal cost. Towards this mindset, we coined the term Multi-x to naturally extend the core concepts of Open RAN to other domains of interest, particularly to the Core Network (CN) and the Management and Orchestration (MANO). MANO is otherwise known as Service Manager and Orchestrator (SMO) or Orchestration and Management (O&M) in the O-RAN context. In this article, we partly review Open RAN architecture and redefine the aspects of multi-x. Later on, we project our model into Open RAN architecture, specifically discussing O1 and A1 interfaces, alongside xApps and rApps.

Background: O-RAN Architecture

O-RAN Alliance is a consortium formed of several network operators around the world to move towards standardization of an Open RAN architecture. Taken from the O-RAN Official Documentation, the figure below represents the O-RAN architecture.

Additionally, to the concepts shown in this figure, one should consider xApps and rApps, where both are external applications that could request from the RAN Intelligent Controller (RIC) to perform specific tasks. The former communicates with Near-RT RIC, while the latter communicates with Non-RT RIC.

One could mirror a similar architecture for the Core Network (CN), where the RIC becomes CN Intelligent Controller (CIC), responsible for performing control operations on the CN. Let us call this non-standard architecture O-CN. In this perspective, one could merge Non-RT RIC and Non-RT CIC into a single entity, hence rApps could issue E2E operations too.

Multi-x: The Natural Extension of Open RAN

Even though the O-RAN architectural transformation considers cloud native deployments as its primal implementation, it does not provide detailed standardization and simply represents it as O-Cloud.

Since BubbleRAN expertise resides at the union of 5G and the cloud, we have immediately recognized the missing challenges and demystified the O-Cloud architecture, offering a unique combination of automation, programmability, scalability, and performance to enable network providers to innovate in this frontier. Encapsulating the mindset of Openness in RAN (O-RAN) and CN (O-CN), we introduced Multi-x.

As a short list, the term “x” in Multi-x could stand for any of the following:

• Vendor: A multi-x architecture MUST NOT impose or introduce ANY new restrictions on interoperability of the components defined in O-RAN and O-CN, 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 a multi-x MANO/SMO MUST respect.
• Version: The multi-x interoperability MUST remain consistent alongside different versions or implementations of any particular component in the architecture.
• RF: Simultaneous deployment of multiple Radio Frontends (RF) MUST be possible in a multi-x architecture. This includes both 4G and 5G options with both FR1 and FR2.
• Cloud: A multi-x implementation MUST NOT restrict any particular choice of cloud provider, including support for simultaneous deployments of multiple cloud providers, support for on-premise deployments, and full support for bare metal deployments. Bare metal deployment in this context refers to a deployment where no virtualization layer sits between the application and the physical machine.
• 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 SIMULTANEOUSLY. We strictly 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.
• Intrinsically, a multi-x solution should also support multi-machine and multi-instance deployments to ensure scalability and availability.

Multi-x is the natural extension of Open RAN mindset into other domains of interest, and we expect it would gain the same momentum and popularity in the community as Open RAN, since it addresses the same fundamental concerns. In BubbleRAN products, RIC, CIC, and Operators all are multi-x components by design and all the artifacts and images are designed with multi-x and interoperability in mind.

O-RAN Interfaces Supported in BubbleRAN Solution

The following table summarizes the support of O-RAN interfaces in BubbleRAN products. Where 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.

Legend

• Supported: The interface is supported.
• Planned: The interface is planned to be supported, depending on the conditions in the Notes column.
• Adapted: The interface is supported, possibly with some adaptations to the standard.
• Defined: The interface is newly defined and is in the beta stage of development.
• Refused: The interface is not supported, and most likely is replaced by a cloud native approach.
• Pending: The interface is not supported yet, and is pending further investigation.

The status of the interfaces is subject to the customer requests or onboarded vendors and when applicable, a specialized team will be working on the implementation with expected release for the next minor version.

BubbleRAN Meets O-RAN

In BubbleRAN’s model, Trirematics (T9s) plays the role of SMO Framework in O-RAN by providing all the required functionalities to Operate the RAN and CN over a multi-x O-Cloud as well as the Non-Real-Time RIC. Trirematics realizes FCAPS (Fault, Configuration, Accounting, Performance, and Security) in a cloud native manner and supports O-RAN interfaces where applicable, according to the table. Trirematics relies on Kubernetes (K8s) as its container orchestrator or Infrastructure Management Framework in O-RAN. T9s is agnostic towards the K8s distribution, including Vanilla Kubernetes, Redhat OpenShift, and OpenSUSE Rancher.

Trirematics comes with ability to use 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, one finds three set of Operators:

1. 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 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 could 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.
2. High-level Operators such as Optimization Operators are examples of higher level Operators that are shipped with BubbleRAN solutions. They rely on Athena for basic functionalities and build complex logics on top. The 3rd party Operators would be placed in the same logical level, while all the Operators could access each other functionalities through O3. The K8s RBAC rules are applied on O3 to provide access control. Other examples include 3GPP slice controller and scheduler Operators. Read blog posts on the Operator Plane for more details.
3. Odin NonRT RIC+CIC Operator is a specialized Operator to provide RIC and CIC functionalities. It is able to communicate with other Operators via O3. Odin is able to request deployment of xApps to Athena, based on 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 human 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 adaption of A1 interface to communicate with RIC and CIC. Arbitrary xApps could also be requested for deployment from Odin.

In T9s, 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. In such sense, 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, 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 T9s and there is no need for human 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. We have a separate blog post on Observability Revolution in BubbleRAN, coming with the second major release. Managers could possibly be extended with plugins to support advanced configuration models that have day-2 implications. For example reconfiguring a component without restarting the application or container. Also, arbitrary 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 is the first multi-x solution to address the missing challenges of Open RAN and Open CN. The compatability translation between O-RAN model and BubbleRAN’s architecture proves the flexibility of BubbleRAN deployments while maintaining all the other features not concerned with Open RAN or Open CN directly, such as high performance, flexibility, automation, observability, security, consistency, and scalability.

Need an Open RAN/O-RAN solution?