Disconnected Networks: The Transition to Intent-Based Autonomous Operations

The telecommunications industry, a cornerstone of global connectivity, has been experiencing a technological renaissance for some time, driven by innovations such as 5G, IoT, cloud computing, and AI. As a result, network management is becoming increasingly difficult. You need automation to handle routine tasks, monitor network health, and respond to issues in real time. However, communications service providers (CSPs)’ existing skill sets may not match the changing requirements of this dynamic environment. To succeed in the modern era, CSPs need a well-rounded team, including data scientists to interpret and operate data, software developers to automate through vendor application programming interfaces (APIs), and service assurance engineers to design closed loops to ensure service reliability. Required.

By building teams with diverse experiences, CSPs are bridging the gap while also benefiting from significant advances in concurrent trends. Programming languages ​​have evolved into a low-code/no-code paradigm, and with the advent of generative AI, we are at the point where underlying models can generate formal code based on natural language descriptions of tasks. This gave a new perspective on the concept. Intent-based networking (IBN), human administrators express high-level network goals in natural language known as “intents,” and these human intentions are automatically translated into network policies and configurations. IBNs have the potential to improve network management and can be a game-changer in bridging talent gaps within telcos. Going one step further, autonomous network (AN) promises to leverage intents as inputs to autonomously self-organize, self-optimize, and self-heal networks as conditions change.

Although we can envision a bright future for both IBN and AN, there are ongoing concerns about feasibility and program application, including expression of intent, accurate translation into network configuration, system transparency, and complexity. In this blog, we look at areas with potential real-world applications and analyze the challenges you may face along the way.

Motivating Story: Introducing a New Service Without Intention

To understand the need to streamline the interaction between CSP teams and the network, we will use the deployment of a new service as an example.

It is assumed that CSP network operations are automated according to the specifications described in the TMF Introductory Guide to Autonomous Network Technology Architecture 1230 (IG1230). In this context, a CSP’s OSS includes (1) an orchestrator for service provisioning, automated provisioning, and automated testing, and (2) a network inventory that collects data and generates insights into network health to drive data-driven decisions. There is a guarantee system. in the context of closed-loop control, and (3) a policy manager that coordinates network behavior using predefined policies to ensure that it is consistent with the policies of the wider CSP. Simply put, automated operations revolve around the tight coupling of services with human-designed TOSCA service descriptors, configurations, policies, and imperative workflows, to which service designers add intelligence and decision-making during design time. Service designers must proactively anticipate the various conditions that may arise in the network and provide detailed guidance on how to resolve them. As long as future conditions are predicted and policies are in place to deal with them, a zero-touch experience is achieved.

We use the terms day 0, day 1, and day 2 to refer to the different service life cycle stages. service design, Service instantiation and service guaranteeeach.

• Service design consists of the development of various service assets, as depicted in Figure 1. This is the job of the service design team, who must understand the Day 1 and Day 2 operations of the service and create the necessary workflows and scripts. The red line in Figure 2 represents the service provisioning process for a new service, confirming that the service is now available for ordering.

• Service instantiation occurs when a service order arrives based on a subscriber request. In today’s CSP, service orders typically arrive through the TMF 641 interface of the Service Order Manager (SOM). When a service order is received, the service orchestrator executes workflows and ensures that the requested monitoring configurations, PM/FM models, and policies are deployed and executed. The service instantiation in Figure 2 is represented by the green line.

• Service assurance follows a closed-loop approach in which the terms of deployed services undergo continuous monitoring and automated lifecycle actions. The guaranteed closed loop in Figure 2 is shown by the blue line.

In summary, this is a design phase that requires a significant amount of manual effort as instructions for the new service must be provided to the network.

What is intent?

In IBN, an intent represents a high-level goal that a CSP wants to achieve on the network. Rather than handling complex low-level network configurations during Day 0 operations as described above, engineering teams express goals as intents, and the logic supporting the intent translates these into the required network configurations that meet the intent goals.

After applying the configuration to the network, AN continuously monitors the deployed services and adjusts the configuration to keep operations consistent with specified intent. AN extends the use of intents to day 2 tasks.

IBN and AN perspectives

Next, we present some aspects of how intention could potentially revolutionize established practices of earlier eras.

• Day 0 tasks:
  • Preparing new services – Utilizes generative AI to process natural language input to automatically complement service requirements.
  • New service introduction – Define and create new services using natural language, such as “Provide customized connectivity solutions for secure communications within healthcare institutions” or “Enable IoT device communication across smart city infrastructure” Leverage AI to support automatic creation of required service assets do.
  • Automatic generation of resource drivers by vendor– Leverage generative AI to generate vendor-specific resource drivers based on vendor documentation.
• Day 1 tasks:
  • Simplify service ordering – Customers can request services using natural language. This user-friendly approach enables new service ordering experiences, such as mixing and matching products from a catalog.
  • Feasibility study – Streamline verification checks when customers express their intent by efficiently assessing critical factors such as fiber line availability. The result is less burden on network engineers, faster service validation, and more agile and responsive deployments.
• Day 2 tasks:
  • Dynamic service guarantee – Enables networks to respond intelligently to changing conditions and user needs. Flexible intent-based policies improve agility, ensuring real-time reliability and responsiveness of network services.

Challenges of IBN and AN

There are two main challenges that need to be addressed:

1. How do you express and communicate your intentions?
2. How to execute an intent: What does an intent handler look like?

TM Forum introduced the TMF921 Intent-Based Networking API, which provides a structured framework for defining high-level network intents. TM Forum defines its intent as follows:Intent is a formal specification of all expectations, including requirements, goals, and constraints, given to a technical system.“. But that part official specifications This raises concerns. Network engineers should become familiar with this formal language to utilize the full potential of the intent concept. Furthermore, intents with a formal specification do not necessarily reduce the number of parameters that must be provided together. These aspects challenge the simplification of network management typically associated with IBNs.

Additionally, by formalizing the intent specification, the intent handler, a core component of the IBN that contains the logic for intent interpretation, simply becomes a deterministic interpreter of the intent format language. This raises the question of how to evolve intent handlers into autonomous systems with declarative behavior that do not require humans to anticipate all potential network states and provide specific instructions for resolution. Otherwise, the system operation cannot be successfully switched from automated to autonomous (TMF IG1230).

Future blogs will cover the challenges and opportunities of IBN and AN in more detail. Want to know more? Contact maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com and tmtattis@ae.ibm.com.

change for the future
by communication