Zero-touch network and Service Management (ZSM); Means of Automation

DGR/ZSM-005ed111_Autom

General Information

Status
Not Published
Current Stage
12 - Completion
Due Date
16-May-2020
Completion Date
19-May-2020
Ref Project

Buy Standard

Standard
ETSI GR ZSM 005 V1.1.1 (2020-05) - Zero-touch network and Service Management (ZSM); Means of Automation
English language
70 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

ETSI GR ZSM 005 V1.1.1 (2020-05)






GROUP REPORT
Zero-touch network and Service Management (ZSM);
Means of Automation
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 GR ZSM 005 V1.1.1 (2020-05)



Reference
DGR/ZSM-005ed111_Autom
Keywords
automation, management, model, network,
orchestration, service

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

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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
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 2020.
All rights reserved.

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.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GR ZSM 005 V1.1.1 (2020-05)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Introduction . 6
1 Scope . 9
2 References . 9
2.1 Normative references . 9
2.2 Informative references . 9
3 Definition of terms, symbols and abbreviations . 13
3.1 Terms . 13
3.2 Symbols . 13
3.3 Abbreviations . 14
4 Means of Automation . 14
4.1 Overview . 14
4.2 Means of Automation: Policy Driven Automation . 15
4.2.1 Motivation. 15
4.2.2 Problems to be solved . 16
4.2.3 Solution Principles and Concepts . 16
4.2.4 Implications . 17
4.2.5 Proof of concept . 17
4.2.6 Relevance for ZSM . 17
4.3 Means of Automation: "Intent Based" . 18
4.3.0 Introduction. 18
4.3.1 Motivation. 18
4.3.2 Problems to be solved . 19
4.3.3 Principles and Concepts . 19
4.3.3.0 Differentiating Intent from Policy . 19
4.3.3.1 Policy-based management . 19
4.3.3.2 Intent-based management . 20
4.3.3.3 Intent-based modelling . 20
4.3.4 Implications . 22
4.3.4.0 Notions of "Intent-based" . 22
4.3.4.1 Intent API . 23
4.3.4.2 Intent-based networking systems . 23
4.3.4.3 Intent-based Network Service orchestration . 23
4.3.4.4 Intent-based Service orchestration . 24
4.3.5 Proof of concept . 24
4.3.5.0 "Intent-Based" is proven . 24
4.3.5.1 Intent API . 24
4.3.5.2 Intent based networking system . 25
4.3.5.3 Intent based Network Service orchestration . 25
4.3.5.4 Intent-based Service orchestration . 26
4.3.6 Relevance for ZSM . 27
4.4 Means of Automation: Intent Based Service Orchestration . 27
4.4.0 Introduction. 27
4.4.1 Motivation. 28
4.4.1.1 Business Goals . 28
4.4.1.2 Inhibitors of agility . 28
4.4.1.3 Cope with complexity . 28
4.4.1.4 Simplify automation . 29
4.4.2 Problems to be solved . 29
4.4.2.1 Aspects to consider per service . 29
4.4.2.2 Behaviour is independent from service model . 30
4.4.2.3 Models are independent from software . 30
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GR ZSM 005 V1.1.1 (2020-05)
4.4.2.4 Organization and vendor independence . 30
4.4.2.5 New modelling approach . 30
4.4.3 Principles and Concepts . 31
4.4.3.1 Intent based modelling . 31
4.4.3.2 Modelling language: Dynamic Service Descriptors (DSD) . 31
4.4.3.3 Modularization and composition of services . 33
4.4.3.4 The generic orchestration engine . 33
4.4.3.5 Automate integrations and Service marketplace . 34
4.4.4 Implications . 34
4.4.4.1 Applicable languages and necessary extensions . 34
4.4.4.2 Architecture simplification . 35
4.4.5 Proof of concept . 36
4.4.6 Relevance for ZSM . 37
4.4.6.0 Several implications become relevant . 37
4.4.6.1 Define Everything as service. 38
4.4.6.2 Operators landscape is a service . 38
4.4.6.3 Closed Loop is a service . 38
4.4.6.4 Support brownfield and classic services . 38
4.4.6.5 Support unexpected future services . 38
4.4.6.6 Revisit modelling languages . 38
4.4.6.7 Define an architecture framework . 38
4.5 Means of Automation for Network Governance . 39
4.5.1 Motivation. 39
4.5.2 Problems to be solved . 39
4.5.3 Solution Principles and Concepts . 40
4.5.3.0 Functions to differentiate . 40
4.5.3.1 The Human-to-Network Function . 41
4.5.3.2 The Policy Derivation and Management Function . 43
4.5.3.3 The AF Management Function . 45
4.5.3.4 The Enforcement Function . 45
4.5.3.5 Examples of Governance Mechanisms . 46
4.5.3.5.1 Translation Mechanisms . 46
4.5.3.5.2 Semantic-based Approach for Policy Conflict Detection . 47
4.5.4 Implications . 48
4.5.5 Proof of concept . 49
4.5.6 Relevance for ZSM . 49
4.6 Means of Automation for Network Stability . 49
4.6.1 Motivation. 49
4.6.2 Problems to be solved . 49
4.6.3 Solution Principles and Concepts . 53
4.6.3.1 Times of the Identification of Interactions between AFs . 53
4.6.3.2 Algorithms to Insure Coordination . 54
4.6.3.3 Coordination Mechanisms to Control AFs . 56
4.6.4 Implications . 56
4.6.5 Proof of concept . 57
4.6.6 Relevance for ZSM . 57
4.7 Means of Automation: Reinforcement Learning . 58
4.7.1 Motivation. 58
4.7.2 Problems to be solved . 58
4.7.3 Solution Principles and Concepts . 59
4.7.4 Implications . 60
4.7.5 Proof of concept . 61
4.7.6 Relevance for ZSM . 61
4.8 Means of Automation: Transfer Learning . 61
4.8.1 Motivation. 61
4.8.2 Problems to be solved . 62
4.8.3 Solution Principles and Concepts . 62
4.8.3.1 The Deep Reinforcement Learning framework . 62
4.8.3.2 Self-Transfer Optimization Network. 63
4.8.3.2.1 Deep Reinforcement Learning Framework . 63
4.8.3.2.2 Transfer Learning Approach . 65
4.8.4 Implications . 67
ETSI

---------------------- Page: 4 ----------------------
5 ETSI GR ZSM 005 V1.1.1 (2020-05)
4.8.5 Proof of concept . 68
4.8.6 Relevance for ZSM . 68
Annex A: Change History . 69
History . 70


ETSI

---------------------- Page: 5 ----------------------
6 ETSI GR ZSM 005 V1.1.1 (2020-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 IPR Policy, no investigation, 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.
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.
Introduction
The automation of network management and service delivery is becoming critical. All major industries are rapidly
digitizing and automating their businesses, relying on state-of-the-art cloud platforms and connectivity services
supporting a similar level of business agility and flexibility. CSP (Communications Service Provider) service delivery
and network management automation is thus becoming critical for handling the increase in overall complexity and scale
of operations created by the transformation of networks into a programmable, software-driven, service-based
architecture. Going forward, unprecedented operational agility will be required to support new business opportunities
enabled by technologies, such as network slicing and artificial intelligence.
The goal is to have all operational processes and tasks (e.g. service creation, fulfilment, assurance, and optimization)
executed automatically and enabled at scale and at a required TCO.
The present document explores and introduces different means and approaches to automate particular aspects of these
functionalities, operational processes and tasks.
Towards the automation continuum
In its simplest form, automation is the action of making a task executable without human intervention. It is realized by
introducing new automatic functions or by replacing, modifying or augmenting manual functions with automation
artifacts (e.g. a script executing a series of commands).
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GR ZSM 005 V1.1.1 (2020-05)
Automation applies to different granularities: from tasks (or function) and processes up to the entire management and
operation of digital infrastructures, i.e. to the entire Life Cycle Management (LCM) of networks and services.
Communication networks and services are already well but fragmentary automated systems.
Individual functions usually exhibit high-level automation. For example, Interior Gateway Protocols (IGP) such as
OSPF or IS-IS can automatically discover peers, advertise capabilities, share topology information, compute routing
paths and react to failures, independently of external control or human supervision [i.1].
Automation also applies to the network or service life cycle management covering phases such as installation,
configuration, provisioning, and termination; and coping with additional level of flexibility introduced by the
decoupling of control and data planes and virtualisation techniques. The essential challenge arising from this advanced
capability is the ability to develop integrated solutions (or systems) out of the composable components with the right
levels of performance, robustness, extensibility, reconfigurability; stressing even further the need for standardized
interfaces, models and mechanisms.
Yet, building a comprehensive automation solution remains an open problem. A comprehensive automation solution
consists in chaining automated functions, with the following properties:
• Vertically end-to-end, i.e. across the protocol stack or from the service-layer to the physical-layer.
• Horizontally end-to-end, i.e. across different technologies or administrative domains.
• Repeatable and reusable in different contexts, i.e. relies on standardized or best current practices for interfaces
and models.
• Provisioning dynamically, customizable "control or touch points" in the end-to-end automation loop for human
supervision.
Therefore, a comprehensive automation provides an approach for combining function automation with process
automation; in line with the approach of Continuous Provisioning (CP), as an additional step of the Continuous
Integration (CI)/Continuous Delivery (CD) model.
Automation challenges
Realizing the automation continuum faces certain challenges.
Automation pros: machine-based automation is useful for repetitive, intensive and/or error-prone tasks. Where a human
will fatigue and introduce errors, a program will run relentlessly and without departing from the normative work flow of
its operations. There is no contest that in front of repetitive and intensive actions, machines outperform human
capabilities by far. Automation can be applied virtually anywhere in the digital infrastructure chain of operation, from
functional level to inter-functions, to processes and life-cycle.
Automation cons: Pure automation techniques show rapidly their limitations limits in front of heterogeneity, changing
context/conditions of the problem at hand, i.e. they are not adaptive. These techniques will require:
• either advanced level of customization or fine tuning, which will make the automation solution specialized and
lower the automation gain;
• or human intervention to adapt to the new context (technology, domain, operation), which works against the
initial goal of automating tasks.
Tackling the automation challenge is necessary but not sufficient. Automation alone can only adapt within the function
pre-defined scope and settings. Higher levels of autonomy can be reached by combining the automatic, aware and
adaptive properties [i.2].
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GR ZSM 005 V1.1.1 (2020-05)

Figure 1: From Automatic to Autonomous - the "AAAA properties"
Collectively, the four properties qualify an autonomous system. Ultimately, this boils down to the essential coupling of
automation with the intelligence that will drive it towards cognitive operation.
From automation to autonomous and cognitive management
Cognitive management automatically solves complex problems under uncertain (sometimes hostile) conditions to adjust
and produce effective (re)action plans [i.3]. Cognitive management covers:
• Automation: ability to perform according to predetermined set of instructions.
• Complex: involve learning, inference and reasoning, causality analysis, expert knowledge.
• Uncertainty: epistemic (lack of knowledge) or aleatory (randomness/variability).
• Closed-loop: mainly adaptive (less often model-reference/predictive).

Figure 2: Legacy versus Cognitive Management - enabling a Closed Loop
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.