BubbleRAN O-RAN compliant stack includes:

1. O-RAN Interfaces: E2AP v2/3, A1AP v1.x, O1. R1 is implemented as a mirror of A1AP.
2. O-RAN Service Models: Key performance measurement v2/3, RAN Control v1.x, and Cell Configuration and Control v3.x. In addition BubbleRAN has developped additional service models including RAN slicing and Traffic Control.
3. O-Cloud: Scalability (128 Compute nodes), synchronization, auto-device discovery, optimized data plane, and eBPF Observability
4. MX-RIC: Near-RT RIC, Non-RT RIC, and an ecosystem of xApps and rApps
5. MX-Operator: SMO/OAM, Observability Stack, FCAPS, Network Slicing, Intent Operator
6. MX-Hub: Artifact registry with images, software packages, deployment blueprints
7. MX-Data: Multi-source data lake with metrics and stats from Infrastructure, 5G RAN and CN, and Energy footprints

Note: BubbleRAN’s O-RAN Stack is all implemented in house. It features cloud-native and can be deployed from bare-metal to private and public clouds. For example you can deploy it on Google K8s Engine (GKE)!

xApp features and supported service models are shown in the figure below.

1. O-RAN E2SM: Key performance measurement v2/3, RAN Control v1.x, and Cell Configuration and Control v3.x
2. BubbleRAN E2SM: MAC, RLC, PDCP, NGAP, Slice Control, and Traffic Control.

1. FlexPolicy: Policy Job defines different control actions and policies to be applied on a selected set of E2 nodes, an evolution of the A1-P service. Use cases include load-balancing.

2. FlexMon: Monitoring Job defines programmable monitoring targeting selected E2 nodes with post-processing and metric selection exported to Timescale Database (TSDB) compatible with Prometheus and Grafana.

3. FlexAI: A collaborative framwwork based on GenAI for automation of shared networks.

1. Full Day-0, Day-1, Day-2 Level-5 Autopilot. Refer to the list of capabilities here
2. Slice definition, assignment, and scaling
3. Multiple interfaces support for the RAN and CN
4. Full scheduling control on the container placement
5. DNS scoping and Edge services
6. High scalability with minimum deployment time (E2E less than a minute)
7. Reconfiguration and full-stack observability
8. Full customization and extensibility for both the Manager and Operators
9. Fully cloud-native with non-privileged containers supporting both private (on-premise) and public cloud providers
10. Automatic device discovery and mapping for GPUs, SDRs, RRHs, etc.
11. Network terminal management
12. Application in the loop
13. Idempotent and declarative logic design

Yes. MX-Operator fully supports external interfaces and each of the NFs could be adjusted/configured to connect externally (as clients) or listen for external connection (as servers). In addition, we support external DNS entries. MX-Operator also support hybrid cloud deployment where different NFs are deployed in different clouds.

1. KPM: Performance Monitoring, Data-set collections, Load Distribution, Congestion Detection
2. RC: Mobility management (HO), RAN Slicing, Load Balancing, QoS Control, Energy Management, Cell Management
3. CCC: BWP reconfiguration, Frequency reconfiguration
4. Mac/RLC/PDCP/GTP: Extended KPM
5. Slice Control: Radio Resource Slicing, Resource Allocation Policy, Slicing Policy, MCS Control
6. Traffic Control: QoS Control, Flow-level Slicing

Yes. BubbleRAN supports a variety and mix-and-match of the vendors that could be simultaneously deployed and operated within the same network environment. BubbleRAN supports the following Open Source 5G Stack: OpenAirInterface, srsRAN, and Open5GS. In addition, BubbbleRAN supports the following industrial-grade 5G stack: Amarisoft 4G/5G, Lite-On All-in-One 5G gNB, O-RDU, and O-RU.

Note: BubbleRAN O-RAN stack is Multi-x by design, refering to various dimensions such as RAN vendor, OS, and cloud, addressing the level of heterogeneity and diversity in the modern networks, and it is considered as a natural extension to the Open RAN

Yes. O-RAN 7.2 fronthaul split is supported for OpenAirInterface, srsRAN, and Amarisoft 5G stack with Lite-On FlexFI O-RU. We also support Benetel and VVDN 7.2 RU.

Note: Each vendor implements the fronthaul interface differently and therefore the capabilities differ across the vendors.

The rApps are implemented as applications running on top of the Non-RT RIC consuming its APIs. These Non-RT RIC is implemented as a Kubernetes Operator exposing its Custom Resource Definitions (CRD) to be consumed by the rApps. Hence, rApps use these CRDs in order to send policies and receive feedback utilizing any Kubernetes clients. The rApps are written in go, python and JavaScript.

Note: R1 is not currently clearly specified. It is shown to include multiple services, such as A1 services among other SMO services. Hence, for R1, we mirrored and extended the A1 as CRDs between non-RT RIC and rApps.

1. A1 interface is fully standard compliant and it is extended to support additional functionalities, such as direct RAN slicing in an effort to provide more control capabilities in the Non-RT and rApp levels. 2. Today the policies that are supported through the rApps are the following: 3. Target PRB Utilization: A target RAN PRB utilization is enforced, and the appropriate xApp takes the necessary control actions in the RAN to bring the current utilization closer to the desired state. 4. Slice Enforce: Slicing control policies are sent, such as creating, updating or deleting slices and also associating the UEs to the various slices. 5. Monitoring Job: A flexible monitoring job is enforced in order to monitor a list of target statistics of one or multiple cells under one or multiple networks.

We use an existing open source NetConf client to realize the O1 interface. The O1 is only available for the Lite-on AIO small-cell and O-RU.

Note: We do not use the O-RAN O1-compliant interfaces to configure and manage OpenAirInterface, srsRAN, and Amarisoft since they do not implement the O1 interfaces (i.e. NetConf Server). Recently, there have been some activities for OAI on the O1 interface but they do not provide all the required features for our SMO.

Nevertheless, this does not limit our SMO in its functions with respect to the NFs or RAN software, but rather improves it for day-2 operations. If you use the cli extract pcap command to extract the PCAP in the containers, you would see some HTTP messages transported for the REST API between the Workload and the Manager containers that might resemble the O1 messages that you are looking for.

In terms of the operations, any change in the YAML file used for the network is propagated automatically to all the affected NFs. In terms of monitoring and fault-tolerance, we use cloud-native software such as Prometheus that are natively integrated with our SMO.

1. There is no coupling between MX-RIC and OAI. In fact, RIC is tied to E2 Agent, and the E2 agent is tied to the RAN functions.
2. MX-RIC is by design multi-vendor, and currently supports OAI, srsRAN, Amarisoft, and tier3 vendors such as Lite-On. This means that each vendor implements a subset of parameters in each service model.

1. MCS is not a configurable parameter, it is decided based on BLER and/or CQI.
2. RB a the function of the bandwidth, and you can change the bandwidth to change the total available RB. Using RAN slicing, you can dynamically reconfigure the total RB per slice over time.
3. In general, you can change the configuration file in two ways:
4. Management system using the SMO: day 0 and day 2 operations
5. Control system using near-RT RIC: CCC E2SM allows you to perform a runtime reconfiguration

1. The 5QIs are defined in the CN configuration in Amarisoft and SMF configuration in OAI. The difference between the two is that in Amarisoft you are allowed to define multiple E-RABs per DNN, but in OAI it is limited to a single one.
2. Upon the request from the UE for a particular DNN, to establish the PDU session, for each of the E-RABs a corresponding DRB is created. In Amarisoft this is governed by the DRB mapping configuration and in OAI it is always mapped to a single DRB.
3. In Amarisoft, the default configuration supports all the 5QI values and their corresponding DRBs, but only the DNN provided by your slice configuration in the YAML file as well as IMS and SOS DNNs are created by default. The DNNs for IMS and SOS use standard values for 5QI (5, 1, and 2) and the other one is always 5QI = 9. If you want to change any of these parameters, we could define some workarounds with annotations in the YAML file.
4. For the matter of PDU Session modification, if you are looking for APIs to connect to the core network to modify them, they are not provided by neither Amarisoft nor OAI.

Yes, you can perform CN network slicing and RAN slicing. 3GPP network slicing is supported with Open5GS and OAI CN, while RAN slicing is achieved using the RAN Control service model.

1. The BubbleRAN DevOps Technology leverages the best practices to deliver an agile and consistent Cloud-Native Multi-vendor 5G/6G 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 (5G/6G).

2. 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 5G/6G network automation.

3. The BubbleRAN Telco Devs include on-boarding & migration, building & packaging, testing & validation, and releasing artifacts via the BubbleRAN hub.

4. The BubbleRAN Telco Ops includes provisioning, Operations, Observe, insight & automate that are accessible via a powerful cli & APIs.

5. 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.

6. Operators and Service Providers can leverage multi-x software-based operators to design and deploy a 5G/6G network tailors to a particular use-case requirements and yield the required level of control and observability to the customers.

Terminologies (DevOps definitions and benefits according to Amazon)

1. CI/CD/CO: Continuous Integration, Continuous Delivery, and Continuous Optimization.
2. SDK: xApp and rApps software development kit.
3. CDK: Container development kit.
4. Operations: design, install, deploy, test, reconfigure, fail-over, backup, restore, upgrade.
5. Observe: logs, metrics, conditional events, alarm, and alerts.
6. Insight: health, anomaly, inefficiency.
7. Automate: scaling, healing, tuning.

1. 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.

2. BubbleRAN develops cloud-native Open RAN components including MX-RIC as NearRT and Non-RT RIC with xApps and rApps, MX-Operator as SMO/OAM, FCAPS, Observability stack, compliant with the 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).

Terminologies

1. SMO: Service Management and Orchestration.
2. RIC: RAN Intelligent Controller.
3. xApp: NearRT-RIC applications.
4. rApp: Non-RT-RIC applications.
5. Multi-x: Multi-vendor, Multi-version, Multi-RAT, Multi-RU, Multi-cloud, Multi-OS, Multi-deployment.

1. 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.

2. 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.

1. 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.

2. 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.

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 5G/6G 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.

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.

1. Open documentation includes xApp and SM documentation for users and developers.
2. In the figure below you can see the xApp /rApp lifecycle from development to production.
3. A software-development kit (SDK) is provided for the development of an xApp (see documentation link above).
4. To onboard an xApp or an NF as a container, a Container Development Kit (CDK) is provided in the DevOps package, allowing you to integrate your custom function into MX-ORS and MX-PDK. We are currently working on documentation for this. Your xApps can also run as normal processes outside the cluster and connect to the RIC and gNBs running inside the cluster.

This is the same as developing a new xApp from the MX-ORS and MX-PDK. Please refer to Q12. We also have a number of xApp examples that support AI/ML, delivered in a source code format so that the clients could reproduce and extend the use-case.

1. Since the rApps in BubbleRAN are using cloud-native Kubernetes APIs, any SDK supporting Kubernetes clients would do. This means, you could implement your own logic in any language (Python, Go, JavaScript, or any REST-client implementation) by just consuming the Custom Resource Definitions (CRDs) created by our SMO.
2. Currently, three rApps are available: Cell manager, Spectrum sharing, Dynamic resource and NF scaling.

Note: We plan to develop an rApp SDK to facilitate the development of rApps.

1. MX-ORS and MX-PDK support any arbitrary containerized application to be attached to the user-terminal and be deployed at the edge cloud.
2. The actual integration might need our support, and requires evaluation.

1. You can access the container of any NF in a given deployment.
2. If the containers come with the source code, you can modify the source code on the fly. Some of our xApps provide such features.
3. You can change the source codes of any open-source based NFs that are supported by BubbleRAN (OAI, srsRAN), and connect to the MX-ORS and MX-PDK product family as external off-cluster resources (see Q19). To on-board such a NF you would need the CDK (see Q12) included in the BubbleRAN DevOps package.

Yes. Note that the number of concurrent networks deployed on your infrastructure depends on the available compute/memory/network resources. This is indeed an effective infrastructure sharing across different users and networks. In K8s, there is the concept of namespace which allows to logically separate the infrastructures across different users and/or networks.

We don’t have any limitations regarding this whether it is in the same namespace or across different namespaces.

As long as other RICs are compliant with E2AP v3 and the O-RAN service models (KPM v3, RC v1.1, and CCC v3.0), you can integrate them with other RIC platforms. Note that the most important part of a RIC is the xApps and rApps, as the RIC itself does not realize any intelligence; the intelligence resides in the xApps.

Note: BubbleRAN RIC extends FlexRIC with new service models and xApps, providing the most comprehensive features of O-RAN RICs. You can access the BubbleRAN FlexRIC here: BubbleRAN FlexRIC.

You can publish results and explore commercial applications, but you can’t transfer the license. Please have a look at the license agreement.

MX-ORS is a subset of MX-PDK and includes all the MX-PDK functionalities. The key difference is that MX-ORS uses emulated UEs and channels, while MX-PDK is an operational over-the-air network. Therefore, the data generated via MX-PDK has a higher level of realism than MX-ORS. Moreover, MX-ORS does not currently support inter-cell handover, whereas MX-PDK does. In the figure below you can see a schematic indicating the relationship between the MX-ORS and MX-PDK products, as well as a mapping to use cases and TRLs.

It depends on the RAN vendor. Please have a look at the OAI and srsRAN supported channel models.

UEs in MX-ORS are software-based emulated UEs, while those in MX-PDK are either smartphones (supported devices: Google phone, Samsung Galaxy, iPhone, oneplus) or 5G modules such as Quectel. The testbed can support up to sixteen 4G/5G connected UEs.

No, the base price includes only the software license and 1 year of software updates and support (dedicated chat channel). In that way you can reuse your existing hardware and radio equipment. All the required hardware components are available as add-ons.

1. MX-ORS can potentially be deployed on a single machine (Minikube), but the number of required machines depends on the scale of the deployment. There is also the option to deploy solely on a public cloud, as there is no need for specific hardware such as SDR or RU (emulated channels and UEs).
2. For MX-PDK, it is recommended to have at least three machines, Intel-based or AMD-based, with the following specifications: i9/Xeon/Epyc, >3.7GHz/16C, >32GB RAM, >250GB SSD (write-intensive), NIC: 10/25Gbps (Intel E810, E820, X710), Form Factor: Tower or Rack, Cooling: Liquid + Fan. Note that some network functions, such as AMF/SMF, can be deployed in the public cloud. Moreover, since MX-PDK deploys an over-the-air network, it also requires at least a PTP time-aware switch (grandmaster), a Radio Unit, and a 4G/5G UE.

1. It depends on different factors including: bandwidth, number of layers (e.g. MIMO), and radio frontend.
2. Indicatively for 100MHz 2x2 single carrier with an Intel i9, 4GHz/16C, 32RAM, NIC: 10Gbps, you can run:
3. -3 gNBs
4. -1 gNB and 2-4 UEs
5. -2 gNBs and 2 UEs

Yes, both configurations are supported; however the NSA is an experimental version.

There is currently a GUI and dashboard available for monitoring, which can provide real time measurements and stats from the network. Regarding the configuration of the network, it is currently only through the CLI.

1. BubbleRAN (BR) founded in 2021, as a spin-off of Eurecom.

2. BR is a software company dedicated to telecom and deliver a range of best-in-class cloud-native 5G/6G O-RAN solutions empowered Edge Computing and Generative AI technologies for R&D and enterprise private 5G use-cases.

3. BR is helping organization to deploy, operate, and automate a high-performance, reliable, and secure 5G/6G infrastructure at scale that is simple to use, customize and extend.

3. Our mission is build an open, neutral, and trustworthy Intelligent Connectivity and Open Ecosystem.

1. Technology First: With no new technology there is no added-value solution and with no research there is no Technology. Our pioneering R&D team strives to accelerate the technological advancements in enabling Intelligent Connectivity across six main dimensions centered at 5G/6G, namely: cloud-native intelligence, Observability, trustworthiness, sustainability, and open ecosystem.
2. Open 5G/6G Ecosystem Openness is our motto, we rely on Open Source software and contribute to it. We support emerging Telco business models, where all players can join, cooperate, and make profit.
3. Affordable Turnkey Solutions: We enforce fair pricing and green IT policy when possible to all of our products to meet the current needs of scalability as well as energy and cost efficiency. Our products portfolio is fully integrated and end-to-end.

Checkout our research and contribution to Open Source here

BubbleRAN is located in French Rivera, south of France.

The postal address is: 450 Route des Chappes, 06410 Biot, France.

1. BubbleRAN is founded in 2021 by Navid Nikaein, the acting CEO/CTO of the company.

2. Currently (01/06/2024), the BubbleRAN team is composed of 9 people.

BubbleRAN develops a complete cloud-native multi-vendor O-RAN stack, all implemented in house. We also work with divers 5G vendors to on-board their 5G stack in our portfolio. Currently we are supporting the following vendors:

1. Open Source: OpenAirInterface, srsRAN, Open5GS
2. Industrial-grade: Amarisoft, and Lite-On

BubbleRAN targets the following markets:

1. Education and Learning with MX-ORS product. TRL 4-5, 3GPP, O-RAN, Cloud-Native, AI, and Edge computing.

2. R&D and Measurement with MX-PDK product. TRL 4-7, PoC and MVP.

3. Private5G with MX-PRO product. TRL7-9, Enterprise Networking and Deployment.

Note:

1. We guarantee a seamless transition from education and R&D to deployment with a consistent UI and tool chain and guaranteed reprehensibility.
2. The three products are based on the same core technology.

To book a meeting, please

1. First Contact us by email to provide us more information about your requirement and the topics you would like to discuss during the meeting.
2. Then, after you received our reply, Book a meeting