ETSI GR ZSM 011 V1.1.1 (2023-02)

Zero-touch network and Service Management (ZSM); Intent-driven autonomous networks; Generic aspects

DGR/ZSM-011_IntentDrv

General Information

• Status: Not Published
• Technical Committee: ZSM - Zero-touch network and Service Management
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 28-Feb-2023
• Completion Date: 08-Feb-2023

Standards Content (Sample)

GROUP REPORT
Zero-touch network and Service Management (ZSM);
Intent-driven autonomous networks;
Generic aspects
Disclaimer
The present document has been produced and approved by the Zero-touch network and Service Management (ZSM) ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR ZSM 011 V1.1.1 (2023-02)

Reference
DGR/ZSM-011_IntentDrv
Keywords
automation, autonomic networking, generic

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2023.
All rights reserved.
ETSI
3 ETSI GR ZSM 011 V1.1.1 (2023-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 The concept of intent-driven management . 8
4.1 Introduction . 8
4.2 Definition of intents. 9
4.2.1 Introduction. 9
4.2.2 Principles of Intent . 10
4.2.3 Ensuring trust in intent-driven autonomy . 10
4.2.4 Additional aspects of Intent . 11
4.3 Examples of use cases considered . 11
4.3.1 Introduction. 11
4.3.2 Automotive use case . 12
4.3.2.1 Description . 12
4.3.2.2 KPIs. 12
4.3.2.3 Intents . 13
4.3.3 Cloud private line services . 14
4.3.3.1 Description . 14
4.3.3.2 Intent parameters . 15
4.3.3.3 Intent Translation . 16
4.3.3.4 CPL service delivery by Intent Management Entities . 16
5 Intent-driven management within the ZSM framework architecture . 16
5.1 The role of Intent Management Entity . 16
5.2 Mapping of ZSM closed loop concepts to Intent Management Entity operations . 18
5.3 Intent interactions between different management domains . 22
5.4 Intent model federation . 23
5.4.1 Introduction. 23
5.4.2 Criteria for selection of intent meta-models. 24
5.4.3 Intent meta-model from TM Forum . 24
5.4.4 Declarative Intent Model . 26
5.4.4.1 Intent Expectation . 26
5.4.4.2 Desired outcomes as Intent Targets . 26
5.4.4.3 Intents and Managed Entities . 27
5.4.4.4 Context and filter information . 27
5.4.4.5 Intent fulfilment status . 27
5.4.4.6 Class definitions . 28
5.5 Intent lifecycle . 29
5.5.1 Introduction. 29
5.5.2 Phases of the intent lifecycle. 29
5.5.3 States machine of intent handling . 31
5.6 Intent-based interface . 32
5.6.1 Introduction. 32
5.6.2 Relationship between intent owner and intent handler . 32
5.6.3 Operations on the intent interface . 33
5.6.3.0 Introduction . 33
5.6.3.1 Mandatory operations. 34
ETSI
4 ETSI GR ZSM 011 V1.1.1 (2023-02)
5.6.3.1.1 Introduction . 34
5.6.3.1.2 Create. 34
5.6.3.1.3 Read . 34
5.6.3.1.4 Update . 34
5.6.3.1.5 Delete. 34
5.6.3.2 Optional operations . 35
5.6.3.2.1 Introduction . 35
5.6.3.2.2 Judge . 35
5.6.3.2.3 Feasibility . 35
5.6.3.2.4 Best . 35
5.6.3.3 Optional operations to ensure trust in Intent-driven autonomy . 36
5.6.3.3.1 Activate . 36
5.6.3.3.2 Deactivate . 36
5.6.3.3.3 Suspend . 36
5.6.3.3.4 Resume . 37
5.6.3.3.5 Logging capabilities . 37
5.6.3.3.6 Notification capabilities . 37
5.6.3.3.7 Testing . 38
5.6.3.3.8 Verification of intent outcome - optional interface capability . 38
5.6.4 Intent Management Entity registry . 39
5.7 Handling management conflicts . 39
5.7.1 Introduction. 39
5.8 Intent translation . 42
5.8.1 Intent translation: background . 42
5.8.2 Intent translation: methods . 42
6 Next steps of standardization activities for ZSM Intent-driven autonomous networks . 43
6.1 Summary of the present document . 43
6.2 Challenges faced on the present document . 43
6.3 Potential future work based on the present document . 43
Annex A: Examples of intents . 45
Annex B: Required Classes of the declarative intent model . 47
B.1 Example of declarative intent model . 47
B.2 Intent <> . 47
B.3 IntentExpectation <> . 48
B.4 IntentTarget << dataType >> . 49
B.5 context << datatype >> . 49
B.6 fulfillmentInfo << dataType >> . 50
Annex C: Testing intent-based autonomous networks and services . 51
Annex D: Alternative Concepts of Intent modelling . 52
D.1 List of challenges . 52
D.2 Service catalog . 53
D.3 Intent model . 53
D.4 Intent-based service model . 54
Annex E: Bibliography . 55
Annex F: Change History . 56
History . 60

ETSI
5 ETSI GR ZSM 011 V1.1.1 (2023-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Zero-touch network and
Service Management (ZSM).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI GR ZSM 011 V1.1.1 (2023-02)
1 Scope
Intent-based management enables simpler, more user-friendly expressions of input information, and higher flexibility in
automation. Intent is a key enabler to increase automation and make management simpler; therefore the present
document investigates the potential use of intents as key enabler for enhancing autonomous network and service
management within ZSM framework. It provides a formal definition of intents and a list of principles of intent-driven
management, leveraging existing standardization work. Some use cases are also included in the present document to
provide examples of management domains where intents are applicable and capabilities that may be needed. Intent-
driven management within the ZSM framework is investigated and the concept of an intent management entity is
introduced, which is responsible for the life cycle management of intents and the exchange of intents between different
management domains. The present document also maps the intent management entity with the concept of closed loops
that is specified in ETSI GS ZSM 009-1 [i.11]. Intent modelling is also investigated, and two different approaches are
proposed. The present document defines intent life cycle phases and a state diagram, together with a set of (mandatory
and optional) interface capabilities that are needed for the life cycle management of intents. Finally, additional aspects
such as conflicts between intents, intent translation, and intent testing are investigated. The present document outlines
potential future work based on the topics explored and the critical areas that were identified in the present document.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are not necessary for the application of the present document, but they assist the
user with regard to a particular subject area.
[i.1] ETSI GR ZSM 005: "Zero-touch network and Service Management (ZSM); Means of
Automation".
[i.2] TM Forum IG1230: "Autonomous Networks Technical Architecture v1.1.0".
[i.3] IETF RFC 9315: "Intent-Based Networking - Concepts and Definitions".
[i.4] ETSI TS 128 312: "LTE; 5G; Management and orchestration; Intent driven management services
for mobile networks (3GPP TS 28.312 Release 17)".
[i.5] TM Forum IG1253: "Intent in Autonomous Networks v1.2.0".
[i.6] TM Forum IG1253A: "Intent Common Model v1.1.0".
[i.7] TM Forum IG1253B: "Intent Extension Models v1.1.0".
[i.8] TM Forum IG1253C: "Intent Life Cycle Management and Interface v1.1.0".
[i.9] TeraFlow Project: "Secured autonomic traffic management for a Tera of SDN Flows".
NOTE: Available at https://www.teraflow-h2020.eu/.
ETSI
7 ETSI GR ZSM 011 V1.1.1 (2023-02)
[i.10] TeraFlow Project - Scenarios.
NOTE: Available at https://www.teraflow-h2020.eu/node/161.
[i.11] ETSI GS ZSM 009-1: "Zero-touch network and Service Management (ZSM); Closed-Loop
Automation; Part 1: Enablers". ®
[i.12] W3C Recommendation 25 February 2014: "RDF 1.1 Concepts and Abstract Syntax".
NOTE: Available at https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/.
[i.13] ETSI GS ZSM 007: "Zero-touch network and Service Management (ZSM); Terminology for
concepts in ZSM".
[i.14] Dave Lenrow: "Intent: Don't Tell Me What to Do! (Tell Me What You Want)".
NOTE: Available at https://www.sdxcentral.com/articles/contributed/network-intent-summit-perspective-david-
lenrow/2015/02/.
[i.15] ETSI GS ZSM 009-2: "Zero-touch network and Service Management (ZSM); Closed-Loop
Automation; Part 2: Solutions for automation of E2E service and network management use cases".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS ZSM 007 [i.13] and the following apply:
autonomous entity: part of a network that is capable of making and actuating decisions within its specified degree of
autonomy and area of influence
NOTE: In the ZSM Framework a Management Domain is an example of an autonomous entity.
intent: formal specification of the expectations, including requirements, goals, and constraints, given to a technical
system (see TM Forum IG1230 [i.2])
intent handler: logical entity that receives intents (i.e. the intent information objects) and handles them in the domain
that is responsible for that intent's fulfilment
NOTE: An intent handler is not allowed to modify and/or remove an intent but can reject to fulfil it. It fulfils the
requirements and goals, based on the resources and solutions it has available once it has accepted the
intent. An intent handler reports back to the intent owner regarding the intent fulfilment.
intent information object: information object that represents a specific set of requirements, goals and constraints
which are structured according to the intent IOC
intent information object class: object class that describes the type, structure and relationships of the information
elements that specify the requirements, goals, and constraints of an intent
intent management entity: autonomous entity in a domain that can play the role of intent owner and/or intent handler
and is capable of making and actuating decisions to fulfil intents
intent negotiation: procedure involving an intent owner and an intent handler where the intent fulfilment terms are
settled prior to the intent being accepted by the intent handler
NOTE 1: Alternatively, an intent negotiation could also result in a rejection of the intent.
NOTE 2: An intent handler is an autonomous entity in a domain for the aspect of intent fulfilment.
intent object instance: unique managed object instance that is instantiated at the intent handler (MnS producer) based
on the information of intent requirements, goals and constraints sent to the intent handler (MnS producer) by the intent
owner (MnS consumer)
ETSI
8 ETSI GR ZSM 011 V1.1.1 (2023-02)
intent owner: logical entity that originates intents (creating intent information objects) and is responsible for managing
its lifecycle. Ideally only an intent owner is allowed to manage the intent lifecycle
opportunity cost: cost of a particular good or service compared to an alternative
NOTE: Opportunity cost is a term used in economics. When consumers or businesses make the decision to
purchase or produce particular goods, they are doing so at the expense of buying or producing something
else. This is referred to as the opportunity cost.
producer utility: total benefit for a producer to supply a good or service
utility: total satisfaction received from consuming a good or service
NOTE: Utility is a term used in economics. Economic theories based on rational choice usually assume that
consumers will strive to maximize their utility. The utility is subjective. It depends upon the mental
assessment of the consumer and is determined by several factors which influence the consumer's
judgment.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [i.13] and the following apply:
CFS Customer Facing Service
IOC Information Object Class
MnS Management Service
OPEX OPerational EXpenditure
4 The concept of intent-driven management
4.1 Introduction
In an autonomous networks management framework that is purely intent-driven, all goals and expected behaviour are
defined with intents. The management framework will only perform operations that relate to the fulfilment and
assurance of an intent, which means that all goals - including those that may have been considered "common sense" in
human-operated systems - are to be expressed as intents.
An intent in an autonomous management framework is expressed declaratively - that is, as a goal that describes the
properties of a satisfactory outcome rather than prescribing a specific solution. This gives the framework the flexibility
to explore various solution options and find the optimal one. It also allows the framework to optimize by choosing its
own actions and decisions, e.g. exactly which service to instantiate, or configuration to make, that will ultimately
maximize utility.
Unlike traditional software systems, where requirements are analysed offline to detect and resolve conflicts prior to
implementation, intents are added to an autonomous framework during runtime. Adaptation to changed intent as well as
conflict detection and resolution are therefore essential capabilities of an autonomous framework.
Expectations originate from contracts or business strategy and remain constant when the underlying framework is
replaced or modified. Consequently, when setting up the intents, it is important that they are formulated in an
infrastructure-agnostic form, so that they can be transferred across network and infrastructure implementations,
i.e. vendor, technology, and operator agnostic.
As described in clause 5.2, intents can be used for interactions between management service consumer and management
service producer in intent-driven management. From the management service consumer's perspective, an intent that is
used in such an interaction is agnostic to the management service producer's infrastructure and the resources that are
ultimately used in the intent fulfilment.
ETSI
9 ETSI GR ZSM 011 V1.1.1 (2023-02)
In short, the intent establishes a universal mechanism for defining expectations for different layers of network
operations. It expresses goals, utility, requirements, and constraints. It defines expectations on service delivery as well
as the behaviour of the autonomous management framework and the underlying managed network.
An original intent will be transformed and decomposed when transferred between different domains. At each stage it
can be decomposed into several new declarative intents and also, partly or completely, transformed into various actions.
In addition, the decomposition and transformation will happen not only when the intent will be transferred between
different domains but also between the different levels and layers of operational management to define for example
needs, requirements, constraints, and targets.
Although purely intent-driven management frameworks are foreseen, it is more likely that intent-driven management
will complement the traditional imperative (not intent-driven) management solutions.
4.2 Definition of intents
4.2.1 Introduction
ETSI GR ZSM 005 [i.1] introduced intent-based approach as a means of automation. Clause 4.3.0 of ETSI
GR ZSM 005 [i.1] summarizes how the notion of intents emerged in the telecommunications industry and how some of
the main academic and industry work have adopted this concept in the area of network and service management and
automation. Also, the later TM Forum's IG 1230 [i.2] presents the concept of intent and the evolution of the concept
over time in clause 5.7, showing mainly how intent is defined and used in different standardization organizations.
The notion of intent as a concept and its role in the telecommunication industry has evolved over time from being
policy-centric towards being a means for declaration and communication of goals, requirements, and constraints to parts
of a technical system, such as a management system. The setting of intent is often linked to humans' expectations and
desires, but it can also be used to express goals to be exchanged between machines or within an autonomous system.
IRTF NMRG [i.3] has defined intent as "A set of operational goals (that a network should meet) and outcomes (that a
network is supposed to deliver) defined in a declarative manner without specifying how to achieve or implement them".
In ETSI TS 128 312 [i.4], intent is defined as "a desire to reach a certain state for a specific service or network
management workflow". Besides that, "an intent specifies the expectations including requirements, goals and
constraints given to a 3GPP system, without specifying how to achieve them".
The same general definition has been adopted in TM Forum's IG 1230 [i.2] as a baseline. TM Forum's work emphasize
that from the user's perspective, an intent expresses the expectation the user has with respect to the behaviour of the
system. Intents should be used to convey the goals needed to ultimately fulfil humans' expectations. In this sense,
according to TM Forum's IG 1230 [i.2], an intent can also be defined as "the formal specification of all expectations
including requirements, goals, and constraints given to a technical system".
Based on the definitions presented above, there is a common understanding in the industry that an intent is a knowledge
object that is used to describe the expectations to a system in a way that allows autonomous operations to be performed
by the system receiving such intents. The ZSM framework should use the same definition when applying an
intent-driven approach in the zero-touch networks and services management.
Therefore, the adoption of intent definition as in TM Forum IG1230 [i.2] is proposed:
"Intent is the formal specification of the expectations, including requirements, goals, and constraints, given to
a technical system".
ETSI
10 ETSI GR ZSM 011 V1.1.1 (2023-02)
4.2.2 Principles of Intent
Properties and Implications of Intent are well defined in [i.2] and some others of the previously mentioned documents.
As conclusion the following principles of intent are identified for ZSM:
1. Intent establishes machine-processable knowledge
Intents are formal specification created for a technical system, which means that they establish machine-readable
knowledge to be considered by the autonomous management. In an autonomous network, where business goals and
requirements can change dynamically and the operations need to quickly adapt without human intervention, the
business objectives of the operators as well as the expectations of the customers and users need to be conveyed in some
means of knowledge, and this is the main purpose of intents.
2. Intent is declarative, so it leaves any implementation detail internal to the solution provider
Intents define goals, requirements, and constraints, which should be provided in a declarative form. The definition
excludes all imperative implementations and solutions aspects. Therefore, intents leave out the implementation of the
details of how the network and service is operated to the internal management capabilities of the autonomous network.
In this respect, artifacts such as workflows, policies, decision rules, etc. are still needed to realize intent-driven
autonomous networks. Such tools will be used internally to the autonomous systems according to network operator's
strategies.
3. Intent is focused on expectations of the results for the consumer
Intents focus on a specification of expectations, reflecting the idea that intents are expressed from a consumer's
perspective. Intents can originate directly from humans, e.g. customers or operators using intents to communicate to an
autonomous system their expectations. It is the job of the autonomous system to fulfil those expectations, while the
intent originator may play a supervisory role. Intents can also be generated internally within the autonomous system and
can be used between the autonomous entities to influence the details of the specific wanted behaviour and contribute to
the overall fulfilment of human expectations (expressed by intents initially created).
4. Intent is formally expressed so it is machine-processable and readable for human
Finally, one of the most important aspects of intents is that they are formally expressed so that they can be interpreted
by machines as well as by humans. The sender and receiver of intents need to agree in their interpretation; therefore,
there should be no ambiguity in their meaning. The formal expression and unambiguous meaning of intents can be
achieved by well-defined information models that completely define the semantics and vocabulary that is required for
the operation of each autonomous system that uses intents. The intent models that can be defined in the ETSI ZSM
scope are presented in clause 5.4.
5. Intent supports complete automation of intent owner-intent handler interactions as well as of intent-defined
service delivery
Intents are abstract, which allows them to be formulated by intent owners without requiring intent owners to learn
details of the intent handler's managed entities. This, combined with e.g. suitable intent owner-intent handler interface
operations and closed loop-based instantiation and maintenance of services by intent handlers, supports complete
automation of intent owner-intent handler interactions and of operations through to service delivery and maintenance.
4.2.3 Ensuring trust in intent-driven autonomy
As expressed with principle 2 above, all implementation details and insight to the intent processing are left to the
particular solution of an autonomous intent handling.
To address the expectations of a guaranteed service quality and most secured processes service providers require a high
level of control, which raises expectation to get more insight into the intent handling process itself. Therefore,
additional capabilities can be optionally enabled.
1. Intent handlers offer optional insight to the intent handling process
Intent handlers may expose the sequence of generated actions or operations, when requested by an authorized user.
ETSI
11 ETSI GR ZSM 011 V1.1.1 (2023-02)
2. Intent handlers offer optional explicit intent verification
An Intent can e.g. be explicitly tested at any time if intent expectations are still met, when requested by an authorized
user.
4.2.4 Additional aspects of Intent
The introduction in clause 4.1 describes intent as a key enabler in a management framework for autonomous networks.
When coming to the more concrete definition how an intent can be expressed (i.e. in an intent information object), also
looking at the process of intent-handling within a ZSM framework, different business goals may be considered.
Table 4.2.4-1
# Goal Means Description
a) Autonomy Service Abstraction Avoiding service knowledge for the consumer, express the need, not the
concrete service, let the producer decide autonomously about concrete
service and how to build it
b) Human Language Translator Allows to formulate an intent with human language, to be translated into
Language machine readable intent information object
c) Flexible Parameters to Allows to negotiate for example quality of a service
Offerings Negotiate
d) Provide Best Intent Request Find the best service producer/intent handler for the purpose
Producer Broker
e) Time to market May vary Enable runbook generation at runtime, avoid coding of runbook
workflows
Service abstraction to enable autonomy as in a) is the most relevant aspect of intent and the focus of the present
document. An intent handler can decide autonomously on the concrete service instantiated, how this is assembled and
how its quality is assured. In the simplest case, the structure of an intent information object, may be similar to a CFS
(Customer Facing Service) specification, catalog based, just at an abstracted level. The handler decides on the concrete
service and resource composition and its quality assurance.
The full value of an intent comes with goals b), c) or d) it may support human natural language, negotiation e.g. about
the quality of service, or find the best service producer for an intent. All these goals are supportable, given the intent
information object has the right structure to express the expectation of the intent consumer to the intent producer.
However, looking at the growing complexity of networks, the fast-growing number of possible service offerings, the
effort to implement the processing of new intent offerings has to be seen as well as shown with goal e). Therefore,
simplification to implement intent processing is another goal, to lower cost of automation and reach faster time to
market. The structure of an intent information enables simplification for the consumer, but not necessarily for the
producer. Hence the present document touches also implications to the intent management entity implementation.
4.3 Examples of use cases considered
4.3.1 Introduction
This clause introduces use cases where intents play an important role in the autonomous service and resource
management. The list of use cases is non-exhaustive and is meant to illustrate the use of intents in different scenarios
and to provide examples of management domains where intents are applicable and capabilities that may be necessary
for the realization of intent-driven management.
ETSI
12 ETSI GR ZSM 011 V1.1.1 (2023-02)
4.3.2 Automotive use case
4.3.2.1 Description
In the automotive use case, mobile operators not only provide the connectivity to the connected cars, but also deploy
MEC and cloud infrastructure along the Transport Network (TN) to host the CCAM (Cooperative, Connected, and
Automated Mobility) applications. The huge scale and diversity of CCAM services impose 3 main requirements for TN
services: low-latency, high-capacity, and massive flow management. For example, in Beyond-5G (B5G) networks, the
objective is to collect telematics and driver behaviour data and analyse it to ensure the vehicle's performance, efficiency,
and safety. It is estimated that each car will produce and send 25GB of data to the cloud every hour. MEC is deployed
to distribute the functionalities between the edge and the core clouds to reduce the number of flows and the capacity
required, thereby lowering the E2E latenc
...