AI-RAN: three ideas wearing one name.

Three ideas wearing one name.

AI-RAN is used for three different things, and most confusion comes from mixing them. AI-for-RAN means using machine learning to do the radio's own job better — a learned receiver, smarter beam management, a scheduler that predicts rather than reacts. AI-on-RAN means using the radio site as a place to run other people's AI: inference and edge applications hosted where the latency is low. AI-and-RAN is the infrastructure idea — putting the radio workload and the AI workload on one accelerated platform so expensive silicon is not sitting idle.

They are not alternatives. A single deployment can learn parts of its physical layer, host edge inference as a service, and do both on shared GPUs. But the engineering questions each raises are different, so it is worth keeping them apart.

AI-for-RAN: learning parts of the physical layer.

The physical layer is full of functions that were hand-designed against models of the channel: channel estimation, equalisation, demapping, beam selection, link adaptation. Where the real channel departs from the model — dense multipath, high mobility, odd interference — a network trained on real data can do better than the closed-form method.

The clearest example is the neural receiver, which replaces several receive-chain blocks with a trained model that recovers bits directly from the received samples, often with a real gain in poor conditions. Beam management, where a model predicts the best beam from sparse measurements instead of sweeping, and scheduling, where a learned policy anticipates traffic, are close behind. Energy saving — predicting when cells and components can sleep — is where many operators see the first payback.

The constraint is that the physical layer is unforgiving in latency and determinism. A model in the receive path has to produce an answer every slot, every time, within microseconds. That rules out anything whose runtime is not bounded, and it is why so much AI-for-RAN work is really about making a model small and predictable enough to live in the real-time loop.

AI-and-RAN: the accelerator does double duty.

Running the 5G L1 on a GPU or a programmable accelerator rather than fixed-function silicon was the enabling step. Once the radio's own processing is software on an accelerator, the same accelerator can run AI workloads when the radio does not need all of it — which is most of the time, because radio load follows a daily curve.

That is the economic argument for AI-and-RAN: size the platform for the busy-hour radio, and sell the spare cycles as AI compute. The catch is isolation. The L1 has hard real-time deadlines; an AI job must never steal the cycles the receiver needs this slot. In practice the PHY is inline-accelerated — data flows through dedicated engines on a tight path — while best-effort AI runs lookaside, scheduled around the radio's guaranteed share.

AI-on-RAN, and how it fits O-RAN and the edge.

If there is already an accelerated platform at the cell site or the edge, it is a natural place to host AI for other people: low latency to the user, and traffic that can break out locally rather than crossing the core. This is the same edge the user plane function is pushed to for local breakout — AI-on-RAN and edge user-plane placement are two uses of the same real estate.

AI-RAN sits comfortably inside an O-RAN architecture: the open interfaces and the RAN Intelligent Controller already define where learned functions plug in — near-real-time control in the RIC, and faster loops inside the DU. What AI-RAN adds is the compute substrate and the discipline to run learned functions where the deadlines are hard.

For anyone building it, the work is unglamorous and specific: fit a model inside a slot's time budget, prove it will not miss a deadline, isolate it from the radio's guaranteed resources, and show that the shared platform still meets the radio's numbers under full AI load.