AI-RAN: Why This New Layer in the Compute Stack Is Worth Watching

AI-RAN was not a topic I expected to spend much time on after Mobile World Congress. I understood the basic story: AI can help optimize networks, improve beamforming, manage traffic, reduce energy use, and make radio access networks more efficient. Useful, certainly, but not normally where I spend most of my time.

What changed for me at MWC26 was the realization that the conversation has moved beyond AI for network optimization. The more interesting question is whether the network itself becomes part of the AI compute layer. If phones, robots, cameras, drones, and industrial systems can offload some workloads to infrastructure much closer to the physical world, then AI-RAN becomes more than a telecom architecture. It becomes a new layer in how distributed AI infrastructure may evolve.

Thanks toKanika AtriandAsad Mushtaq, via theNVIDIAtour at MWC, I got a better sense of what the likes of Nokia, SynaXG, Eridan and the AI-RAN Alliance are working on. And while this is not one of my usual topics, once the conversation moved into offloading AI workloads from edge IIoT devices to the network edge, it became a lot more relevant to the world I normally spend my time in.

And before you ask, to level set upfront, AI-RAN is not only a 6G research topic. It is relevant to today’s 5G and 5G-Advanced evolution, especially around software-defined RAN, edge inference and better use of accelerated infrastructure, but a lot of the bigger architectural idea and ambition here is clearly about the path toward AI-native 6G.

A new layer in the stack

A few weeks later at GTC, I had a chat withXin HuangfromSynaXG, and that conversation helped connect a few more dots. The more I looked into the AI-RAN Alliance material afterwards, and now NVIDIA’s broader AI Grid positioning, the more I started thinking this is an area worth keeping an eye on. Not because it is guaranteed to become the next big thing, and not because every robot, drone, camera, phone, or industrial system is suddenly going to offload its brain into the nearest base station overnight, but because the underlying architectural direction is genuinely interesting. In my chat with Xin, he described SynaXG’s mission as deploying AI and the radio access network on the same GPU server, which is a very simple way of framing the shift.

The helpful way to break this down is that AI-RAN is not just one idea. The industry tends to frame it across three related areas:

• AI-for-RAN:where AI helps optimize and automate the radio network itself.
• AI-on-RAN:where the network edge can host AI applications, computer vision workloads, or other inference tasks.
• AI-and-RAN:where RAN and AI workloads run together on common accelerated infrastructure.

For me, it was the second and third parts that made the topic worth paying attention to. At a simple level, AI-RAN is not just about making the radio network smarter. It is about asking whether the RAN can also become another place where AI workloads can live.

But sharing infrastructure like this is not simple. This is where the orchestration piece becomes important. If RAN workloads and AI workloads are running on common accelerated infrastructure, something has to decide where workloads run, when radio network functions need priority, when AI workloads can be shifted, how resources are allocated across compute nodes, and how service levels are protected. In practical terms, that means the system has to understand constraints around CPU, GPU, memory, storage, latency, network demand, and service priority. It may also need to anticipate demand patterns, because the radio network does not sit still and neither do the devices connected to it.

NVIDIA’s AI-RAN positioning around AI Aerial is focused on this kind of software-defined infrastructure, where both network and AI workloads can be supported on common accelerated infrastructure. That may sound like a subtle shift, but I think it matters.

Today, when we think about AI infrastructure, we tend to think in fairly familiar layers. There is onboard compute on the device itself, local edge infrastructure, centralized cloud infrastructure, and increasingly AI factories. NVIDIA’s AI Grid adds another important piece to that picture: distributed AI infrastructure that connects AI factories, regional hubs, and edge sites so workloads can run where they make the most sense, depending on performance, cost, latency, locality and operational requirements.

That, to me, is the bigger backdrop for AI-RAN. It is not sitting on its own as some isolated telecom idea. It looks more like one part of a broader move toward distributed AI infrastructure. The AI factory may still be where the heavy training happens. Regional hubs may take on some larger inference and orchestration workloads. Local edge sites may support latency-sensitive applications. And the radio edge, via AI-RAN, could become another place where AI workloads are supported much closer to the physical world.

During the conversation at GTC, Xin used a simple analogy that worked quite well. He compared it loosely to the iPhone combining compute power and wireless connectivity into one platform. His point was that AI-RAN is trying to bring together AI compute and wireless infrastructure on the network side in a similar way, with AI and RAN workloads sharing the same GPU infrastructure and connectivity becoming more tightly integrated with compute.

That immediately starts raising practical questions. If AI compute is sitting much closer to the radio edge, what workloads make sense to run there? What happens when robots, drones, autonomous systems, cameras, or industrial AI systems no longer need to carry quite so much onboard compute? What happens if some inference tasks can be distributed closer to the network instead?

Imagine the possibilities …

Once you move into enterprise environments, the constraints become very real very quickly. Weight, battery life, heat, ruggedization, latency, reliability and cost all matter, particularly when systems have to operate continuously in messy real-world environments rather than polished trade-show demos. This is why I think the “offload” discussion is the part people should pay attention to.

Not because everything should suddenly move into the network. Far from it. A robot still needs local intelligence. Safety systems still need local control. Nobody sensible wants critical operational systems freezing because of a network issue somewhere upstream. This is not about replacing onboard compute completely. But not every workload necessarily needs to sit entirely on the device either. Some inference could remain local, some workloads could happen on local edge infrastructure, some could potentially sit within AI-RAN infrastructure, and some may still go all the way back to centralized AI infrastructure. The point is not that one architecture replaces all the others. The point is that the architecture becomes more flexible.

That flexibility could become really important for physical AI.

One of the more useful points from the AI-RAN Alliance Working Group 3 white paper is that AI applications make network quality much more visible than traditional mobile applications often did. If a video buffers for a few seconds, people get annoyed. If an industrial AI workflow, autonomous inspection system, robot, drone, AR remote-support session, or multimodal assistant loses context during a handover or suffers unpredictable latency spikes, that quickly becomes an operational issue.

The white paper spends a lot of time discussing differentiated connectivity, deterministic behavior, predictable uplink performance, mobility, and verifiable KPIs. In plain English, AI-native applications place very different demands on infrastructure than traditional mobile applications. And one point I would not gloss over is uplink. Traditional mobile networks have largely been shaped around downlink-heavy use cases such as video consumption. But AI-native applications, especially physical AI applications, can create much heavier uplink flows: video, images, sensor data, telemetry and context moving from the device to the edge. That is why predictable uplink performance becomes such a big part of the AI-RAN discussion.

It is also where AI-RAN starts to make sense for industrial AI, robotics, manufacturing, utilities, infrastructure, ports, airports, logistics, mining, and energy systems. Imagine drones inspecting transmission infrastructure, cameras monitoring substations, autonomous systems analyzing thermal or LiDAR data, technicians using AR for remote inspection and field support, or mobile robots operating in environments where sending people may be expensive, difficult, or potentially unsafe. In many of those situations, there may be advantages in distributing some AI workloads closer to the network edge rather than forcing every device to carry increasingly large amounts of onboard compute.

Under the covers, things like local breakout and distributed UPF also matter, because if traffic has to wander off through unnecessary network paths before reaching the AI workload, the whole low-latency story starts to weaken. This is where the architecture matters. It is not enough to say “put AI at the edge” and assume everything works. You still have to think about where the traffic goes, where the inference runs, what happens during mobility, how session continuity is maintained, and what level of assurance the application actually needs.

That does not mean “the network becomes the brain” in some magical sci-fi sense. But it could become part of the broader distributed AI infrastructure layer.

NVIDIA's AI Grid

And this is where NVIDIA’s AI Grid framing becomes useful. The way I look at it, AI Grid is not simply “more data centers.” It is a way of thinking about AI infrastructure as a distributed system: AI factories, regional hubs, edge locations, and potentially radio-edge AI-RAN sites all connected and orchestrated as part of a broader AI compute fabric.

That is a very different mental model from “build a giant AI factory somewhere and send everything there.”

IMO, this really matters when it comes to inference. Training wants scale, density, high-speed interconnects, and controlled data center environments. Inference is different. Inference is everywhere. It is closer to users, devices, cameras, robots, agents, industrial systems, buildings, cities, vehicles and infrastructure. It may be latency-sensitive. It may be tied to data locality or sovereignty. It may need to run close to where the data is created.

That is why we are now seeing multiple versions of this distributed infrastructure idea emerge. SPAN, for example, recently announced XFRA, a distributed data center approach using compute nodes in homes and small commercial spaces. My understanding is that SPAN is looking at how local electrical capacity can be used to support distributed AI inference, with orchestration bringing lots of smaller nodes together into a broader compute resource. That is not the same thing as AI-RAN, but it is clearly related to the same bigger question: where should AI inference run, and can we create distributed infrastructure that is closer to users, devices, power sources and physical systems?

Why all this matters

This is why I think the AI-RAN discussion is bigger than telecom. It is really part of a wider question about distributed AI infrastructure.

For years, the cloud model trained us to think in terms of centralization. Put workloads into large data centers. Centralize management. Centralize compute. Centralize storage. It was almost back to the mainframe type model we had years ago (and yes, I started out on Mainframes; IBM mainframes/CICS, Tandem Himalaya, PDP 11, Stratus etc etc)

Now the centralized model works for many workloads, that still makes total sense. But in some ways, physical AI changes the equation. If you are dealing with robots, drones, industrial cameras, smart infrastructure, AI assistants, autonomous systems, or real-time operational workflows, then the location of compute starts to matter again. Latency matters. Uplink reliability matters. Data locality matters. Power availability matters. Cost matters. And orchestration across multiple layers becomes critical. Not to mention the every increasing requirement of sovereignty.

To be fair, this is not starting from zero. Some of the building blocks already exist or are emerging across 3GPP, O-RAN, GSMA Open Gateway and CAMARA. The hard part is not inventing every component from scratch; as always a lot will depend on how the players align on definitions, APIs, KPIs and commercial models so this becomes usable at scale rather than another fragmented architecture story. That is also where the tag line around from “selling pipes to selling outcomes” becomes relevant. If AI-RAN and AI Grid are going to matter commercially, the value cannot just be “more bandwidth.” It has to be assured performance, predictable behavior, trusted APIs, workload placement, and measurable outcomes.

Now I am not saying this is a given and the best thing since 'sliced bread'. The tech needs to be proven at scale, and the market needs to be proven. It does not mean every operator will suddenly buy GPUs for every cell site. It does not mean distributed inference is easy. But the use cases being discussed, from robots and vision AI agents to industrial safety, utility inspection, remote field support and autonomous systems, are exactly the kind of physical AI workloads that could benefit from compute closer to the action.

Still, this is where expectations need to stay grounded. Talking about architectures is one thing. Deploying them at industrial scale is another. Telecom infrastructure has never exactly been simple, and industrial environments are even less forgiving. Once you add AI orchestration, distributed workloads, edge inferencing, network slicing, security, mobility management, operational technology constraints, sovereignty requirements, API integration, and business model questions into the mix, there is clearly still a great deal that needs to mature. And as I’m writing this, I have not seen any of the Industrial 5G players taking about AI-RAN, and Industrial 5G is needed in many industry use cases.

There are also some really hard questions around the distributed data center idea that need to be answered. If compute moves into telco sites, who owns the customer relationship? If inference moves into CDN edge locations, how does that compete with cloud providers? If compute nodes start showing up in homes or small commercial buildings, who maintains them, who secures them, who pays for the power, who deals with heat, noise, safety, grid impact, permitting, insurance, utilization, and support? And if everyone starts building their own distributed AI fabric, how does the industry avoid creating another fragmented hodgepodge of incompatible platforms?

For telcos, AI-RAN and AI Grid could be a route to move beyond being “the pipe” and into AI infrastructure services. For industrial companies, this could create new options for deploying physical AI without forcing every device to carry all the compute locally.

For energy and infrastructure players, this could create new demand patterns around where compute is installed, how power is used, and how local electrical capacity is monetized. For cloud and CDN providers, this could extend the AI infrastructure race closer to the edge. And for companies like SPAN, it could even turn buildings and homes into part of a much larger distributed inference layer.

Closing comment

Will this all happen? Let’s see. This stuff is hard ... but my point is that more AI infrastructure is moving towards the edge. And while not every AI workload belongs at the edge, AI infrastructure will become more distributed, more physical, and more closely tied to where people, machines, sensors, vehicles, and industrial systems actually operate.

So if you are off developing Physical AI solutions today, keep an eye on AI-RAN, so you can game out what it might mean for you.

And thanks to all of ye who have subscribed to this newsletter, it just passed the 4,000 subscriber mark 😉

Kev.