1. What is the BubbleRAN Telco DevOps Technology?
The BubbleRAN DevOps Technology leverages the best practices to deliver an agile and consistent Cloud-Native Multi-vendor 4G/5G CI/CD/CO platform providing more than 10x faster on-boarding, performance and conformance testing (3GPP and O-RAN), efficiency and delivery cycles targeting telco network functions and applications (4G and 5G).
The BubbleRAN DevOps is realized using GitOps operational framework that leverages the best practices used for network functions and application development/integration/testing such as CI/CD/CO and applies them to the infrastructure and multi-vendor 4G/5G network automation.
The BubbleRAN Telco Devs include on-boarding & migration, building & packaging, testing & validation, and releasing artifacts via the BubbleRAN hub.
The BubbleRAN Telco Ops includes provisioning, Operations, Observe, insight & automate that are accessible via a powerful cli & APIs.
Vendors and Developers can now simply develop/customize/on-board their network functions and xApps/rApps as well as their Kubernetes custom resource definitions (CRDs) via the CI/CD/CO platform using the BubbleRAN SDK and CDK.
Operators and Service Providers can leverage multi-x software-based operators to design and deploy a 4G/5G network tailors to a particular use-case requirements and yield the required level of control and observability to the customers.
Terminology CI/CD/CO: Continuous Integration, Continuous Delivery, and Continuous Optimization. SDK: xApp and rApps software development kit. CDK: Container development kit. Operations: design, install, deploy, test, reconfigure, fail-over, backup, restore, upgrade. Observe: logs, metrics, conditional events, alarm, and alerts. Insight: health, anomaly, inefficiency. Automate: scaling, healing, tuning.
2. How does the BubbleRAN technology supports 3GPP standard, O-RAN architecture and its components in public and private clouds?
- BubbleRAN relies on the 3rd party vendors, such as Amarisoft, OpenAirInterface, srsRAN, and Open5GS among the others, to create and validate an optimized multi-x 5G artifacts in conformance with the 3GPP, O-RAN and public cloud requirements.
- BubbleRAN develops cloud-native Open RAN components including MX-RIC as NearRT and Non-RT RIC, MX-Operator as SMO, xApps, rApps, in compliance with O-RAN specification, where both legacy and emerging Operators and service providers are one click away to mix-and-match one x in multi-x to another one (one vendor to another or one deployment to another).
SMO: Service Management and Orchestration. RIC: RAN Intelligent Controller. xApp: NearRT-RIC applications. rApp: Non-RT-RIC applications. Multi-x: Multi-vendor, Multi-version, Multi-RAT, Multi-RU, Multi-cloud, Multi-OS, Multi-deployment.
3. What is the BubbleRAN MX-Operator?
- The BubbleRAN MX-Operator is a new generation of MANO/SMO that fully adheres to the cloud-native principles, while fostering innovation and sustainable deployment for 4G, 5G, and beyond. It elicits an agile and intelligent, dynamic control over variety of vendors and radio stacks (multi-x) coexisting on the same network with built-in observability and at the scale.
- MX-Operator bases its foundation upon the Operator Framework to assist or replace the human in the loop, approaching six dimensions including Cloud-Native Intelligent, Closed-Loop Observability, 4C Secure Networking, Sustainability, Agile and Consistent DevOps, and Open Ecosystem, for RAN and its hardware resources, CN, and edge applications.
4. What are the Benefits of MX-Operator?
MX-Operator is a cloud-native O-RAN-compliant SMO and as such provides a Kubernetes-based control-plane automation and closed-loop observability in a heterogeneous and distributed infrastructure without compromising the user-plane performance. To this end, MX-Operator brings the following benefits for each player:
For Operators: A declarative multi-vendor Kubernetes-based software-based operator plane that provides 10x faster ob-boarding and delivery cycle with order of magnitude lower energy footprint. The MX-Operator provides a uniform control plane across the above-mentioned 6 dimensions, notably simpler yet agile life-cycle management (level I-IV) including fault recovery, closed-loop network service observability, intent-based reconciliation, network policy management and enforcement, and network service continuity and assurance.
Cloud Providers: A standard Kubernetes automation workflow enabling faster delivery cycle with known technology and best practices providing assurance that the E2E network and its applications will consistently and reliably runs on the top of the cloud, both public and private.
Vendors: A well-proven CI/CD/CO environment (GitOps) coupled with a container development kit (CDK) that make the network function and application on-boarding as well as multi-vendor integration and interoperability order-of-magnitude easier and faster.
Customers: Gain the required level of control over their network as a whole (i.e. vendors, SLA, infrastructure among the others) while optimizing simultaneously the CAPEX and OPEX.
5. Why are the different domains of the BubbleRAN MX-Operator?
MX-Operator spans across five domains as follows:
- Athena: Telco Service Operators.
- Odin: Telco Service Manager.
- Gaia: Telco Kubernetes Distribution.
- Hydra: Container-Development Kit.
- Trident: CI/CD/CO/DevOps/hub platform.
Refer to the BubbleRAN Open Documentation for further information.
6. What problem does the BubbleRAN MX-Operator solves?
Relying on different automation control planes for each infrastructure, vendor, and deployment (i.e. multi-x dimension) makes it impossible to provide an agile, consistent and reliable E2E network operations and retain the network efficiency and service continuity. This is because each network function or application from each vendor is usually associated with its own automation control planes.
By relying on the standards and unified Kubernetes-based control plane, MX-Operator provides software-based Operators for logical network entities that are formulating concepts such as 5G-SA, slices, terminals, costs. In this view, the NFs could be mix-and-matched in a heterogeneous and distributed cloud infrastructure, which was otherwise impossible or troublesome to achieve since each vendor was providing its own (perhaps patched or tweaked) MANO/SMO.
MX-Operator solves the above problem by applying an intent-based and decentralized decision-making, utilizing sidecar Managers to realize a declarative idempotent operations and delivers a built-in autonomous observability stack as opposed to the traditional monitoring systems which required human intervention.
7. How does the BubbleRAN MX-Operator work?
MX-Operator defines an extendable Operator-plane where several operators cooperatively process logical network entities and its representations in various aspects. The functionalities of ATHENA in the Operator Plane could be expanded in two levels.
- Level-1 of the Operators consumes logical network custom resources (CRs) to expose new set of CRs targeting a logical entity such as slice or network terminal.
- Level-2 of the Operators is built on top of those logical entities, to enable sophisticated and/or E2E Operations like cost optimization. Through the Operator Plane, concepts and functionalities are transcended from physical to logical, abstracting both the network itself and the related concepts
8. Why Telco CI/CD/CO/DevOps matters and how it helps the business
Telco is moving towards a software-based telco solution empowered with hardware resources (e.g. look aside or inline accelerated cards). Today’s legacy public operators as well as emerging private Operators are calling for a faster and more efficient 5G delivery cycles on daily basis to meet their business application requirements while at the same time lowering the operating costs and energy footprint of the overall network.
By leveraging CI/CD/CO/DevOps, the entire delivery cycle can be automated in an agile, consistent manner helping Operators to deal with network fixes and upgrade. One simple example is an important security patch on a running network or release a new features in a matter of an hour rather than days or months while retaining the service assurance and continuity.
8. What are the challenges to adopt a cloud-native 4G/5G solution?
From the technical perspective, one of the main challenges is the transition from VNF to CNF and from physical infrastructure to private/public clouds. This means more software-based 4G/5G solutions that are empowered by the hardware accelerators to sustain the promised performance. This brings another challenges, which is to expose hardware capabilities as a soft and composable resources to the CNF to maximize the efficiency and multiplexing gain.
CNF: Cloud-native network function. VNF: Virtual network function.
9. Why existing approaches (e.g., Docker-based, or Helm-based) automation is not sufficient for 5G?
A 4G/5G network components by design relies on a heterogeneous, distributed, and synchronous infrastructure resources, namely hardware accelerators, radio units, network functions, and edge apps, that usually provided by different vendors.
A Docker-based or Helm-based automation can only provide level 1 and 2 life-cycle operations and are limited to a single vendor and single infrastructure.