IEEE IM 2021 Tutorial - Next-generation closed-loop automation - an inside view

NEXT GENERATION
CLOSED-LOOP AUTOMATION
L. Ciavaglia, P. H. Gomes, I. Vaishnavi

ABOUT US
Laurent
Ciavaglia
Senior Standardization
Specialist, Nokia
Pedro Henrique
Gomes
Senior Researcher, Ericsson
Ishan
Vaishnavi
Research Topic Leader,
Lenovo
2 Next-Generation Closed-Loop Automation | IEEE IM 2021 Tutorial May 2021
We work together in the ETSI ISG ZSM “Zero
Touch Network & Service Management” as
Rapporteurs for the group of specifications on
Closed-Loop Automation
Our motivations for this tutorial are to:
• Share our experience and inside view of the
standards development process on a key
enabling technology for network automation
• Present and reflect on the most recent
developments in standards and open source
towards the realization of next generation
multi-vendor, coordinated, operator-friendly
closed-loop automation solutions

ABOUT US
Laurent
Ciavaglia
Senior Standardization Specialist,
Nokia
Mini Bio
Laurent is Innovation and Standardization Expert at Nokia where he
works at inventing future network automation technologies with focus
on intent-driven, zero-touch and artificial intelligence techniques.
He is Rapporteur of ETSI ZSM GR 009-3 on Closed-Loop Automation
Advanced Topics and ETSI ZSM GS 012 on AI Enablers for Network
and Service Automation.
Laurent serves as co-chair of the IRTF Network Management Research
Group (NRMG) and participates in standardization activities related to
network and service automation in IETF and ETSI.
Laurent is also Standards Liaison Officer of the IEEE Network
Intelligence ETI (Emerging Technical Initiative) and an active member
of the IEEE ComSoc Technical Committee on Network Operation and
Management (CNOM).

ABOUT US
Pedro Henrique
Gomes
Senior Researcher, Ericsson
Mini Bio
Pedro Henrique Gomes is a senior researcher at Ericsson Research Brazil,
engaged in orchestration and automation of 5G network services.
He is a delegate in the ETSI Zero-Touch Network & Service Management
(ZSM) working group, contributing to the architecture definition
especially with AI and ML concepts and the specification of enablers
for Closed-Loop Automation.
He received his Ph.D. (2019) and M.Sc. (2015) in electrical engineering
from the University of Southern California, USA, and his B.Sc. (2007) in
computer engineering from the University of Campinas, Brazil.

ABOUT US
Ishan
Vaishnavi
Research Topic Leader,
Lenovo
Mini Bio
Ishan Vaishnavi is a research lead at Lenovo responsible globally for the
work in Network Management research and standards.
Prior to that, he worked at Huawei and Docomo in the
telecommunication management fields and as a developer for Solaris
and Java at Sun microsystems.
He has been one of the key proponents of virtualization, SDN and slicing
for telecommunication networks and has seminal works in those
areas. He is an active participant in EU Projects based Research, ETSI
and 3GPP standards’ development.

Useful
information
Slides are available on SlideShare
https://www.slideshare.net/
Search for instructor’s name
May 2021
Next-Generation Closed-Loop Automation | IEEE IM 2021 Tutorial
6

Let’s have an interactive tutorial !
Feel free to ask questions anytime
Use the Q&A
May 2021
7
Useful
information

May 2021
8
Part I A. The Need for Automation
B. Landscape Overview
C. Concepts and Definitions
INTRODUCTION 11:15 AM - 1:15 PM
LONG BREAK 1:15 PM - 2:15 PM
DEEP DIVE II 4:30 PM - 6:30 PM
Part II
A. Closed Loop Coordination
including Illustrative Examples
B. Closed Loop Modeling
C. Future Directions
D. Summary of Learnings and Conclusions
Part III
A. Closed Loop Governance
DEEP DIVE I 2:15 PM - 4:15 PM
SHORT BREAK 4:15 PM - 4:30 PM
* All times are CEST

May 2021
9
Next-Generation Closed-Loop Automation | IEEE IM 2021 Tutorial * All times are CEST

The Need for
Automation
Part I-A
Peter Baer via Flickr
May 2021
10

Recent transformations in Telco
The telco operator network is increasingly complex
- Multiple Technologies (Radio, Network, Cloud,
Core) in a complex topology
- Multiple Vendors
- Backward Compatible (3G, 4G… )
- Size of the network
Telco
infrastructures
are complex
May 2021
11

5G high level architecture
May 2021
12

Problems in Management of 5G
5G was aimed at reducing CAPEX
Management is complex and runs in the background
- Traditionally separated in OSS and BSS
- Integrates Multiple Technologies (Radio, Network,
Cloud, Core)
- Integrates Vendors
- Management architecture must be designed to
maintain scalability, reliability
All of this has an impact on the OPEX of the operators
May 2021
13

Scale in or
scale down
Scale out or
scale up
Simple scenario for management automation
Existing: Plug N Play New: NF scaling
Requires
- Historical knowledge
- Monitoring of the network
- Decision making and
configuration
New radio auto install
New equipment auto-install
May 2021
14

From Manual to Automated to Autonomous Operation
Policies TOSCA models
SLA/SLS/SLO
Operator Customer
Workflow and Policy execution
Automated operation:
Input: SLA/SLS/SLO, policies, TOSCA models
• Workflows and policies invoking actions
through dedicated APIs
• Tight coupling between services and policies
• “Zero-touch” only as long as policies match
situations
• Intelligence and decision making by humans
at design time
Operations Team
Tickets Strategy Targets Priorities
Service Order
Network Cloud RAN
Manual operation:
Input: Documents and work orders
• A team of specialists operates the
network manually by configuring,
provisioning, assuring, optimizing
• All decisions are made, and all actions are
initiated by humans
Actuation
Reasoning
Knowledge
Behavioral Intent Strategic intent
Service Intent
Intent Handling
Autonomous operation:
Input: Intent for setting goals and targets
• Paradigm shift from explicit invocation of
actions to goals-based autonomy
• Artificial Intelligence can explore and find
new solutions
• Zero-touch because the machine can assess
utility, consequences, risk
Operator Customer
Operator Customer
Network Cloud RAN Network Cloud RAN
Source: TM Forum IG 1230 - Autonomous Networks Technical Architecture
May 2021
15

Why CLA Standards matter…
• Interoperability
• Multi-vendor environment
• “Open” specifications,
interfaces and protocols
May 2021
16
The need for (good) Standards

Landscape
Overview
Part I-B
May 2021
17

Autonomic Computing: IBM's Perspective on the State of Information Technology (2001)
Self-management of system components (self-CHOP):
● Self-configuration
● Self-healing
● Self-optimizing
● Self-protecting
Autonomic manager (Closed Loop):
● Monitor – collect, aggregate, filter
● Analyze – correlate and model complex situations.
Learn and predict.
● Plan – constructs the actions needed.
Uses policy information.
● Execute – control the execution of the plans,
considering dynamic updates
IBM MAPE-K
Source: IBM, An architectural blueprint for autonomic computing
May 2021
18

OODA (John Boyd)
Observe–Orient–Decide–Act cycle developed by military strategist and US Air Force Colonel
John Boyd
The second O (Orientation) as the repository of our genetic heritage, cultural tradition,
and previous experiences—is the most important part of the O-O-D-A loop since it
shapes the way we observe, the way we decide, the way we act.
May 2021
19

FOCALE
May 2021
20
Foundation, Observation, Comparison,
Action, and Learning Environment
• Evolution-extension of the OODA loop
• Semantically rich architecture for orchestrating the
behavior of heterogeneous and distributed
computing resources
[1] J. Strassner et al., The design of an Autonomic Element for managing
emerging networks and services, International Conference on Ultra Modern
Telecommunications & Workshops. 2009

GANA (EFIPSANS and ETSI ISG AFI)
May 2021
21
Generic Autonomic Network Architecture
[1], [2]
• A blueprint model prescribing design and operational
principles of autonomic decision-making manager
components/elements, responsible for autonomic
management and adaptive control of services and
network resources
• Essential concepts
• Decision-Elements/Engines and Decision Plane Hierarchy
• Managed Entities
• Knowledge Plane
• Network Governance Interface
[1] C. Simon et al., Enabling autonomicity in the future networks, IEEE Globecom
Workshops. 2010
[2] ETSI GS AFI 002 AFI Generic Autonomic Network Architecture

ETSI ENI
May 2021
22
Experiential Networked Intelligence
[1]
• ISG ENI focuses on improving the operator
experience by adding closed-loop artificial
intelligence mechanisms based on context-aware,
metadata-driven policies to recognize and
incorporate new and changed knowledge, and
hence, make actionable decisions more quickly
[1] Y. Zeng et al., ENI Vision: Improved Network Experience using Experential
Networked Intelligence, ETSI Whitepaper. 2021.

IETF & IRTF
• NMRG
• Autonomic Networking (2013-2014)
• RFC 7575 - Autonomic Networking: Definitions and Design Goals
• RFC 7576 - General Gap Analysis for Autonomic Networking
• Intent-based Networking (2016-Present)
• https://datatracker.ietf.org/group/nmrg/documents/
• ANIMA WG
• Reference model
• https://datatracker.ietf.org/doc/html/draft-ietf-anima-reference-model-10
• Soon to be RFC 8993
• Control Loops
• https://datatracker.ietf.org/doc/html/draft-strassner-anima-control-loops-01
• Good overview of control loops state-of-the-art and requirements; expired document
• OPSAWG
• RFC 8969 - A Framework for Automating Service and Network Management with YANG
• Network Telemetry Framework
• https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ntf-07
• Service Assurance for Intent-based Networking Archietcture
• https://datatracker.ietf.org/doc/draft-claise-opsawg-service-assurance-architecture/
May 2021
23

3GPP 5G Logical Architecture
Management
May 2021
24

Concept - Management Service
Management Capability: A functionality provided to you - example: get something configure
something, create something…
Management Service: A collection of capabilities provided to you
Management Service Producer: An implementation of a specific management service
Management Function: An implementation of one or more management services and or
consumers of services
Managed Entity: the resource being managed
Management domains: Any collection of resources that has its own management service
implementation - think geographical, administrative, technological...
May 2021
25

3GPP SA5 – Managing the 3GPP network
NFMSP
NSSMSP
NSMSP
NF(SA2)
NF MOI(SA5)
Attribute name
Support
Qualifier
isReadable isWritable isInvariant isNotifyable
pLMNIdList M M M - M
tAClist M M M - M
sBIFQDN M M M - M
sBIServiceList M M - - M
nSSAI CM M M - M
SMF IoC
May 2021
26
To CSP (CSaaS)
Vertical Consumer (NSaaS)

NFMSP
NSSMSP
NSMSP
NF(SA2)
NF MOI(SA5)
May 2021
27
To CSP (CSaaS)
Vertical Consumer (NSaaS)

NFMSP
NSSMSP
NSMSP
NF(SA2)
NF MOI(SA5)
To CSP (CSaaS)
Vertical Consumer (NSaaS) For each Service Interface
May 2021
28

History of CL in SA5 - SON CLs
• Self Configuring
• PNP
• Self Optimizing
• CCO
• HO
• Self Healing
• Fault supervision
L. Jorguseski, A. Pais, F. Gunnarsson, A. Centonza and
C. Willcock, "Self-organizing networks in 3GPP:
standardization and future trends," in IEEE
Communications Magazine, vol. 52, no. 12, pp. 28-34,
December 2014, doi: 10.1109/MCOM.2014.6979983.
SON represents very specific closed loops in 3GPP where the data that you monitor and the actions
you take are specified in the specification itself, the operator may configure some thresholds.
May 2021
29

SON basic operation
SON
Function
Managed
Object/element/entity
Data in Configuration out
Threshold
configuration in
Advantage : Very deterministic
Disadvantage : Very deterministic
(limited configurability, no AI, no analytics)
May 2021
30

3GPP SA5 – Status R16 - Service Assurance
3GPP defines a number of attributes of the
assuranceClosedControlLoop (ACCL)
(TS28.535, TS28.536)
❑ LifcyclePhases:
Prep, Commisioning, Op, Decomissioning
❑ Goal target and value – only supports
equalTo currently
❑ A list of targets
❑ Goal status: current and predicted
May 2021
31

SA5- R16 status
Goal configuring sequence diagram
ACCL state diagram
May 2021
32

TM Forum – Autonomous Networks
Autonomous Networks Project started in May 2019 with White Paper
“Autonomous Networks: Empowering Digital Transformation For The
Telecoms Industry”
“Define fully automated zero wait, zero touch,
zero trouble network/ICT services”
“Autonomous Networks incorporate a simplified network architecture,
autonomous domains and automated intelligent business/network operations
for the closed-loop control of digital business, full lifecycle operations
automation/autonomy and maximum resource utilization.”
May 2021
33

Autonomous Network Concepts
Autonomous Domain
● An administrative governance boundary (Management
Domain) that defines the scope of delegated
autonomous behaviors
Intent-driven APIs
Self X Capabilities and Closed control Loop Optimization
Operational layers are decoupled
● Business, Service, Network
● A prerequisite of an autonomic architecture is the
efficient separation of the “operating layers” for the
control loops.
May 2021
34

Autonomous Network Architecture
Source: TM Forum IG 1230 -Autonomous Networks Technical Architecture May 2021
35

Cognitive Closed Loop
May 2021
36

AI-driven closed loops - CLADRA
Closed-loop Anomaly Detection and Resolution Automation (CLADRA) Project
• “AI driven closed-loop automation to transform network operations to detect anomalies,
determine resolution and implement the required changes to the network within a
continuous highly automated framework.”
May 2021
37

ONAP - Open Network Automation Platform
“ONAP is a comprehensive platform for orchestration, management, and
automation of network and edge computing services for network operators,
cloud providers, and enterprises.”
Key Projects for control
loop automation:
● SDC
● DCAE
● Policy Framework
● CLAMP
● SO and Controllers
May 2021
38

Closed Control Loop Automation in ONAP
Design time and run-time elements
1. DCAE collects performance, usage, configuration data; and provides Analytics
2. Policy Framework and CLAMP detect the problems and identify remediation
3. Service Orchestrator or a Controller takes the appropriate action(s)
May 2021
39

CLAMP - Control Loop Automation Management
Platform
2 control loop levels in Policy/CLAMP:
● CLAMP is a function for designing and managing control loops
● You can visualize a control loop, configure it with specific parameters for a
particular network service, then deploy and undeploying it.
● Once deployed, the user can also update the loop with new parameters during
runtime, suspend and restart it.
Control loop template:
● This is created from the DCAE
blueprint (designed in the DCAE
designer), and distributed by SDC to
CLAMP
Control loop instance:
● Based on the template, it represents
a physical control loop in the
platform related to a service and a
VNF.
May 2021
40

CLAMP - Future work (Honolulu R8 and Istanbul R9)
41
• CLAMP has been integrated into the Policy framework project (as a PoC in
R8 and definitely in R9)
• CLAMP is now a function for designing and managing control loops and a UI to
manage Policies.
• In R7 and R8:
• TOSCA language has been
used to model Closed Loops
in CLAMP
• In R9:
• TOSCA will be used for the
LCM of Closed Loops
May 2021
41

O-RAN
May 2021
42
Openness
— Expand the RAN vendor ecosystem.
Avoid lock-in and reduce prices
— Making 3GPP defined RAN
interfaces true multi-vendor
Intelligence
— Self-driven networks with AI-
optimized closed-loop automation
— Defining two Radio Intelligent
Controllers (RIC)
Virtualization
— Introduce service agility and cloud
scale in the RAN
— Open-source realization of O-RAN
nodes
O-RAN
Mission
▪ Initial founding members: AT&T, DT, DoCoMo, CMCC, Orange
▪ 27 operator members
▪ 218 Contributors (non-operator members)
O-RAN Alliance
● Created in Feb 2018 at MWC
● Merger of xRAN Forum and CRAN Alliance
● Mission is to transform the Radio Access
Networks Industry towards Open, Intelligent,
Virtualized and Fully Interoperable RAN
May 2021
42

O-RAN Architecture
A Service Management
and Orchestration system
for O-RAN functions.
Enables near-real-time control and optimization of RAN
elements and resources via fine-grained data collection
and actions over E2 interface. It may include AI/ML
workflow including model training, inference and updates.
Enables non-real-time
control and optimization of
RAN elements and
resources and policy-
based guidance to the
applications/features in
Near-RT RIC through A1
interface.
Hosts the lower
physical layer and RF
(Radio Frequency)
processing.
Hosts the RLC (Radio Link
Control), MAC (Media Access
Control) and higher physical
layer functions.
Cloud computing platform comprising a
collection of physical infrastructure
nodes to host the relevant O-RAN
functions. Also provides appropriate
management and orchestration features.
Hosts the user plane part of
the RRM function.
Hosts the control plane
RRM (Radio Resource
Management) function.
May 2021
43

O-RAN RIC – Radio Intelligent Controllers
44
Open Fronthaul Interface
F1-c
Service management & Orchestration Framework
A1
F1-u
E1
E2
Non-Real Time RIC
O-DU
O1
NG2
NG3
NearRIC Platform
xAPP
xAPP
xAPP
xAPP
API
NonRIC Platform
rAPP
rAPP
rAPP
rAPP
API
O2
O-RU
Infrastructure & White boxes
O-CU-UP
O-CU-CP
Beamforming, scheduling, CoMP
and fast spectrum management
50µs – 10 ms
Handover, QoS, Dual connectivity,
load balancing
50ms – 200 ms
Management, orchestration, SON
Seconds and up
Near-Real Time RAN
Intelligent Controller (RIC)
May 2021
44

Non-real time and Near-real time RICs
45
Source: O-RAN Alliance
Deployment modes
R-APP ...
NonRT-RIC
A1 i/f
NMS data bus
R-APP R-APP R-APP
X-APP ...
NearRT-RIC
X-APP X-APP X-APP
Platform part
Platform part
May 2021
45

Consolidated view of CLA landscape
• Each group defining closed loops, enablers or architectures at
various levels
• Domain-level: e.g. 3GPP SA5, O-RAN, IETF, (ONAP)…
• End-to-end / inter-domain: TMForum ANP, ZSM, (ONAP)…
• Commonalities and complementarities of the different
groups/works – but also differences
• Need for cross-SDO interaction
May 2021
46

Concepts and
Definitions
Part I-C
May 2021
48

Concept - Management Domain
May 2021
49

Open-loop & Closed-loop Automation
Open-Loop Automation Closed-Loop Automation
A. The human operator intervenes in one or more of the
process steps of the loop
B. The human operator sets the goals of the loop
A. The operation of the loop is fully automated
B. The human operator sets the goals of the loop. The
human operator supervises the operation of the loop
May 2021
50

ETSI Zero-Touch Network and Service Management
(ETSI ZSM)
14 founding members
Formed under the auspices
of the ETSI ISG
Key objective
Enable future operational
processes and tasks to be
executed automatically, end-
to-end
Industry convergence
Facilitate collaboration with
the relevant open-source
projects, standardization
bodies and fora
Goal
Accelerate the definition of the
end-to-end service
management architecture,
spanning both legacy and
virtualized network
infrastructures
Interoperability
Provide a common foundation
to enable a diverse ecosystem
of open source groups to
produce interoperable
solutions
May 2021
51

ETSI ZSM Architecture I
52
Architectural principles:
• Modular, flexible, scalable and extensible service-based
architecture
• Separation of concerns: network domain management and end-
to-end cross-domain service management, where each domain
addresses its own sphere of expertise
• Support of model-driven, open interfaces
• Support of intent-based interfaces
• Enablement of adaptive closed-loop management automation,
where the automated decision-making mechanisms can be
bounded by rules and policies
• Support of stateless management functions
• Design for resilience
• Functional abstraction
Designed for closed-loop automation and optimized for
data-driven machine learning and artificial intelligence
algorithms
Next-Generation Closed-Loop Automation | IEEE IM 2021 Tutorial May 2021
52

ETSI ZSM Architecture II
● ZSM service aka Management Service:
A set of offered management capabilities.
● Management function:
Logical entity playing the roles of service consumer and/or
service producer.
● Integration fabric:
A management function that enables interoperation and
communication between management functions within and across
management domains.
● Cross-domain data services:
Services that allow to share data with authorized consumers
across domains.
● Management domain:
A scope of management delineated by a technological, business,
administrative or other boundary.
● E2E service management domain:
A management domain specialized to manage E2E services.
May 2021
53

Separation of concerns in management
E2E Service Management Domain
• Manages E2E services that span multiple management
domains
• Provides and consumes management services
• Coordinates between management domains
Management Domain
• Scope of management delineated by e.g.
technological or organizational boundaries
• Manages resources and services
• Provides management services and decouples the
inner domain details from the outside world
• Can consume management services from other
management domains
May 2021
54

Integration fabric
The integration fabric allows management service (MnS) interoperation and communication
● MnS communication asynchronous or synchronous, e.g. event notifications and streaming data
● MnS registration and discovery
● MnS invocation, including support for service meshes (direct invocation also possible)
● MnS exposure management and access control
May 2021
55

Cross-domain data services
Examples of shared data related to managed entities:
● performance monitoring data (e.g. performance
counters)
● assurance data (e.g. performance/fault alarm events)
● trace data (e.g. packet capture data)
● configuration data
● miscellaneous log data
● network/service topology data
● network/service inventory data
Cross-domain Data Services allow
● Storing of management data
● Sharing of management data with authorized consumers across domains
● Supporting big data analysis
Data are the lifeblood of automation
May 2021
56

Closed Loop in the ZSM framework - Functional view
Monitoring
Analysis Decision
Execution
Knowledge
Managed entity
M2A
K2
K1
data
K4
K3
A2D
action
D2E
E2M
This represents:
Managed resource, or
Managed service, or
Closed loop
E4
E3
E2
E1
E5
PRESENTER: Pedro
DURATION:
---
May 2021
57

Closed Loop in the ZSM framework - Services view
Orchestration MnS
Automate workflows to handle
lifecycle management of the
managed entities
Control MnS
Individually steer the state
of managed entities
(resources and services)
Intelligence MnS
Provide specific decisions and
recommendations
AI models / Policies & Intents
Data Collection MnS
Monitor the managed entities
(resources and services) and provide
live performance and fault data
Analytics MnS
Provide insights based on
collected data
Monitoring
Decision
CL
Analysis
Execution
May 2021
58

Closed Loop in the ZSM framework - Deployment view
May 2021
59
(E2ES) Management Domain
data action
managed
entities
Domain Integration Fabric
CL instance
(Domain or E2E) Data
Collection
Monitoring
(Domain or E2E)
Data Services
Knowledge
(Domain or E2E)
Orchestration & Control
Execution
(Domain or E2E)
Intelligence
Decision
(Domain or E2E)
Supporting
Governance & Coordination
(Domain or E2E)
Analytics
Analysis

Closed loops within the ZSM framework
Closed Loops at:
● E2E Service Management
domain
● Management domains
● Across management domains
New management services specific
to Closed Loops:
● Closed Loop Governance
● Closed Loop Coordination
More details in Parts II and III
May 2021
60

Closed loop as an entity
2 mandatory categories of management services externally visible:
● Closed Loop Governance
● Closed Loop Coordination
May 2021
61

May 2021
62
End of
Next-Generation Closed-Loop Automation | IEEE IM 2021 Tutorial * All times are CEST

May 2021
63

May 2021
65
Part II

Closed Loop
Governance
Part II-A
May 2021
66

Concept - Management Service
Management Capability: A functionality provided to you - example: get something configure
something, create something…
Management Service: A collection of capabilities provided to you
Management Service Producer: An implementation of a specific management service
Management Function: An implementation of one or more management services and or
consumers of services
Managed Entity: the resource being managed
Management domains: Any collection of resources that has its own management service
implementation - think geographical, administrative, technological...
May 2021
67

Closed Loop Governance
Closed loop Governance is the set of capabilities that allow external entities to manage
the life cycle and to configure the behaviour of the closed loops.
Governance can also be used to retrieve information about the status and performance
of the closed loop.
Types of capabilities:
● Management of the lifecycle of the CLs
● Management of CL models
● Configuration of policies, rules, triggers and priorities for the closed loops;
● Conveying status and performance information of the CLs.
Closed loop governance can be done by authorized entities inside or outside the
management domains where the CLs are running
May 2021
68

Lifecycle management of closed loops
May 2021
69

70
Preparation
• Closed loop design
• Result is an artifact
that described the
CL
• Artifact should be
based on the CL
model (Part III)
Commissioning
• Closed loop is
instantiated
• Creation and
registration of the
closed loop
• Optionally, the creation
and registration of the
CL stages
• Association of existing
CL stages is possible
• Configuration of CL
parameters
Operation
• Closed loop is
activated
• May include
subscription to
relevant
communication
channels
• Optional activities:
monitor, evaluate,
update & upgrade
• Deactivation to
stop the execution
Decommissioning
• Closed loop is
terminated and
does not exist
anymore as an
entity within the
management
framework
• The management
functions,
however, may still
exist
May 2021
70

Closed Loop Governance Service
May 2021
71

Closed Loop Goal Configuration
MD 1 MD 2
E2E MD
Goal set
Goal translated
Translated goal set
Before setting there should be
a check for feasibility
May 2021
72

Building Trust in CLs
• Building trust in Closed loop operation
• Logging CL activities
• Enabling pause points
May 2021
73

Pause points example implementation
May 2021
74

ZSM Closed Loop types
75 May 2021
75
Visibility
Composability
Dis-aggregated,
Made-to-Order CL
Integrated,
Made-to-Order CL
Integrated,
Ready-Made CL
Dis-aggregated,
Ready-Made CL
Higher standardization needs and value
• Build to order: ability to compose CL
building blocks
Multi-vendor interoperability and flexibility
(at build and run time)
• Tailored operations:
Advanced and dynamic CL control and
capabilities exposure

We need to differentiate between ready-made and made-to-order because they have
different sets of CL requirements
76
Collection
Analytics Decision
Actuation
Managed Entity
Ready-made
closed-loop Made-to-Order
closed-loop
Integration Fabric, ZSM CL
interfaces, etc.
Integration Fabric, ZSM CL
interfaces, etc.
Ready-made:
• Vendor-provided closed loop
• Internal implementation of the closed-loop is proprietary or
not visible to the operator
• Support ZSM interfaces for interaction outside of the loop
• Optimized implementation
Made-to-order
• Closed loop is designed/created by operator, system
integrator, or vendor
• The components/stages inside the loop may be provided by
other vendor(s)
• Standard interfaces between stages
• Configuration capabilities of each stages are defined
• Operator may prefer to use Analytics from vendor A,
and Collection from vendor B, while the close-loop
may be created by a system integrator
• Flexible implementation
76 May 2021
76
Managed Entity

77
Made-to-Order CL
• Assembled on demand using the
capabilities of ZSM framework
• The CL components and their
interoperability are standardized
• LCM phases: Preparation,
Commissioning and Operation
Ready-made CL
• Assembled prior to the use in the ZSM
framework
• The CL components and their
interoperability are proprietary
• External interactions and capabilities are
standardized
• LCM phases: Commissioning and
Operation
May 2021
77

May 2021
78
End of
Part II

May 2021
79

May 2021
81
DEEP DIVE II 4:30 PM - 6:30 PM
A. Closed Loop Coordination
B. Closed Loop Modeling
C. Future Directions
D. Summary of Learnings and Conclusions
Part III

Closed Loop
Coordination
Part III-A
May 2021
82

The need for coordination
May 2021
83
NO or LIMITED COORDINATION
Simple cases managed manually
Ad-hoc solutions: limited scope, not
interoperable
ADAPTIVE INTELIGENCE
Standard-based functionality
Pluggable intelligence
DELIVERING THE FULL POWER OF
AUTONOMIC NETWORKS
Without coordination: inefficient,
unstable networks, difficult to operate
AN OPEN AND RE-USABLE COORDINATION FUNCTION IS A MUST-HAVE FEATURE

May 2021
84
System
A
System B
Metric 1
Metric 2
Metric 3
target function
metric x
target function
metric y
optimization algorithm y
optimization algorithm x
Parameter
1
Parameter
2
Parameter
3
Metric value conflict:
One metric is influenced by
parameters of different
closed loops
Parameter value conflict:
One parameter is modified
by different closed loops
Closed loop x
Closed loop y

Interactions can be:
• Conflict - closed loops interfere negatively with each other
• Cooperation - a closed loop can improve another one
• Dependency - a closed loop cannot work without another one
Interactions are complex to manage by humans because of:
• scale
• speed
• hidden dependencies
Proposal: coordinate collective behavior via a common enabler available
to all CLs
May 2021
85

Sketch of a coordination enabler
• Provides means to achieve local and global stability or convergence
• Is a re-usable functionality i.e., applicable for multi-vendor closed loops
• Is useful for the whole network lifecycle
• Offers multiple strategies to solve different coordination problems
• Can operate with no or limited knowledge and control on the CL internals
• Requires common CL descriptors, CL lifecycle and representation of
information
An essential feature for safe closed-loop operations
May 2021
86

CL Coordination, a ZSM definition
• CL coordination is a set of capabilities that allows multiple CLs to be
coordinated, with the main objective of improving their performance and the
fulfilment of their goals
• CL coordination involves different types of interactions between multiple
closed loops during their run-time
• Coordination of conflicting CLs is an important part of CL coordination
capabilities. Conflicts between CLs can negatively impact their operations.
Conflicts can occur between two or more CLs, involving the same or
different sets of managed entities
May 2021
87

Coordination between hierarchical closed loops
• Closed loops in different
Management Domains that are
hierarchically organized or closed
loops in the E2ES MD that interact
with the closed loops in
subordinate MDs
• In both cases the subordinate
closed loops are responsible for
optimization and self-healing
within their scope, while the
superior closed loops are
responsible for the coordination
and optimization within their scope
May 2021
88

Coordination between hierarchical closed loops
May 2021
89
The subordinate CLs deployed in the E2ES MDs or in the MDs
perform local optimizations which might not result in a global,
end-to-end optimum or which might even be in conflict to each
other. To this end the superior CLs shall be able to coordinate the
decisions of subordinate CLs. Such coordination can happen via
the use of the escalation-delegation pattern:
• Delegation - The superior CLs delegates respective goal(s) to
the subordinate CLs, e.g. by setting the policies and/or the
intents in a way that allow the subordinate CL to act
autonomously.
• Escalation - If a subordinate CL is not able to achieve the
goal(s) assigned to it, it escalates the situation to the superior
CL in the E2ES MD.

The Escalation – Delegation pattern
• The escalation – delegation pattern is a powerful means to address and
organize:
• management and control hierarchies
• Problem remediation
• Scalability and performance
• Separation of Concerns
• Autonomous Operation
• Communication of marching orders
May 2021
90

Coordination between peer closed loops
CLs in the different MDs may benefit from
exchanging information to cooperate in achieving
a common objective.
However, peer CLs may perform local operations
which might be in conflict to each other. They can
also request the resolution of issues within their
local scope that could be resolved by another
peer CL. Such coordination can happen in the
following way:
• Cooperation – Two or more peer CLs that are
aware of each other can exchange their
goal(s), their model(s) or other pieces of
information.
Based on this information, the peer CLs can
adjust their own behaviours to achieve a
common objective and avoid conflicts.
A CL can also request a peer CL to assist in the
resolution of an issue.
May 2021
91

High-level requirements for CL coordination
May 2021
92
To address different situations and coordination needs of the different closed loops, coordination
capabilities may include among others:
• Capability to align goals of individual closed loops sharing a given scope
• Capability to identify different interaction types between closed loops such as cooperation, conflict
or dependency
• Capability to identify different types of conflicts between closed loops such as parameters conflict,
metrics conflict, or indirect conflict
• Capability to address the different interactions between closed loops with adequate mechanisms,
such as conflict resolution mechanisms
• Capability to identify before the execution of a proposed action of closed loop that such an action
may cause undesired effects to other closed loops or to managed entities (e.g. pre-execution and
post-execution coordination, concurrency coordination…)
• Capability to evaluate the impact and effectiveness of closed loops actions after their execution (e.g.
impact assessment)

CL coordination services
May 2021
93
Domain Integration Fabric
Governance Collection Analysis Decision Actuation Knowledge
Closed Loops Coordination Services
Goal
coordination
Pre-execution
coordination
Interaction
identification
Other CL
coordination services
Governance Collection Analysis Decision Actuation Knowledge
Governance &
Coordination
Monitoring Analysis Decision Execution Knowledge
Closed
loops
Concurrency
coordination
Impact
assessment

Typical timeline of CL coordination services
May 2021
94
The closed loop coordination services can interact with each other in different
ways and at different times
Monitoring Analysis Decision Execution
Pre-execution coordination
T1 T2
Post-execution coordination
Action(s)
CL instance A
Monitoring Analysis Decision Execution
Action plan(s)
Action(s)
CL instance B
ME2
T3
Concurrency coordination
Action plan(s)
Impact assessment
T4
T0
ME1
ME3
Data
Data
Goal coordination
Interaction identification
Action enabling/disabling

Interactions identification
May 2021
95
• Closed loops interactions identification determines
and characterizes the interactions that may exist
between two or more CL instances. The
interactions identification service may be used by
other CL coordination services designed to manage
or arbitrate the coordination between CL instances
and that need to know beforehand if interactions
exist and, optionally, other information about the
interaction(s), and details on CL instance attributes
involved in the interactions, etc
• Interactions identification typically occurs when
new closed loops are instantiated, or when other
coordination services require information about
interactions between given closed loops. Those
occurrence times are represented as time T0

Goal coordination
May 2021
96
• Given the potentially high number and diversity of
closed loops, the operator may want to automate
this process of setting and coordination goals for
the closed loops.
This process includes the negotiation phase among
the closed loops in the cases where one closed
loop actions may hinder another closed loop from
reaching its targets
• Goal coordination may also use information from
other services such as the impact assessment
service (next slide) to gain additional knowledge
and a broader understanding on how goal
alignment between closed loops could be achieved
• Goal coordination typically occurs when new
closed loops are instantiated or when other
coordination mechanisms cannot achieve to
address long-term dependency between closed
loops interactions, thus requiring (re-)alignment of
their goals. Those occurrence times are
represented as time T0

May 2021
97
• Pre-execution coordination refers to the
management of interactions between closed loops
before the triggering of the Execution stage,
typically occurring at time T1.
Pre-execution coordination is responsible for
optimizing the effects of actions taken by
interacting closed loops.
• Interacting closed loops and/or the closed loops
coordination functionality receive one or more
action plans.
The action plans are provided prior to their
execution by the interacting closed loops. Pre-
execution coordination relies on capabilities for
identifying conflicts and for determining which
combination of action plans contributes best to the
coordination goal

May 2021
98
Action plans conflict detection
• If executed without coordination, actions taken by
interacting closed loops may cause undesirable effects on
the managed entities. To avoid such detrimental
situations, the Pre-execution coordination service is used
to detect conflict before the interacting closed loops
execute their actions. The conflict detection works as
follows:
1) Retrieve the action plans which contain the information of
target resources and scheduled time for execution
2) Check if there are any conflicting actions based on the
provided information
3) Notify the detected conflict(s) to the related closed loops
and/or the closed loops coordination functionality

May 2021
99
Action plans selection
• The Pre-execution coordination service is used to select
the most appropriate combination of action plans to be
executed.
• The most appropriate combination of action plan(s) can
be evaluated by multiple means and by using, for
instance, historical data and/or operational data. This
service can be used to address the detected conflicts
identified as well as the non-conflicting action plans
provided by the interacting closed loops. The action
plans selection works as follows:
1) Retrieve the action plans which contain the information of
target resources, scheduled time for execution, and other
additional information such as historical results of the
proposed actions
2) Assess each plan and choose the most appropriate
combination of action plan(s) based on the selection policy
3) Notify the selected action plan(s) to the related closed
loops and/or the closed loops coordination functionality

May 2021
100
Post-execution coordination refers to the management
of interactions between closed loops after the triggering
of the Execution stage, and typically spans between
times T2 and T4.
Post-execution coordination is responsible for ensuring
that all actions that are executed result in positive
outcomes and any actions that do not are identified and
flagged as such

May 2021
101
Action enabling and disabling
• Coordination amongst closed loops may require
disabling actions (actions are changes that a closed
loop can perform over a managed entity such as
configuring an attribute) of a closed loop. Action
enabling or disabling typically occurs at time T2

May 2021
102
Concurrency coordination
• Concurrency coordination ensures that the actions
of CL instances that have managed entities in
common are applied consistently and in accordance
with the operational policies, rules, or decision
criteria. A typical example is to compare the value
assigned to the closedLoopPriority attribute of the
CL instances under coordination to decide in which
order the CL instances action(s) should be executed
on the shared managed entity
• Concurrency coordination orchestrates access
control to managed entities and avoids race
conditions. For example, if two or more CL instances
decide on actions resulting in different changes to
the same managed entity(ies) at the same time, the
concurrency coordination can identify the issue and
decide which of the CL instances can proceed with
the execution of its action.
• Concurrency coordination typically occurs at time
T3

May 2021
103
Impact assessment
• Impact assessment allows evaluating the direct and indirect effects of
CL actions, and determining remediation measures to cover the
following cases:
- For some closed loops, the scope of the action (be it in time, space, or
network function) may not be known a priori, either by the closed loop itself
or the closed loops coordination functionality. Correspondingly, any
negative effects cannot be easily anticipated and most importantly, they
may not be easily resolvable by simple if-then-else rules. However, post-
execution coordination must still be able to identify actions that lead to
negative outcomes and flag them accordingly.
- For some closed loops, the expected, bounded scope of the action may be
known either to the closed loop itself or to the closed loops coordination
functionality. In some cases, even if not specified such scope may be easily
derived from the description of the command(s) that are executed in the
action.
In the above situations, the post-execution coordination should evaluate a
wider scope and rely on the additional information (e.g. knowledge gained
from other closed loops) to:
1) Determine if there are unwanted outcomes
2) Diagnose if the executed action(s) is/are responsible for those outcomes,
especially for the case where multiple closed loops have concurrently taken
actions, and
3) Determine what needs to be done to undo the degradation and to avoid it
in future
Impact assessment typically occurs at time T4

Issue escalation – Goal delegation
104 May 2021

In addition, knowledge sharing
105
• In case of delegation the new CL
could access knowledge from
the old CL
Knowledge
flow
May 2021

Limiting CL actions
106 May 2021

Conflict Detection
107 May 2021

Closed Loop
Modeling
Part III-B
May 2021
108

Closed Loop models
109
• Meta models used for different closed
loop instances
• Can be applied to different phases of the
lifecycle management
May 2021

Closed Loop
class
110
• Closed loops
shall have at
least one goal
• At least one
managed entity
• One or more
closed loop
components (CL
stages,
knowledge)
May 2021
Attribute name Description and properties
closedLoopInstanceUniqueId
- Mandatory
- Multiplicity: 1
It indicates the identifier of the CL instance.
closedLoopLifeCyclePhases
- Mandatory
- Multiplicity: 1..4
It indicates the list of supported lifecycle phases of this CL type.
Allowed values are Preparation, Commissioning, Operation, and Decommissioning.
currentClosedLoopLifeCyclePhase
- Mandatory
- Multiplicity: 1
It indicates which CL life cycle phase the CL is in.
closedLoopPriority
- Mandatory
- Multiplicity: 1
It indicates a priority of the CL.
It is set to avoid conflicting actions to the same managed entity.
closedLoopTypeDescription
- Optional
- Multiplicity: 1
It indicates a description of the CL type.
closedLoopGoal
- Mandatory
- Multiplicity: 1..N
It indicates goals of the CL.
manageableEntityList
- Mandatory
It indicates the types/categories of entities that can be managed by the CL.
Entities are not instantiated entities, but categories/types/classes or range of
products/elements.
targetEntityList
- Mandatory
It indicates the entities that the CL instance will have to manage after being successfully
deployed/instantiated.
closedLoopComponentList
- Mandatory
It indicates the composable unit of CL, e.g., CL stages and knowledge.
closedLoopPolicy
- Mandatory
Defines policies applicable to the CL instance.

Closed Loop goal
111
closedLoopGoalId
- Mandatory
- Multiplicity: 1
It indicates the identifier of the CL instance goal.
closedLoopGoalDescription
- Mandatory
- Multiplicity: 1
Describes the closed loop goal.
Description of the closed loop goal statement in a human-readable form.
closedLoopGoalStatement
- Mandatory
- Multiplicity: 1
The closed loop goal statement can be a declarative or an imperative statement.
The declarative statement of a CL goal is an intent that expresses the
expectations to be met by the CL, including requirements and constraints.
The imperative statement of a CL goal is a service level specification that
expresses the minimum acceptable standard of service to be met.
While closedLoopGoalDescription is in a human-readable form, the
closedLoopGoalStatement shall be in a machine-processable form.
● Determines the
objective a CL shall
meet
● At the preparation
phase, it is set by the
vendor, operator, or
authorized entity
● Multiple goals may
be set
● At the operation
phase, changes are
allowed to select the
current goal, or to
configure the values
of the parameters
May 2021

Closed Loop component
112
closedLoopComponentDescription
- Optional
- Multiplicity: 1
Describes the functionality of the closed loop component in a human-readable
form.
inputDataList
- Optional
Lists the mandatory and optional information the closed loop component can
receive from other entities internal or external to the closed loop.
outputDataList
- Mandatory
Lists the information the closed loop component can provide to other entities
internal or external to the closed loop.
producedManagementCapabilitiesList
- Mandatory
Lists the capabilities offered by the closed loop component for consumption by
authorized entities.
consumedManagementCapabiltiesList
- Mandatory
- 1..N
Lists the capabilities consumed by the closed loop component for its
functioning.
● Management
functions utilized
by the closed loop
to realize its
operation
● MnF for CL stages,
knowledge, CL
governance and
CL coordination
are examples of
CL components
May 2021

Managed entity
113
• The managed
resource,
managed
service or
managed
closed loop
managedEntityId
- Mandatory
- Multiplicity: 1
It indicates the identifier of the managed entity.
managedEntityType
- Optional
- Multiplicity: 1
It indicates a type of managed entity. Allowed values are managed resource,
managed service, or closed loop.
May 2021

Future
Directions
Part III-C
May 2021
115

Cognitive Closed Loops
May 2021
116
Control loop incorporates ML at each
stage [1]
• C-Monitor: performs intelligent probing
• C-Analyze: detects and predicts changes in
networks
• C-Plan: automated planning engine to react to
changes
• C-Execute: Optimal scheduling for plan execution
[1] S. Ayoubi, et al. Machine Learning for Cognitive Network Management.
IEEE Communications Magazine. 2018

May 2021
117
Closed Loop
Regular data
sources
On-demand
data sources
Continuous data
collection (streaming)
Request data (trigger
measurement)
Provide data
Dynamic interaction with data sources
Closed Loop
with multiple analytics models
Analytics
Model 1
Analytics
Model 2
Regular data
sources
On-demand
data sources
Closed Loop
Analytics
Model 1
Analytics
Model 2
Regular data
sources
On-demand
data sources
Closed Loop
(a) (b)

May 2021
118
• Closed Loops autonomously adapt their
operation to varying environments, collect
operational knowledge and autonomously
learn from their experience.
• Such self-learning capability complements
external CL supervision when an entity outside
of the CL evaluates the performance of a CL
and may adapt the CL’s operation

Adaptive automation
May 2021
119
Adaptive automation is the dynamic and informed
allocation of management functions between humans and
machines [2]
Key issues
• Who decides when the control of function must be shifted?
• Which adequate criteria to determine functions
(re-)allocation, how, and when
Levels of Automation and Supervision
• Apply to four primary functions of the closed loop
Appropriate and individual setting for each function
• Different scales have been proposed for the LoA
• Operator defines LoS when and for what she must be “in the loop”
e.g., What information shall be reported/recorded and when
e.g., Quarantine, test modes…
[2] T. Inagaki. Adaptive Automation: Sharing and Trading of Control. In
Handbook of Cognitive Task Design. 2003

Adaptive automation
May 2021
120
• LoA/LoS for individual elements vs. composite/domain/cross-
domain LoA/LoS
– What are the "right" granularities to consider, how to "compose"…
– How "transitive" are the LoA/LoS?
– How harmonized should it be…?
– How to discover and configure such capabilities, in multi-vendor context…?

Intent-driven closed loop operations
May 2021
121
e2e Service Operations
Service
Deployment
Service design
& Onboarding
Customer Experience
Business Intent
Service
Monitoring
Service
Intelligence &
Monetization
Service
Assurance
Core Domain
Network
Intelligence
Resource
Assurance
Resource
Control
Resource
Orchestration
Transport Domain
Network
Intelligence
Resource
Assurance
Resource
Control
Resource
Orchestration
Access Domain
Network
Intelligence
Resource
Assurance
Resource
Control
Resource
Orchestration
Business Service creation
1
X-Domain Service
Orchestration
Domain
Adaptation
2
3 3 3
Source:
Nokia
1
2
3
Service lifecycle management
loop
• Driven by dynamic business
needs
• Spanning multiple levels and
domains in the architecture
Service operation loop
• Customer experience mgmt.
• e2e network slice
management
• SLA enforcement
Network domain loop(s)
• Fault management
• Performance optimization
• Security attack mitigation
• Resource optimization and
configuration

Summary of
Learnings and
Conclusions
Part III-D
May 2021
122

Key take-aways
May 2021
123
• Automation megatrend
• Closed loops as central enabler
• Standards matter
• Emergence of CL operation framework(s) encompassing
– CL Governance
– CL Coordination
– CL Modeling
• Only “scratched the surface…“

Closed Loop Automation in ETSI ZSM
May 2021
124

Get Involved !
Zero Touch Network &
Service Management (ZSM)
Website:
https://www.etsi.org/technologies/zero
-touch-network-service-management
May 2021
126
Open area:
https://docbox.etsi.org/ISG/ZSM/Open

Contact
Information
linkedin.com/in/laurentciavaglia
Laurent
Ciavaglia
linkedin.com/in/ishan-vaishnavi-9227413b/
Pedro Henrique
Gomes
linkedin.com/in/pedrohenriquegomes
Ishan
Vaishnavi
THANK YOU!
May 2021
127

IEEE IM 2021 Tutorial - Next-generation closed-loop automation - an inside view

More Related Content

What's hot (12)

Similar to IEEE IM 2021 Tutorial - Next-generation closed-loop automation - an inside view (20)

Recently uploaded (20)

IEEE IM 2021 Tutorial - Next-generation closed-loop automation - an inside view