The RIC is where learned control plugs into an open RAN. This is the near-real-time platform that hosts xApps, terminates E2 to the CU and DU, and resolves the conflicts between apps — the programmable control plane that pulls RAN optimisation out of each vendor's base station.
Historically the logic that optimises a radio network was locked inside each vendor's base station. The RIC opens it: a platform where operators and third parties run applications that read live RAN telemetry and apply control. The near-real-time RIC works between about ten milliseconds and a second — fast enough to matter, over an open interface.
It is an application platform. xApps — traffic steering, interference management, admission control, energy saving — run on it and act on the RAN over E2, each through an E2 service model that defines what it may read and set. The platform handles the hard shared problems: conflict mitigation when two xApps want the same parameter, resource isolation, and keeping every app inside its latency budget.
Above it, the non-real-time RIC trains models and sets policy, pushing them down over A1. Together they are how AI-for-RAN reaches the network: slow learning on top, fast bounded control underneath.
| Parameter | Detail |
|---|---|
| Type | Near-real-time RIC (10 ms – 1 s); pairs with a non-RT RIC in the SMO |
| Apps | Hosts third-party and in-house xApps; onboarding, lifecycle and isolation |
| Southbound | E2 termination to O-CU and O-DU; E2 service models (KPM, RC and others) |
| Northbound | A1 from the non-RT RIC for policy, intent and trained models |
| Control | Conflict mitigation between xApps; resource and latency isolation |
| Use cases | Traffic steering, interference and mobility management, admission control, energy saving |
| Fit | O-RAN architecture; the control substrate for AI-for-RAN |
The RIC platform is for operators and vendors building an open, programmable RAN — multi-vendor control, third-party xApps, and a route for machine-learned optimisation into live networks. It is the orchestration counterpart to the accelerated compute that runs the models.
It pairs with the O-RAN CU and DU it controls over E2, and with the AI-RAN compute platform that hosts the heavier inference.
We work on the RIC where it is hard: the E2 termination and service-model handling, the xApp hosting and isolation, the conflict-mitigation logic, and meeting the near-real-time latency budget over a network interface. Deliverables span platform architecture, xApp development, E2 interop and performance validation.
We can build the platform, specific xApps, or the E2 integration into a CU/DU, to your control problem.
The RAN Intelligent Controller platform is where learned and rule-based control plugs into an open RAN. The near-real-time RIC hosts xApps, terminates E2 to the O-CU and O-DU, and resolves conflicts between apps, taking policy and models from the non-RT RIC over A1.
The near-real-time RIC works from about 10 ms to 1 s, close to the radio, hosting xApps that apply control over E2. The non-real-time RIC works on timescales over a second in the SMO, hosting rApps for analytics, ML training and policy, which it sends down over A1.
Applications that run on the near-RT RIC and act on the RAN over E2 — traffic steering, interference and mobility management, admission control, energy saving. Because the interfaces are open, operators and third parties can write and deploy them.
Through the E2 interface, using an E2 service model that defines what the xApp may read (KPIs, measurements) and set (control actions). The platform enforces isolation and mitigates conflicts when two xApps target the same parameter.
The RIC is the orchestration side of AI-for-RAN: the non-RT RIC trains models and sets policy, the near-RT RIC runs inference as xApps. It is the open framework for deploying learned control, while the AI-RAN compute platform supplies the silicon that runs the heavier models.
It must act within tens of milliseconds over a network interface while many xApps run at once, which raises conflict resolution, resource isolation and E2 service-model design — all while closing the loop fast enough to beat the vendor logic it replaces.
An xApp that acts usefully inside tens of milliseconds over E2 without fighting its neighbours is the real work. Tell us the control problem and the service model.