Every generation of mobile technology arrives with a headline promise. For 6G, one of the loudest is the autonomous network: a network that monitors itself, diagnoses its own faults, decides what to do about them and then does it, with engineers setting the goals rather than turning the dials.
It is a compelling vision, and the conversation about it almost always turns quickly to AI. Which models. Which agents. Which platform. The assumption underneath is that autonomy is an intelligence problem, and that a sufficiently capable AI will close the gap between where networks are today and where the industry wants them to be.
The operators making genuine progress have learned something less glamorous. Autonomy is not primarily an AI problem. It is a data problem. And for most of the industry, the data problem has not yet been solved.
A journey that has already started
The first thing worth saying is that autonomous networks are not a 6G invention. The transformation began with 5G and 5G-Advanced, and it is already well under way.
The industry’s common yardstick is TM Forum’s six-level autonomy scale. Level 0 is fully manual operation. Levels 2 and 3 cover partial and conditional automation of specific tasks. Level 4 is where the real shift happens: AI-driven analysis and decision-making, executed through closed loops with minimal human intervention. Level 5, full autonomy across every domain, remains a long-term aspiration.
Most operators today sit somewhere between Levels 2 and 3. But the ambition is clear. A TM Forum survey of 80 operators, published in June 2026, found that one in five expect to reach Level 4 or above by 2027, and 81% have set that as their goal for 2030. The early movers are not attempting it network-wide. They are starting in specific, high-value areas: fault management, RAN optimisation, energy management and capacity planning.
What 6G changes is the stakes. As autonomous vehicles, robots, drones and dense populations of connected devices become commonplace, traffic patterns will shift faster than any operations team can respond to manually. Autonomy stops being an efficiency programme and becomes a precondition for running the network at all.
What it looks like when it works
The published results from early deployments are striking, and they are worth looking at closely, because they show where autonomy is delivering first.
One large Asian operator, described in a TM Forum case study, built an AI knowledge graph to capture the operations and maintenance expertise held by its engineers. Before the project, it could take months to turn expert summaries into usable insight. Once that expertise was structured into a form the system could reason over, root cause analysis accuracy rose from around 70% to 89%.
A second operator, also profiled by TM Forum, deployed AI agents across its network operations centres to handle fault management and customer complaints. It reported an average 30% reduction in mean time to repair, a reduction of more than 30% in back-end operations and maintenance effort, and a move from Level 3.2 to Level 4 in those operations.
The most instructive example, though, comes from a recent vendor case study of a Middle Eastern operator during one of the world’s largest annual mass gatherings. Millions of people converge on a small geographic area for a few days, and traffic behaves in ways no static plan can anticipate. Using closed-loop automation, the network handled more than 23,000 AI-driven decisions per hour, with one coverage optimisation loop alone executing nearly 600 corrective actions across 116 sites at one-minute decision intervals. The volume of network optimisation actions rose by around 280% on the previous year.
That last case is worth dwelling on. A sudden, dense concentration of devices, all demanding capacity at once, is a fair preview of what 6G-era networks will face every day. No team of engineers could have made those decisions at that speed. The network had to make them itself.
Garbage in, disaster out
The AI industry has long relied on the phrase “garbage in, garbage out” to describe the effect of poor training data on a model’s output. In autonomous networks, where AI is not just advising engineers but executing changes on a live network, some practitioners have started using a sharper version: garbage in, disaster out.
The practical obstacles fall into four groups. The first is data quality: whether the measurements, counters and records feeding the system are complete, consistent and trustworthy. The second is data silos. RAN, core, service and OSS data typically live in separate systems, with separate identifiers and separate owners, so even good data cannot be brought together when a decision needs it. The third and fourth are legacy OSS/BSS platforms and multi-vendor, multi-domain environments, each with its own interfaces.
The first two determine whether the AI can understand what is happening. The second two determine whether it can act on what it understands. Most of the industry’s attention goes to the latter, but the former is where autonomy most often stalls.
Consider a recurring dip in voice quality that shows up in core network KPIs. Viewed from the core alone, it is a symptom without an explanation. The cause only becomes visible when those KPIs are correlated, by subscriber, location and time, with RF quality data from the access network, revealing in this case a base station overloaded by activity at a nearby construction site. An engineer can eventually find that connection by querying system after system. An autonomous network has to find it on its own, every time, in minutes rather than days.
Teaching the network what it knows
The standards bodies agree on the basic architecture. ETSI’s Zero-touch network and Service Management group places a closed loop at the heart of autonomy: collect data, analyse it, decide and plan, act, then validate the outcome and feed it back. Crucially, at the centre of that loop sits knowledge, not raw data.
TM Forum extends the idea across the whole organisation through intent. An operator expresses what it wants the network to achieve, and each domain’s closed loop continuously compares that intent with the network’s actual state, acting whenever the two diverge. Anyone familiar with Kubernetes will recognise the pattern: declare a desired state, and let automation keep pulling reality back towards it. It is one reason autonomous network platforms are so often built on cloud-native foundations. Meanwhile, 3GPP is filling in the detail, from domain data models and analytics functions to intent management and AI model lifecycle management.
The piece that turns data into knowledge is increasingly the ontology, often implemented as a knowledge graph. An ontology defines the concepts of the network domain (cells, equipment, alarms, KPIs, faults, corrective actions) and the relationships and rules that connect them. It gives structure to both kinds of operational data: structured records such as performance, fault and configuration data, call detail records and MDT, and unstructured knowledge such as operations manuals, fault-handling procedures and historical root cause analysis reports.
With an ontology in place, an AI agent does not have to guess what a counter means or which system holds the evidence it needs. It can retrieve the right data, reason about it in context, and arrive at a clear recommendation that can be actioned. The result is closed-loop automation that is more consistent, more accurate and far less prone to hallucination.
Small, specialised, and on a harness
There is one more practical reality that the broader AI conversation tends to overlook. Telecom networks are mostly operated in closed environments, and sending operational data to a commercial large language model is often not an option. Even where hybrid deployment makes it possible, the token costs and GPU demands of very large models are hard to justify for decisions made thousands of times an hour.
This is driving interest in compact, telco-specific small language models: models trained deeply on telecom domain knowledge rather than broadly on everything. GSMA has established datasets, benchmarking methods and leaderboards for telecom AI, and specialised models of this kind are now scoring impressively against those benchmarks, holding their own against far larger general-purpose models.
At LIG Accuver, we have been building one. Our telco-specific SLM, fine-tuned on mobile network domain knowledge, achieved 72.35% accuracy against GSMA’s benchmarking criteria in our internal evaluation, on a par with gemini-3-flash-preview (70.4%), a far larger general-purpose model. Because it is compact, it can run on-premise or in a private environment, so operational data never has to leave the operator’s network, and we continue to raise its accuracy through ongoing base-model exploration and fine-tuning.
Capability alone is not enough, however. Language models are non-deterministic, and a closed loop acting on a live network cannot afford surprises. Hence the growing attention to what AI developers call harness engineering. A harness is what keeps a horse moving in the direction intended; in AI, it is the set of controls that keeps a model’s behaviour within safe bounds. In practice that means scoring the confidence of every response, routing a query to a more capable model when confidence falls below a threshold, filtering and masking sensitive data, and enriching queries with the right domain terminology before the model ever sees them.
In our own implementation, the SLM never works alone. It sits inside exactly this kind of harness: a query-enhancement step that adds telecom terminology, a data-filtering engine that masks sensitive information, a context retriever that draws the relevant knowledge from the network ontology, and a confidence engine that decides whether an answer can be trusted or must be routed to a more capable model.
Autonomy, in other words, depends as much on knowing when not to trust the AI as on the AI itself.
One loop at a time
The operators furthest along share a common approach, and it is not a big-bang transformation. They pick a high-value use case, such as root cause analysis or a specific optimisation problem. They gather the data that use case needs and structure it into knowledge. They prove the closed loop works on live network data. Only then do they add the next use case, raise the level of autonomy, and fold in the relevant standards.
The industry’s shorthand for the destination is zero wait, zero touch, zero trouble. The route there runs through data integration and domain knowledge long before it reaches the more visible AI.
This is the foundation LIG Accuver is building with Accuver NLA (Network Lifecycle Automation), an ontology-based decision support platform. Its Nexus layer integrates data from the mobile, access and core domains, including measurements from our XCAL, AEGIS-AP, AEGIS-CP and Accuver Cloud solutions, and structures it into AI-ready knowledge through a semantic layer and a network ontology. Its Raven layer puts that knowledge to work, combining our telco-specific SLM, context retrieval and agentic AI support tools to drive closed-loop analysis and decisions. It draws on more than 25 years of working with data across every layer of the mobile network, and we are taking the same approach we recommend to operators: define a use case together, prove it through a PoC on live network data, then expand step by step towards Level 4.
The operators who build that foundation now will be ready when 6G turns autonomy from an advantage into a necessity. The ones who start with the AI and work backwards may find themselves automating decisions they do not yet have the data to get right.
That is the real race to 2030.
If you are working through these questions in your own organisation, whether that is deciding where to start, or how to bring access and core data together into something an AI can genuinely use, I would be glad to compare notes. Please do get in touch.
Sources
- TM Forum: Autonomous Networks Leadership Forum spotlights Level 4 shift (survey of 80 operators: 20% by 2027, 81% by 2030)
- TM Forum case study: AI knowledge graphs and root cause analysis (RCA accuracy 70% to 89%)
- TM Forum case study: Level 4 network operations centre with intelligent agents (30% MTTR reduction, Level 3.2 to 4)
- Ericsson case study: Level 4 autonomy during a mass gathering (23,000 decisions per hour, 598 actions across 116 sites, ~280% year-on-year)
List