This post is about how a telecom network moves from people doing the work to software doing it, one feedback loop at a time. All you need from earlier posts is that Blog 7 described intent (TMF921) as a request for an outcome rather than a list of steps, and that Blog 9 showed components running on a shared runtime (the series sits on the hub).
At a Glance
- Autonomy is not a product you buy or an AI feature you switch on. It is built one closed loop at a time: watch the network, decide, act, check, repeat.
- TM Forum grades autonomy from Level 0 to Level 5, and it grades it per scenario. A Level 4 result in one task, such as putting radio sites to sleep overnight, says nothing about the rest of the network.
- Intent describes what the network must guarantee, not how to configure it. Generative AI is useful for writing and explaining intents. A deterministic engine, one that gives the same answer every time and can be checked, should be the thing that touches the live network.
Why this post exists
You will hear that an operator “runs a Level 4 autonomous network.” Then you talk to the people in its network operations centre (NOC). They still move between several ticketing screens and a wall of vendor management consoles.
Both things can be true. The gap between them is what this post is about. TM Forum’s levels are a useful ruler, but only if you know what is being measured. The answer is a scenario, not an operator.
The six levels
TM Forum’s Autonomous Networks (AN) work sets out six levels. The detail lives in a group of documents: IG1218 for the business requirements and framework, IG1230 for the technical architecture, IG1251 for the reference architecture, and IG1252 for how to evaluate a level. The aim TM Forum often attaches to all this is “zero-wait, zero-touch, zero-trouble” operations. Treat that as a direction of travel, not a description of anyone’s network today.
Here are the levels in plain terms.
Level 0, manual. The system shows dashboards and raises alarms. People do everything else: they work out what’s wrong, decide what to do, and make the change.
Level 1, assisted. Scripts take over repetitive jobs, such as pushing the same configuration to many devices or opening a ticket when an alarm fires. A person still starts each job and checks the result. If anything unexpected happens, the script stops and hands back to a person.
Level 2, partial. A closed loop runs inside one small, well-fenced area, for example tuning radio settings within one vendor’s equipment. The system can suggest or make changes, but a person approves them.
Level 3, conditional. The system senses what is happening and fixes problems on its own inside one domain, such as the optical transport layer or the mobile core. “Conditional” is the important word. When a problem crosses into another domain, a person takes over.
Level 4, high. Loops now run across domains and are driven by service goals rather than device settings. In the scenarios it was built for, the system analyses, decides, and acts without waiting for a person. People handle exceptions and set policy.
Level 5, full. Every domain, every service, the whole lifecycle, under any conditions, with no one stepping in. Standards bodies describe this as a target. Nobody runs it.
IG1252 doesn’t grade a level with one score. It looks at several abilities separately. The research for this post uses the shorthand I-AADE for them: Intent (taking in a goal), Awareness (seeing what is happening), Analysis (working out why), Decision (choosing what to do), and Execution (making the change). The table below shows how each level splits the work between system and people.
| Level | Seeing the network | Working out why | Deciding | Making the change | What people do |
|---|---|---|---|---|---|
| L0 | Alarms and dashboards | People | People | People | Everything |
| L1 | Alarms and dashboards | People | People | Scripts, started by people | Start and check every job |
| L2 | Live data in one area | System, in one area | System suggests | System, after approval | Approve each change |
| L3 | Live data in one domain | System, in one domain | System, in one domain | System, in one domain | Handle anything that crosses domains |
| L4 | Across domains | Across domains | System, in named scenarios | System, in named scenarios | Set policy, handle exceptions |
| L5 | Everywhere | Everywhere | Everywhere | Everywhere | Set goals |
One pattern in real networks is worth knowing. The abilities rarely move together. Many operators can now see a great deal, through streaming telemetry and large data pipelines. Far fewer let the system act without a person clicking approve. The reason is simple. When an automated change takes down a network, someone has to explain it.
Reality check: a scenario is not an estate
Scenario ≠ Estate. A Level 4 result in one workflow is not a Level 4 network.
TM Forum’s evaluation method grades a scenario, such as “save energy at radio sites” or “restore an optical path after a fibre cut.” It doesn’t grade a whole operator. So when you hear “Level 4,” ask one question first: Level 4 at doing what?
Here is a made-up example that is typical of what operators describe. An operator lets software put tens of thousands of radio sites into a low-power mode in the small hours, using predicted traffic. No one approves each decision. For that task, that is a fair claim to Level 4.
On the same network, a fault on a link between two vendors’ routers might still need several teams, several tools, and a few days of tickets. That task is Level 1. Same operator, same week.
Several operators have publicly committed to Level 4 in named scenarios. TM Forum’s Autonomous Networks Manifesto collects some of those pledges. A pledge is a statement of intent and investment. It is not a certificate that the live network operates at that level. I’m not going to repeat operator percentages in this post, because they come from each operator’s own method and pilot areas. Blog 13 looks at operator evidence properly.
Why does most of the network stay at Levels 1 and 2? Usually not because the AI isn’t clever enough. It is the older plumbing:
- Equipment that can only be read by polling (SNMP) or by scraping command-line output.
- Vendor element management systems (EMS) that don’t expose a standard interface.
- Inventory records that don’t match what is actually installed.
- A reasonable fear, in the NOC, of automation that breaks things at 3 a.m.
A clever model sitting on bad data and no safe way to act is just a better alarm filter.
Intent: say what you need, not how to do it
There are two ways to ask a network for something.
The imperative way gives steps: log into router 4, set this interface’s packet size to 9000, then ping to check. It is precise, and it breaks easily. If router 4 is replaced, or the link degrades next week, the script either fails or does the wrong thing, and it has no idea why the change was wanted.
The declarative way states the outcome: keep latency under 20 milliseconds and availability above 99.99% for the telemedicine service between Clinic A and Hospital B. It says nothing about routers. Blog 7’s example was “Jane has a working mobile plan.” Same idea, at business scale.
That second kind of request is an intent. TMF921, the Intent Management API, is TM Forum’s standard way to send one. There are two roles. The intent owner asks for the outcome. The intent handler is the system that has to deliver it, often the controller for one domain.
The lifecycle runs roughly like this:
- The owner sends the intent.
- The handler checks whether it can meet it and may push back or negotiate.
- Once accepted, the handler configures what it needs to and starts watching.
- If something changes, such as a fibre cut or a traffic surge, and the goal is no longer being met, the handler reports that and tries to recover, for example by moving traffic to another path.
- Throughout, the handler sends intent reports back to the owner, saying whether the goal is being met.
TM Forum’s TR292 documents describe this lifecycle in more formal detail, and the TMF921 repository on GitHub holds the API definition. One limit matters a lot. TMF921 standardises the conversation between owner and handler. It doesn’t supply the logic that works out how to meet the goal. That logic, and the controllers that make the changes, still have to be built or bought.
That is the real difference from a script. A script runs once and finishes. A handler keeps checking the goal for as long as the intent exists.
The loop that does the work
Under every level above L1 is the same basic loop. Different groups name it differently: monitor, analyse, plan, execute (MAPE-K); observe, orient, decide, act (OODA); or continuous data collection and analysis (CDCA). The idea is the same. Compare what the network is doing with what the intent asked for. If they differ, act, then look again.
Mapped onto I-AADE, one turn of the loop looks like this:
- Intent: the goal and its limits, for example the latency target and the budget.
- Awareness: live data from the network, such as streaming telemetry, metrics, and sometimes a digital twin (a software model of the network).
- Analysis: linking related alarms so one fibre cut doesn’t look like five hundred faults, and finding the cause.
- Decision: comparing possible fixes, predicting their effect, and picking one.
- Execution: making the change through a controller or an API, then going back to Awareness to check it worked.
Loops run at different speeds
This is easy to miss. Some loops run inside radio and optical equipment and act in milliseconds. Others run at the service layer and act over seconds or minutes. If a fast loop and a slow loop both try to fix the same problem without knowing about each other, they can fight. One moves traffic, the other moves it back, and the network flaps.
IG1251’s answer is autonomous domains: clear boundaries, each with its own loop, and a separate cross-domain layer above them. The reference architecture defines named interfaces for passing intent between layers, for domains working together, and for sharing knowledge. On paper that is tidy. In a network with several competing equipment vendors, the interfaces between domains are often missing, and operators fill the gap with their own integration code.
Where generative AI fits, and where it doesn’t
Large language models (LLMs) are the most talked-about part of this story. They are also the part most likely to be put in the wrong place.
A network’s control plane, the part that decides where traffic goes, has to behave predictably. An LLM doesn’t. Even a model that is right 99% of the time is wrong 1% of the time. On a network carrying emergency calls and payments, one wrong routing value is an outage.
So the pattern that holds up has two layers.
Where generative AI helps:
- Turning a person’s plain-language request into a structured intent that TMF921 can carry.
- Summarising a flood of alarms and tickets into something a NOC engineer can read in a minute.
- Suggesting possible causes after a complex incident, for a person to check.
Where it should not act alone:
- Changing routes, reserving bandwidth, or editing firewall rules on the live network.
Between the two sits a deterministic layer: rule engines, constraint solvers, and policy checks that give the same answer every time and can be audited. Every proposed change passes through it. If the change breaks a safety limit, it is rejected. If it goes wrong after it is applied, there is an automatic way back.
Put shortly: the AI proposes, the rules check, and the controllers act.
Blog 9 noted that TM Forum is extending the ODA Canvas for AI agents, and that the Canvas can expose interfaces as tools those agents can call. The same rule applies there. An agent that can call a tool still needs a check between its decision and the network. How to build and run those AI systems is a different series. On this site, that is the Friday AI Systems posts.
Catalysts: where the ideas are tried first
TM Forum Catalysts are short, multi-company projects that test an idea in a demonstration environment. They are useful for seeing where the industry is heading. They are not proof that something runs in production at scale. Three are relevant here, as TM Forum and the teams describe them:
- AI Marketing Brain used a transformer model to read customer behaviour across billing, operations, and CRM systems and predict what a subscriber is likely to want next. That’s intent on the customer side, not the network side.
- ODA-in-a-Box packaged ODA components on a Canvas to show pre-integrated parts working together through Open APIs to switch on a service.
- Converged Access with ODA put fixed broadband and 5G access under shared data models and APIs. That is a precondition for any intent that spans both.
The last one shows something the levels don’t. You can’t run a loop across two domains that describe the same customer in two different ways.
Three questions for your architecture team
- Are our automation projects building loops that keep checking a goal, or scripts that run once with a nicer dashboard?
- Where exactly do our Level 3 and Level 4 scenarios stop, and is the blocker a closed vendor system or a manual approval step?
- Does our AI roadmap keep a deterministic check between anything a model suggests and anything that changes the live network?
Key takeaways
- Levels are graded per scenario. Ask “Level 4 at doing what?” before comparing any two claims.
- Intent is a standing request, not a script. TMF921 standardises the conversation between owner and handler. The logic that meets the goal is still yours to build or buy.
- AI proposes, rules check, controllers act. Generative AI belongs at the edges: writing intents and explaining incidents. A deterministic check guards the live network.
Terms in this post
| Term | Meaning in this post |
|---|---|
| AN | Autonomous Networks. TM Forum’s work on levels of network autonomy. |
| I-AADE | Intent, Awareness, Analysis, Decision, Execution. The abilities graded at each level. |
| TMF921 | Intent Management API. How an intent is sent and reported on. |
| MAPE-K | Monitor, analyse, plan, execute, over shared knowledge. One name for the loop. |
| OODA | Observe, orient, decide, act. Another name for the loop. |
| CDCA | Continuous data collection and analysis. TM Forum’s name for the watching half of the loop. |
| NOC | Network operations centre. |
| EMS | Element management system. A vendor’s tool for managing its own equipment. |
| SNMP | Simple Network Management Protocol. An older way of reading device status by polling. |
| LLM | Large language model. |
| CRM | Customer relationship management. |
| ODA | Open Digital Architecture. |
TM Forum · Part 10 of 14
11 · Practical Implementation
Previous: TM Forum ODA Canvas: The Runtime the Component Does Not Touch · All 14 parts
Leave a Reply