By WG SA5 Authors: Ruiyue Xu (Huawei), Mark Scott (Ericsson)
First published June 2025, in Highlights Issue 10
Compared to earlier networks - 5G and 5G Advanced systems bring more operational complexities, largely due to the growing number of devices online and their increased diversity. Network autonomy is one of the important topics for 5G systems, for reduced OPEX through efficiency and an improved service experience - for various vertical industries – through a variety of intelligence and automation mechanisms.
As networks continue to evolve the level of complexity can explode, as scenarios such as design & planning, deployment, maintenance and optimization are considered. The need for abstraction of the operational requirements, such as is supported by intents, becomes more apparent. 3GPP SA5 started the intent driven management work for mobile networks back in June 2018. The effort is continually evolving as new capabilities and scenarios come to light, to support highly autonomous networks.
Intent concept
An intent is a set of expectations including requirements, goals and constraints given to a 3GPP system, without specifying how to achieve them. Intents allow customers to request networks and services without detailed knowledge of how they will be provided. Inherently, this assumes that the system can learn the behaviour of networks and services and use intelligence and automation mechanisms to fulfil the requests expressed via intents.
This not only relieves the consumer of the burden of knowing implementation details but also provides flexibility allowing the system to explore alternative options, to find optimal solutions.
Intent based on user types
To support different roles related to 5G networks and network slicing management defined in 3GPP, different intents could be considered, being used for supporting different interactions, specifically:
- Intent-CSC: from Communication Service Customer (CSC) to the Communication Service Provider (CSP) to express properties of a communication service, e.g. ‘Enable a V2X communication service for a group of vehicles in certain time with low latency’.
- Intent-CSP: from CSP to a Network Operator (NOP) to express properties of the CSP’s desired network, e.g., ‘a network slice supporting V2X communications.
- Intent-NOP: from NOP to a Network Equipment Provider (NEP) to express characteristics of a RAN and/or 5GC network, e.g., specifying ‘coverage requirements and UE throughput requirement in certain area'.
Figure 1
Intent management functionalities for different phases
The intent management functionalities for different phases include:
Intent Investigation
In this phase, the MnS Consumer finds out what intent content (a list of expectations) is feasible before expressing the intent expectations to be fulfilled by the Intent Handling Function (i.e. MnS Producer). This has two aspects:
- Intent handling capability. The MnS Consumer finds the Intent Handling Function which has the necessary domain responsibilities and supports their required intent expectations.
- Intent pre-evaluation. The MnS Consumer finds out whether their wanted intent expectations and wanted values are feasible. The MnS Consumer can use negotiation procedures to help determine suitable intent information for the Intent Handling Function. The network (including NFs) will not be changed during the intent pre-evaluation phase. Supported procedures include a Feasibility Check to allow the MnS Consumer to confirm that the proposed intent is supported by the Intent Handling Function, and exploration procedures such as requesting the best values.
Intent Generation and Activation
In this phase, the MnS Consumer generates the intent content (a list of expectations) and sends it to the Intent Handling Function for fulfilment.
Intent Fulfilment
The Intent Handling Function fulfils the given intent within its domains of responsibility. Intent Reports generated by the Intent Handling Function are used by the MnS Consumer to observe the fulfilment. The MnS Consumer may identify a need to modify the intent content based on the intent report content. Intent negotiation procedures can be used by the MnS Consumer to improve the fulfilment by modifying the intent to better align with the Intent Handling Function's ability to fulfil the intent.
Intent driven management service (IDMS)
Intent support in 3GPP is provided via an Intent Driven Management Service (IDMS) defined as an MnS per 3GPP Service Based Management Architecture (SBMA). The Intent Handling Function provides the MnS Producer (a logical function with intent handling capabilities that provides the intent driven management service) which allows its MnS Consumer to express intents for managing the network and services.
The intent driven MnS solution uses the “model driven approach” in SBMA, which decouples the operations from the intent model. The intent driven MnS solution specified by 3GPP TS 28.312 is a flexible interface and allows for extensions to support new scenarios/services.
In TS 28.312, the following are defined:
A unified set of management operations, including:
- Intent lifecycle management, including create an intent, modify an intent, delete an intent, query an intent, activate an intent and deactivate an intent.
- Intent report management, including query an intent report, subscribe to an intent report, unsubscribe from an intent report, notify an intent report.
- Intent handling capability query, including query intent handling capability.
- Intent negotiation management, including intent feasibility check, intent exploration and intent fulfilment negotiation procedures.
A generic intent information and data model defined in a common intent model framework to support intent management. The generic intent information model includes:
- Intent HandlingFunction model, represents the intent handling capabilities (i.e., supported expectation object information and expectation target) supported by a specific Intent Handling Function.
- Intent model, contains one or multiple IntentExpectation(s) which includes MnS Consumer's requirements, goals and contexts.
- IntentReport model, represents intent report information containing one or any combination of intentFulfilmentReport, intentConflictReports, intentFeasibilityCheckReport, intentExplorationReport and intentFulfilmentNegotiationReport.
Figure 2
Scenario specific intent Expectation instances. The following scenario specific intent instances are defined by utilizing the constructs of the generic IntentExpectation to support some typical intent driven scenarios:
- RadioNetworkExpectation, which can be used to represent MnS Consumer's expectations for radio network delivering and performance assurance.
- Radio Service Expectation, which can be used to represent MnS Consumer's expectations for radio service delivering and assurance in the specified area.
- 5GC Network Expectation, which can be used to represent MnS Consumer's expectations for 5GC network delivering.
- End-to-end Network Resource Optimization Expectation, which can be used to represent MnS Consumer's expectations for the resource optimization of network resources across multiple network domains.
- Edge Service Support Expectation, which can be used to represent MnS Consumer's expectations for edge service deployment.
- Network Maintenance Expectation, which can be used to represent MnS consumer’s expectation for maintaining a network.
Guidelines for using scenario specific intent expectation for intent driven scenarios. The following table describes guidelines for using the 3GPP standardized scenario specific intent expectations defined in TS 28.312 to satisfy the intent driven scenarios defined in TS 28.312.
3GPP standardized scenario specific intent expectations
The intent driven MnS solution is a flexible interface, which not only provides support for the scenario specific intents defined in TS 28.312, but can also support scenarios which are not standardized. TS 28.312 contains guidelines for using the intent Generic Information Model to support new scenarios using vendor defined extensions to the generic ExpectationObject(s) and vendor defined ExpectationTarget(s):
- Standardized Intent Expectation with vendor specific combination of standardized ExpectationObject(s) and ExpectationTarget(s).
- Standardized Intent Expectation with standardized ExpectationObject(s) and ExpectationTarget(s) and additional vendor defined ExpectationObject(s) and/or ExpectationTarget(s).
- Vendor defined Intent Expectation by utilizing generic IntentExpectation. The Vendor defined Intent Expectation includes vendor extension ExpectationObject(s) and/or ExpectationTarget(s).
Way Forward
Intent driven management is a key enabler in increasing the autonomy and efficiency of mobile networks, not only for the networks themselves but for those interacting with them. As networks with automation & intelligence become increasingly self-sufficient and able to manage their own resources in increasingly efficient ways, the ways in which we interact with networks must change. Network operators, and their customers, must increasingly shift their focus to ‘what’ they wish to achieve from their networks and services. The 3GPP defined Intent Driven Management Service is aligned with, and can be integrated with, similar mechanisms being defined across the industry to provide a comprehensive and interoperable solution. 3GPP SA5 will continuously develop standards for intent driven management solutions for 5G Advanced networks and future networks and stands ready for new requirements for intent driven management from the industry.
Specification References:
Common specifications for 5G management services are also used for the intent driven management, including the SBMA and corresponding generic management services.
- TS 28.533: " Management and orchestration; Architecture framework".
- TS 28.532: " Management and orchestration; Generic management services ".
Specific intent driven management specifications for release 17, release 18 and release 19 are the following:
- TS 28.312: "Management and orchestration; Intent driven management services for mobile networks".(Current latest versions: V 19.1.0)