Two different ideas travel under one name. AI for RAN puts learning into network control — scheduling, energy, mobility — through the RAN Intelligent Controller. AI on RAN uses spare accelerator capacity at the base station to run somebody else's inference. They share hardware and almost nothing else, and confusing them is how business cases go wrong.
| What it means | What it needs | |
|---|---|---|
| AI for RAN | Learning improves network function: scheduling, beam management, energy saving, anomaly detection | A control interface with the right latency, and telemetry good enough to learn from |
| AI on RAN | Spare accelerator capacity at the base station sells inference to third parties | Multi-tenancy, isolation, and an economic case that survives the fact the radio has priority |
| AI and RAN | One accelerated platform hosts both the radio workload and the AI workload | Deterministic scheduling so an inference burst cannot miss a symbol deadline |
The first improves the network. The second monetises the site. Only the third genuinely shares silicon, and it is the hardest because the radio has a hard deadline and the inference does not.
Scheduling, HARQ, beam selection. This lives inside the DU and is not where a learned policy goes — the deadline is set by the subcarrier spacing and nothing negotiates with it.
The near-RT RIC, hosting xApps over the E2 interface. Load balancing, handover policy, interference coordination. This is where most useful AI for RAN actually sits.
The non-RT RIC in the SMO, hosting rApps. Policy, model training, configuration, energy schedules. It informs the near-RT layer rather than acting directly.
How the near-RT RIC reaches the DU and CU. Its capability bounds what an xApp can observe and change — a policy is only as good as the interface exposes.
How the non-RT RIC passes policy down to the near-RT RIC. Intent rather than instruction.
None of it works without measurement at the right resolution. Most disappointing RIC deployments are a data problem before they are a model problem.
An umbrella term covering three distinct ideas: AI for RAN, where learning improves network functions like scheduling and energy saving; AI on RAN, where spare accelerator capacity at the base station is sold for third-party inference; and AI and RAN, where one accelerated platform hosts both. They share hardware and little else.
The RAN Intelligent Controller, defined by O-RAN. It comes in two forms: a near-real-time RIC operating between 10 ms and 1 second hosting xApps over the E2 interface, and a non-real-time RIC in the SMO operating above 1 second hosting rApps. The split reflects what can be decided at what latency.
An xApp runs on the near-real-time RIC and acts within 10 ms to 1 second — load balancing, handover policy, interference coordination. An rApp runs on the non-real-time RIC above 1 second and handles policy, training, configuration and energy scheduling, informing the near-RT layer rather than acting directly.
Not in the sub-millisecond loop. Scheduling, HARQ and beam selection run to a deadline set by the subcarrier spacing, and nothing negotiates with it. Learning influences scheduling through policy set at the near-real-time layer, not by making the per-slot decision itself.
Energy. The power amplifier dominates site consumption, and learned traffic prediction can shut down carriers and cells more aggressively than a fixed schedule dares, because it can anticipate rather than react. That is where most operators see return before anything else.
The radio workload has a hard deadline and the inference workload does not. Sharing requires the radio to preempt reliably, and isolation strong enough that a tenant workload cannot stall the accelerator. That is a scheduling and partitioning problem, not a modeling one.
Written for engineers. Share it with one.
The radio the controller acts on.
TECHNOLOGYPHY to RRC and the splits.
KNOWLEDGEWhere the boundary belongs.
AIInference inside a power budget.
PRODUCTWhere site energy is decided.
INDUSTRYWhere this is deployed.
Tell us the specification, the constraint and the deadline. Programs that cross silicon, radio, embedded and AI are where Faststream is strongest.