Non-RT RIC, AI-RAN, and the AI Grid: Three Different Bets on the Future of the RAN

I have been asked a few times lately what the difference is between the Non-Real Time RIC and AI-RAN. The question itself tells you something. Both sit under the broad "AI in the RAN" umbrella, marketed aggressively by the same vendors, debated in the same conference sessions. But they are fundamentally different in architecture, ambition, and business model. And neither is quite the same as what NVIDIA formally branded the AI Grid at GTC 2026 — which is where the most important and most misread opportunity actually sits.

The Non-RT RIC: the pragmatic bet

The Non-RT RIC is an O-RAN defined software layer that sits in the Service Management and Orchestration layer above the RAN, not inside it. Control loops over one second. rApps for energy saving, traffic steering, slice assurance, automated optimization. Think of it as the evolution of Self-Organizing Networks, re-platformed on open interfaces with a proper application model and a genuinely lower barrier to entry — cloud-native and OSS skills are sufficient. No RAN silicon expertise required.

This is precisely why the early commercial traction is here, not in AI-RAN. AT&T is deploying Ericsson's SMO and Non-RT RIC to replace two legacy C-SON systems. TELUS has launched an RIC platform alongside its Open RAN rollout. Swisscom is deploying one for multi-technology network management. These are not trials. These are production decisions.

AI-RAN: real performance gains, speculative revenue

AI-RAN embeds AI natively into the RAN stack itself .The AI-RAN Alliance — founded in February 2024, now at 109 member companies — defines it across three working groups: AI-for-RAN, AI-and-RAN, and AI-on-RAN.

AI-for-RAN is the most mature: using AI to optimize the RAN itself — the scheduler, link adaptation, beamforming, interference management. T-Mobile and Ericsson have been trialing an AI-driven scheduler and link adaptation engine on a live 5G Advanced network since Q2 2025, targeting commercial deployment in Q3 2026. Nokia and NVIDIA, backed by a $1 billion equity partnership, are testing GPU-accelerated AI-RAN with BT, Elisa, NTT DOCOMO, and Vodafone.

AI-and-RAN is where the narrative gets more ambitious — and more speculative. The idea is that RAN sites become shared compute infrastructure, running both network workloads and enterprise AI workloads on the same hardware. The tower becomes a distributed AI compute node. New revenue streams. Operators escape the utility trap.

AI-on-RAN is the monetization layer for the above. The commercial mechanisms are still being defined. That tells you where the maturity is.

The AI Grid: follow NVIDIA's sequencing, not its marketing

At GTC 2026, NVIDIA formally introduced the AI Grid as a reference design — geographically distributed AI infrastructure, using the telco footprint to run inference workloads closer to users. The numbers are interesting: early Comcast benchmarks showed inference cost reductions of up to 76% versus centralized deployments. HPE, SpectroCloud, and others have already announced implementations aligned to the reference architecture.

I have used this concept in my own work for years to describe the evolution from isolated MEC deployments into a coherent, programmable distributed inference fabric. Good to see NVIDIA put a formal architecture behind it. But the marketing obscures a critical sequencing question.

NVIDIA's own GTC announcements noted that many operators are starting by lighting up existing wired edge sites — central offices and mobile switching offices — as AI Grids they can monetize today. The cell site layer is a later phase. AT&T's CTO Igal Elbaz has been direct about questioning the value of pushing compute all the way to the far edge to save one or two milliseconds of latency. T-Mobile's SVP of network infrastructure defined her AI edge strategy as what is at a data center at a mobile switching office. Verizon's CTO has flagged the cost and complexity of far-edge GPU deployments.

These are the three largest US operators. They are not being conservative for the sake of it. The economics are straightforward: central offices and mobile switching offices already have power, cooling, connectivity, and physical security. They aggregate traffic from hundreds of cell sites. The sub-500ms latency threshold that NVIDIA's own reference design targets is achievable from a well-positioned CO. It does not require a GPU at the tower — not for the use cases that have a business case today.

I have seen this movie before with MEC. The industry led with its most ambitious architectural vision, ran the infrastructure investment ahead of the demand, and recovered slowly. The AI Grid does not have to repeat that pattern.

What to actually do

Start with the Non-RT RIC. The contracts are being signed, the ecosystem is opening, the business case is defensible.

On AI-RAN, wait for AI-for-RAN where your vendors have credible near-term roadmaps. Treat AI-and-RAN at the cell site as a long term speculative option — worth tracking, too early to fund at scale.

On the AI Grid, follow NVIDIA's own sequencing rather than the brochure. Central offices and mobile switching offices first. Build the orchestration and service layer from there outward. Expand to the far edge when the use cases and economics justify it — not because a GPU manufacturer's demand forecast requires it.

The cell site AI Grid is a compelling long-term vision. The central office AI Grid is deployable today. In this industry, deployable usually wins.

Open RAN technical priorities release 3

The Open RAN technical priorities release 3, was published in March 2023 by Deutsche Telekom, Orange, Telefonica, TIM and Vodafone as part of the Open RAN MoU group at the Telecom Infra Project.

A review of the mandatory, highest priority unanimous requirements shed lights on what the big 5 operators consider essential for vendors to focus on this year, and more importantly highlights how much efforts are still necessary by the industry to meet markets expectations.

Scenarios

In this section, the big 5 regard virtualized DU and CU with open Front Haul on site as a must, for Macro and indoor / outdoor small cell deployments. This indicates that 7.2.x remains the interface of choice, despite recent attempts by other vendors to change its implementation. It also shows that as a first step, at least, they are looking at deploying Open RAN in the conventional fashion, replacing traditional e/g Node  B with like-for-like O-RU, DU. CU on site. The benefits of resource pooling due to disaggregation and virtualization, enabling either CU or CU and DU to be centralized is the highest priority by the majority of operators, but not all yet. Network sharing of O-RU and vDU/CU is also a highest priority for the majority of operators.

Security

The security requirements have increased dramatically in this latest version, with the vast majority of the requirements (166 out of 180) considered highest priority by al the MoU operators. This evolution marks the effort that have been dedicated to the topic over the last 24 months. Open RAN has been openly criticized and accused of lax security and the O-RAN alliance has dedicated a working group to assess and shore up criticism in that space. My assessment is that most of the security concerns of Open RAN are either linked to virtualization / O-Cloud implementation or just mechanically a result of having more open interfaces, providing more attack surfaces. Open RAN is not inherently more or less secure than 3GPP implementation and the level of security by design necessary to satisfy the criticisms we have seen in the media is not today implemented by traditional RAN vendors either. Having said that, the requirements now spell out exhaustively the level of admission control, authentication, encryption, certification necessary for each interface, for each infrastructure block and for their implementation in a cloud native containerized environment.

O-Cloud Infrastructure (CaaS)

The O-Cloud requirements are focused on ensuring a cloud-native architecture, while allowing acceleration hardware whenever necessary. As a result, the accent is put on bare metal or IaaS implementations of Kubernetes, with FPGA, eAsic, GPU acceleration support and management. The second theme that is prevalent in O-Cloud unanimous high priority requirements is the lifecycle management features which indicate a transition from the lab to more mature commercial implementations going forward.

CU and DU requirements

First and foremost the big 5 unanimously are looking at virtualized and containerized implementations of O-CU/O-DU with both look-aside and inline acceleration (this is contradictory, but I assume either one is acceptable). The next requirements are the usual availability, scalability, and performance related requirements we find in generic legacy RAN systems. All O-RAN interfaces support are mandatory.

Interestingly, power consumption targets are now spelled out per scenario.

RU requirements

The Radio Units requirements area good illustration of the difficulty to create a commercially viable Open RAN solution at scale. While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN.

The other RU related requirements helpfully spell out the power consumption, volume and weight targets for each type of configuration.

Open Front Haul requirements

There are no changes in the release 3, which shows the maturity of the interface implementation.

RAN features

The RAN features of the highest priority unanimously required by the big 5 operators remain mostly unchanged and emphasize the need for multi connectivity. Dual connectivity between 4G and 5G is essential for any western european operator to contemplate mass deployment of open RAN or replacement of their Chinese RAN vendor. The complexity does not stop to the support of the connectivity, but also necessitate advanced features such as Dynamic Spectrum Sharing (DSS) and Carrier Aggregation (CA) which is a complexity multiplier when associated with the RU band support requirements. These advanced features are probably some of the highest barriers to entry for new vendors in the space, as they have been developed for years by traditional vendors and require a high level of technological maturity and industrialization.

Near-RT RIC

The requirements for the Near-Real Time RAN Intelligent Controller are extremely ambitious. While they technically would enable better control of a multi-vendor RAN operation, they are unlikely to succeed in the short to medium term, in my opinion, as per previous analysis.

SMO and Non-RT RIC

The requirements for Service Management and Orchestration and Non-Real Time RIC are fairly mature and provide a useful framework for RAN domain automation and lifecycle management. The accent in this release is put on AI/ML support and management, which shows that the operators have been seduced by the promises of the technology, allowing a zero touch, automated, network, relying on historical analysis and predictive algorithms. The requirements are fairly high level, suggesting that the operators themselves might not have yet very clear targets in terms of algorithmics policy, performance and management.

In conclusion, this document provides useful data on Open RAN maturity and priorities. While the release 3 shows great progress in many aspects, it still fails to provide sufficient unanimous guidance from a commercial standpoint on the minimum set of end to end capabilities a vendor could reasonably develop to be selected for deployment at scale in these western european networks.