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, networks have become increasingly difficult 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 capabilities of communications service providers (CSPs) may not be aligned with the evolving needs of this dynamic landscape. To succeed in the modern era, CSPs need diverse teams including data scientists for data interpretation and operations, software developers for automation via vendor application programming interfaces (API), and service assurance engineers for closed-loop design to ensure service reliability.
While CSPs are bridging this gap by building teams with diverse experiences, they are also benefiting from significant advances in a concurrent trend. Programming languages have evolved into low-code/no-code paradigms and with the advent of generative AI, we have reached a point where basic models can generate formal code based on natural language descriptions of tasks. This gave the concept a new perspective Intent-based networking (IBN), in which human administrators express high-level network goals in natural language, called “intents,” and those human intents are automatically translated into network policies and configurations. IBN has the potential to improve network management and could play a critical role in closing the talent gap in telecommunications companies. Let's go one step further, autonomous networks (AN) promise to use intentions as inputs for the autonomous self-configuration, self-optimization, and self-healing of networks as their conditions evolve.
While we can envision bright futures for both IBN and AN, there are ongoing concerns about their feasibility and program applications, including expression of intent, accurate translation into network configuration, system transparency and complexity, and others. In this blog, we delve into the areas where their practical application holds potential and analyze the challenges they may face along the way.
A motivating case: introducing new services without intentions
To understand the need to optimize interactions between CSP teams and the network, let's use a new service deployment as an example.
We assume that CSP network operations are automated according to the specifications in TMF Implementation Guide 1230 (IG1230) on the Technical Architecture of Autonomous Networks. In this context, the OSS of the CSP has (1) an orchestrator for service provisioning, automated deployment and automated testing, (2) a backup system with network inventory that collects data, creates insights into the network status and thus facilitates data-driven decision making in the context of the Closed-loop control and (3) a policy manager that controls network behavior using predefined policies to ensure alignment with broader CSP policies. In short, automated operations are about tightly coupling services with their assigned human-designed TOSCA service descriptions, configurations, policies, and imperative workflows, where service designers add information and decision-making during design time. Service designers must proactively anticipate a variety of conditions that may arise on the network and provide detailed instructions on how to address them – a zero-touch experience will be achieved as long as future conditions have been anticipated and there are guidelines for dealing with them with them there.
We use the terms Day 0, Day 1, and Day 2 to refer to different service lifecycle phases, namely service design, service instantiation, and service assurance, respectively.
- Service design involves the development of various service assets, as shown in Figure 1. This is the job of the service design team, which must understand the Day1 and Day 2 operations of the service and create the necessary workflows and scripts. The red lines in Figure 2 represent the service delivery process of a new service and ensure that the service can now be ordered.
Figure 1: Day 0 service design process – service asset design
- Service instantiation occurs when the service order arrives after a subscriber request. Today, at CSPs, the service order typically arrives via 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 executed. We show the service instantiation in green lines in Figure 2.
- Service assurance follows a closed-loop approach, subjecting the conditions of the services provided to continuous monitoring and automated lifecycle actions. We show the closed safety loop in blue lines in Figure 2.
Figure 2: Day 0/Day 1/Day 2 interactions
In summary, the design phase requires a significant amount of manual work as the network needs to be provided with instructions for the new service.
What are intentions?
In IBN, intents refer to high-level goals that CSP wants to achieve in its network. Instead of dealing with complex low-level network configurations during Day 0 operations as described above, engineering teams express the goals with intents, and the logic underlying the intents translates them into the required network configuration that meets the intent goal.
After applying the configurations to the network, the AN then continuously monitors the services provided and adjusts the configuration to ensure that operations remain consistent with the stated intentions. The AN extends the use of intents to Day 2 operations.
Perspectives from IBN and AN
Next, we present some aspects where intentions could potentially revolutionize established practices that predate intentions:
- Day 0 Operations:
- Prepare for new services – Use generative AI to process natural language input to autonomously complement service requirements.
- Introduce new services – Define new services using natural language, e.g. B. “Provide a tailored connectivity solution for secure communication within healthcare facilities” or “Enable IoT devices to communicate across the smart city infrastructure” and use generative AI to automatically generate the required service resources.
- Automated generation of vendor-specific resource drivers – Use generative AI to create vendor-specific resource drivers based on supplier documentation.
- First day operation:
- Simplify service ordering – Allows customers to request services in natural language. This user-friendly approach enables a new service ordering experience, such as mixing and matching catalog offerings.
- Feasibility Checks – Streamlines validation checks as customers express their intent by efficiently assessing critical factors such as fiber availability. The result is reduced burden on network engineers, faster service validation, and more agile and responsive delivery.
- Day 2 operations:
- Dynamic Service Assurance – Enables networks to intelligently respond to changing conditions and user needs. Flexible, intent-based policies increase agility and ensure real-time reliability and responsiveness of network services.
The challenges with IBN and AN
There are two main challenges to overcome:
- How to express and convey an intention?
- How to execute an intent: What does the intent handler look like?
TM Forum introduced the TMF921 Intent-based Networking API, providing a structured framework for defining high-level network intent. The TM Forum defines intent as follows: “Intent is the formal specification of all expectations, including requirements, goals and constraints, placed on a technical system.” However, the partially formal specification raises concerns: network engineers would have to familiarize themselves with this formal language familiarize yourself with the intention concept to its full potential. Additionally, formal specification intents do not necessarily reduce the number of parameters that need to be provided with them. This aspect challenges the expected streamlining of network management that one would normally associate with IBN.
Furthermore, by formalizing the intent specification, the intent handler, the core component of IBN that contains the logic for intent interpretation, becomes merely a deterministic interpreter of the formal intent language. The question is how do we evolve the intent handler into an autonomous, declarative system that does not require humans to anticipate every potential network condition and provide specific instructions for resolving them? Otherwise, the system operation cannot be successfully converted from automated to autonomous (TMF IG1230).
In future blogs we will discuss the challenges and opportunities of IBN and AN in more detail. Would you like to find out more? Contact us at [email protected], [email protected] and [email protected].
Transform for the future
with telecommunications
Was this article helpful?
YesNO
Telco Network Cloud Architect at IBM
Associate Partner and Industry Expert – Network and OSS Transformation, IBM Consulting
Senior Partner – Customer Partner
