Skip to main content

3 posts tagged with "O-RAN"

View All Tags

Network Automation: towards autonomous networks

ยท 6 min read
BubbleRAN
BubbleRAN

The BubbleRAN SMO-Sphere platform is designed around a simple idea: network automation should start from what the network operator wants to achieve, and not from a long sequence of manual procedures, handcrafted rules, or static operational workflows. In our October 2025 webinar, we showed how a declarative and cloud-native approach can turn that idea into a practical operational model for Day 0 to Day 2+ lifecycle management.

In SMO-Sphere, network automation is modeled declaratively. The network operator expresses the desired outcome as an intent through custom resources representing services, slices, networks, and terminals, while the platform continuously reconciles the target and current state of the network. This is the role of SMO-Sphere as an O-RAN-compliant, Kubernetes-based Service Management and Orchestration framework. It is built on the Kubernetes Operator pattern, meaning that custom resources describe the desired state and software controllers continuously observe and reconcile the live system toward that state. Here, Operator refers to the Kubernetes automation pattern, not to the telecom operator itself. Instead of treating deployment, assurance, scaling, and change management as disconnected tasks, they become part of the same coherent lifecycle automation.

As shown in Figure 1, automation is performed across different layers, each abstracting a network concept or operational function. Starting from the service intent, BubbleRAN can automate the path through Slice lifecycle, rApps, xApps, network blueprints, and finally the deployed network functions themselves. Operators work with high-level entities such as ServiceProfile, which captures service requirements such as latency, bandwidth, or policy objectives, and SliceProfile, which translates those requirements into a deployable 3GPP-compliant slice specification. At the lowest level, network intent is represented in our ecosystem through network blueprints, which specify for each domain the Composition Models used to compose and deploy the corresponding network functions. The underlying deployment details are then handled by the automation framework. The result is an end-to-end service view that remains operationally simple even when the underlying infrastructure is not.

Abstraction ladder from intent to slice, rApp, xApp, network, and function.

Figure 1. BubbleRAN automation spans from service intent down to deployed network functions.

BubbleRAN can realize network intent across heterogeneous RAN, Edge and Core Network (CN) components under an O-RAN-aligned SMO and RIC architecture. As shown in Figure 2, the same automation framework can manage deployments that combine OAI or Open5GS core functions with OCUDU (formerly srsRAN), OAI, or Amarisoft RAN components. The same approach also supports partial-domain automation. For example, BubbleRAN SMO can manage the lifecycle of the RAN while that RAN is connected to an external Core network already in place, as depicted in Figure 2 with an external Open5GS CN. This is particularly important in brownfield environments where operators want automation without having to replace the entire stack. The main enabler of this flexibility is the network blueprint approach and the decoupling of composition from deployment. In BubbleRAN, a network blueprint captures how each domain of the target network is assembled, while vendors can expose reusable recipes and composition models for the underlying functions. Operators therefore preserve control of how the network is planned, configured, integrated, and evolved over time, without being forced into a closed and vertically integrated operational model.

BubbleRAN SMO orchestrating a multi-vendor deployment with Open5GS, srsRAN, OAI, and Amarisoft.

Figure 2. A single network intent can be realized across multi-vendor RAN and Core building blocks, including deployments where BubbleRAN controls the RAN while interconnecting with internal or external elements (OAI and Open5GS respectively in this example).

Automation gives the system the ability to translate intent into deployment, assurance, scaling, and policy-driven actions. Autonomous networks go one step further: they require observation, reasoning, decision-making, and closed-loop adaptation over time. In practice, this is not a binary jump but a progression from manual to assisted to automated and eventually autonomous operation. True network automation is therefore the foundation on top of which autonomous networks can be built. Within BubbleRAN, this progression is aligned with an agentic approach to network operations. AI agents are a key enabler for moving from automation toward autonomy because they can interpret high-level intents, decompose them into domain-specific actions, and coordinate workflows across the network. BubbleRAN supports this direction natively through multi-agent schemes that can work with the same declarative network model. Together with rApps, xApps, digital twins, and specialized controllers, agents can provide network assistance, optimization, and closed-loop operational intelligence in a practical and incremental way.

In BubbleRAN, this direction is realized through MX-AI, our agentic platform for network assistance, agentic workflows, and AI-driven optimization. Built on top of the same declarative and intent-driven operational model, MX-AI extends the automation foundation of SMO-Sphere toward more adaptive, data-driven, and progressively autonomous operations.

This evolution toward more intelligent operations does not come at the expense of openness or operational control. BubbleRAN supports the onboarding of third-party network functions, interconnection with external workloads, and preservation of manual control whenever needed. The platform can automate network operations with repeatability, while remaining flexible enough for brownfield integration, custom extensions, and direct network operator intervention. This is the direction we believe matters most: not automation for its own sake, but a path toward autonomous networks grounded in declarative intent, multi-vendor interoperability, lifecycle control, and native support for AI agents. Network automation is the starting point.

Watch our automation webinarโ€‹

Further readingโ€‹

[1] BubbleRAN SMO-Sphere datasheet
[2] Webinar slides
[3] ATHENA: An Intelligent Multi-x Cloud Native Network Operator
[4] BubbleRAN MX-AI
[5] Agentic AI for Open RAN: Design, Integration, and Field Validation in a Multi-Agent Framework
[6] BubbleRAN Opti-Sphere

DENIM Release Notes (2026-01)

ยท 2 min read
BubbleRAN
BubbleRAN

Release Notesโ€‹

note

Download Denim Release Notes

Denim Release Notes

Top Feature Setsโ€‹

BubbleRAN Near-RT RICโ€‹

  • O-RAN RC Service Model support for handover control
  • O-RAN LLC Service Model support for I/Q sample collection (SRS, noise, channel estimates)
  • VictoriaMetrics support for RAN telemetry and analytics
  • Enhancements to RAN slicing (ePR algorithm, multi-DL slice association, de-association control)

BubbleRAN SMO / Non-RT RICโ€‹

  • Automatic O-RU discovery and management for Benetel and LITEON platforms
  • E2 compatibility with LITEON All-in-One O-RAN nodes
  • Support for band n79 deployments
  • Expanded O-Cloud deployment compositions (OAI CU/DU/RU for OTA handover scenarios)
  • Dynamic rApp lifecycle management and policy composition (Non-RT RIC)
  • End-to-end network slice lifecycle management with automated QoS enforcement
  • Operational robustness improvements and firmware compatibility fixes

Observabilityโ€‹

  • Migration of observability backend from Prometheus to VictoriaMetrics
  • High-resolution RAN, Kubernetes, and power telemetry (500 ms granularity, 7-day retention)
  • Dataset extraction and export via BRC (CSV)
  • New Grafana dashboards aligned with O-RAN observability practices
  • MySQL deprecated with backward compatibility maintained

MX-AI (AI-RAN Enablement)โ€‹

  • Introduction of BAT-ADK (BubbleRAN Agent Development Kit)
  • Prebuilt agent workflows (ReActLoop, CallAgentNode)
  • Agent configuration and usage metadata support
  • Internal MCP-based integration via AIFabric
  • New IRIS UI for AI-native RAN operations
  • Release of Supervisor, SMO Agent v2, Kubernetes API Agent, and experimental AI agents (UL AD, P0 Nominal)
  • Deprecation of legacy Orchestrator and SMO Agent

Supported Artifacts Fromโ€‹

  • Amarisoft
  • Benetel
  • LITEON
  • OpenAirInterface
  • Open5GS
  • Software Radio Systems (SRS)
  • BubbleRAN SDKS, rApp/xApp/Agent directory, E2 Agent Proxy, MX-RIC, MX-Operator, MX-AI

CRIMSON Release Notes (2025-06)

ยท 2 min read
BubbleRAN
BubbleRAN

Top Feature Setsโ€‹

note

Download MX-PDK Datasheet

MX-PDK Data Sheet

MX-5Gโ€‹

OAI 5G gNB / CU / DUโ€‹

  • Support public version v2.2.0 + 2025.w12 (v2.3.0 coming soon)
  • Support RAN functions:
    • More metrics for KPM monitoring
    • ISAC
    • Slicing
  • Support RFSIM, LITEON O-RU (FlexiFi FR1), Benetel O-RU (RAN550 and RAN650)

OAI 5G UEโ€‹

  • Support public version v2.2.0 + 2025.w12 (v2.3.0 coming soon)

Open5GSโ€‹

  • Support public version 2.7.5

Amarisoftโ€‹

  • Support public version 2024-12
  • Support RAN functions:
    • KPM monitoring
    • RC inter and intra XnAP HO
    • CCC BWP switch

srsRAN gNBโ€‹

  • Support public version release_2025_04
  • Support USRP B210, LITEON O-RU (FlexiFi FR1)

MX-RICโ€‹

Improved developer experienceโ€‹

  • rApp SDK, rApp directory
  • xApp SDK (user and developer), xApp directory
  • xApp YAML config file

New Custom Service Modelsโ€‹

  • RAN Sensing E2SM
  • RAN Slicing E2SM (eEDF, policy-based slicing algorithms)

Enhanced RAN Controlโ€‹

  • Handover (RC SM based)
  • MCS control (RC SM based)
  • RAN configuration (CCC SM based)
  • BWP control

New E2 Agent Proxyโ€‹

MX-Operatorโ€‹

  • Non-RT MX-RIC
  • R1AP, A1AP and native JSON encoding
  • PDU support (Redfish API) O-RAN O1 interface
  • Enhancements: FCAPS, Networking, and CLI
  • (EXP, Canary Release) Network Slicing (Layered service/slice/network model, end-to-end across RAN and core, aligned with O-RAN and 3GPP specifications)
  • RAN Data acquisition pipeline (data-lake, compute resources, energy consumption efficiency)

MX-AIโ€‹

  • Flexible Multi-Agent environment (MX-AI Core)
  • Dev Kit for xApp, rApp, AI Agents
  • MX-HUB to collaborate, publish, and monetize!
    • Reusable and extendable rApp, xApp, and Agent directory

O-Cloud / Radio fronthaul:โ€‹

  • O-RAN 7-2 split (LiteON, Benetel)
  • PTP time-synch
  • Small cell (LiteON)
  • O1 O-Cloud RU management

Supported Artifacts Fromโ€‹

  • Amarisoft
  • Benetel
  • LITEON
  • OpenAirInterface
  • Open5GS
  • Software Radio Systems (SRS)
  • BubbleRAN SDKs, rApp/xApp/Agent directory, E2 Agent Proxy, MX-RIC, MX-Operator, MX-AI