ODA blog series: Taking autonomous networks from theory to reality

What is an autonomous network?

TM Forum defines an autonomous network as a set of network and software platforms that are capable of sensing its environment and adapting its behavior accordingly with little or no human input.

This seemingly simple, and obvious statement does not portray the complexity and integration requirements needed to deliver on this autonomous state, especially if you consider the legacy network and software platforms most CSPs have. That is why with the participation of more than 200 professionals from 95 companies, the Autonomous Networks project, has quietly put all the pieces in place to deliver a standardized approach to intent-based network operations, including the language needed to express intent (the desired outcome) in a way that machines can interpret, supported by a new Open API.

CSPs needed an industry-led set of artifacts to support them in implementing autonomous networks. The first major breakthrough came from creating an industry standard, vendor agnostic, reference architecture that enabled all parties to understand the relationship within the autonomous domain across three operational layers from the business through service to resource operations. The second major breakthrough came when TM Forum created the six levels of automation which helps CSPs understand where they are in their journey towards a fully autonomous network.

However, these two aspects alone are not enough to roll out an autonomous network. We need more practical, operational requirements. So, TM Forum members within the autonomous network initiative set about defining two further areas:

Control Loop: AI Closed-Loop Automation & Anomaly Detection & Resolution (CLADRA) and related collateral that uses closed loops to enable CSPs to transform their network operations by using AI-driven closed loop automation to detect anomalies, determine resolution and implement the required changes to the network within a continuous highly automated framework.

• Intent: Where the role of “intent” in autonomous networks is to communicate requirements, goals, constraints, and preferences of the customer to an autonomous system. This knowledge enables the system to evaluate the state of the controlled infrastructure and the utility of actions.

Why do we need “intent” within autonomous networks

Autonomous networks are systems that are governed according to specified objectives or expectations which are known as intents. Intent comprise of the requirements, goals and constraints in a simplified manner that is abstracted from the technical inner workings. It enables a level of autonomy where the system can adapt its behavior and generate new solutions instead of just following human-defined recipes and policies.

To put it more simply, intents are the “what” not the “how”. You are therefore telling the system what you want it to do, without having to tell it how to do it. So, how do we turn intent – which in human terms is a fairly abstract concept (just because you intend to do something doesn’t mean you will do it) - into action?

How do we go from “intent” to “action”

Intent describes a customer's needs and the service provider's contractual obligations - service level agreement (SLA). It enables exploration of potential solution options and evaluation of actuation strategies in order to find one that delivers the best available business result. Intent-driven operation refers to models, interfaces and architectures for managing this knowledge and operating a system accordingly.

We need to change the SLA requirements (intent) of the customer into action within the network. This is where TM Forum’s members have developed two key concepts of intent in autonomous networks:

1. Intent Ontology: First we need to translate the intent so that it can be expressed through a common vocabulary called the TM Forum Intent Ontology. An industry-defined ontology is critical as autonomous systems can only adapt to the requirements if they actually know what they are. That is why it is critical they are expressed in a formal, machine-readable, and unambiguous vocabulary.
2. Intent management function: The turning of the SLA requirement (intent) into an action is then left to the handler, which we have defined as the intent management function. The intent management function decides suitable actions needed to fulfill the intent and ensure this intent is communicated and implementable across a CSP's network.

TM Forum members will be demonstrating intent-driven autonomous networks in a number of Catalyst proof-of-concept projects at Digital Transformation World (DTW). These Catalysts are championed by CSPs - AIS, MTN, Orange, Jio, TIM, Sparkle, Telenor and Vodafone as well as key industry players including, Huawei, Ericsson, Intraway, CloudBlue, TEOCO, University of Milan and the CAICT.

Read ODA blog series:

• Interoperability mismatch” to “Plug and Play” ecosystem
• Leading companies prove real-world value of TM Forum Open APIs
• The creation of industry-wide Open Standard for a “plug and play” ecosystem
• Creating next-gen telco interoperability on cloud native networks
• Taking autonomous networks from theory to reality