O-RAN RIC and xApps: Building Programmable Intelligence for the RAN

The RIC: Programmable Brain of the RAN

Traditional RANs operate on vendor-embedded algorithms: handover, scheduling, and power control logic are hardcoded into proprietary baseband software. Operators have limited ability to customize behavior beyond parameter tuning. The O-RAN Alliance's RAN Intelligent Controller (RIC) changes this paradigm by externalizing RAN intelligence into a programmable platform.

The RIC comes in two variants:

• Near-RT RIC: Operates on a 10 ms to 1 second control loop. Hosts xApps that make per-UE, per-cell decisions such as traffic steering, QoS optimization, and interference mitigation.
• Non-RT RIC: Operates on a > 1 second control loop (typically minutes to hours). Hosts rApps that handle policy management, ML model training, and RAN analytics enrichment.

This architecture is specified in the O-RAN Alliance's O-RAN.WG2.RIC-Architecture and O-RAN.WG3.E2AP documents. 3GPP provides the underlying RAN protocol foundation through TS 38.300 (NR overall description), while the O-RAN specifications define the open interfaces that expose RAN data and control to the RIC.

Architecture and Interfaces

RIC Interface Overview

E2 Service Models (E2SM)

E2SMs define what data the RIC can collect and what control actions it can issue. Each E2SM is a self-contained specification:

E2SM-KPM and E2SM-RC are the most widely deployed. E2SM-KPM v3.0 supports over 50 measurement types aligned with 3GPP TS 28.552 (performance measurements). E2SM-RC v1.03 supports 12 control action types including handover, scheduling, and slicing resource allocation.

xApp Architecture and Lifecycle

An xApp is a containerized application that runs on the Near-RT RIC platform. It follows a standardized lifecycle:

1. Onboarding: xApp descriptor (JSON/YAML) registered with the Near-RT RIC. Descriptor specifies E2SM subscriptions, resource requirements, and A1 policy types consumed.
2. Deployment: Kubernetes creates xApp pod on the RIC cluster. RIC framework provisions the xApp's E2 subscriptions with target E2 nodes.
3. Subscription: xApp subscribes to E2SM-KPM indications for specific UE/cell measurements via the E2 interface.
4. Execution: xApp receives periodic RAN data (e.g., per-UE RSRP every 100 ms), runs its algorithm, and issues E2SM-RC control messages.
5. Termination: xApp unsubscribes from E2 indications, pod is deleted.

xApp Internal Components

Worked Example 1 -- Traffic Steering xApp

Scenario: Operator Z has co-located 5G NR cells at 3.5 GHz (n78, 100 MHz) and 700 MHz (n28, 20 MHz). During peak hours, the n78 cell is congested (PRB utilization > 85%) while n28 is underutilized (PRB utilization 40%). A traffic steering xApp rebalances load. Algorithm Design:

The xApp implements a threshold-based steering policy with hysteresis:

• Input (E2SM-KPM, every 200 ms per UE):

- Serving cell PRB utilization: U_serving

- Target cell SS-RSRP for each UE: RSRP_target

- UE DL throughput: T_dl

- UE QoS requirements (from A1 policy): T_min (minimum guaranteed throughput)

• Steering decision for each UE:

1. If U_serving > 85% AND RSRP_target > -100 dBm AND T_dl < T_min:

- Issue E2SM-RC handover control to move UE to n28 cell

2. If U_serving < 60% AND UE was previously steered:

- Move UE back to n78 for higher throughput

Numerical Walk-Through:

Time T=0:
  n78 cell PRB utilization: 88%
  UE-1: RSRP(n78)=-75 dBm, RSRP(n28)=-82 dBm, DL throughput=8 Mbps, QoS T_min=15 Mbps
  UE-2: RSRP(n78)=-92 dBm, RSRP(n28)=-78 dBm, DL throughput=3 Mbps, QoS T_min=5 Mbps

Decision:
  UE-1: U_serving(88%)>85% ✓, RSRP_target(-82)>-100 ✓, T_dl(8)<T_min(15) ✓ → STEER to n28
  UE-2: U_serving(88%)>85% ✓, RSRP_target(-78)>-100 ✓, T_dl(3)<T_min(5) ✓ → STEER to n28

Time T=5s (after steering):
  n78 cell PRB utilization: 62%
  n28 cell PRB utilization: 58%
  UE-1 on n28: DL throughput = 18 Mbps (meets QoS)
  UE-2 on n28: DL throughput = 12 Mbps (meets QoS)

The xApp issues E2SM-RC Control Request messages with Action ID = HANDOVER containing the target cell Global Cell ID and UE ID. The O-CU-CP executes the handover via Xn or N2 procedures.

E2SM-RC Control Message Structure:

E2SM-RC Control Header:
  ueID: gNB-CU-UE-F1AP-ID = 1001
  ricControlAction: HANDOVER
E2SM-RC Control Message:
  targetCellGlobalID: PLMN(310/260) + NR-Cell-ID(n28-cell-12)
  handoverType: intra-gNB

Worked Example 2 -- QoS-Aware Scheduling xApp

Scenario: An enterprise slice (S-NSSAI: SST=1, SD=000010) requires guaranteed 50 Mbps per user for an AR application. The scheduling xApp adjusts per-UE scheduling weights via E2SM-RC. Algorithm:

• Every 100 ms, the xApp reads per-UE throughput from E2SM-KPM
• For UEs on the enterprise slice with T_dl < 50 Mbps:

- Calculate deficit: D = (50 - T_dl) / 50

- New scheduling weight: W_new = W_base (1 + 2 D)

- Issue E2SM-RC scheduling weight update

Numerical Walk-Through:

UE-A (enterprise slice): T_dl = 32 Mbps, W_base = 1.0
  Deficit D = (50 - 32)/50 = 0.36
  W_new = 1.0 * (1 + 2*0.36) = 1.72

UE-B (enterprise slice): T_dl = 48 Mbps, W_base = 1.0
  Deficit D = (50 - 48)/50 = 0.04
  W_new = 1.0 * (1 + 2*0.04) = 1.08

UE-C (consumer slice): T_dl = 25 Mbps, W_base = 1.0
  No adjustment (different slice, not managed by this policy)

After weight adjustment (next scheduling period):
  UE-A: T_dl improves to 49 Mbps (weight increased scheduler allocation)
  UE-B: T_dl remains at 50 Mbps (minimal adjustment needed)

Operator Deployment Results

Dish Network (US) -- O-RAN Native Deployment

Dish Network built the first greenfield O-RAN 5G network in the US:

• RIC Vendor: VMware (now Broadcom) RIC platform
• xApps deployed: Traffic steering, interference management, energy saving
• E2 nodes: Fujitsu O-RU + Mavenir O-DU/O-CU across 70+ markets
• Traffic steering result: 22% reduction in cell-edge user throughput variance
• Control loop latency: Average 45 ms E2 round trip (subscription to control acknowledgment)
• Scale: 15,000+ E2 connections managed by regional RIC clusters

Vodafone (Europe) -- Near-RT RIC in Brownfield

Vodafone deployed Near-RT RIC across select markets in Europe:

• RIC Vendor: Nokia RIC with third-party xApps (Rimedo Labs, Capgemini)
• Use case: Energy saving xApp that reduces n78 transmit power during low-traffic hours
• Result: 18% energy reduction in RAN during off-peak (midnight to 6 AM) with < 1% throughput degradation to active users
• Deployment model: RIC runs at regional data centers, E2 interface over operator MPLS transport
• A1 policy: Non-RT RIC sets energy saving targets per cell based on traffic forecasts from rApp ML model

Rakuten Mobile (Japan) -- Full Stack O-RAN

Rakuten's fully virtualized O-RAN network provides the largest-scale reference:

• RIC: In-house RIC platform (Rakuten Symphony)
• xApps: 8 active xApps including traffic steering, MRO (Mobility Robustness Optimization), load balancing, and anomaly detection
• MRO result: Handover failure rate reduced from 1.8% to 0.4% through real-time A3 event threshold optimization via E2SM-RC
• xApp conflict resolution: Implemented priority-based arbitration when multiple xApps issue conflicting E2 controls for the same UE

rApps and the Non-RT RIC

rApps operate on longer timescales and provide strategic intelligence:

The A1 interface carries two types of messages:

1. A1 Policy: Non-RT RIC sets target KPIs or constraints (e.g., "minimum cell-edge throughput = 10 Mbps") that guide xApp behavior.
2. A1 Enrichment Information: Non-RT RIC delivers contextual data (e.g., traffic predictions, ML models) to xApps.

Challenges and Future Direction

1. E2 interface scalability: Each UE-level subscription generates significant data volume. At 200 ms reporting intervals with 1,000 UEs per cell and 50 cells per RIC, the E2 data rate exceeds 100 Mbps. E2SM-KPM v3.0 supports aggregation and filtering to reduce this.

1. xApp conflict management: When a traffic steering xApp and energy saving xApp issue conflicting controls for the same cell, the RIC's conflict mitigation function (O-RAN WG2) must arbitrate. Current solutions use priority-based ordering, but AI-driven multi-objective optimization is being researched.

1. Multi-vendor interoperability: Despite O-RAN specifications, E2 interface interoperability between vendors remains challenging. The O-RAN Software Community (OSC) provides a reference implementation (RIC "I" Release), but production interoperability requires extensive testing. The O-RAN TIFG (Testing and Integration Focus Group) administers plugfest events to validate compliance.

1. Real-time ML inference: xApps using deep learning models must complete inference within the 10 ms--1 s control loop. GPU acceleration on the RIC platform, ONNX Runtime optimization, and model quantization (INT8) are common approaches. Rakuten achieved 4.2 ms inference latency for their traffic steering neural network using ONNX on CPU.

> Key Takeaway: The O-RAN RIC transforms the RAN from a closed, vendor-locked system to a programmable platform where operators and third parties deploy custom intelligence via xApps and rApps. E2SM-KPM and E2SM-RC provide the standardized data and control interfaces. Real deployments by Dish (greenfield), Vodafone (brownfield), and Rakuten (full-stack) demonstrate measurable gains in traffic steering, energy saving, and mobility optimization. The key challenge is scaling E2 data flows and resolving multi-xApp conflicts in real time.