The RIC is where the logic that optimises a radio network lives — pulled out of each vendor's base station into an open, programmable platform. It runs at two timescales: a slow layer that learns and sets policy, and a fast layer that acts, connected by open interfaces. Here is how the pieces fit.
The RAN Intelligent Controller is O-RAN's answer to a simple question: where do you put the logic that optimises a radio network, and how fast does it have to run? The answer is two controllers at two timescales. The non-real-time RIC lives in the service management and orchestration layer and works on timescales longer than a second — collecting data, training models, setting policy. The near-real-time RIC works between about ten milliseconds and a second, close to the radio, applying control decisions while they still matter.
Below both of them sits the part that is genuinely real-time — the scheduler in the DU, deciding resource blocks every slot in well under a millisecond. That is deliberately not in the RIC. The RIC steers and optimises; it does not sit in the per-slot loop, because nothing that reaches across a network interface can meet a sub-millisecond deadline reliably.
The RIC is a platform for applications, not a monolith. On the non-RT RIC, rApps do the slow, data-rich work: analysing performance across the network, training a model, deciding a policy for how a cell should behave. On the near-RT RIC, xApps do the fast work: load balancing, interference management, admission and handover control, acting on live measurements.
This apps model is the point of the architecture. A third party can write an xApp for traffic steering or an rApp for energy saving and run it on anyone's RIC, because the interfaces are open. It is the same idea as AI-for-RAN seen from the orchestration side: the RIC is where learned control plugs in, with the non-RT side training and the near-RT side inferring.
E2 connects the near-RT RIC to the RAN nodes — the O-CU and O-DU. It carries telemetry up and control down, and it is how an xApp actually changes the network. Each controllable function is exposed through an E2 service model, which is the contract for what the xApp is allowed to read and set.
A1 connects the non-RT RIC to the near-RT RIC. It carries policy, intent and trained models downward — the slow layer telling the fast layer what good looks like. O1 is the management interface from the SMO to everything: configuration, software, fault and performance management. Together they form the loop: data up through E2 and O1, learning in the non-RT RIC, policy and models down through A1, action through E2.
The RIC exists to break the RAN open. Historically the optimisation logic was locked inside each vendor's base station; the RIC pulls it into an open platform where operators and third parties can add their own control. That is the commercial case — multi-vendor, programmable, and a route for AI into the network — and it is why the RIC sits at the centre of O-RAN.
The difficulty is real. The near-RT RIC has to act within its latency budget over a network interface while many xApps run at once, which raises conflict resolution — two xApps that both want to change the same parameter — and resource isolation. E2 service models have to expose enough to be useful without destabilising the RAN. And the whole thing has to earn its latency: a control loop that closes too slowly is worse than the vendor logic it replaced. Getting an xApp to act usefully inside tens of milliseconds, without fighting its neighbours, is the work.
O-RAN's platform for the logic that optimises a radio network. It comes in two parts: a non-real-time RIC in the orchestration layer for slow work like training and policy, and a near-real-time RIC close to the radio for fast control. It makes RAN optimisation open and programmable instead of locked inside each vendor's base station.
Timescale and job. The non-real-time RIC works on timescales over a second — data analytics, ML training and policy — and hosts rApps. The near-real-time RIC works from about 10 ms to 1 s, close to the radio, hosting xApps that apply control. Sub-10 ms real-time scheduling stays in the DU, not the RIC.
Applications that run on the RIC. rApps run on the non-RT RIC and do slow, data-rich work such as analytics, model training and policy. xApps run on the near-RT RIC and do fast control such as load balancing, interference management and handover. Because the interfaces are open, third parties can write and deploy them.
A1 connects the non-RT RIC to the near-RT RIC, carrying policy, intent and trained models. E2 connects the near-RT RIC to the O-CU and O-DU, carrying telemetry up and control down. O1 is the management interface from the SMO to all nodes for configuration, software, fault and performance management.
The RIC is where learned control plugs into the RAN: the non-RT RIC trains models and sets policy, the near-RT RIC runs inference as xApps. It is AI-for-RAN seen from the orchestration side — the open framework for deploying learned functions, while AI-RAN also covers the accelerated compute that runs them.
It must act within tens of milliseconds over a network interface while many xApps run at once. That raises conflict resolution when two xApps want the same parameter, resource isolation, and E2 service models that expose enough to be useful without destabilising the RAN — all while closing the loop fast enough to beat the vendor logic it replaces.
The compute that runs the models.
KNOWLEDGEWhat an xApp steers.
KNOWLEDGEThe DSP underneath.
KNOWLEDGEWhere control meets data.
KNOWLEDGESharing the open RAN.
TECHNOLOGYRU, DU, CU and the haul.
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.