ETSI GS ZSM 009-2 V1.1.1 (2022-06)

Zero-touch network and Service Management (ZSM); Closed-Loop Automation; Part 2: Solutions for automation of E2E service and network management use cases

DGS/ZSM-009-2_CLA_sol

General Information

• Status: Not Published
• Technical Committee: ZSM - Zero-touch network and Service Management
• Current Stage: 12 - Completion
• Due Date: 02-Jun-2022
• Completion Date: 21-Jun-2022

Standards Content (Sample)

ETSI GS ZSM 009-2 V1.1.1 (2022-06)






GROUP SPECIFICATION
Zero-touch network and Service Management (ZSM);
Closed-Loop Automation;
Part 2: Solutions for automation of E2E service and
network management use cases
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.

---------------------- Page: 1 ----------------------
2 ETSI GS ZSM 009-2 V1.1.1 (2022-06)

Reference
DGS/ZSM-009-2_CLA_sol
Keywords
automation, network management, use case

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
arranty is made of merchantability or fitness
and/or governmental rule and/or regulation and further, no representation or w
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 2022.
All rights reserved.

ETSI

---------------------- Page: 2 ----------------------
3 ETSI GS ZSM 009-2 V1.1.1 (2022-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, abbreviations and conventions . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 Abbreviations . 7
3.4 Conventions . 7
4 Introduction . 7
5 Solutions supporting selected scenarios . 8
5.1 Generic management using closed loops . 8
5.1.1 Inclusion of a new physical resource into a management domain . 8
5.1.1.1 Description . 8
5.1.1.2 Proposed Solution . 8
5.1.2 Provisioning services in back up domains . 8
5.1.2.1 Description . 8
5.1.2.2 Proposed Solution . 9
5.1.3 Automated service healing capability . 9
5.1.3.1 Description . 9
5.1.3.2 Proposed Solution . 10
5.1.4 Capability change notification across management domains . 10
5.1.4.1 Description . 10
5.1.4.2 Proposed Solution . 11
5.1.5 Automated detection of a management domain's inability to support the assigned part of the E2E
Service . 11
5.1.5.1 Description . 11
5.1.5.2 Proposed Solution . 12
5.2 Analytics in closed loops . 12
5.2.1 Dynamic configurability of E2E service monitoring . 12
5.2.1.1 Description . 12
5.2.1.2 Proposed Solution . 13
5.2.2 Modifying services based on analytics' insights . 13
5.2.2.1 Description . 13
5.2.2.2 Proposed Solution . 13
5.2.3 Maintaining AI Models in Analytics . 14
5.2.3.1 Description . 14
5.2.3.2 Proposed Solution . 14
5.3 Closed loop coordination . 14
5.3.1 Coordination between multi-domain closed loops . 14
5.3.1.1 Description . 14
5.3.1.2 Proposed Solution . 15
5.3.2 Knowledge sharing across closed loops. 16
5.3.2.1 Description . 16
5.3.2.2 Proposed Solutions . 16
5.3.2.2.1 Knowledge Sharing across management domains . 16
5.3.2.2.2 Knowledge Sharing to detect the effects of Closed Loops actions after their execution . 17
5.3.3 Limiting actions of a closed loop . 17
5.3.3.1 Description . 17
5.3.3.2 Proposed Solution . 17
5.3.4 Pre-action conflict management between closed loops. 18
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5.3.4.1 Description . 18
5.3.4.2 Proposed Solution . 18
5.4 Closed loop governance . 19
5.4.1 Enabling pause points in a closed loop . 19
5.4.1.1 Description . 19
5.4.1.2 Proposed Solution . 20
5.4.2 CL Goal configuration . 21
5.4.2.1 Description . 21
5.4.2.2 Proposed Solution . 21
5.4.3 CL Goal feasibility check . 22
5.4.3.1 Description . 22
5.4.3.2 Proposed Solution . 23
5.4.4 Trigger based CL state change . 24
5.4.4.1 Description . 24
5.4.4.2 Proposed Solution . 25
5.4.5 Trigger based CL Goal change . 26
5.4.5.1 Description . 26
5.4.5.2 Proposed Solution . 26
5.4.6 M2O-CLs preparation and commissioning from multi-vendor stages . 27
5.4.6.1 Description . 27
5.4.6.2 Proposed Solution . 27
6 Additional Capabilities . 29
History . 30


ETSI

---------------------- Page: 4 ----------------------
5 ETSI GS ZSM 009-2 V1.1.1 (2022-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 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 of
ETSI GS ZSM 009-1 [3].
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

---------------------- Page: 5 ----------------------
6 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
1 Scope
The present document presents solutions to scenarios related to closed loops using the ZSM specified service
capabilities. New service capabilities are specified where the need arises based on the scenarios solution requirements.
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 007 (V1.1.1): "Zero-touch network and Service Management (ZSM); Terminology
for concepts in ZSM".
[2] ETSI GS ZSM 002 (V1.1.1): "Zero-touch network and Service Management (ZSM); Reference
Architecture".
[3] ETSI GS ZSM 009-1 (V1.1.1): "Zero-touch network and Service Management (ZSM); Closed-
Loop Automation; Part 1: Enablers".
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 001: "Zero-touch network and Service Management (ZSM); Requirements based
on documented scenarios".
3 Definition of terms, symbols, abbreviations and
conventions
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS ZSM 007 [1] apply.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS ZSM 007 [1] apply.
3.4 Conventions
Clause 5 of the present document specifies expected solutions to typical automation scenarios using ZSM specified
capabilities. For each step a corresponding capability is referenced from ETSI ISG ZSM specifications. The scenarios
are briefly described in the description part of each clause. The solutions are provided in a table similar to table 3.4-1
that provides a pre-condition, a target, examples of expected steps for the solution and references to ZSM capabilities
that may be used to achieve that step.
The table format with explanation of each of the parts is provided in table 3.4-1.
Table 3.4-1: Table used for solutions to scenarios
Precondition: The conditions/assumptions of the scenario
Target: The target to be achieved by the solution of the scenario
Solution alternative
Step 1: Step 1 of the solution. For this the capability X specified in clause Y.x is used.
Step 2: (Steps may refer to a picture).

4 Introduction
The present document specifies solutions to automation scenarios. The scenarios and corresponding solutions are
presented together in clause 5. Scenarios are grouped in four categories, namely:
1) Generic management scenario solutions addressed in clause 5.1.
2) Scenario solutions relating to analytics in clause 5.2.
3) Scenario solutions relating to closed loops' coordination in clause 5.3.
4) Scenarios to solutions relating to closed loops' governance in clause 5.4.
Clause 6 specifies additional capabilities which extend existing ZSM services supporting the solutions.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5 Solutions supporting selected scenarios
5.1 Generic management using closed loops
5.1.1 Inclusion of a new physical resource into a management domain
5.1.1.1 Description
When a new physical resource is added to a management domain all other relevant authorized management domains
should become aware of the management domain's ability to provide services based on the inclusion of the new
resource. For example: when a new radio is added to the RAN domain of an operator the E2E management domain of
the operator detects that it has the ability to provide services in an updated coverage area. This scenario is related to the
scenario in clause 6.2.3.6 of ETSI GS ZSM 001 [i.1].
5.1.1.2 Proposed Solution
Table 5.1.1.2-1: Steps in solution
Pre-condition: The operator network exists and is operational, and a new physical resource is added into a
management domain, say MD1.
Target: To notify relevant management domains of the update in services based on the availability of the new
resource in a management domain.
Solution alternative
Step 1: MD1 updates its inventory and service capabilities based on the inclusion of a new resource. This is an
internal capability of the management domain.
Step 2: Other management domains authorized to view the changes in service/resource capabilities of MD1 can
view these changes at their respective abstraction level. The solution to do this is specified in clause 5.1.4.
Step 3: The management domains can use the updated capabilities of MD1.

5.1.2 Provisioning services in back up domains
5.1.2.1 Description
A new E2E Service may be provisioned in one or more management domain(s) as determined by the E2E management
domain. However, if during the lifetime of the service one of the management domains, (say MD1) becomes unable to
host its part of the E2E service (for example: MD1 encounters a failure) then the E2E service may need to provision an
equivalent part of the E2E service that was hosted by MD1 to another management domain (say MD2) to ensure the
continued operation of the E2E service. This solution is related to scenarios in clause 6.2.3 of ETSI GS ZSM 001 [i.1].
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5.1.2.2 Proposed Solution
Table 5.1.2.2-1: Steps in solution
Precondition: The E2E management domain has deployed an E2E service across management domains MD1,
MD2, MD3. The E2E management domain detects that MD1 is unable to support its part of the E2E service.
Target: The E2E management domain can deploy the E2E Service in a new set of management domains, say,
MD-A, MD-B, MD-C.
NOTE 1: The relationship between MD-A-C , MD1-3 is intentionally not specified. That is to say that, for example
MD-B could be identical to MD-2.
Solution alternative:
Step 1: E2E management domain evaluates E2E service requirements and deploys the E2E service across
multiple Management domains, say MD1, MD2, MD3. The manage service lifecycle capability as in
clause 6.5.5.2.1 of ETSI GS ZSM 002 [2] is used for this purpose.
Step 2: The E2E management domain detects that the domain MD1 is no longer able to support its part of the
requested service and re-evaluates that the desirable new solution is MD-A, MD-B and MD-C. If the E2E
MD is unable to find a new set of MDs to support the E2E Service, it issues an alarm to the ZSM
consumer. See clause 5.1.5 on the solution for how this is done.
Step 3: The E2E MD deactivates the request from MD2, MD3 and deploys it on MD-A, MD-B, MD-C. The
manage service lifecycle capability as in clause 6.5.5.2.1 of ETSI GS ZSM 002 [2] is used for this
purpose.
NOTE 2: The use case focuses on deployment, other procedures required to support the deployment are not
addressed.

5.1.3 Automated service healing capability
5.1.3.1 Description
An E2E service is deployed across a set of management domains. During the lifetime of the E2E service a failure occurs
in one management domain which then intends to automatically heal the service without involving the other
management domains of the E2E management domain. If self-healing is not possible in the management domain local
scope, the management domain escalates the problem towards the E2E management domain, which then evaluates the
problem, initiates service self-healing actions in the E2E scope, and drives the management domains to perform the
required reconfigurations in the underlying management domains. The solution is related to clauses 6.2.3.3 and 6.5.3 of
ETSI GS ZSM 001 [i.1].
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5.1.3.2 Proposed Solution
Table 5.1.3.2-1: Steps in solution
Precondition: The E2E management domain has deployed an E2E service across a set of management
domains, e.g. MD1, MD2, MD3.
Target: The service is automatically self-healed by a management domain or by the E2E management
domain when an infrastructure failure occurs in a management domain.
Solution alternative:
Step 1: Domain analytics management functions subscribe to fault events service running at
management domains to detect fault events regarding the deployed E2E service originating from
the infrastructure resources of the respective management domain, e.g. MD1, MD2, MD3. For this
the provide notification capability of the fault events service as specified in table 6.5.2.2.1-2 of
ETSI GS ZSM 002 [2] is used.
Step 2: The E2E domain analytics management functions subscribe to anomaly detection service running
at management domains and/or E2E anomaly detection service. For this the provide analysis
results capability of the anomaly detection service as specified in table 6.5.3.2.1-2 of ETSI
GS ZSM 002 [2] is used.
Step 3: When a failure occurs in a domain, the reactive incident analysis service of the corresponding
management domain (e.g. MD1) tries to heal the impacted service locally. This capability is
domain internal.
Step 4: When the service healing is not possible in the management domain's local scope then the
problem is escalated towards the E2E management domain using the health issue reporting
service. For this the provide health issue notification of the health issue reporting service as
specified in clause 6.5.4.2.5 of ETSI GS ZSM 002 [2] is used.
Step 5: The E2E management domain evaluates the situation using the E2E anomaly detection service
and the responsible E2E service closed loop determines the required management domain level
reconfiguration actions, e.g. in MD1 and MD2. This capability is domain internal
Step 6: The required actions are performed in the respective MDs using the manage resource
configuration capability of the Resource configuration management service.

5.1.4 Capa
...