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)

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.

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
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
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
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
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
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
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
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
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 Capability change notification across management domains
5.1.4.1 Description
In this scenario a Management Domain (MD) A use capabilities provided by another management domain B.
Over the course of time management domain B may improve or remove capabilities such as, for example:
management domain B adds the capability to support new geographies, or technologies that support shorter
delay in the network, no support for an older technology. In such cases MD A should automatically become
aware of these changes.
ETSI
11 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5.1.4.2 Proposed Solution
Table 5.1.4.2-1: Steps in solution
Precondition: Management Domain A and B exist.
Target: Management domain A is informed of any changes in Management Domain B's resources.
NOTE: Either of the domains could be the E2E MD.
Solution Alternative 1: Event driven.
Step 1: Management Domain A configures a condition using the condition detection service of Management
Domain B, requiring to report any changes in inventory of management domain A (this is typically done
via the integration fabric). For this the manage conditions detection service (as specified in
clause 6.5.3.2.2 of ETSI GS ZSM 002 [2]) in an MD is used.
Step 2: After a new resource appears in MD B, the condition management service publishes an event over the
integration fabric notifying MD A that new capability is available in MD B. For this, the event publication
capability Provide condition state change Notifications of condition detection service (as specified in
clause 6.5.3.2.2 of ETSI GS ZSM 002 [2]) in an MD is used.
Solution Alternative 2: Using monitoring closed loop.
Step 1: MD A creates a periodic closed loop, with a configurable period, consisting only of the observe, decide,
and act stages. For this the Request M2O CL capability as specified in clause 6 is used.
Step 2: In the observe stage MD A gets updated with the set of resources from MD B, if any. For this the
manage inventory capability of the domain inventory management service as specified in
clause 6.5.5.2.6 of ETSI GS ZSM 002 [2] is used.
Step 3: In the decide stage, MD A checks internally if there are changes in the set of resources of MD B as
reported in Step 2. if yes, the act state is triggered. This is an internal capability.
Step 4: In the act stage, MD A updates the related inventories. For this the manage inventory capability of the
domain inventory management service as specified in clause 6.5.5.2.6 of ETSI GS ZSM 002 [2] is
used.
Step 5: MD A checks for updates again same as in step 2 after the period has passed.

5.1.5 Automated detection of a management domain's inability to support
the assigned part of the E2E Service
5.1.5.1 Description
In this scenario a E2E Management Domain (MD) A use a service provided by another management domain
B to support the E2E Service. Over the course of time management domain B may not be able to support its
part of the E2E service such as, for example: due to removal of an older technology, failure in MD B
network. In such cases MD A should automatically become aware of these changes.
ETSI
12 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5.1.5.2 Proposed Solution
Table 5.1.5.2-1: Steps in solution
Precondition: E2E MD A and MD B exist. MD B supports E2E A in at least one E2E service.
Target: E2E MD A shall be notified if MD B is unable to support the part of at least one E2E service in MD B
Solution Alternative 1: Event driven
Step 1: E2E MD A asks the inter-domain integration fabric to configure a condition relating to the SLA/SLS of the
part of the E2E Service using the condition detection service in Management domain B. For this the post
execution coordination service detection service (as specified in clause 6.5.3.2.2 of ETSI GS ZSM 002 [2])
in an MD is used.
Step 2: The integration fabric uses the condition detection service instance in management domain B to evaluate if
it is possible to set such a condition. If yes, the condition is set using the manage conditions detection
service (as specified in clause 6.6.3.2.2 of ETSI GS ZSM 002 [2]).
Step 3: When an SLA/SLS is violated in MD B, the MD B condition management service publishes an event over
the integration fabric. MD A is notified of the failure since it has subscribed to such notifications. For this
the event publication capability Provide condition state change Notifications of domain condition detection
service (as specified in clause 6.5.3.2.2 of ETSI GS ZSM 002 [2]) is used.
Step 4: The inter-domain integrations fabric informs E2E MD A about event.
Solution Alternative 2: Monitoring closed loop
Step 1: E2E MD A creates a periodic closed loop consisting of observe, decide, and act stages. For this the
Request M2O CL capability as specified in clause 6 is used.
Step 2: In the observe stage E2E MD A monitors the performance KPIs of the MD B part of the E2E Service. For
this the get batch measurements capability of the performance measurements collection service as
specified in clause 6.5.2.2.3 of ETSI GS ZSM 002 [2] is used.
Step 3: In the decide stage, E2E MD A checks if the monitored KPIs meet the requirement of the respective E2E
Service. If not, act state is triggered with the appropriate resolution. This is an internal capability.
Step 4: In the act state the appropriate resolutions from the decision state are carried out. This uses the
capabilities related to domain orchestration (clause 6.5.5) or domain control (clause 6.5.6) of ETSI
GS ZSM 002 [2] as required.
Step 5: After the period, MD A checks for performance updates again repeating step 2.

5.2 Analytics in closed loops
5.2.1 Dynamic configurability of E2E service monitoring
5.2.1.1 Description
Every time a new E2E Service is deployed, various aspects of the E2E Service need to be monitored to ensure that the
overall service KPIs (with regards to maintaining the SLA/SLS of the service) are being met. In addition to basic
monitoring for adherence to SLA/SLS, the E2E service may, for example, also be monitored to draw inference about
the expected performance of the E2E service by the respective analytics service. In this scenario the analytics service
may require different information at different levels of detail (for example periodicity) at different times. Hence there
may be a need for the E2E management domain to dynamically change the requested monitoring details from the
respective management domains where the E2E service is deployed. This solution is related to clauses 6.4.1 and 6.4.4 of
ETSI GS ZSM 001 [i.1].
ETSI
13 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5.2.1.2 Proposed Solution
Table 5.2.1.2-1: Steps in solution
Precondition: The E2E management domain receives a request to deploy a E2E service with certain SLA/SLS.
Target: The monitoring of the E2E service reported from the management domains to the E2E domain is
dynamically configurable.
Solution alternative:
Step 1: E2E service domain evaluates E2E service SLA/SLS requirements and sends requests to the
management domain for the required monitoring data. This is done using the "Configure Measurements"
capability in clause 6.5.2.2.2 or Configure batch measurement capability of clause 6.5.2.2.3 of ETSI
GS ZSM 002 [2].
Step 2: Based on the requested monitoring data the E2E management domain receives monitoring data from the
respective domains. For this the provide measurements capability of clause 6.5.2.2.2 or Provide batch
availability Notifications of clause 6.5.2.2.3 of ETSI GS ZSM 002 [2] is used.
Step 3: At a later stage new monitoring configuration requirements towards the management domains may be
derived.
EXAMPLE: The analytics service may request different data).
This is an internal capability.
Step 4: These new configurations are applied (same as in Step 1) to the MDs. New monitoring data is received
from the management domains based on the new request configuration same as in Step 2.
The loop (Step 3 to Step 4) continues as long as the E2E service is active.

5.2.2 Modifying services based on analytics' insights
5.2.2.1 Description
A new E2E Service is deployed across a set of management domains as determined by the E2E management domain.
During the lifetime of the E2E service, the analytics services of an involved management domain provide insights that
may result in the E2E management domain modifying the E2E service. This solution is related to clauses 6.4.2 and
6.4.3 of ETSI GS ZSM 001 [i.1].
5.2.2.2 Proposed Solution
Table 5.2.2.2-1: Steps in solution
Precondition: The E2E management domain has deployed an E2E service across management domains, say
MD1, MD2, MD3.
Target: The E2E service is modified based on insights received from any one of the domains MD1-3.
Solution alternative:
Step 1: E2E management domain evaluates E2E service requirements and deploys the E2E service across
management domains MD1, MD2, and 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 analytics service in any one of the domains MD1, 2, 3 or the E2E MD provides an insight about the
E2E service. The insight is received by an E2E MD as it may not be possible to be handled locally.
EXAMPLE 1: The insight is about the possible increase in demand in a specific coverage area.
See clause 5.1.5 on the solution for how this is done.
Step 3: The E2E MD based on the received insight modifies the E2E service.
EXAMPLE 2: Increases the resources, like spectrum, for that coverage area.
The manage service lifecycle capability as in clause 6.5.5.2.1 of ETSI GS ZSM 002 [2] is used for this purpose.

ETSI
14 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
5.2.3 Maintaining AI Models in Analytics
5.2.3.1 Description
AI models can be applied in domain analytics services for a specific goal (e.g. anomaly detection, root cause analysis).
The models developed using training data collected during a certain time period may degrade as time passes and the
target environment changes, causing incorrect analysis results or overlooking failures. To detect such performance
degradation of AI models and improve them, a set of management services (AI model management service, deployed
AI model assessment service, AI training data management service, Deployed AI model performance evaluation
service) are specified in ETSI GS ZSM 002 [2]. The present scenario provides a possible solution for the maintenance
of AI models by those management services in a zero-touch manner.
5.2.3.2 Proposed Solution
Table 5.2.3.2-1: Steps in solution
Precondition: The AI model created by AI model management service is operational in the domain analytics
service.
Target: The AI model is updated based on its performance to keep a proper closed-loop operation.
Solution alternative
Step 1: Deployed AI model performance evaluation service producer as specified in clause 6.6.3.2 of ETSI
GS ZSM 002 [2] provides the notification of performance degradation of the AI model to the
deployed AI model assessment service via the appropriate integration fabric.
Step 2: The deployed AI model assessment service producer as specified in clause 6.6.4.2.2 of ETSI
GS ZSM 002 [2] publishes the decision result on the most appropriate action for the degraded
deployed AI model in the cross-domain integration fabric.
Step 3: If the decision result in Step 2 is re-training, AI model management service producer as specified in
clause 6.6.4.2.1 of ETSI GS ZSM 002 [2] updates the AI model using new AI training data derived
by AI training data management service producer as specified in clause 6.6.4.2.3 of ETSI
GS ZSM 002 [2].
Step 4: The AI model management service producer configures the domain analytics to replace the existing
AI model used in its analysis with the updated one at a particular time.

5.3 Closed loop coordination
5.3.1 Coordination between multi-domain closed loops
5.3.1.1 Description
When an unexpected event occurs such as an earthquake or when a large-scale event is held, demands for network
services increase. It may be necessary for a specific Management Domain (say MD-A) to cope with the increase of
demands e.g. a sudden increase of traffic or loads on managed entities. In such cases, CLs in MD-A take action and may
need to report information (e.g. results of action taken by the CL in MD-A) to CLs in E2E service MD. In such cases, to
proactively mitigate the impact caused by the event, CLs in E2E service MD should have the ability to delegate roles
(e.g. of Analytics or Decision) to lower CLs in other MDs (say MD-B). This definition is related to clause 7.2.2 of
ETSI GS ZSM 009-1 [3].
ETSI
15 ETSI GS ZSM 009-2 V1.1.1 (2022-06)
E2E Service MD
Output from CL in E2E Service MD
Output from CL in MD-A
(Input to CL in MD-B)
(Input to CL in E2E Service MD)
MD-B
MD-A
Output from CL in MD-B
Input to CL in MD-A
Figure 5.3.1.1-1: Interaction between CLs at different levels
5.3.1.2 Proposed Solution
Figure 5.3.1.2-1: Solution alternative for coordination between multi-domain closed loops
Table 5.3.1.2-1: Steps in solution
Precondition: The E2E management domain has deployed an E2E service across management domains and the
CL governance service producer in MD-A has set a subscription to get information related to anomaly in MD-A.
Target: MD-A reports the changed management information which also has an impact on management information
in E2E MD. Based on the change in MD-A, the CL in E2E MD further delegates to MD-B.
Solution alternative
Step 1: An anomalous state (e.g. sudden increase of traffic or load on managed entity, etc.) is detected in MD-A
and Anomaly detection service producer notifies the information to CL governance service producer,
using Provide analysis result capability as described in clause 6.5.3.2.1 in ETSI GS ZSM 002 [2].
Step 2: The reactive incident analysis service producer analyses the anomalous state using Request analysis
result capability as described in clause 6.5.3.2.1 in ETSI GS ZSM 002 [2].
Step 3: Based on the analysis derived in Step 2, the CL in MD-A takes a recovery action by using Manage
service lifecycle and/or Execute workflow capabilities as described in clause 6.5.5.2.1 of ETSI
GS ZSM 002 [2], offered by Domain orchestration service producer. The change to management
information in the MD-A has an impact on management information in E2E service MD.
Step 4: The change derived in Step 3 is notified to higher closed loop entity such as E2E service MD using
Request issue resolution capability of Closed loop governance service producer as described in
clause 9.2.1 in ETSI GS ZSM
...