Title: RANPilot: Making AI Functionalities Robust to Dynamic O-RAN Reconfigurations
Authors: Shiming Yu, Leming Shen, Jianing Zhang, Xin Li, Xianjin Xia, and Yuanqing Zheng (The Hong Kong Polytechnic University); Yaxiong Xie (University at Buffalo, SUNY)
Introduction
O-RAN makes cellular infrastructure modular, programmable, and dynamically reconfigurable, while RIC-hosted AI models increasingly control functions such as resource allocation, handover, and anomaly detection. Unfortunately, a planned hardware, topology, parameter, or policy change can shift the distribution and causal structure of Key Performance Measurements (KPMs), invalidating a model trained on the old configuration. The authors observe that even though only about 8% of post-reconfiguration traffic differs strongly from old training data, failures concentrate in this critical subset; reactive collection and retraining then leave AI services degraded for roughly 20-31 minutes. Generic continual learning, domain adaptation, noise augmentation, and PHY-oriented digital twins fall short because they either need post-change data or fail to reproduce the system-level interactions that create the important drift.
Key idea and contribution:
RANPilot changes AI adaptation from reactive recovery to proactive preparation. Given an operator’s planned reconfiguration, it constructs a lightweight, trace-driven “virtual O-RAN” that abstracts CUs, DUs, RUs, links, control policies, and their interactions. Seed KPM traces preserve site-specific channel and workload characteristics, while the emulator applies the future topology and control behavior to synthesize post-change training data before the physical network changes. This focuses fidelity on data- and control-plane dynamics rather than expensive waveform-level reconstruction.
RANPilot further uses a Transformer-based meta-augmentation model to expand the synthetic traces and inject operational dynamics learned across prior configurations. After deployment, importance-aware incremental learning selects informative live KPMs to close the remaining simulation-to-reality gap quickly. Heavy synthesis and augmentation run in the non-real-time RIC, isolated from time-sensitive control loops, while a lightweight near-real-time xApp collects KPMs. The authors implement the framework with srsRAN, Open5GS, and the O-RAN Software Community RIC and apply it to QoE prediction, reinforcement-learning-based resource allocation, and anomaly detection.
Evaluation
The evaluation uses more than 30 million KPM measurement points (over 60 metrics each) and over-the-air experiments on a live 5G O-RAN testbed across indoor and outdoor deployments, six reconfiguration scenarios, and three downstream AI tasks. RANPilot’s synthesized traces more closely reproduce live post-change distributions and transient fluctuations than an O-RAN digital-twin baseline. It reduces AI downtime by roughly 85-94% overall: QoE-model recovery after cell addition falls from 29 minutes to 1.7 minutes, anomaly detectors start at 89.1-97.5% accuracy and recover in 1.3-2.4 minutes rather than 19.6-23.7 minutes, and the resource allocator approaches Oracle performance immediately before resolving residual gaps within four minutes. This result is significant because it turns a planned O-RAN upgrade from a prolonged AI outage into a short calibration period, making frequent reconfiguration more compatible with AI-controlled network operation.
Q1: Could you clarify what you mean by RAN reconfiguration, perhaps with a few examples? Also, how frequently do RAN reconfigurations occur?
A1: Reconfiguration means making changes to the RAN system, either at the hardware level or the software level. For example, to improve cellular coverage, an operator may add a new cell, modify cell parameters, or adjust transmit and receive gains.
On the software side, operators may change control policies. This is particularly relevant to O-RAN, which provides many programmable functions, such as handover control and resource scheduling. These software-based control functions can be flexibly reconfigured. We consider any such hardware, parameter, topology, or software-policy change to be a RAN reconfiguration.
Q2: What are some examples of cell parameters or configurations that might be changed?
A2: A typical cell tower currently has approximately one to four cells. Reconfiguration may involve adding a cell, modifying the cell topology, or changing neighboring-cell connections and relationships. These changes are all considered RAN reconfigurations.
I should note that reconfiguration does not occur very frequently in today’s cellular networks. It may happen every few months or perhaps once every six months. However, in future systems, as the RAN software stack becomes increasingly software-defined and programmable, there will be more opportunities to reconfigure the network.
For example, operators may need to support more users, accommodate different mobility patterns, or adapt to fine-grained changes in application scenarios. Reconfiguring a traditional RAN is expensive, but a software-based RAN provides more opportunities to adjust the system dynamically so that it can better serve changing application requirements.
Q3: Many types of reconfiguration can occur in a RAN. From our experience with AT&T, we have observed that the same reconfiguration can produce different behavior at different locations. Modeling this behavior requires a large amount of data, and many attributes—such as frequency, bandwidth, and neighboring-cell relationships—can affect the outcome.
You mentioned that your virtual O-RAN synthesizes network behavior and attempts to approximate the real system. How large is the gap between the synthetic traces and real-world traces, and what can you do to reduce that gap?
A3: We discuss the applicability and limitations of our data-synthesis approach in the paper. Many factors can affect synthesis fidelity, including seasonal patterns, user traffic, mobility, radio conditions, and other properties of the physical environment.
If this environmental complexity is not represented in the seed KPM traces, the synthesized data may not be sufficiently accurate. Our approach relies on the seed KPMs to capture these external factors and real-world variations. This is a general challenge for the cellular-networking community. For example, when an operator deploys a cell tower at a completely new site, predicting its performance and tuning the RAN parameters in advance are inherently difficult problems.
Our current solution focuses on reconfigurations at the level of an existing cell tower. We assume that the environmental conditions remain broadly consistent before and after the reconfiguration, and that the primary changes occur within the RAN system itself. Under this assumption, we can construct a virtual system and inject domain knowledge and external-factor models to translate behavior from the old configuration to the new one.
In other words, our current method is most applicable when the changes are limited to RAN hardware, topology, parameters, or software policies. If major external factors also change—for example, if a cell tower is deployed at a completely new site—we would need to integrate RANPilot with other advanced techniques, such as physical-layer forecasting and site-specific propagation modeling.
Personal thoughts
I like the paper’s formulation of “AI downtime” as a first-class operational cost. The insight that a small but behaviorally important slice of drift defeats global distribution alignment is persuasive, and the separation between structural emulation, learned augmentation, and targeted online calibration gives each component a clear role. The use of three AI applications and explicit ablations also provides stronger evidence than evaluating a single predictor.
The key limitation is that proactive adaptation depends on advance knowledge and representative seed traces, so the system is best viewed as part of a change-management pipeline rather than a general robustness solution. The experiments are also centered on an individual base station with one to four cells. Future work should test cross-site and multi-vendor transfer, simultaneous software and radio changes, massive-MIMO and beamforming policies, and uncertainty-aware admission rules that can decide when synthesized data is not trustworthy enough to activate a prepared model. Comparing the offline preparation cost and operator effort against safer staged or canary deployments would further clarify the operational tradeoff.