ArchitectureTechnology, Media & Telecommunications

AI in the radio access network: O-RAN RICs, xApps, rApps and the guardrails around them

In O-RAN, AI reaches the radio network through two intelligent controllers: the Non-RT RIC inside the service management and orchestration layer runs rApps for slower policy loops, and the Near-RT RIC runs xApps that act on base stations within a sub-second window. Choosing the right loop, keeping apps from fighting each other and making every policy change reversible matter more than the model itself.

Reviewed 8 min read

On this page
  1. Why operators are moving models into the radio access network
  2. O-RAN components from orchestration down to the radio unit
  3. The interfaces that carry policy, telemetry and models
  4. Matching a RAN problem to the control loop that should own it
  5. Running the model lifecycle for a RIC application
  6. Conflicts, drift and other ways RIC apps degrade a network
  7. Where NWDAF fits next to the RIC on the core side
  8. A hypothetical energy-saving rApp with KPI guardrails
  9. Questions and answers
  10. Sources

Why operators are moving models into the radio access network

The radio access network is where most of a mobile operator's energy, spectrum and field cost sits, and it is managed through thousands of parameters per site that engineers once tuned by hand or through vendor self-organizing network features. Those features work, but they are usually closed: the operator cannot see the logic, swap it out or combine signals from another vendor's equipment.

O-RAN changes that by defining open interfaces and two controllers that host third-party applications. The practical consequence is that an operator, or a firm it hires, can write a model that decides when to put a capacity layer to sleep or how to steer traffic between carriers, and deploy it across mixed-vendor equipment under the operator's own policy. The risk is the same openness: a badly behaved app now has a legitimate path to change live network behavior.

O-RAN components from orchestration down to the radio unit

Read the stack top to bottom: slower, wider decisions at the top, faster and more local ones further down.

SMO and Non-RT RIC01Near-RT RIC02O-CU (CP and UP)03O-DU04O-RU05O-Cloud06
  1. SMO and Non-RT RIC

    Service management and orchestration hosts the Non-RT RIC, which runs rApps, trains and stores models and sends policy over A1.

  2. Near-RT RIC

    Hosts xApps that read fine-grained RAN data and send control actions to RAN nodes over E2.

  3. O-CU (CP and UP)

    Central unit handling higher-layer control and user-plane protocols; an E2 node.

  4. O-DU

    Distributed unit running real-time scheduling and lower-layer processing; also an E2 node.

  5. O-RU

    Radio unit at the antenna; connected to the O-DU over the open fronthaul.

  6. O-Cloud

    The cloud platform that hosts virtualized RAN functions and RIC software, managed by the SMO over O2.

Conceptual layering of the main O-RAN functions, simplified from the O-RAN Alliance architecture as described in the cited sources. It is not a deployment diagram for any specific operator.

The interfaces that carry policy, telemetry and models

A1
Connects the Non-RT RIC to the Near-RT RIC. It carries declarative policies, enrichment information and model guidance to xApps and returns policy status2.
E2
Connects the Near-RT RIC to E2 nodes such as the O-CU and O-DU. xApps subscribe to measurements over it and send control or policy actions back1.
O1
The management interface between the SMO and O-RAN managed elements, used for configuration, fault and performance management3.
O2
Connects the SMO to the O-Cloud for infrastructure and workload management, such as instantiating a RIC or a virtualized DU1.
R1
Sits between rApps and the services of the SMO and Non-RT RIC, so an rApp can reach data, model and policy services without vendor-specific integration2.
xApp and rApp
An xApp is a plug-in to the Near-RT RIC; an rApp is an application hosted by the Non-RT RIC. Both are where third-party AI logic lives23.

Matching a RAN problem to the control loop that should own it

The Non-RT RIC works on timescales above one second and the Near-RT RIC between roughly ten milliseconds and one second; anything faster stays in the DU's own scheduler1.

ProblemrApp in the Non-RT RICxApp in the Near-RT RICVendor DU or RU logic
Cell and carrier sleep for energy savingForecast load and set sleep policy per clusterWake a carrier quickly if load spikesExecutes the switch and protects the radio
Traffic steering between layersSet steering preferences by area and timeSteer individual users or groupsApplies the resulting priorities
Mobility and handover tuningLearn neighbor and offset settings from historyAdjust per-cell parameters within boundsPerforms the handover
Anomaly and sleeping-cell detectionCorrelate counters and alarms across sitesFlag sudden degradation for fast mitigationRaises the alarms and counters
Per-slot schedulingNot suitablePolicy guidance onlyOwns it; too fast for either RIC

Most first deployments start with rApps: slower loops are easier to test, explain and roll back, and they need less integration with each vendor's E2 support.

Running the model lifecycle for a RIC application

  1. Define the KPI contract

    Write down the target KPI, the guardrail KPIs that must not degrade (accessibility, retainability, throughput at the cell edge) and the cells the app may touch. This becomes the app's acceptance test and its kill switch condition.

    Output
    KPI and guardrail specification
    Owner
    RAN optimization lead

  2. Collect and label the data

    Pull performance counters, configuration history and alarms over O1, and finer E2 measurements where an xApp needs them. Record every manual parameter change in the period, or the model will learn engineers' interventions as natural behavior.

    Output
    Versioned training dataset
    Owner
    Network data engineering

  3. Train away from the network

    Train in the SMO's training host or a separate platform, then test against a network simulator or digital twin and against replayed history from the target cluster.

    Output
    Candidate model with offline results
    Owner
    Data science

  4. Shadow, then a bounded cluster

    Run the app in recommend-only mode first, comparing its proposals with what engineers did. Then let it act on a small, well-instrumented cluster with automatic rollback when a guardrail KPI breaches.

    Output
    Shadow report and cluster trial results
    Owner
    RAN operations

  5. Widen under change control

    Extend by cluster through the operator's normal change process, respecting freeze windows. Policy changes that alter how the app behaves need the same approval as a parameter change made by a person.

    Output
    Change records per expansion
    Owner
    Network change board

  6. Monitor drift and retrain

    Track model inputs and guardrail KPIs continuously. Vendor software upgrades, new spectrum and new sites all shift counter behavior, so plan retraining around them rather than on a fixed calendar.

    Output
    Drift dashboard and retraining triggers
    Owner
    Data science with RAN operations

Conflicts, drift and other ways RIC apps degrade a network

Direct conflicts between apps

Early signalTwo apps write different values to the same parameter on the same cell, or request more resources than exist.

MitigationUse the RIC's conflict mitigation to resolve before action, with an explicit priority order per parameter1.

Indirect and implicit conflicts

Early signalAn energy-saving app and a mobility app each meet their own target while cell-edge users degrade.

MitigationVerify after action by monitoring shared guardrail KPIs and rolling back the most recent change first1.

Model drift after a vendor upgrade

Early signalRecommendations change sharply in clusters that received new software, with no change in traffic.

MitigationPin model versions to software baselines and pause automatic action in clusters mid-upgrade.

Opaque third-party apps

Early signalThe app vendor cannot say which inputs drove a decision or how to reproduce it.

MitigationRequire decision logs with inputs, model version and policy in force as a condition of onboarding.

Data leaving the operator's control

Early signalAn app needs subscriber-level measurements sent to an external cloud for inference.

MitigationKeep inference inside the operator's O-Cloud and aggregate or pseudonymize before any external training.

Where NWDAF fits next to the RIC on the core side

The RIC is a radio construct. In the 5G core, analytics are standardized separately through the Network Data Analytics Function (NWDAF), specified in 3GPP TS 23.288, which collects data from core network functions and provides statistics and predictions to consumers such as policy control and session management4.

The two complement each other. NWDAF sees sessions, slices and user-plane behavior; the RIC sees radio conditions. An operator running slice assurance, for example, gets better results when core analytics on slice load inform radio policy, and when RAN congestion predictions feed back to core policy. Design that exchange deliberately, through the SMO and the operator's data platform, rather than letting each vendor's analytics run in isolation.

A hypothetical energy-saving rApp with KPI guardrails

Questions and answers

Do we need a full Open RAN deployment to run RIC applications?

Not necessarily. rApps mainly use O1 data and A1 policy, and several RAN vendors expose those on otherwise single-vendor networks, so an operator can start with non-real-time use cases on existing equipment. Near-RT xApps depend on E2 support in the installed base, which varies by vendor and software release, so check that first before planning any sub-second use case.

How should xApps and rApps be tested before they touch live cells?

Combine three layers: offline evaluation on replayed history from the target clusters, testing against a simulator or digital twin with the same parameter ranges, and a shadow period in which the app proposes actions that engineers compare with what they would do. Only then let it act on a bounded cluster with automatic rollback on guardrail KPIs.

What network data has to leave the operator for RIC apps to work?

Ideally none. Inference can run on the operator's own O-Cloud, and training can use aggregated cell-level counters. Where an app vendor wants subscriber-level measurements for training, treat it like any other processing of traffic and location data: check the lawful basis, minimize and pseudonymize, and keep the data within agreed jurisdictions.

Can an rApp from one vendor run on another vendor's SMO?

That is the purpose of the R1 interface, which gives rApps a standard way to reach SMO and Non-RT RIC services. In practice, portability depends on how completely each platform implements it, so ask for a demonstration on your chosen SMO, not a roadmap slide, before buying an app.

Sources

  1. Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges (Polese, Bonati, D'Oro, Basagni, Melodia) — arXiv · checked 10 October 2026
  2. Non-RealTime RIC overview — O-RAN Software Community · checked 10 October 2026
  3. O-RAN SC architecture — O-RAN Software Community · checked 10 October 2026
  4. 3GPP TS 23.288: Architecture enhancements for 5G System (5GS) to support network data analytics services — 3GPP · checked 10 October 2026

More in Technology, Media & Telecommunications

Back to Technology, Media & Telecommunications

Next step

Send us one RAN use case and your counters for a RIC feasibility read

Describe the problem, the vendors in the target clusters and which interfaces they expose. We will tell you which loop it belongs in, what data it needs and how to trial it safely.

Discuss a RAN use case