What Will Make Intent-Based Automation Possible for 5G Slicing?

Maximizing operations automation is essential for CSPs to offer on-demand services at the lowest cost across a network with diverse technology and service domains. With VNFs evolving into CNFs, more frequent releases, multiple cloud platforms, E2E network slicing, and a much larger ecosystem of players, there are simply too many moving parts for partial automation.

Intent-based automation is the clear goal. Intent refers to a business or service request, such as opening a new smart office or updating the security policy globally regardless of the technical platform. The service is abstracted from technical/platform implementation, so administrators or business owners can simply express their intent, and orchestration systems automatically accomplish the tasks without implementation experts. This significant operations simplification means CSPs can execute and adapt to any changing needs much faster.

However, the degree of automation depends on how good the service model is.

Before intent can be executed by service orchestration, predefined service models need to be created that define the intent rules, policies and processes. Intent-driven service models and context (specific inputs and inventory) enable automation of all aspects of the lifecycle and closed-loop control. However, it all gets more complicated with 5G network slicing.

5G Slicing Demands a Fully Flexible and Dynamic Service Model
5G network slicing requires slice service models for automating the execution of intent across multiple network domains to:

• Rapidly set up, deploy and terminate a network slice.
• Continuously assure that network slice SLAs are maintained.
• Dynamically adapt to the changing needs of slice services to maintain SLAs.
• Easily customize by catering to various xNF permutations, requirements and maturity levels, so CSPs can develop new services and use cases without a significant dependence on the individual components of the underlying network.

The problem is that slice modeling is very complex due to the sheer amount of slice attributes, relationships between elements, dependencies and mappings across the lifecycle, and closed-loop control. As a result, slice service models are more than slice templates. However, there is no single domain-specific language or unified data model that is good enough to build the model for all of the required operational lifecycle transitions and modifications of a network slice.

Netcracker Service Design Studio overcomes these issues by creating dynamic composite slice service models using multiple well-known modeling languages, domain specific languages and programming languages. YANG is used for the data model and complemented with imperative and declarative policies and scripts using multiple, popular languages to describe the full list of slice attributes, SLA and QoS parameters, charging requirements, topology and capacity dependencies, and slice lifecycle transition logic. The composite model is the lifecycle managed as a single model, eliminating the complexity of creating and linking many separate models.

Netcracker’s comprehensive approach to modeling creates fully flexible and dynamic composite service slice models (and service models in general). They increase the level of automation for all of the lifecycle and closed-loop control events and avoid model redesigns when service anomalies occur.

Rapid Slice Deployment Requires a Comprehensive Library of Slice Service Models
The slice service model is stored as a package in the service catalog (part of service orchestration) with all of the appropriate artifacts for implementing intent-based and model-driven orchestration.

CSPs must build up a large catalog or library of slice service models for all popular customer use cases so that they can be quickly instantiated and provisioned at both the domain and cross-domain levels.

Netcracker is working closely with CSPs to build a library of network slice models for popular use cases. The library goes beyond just slice templates by including lifecycle transitions, control-loop logic, slice service relationships and mappings, and topology and capacity dependencies.

Creating Slice Service Models On the Fly Will Be a Key Differentiator
If a user makes a service request and there is no suitable slice service model to execute it, CSPs need the capability to create and customize slice service models on the fly. Netcracker’s Service Design Studio provides this capability using samples from other service models and a user-friendly GUI with adjustable parameters for the new use case.

The tools of Service Design Studio include a wizard to propose configuration samples for network-specific parameters and a manual workplace with visual topology composition. Users simply describe their intent and the tools hide complicated details while guiding or automating the rest of the process.

In summary, intent-based automation is the clear goal for CSPs to reach the levels of automation needed for complex services and E2E network slicing. However, the extent of this automation will depend on two aspects. First, how comprehensive and dynamic the service model is and its ability to avoid too many manual steps or model redesigns. Second, intent-based orchestration can only be achieved by close alignment between service design and service orchestration to simplify operations, improve agility and strengthen security with advanced automation.