BubbleRAN unveils its MX-DT product, Scalable Network Digital Twins, as an extension to MX-ORS, bringing a whole new dimension into network intelligence.

Digital Twin (DT) of a physical entity, such as a manufacturing process or a communication network, provides a digital representation and reconstruction of that entity in the digital domain where real-time monitoring, data-driven analytics, and fine-grained control can be applied in isolation and without interference to and disruption of the physical domain. In the telecom space, planning, operation, maintenance, and optimization of mobile networks is becoming prohibitively costly and complex due to the sheer scale of the network, sophisticated systems and components, and also considerable generation-over-generation complexity in multiple protocols and standards adopted in these networks. For a single cell site, there are hundreds of system parameters impacting the performance which should be monitored regularly and fine-tuned to meet demanding end user service requirements.

A Digital Twin of a mobile network spans RAN, transport, and core of a physical mobile network but with RAN being the most cost-intensive sub-system, intelligent management, and automation of RAN will drive end user service assurance and significant OPEX efficiency. Service providers can adopt data-driven AI/ML/GenAI techniques to enrich the digital twin with network intelligence for predictive analytics and optimization purposes. Such an integrated AI-DT approach will be a significant value-add for private networks for verticals where limited network optimization resources are typically available.

Design Principles

BubbleRAN’s Digital Twin technology addresses service requirements of both public and private network operators with a significant critical business impact.

• Network Insights: It mines data from multiple system nodes, consolidates, and refines to produce network knowledge and insights (ML/RL/GenAI-based) and leverages them to identify the optimal reconfiguration, management, and control outcomes based on the operational and business objectives.
• Predictive Maintenance: It delivers actionable foresight for proactive network management.
• Risk-Free Optimization Using multiple DT instances, one can derive past and present analytics in different dimensions to test and verify optimization scenarios for performance enhancement while retaining service continuity (SLA/QoS).

As the high-level figure shows, we can construct multiple digital twin copies with twinned instances of the elements of the physical network for independent analysis on each one. Dedicated management and control for the twinned instances, and Apps for data collection, observability and AI integration are also included in each digital twin copy. The application layer provides interfaces for the mobile operator to realize real-life use cases of the digital twin, such as implementing zero-touch automation and optimization of the physical network. Through intent-based declarative schemes using Large Language Models (LLMs), one can create autonomous agents capable of utilizing data from both the physical and digital networks to enable hypothesis modeling and analysis and deriving optimal control policy for the physical network.

Key Technical Features of BubbleRAN’s Digital Twin Design

Our industry-leading implementation of the digital twin of an open 5G network embodies the following differentiating features.

• Cloud-native, Kubernetes-Based Architecture – Providing logical abstraction of the digital replicas, and functionalities offered by means of a Kubernetes Operator, yielding scalability and agility.

• Selective Replication and Scoping – The network context is encapsulated in a modular entity called State, enabling the users to define the scope and granularity of replication based on their specific requirements and use cases. This allows them to specify which attributes should be mirrored and included in the twinning process.

• Intent-Driven Automation – Based on the capabilities of Kubernetes Operator, the user can specify the desired resources, and the operator reconciles the existing and target resources.

• Parallel Digital Twins – Supports multiple simultaneous replicas of a single Physical Network (PN), each with different assumptions and configurations, and to orchestrate and execute different what-if hypotheses in each. This enables seamless branching, replication, and scenario exploration.

• Time Awareness – Through integrating Horaion for embedding the concept of time. Zero-touch synchronization guarantees real-time link and mirroring between physical and multiple digital networks.

We leveraged BubbleRAN’s Multi-x platform as a 5G reference system to test and validate the DT implementation, and demonstrated its technical readiness to scale out for networks with open interfaces.

Architectural Specifications

We follow a near-complete isolation of the physical network and the DT to develop a risk-free analysis, test, and validation sandbox, not interfering with the physical network. As shown in the diagram, first, components of the digital twin are all grouped in an independent plane, where Digital Twin Operator handles all the related procedures of the life-cycle management of the twinned entity, and second, the end-to-end stack of the network including the management and control plane can be cloned for subsequent what-if analyses and hypotheses testing.

The main components of the DT implementation are:

1. Perceptor – Collects information and data from the PN and DTs. It can retrieve data from multiple sources based on the defined state, network topology, channel conditions, traffic patterns, databases, and more.

2. Replicator – Inserts information and data into the DTs. This component includes Channel Estimator, Traffic Estimator, and Scenario Generator to enhance the accuracy of the digital twin representation.

3. Horaion – Timing agent which handles the following tasks:

   • Synchronization: Manages the Age of Information based on the type of information and the fusion of digital and physical times, where chronology is influenced by the observer and data processing. To address potential causality violations, a sync parameter and an observation window are introduced. All changes within the observation window are emulated in the DT as a single event.

   • Time Awareness: Enabling exploration of the past representations of the PN, making possible fault detection and root-cause analysis tasks.

The design employs an extensible multi-level Operator Plane that enables complex operations by separating network Custom Resources (CRs) from its deployment composition model. End-to-end logical networks and concepts can be created by exposing a new set of CRs at each level, effectively abstracting the created networks and the related concepts^1^.The DT Operator is a new operator for managing and operating within the Operator Plane.

Perceptor and Replicator are modular and extensible, allowing the set of mirrorrable network states to expand. Each network state comprises collect, read, diff, write, and deploy functions, making it adaptable and extendable. DT Operator continuously stages network state changes, enabling time awareness, i.e., the capability to create DTs from he past states. This allows operators to construct and explore past representations of the physical network, aiding in fault detection and root cause analysis. DT Operator also supports the creation of multiple DTs simultaneously and the sequential generation of different DTs over time.

In our DT implementation, State is the key concept through which we build the main components, Perceptor and Replicator.The network State represents an abstract representation of the network context at a given timestamp (network configuration, traffic traversing the network, etc.). The Perceptor is responsible for collecting the PN state and storing it in the permanent storage of the DT plane. The Replicator is responsible for reading the latest PN state from the storage and re-deploying it for each desired replica. It also manages the lifecycle of the replicas (create, update, delete). The replicator can be set up in order to synchronize the replicas, meaning that if any update occurs to the state of the PN it will reflect the update on the replica. For instance if a new UE joins the PN, a replica of that UE will also join the replica network. There is a 1-to-many relationship between the perceptor and replicator resource. One Perceptor can have multiple Replicators attached to it. For example, one Replicator could be used to deploy a synchronized DT, while another one to deploy a non-synchronized DT.

According to what is defined in the state, we harvest network context data such as network topology, databases created by xApps (KPM), and traffic (channel MCS in scope for a future release). The Network topology is available in the form of Network and Terminal Kubernetes CRDs (managed by BubbleRAN’s own SMO). Network CRDs correspond to a full 5G network (core+access+edge) while Terminal CRDs correspond to the cell UEs(2). The databases are mirrored by just collecting all entries from the tables in the PN and inserting them in the replicas. Traffic is mirrored by the Traffic Estimator which includes multiple components responsible for capturing packets in the PN, routing them to the DT, generating dummy packets with the same header in the DT.

The DT Operator focuses on the mechanical aspects of the digital twins, such as lifecycle management, synchronization, and state mirroring. However, the control logic remains aligned with O-RAN and 3GPP standards. No new components are introduced to apply actions or provide feedback to the network - this is left to the relevant rApps/xApps. More specifically, the feedback from DT can be in the form of either of the following three types.

• Recommendations for the intelligent entities like rApp/xApp where they decide whether and how to apply.

• Direct use of O-RAN or 5G APIs: This approach should ideally be applied manually by telecom operators to remove operational risks. If automation is required, it should be implemented through standardized 3GPP/O-RAN interfaces. For example, if the DT finds a better HO threshold, it can send an A1-P policy to an xApp to adjust the handover parameters.

• Providing future insights: This type of feedback does not trigger direct actions but serves as enrichment information, such as A1-EI to enhance decision-making.

We use K8s interfaces, for instance, when sending an A1-P policy, we apply the A1-P CRD. There is no direct interface between the DT operator and Non-RT RIC. However, the DT operator can leverage the Non-RT RIC to send an A1-P policy.

Traffic Mirroring takes place on a per-packet basis, which requires real-time information transfer from the PN to the DTs. To ensure real-time delivery and to prevent packet loss during peak traffic, we use an MQTT broker. The process follows these steps.

• Defining Traffic Mirroring – If traffic is specified as a state in the Perceptor YAML configuration, the DT operator applies the DynamicxApp CRD. This CRD instructs the Non-RT RIC to deploy an xApp in the Near-RT RIC.

• Packet Extraction via RAN Packet Sniffer (RPS) – Within this DynamicxApp, the RAN Packet Sniffer xApp is executed to extract relevant packet information. We use TC SM in the OAI RAN for traffic classification and monitoring.

• Data Transmission to the DT Operator – Instead of forwarding full packets, the RPS xApp extracts key metadata, including: Source and destination IP and port, Packet size, Protocol type. The extracted information is then sent to the DT operator via an MQTT queue.

• Processing in the DT

  • Perceptor receives packet metadata from the queue, stores it, and forwards it to the Replicator.

  • Replicator transmits the processed information to the DT, where an application in the UPF and UEs generates the corresponding traffic pattern in DL and UL.

This structured approach ensures efficient and real-time traffic mirroring, maintaining synchronization between the PN and DT.

Digital Twin Sample Use Cases

Digital Twin technology enables advanced use cases in the compute and connectivity domains for the telecom industry. In the context of future 6G networks, we can point to the following possibilities

• Network Simulation – Simulating a physical network allows providers to test the performance of new network installations with reduced costs and improved operational efficiency. This approach enables dynamic adjustments to the installation plan based on real-time feedback, ensuring optimal configurations – Once a finalized plan is developed, it can be deployed with confidence that it will meet the specified requirements.

• Data Generation – Artificial Intelligence (AI) will play a pivotal role in the development and operation of 6G networks. Generating sufficient data to train robust AI models is a significant challenge, which Digital Twins can (partially) address by facilitating the creation of synthetic datasets.

• AI/ML Validation – A Digital Twin environment provides an ideal platform for validating the decisions and actions of AI/ML models in a controlled, risk-free setting. By replicating the physical network in a virtual environment, operators can test AI/ML algorithms against a wide range of scenarios, configurations, and edge cases without impacting the actual network’s performance or stability. This ensures that the models are robust, reliable, and well-suited for deployment in the live network

• What-If Analysis – 6G networks are expected to be highly dynamic, allowing operators to modify key parameters and architectures within minutes or hours, rather than months or years. A Digital Twin application capable of detecting misconfigurations can assist network operators by proposing alternative, optimized configurations. These alternatives can be tested safely in various digital replicas of the Physical Network, ensuring robust and efficient implementations.

• Time-Travel Debugger – In cases where neither the network operator nor the Digital Twin application can identify misconfigurations, parts of the network may experience failures. A Time-Travel Debugger, a specialized debugging tool, records the network’s state history and enables step-by-step rollback to pinpoint the root cause of a crash. The presence of a Digital Twin would be a foundational requirement for developing such an advanced debugging system.

Digital Twin and Open RAN Networks

O-RAN Alliance has defined DT Networks as, “A digital replica of a communications network, or part(s) of a communications network, including, for example, any combination(s) of physical network elements and components, virtualized/cloud-native (containerized) network functions (VNFs/CNFs), physical hosts for such VNFs/CNFs etc.” Our implementation of the DT for O-RAN networks aligns with this vision. Our DT is designed for end-to-end (E2E) mobile networks, encompassing all network domains, including the RAN, core, and transport layers. Due to its broad scope and requirements for flexibility and scalability, it is not suitable to deploy the DT within the Non-RT RIC or Near-RT RIC. Instead, it operates independently, ensuring seamless integration across multiple network domains while remaining decoupled from real-time control functions. This architectural choice allows for enhanced data aggregation, cross-domain optimization, and an isolated environment for testing rApps/xApps.

The architecture of our solution allows the Digital Twin to be provided by a third party in a standalone fashion, rather than being tightly integrated with the RIC platform or specific rApp/xApp vendors’ solutions. This eliminates the need for additional standardization efforts to formally integrate DTs into the Open RAN architecture, making it easier to adopt and deploy across diverse network environments.

Despite being decoupled from RICs, the DT retains full compatibility with the O-RAN framework. The same data flow, monitoring mechanisms, policy enforcement mechanisms, AI/ML applications, training methods, testing approaches, and performance assurance techniques used in O-RAN networks are directly applicable to our DT solution. This ensures a seamless transition between the physical and simulated network environments.

References

(1) ATHENA: An Intelligent Multi-x Cloud Native Network Operator

(2) Sample Custom Resources (CR) for Terminal and network at https://bubbleran.com/docs/samples/athena/network, and https://bubbleran.com/docs/samples/athena/terminal

(3) Adopted from https://arxiv.org/pdf/2212.02032.

(4) Digital Twin RAN: Key Enablers, by O-RAN Alliance next Generation Research Group (nGRG), 2024.