ETSI GS ZSM 009-1 V1.1.1 (2021-06)

Zero-touch network and Service Management (ZSM); Closed-Loop Automation; Part 1: Enablers

DGS/ZSM-009-1_Cla_enab

General Information

• Status: Not Published
• Technical Committee: ZSM - Zero-touch network and Service Management
• Current Stage: 12 - Completion
• Due Date: 23-Jun-2021
• Completion Date: 15-Jun-2021

Standards Content (Sample)

GROUP SPECIFICATION
Zero-touch network and Service Management (ZSM);
Closed-Loop Automation;
Part 1: Enablers
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 GS ZSM 009-1 V1.1.1 (2021-06)

Reference
DGS/ZSM-009-1_Cla_enab
Keywords
automation, management, network, service

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
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
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
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 2021.
All rights reserved.
ETSI
3 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
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 . 7
3.3 Abbreviations . 7
4 Description of ZSM 009 multi-part deliverable . 8
5 Requirements for Closed-Loop Automation . 8
5.1 Introduction . 8
5.2 General requirements . 8
6 Introduction to Closed-Loop Automation . 10
7 Closed loops within the ZSM framework . 10
7.1 Introduction . 10
7.2 Functional view . 11
7.2.1 Introduction. 11
7.2.2 Closed loops data and control flow . 13
7.2.2.1 Introduction . 13
7.2.2.2 Primary flow . 13
7.2.2.3 Knowledge-enabled flow . 14
7.2.2.4 Customization flow . 15
7.3 Deployment view . 15
7.4 Closed loop types . 17
8 Closed-Loop Automation enablers . 18
8.1 Closed Loop Governance . 18
8.1.1 Introduction. 18
8.1.2 Options for governing a Closed Loop . 18
8.1.3 Lifecycle management of Closed Loops . 19
8.1.3.1 Closed loops lifecycle phases and activities . 19
8.1.3.2 Preparation phase . 20
8.1.3.3 Commissioning phase . 20
8.1.3.4 Operation phase . 20
8.1.3.5 Decommissioning phase . 20
8.1.4 Closed loop models . 21
8.1.4.1 Introduction . 21
8.1.4.2 Closed loop class . 21
8.1.4.3 Closed loop goal class . 23
8.1.4.4 Managed entity class . 24
8.1.4.5 Closed loop component class . 24
8.1.5 Interactions between Closed Loops and external entities . 25
8.1.5.1 Introduction . 25
8.1.5.2 Interactions based on policies . 25
8.1.5.3 Interactions based on intents . 25
8.2 Closed Loop Coordination . 26
8.2.1 Introduction. 26
8.2.2 Relationships between different Closed Loops . 27
8.2.3 Coordination between hierarchical Closed Loops . 28
8.2.4 Coordination between peer Closed Loops . 28
ETSI
4 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
8.2.5 Closed Loop Coordination services . 28
8.2.5.1 Introduction . 28
8.2.5.2 Interactions identification . 29
8.2.5.3 Goal coordination . 30
8.2.5.4 Pre-execution coordination . 30
8.2.5.4.1 Introduction . 30
8.2.5.4.2 Action plans conflict detection . 30
8.2.5.4.3 Action plans selection . 30
8.2.5.5 Post-execution coordination . 31
8.2.5.5.1 Introduction . 31
8.2.5.5.2 Action enabling and disabling . 31
8.2.5.5.3 Concurrency coordination . 31
8.2.5.5.4 Impact assessment . 31
9 Specification of management services relevant to Closed Loops . 32
9.1 New management services . 32
9.2 Management services for Closed Loop Governance . 32
9.2.1 Introduction. 32
9.2.2 Closed Loop Governance service . 32
9.2.3 Closed loop information reporting service . 33
9.2.4 Closed loop execution management service . 33
9.2.5 Closed loop usage statistics management service . 34
9.3 Management services for Closed Loop Coordination . 34
9.3.1 Introduction. 34
9.3.2 Pre-execution coordination service . 34
9.3.3 Post-execution coordination service . 35
Annex A (informative): Possible implementation of pause points . 36
Annex B (informative): Change History . 37
History . 40

ETSI
5 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
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 Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Zero-touch network and
Service Management (ZSM).
The present document is part 1 of a multi-part deliverable covering Closed-Loop Automation (CLA) based on the ZSM
architectural framework, as identified below:
Part 1: "Enablers";
Part 2: "Solutions for automation of E2E service and network management use cases";
Part 3: "Advanced topics".
Full details of the entire series can be found in clause 4.
Modal verbs terminology
In the present document "shall", "shall not", "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 GS ZSM 009-1 V1.1.1 (2021-06)
1 Scope
The present document describes enablers for Closed-Loop Automation (CLA) based on the ZSM architectural
framework. The present document initially specifies Closed Loop-specific requirements and introduces Closed Loops
within the ZSM framework, from both functional and deployment perspectives. The specifications include enablers for
Closed Loop Governance (CLG), covering the definitions of Closed Loop lifecycle management as well as Closed Loop
models. Such enablers allow automatic deployment and configuration of Closed Loops involving both the end-to-end
service management domain and the individual management domains. Then, the present document specifies enablers
for Closed Loops coordination within the ZSM framework, including means for delegation and escalation between
Closed Loops as well as other coordination means. Finally, the deliverable specifies stage-2 generic enablers for
Closed-Loop Automation (CLA) and includes new management services in addition to those identified in ETSI
GS ZSM 002 [2]. Closed loops running entirely within the managed entities are out-of-scope.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ETSI GS ZSM 001: "Zero-touch network and Service Management (ZSM); Requirements based
on documented scenarios".
[2] ETSI GS ZSM 002: "Zero-touch network and Service Management (ZSM); Reference
Architecture".
[3] ETSI GS ZSM 007: "Zero-touch network and Service Management (ZSM); Terminology for
concepts in ZSM".
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 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".
[i.2] ETSI GR ZSM 009-3: "Zero-touch network and Service Management (ZSM); Closed-loop
automation; Part 3: Advanced topics".
ETSI
7 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
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 [3] and the following apply:
delegation: action taken by a ZSM entity to assign responsibility for one or more goals to one or more other ZSM
entities within stated limits
NOTE 1: Delegation defines the operation autonomy the receiving ZSM entity may use to achieve the assigned
goal(s) and defines conditions for escalation (i.e. to address situations leading to breach in operation
autonomy).
NOTE 2: Delegation is often combined with the concept of escalation in the context of operation autonomy.
Operation autonomy is a central concept in Closed-Loop Automation (see clause 7 of ETSI
GS ZSM 002 [2]).
NOTE 3: Delegation can define the escalation entity or entities.
NOTE 4: Delegation relies on acknowledgment by the receiving entity, and may contain a phase of negotiation
between the entity that originates the delegation and the entity/entities that receive the delegation (e.g. if
the receiving entity can achieve, entirely, partly, or not the delegated goal).
escalation: action taken by a ZSM entity to inform one or more ZSM entities about a breach in its operation autonomy
NOTE 1: A ZSM entity escalates an issue that prevents it from achieving its goal properly, and that is not solvable
with means under its control. An escalation differs from other types of issue or problem reporting in the
sense that an escalation signals a breach in operation autonomy.
NOTE 2: Escalation is often combined with the concept of delegation in the context of operation autonomy.
Operation autonomy is a central concept in Closed-Loop Automation (see clause 7 of ETSI
GS ZSM 002 [2]).
NOTE 3: Escalation can target explicitly an entity or list of entities. Escalation can be with or without
acknowledgment by the receiving entity or entities.
NOTE 4: Escalation can contain contextual information about the problematic situation faced, attempt(s) to solve it,
and other contextual information that could be useful to the recipient of the escalation, or any other
information defined by the corresponding policies.
managed entity: managed resource, a managed service or a managed Closed Loop
NOTE: This term differs from the definition in ETSI GS ZSM 007 [3] because a Closed Loop may also be
managed, similarly to managed resources ( e.g. VNFs, PNFs) and managed services ( e.g. cloud services,
RFSs, CFSs).
3.2 Symbols
For the purposes of the present document, the symbols given in ETSI GS ZSM 007 [3] apply.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [3] and the following apply:
AI Artificial Intelligence
CL Closed Loop
CLA Closed-Loop Automation
CLC Closed Loop Coordination
CLG Closed Loop Governance
E2E End-to-End
ETSI
8 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
E2ES End-to-End Service
KPI Key Performance Indicator
LCM Lifecycle Management
M2O-CL Made-to-Order Closed Loop
MD Management Domain
ML Machine Learning
MnF Management Function
MnS Management Service
RDBMS Relational DataBase Management System
RM-CL Ready-Made Closed Loop
ZSM Zero-touch network and Service Management
4 Description of ZSM 009 multi-part deliverable
The present document specifies part 1 of a multi-part deliverable that focuses on Closed-Loop Automation (CLA) based
on the ZSM framework architecture.
The present document specifies the enablers for Closed-Loop Automation (CLA) that can be used in different use cases.
It includes aspects of Closed Loop Governance (CLG) in clause 8.1 and Closed Loop Coordination (CLC) in clause 8.2.
The present document also extends the ZSM framework architecture specified in ETSI GS ZSM 002 [2] with new
management services and capabilities needed for the specified Closed Loop enablers (clause 9).
ETSI GS ZSM 009-2 [i.1] specifies solutions for end-to-end service and network automation use cases, based primarily
on the enablers and architectural elements specified in ETSI GS ZSM 009-1 (the present document).
ETSI GR ZSM 009-3 [i.2] investigates advanced topics related to Closed-Loop Automation (CLA) such as learning and
cognitive capabilities. It documents problem statements and technical challenges, derives potential requirements and
provides recommendations for the evolution of Closed-Loop Automation (CLA) standardization activities.
5 Requirements for Closed-Loop Automation
5.1 Introduction
This clause defines the requirements relevant to Closed-Loop Automation (CLA) within the ZSM framework
architecture. The requirements are derived from ETSI GS ZSM 001 [1] and ETSI GS ZSM 002 [2], as well as new
requirements introduced specifically for Closed-Loop Automation (CLA).
The requirements are considered for the specification of the Closed-Loop Automation (CLA) enablers in clause 8.
5.2 General requirements
[CL-general-1] Closed loops within the ZSM framework shall have access to the data necessary to allow its proper
operation.
NOTE 1: Examples of data include system log data, historical data, policy data, other external data input, etc.
[CL-general-2] The ZSM framework shall allow establishing different types of relationships between Closed
Loops.
NOTE 2: Examples of relationships are peer Closed Loops, hierarchical or nested Closed Loops.
[CL-general-3] Closed loops stages should be able to expose their outcomes to the authorized entities.
NOTE 3: Examples of authorized entities are other Closed Loops and ZSM framework consumers.
[CL-general-4] Authorized Closed Loops within the ZSM framework shall be able to interact with other Closed
Loops within the ZSM framework in different management domains.
ETSI
9 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
[CL-general-5] Closed loops within the ZSM framework shall be able to be defined across multiple management
domains.
NOTE 4: The management services for different Closed Loop stages may be provided by different management
domains, e.g. data can be collected from one management domain and execution of actions may be
performed in another management domain, etc.
[CL-general-6] Closed loops within the ZSM framework working in a management domain shall be able to
request other Closed Loops in the E2E service management domain to take necessary action(s) in
different management domains.
[CL-general-7] Closed loops stages should support influences from authorized entities outside the Closed Loop,
but within the ZSM framework.
[CL-general-8] The actions taken by Closed Loops shall be logged.
[CL-general-9] The period for which Closed Loops logs are retained should be configurable.
[CL-general-10] The ZSM framework should support capabilities to present external instructions to the Closed
Loops in a declarative form.
[CL-general-11] Closed loops within the ZSM framework should understand external instructions received in a
declarative form.
[CL-general-12] Closed loops within the ZSM framework should support the capability to provide the state of each
stage for its proper operation.
[CL-general-13] Closed loops within the ZSM framework should support the capability to detect abnormal states of
any stage and notify the authorized entities.
[CL-general-14] Decisions based on AI/ML made by a Closed Loop within the ZSM framework should be
monitored to support administrative audit trails.
[CL-general-15] Closed loops within the ZSM framework should support data collection from multiple available
and applicable data sources, including their several data schemas.
[CL-general-16] The ZSM framework should support capabilities to avoid conflicts between Closed Loops.
[CL-general-17] The ZSM framework should support capabilities to minimize the negative effects of conflicts
between Closed Loops.
[CL-general-18] Closed loops within the ZSM framework should support capabilities to enable continuous data
integration from several available and applicable data sources.
[CL-general-19] The ZSM framework should support capabilities to enable continuous data integration from
management data sources in a Closed Loop within the ZSM framework.
[CL-general-20] The ZSM framework should support capabilities to enable real-time data integration from
management data sources in a Closed Loop within the ZSM framework.
[CL-general-21] The ZSM framework shall support a capability to uniquely identify a Closed Loop instance.
[CL-general-22] The ZSM framework should support capabilities to control the execution of a Closed Loop during
its run time.
NOTE 5: An example of control capabilities could be the use of pause points.
[CL-general-23] Closed loops within the ZSM framework should support capabilities to handle control requests
from authorized external entities.
[CL-general-24] Closed loops within the ZSM framework should support capabilities to dynamically adapt the
exposure of control capabilities to external entities.
NOTE 6: Closed loop control capabilities could be defined by the Closed Loop model and may vary depending on
the phases of the defined Closed Loop life cycle.
ETSI
10 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
6 Introduction to Closed-Loop Automation
A Closed Loop (CL) is a type of control mechanism that monitors and regulates a set of managed entities with the
objective of achieving a specific goal. CLs can be logically decomposed into a variable number of stages, each of them
responsible for performing part(s) of the functionality of the Closed Loop. Well-known Closed Loop types are OODA
loop, composed of 4 stages (Observe, Orient, Decide, Act) and MAPE-K, also composed of 4 stages (Monitor, Analyse,
Plan, Execute) plus Knowledge.
Closed-Loop Automation (CLA) is the combination of CL stages that create automated processes that based on
feedback from monitoring data can manage the network reducing or removing human involvement from the operation
of a system. CLA in management systems can be realized with the combination and chaining of management services
(data, analytics, policy, orchestration, etc.), and it creates autonomous systems that are able to constantly monitor and
assess the network and take corrective actions when the goals (e.g. business intents, SLSs, etc.) are not fulfilled.
Although the purpose of CLA is to reduce the direct human intervention, it is important that any autonomous system
still allows interactions with human operators. Such interactions can be used for the specification and modification of
the goals of the CL, as well as for monitoring the performance of the autonomous system and eventual
approval/rejection of actions taken by it.
The focus of the present document is to enable the creation and execution of CLs as well as on the integration and
interoperability between CLs within the scope of ZSM framework, including CLs running at different domains. The
interactions between CLs and external entities such as human operators are also considered, as this is important for the
gradual increase of autonomy of Closed Loops.
NOTE: There are other CLs running outside of the scope of the ZSM framework (e.g. at the network resources)
that can influence the CLA within the ZSM framework.
7 Closed loops within the ZSM framework
7.1 Introduction
ETSI GS ZSM 002 [2] specifies the overall architecture of the ZSM framework. CLs may exist in any of the
management domains of the ZSM architecture as shown in Figure 7.1-1.
The present document specifies the management services relating to how CLs in the (E2E) MDs can be integrated into
the ZSM framework. Two main groups of management capabilities are identified: capabilities relating to:
i) Closed Loop Governance (CLG); and
ii) Closed Loop Coordination (CLC).
Management capabilities belonging to these groups are specified in clause 9. Furthermore, the information models
relating to a CL are presented in clause 8.1.4.
ETSI
11 ETSI GS ZSM 009-1 V1.1.1 (2021-06)

Figure 7.1-1: CL related management capabilities introduced in the present document
In the ZSM framework, CLs are realized by the interworking of management services defined in ETSI GS ZSM 002 [2]
(and other future specifications in ISG ZSM) that are relevant to achieving the functionalities of the different stages of
the CL. The stages when connected in a CL can be used to autonomously collect data, make decisions and execute
actions upon one or more managed entities.
The set of stages that compose a CL includes at least one stage, called "Monitoring", responsible for collection of data
from one or several sources (e.g. one or more managed entities, or external data sources) and one stage, called
"Execution", responsible for executing actions upon one or more managed entities. The managed entities over which the
execution is made are not necessarily the same as those where the data came from. Besides the two elementary stages,
i.e. monitoring and execution, there may be other stages responsible for the analysis of operational and historical data
and decisions based on the outcomes of the analysis. The number and functionality of intermediate stages between the
"monitoring" of data and the "execution" can vary depending on the implementation and the deployment choices. This
specification does not mandate a fixed number of stages that compose a CL within the ZSM framework, but it
recommends at least three: one for monitoring, one for execution and one for analysis and decision making. Analysis
and decision making can further be composed of several stages.
The CLs running within the ZSM framework can be represented by a functional view (clause 7.2) or by a deployment
view (clause 7.3). The functional view expresses the functions that are conveyed in each stage and the flow of data and
control between different stages of the Closed Loop and between the Closed Loop and external entities (clause 7.2.2).
The deployment view expresses the connections between ZSM architectural components that are necessary for the
realization of Closed Loops within the ZSM framework.
7.2 Functional view
7.2.1 Introduction
This specification takes as a baseline for the functional view the CL from Annex C of ETSI GS ZSM 002 [2] that is
composed by 4 stages plus knowledge as its components, as shown in Figure 7.2.1-1. This collection and ordering of the
components within a CL is referred to as the chain that forms the Closed Loop.
ETSI
12 ETSI GS ZSM 009-1 V1.1.1 (2021-06)

Figure 7.2.1-1: Functional view of a Closed Loop and its stages within the ZSM framework
In Figure 7.2.1-1, the "Managed entities" is not a stage in the CL, but rather the target of automation. A managed entity
can be a managed service, a managed resource or another Closed Loop.
The "Monitoring" stage is responsible for collecting and pre-processing data from managed entities or from external
sources.
NOTE 1: Data ingestion is a part of this stage. It is a process where data is transferred from one or more sources to
a destination where it can be stored and further analysed. The data might be in different formats and come
from various sources, including RDBMS, other types of databases, or from data streams. Since there is
data of different origin, there is need for each source to be transformed in a way that allows it to be
analysed in conjunction with data from other sources.
The "Analysis" stage is responsible for deriving insights from available data from the monitoring stage as well as
historical data.
NOTE 2: An insight is produced based on data and the context of the finding. An example of insight may be the
conclusion that congestion has taken place in a set of resources, and the context could be the time and
date, the service affected, users involved and set of resources that make up the service. Insights can
answer questions such as "What happened?" as well as "Why did it happen?". The insight derivation is a
continuous process that can be enhanced by new data. Analysis should be able to continuously improve
its results and, consequently, provide better decision options to the decision stage.
The "Decision" stage is responsible for deriving workflows from insights provided by the analysis stage.
NOTE 3: The decision stage governs the behaviour of the system as it decides which actions should be taken in
face of issues detected in the analysis stage. The actions can be either reactive, proactive or predictive.
The decision stage should decide which actions are required, but not necessarily how they should be taken
in the managed entities. The translation from actions to commands is a responsibility of the execution
stage.
In a CL the analysis and decision stages can optionally be combined into one single stage, kept separate as two stages,
or even further split into multiple stages. The general objective of the stages that sit in between the monitoring and
execution stages is to translate data into knowledge and by means of any type of intelligence mechanism (e.g. ML/AI,
rules, policies) derive decisions that move the management target towards the desired state.
The "Execution" stage is responsible for executing workflows towards managed entities within the ZSM framework.
Execution occurs when the decision stage determines that an action is required. Workflows may be composed of one or
more operations that need to be properly orchestrated.
ETSI
13 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
NOTE 4: Execution towards managed services or managed resources occurs when the CL involves one or more
management domains and have direct access to steer the state of the managed services or managed
resources by means of ZSM domain control services. Execution towards other CLs occurs when the goal
of the CL that originates the execution is to steer the state of another CL. The latter case allows
interactions between different CLs and enables the interworking of multiple distributed CLs that are
required for the automation of the E2E services management.
The "Knowledge" is technically not a stage in the CL, but rather a means for storing and retrieving data that is shared
between the stages within a Closed Loop, as well as between different Closed Loops. Examples of data are
configuration data, operational and historical data. Knowledge can be used as a means for feedback signalling between
the other stages.
Data and control flow are represented by the arrows between the stages of the Closed Loop (i.e. M2A, A2D, D2E,
E2M). The types of data are information (M2A), insights (A2D), decisions (D2E) and feedback (E2M).
NOTE 5: The feedback in E2M may be used to improve responsiveness of the CL and when the CL does not use
persistent data services. However, feedback is also possible to be conveyed by means of the knowledge,
not only between execution and monitoring stages, but also between any stages of the CL.
The double-headed arrows between each stage and the knowledge (i.e. K1, K2, K3 and K4) are used for data-related
inputs and outputs from CL stages.
The double-headed arrows pointing into each stage and the knowledge (i.e. E1, E2, E3, E4, E5) are used for data and
control flows (e.g. policy/intent specification, parameter tuning, etc.) between different CLs within the ZSM
framework, or between CLs and external entities. Interactions specified in clause 8.2 are conveyed through E1, E2, E3,
E4 or E5.
All arrows in Figure 7.2.1-1 are realized by the endpoints exposed by the ZSM management functions that are part of
the CL, as described in clause 7.3.
Clause 7.2.2 specifies examples of data and control flows that can exist between the CL stages.
7.2.2 Closed loops data and control flow
7.2.2.1 Introduction
The arrows in Figure 7.2.1-1 represent flow of data and control messages between the various components of the CL
chain. There can be multiple flows running concurrently in a CL chain.
Which flows exist in a CL chain depends on the scenario and implementation choice. The typical, non-exhaustive, list
of flows is detailed below.
7.2.2.2 Primary flow
Upon receiving data from the underlying managed entities and/or context sources, the primary flow can be executed. It
involves all 4 Closed Loop stages and generates actions towards the managed entities. The transitions between stages in
the primary flow are expressed by arrows M2A, A2D, D2E and E2M, as explained below.
M2A
- Monitoring stage provides information based on historical and/or streaming real-time data coming from
various data sources. Information is a set of data processed in a meaningful way following the goals assigned
to the Closed Loop. The information derived from raw data is highly depend on the context. Monitoring stage
also provides capabilities for tuning the data sources and data ingestion.
- Provide historical information
- Provide real-time information
- Tune data sources
- Tune data ingestion
ETSI
14 ETSI GS ZSM 009-1 V1.1.1 (2021-06)
A2D
- Analysis stage provides insights on historical and/or streaming real-time information that is provided by the
monitoring stage. Analysis also provides capabilities for tuning the analytics models and starting/terminating
the analytics processes.
- Provide historical analytics insights
- Provide real-time analytics insights
- Tune analytics models
- Start/stop analytics process
D2E
- Decision stage provides action plans in form of workflows, e.g. onboarding of services and/or resources, or
configuration changes.
- Provide workflows
- Tune decision models
- Start/stop decision process
E2M
- Execution stage executes the workflows towards the managed entities. Optionally, it also provides information
about historical and/or more recent actions that have been executed. This can be used as a feedback to the
monitoring stage.
- Provide real-time actions
- Provide historical actions
7.2.2.3 Knowledge-enabled flow
The primary flow can preferably be augmented by data that are stored and retrieved from the knowledg
...