Networks unchained: the shift toward intent-based autonomous operations – IBM Blog

Telecommunications industry, a cornerstone of global connectivity, has been going through a technological renaissance for some time, driven by innovations such as 5G, IoT, cloud computing and AI. As a result, networks have become increasingly hard to manage. There is a need for automation to handle routine tasks, monitor network health and respond to issues in real-time. However, the existing skill sets within communication service providers (CSPs) may not align with the evolving demands of this dynamic landscape. To succeed in the modern era, CSPs need versatile teams, including data scientists for data interpretation and operations, software developers for automation through vendor application programming interfaces (API) and service assurance engineers for designing closed loops to ensure service reliability.

While CSPs bridge the gap by building teams with diverse experience, they also simultaneously benefit from significant advances on a concurrent trend. Programming languages have evolved toward low-code/no-code paradigms and with the emergence of generative AI, we are at a point where foundational models can generate formal code based on natural language descriptions of the tasks. This gave the new perspective to the concept of intent-based networking (IBN), where human administrators express high-level network objectives in natural language known as “intents” and that these human intents are automatically translated into network policies and configurations. IBN has the potential to improve network management and could become a game-changer in addressing the talent gap within telcos. Taking it a step further, autonomous networks (AN) promise to utilize intents as inputs to autonomously self-configure, self-optimize and self-heal networks as their conditions evolve.

While we can envision a bright future for both IBN and AN, there are persistent concerns about their feasibility and program applications including intent expression, accurate translation into network configuration, system transparency and complexity among others. In this blog, we dive into the areas where their practical application hold potential and analyze the challenges they may encounter along the way.

A motivating case: introducing new services without intents

To understand the need for streamlining interactions between CSP teams and the network, we will use a new service deployment as an example.

We assume that the CSP network operation is automated as per the specifications outlined in the TMF Introductory Guide 1230 (IG1230) on Autonomous Networks Technical Architecture. In that context, the CSP’s OSS has (1) an orchestrator for service provisioning, automated provisioning and automated testing, (2) an assurance system with network inventory that collects data, creates insights about the network state and hence facilitates data-driven decision making in the context of closed-loop control and (3) a policy manager that steers network behavior using predefined policies, ensuring alignment with the broader CSP’s policies. In a nutshell, automated operations revolve around tight coupling of services with their assigned human-designed TOSCA service descriptors, configurations, policies and imperative workflows in which intelligence and decision-making is added by service designers during the design time. Service designers must proactively foresee a wide range of conditions that may occur in the network and provide detailed instructions on how they must be addressed—zero-touch experience is achieved as long as the future conditions have been foreseen and there are policies to handle them.

We use terms Day 0, Day 1 and Day 2 for different service lifecycle stages, namely service design, service instantiation and service assurance, respectively.

• Service design comprises the development of various service assets as depicted in Figure 1. This is the task of the service design team, who need to understand the Day1 and Day 2 operations of the service and produce the workflows and scripts required. The red lines in Figure 2 depict the service provisioning process of a new service, ensuring that the service can now be ordered.

• Service instantiation occurs when the service order arrives, following a subscriber request. Today in CSPs the service order typically arrives over the TMF 641 interface from the service order manager (SOM). When the service orchestrator receives the service order, it ensures that the workflows are executed and that the requested monitoring configurations, PM/FM models and policies are deployed and running. We show the service instantiation in the Figure 2 in green lines.

• Service assurance follows a closed-loop approach wherein the conditions of deployed services undergo continuous monitoring and automated lifecycle actions. We show the assurance closed loop in the Figure 2 in blue lines.

In summary, it is the design phase that involves a substantial amount of manual work, as it is necessary to furnish the network with instructions for the new service.

What are intents?

In IBN, intents refer to high-level objectives that CSP wants to achieve in its network. Instead of dealing with complex low-level network configurations during the Day 0 operations as discussed above, the engineering teams express the objectives with intents and the logic underpinning intents translates them into the required network configuration that fulfills the intent objective.

Following the application of the configurations to the network, the AN then continuously monitors the deployed services and adapts the configuration to ensure that the operation remains in alignment with the specified intents. The AN extends the use of intents into Day 2 operations.

Perspectives of IBN and AN

Next, we provide some of the aspects where intents could potentially revolutionize established practices from the pre-intent era:

• Day 0 Operations:
  • Preparation for new services – Leverage generative AI to process natural language input to autonomously supplement service requirements.
  • Introduction of new services – Define new services using natural language, such as “provide a tailored connectivity solution for secure communication within healthcare institutions” or “enable IoT device communication across smart city infrastructure” and leverage generative AI for automatic generation of the necessary service assets.
  • Automated generation of vendor-specific resource drivers ­– Utilize generative AI to create vendor specific resource drivers, based on vendor documentation.
• Day 1 Operations:
  • Simplification of service order – Allows customers to request services using natural language. This user-friendly approach enables a novel service ordering experience, such as mixing and matching offerings from the catalog.
  • Feasibility checks – Streamlines validation checks as customers express their intents by efficiently assessing critical factors like fiber optic line availability. The result is reduced burden on Network Engineers, faster service validation, and more agile and responsive deployment.
• Day 2 Operations:
  • Dynamic service assurance – Enables networks to intelligently respond to changing conditions and user needs. Flexible intent-based policies enhance agility, ensuring real-time reliability and responsiveness of network services.

The challenges with IBN and AN

There are two main challenges to be addressed:

1. How to express and convey an intent?
2. How to execute on an intent: what does the intent handler look like?

TM Forum introduced the TMF921 Intent-based Networking API, offering a structured framework for defining high-level network intents. TM Forum defines the intent as follows: “Intent is the formal specification of all expectations including requirements, goals, and constraints given to a technical system”. However, the part formal specification introduces a concern: network engineers would need to familiarize themselves with this formal language to harness the full potential of the intent concept. What is more, intents with formal specification do not necessarily reduce the number of parameters that must be provided with them. This aspect challenges the anticipated streamlining of network management that one would typically associate with IBN.

Furthermore, by formalizing the intent specification, the intent handler, the core component of IBN that holds the logic for intent interpretation, becomes merely a deterministic interpreter of the intent formal language. The question raises on how we evolve the intent handler into an autonomous system with declarative way of operation wherein humans are not required to anticipate every potential network condition and provide specific instructions for its resolution. Otherwise, the system operation cannot successfully transition from automated to autonomous (TMF IG1230).

In future blogs we will address the challenges and opportunities of IBN and AN in more detail. Want to learn more? Contact us at maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com and tmtattis@ae.ibm.com.