AI-RAN: What Changes When the Radio Network Learns

Here's the objection worth addressing first: RANs have been automated for twenty years. SON has been shipping since LTE. Every vendor's OSS already does closed-loop parameter optimisation. So what exactly is new?

The honest answer is that it's a shift in how decisions get made, not whether they're automated. A rule fires when a threshold is crossed. A model estimates what's about to happen and acts before it does. That difference sounds small on a slide and turns out to matter quite a lot in networks with too many interacting parameters for anyone to hand-tune.

---

Three different things called AI-RAN

The term covers three distinct concepts, and conversations go badly when people mean different ones.

AI for RAN — using machine learning to optimise network behaviour. Energy saving, mobility prediction, beam management, interference handling. This is what most people mean.

RAN for AI — using RAN infrastructure to deliver AI services to users. Edge inference hosted at the base station, with the network as an AI delivery platform.

AI on RAN — running AI workloads on the same compute that runs the RAN, monetising idle capacity when traffic is low.

The industry AI-RAN Alliance uses all three. This article is mostly about the first, with a section on the third because it's where the interesting infrastructure argument lives.

---

Rules versus models

Traditional RAN automation is threshold logic. It works, and for well-understood situations it works well:

IF   traffic < threshold
AND  time = night
THEN reduce cell capacity

The engineer encodes a relationship they already understand. The system executes it. Behaviour is fully predictable, fully auditable, and fails in ways you can reason about.

A learned system inverts the direction:

Instead of asking "has the threshold been crossed?", the system asks "given current conditions and what's happened before, what's likely to happen next?"

That reframing is the whole thing. It's also where the risks come from — you gain the ability to capture relationships nobody hand-coded, and you lose the ability to read the decision logic off a config file.

The practical test for whether ML is worth it: can you write the rule? If a competent engineer can express the relationship in a threshold, use a threshold. ML earns its complexity when the relationship involves many interacting variables, shifts over time, or differs per cell in ways that make hand-tuning intractable.

---

Where it actually pays off

Energy savings

The strongest near-term case, because the economics are unambiguous — RAN energy is a large, measurable operational cost.

Traffic is highly predictable at the daily and weekly scale:

A threshold-based scheme reacts after traffic has already dropped, and reacts late again when it returns — which is the expensive half, because waking a carrier isn't instant and users feel the gap. A predictive model can combine historical patterns, current load, calendar effects, weather, and local events:

The action space is the same either way: carrier and cell sleep modes, RF chain shutdown, transmit power adaptation, and — critically — reactivation before demand arrives rather than after. Prediction mostly buys you better timing, and better timing is where the savings are.

Mobility

Conventional handover triggers on measurement events and configured offsets. That's reactive by construction, and it produces the two failure modes everyone recognises: ping-pong between cells and too-late handovers on fast-moving UEs.

A model can factor in UE velocity and heading, historical trajectories along the same road or rail corridor, target cell load, and predicted radio conditions rather than current ones. On a highway, the useful question isn't "which cell is strongest now" but "which cell will still be serving this UE in three seconds."

Massive MIMO and beam management

This may be the best technical fit of all. Beam selection is high-dimensional, must be decided fast, and involves relationships that are genuinely hard to express in rules.

Channel prediction, beam selection, and CSI compression are all active areas — and CSI feedback compression in particular is one of the few places where 3GPP has taken AI into the air interface itself.

Interference management

Interference in dense deployments is a coupled, multi-cell problem. Changing power or scheduling in one cell shifts conditions in its neighbours. Model-based approaches can learn the coupling patterns and predict where interference will appear rather than reacting after SINR has already degraded.

---

Where the models live

AI-RAN doesn't need Open RAN — vendors run ML inside integrated RAN products today. But the O-RAN RIC architecture gives it a standardised home, which is why the two are discussed together.

The short version: Non-RT RIC handles training and policy on timescales above a second; Near-RT RIC handles inference and control between 10ms and 1s; anything faster stays inside the DU. The full breakdown of RIC timescales, the A1 and E2 interfaces, and how rApps and xApps divide the work is covered in O-RAN Architecture Explained.

The architectural point for AI-RAN specifically is the train/infer split. Training needs data volume and tolerates latency. Inference needs speed and tolerates a frozen model. Putting them at different layers isn't an implementation detail — it's the design that makes real-time ML control feasible at all.

---

The receiver is where the money is

Of everything filed under AI-RAN, the physical-layer receiver is where the case is strongest and least speculative — because the classical approach has a known, provable ceiling.

Conventional receivers are built from blocks derived under assumptions: the channel is linear, the noise is Gaussian, the interference is white. Each block is optimal given those assumptions and given that the blocks are designed separately. Reality violates all of it — power amplifiers are nonlinear, interference is structured and bursty, hardware impairments are neither Gaussian nor independent.

A learned receiver optimises the whole chain against the channel it actually sees, impairments included. Reported gains cluster around 1–2 dB in link budget, which sounds modest until it is converted: 2 dB is roughly 25% more cell area, or the same coverage from fewer sites.

Channel estimation is the clearest single win. Classical interpolation between reference signals assumes a smooth channel. A model trained on real channel realisations learns the actual statistics of that deployment — the delay spreads, the Doppler profiles — and interpolates better, particularly at low SNR where reference signals are themselves noisy.

CSI compression is the other. Reporting full channel state for a 64-element array costs prohibitive uplink overhead, so classical designs quantise into codebooks and discard the rest. An autoencoder learns a compression matched to the channel distribution, giving better reconstruction at the same overhead — and this is the case 3GPP has taken furthest, precisely because the compression must be standardised for both ends to agree.

---

Two-sided models and why they are hard

That last point exposes the structural problem in standardising AI for the air interface. A one-sided model lives entirely in one implementation — the network's scheduler, the device's receiver — and needs no standardisation at all. Vendors ship what they like.

A two-sided model splits across the interface: the device encodes, the network decodes. Now both ends must agree, and agreement raises questions the specification process has never had to answer.

Does 3GPP standardise the model architecture? That freezes the state of the art at the moment of standardisation.

Does it standardise only the format, letting vendors train their own? Then an encoder from one vendor must interoperate with a decoder from another, which requires either shared training or a compatibility mechanism.

Does the network push a model to the device? That needs a model delivery protocol, version negotiation, storage requirements, and a story for what happens when the device cannot run it.

Release 18 studied these; Release 19 is working through them. The two-sided case is the hardest standardisation problem AI has raised for 3GPP, and it is unresolved.

Here's where AI-RAN gets genuinely interesting, and genuinely difficult.

RAN workloads and AI workloads have opposite characteristics. RAN processing is hard real-time with fixed deadlines, latency-critical, and continuous. AI training is throughput-oriented, latency-tolerant, and bursty. AI inference sits somewhere between.

The AI-on-RAN argument follows from an observation about utilisation. RAN compute is dimensioned for peak traffic, which means it's substantially idle at 3am — exactly when AI training workloads would like capacity. Sharing the infrastructure improves utilisation, and if you've already deployed accelerators for RAN processing, you've already deployed hardware AI workloads can use.

The catch is that RAN workloads cannot be preempted. A missed slot boundary is a dropped transmission, not a delayed job. Sharing infrastructure between a workload with hard deadlines and one that wants to consume everything available needs genuinely strict isolation — CPU pinning, cache partitioning, memory bandwidth controls, and accelerator scheduling that will never let the AI job starve the scheduler. This is a real systems engineering problem, not a configuration exercise.

---

Data is the harder half

Models need data, and RAN data is inconveniently distributed.

Measurements originate at UEs and cells, in enormous volume, at high frequency, across sites, and often under privacy and regulatory constraints. Centralising all of it is expensive and sometimes not permitted.

Federated learning is the response: train local models where the data lives, share model updates rather than raw measurements, and aggregate centrally.

It fits the RAN topology well and reduces both backhaul cost and privacy exposure. It also introduces its own problems — non-IID data across cells (a rural cell and a stadium cell genuinely have different distributions), aggregation strategy, and update synchronisation across an unreliable network.

---

The reliability problems nobody has fully solved

Worth being direct about these, because they're the reason deployment is more cautious than the hype implies.

Explainability. When a rule causes an outage, you read the rule. When a model does, you have a set of weights. Root-cause analysis on a learned control loop is a genuinely unsolved operational problem.

Model drift. Networks change — new sites, new traffic patterns, new device populations, seasonal shifts. A model trained on last year's network gradually stops describing this year's. Drift detection and retraining pipelines aren't optional extras; they're the majority of the operational cost.

Bounded behaviour. An AI control loop needs hard limits, sanity checks, and fallback to deterministic behaviour when confidence is low or outputs look wrong. Nobody wants a model that has learned something subtly incorrect operating a live network without guardrails.

Data quality. Bad measurements produce confidently bad models. Validation and cleaning are unglamorous and load-bearing.

Latency budgets. Inference must complete within the control loop's timescale. A model that produces a better answer 200ms too late is worse than a rule that produced a mediocre answer on time.

Security. Training data becomes an attack surface. Poisoning a model changes network behaviour without ever touching a network element — a genuinely novel threat class for RAN.

---

Lifecycle management is the unglamorous half

A model that works at deployment does not stay working. Traffic patterns shift, sites are added, the physical environment changes, and the distribution the model was trained on drifts away from the one it now sees.

Monitoring must detect this without ground truth. The network rarely knows the correct answer at inference time — that is why it used a model. Practical monitoring therefore watches proxies: prediction confidence, distribution statistics of the inputs, and downstream KPIs that would degrade if predictions worsened.

Fallback must be immediate and safe. Every deployed model needs a classical path that can take over, and the switch must be fast enough that degradation does not persist. This means the classical implementation stays in the product indefinitely — the model reduces neither code size nor validation burden.

Retraining and rollout raise the question of where training happens. Centrally, with data shipped from sites, is simplest but moves large volumes of sensitive measurement data. At the edge avoids that and adapts to local conditions, but produces per-site models that are far harder to validate and support.

Federated approaches sit between: sites train locally and share model updates rather than data. This is attractive on paper and awkward in practice, because update aggregation assumes sites are similar enough for a shared model to make sense, which dense urban and rural sites plainly are not.

None of this is research. It is operations, and it is the part that determines whether AI-RAN survives contact with a live network.

3GPP has been building AI/ML support incrementally rather than in a single release. Release 17 introduced network data analytics and the RAN AI/ML study work. Release 18 — the first release branded 5G-Advanced — brought AI/ML for the NR air interface, covering CSI feedback, beam management, and positioning, along with a general framework for model lifecycle management. Releases 19 and 20 continue extending that and increasingly point toward 6G, where AI is expected to be architectural rather than an add-on.

Meanwhile O-RAN provides the RIC architecture, the AI-RAN Alliance drives the shared-infrastructure work, and vendors ship proprietary ML inside integrated products today.

---

The energy case is the one operators actually fund

Ask what justified the budget and the answer is rarely spectral efficiency. It is electricity.

The RAN dominates a mobile operator's energy consumption, and most of that sits in radio units whose power draw does not scale down with traffic nearly as well as intuition suggests. A cell serving almost nobody at four in the morning still consumes a substantial fraction of its peak.

The classical fix is threshold-based: shut a carrier down when load drops below some value, bring it back when load rises. It works, and it is conservative, because the thresholds must be set for the worst case. Set them aggressively and a burst of traffic arrives at a cell that has powered down, producing a coverage hole or a scramble to reactivate.

Prediction changes the risk calculus. A model that forecasts load an hour ahead with useful accuracy allows shutdown decisions that a reactive threshold could never justify, because reactivation can begin before demand arrives rather than after. The same applies to antenna elements, to carrier sets, and to entire capacity layers.

Reported savings sit in the range of 10–30% of RAN energy depending on traffic profile and how much of the network is capacity rather than coverage. For a large operator that is a material line item, it is measurable directly, and it does not require anything to be standardised — which is exactly why it is the AI-RAN application furthest along in real deployments.

AI-RAN is best understood as the RAN gaining the ability to predict rather than react. That's a real change, and energy optimisation, mobility, and beam management are where it demonstrably pays.

It's also not free. You trade deterministic, auditable behaviour for adaptive behaviour that's harder to explain and requires continuous maintenance. Models drift. Data pipelines are expensive. Compute isolation is hard. The engineering challenge isn't building models that work in a lab — it's building control loops that stay safe, bounded, and explainable in a live network for years.

For engineers, the useful position is neither dismissal nor enthusiasm. It's knowing which problems genuinely need a model, and which ones a well-chosen threshold has been solving perfectly well since 2012.

---

Further reading

• O-RAN Architecture Explained — the RIC, A1/E2, and where models run
• 3GPP TR 37.817 — Study on enhancement for data collection for NR and EN-DC
• 3GPP TS 38.843 — AI/ML for the NR air interface
• O-RAN ALLIANCE WG2 — Non-RT RIC and A1 interface specifications
• AI-RAN Alliance — shared RAN and AI infrastructure work