Autonomous vs. automated: a distinction that matters.
Before getting into control loops, it's worth being precise by differentiating automation from autonomy. "Automated" describes a process that runs without human intervention but follows pre-set instructions or rules. "Autonomous" describes something that can make decisions and operate independently – without human control guiding each step.
Both automated and autonomous systems can use closed loops and be intent-driven. But only the autonomous network is intelligent enough to make appropriate decisions across a genuinely wide set of scenarios, including ones nobody has explicitly programmed for.
The anatomy of a control loop.
At its core, an autonomous network is a control theory problem, built from continuous control loops. Each loop has four essential stages.
Sense means observing the network and accurately assessing its current state. This sounds simple, but in a complex network, knowing what to watch is critical – and that guidance has to come from a trusted "single source of truth," typically a network inventory that holds the definitive, up-to-date state of every element and service.
Analyse is where the loop figures out what's actually wrong. Networks generate enormous volumes of alerts, and pinpointing the true root cause among all that noise is genuinely hard. This is where AI shines – correlating and processing large amounts of data quickly. But again, it depends on that same single source of truth, both as an input and as a knowledge base for drawing sound conclusions.
Decide is where operator intent comes into play. The operator expresses business goals in a clear, abstract way – something like "prioritize voice quality over data speed." Large language models can make this intent-setting more natural and conversational, but the actual decision logic underneath should rely on precise, reliable methods rather than AI alone.
Act translates the decision into real changes on the network, via APIs to network elements and management systems – typically handled by orchestrators that execute changes safely and consistently. Notably, AI is deliberately kept out of this final stage. APIs need to be explicit and deterministic; introducing AI at the point of actual network change risks the most damage at the most critical moment.
Why "more data" isn't always "better decisions".
One of the more counterintuitive insights from this approach is about how telecom networks actually behave. It's tempting to assume that feeding more information into a control system always improves performance – and that's true for things that vary gradually. But most elements in a telecom network are discrete: a configuration is either exactly correct or wrong.
Consider a cable plugged into the wrong port – one position off from where it should be. Control theory might say that's "closer" to correct than being two ports off. Operational reality says: it doesn't matter, the network still doesn't work. With a tightly scoped feedback loop (intent-based self-healing) and good composition of smaller pieces, this discrete complexity becomes manageable.
At higher levels – where decisions span multiple network domains and involve real business trade-offs, like how to fairly allocate limited resources between customers – the picture changes. Here, decisions genuinely are more gradual, and the system needs richer, more nuanced intelligence to stay stable and predictable.
Divide and conquer: separation of concerns.
Rather than building one giant control loop that tries to handle everything, autonomous network architectures should be built from many smaller, independent control loops, connected through clean, standardized abstractions for expressing intent, desired state, and current state. This is where the "divide and conquer" principle earns its name.
These loops can be organized in two complementary ways. Horizontally, by separating different technical domains – radio, transport, core – each managed under its own autonomous control. Vertically, by layering higher-level loops that coordinate and oversee the domains below, capturing more holistic, service-level control.
The goal is loops that operate independently but integrate cleanly – what could be described as "autonomy-friendly" architecture, aligned with the TM Forum's functional architecture for autonomous networks. This matters because telecom networks are inherently distributed, both geographically and across technical and administrative domains.
Today's team structures and operational boundaries were largely designed around manual processes – and the shift to autonomous operations will likely require rethinking those boundaries from the ground up.
Crucially, this doesn't mean every control loop needs its own separate orchestrator. A well-designed platform can host many control loops and manage their interactions within a single, coherent architecture – avoiding both duplication of effort and the dreaded vendor sprawl.
Building this in practice.
Designing, implementing, and connecting these control loops – across radio, transport, core, and service layers – is exactly the kind of work Tieto Tech Consulting specializes in. With more than 3,000 telecom-focused software engineers across the Nordics, Europe, and the Americas, and deep experience in multivendor systems integration, we help operators turn this architectural theory into operational reality, including the precise network analysis capabilities (via our SBA technology) that feed the "Sense" and "Analyse" stages of every loop.
Go deeper.
This is just a glimpse of how control loops fit together in a real autonomous network architecture. Our strategic brief, co-authored with FNT Software and Inmanta – "Are Autonomous Networks Real? A Telco's Guide on How to Move Forward" – goes much further, including a full worked example of how config-and-resource loops, monitor-and-fix loops, and predictive loops layer together in practice.
Download the full brief to see the complete architecture, including diagrams of how horizontal and vertical control loops map onto real network operations.
