If you work in O-RAN, you have heard both terms in the same sentence dozens of times — near-RT RIC and non-RT RIC. They sound similar. They both appear in O-RAN Alliance architecture diagrams. They both involve intelligence and control of the radio network. But they are architecturally very different — and confusing them leads to poor xApp design decisions.
In this article we explain exactly what separates them, what each one can and cannot do, and what this means for teams deploying xApps on O-RAN infrastructure.
The Question That Comes Up on Every O-RAN Project
Tech Expert: Hi Mohamed, I have a question for you.
Me: Go ahead.
Tech Expert: near-RT RIC and non-RT RIC — they sound similar. What is actually different between them?
Me: One word — latency. And that determines everything.
That one word — latency — is the architectural dividing line. It determines what each RIC can control, what interfaces it uses, and what types of xApps can run on it.
O-RAN Architecture — Where the Two RICs Sit
Before comparing them, it helps to understand where each RIC sits in the O-RAN Alliance reference architecture. The architecture defines three control planes operating at different timescales:
Non-RT RIC — SMO Layer
Controls the near-RT RIC via A1 interface · AI/ML training · Long-term policy
Near-RT RIC
Controls O-DU/O-CU via E2 interface · xApps · Real-time optimization
O-DU / O-CU — Real-time scheduler
Symbol scheduling · HARQ · Beamforming · No RIC involvement at this level
Non-RT RIC — The Policy Brain (> 1 second)
The non-RT RIC (non-real-time RIC) is part of the SMO — Service Management and Orchestration layer. It operates on control loops longer than 1 second, meaning it is not involved in real-time radio decisions. Instead it handles:
- AI/ML model training: trains machine learning models on historical network data (traffic patterns, interference, mobility) and pushes trained models down to the near-RT RIC
- Long-term policy management: defines high-level optimization goals (energy saving targets, coverage objectives, slice SLA thresholds) that the near-RT RIC enforces
- A1 interface: the interface between non-RT RIC and near-RT RIC — carries policy intents and ML model updates downward, and performance feedback upward
- rApps: applications running on the non-RT RIC, analogous to xApps on the near-RT RIC but operating at longer timescales
Near-RT RIC — The Real-Time Optimizer (10ms – 1 second)
The near-RT RIC operates in the 10 millisecond to 1 second control loop range — fast enough to react to real network events, but not so deep in the stack that it conflicts with the real-time scheduler. It sits between the SMO and the O-DU/O-CU and controls RAN elements via the E2 interface.
- Load balancing: detects overloaded cells and redistributes UEs to neighbor cells within 100ms
- Handover optimization: adjusts handover parameters dynamically based on real-time UE mobility patterns
- per-UE QoS enforcement: monitors per-UE throughput and adjusts scheduling priority in near-real-time
- E2 interface: carries E2 Service Models (E2SM) — standardized data formats for reports, policies and control messages between the near-RT RIC and O-DU/O-CU
What is an xApp — and How Does It Work?
Tech Expert: And what is an xApp exactly?
Me: An xApp runs on the near-RT RIC. It subscribes to E2 performance reports from O-DU/O-CU and sends control actions back in near-real-time. One xApp = one optimization function.
An xApp is a microservice application deployed on the near-RT RIC platform. Each xApp is designed to handle one specific optimization use case. The xApp lifecycle follows a simple pattern:
| Step | Action | Interface |
|---|---|---|
| 1 — Subscribe | xApp subscribes to E2 reports (PRB utilization, RSRP, handover events) | E2 (near-RT RIC ↔ O-DU/O-CU) |
| 2 — Receive | O-DU sends periodic or event-triggered E2 indication messages | E2 indication |
| 3 — Decide | xApp logic processes the data and determines a control action | Internal xApp logic |
| 4 — Control | xApp sends E2 control message to O-DU/O-CU to adjust parameters | E2 control |
Complete Comparison — non-RT RIC vs near-RT RIC
| Parameter | Non-RT RIC | Near-RT RIC |
|---|---|---|
| Control loop | > 1 second | 10ms – 1 second |
| Architecture layer | SMO layer | Between SMO and O-DU/O-CU |
| Key interface | A1 (to near-RT RIC) | E2 (to O-DU/O-CU) |
| Application type | rApp | xApp |
| Primary functions | AI/ML training · policy mgmt · model push | Load balancing · HO opt · QoS per UE |
| Typical example | Train traffic model → push policy via A1 | Detect congestion → redistribute PRBs in 100ms |
| Can replace real-time scheduler? | No | No — guides it only |
Key Takeaways
- The only thing that separates non-RT RIC from near-RT RIC is control loop latency — and that determines everything else
- Non-RT RIC operates at >1 second — it is the policy brain, not a real-time controller
- Near-RT RIC operates at 10ms–1s — it is the real-time optimizer, controlling O-DU/O-CU via E2
- xApps run on the near-RT RIC — one xApp = one optimization function
- Nothing faster than 10ms can be offloaded to the RIC — the O-DU/O-CU real-time scheduler is not replaceable
- When designing xApps, always validate your control loop latency requirement first — it determines which RIC tier your application belongs to
O-RAN Alliance References
- O-RAN.WG2.A1AP — A1 interface: Application Protocol (non-RT RIC ↔ near-RT RIC)
- O-RAN.WG3.E2AP — E2 interface: Application Protocol (near-RT RIC ↔ O-DU/O-CU)
- O-RAN.WG3.E2SM-KPM — E2 Service Model: KPM (Key Performance Metrics reporting for xApps)
- O-RAN.WG1.OAD — O-RAN Architecture Description (overall reference architecture)
🎓 Want to master O-RAN architecture and xApp design?
Our Open RAN Advanced Course on 5GWorldPro covers the full O-RAN architecture,
near-RT RIC · non-RT RIC · xApp development · A1 · E2 interfaces — with real deployment scenarios.
Benefit from Massive discount on our 5G Training with 5WorldPro.com
Start your 5G journey and obtain 5G certification
contact us: contact@5GWorldPro.com
