PaperlayerView exact revision on arXiv

Source-linked AI summary

ONDT: A Modular and Virtualized O-RAN Digital Twin for xApp/rApp Closed-Loop Experimentatio

Miguel Catalan-Cid, Joan Josep Aleixendri, August Betzler, George Oikonomou, Lydia Ntzogani, David Reiss

arXiv:2610.07889v1cs.NI

TL;DR

O-RAN application validation must account for interactions among applications, RIC services, telemetry, and RAN behavior, including coordinated control across RIC layers. ONDT provides a modular, cloud-native framework for repeatable experimentation, and its validation demonstrates complete closed-loop execution with approximately 35% average energy savings and a 3–4 percentage-point throughput-outage increase.

Abstract

from arXiv · show

Open Radio Access Network (O-RAN) architectures extend programmability in next-generation cellular networks through Near-Real-Time and Non-Real-Time RAN Intelligent Controllers (RICs), enabling AI/ML-driven xApps and rApps to optimize network behavior dynamically. However, validating automated closed-loop control algorithms in live environments presents significant operational risks and deployment costs. To address this challenge, this paper introduces the O-RAN Digital Twin (ONDT), a modular, virtualized, and cloud-native experimentation framework developed as a 6G enabler within the SNS SUNRISE-6G project. We present the ONDT architecture and its end-to-end experimentation workflows, showing how the framework automates O-RAN-compliant rApp/xApp onboarding, RAN scenario configuration and initialization, Key Performance Metric (KPM) collection, and closed-loop control validation. Experimental validation using Juniper RIC platforms and the Keysight RICtest emulation framework demonstrates ONDT ability to provide an isolated and reproducible environment for KPM monitoring, cell ON/OFF control, automated dataset generation, and rApp/xApp validation.

I. INTRODUCTION AND MOTIVATION

O-RAN’s split RIC architecture enables programmable control, but validating applications requires testing their interactions with RIC platforms, interfaces, telemetry, and RAN behavior. ONDT addresses this challenge with a cloud-native framework for repeatable O-RAN application and closed-loop experimentation.

I. INTRODUCTION AND MOTIVATION

  • O-RAN application validation must account for deployed software interacting with RIC platforms, service models, open interfaces, telemetry pipelines, and RAN behavior.Source: §I · p. 1
  • Offline datasets and physical platforms support evaluation, but complete O-RAN workflows still require alignment across RAN components, RICs, service models, configurations, and software versions [5].Source: §I · p. 1
  • Integrated testing is needed because coordinated rApp/xApp behavior depends on Non-RT and Near-RT logic interacting with the underlying RAN.The paper contrasts full cross-RIC control-loop testing with validating each application component in isolation.Source: §I · p. 2
  • Existing approaches include hardware-in-the-loop emulation, simulator-to-RIC integrations, and modular O-RAN digital-twin designs [12].Source: §I · p. 2
  • ONDT is a modular, virtualized, cloud-native framework for controlled O-RAN application validation, with workflows for onboarding, scenario execution, KPM collection, dataset generation, and control validation.It is validated using Juniper RIC and Keysight RICtest platforms.Source: §I · p. 2

II. ONDT ARCHITECTURE

ONDT connects the SUNRISE-6G experimentation platform to RICs and an emulated RAN through a microservice-based orchestration layer. Its components manage experiment lifecycle operations and translate requests into platform-specific RIC and emulator operations.

II. ONDT ARCHITECTURE

  • ONDT is a SUNRISE-6G 6G Enabler for controlled experimentation, dataset generation, and pre-deployment testing, focused on Near-RT RIC, Non-RT RIC, and an emulated RAN domain.Source: §II · p. 2
  • The ONDT layer translates high-level experiment requests into vendor-specific commands and is implemented as Kubernetes-orchestrated microservices, with NATS providing asynchronous communication and persistent state.Source: §II · p. 2
  • The Experiment Manager coordinates onboarding and deployment, topology initialization, experiment start and stop, and application offboarding.Source: §II · pp. 2–3
  • The SBI RIC component adapts ONDT requests to proprietary RIC APIs and supports application lifecycle and operation monitoring; its SUNRISE-6G implementation targets Juniper Non-RT and Near-RT RICs.Source: §II · p. 3
  • The SBI RAN emulator integrates with Keysight RICtest and supports topology control, result collection, and scenario configuration for sites, cells, slices, mobility, and traffic.Source: §II · p. 3
  • Prometheus supports runtime metric collection for monitoring and dataset generation, while ONDT workflows cover onboarding, topology loading, KPM collection, policy delivery, and E2-based control.Source: §II · p. 3

III. EXPERIMENTATION WORKFLOWS

ONDT provides reusable workflows for coordinating the Portal, orchestration layer, RIC platforms, and RAN emulation. The same lifecycle can be applied across use cases when the required applications and scenarios are available.

III. EXPERIMENTATION WORKFLOWS

  • ONDT workflows coordinate the SUNRISE-6G Portal, orchestration layer, RIC platforms, and RAN emulation layer.Source: §III · p. 3
  • The workflows are designed to be independent of a specific use case, provided the required rApps, xApps, and RAN scenarios are available.Source: §III · p. 3
  • Using a shared lifecycle, ONDT can select, deploy, execute, monitor, and terminate experiments.Source: §III · p. 3

A. Baseline Experiment Lifecycle

The baseline lifecycle establishes connectivity and discovers resources before the Portal launches a selected experiment. ONDT then retrieves results, makes them available through the Portal, and undeploys the applications.

A. Baseline Experiment Lifecycle

  • During establishment, ONDT checks connectivity with both RICs and the emulator, discovers available apps and scenarios, and exposes them for experiment selection in the Portal.Source: A. Baseline Experiment Lifecycle · p. 3
  • For an experiment, the Portal sends the selected rApp, xApp, scenario, and duration; ONDT starts the scenario and deploys each app in its corresponding RIC.Starting the scenario establishes E2 setup, while instantiating the rApp and xApp establishes A1 connectivity.Source: A. Baseline Experiment Lifecycle · pp. 3–4
  • At finalization, ONDT retrieves emulator results, stores them in the NATS.io database, forwards them to the Portal, and undeploys the rApp and xApp.Source: A. Baseline Experiment Lifecycle · p. 4

B. KPM Monitoring and Dataset Generation

ONDT supports experiment-specific KPM monitoring through E2 subscriptions and extends that workflow to dataset generation. Metrics are exposed through Prometheus for online observation and subsequent processing.

B. KPM Monitoring and Dataset Generation

  • The selected xApp subscribes to required E2 nodes, cells, and KPMs to collect use-case-specific measurements.After scenario initialization and E2 setup, it generates a RIC Subscription Request; accepted subscriptions produce KPM-bearing RIC Indication messages.Source: B. KPM Monitoring and Dataset Generation · p. 4
  • The xApp exports parsed metrics to Prometheus with 3GPP/O-RAN naming conventions and cell and node identifiers as labels.The Prometheus API supports filtering, aggregation, and averaging for online monitoring and subsequent data processing.Source: B. KPM Monitoring and Dataset Generation · p. 4
  • An optional dataset-generation rApp retrieves selected Prometheus metrics and stores them in Minio S3 as CSV files.The datasets can be used for ML-model training and evaluation.Source: B. KPM Monitoring and Dataset Generation · p. 4
  • The same KPM xApp and Dataset rApp can run alongside control-oriented rApps and xApps during control validation.This combines metric collection and storage with evaluation of control algorithms.Source: B. KPM Monitoring and Dataset Generation · p. 4

C. Closed-Loop Control

ONDT coordinates control xApps and rApps across the Near-RT and Non-RT RICs. The workflow converts collected KPMs into A1 policies and E2 control actions under repeatable emulated conditions.

C. Closed-Loop Control

  • After the scenario starts and E2 setup completes, the Near-RT control xApp subscribes to required KPMs and receives emulator indications.ONDT deploys the control xApp in the Near-RT RIC and the control rApp in the Non-RT RIC.Source: C. Closed-Loop Control · p. 4
  • The xApp publishes measurements to Prometheus, where the rApp retrieves metrics and generates an A1 policy that the xApp translates into E2 control actions.The control xApp sends those actions toward the O-RAN emulator.Source: C. Closed-Loop Control · pp. 4–5
  • ONDT validates complete cross-RIC control loops under repeatable emulated conditions and can combine control validation with monitoring and dataset generation.Telemetry collection and control validation can run simultaneously in the same experiment.Source: C. Closed-Loop Control · p. 5

IV. FUNCTIONAL VALIDATION

The validation tests whether ONDT can execute a complete O-RAN experimentation workflow for cell ON/OFF control, rather than optimize the control algorithm.

IV. FUNCTIONAL VALIDATION

  • The QoS-aware energy-saving validation uses selective cell ON/OFF control.The objective is to verify ONDT’s experimentation workflow, not to optimize the control algorithm itself.Source: §IV · p. 5
  • The workflow combines xApp-based KPM collection, rApp-assisted policy generation, A1 policy delivery, and E2-based control.Source: §IV · p. 5
  • The validation executes this workflow over an emulated RAN scenario.Detailed design and evaluation of the AI/ML model are outside this paper’s scope and are reported in prior work [5].Source: §IV · p. 5

A. Scenario Generation and Use Case

The scenario reproduces traffic evolution from an operational MNO dataset for repeatable monitoring and closed-loop experiments. The reported KPMs show varying cell loads and mostly maintained target throughput, with transient simulator dips excluded as unrepresentative.

A. Scenario Generation and Use Case

  • The scenario derives target-cell load profiles from an operational MNO dataset and converts them into JSON configuration for the Keysight RICtest emulator.The emulated traffic fixes throughput per UE to the target QoS level and varies active UE counts over time to reproduce the day-night pattern.Source: A. Scenario Generation and Use Case · p. 5
  • The validation selectively deactivates capacity cells during low-load periods while maintaining service through coverage infrastructure, subject to operator-defined QoS requirements.The control setup instantiates a representative workflow; detailed AI/ML model design and evaluation are outside the paper’s scope [5].Source: A. Scenario Generation and Use Case · p. 5
  • Each emulated site combines a 100 MHz 5G capacity cell with associated 50 MHz coverage cells, and three sites represent high, moderate, and light loads.The selected scenario uses a 5 Mbps requested throughput and 15% outage tolerance over 72 hours, with aggregate peaks of 1,000 active UEs and 4 Gbps.Source: A. Scenario Generation and Use Case · p. 5
  • The UE-throughput plot shows the emulated scenario maintains the target service level most of the time, while low-throughput peaks are transient simulator effects.The upper plot reports downlink PRB usage across selected coverage and capacity cells; the lower plot reports average downlink throughput per UE.Source: A. Scenario Generation and Use Case · p. 5, Figure 5 · p. 5

B. Evaluated control-logic and validation results

The evaluated control loop uses rApp decisions based on E2-KPM measurements to switch capacity cells off or back on, with stable observations used to avoid ping-pong. Validation reported energy savings alongside increased throughput outage and verified the complete workflow, while detailed AI/ML and optimization evaluation remained out of scope.

B. Evaluated control-logic and validation results

  • The rApp switches capacity cells off using ML inference on recent PRB usage and back on when measured UE throughput violates the outage constraint.Stable metric values must persist over a defined period to avoid instability and ping-pong effects.Source: B. Evaluated control-logic and… · p. 5
  • The rApp expresses energy-saving policies through A1 esObjectives and esPercentage fields, which the xApp maps to E2-CCC messages.The xApp uses the O-CESManagementFunction structure for that mapping.Source: B. Evaluated control-logic and… · pp. 5–6
  • Approximately 35% average energy savings came at the cost of a 3–4 percentage-point increase in throughput outage.Figure 6 summarizes the selected-cell behavior and the impact of the control decisions.Source: Figure 6 · p. 6, B. Evaluated control-logic and… · p. 6
  • The validation verified complete workflow execution and output collection, but detailed AI/ML-model, control-logic, and energy-saving-versus-QoS evaluation was outside the paper’s scope.The workflow includes E2-KPM telemetry, Prometheus metrics, Non-RT policy generation and A1 delivery, xApp processing, and E2 control toward the emulator.Source: B. Evaluated control-logic and… · p. 6

V. CONCLUSION

ONDT coordinates the Portal, RIC platforms, and RAN emulation for repeatable xApp/rApp experimentation, including onboarding, scenario execution, KPM monitoring, dataset generation, and control. Validation demonstrated complete workflow execution over dataset-based RAN scenarios; future work targets broader scenarios and adapters and improved automation.

V. CONCLUSION

  • ONDT coordinates the SUNRISE-6G Portal, RIC platforms, and RAN emulation to run repeatable xApp/rApp experimentation workflows.These workflows cover onboarding, scenario execution, KPM monitoring, dataset generation, A1 policy delivery, and E2-based control.Source: §V · p. 6
  • Validation with Juniper Non-RT and Near-RT RICs and the Keysight RICtest emulator demonstrated complete workflow execution over dataset-based RAN scenarios.The validation used an AI-driven QoS-aware energy-saving control loop.Source: §V · p. 6
  • Future work targets additional scenarios and southbound adapters, plus improved automation of experiment configuration, execution, and result analysis.Source: §V · p. 6
Loading 2610.07889v1…