Joint Wokshop with E2NA

© ETSI 2012. All rights reserved

Future topics of interest: some appetizers…13 September 2012, ETSI Premises, Sophia Antipolis

Appetizers on

Federation/ConvergenceService and Network GovernanceCoordination schemesTrust in autonomicsInformation model evolutionEmerging technologies

Federation/Convergence

Feel (operate) like one networkWhat, How and How much to unify?

• Generic framework and reference architectural principles (for management and control)

• Enablers and technology-specific adapters• Seamless deployment

• Over different network technologies• End-to-end, from access to core and service

Service and Network Governance

Profile-based and Policy- based management

Coordination schemes

Challenges: avoid• oscillations between two or more systems states• coupling effects (leading to amplification chains)• concurrency (leading to antagonistic action-reaction)

in a distributed environment composed of self(-ish) managing elements (e.g. 3GPP SON functions)• Two control-loops is “easy”• 3+ becomes “hard”

Coordination: simple example

SON use case a

optimization algorithm a

SON use case b

optimization algorithm b

Metric 1

Metric 2

Metric 3

target functionmetric a

target functionmetric b

Parameter III

Parameter I

Parameter II

Radio system Radio system

Parameter value conflict:One parameter is modified by different SON algorithms

Handover <-> Load balancing

Metric value conflict:One metric is influenced by parameters of different SON algorithms

Interference Coordination <-> Load balancing

Coordination: conflict map

Trust in Autonomics

Operators trust in autonomics as a key steps in the adoption/deployment

CL: Control Loop

CL

Trust in Autonomics

Reliable functioning• Characterize-Test-Verify-Certify the performance and conformance of the

function/system wrt. “referential” (e.g. canonical implementation, behavioral model, requirements, specifications, benchmark)

Trustworthy interworking• Coordination strategies, conflict maps: pre-defined/a priori ; dynamic/run-

time, schemes: static/fixed/dynamic ; centralized/distributed ; concurrent

• Stability/convergence tests, Interoperability Tests

Seamless deployment• Unified operations “feel”, compliance to the framework

specifications/operations, plug and play

Trust in Autonomics

Five requirements and how to meet them:

1. Trust must be measurable (we shall suggest a composite metric for stability, potentially for other measures of autonomicity)

2. Trust must be SON-specific (we shall define a KPI-based envelope of dependable adaptations)

3. Trust must be model-driven (we shall demonstrate how to construct such models based on predicates)

4. Trust must be propagated end-to-end (we shall show that trust networks emerge from predicate-enabled behaviors)

5. Trust must certified (we shall outline the certification process).

Information model evolution

An essential enabler for federation/convergence/unification

Understand and determine the necessary changes to Information model(s)• Distributed systems and reasoning• Semantic• Model-driven design and development

Emerging technologies

Understanding the new/specific requirements of • E.g. M2M, Cloud computing/networking…• Wrt. M2M: numerous, distributed, versatile…• Unique opportunity in ETSI: M2M TC, One M2M

partnership

Applicability and necessary adaptations (incl. framework level)

BACK UP SLIDES

© ETSI 2011. All rights reserved

Envisaged New Work Items: Come Join!

Evolution of Management Systems and Architectures as necessitated by Autonomic Management & Control, Converged Management and Federation

Evolution of Information Models, Data Models, Ontologies and Policy Frameworks as necessitated by Autonomic Management & Control, Converged Management and Federation

Methods and Tools for Knowledge derivation and presentation to the Knowledge

Plane

Definition and Standardization of new types of Managed Objects (MOs) for various types of technologies

Trust and Confidence building in Autonomic Networks

Modeling Methods and Tools for Design, Simulation and Validation of Autonomic Components

Testing, Labeling and Certification of Autonomic Systems: Test Campaigns for Autonomic Behaviours in diverse network architectures and environments 15

Looking at the implications of Autonomics and Self-Management Technology

Introduce Intelligence (“autonomic” and “cognitive” processes) into the node/device architectures as well as within the overall network architecture, to enable Self-Management and Control of Resources.

The architecture of a Network Element e.g. a Router, Switch, an element in the 3GPP/LTE/SAE environment, an End-System, etc, should be enhanced with special types of Functional Blocks and Interfaces for Autonomic Management and Control of resources.

ETSI-AFI developing: A Standardizable evolvable holistic Architectural Reference Model for Autonomic Network Engineering, Cognition and Self-Management: called GANA (Generic Autonomic Network Architecture)can be „instantiated“ onto diverse Architectures to create „Autonomicity-enabled Architectures“ e.g. Autonomicity-enabled BBF arch, Autonomicity-enabled 3GPP, …NGN, FN, etc……

Some of the Management Problems requiring Autonomic/Self-Management Solutions: Deployment and Provisioning; Faults/Failures, Congestions, Predictions and Forecasting, Performance

16

Network Governance, Profiles & Policies

17 17

Policy Semantic Model

Network node

Policy Server

• Policy Edition• Policy Validation (conflict resolution)• Policy Translation to profiles• High level policy repository

– Policy Enforcement– LowlevelPolicyrepository

–Profile distribution mechanisms

GUI

PolicyPublisher

Push Network Profiles toNetwork ONIX

Information Server

Architectural Enhancements and Autonomic Behaviour Specifications for ANY Architecture

Instantiate Functional Blocks and Reference Points for Autonomicity/Self-Management from AFI’s Reference Model onto ANY Architecture and its Management Architecture

Functional Blocks of the Knowledge Plane (Net-Level-DEs, MBTS, ONIX)Network-Level-DEs perform the role of Policy-Decision Points (PDPs) and so PDPs can be evolved by the DEsNetwork-Level-DEs (in the Knowledge Plane) evolve EMSs or NMSsONIX Information sharing/exchange servers facilitate advanced Auto-DiscoveryEstablish the type of Autonomic Functions (Decision Elements and their associated Control-Loops and Managed Entities) that should be instantiated into what type of Network ElementsHow are the Network Elements, EMSs/NMSs enhanced by DEs and the Reference Points instantiated to all the Functional Blocks that are specific to Autonomics/Self-Management

Use the Instantiated Functional Blocks and Reference Points for Autonomicity/Self-Management from the Reference Model, to specify Autonomic Behaviours within the Management and the E2E Transport Architecture

Specify Behaviours of instantiated DEs and their Control-Loops18

AFI comments on Policy Control

Reference Model AFI enables Policy-Control through the Network Governance Interface, as well as facilitating other mechanisms for supporting the Loading of Control-Strategies (executable run-time behavioral models) that can be pushed into the network i.e. into the autonomic manager elements/functions (Decision Elements) by the operator and can be viewed as customized optimization behaviors/algorithms.

Policies are encapsulated by so-called Network Profiles that also convey Goals/Objectives specified by the Operator as well as Configuration Data, and the Profiles are then pushed into the network as input.

There are aspects that cannot be addressed by the operator through Policy-Control and manual human operations but rather require certain Autonomic Decision-making-Capabilities (“some intelligence”) within individual Network Elements and collaboratively across the Fundamental E2E transport architecture, coupled with some predictions and forecasting. Examples include “Autonomic Fault Management and Resilience”, “Autonomic QoS Management”, “Autonomic Security Management”, etc.]

19