Autonomous network system
Technologies like 5G, IoT, cloud computing, and AI are revitalizing the telecommunications sector, which is vital to global connectivity. Consequently, networks have gotten harder to maintain. Automation is required to manage repetitive tasks, keep an eye on the health of the network, and react quickly to problems. But the communication service providers’ (CSPs’) current skill sets might not match the changing needs of this changing environment.
CSPs need adaptable teams to thrive in the modern era: software developers for automation through vendor application programming interfaces (API), data scientists for data interpretation and operations, and service assurance engineers for creating closed loops to guarantee service reliability.
By assembling teams with a variety of backgrounds, Communication Service Providers not only close the gap but also gain from noteworthy developments in a related field. With the advent of generative AI, programming languages have progressed toward low-code/no-code paradigms. Today, foundational models are able to produce formal code from natural language descriptions of tasks. The notion of intent-based networking (IBN) gained a fresh viewpoint as a result.
In intent based networking, human administrators articulate high-level network goals using natural language, or “intents,” and their intentions are automatically converted into network configurations and policies. In addition to potentially changing the game in terms of closing the talent gap within telcos, intent based networking has the ability to enhance network management. Furthermore, as network conditions change, autonomous networks (AN) claim to be able to use intents as inputs to automatically self-configure, self-optimize, and self-heal networks.
Even though both intent based networking and Autonomous Network have bright futures ahead of them, ongoing questions remain regarding their viability and program applications, including intent expression, precise translation into network configuration, system complexity, transparency, and other issues. In this blog, we explore the domains in which their real-world implementation has the potential and examine the obstacles that might arise.
An example of motivation: launching new services with no intention of
In order to comprehend the necessity of optimizing communication between CSP teams and the network, let’s examine the example of a new service deployment.
It is assumed that the Communication Service Providers network operates automatically in accordance with the guidelines provided in the TMF Introductory Guide 1230 (IG1230) on the Technical Architecture of Autonomous Networks. Within that framework, the CSP’s OSS consists of the following:
(1) An orchestrator for automated provisioning, testing, and service provisioning.
(2) An assurance system with network inventory that gathers information, generates insights about the state of the network, and thus enables data-driven decision making within the framework of closed-loop control.
(3) A policy manager that directs network behavior based on predefined policies, guaranteeing compliance with the wider Communication Service Providers policies.
To put it briefly, automated operations involve tightly coupling services with the TOSCA service descriptors, configurations, policies, and imperative workflows that are assigned to them by humans. During the design phase, service designers add intelligence and decision-making to these workflows. Zero-touch experience is achieved as long as future conditions have been anticipated and policies have been put in place to handle them. Service designers must proactively anticipate a wide range of conditions that may arise in the network and provide detailed instructions on how they must be addressed.
For the various stages of the service lifecycle-service design, service instantiation, and service assurance, respectively-IBM refer to them as Day 0, Day 1, and Day 2.
- The creation of diverse service assets is included in service design, as shown in Figure 1. The service design team is responsible for this; they must create the necessary workflows and scripts and comprehend the Day 1 and Day 2 operations of the service. Figure 2’s red lines show how a new service is provisioned, making it possible for orders to be placed for the service.
- After a subscriber requests a service, the service is instantiated when the service order is received. The service order manager (SOM) normally sends the service order to Communication Service Providers these days via the TMF 641 interface. Upon receipt of the service order, the service orchestrator guarantees the execution of the workflows and the deployment and operation of the requested monitoring configurations, PM/FM models, and policies. In Figure 2, the service instantiation is displayed using green lines.
- The closed-loop methodology of service assurance involves automated lifecycle actions and constant monitoring of deployed services’ conditions. In Figure 2, the assurance closed loop is displayed using blue lines.
To sum up, a significant amount of manual labor is required during the design phase because the network needs to be provided with instructions for the new service.
What do intentions mean?
The term “intents” in intent based networking refers to the broad goals that Communication Service Providers hopes to accomplish within its network. As previously mentioned, the engineering teams express the objectives with intents, and the logic underlying the intents translates them into the necessary network configuration that fulfills the intent objective. This eliminates the need for the engineering teams to deal with intricate low-level network configurations during Day 0 operations.
After the configurations are applied to the network, the Autonomous Network keeps an eye on the services that have been deployed and modifies the configuration as needed to keep the operation in line with the intended goals. The use of intents is expanded into Day 2 operations by the Autonomous Network .
Views from Autonomous Network and Intent Based Networking
Next, IBM list a few areas where intents might potentially transform pre-intent established practices into revolutionary ones:
Day 0 Operations: Setting up new services – Use generative AI to process natural language input and add requirements on its own.
Launch of fresh services Use natural language to describe new services, e.g., “offer a tailored connectivity solution for secure communication within healthcare institutions” or “enable IoT device communication across smart city infrastructure.” Then, use generative AI to generate the required service assets automatically.
Automated creation of resource drivers tailored to individual vendors Based on vendor documentation, use generative AI to create resource drivers unique to each vendor.
Day 1 Operations: Streamlining the service order process so that users can make requests in plain English. A unique service ordering experience, like mixing and matching products from the catalog, is made possible by this user-friendly approach.
Feasibility checks: These efficiently evaluate important factors, such as the availability of fiber optic lines, and expedite validation checks as customers express their intents. As a result, network engineers have less work to do, services are validated more quickly, and deployment is more responsive and agile.
Day 2 Operations: Dynamic service assurance allows networks to adapt to changing circumstances and user demands with intelligence. Intent-based policies that are flexible improve agility and guarantee the responsiveness and dependability of network services in real time.
The difficulties with Autonomous Network and intent based networking
There are two primary issues that need to be resolved:
How do you communicate and express intent?
What does the intent handler look like and how can I execute on an intent?
The TMF921 Intent-based Networking API was unveiled by TM Forum and provides a structured framework for specifying high-level network intents.
The intent is defined by TM Forum as follows:
“A technical system’s intent is the formal specification of all expectations, including requirements, goals, and constraints.” To fully utilize the intent concept, network engineers would need to become familiar with this formal language, which is why the part formal specification raises concerns. Furthermore, formal specifications do not always result in fewer parameters needing to be supplied with them. This feature calls into question the expected simplification of network administration that is commonly associated with intent based networking.
Moreover, the intent handler-the central part of intent based networking that contains the reasoning for intent interpretation-becomes nothing more than a deterministic interpreter of the intent formal language as a result of formalizing the intent specification. The issue is how to transform the intent handler into a declarative, autonomous system so that people don’t have to predict every possible network situation and give detailed instructions on how to fix it. If not, the automated to autonomous system operation transition cannot be accomplished.
