AI and 5G meet at the edge. A 5G standalone network can send a device's traffic to a server beside the radio network instead of a distant cloud region, so AI inference can answer in milliseconds, less raw data crosses the network and sensitive data stays local. AI also runs inside the radio network, and 6G is being designed around it.
This guide explains what edge AI is and where a model can run, how multi-access edge computing (MEC) works in a 5G network, which AI workloads really need the edge (with the latency budgets 3GPP sets for them), how 5G carries AI traffic, how AI is moving into the radio access network through 3GPP Releases 18 and 19 and the AI-RAN Alliance, what 6G adds, and the limits. For 5G and 6G themselves, from New Radio to the 6G timeline, read our guide to 5G and 6G networking.
Why AI and 5G are discussed together
In one paragraph, the networks: 5G is the mobile system whose first full set of standards is 3GPP Release 15, with protocols stable in June 2019, and 5G-Advanced is 3GPP's name for Release 18 onward. 6G is what ITU calls IMT-2030, and 3GPP plans its first normative 6G specifications in Release 21, with the stage 3 freeze in December 2028 and the ASN.1 freeze in March 2029.
AI touches these networks in two directions. 3GPP's own Release 19 summary names them: "network for AI", which optimizes how the network carries AI-related data, and "AI for the network", which uses AI to run the network more efficiently. A third idea sits between them: hosting AI applications on computing inside the network, close to the people and machines that use them. That is edge AI, and it is where a business's own decisions start.
What edge AI is, and where a model can run
Edge AI means running inference, the use of a trained model on new input, close to where the data is produced rather than in a distant cloud region. "Close" covers four places, and one system often uses several:
| Where the model runs | What fits there | Strength | Watch for |
|---|---|---|---|
| On the device | Small, compressed models on the phone, camera or controller | No network delay, works offline, data never leaves | Power, heat, memory, and getting updates onto every device |
| On premises (your edge) | Larger models on a server or GPU box in the factory or store | Raw data stays on site; reachable over Wi-Fi or private 5G | You buy, secure and run the hardware |
| Operator edge (MEC, edge zones) | Models on servers beside the mobile network | Close to mobile users over a wide area | Available only where the operator or cloud has an edge site |
| Cloud region | The largest models, training, fleet-wide analytics | Capacity, every managed service, simplest to run | Distance adds latency, and every byte has to travel there |
Three reasons push inference toward the edge. The first is latency: 3GPP's edge computing overview points out that the theoretical minimum is the distance divided by the speed of light, so edge computing cuts latency by shortening the distance. The second is bandwidth: a camera that streams every frame to the cloud spends uplink capacity on footage where nothing happens, while a model beside the camera can send only the events. The third is privacy: a model that runs where the data is created never ships the raw data anywhere. 3GPP's service requirements for 5G (TS 22.261) state the same trade in their own words: offload the compute-heavy, energy-heavy parts of a model to the network, and keep the privacy-sensitive and delay-sensitive parts on the device.
The tooling for the device end is mature. Google's LiteRT, built on TensorFlow Lite, converts PyTorch, JAX or TensorFlow models, quantizes them and runs them on a device's CPU, GPU or NPU; ONNX Runtime is a cross-platform model accelerator that also targets IoT and edge devices. For deciding feature by feature between on-device and cloud models inside an app, see our guide to building intelligent apps. The rest of this guide is about the network in between.
How multi-access edge computing works in a 5G network
ETSI defines multi-access edge computing as cloud computing capabilities and an IT service environment at the edge of the network, characterized by ultra-low latency, high bandwidth and real-time access to radio network information that applications can use. An operator can open its radio network edge to authorized third parties, and deployments range from an on-premises edge to the operator's network edge. The "multi-access" is literal: MEC covers fixed and Wi-Fi access as well as mobile. ETSI's own list of use cases includes video analytics, V2X (vehicle communication), drones, gaming, augmented reality and location services.
In a 5G network, 3GPP supports edge computing natively in the 5G Core. The core places a user plane function (UPF), the function that carries user data, at a local site and connects traffic to it in one of three ways:
- Distributed anchor point: all of a device's traffic goes through the local UPF.
- Session breakout: one session has a central UPF and one or more local ones, and only the edge application's traffic is diverted to the local site.
- Multiple sessions: some applications use a session anchored at the local site, others one anchored centrally.
Around that, 3GPP specifies how an application finds the right edge server (the Edge Application Server Discovery Function and an edge enabler layer with its own APIs) and how it keeps working when the device moves to an area served by another edge server, which 3GPP calls application context relocation. Support began in Release 15, the main normative work came in Release 17, and Release 19 adds the delay between the UPF and the external data network to how edge servers and UPFs are chosen. The 4G core can host edge computing too, but 3GPP notes that it was not designed for it: native support comes with the 5G Core, which means 5G standalone.
You do not always reach the edge through an operator's own platform. Cloud providers run edge zones too: AWS Wavelength deploys standard AWS compute and storage at the edge of communications service providers' networks, and you extend a VPC into a Wavelength Zone and run EC2 instances there, while AWS Local Zones put AWS resources close to large population and industry centres. On the API side, ETSI's MEC Phase 4 work, announced in October 2025, explains how its service APIs complement open-source network APIs such as CAMARA, and proposes abstracted APIs that expose network information to developers without deep knowledge of 3GPP networks.
Which AI workloads need the edge, and which belong in the cloud
Start from physics. ITU-T's planning value for delay in an optical fibre system is 5 µs per kilometre, one way. A server 1,000 km away therefore costs 10 ms per round trip in fibre alone, before any radio, routing, queuing or model execution. Whether that matters depends on the workload's latency budget, and 3GPP has written those budgets down:
| AI workload | Latency budget in 3GPP requirements | Specification | Where the AI fits |
|---|---|---|---|
| Motion control in a machine | Under a transfer interval of 0.5, 1 or 2 ms | TS 22.104 | On the controller; at most an on-site server |
| Remote driving (vehicle to application server) | 5 ms end to end | TS 22.186 | Edge server beside the radio network |
| Cloud, edge or split rendering for XR | 5 ms, uplink and downlink together | TS 22.261 | Edge |
| VR motion-to-photon | 7 to 15 ms | TS 22.261 | Tracking on the headset; rendering at the edge at most |
| Split control for robotics | 12 ms downlink | TS 22.261 | On-premises edge or MEC |
| Split AI/ML image recognition | 15 ms uplink | TS 22.261 | Device plus edge |
| Conversational voice | 100 ms one way, mouth to ear | TS 22.261 | A nearby cloud region; the edge only for tight budgets |
| Enhanced media recognition | 100 ms uplink, 100 ms downlink | TS 22.261 | Cloud region |
| AI/ML model download | 1 s for an 80 MB speech or 138 MB image model | TS 22.261 | Cloud or CDN, delivered to devices |
| Federated learning round | 1 s to move 132 MB each way, uncompressed | TS 22.261 | Devices train; the cloud aggregates |
| Model training and batch analytics | No interactive budget | None | Cloud region |
Read the budgets as end to end. TS 22.261 is explicit that service latency adds up the radio, transport inside the 5G system, transport to a server outside it, and the data processing itself, and that hosting services locally reduces the parts outside the 5G system. Subtract the radio and the model's own execution time, and what is left is the distance you can afford: at 5 µs per kilometre, each millisecond of budget buys about 100 km of fibre, there and back. A 5 ms remote-driving budget leaves no room for a region 1,000 km away. A 100 ms voice budget usually does.
Tip
Measure where the time goes before paying for proximity. If most of a request's delay is model execution or a database call, a closer server will not fix it; a smaller model, a cache or a faster query might.
Two patterns fall out of the table. Budgets of a few milliseconds, such as machine control, remote driving and rendering, leave room only for the device, the site or a server beside the radio network. Interactive AI that people wait on, such as voice, recognition and assistants, usually works from a nearby cloud region, and moves to an edge only when the budget, the uplink volume or data residency demands it.
How 5G carries AI traffic: split inference, model downloads and federated learning
When the model does not run entirely in one place, AI becomes network traffic with its own requirements. 3GPP's service requirements group it into three types of AI/ML operation, each with KPIs in TS 22.261:
- Split inference. The device runs the model up to a certain layer and sends the intermediate data to a network server, which runs the remaining layers and returns the result. For split image recognition, the uplink budget is 15 ms at 144 Mbit/s; for split control of robots, the downlink budget is 12 ms.
- Model download. A device cannot preload every model it might need, given its limited storage, so it downloads the right one when the task changes. The requirement for an image recognition model is 138 MB in 1 s, which works out to 1.1 Gbit/s.
- Federated learning. Each device trains the current model on its own data and uploads interim results; a server aggregates them and sends the new global model back. Uncompressed, federated learning for image recognition moves 132 MB each way, each transfer within 1 s.
The network also owes the application information. TS 22.261 requires that, subject to operator policy, the 5G system can predict changes in bitrate, latency or reliability per device and expose them to an authorized third party, and give advance notice, with time and location, of a planned QoS change. An AI application can use that notice to switch to its on-device model before the link degrades, instead of failing mid-request. Release 19 continued this "network for AI" work with requirements for operator-controlled device participation in AI tasks, a new AI/ML enablement service with an ML model repository for edge applications, and more efficient AI data collection from the UPF.
How AI runs inside the radio network
AI inside mobile networks is older than the current wave. The Network Data Analytics Function (NWDAF) arrived in Release 15, providing network slice analytics, and was extended to data collection and exposure in the 5G Core in Release 16. A Release 17 study on RAN intelligence (TR 37.817) led to normative Release 18 work on AI/ML for the NG-RAN, the 5G radio access network, covering network energy saving, load balancing and mobility optimization. Release 19 added AI-based use cases for network slicing and coverage and capacity optimization.
AI/ML for the 5G air interface: Releases 18 and 19
The bigger step is AI in the air interface itself, the radio link between device and base station. The Release 18 study led by RAN1 (TR 38.843) took three pilot use cases:
- CSI feedback: compressing the device's channel report to cut overhead, or predicting how the channel will change.
- Beam management: predicting the best beam in space and time, to cut measurement overhead and latency.
- Positioning: estimating location directly with a model, or improving the measurements a location is computed from.
Release 18 was functionally frozen in March 2024, with protocols stable in June 2024. Release 19, whose protocols were stable on December 12, 2025, according to 3GPP's release timeline, turned the study into specifications: a normative framework for one-sided models, running either in the base station (gNB) or in the device, for AI-based beam management, positioning and CSI prediction, plus a generic life cycle management framework for those models.
What 3GPP does not standardize is the models. The specifications define the signalling, the data collection, the model's life cycle management and how its behaviour is tested; the model itself is left to the vendor. The air interface work has also assumed offline training: a model is fully trained before it goes into a commercial network, as the NR_AIML_air rapporteur told an ETSI conference in February 2025.
CSI compression is the use case that shows why this is hard. It needs a two-sided model: an encoder in the device compresses the channel measurement, and a decoder in the base station reconstructs it. Because a phone maker builds one half and a network vendor the other, the pair raises interoperability and testing questions that a one-sided model does not.
3GPP deferred two-sided CSI compression, along with collecting training data from devices, to Release 20.
Operators also run AI above the radio link. In O-RAN architectures, a near-real-time RAN intelligent controller (RIC) runs control applications called xApps on loops between 10 ms and 1 s, while a non-real-time RIC works on loops above 1 s, running rApps and managing the ML models the near-real-time side uses.
AI-RAN and the AI-RAN Alliance
AI-RAN is the industry's name for the whole agenda. The AI-RAN Alliance was launched at MWC Barcelona on February 26, 2024, by Amazon Web Services, Arm, DeepSig, Ericsson, Microsoft, Nokia, Northeastern University, NVIDIA, Samsung Electronics, SoftBank and T-Mobile USA. It works in three areas:
- AI-for-RAN: AI that improves the radio network itself, such as spectral efficiency and energy use.
- AI-and-RAN: AI and RAN workloads sharing the same computing infrastructure, placed by cost and performance targets.
- AI-on-RAN: AI services deployed at the network edge through the RAN, close to mobile users.
Two years in, the alliance reported 132 members in February 2026, along with 33 multi-member demonstrations at MWC 2026 and four blueprints, including a reference architecture for an AI-native RAN. An alliance publishes reference designs and runs demonstrations; the interoperable specifications that equipment from different vendors must follow are still written in 3GPP.
What 6G adds: AI-native networks and IMT-2030
ITU-R's IMT-2030 framework, Recommendation M.2160 (November 2023), makes AI part of 6G's definition rather than an add-on. It expects IMT-2030 to integrate sensing and AI-related capabilities into communication, and describes three layers of that ambition:
- An AI-native air interface, using AI to improve radio functions such as symbol detection, decoding and channel estimation.
- Ubiquitous intelligence, with networks able to some extent to monitor, organize, optimize and heal themselves without human intervention.
- A new usage scenario, "artificial intelligence and communication", with distributed training, model sharing and distributed inference across the system, and compute orchestration. Its typical use cases include assisted automated driving, offloading heavy computation across devices and networks, and digital twins.
M.2160 also lists "applicable AI-related capabilities" (distributed data processing, distributed learning, AI computing, model execution and inference) among the capabilities of IMT-2030; AI is one of the capabilities previous generations were not designed to support. It gives 0.1 to 1 ms as a research target for latency over the air interface. That target is for the radio alone: a server 1,000 km away still adds 10 ms of fibre, and M.2160's own directions for AI include the "deep edge" and distributed machine learning.
In 3GPP, the 2025 rapporteur presentation expects AI/ML in the Release 21 specifications from the first day, and sees potential for some online training of models to grow from the start of 6G. None of this is a product yet.
Note
"AI-native 6G" describes a research and standards direction as of September 2026. The first 6G specifications are planned to freeze between December 2028 and March 2029, so anything sold today as 6G AI is 5G-Advanced or pre-standard.
The limits: cost, device power, model size and operations
Edge AI solves latency, bandwidth and privacy by adding places for software to run, and every one of those places has a cost.
- Cost and availability. Edge capacity is spread over many small sites instead of a few large regions. Cloud edge zones offer a subset of services, and AWS notes that resources in Local Zones are priced differently from their parent region. In a Wavelength Zone you run EC2 instances, EBS volumes and a short list of services such as EKS and ECS, with load balancing only in select zones, and reach everything else back in the region. An operator's MEC exists only where the operator has deployed it.
- Device power. Running a model drains a battery and heats a device. Even inside the network, 3GPP's rapporteur noted that AI/ML processing is not good for energy consumption on either the network or the device side, and the Release 18 study counted power consumption and memory use in the complexity of each AI technique it evaluated.
- Model size. Apple's on-device foundation model (June 2025) has about 3 billion parameters, compressed to 2 bits per weight, roughly 750 MB of weights. Apple measured a regression of about 4.6% on one math benchmark after compression (and a small gain on another), and says the model is not designed to be a chatbot for general world knowledge; a separate server model handles more complex tasks. For the chips that may raise this ceiling, see our explainer on memristor AI chips.
- Operations. Every site is one more place to deploy, version, monitor and roll back a model. TS 22.261 notes that model performance on a device needs constant monitoring. Applications have to follow devices from one edge server to the next, which is why 3GPP specifies application context relocation. And add-ons break when the base model changes: Apple's adapters must be retrained with each new version of its base model.
The honest default is to run AI in the cloud or on the device, and to add a network edge only when a measured budget or a data rule requires one.
How to decide where your AI should run
- Write the latency budget for each AI feature, end to end, and measure where the time goes today: radio, transport, queuing, model execution, database.
- Start with the device or the nearest cloud region. Move a workload to the edge only when its budget, its uplink volume or a data residency requirement rules those out.
- Keep raw data where privacy requires it, and send features, events or split-model intermediates instead.
- If you need an operator edge, ask specific questions: is the service on 5G standalone at your sites, where is the UPF for your traffic, which edge zones exist, and which network APIs (QoS, predicted network conditions) can your application use.
- Package the model to run in more than one place, in containers with the same runtime, with a fallback when the edge or the link is unavailable.
- Plan the model's life cycle before launch: versions pinned per site, monitoring, rollback, and who updates the devices.
- Track 3GPP, not marketing. Release 20 carries the next 5G-Advanced AI work, including two-sided CSI compression, and Release 21 the first 6G specifications, with AI/ML expected in them from the start.
Where applications and models run, and how they reach each other, is the part you control. Our cloud transformation service covers the platform side: workloads containerized and run on Red Hat OpenShift or Kubernetes, on a landing zone defined as code, moved in waves with a rehearsed rollback. When the AI is a language-model workflow rather than a control loop, our AI and automation service builds it with an evaluation set run before every change and a fallback when the model is unavailable. More on these themes is in our AI articles.
