ETSI GS AFI 001 V1.1.1 (2011-06)

Autonomic network engineering for the self-managing Future Internet (AFI); Scenarios, Use Cases and Requirements for Autonomic/Self-Managing Future Internet

DGS/AFI-0001

General Information

• Status: Published
• Publication Date: 28-Jun-2011
• Technical Committee: AFI - Autonomic network engineering for the self-managing Future Internet
• Current Stage: 12 - Completion
• Due Date: 22-Jun-2011
• Completion Date: 29-Jun-2011

Standards Content (Sample)

Group Specification
Autonomic network engineering for
the self-managing Future Internet (AFI);
Scenarios, Use Cases and Requirements for
Autonomic/Self-Managing Future Internet
Disclaimer
This document has been produced and approved by the Autonomic network engineering for the self-managing Future Internet
(AFI) 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 AFI 001 V1.1.1 (2011-06)

Reference
DGS/AFI-0001
Keywords
Autonomic Networking, Cognition, OAM, ontology,
Self-Management
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
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
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS AFI 001 V1.1.1 (2011-06)
Contents
Intellectual Property Rights . 4
Foreword . 4
1 Scope . 5
1.1 Global description background. 5
1.2 AFI Methodology . 6
1.3 AFI Process & Roadmap . 7
1.3.1 AFI Process . 7
1.3.2 AFI Roadmap. 7
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definitions and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 11
4 AFI's Requirements for an Autonomic Network . 12
4.1 Current NGN network . 12
4.2 Future network vision . 13
4.3 Operator's requirements . 13
4.4 Management requirements . 14
4.4.1 Network management driven by players . 14
4.4.2 Requirement framework for a Policy- based management . 16
4.4.3 Operator's Policy-based autonomics network vertical framework (cross-layer) . 18
4.4.4 Operator's Policy-based autonomics network horizontal framework (cross-domain). 21
4.5 AFI Requirement template . 22
4.6 AFI high level Requirements. 23
5 Use Case & Scenarios . 37
5.1 Use Case & Scenario Template . 37
5.2 Autonomic in legacy network (NGN) . 38
5.3 Auto-Configuration of Routers using Routing Profiles in a Fixed Network Environment . 39
5.4 Self-Management of Coverage and Capacity in Future Internet Wireless Systems . 40
5.5 Cognitive event management (Fault/Anomaly/Intrusion Detection) . 42
5.6 Coordination of Self-* mechanisms in autonomic networks . 44
5.7 Autonomic Network Monitoring . 45
5.8 Scenarios Overlay Virtual Network Service Breakdown . 47
5.9 Scenarios Overlay Virtual Network Service Quality Degradation . 50
5.10 Monitoring in Carrier Grade Wireless Mesh Networks . 53
5.11 Network self-management based on capabilities of network behaviours as described to the overlying
OSS processes . 55
5.12 Scenarios, requirements and references relationship . 56
Annex A (informative): Authors & contributors . 57
Annex B (informative): Acknowledgements . 58
Annex C (informative): Bibliography . 59
History . 60

ETSI
4 ETSI GS AFI 001 V1.1.1 (2011-06)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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 (http://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.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group Autonomic network
engineering for the self-managing Future Internet (AFI).
ETSI
5 ETSI GS AFI 001 V1.1.1 (2011-06)
1 Scope
The present document contains a description of scenarios, use cases, and definition of requirements for the
autonomic/self-managing future internet based on a Top-down & Bottom-up methodology and related master templates
we defined as a dedicated tool. Scenarios and use cases selected in the present document reflect real-world problems
which can benefit from the application of autonomic/self-management principles. This list will be enriched and
extended with new set of scenarios and use cases in the next release.
1.1 Global description background
As network operators need to address numerous issues such as deregulated markets, open competition, explosion of
digital services, converged fixed-mobile services, converged IT-Network (Virtualisation, Clouds) and operation
efficiency, they are facing new business and technical challenges. Consequently, they are striving to build a new
ecosystem comprising end-to-end solutions, created through strategic alliances within the telecommunications sector
including third parties MVNO/MVNEs, competitors becoming partners (Radio infrastructure sharing or "RAN Sharing"
agreement, for instance), Clouds Services Providers, Virtual Network Providers, consumers becoming content
producers, outsourcing partners, integrators. For this reason the networks they are operating and the associated OSS
(Operations Support System) must be intelligent, agile, open, secure, flexible and autonomic (i.e. operating with
minimum human intervention).
As driving forces from the network evolution perspective, we can highlight the deployment of key emerging
technologies such as IP Multimedia Subsystem (IMS) / Next Generation Network (NGN), Long Term Evolution (LTE)
/ Evolved Packet Core (EPC), Future Internet, Internet of Things, Machine to Machine, IaaS/NaaS/CaaS (Infrastructure,
Network, Communication as a Service) etc. The underlying network architectures, so called "flat architecture" will
increase the amount of equipments required while at the same time the major operators' requirement is to lower
operating costs (OPEX).
That means, some level of the notion of being "autonomics" should be embedded into network equipment and OSS at a
first phase for the configuration purpose, but Future Network infrastructure should incorporate more and more
autonomic features in order to maintain operational costs under control when it comes to a large scale deployment
phase. The same should be also applicable during the "operation phase" and "optimisation phase", all lifelong of the
network. This needs embedding Self-optimisation, Self-Healing features. In this context, requirements aiming at
building Trust & Confidence on these Self-functions, in one hand, and the coordination of interaction of various
Autonomics functions in the other hand, must be implemented in order to ensure a global optimum while targeting a
local optimum per Autonomics function activated through the same optimisation parameter. Without this coordination,
we could not prevent the fact that some parameters can lead to the optimisation of one Autonomics function while at the
same time, it negatively impacts another Autonomics function. This results in an unstable behaviour of the network.
That means, the coordination of interaction of Autonomics functions deployed in a network is a major requirement as
well from operators' perspective. In case of failure of an Autonomics function, a process must be specified and designed
to allow the operator to keep control of the management of the network through its OSS and related tools by
desactivating a given autonomics function as long as a solid Trust & confidence has not being built.
Currently, there is a lot of work being carried out on autonomics, mostly conducted by the research community but from
the operational point of view there is little common understanding on how autonomic technologies can help and how
they will impact current operation models of the operators. There is a need to build a new management environment
that can definitely contribute to the efficiency of business units and reduce OPEX. Autonomics and Self-Management
related technologies are envisioned as the solution for a player to control its own environment and at the same time
assuring the end to end view, which emerges from the individual behaviors of all the players.
Work Item 1 focuses on the set of requirements for Autonomic and Self-Managing Future Networks to efficiently help
the operator to face new market realities and on the definition of the operational requirements for operators to take
advantage of such advanced infrastructure. The Operational Model is far beyond the classical centralized management
approaches, looking for innovative methods for controlling and managing distributed decision making functions
embedded in an autonomous and intelligent infrastructures.
Work Item 1 establishes a framework for "Scenarios, Use Cases and Requirements for the Self-Managing Future
Networks" contributed by Network Operators and other players such as content providers, etc into this AFI
Specifications. This framework is based on Templates and Tables.
ETSI
6 ETSI GS AFI 001 V1.1.1 (2011-06)
1.2 AFI Methodology
Figure 1 depicts the AFI Top-Down & Bottom-up Methodology. This methodology is composed of two horizontal
layers, high level "operators' requirements, use cases and scenarios" at the bottom and "Generic Autonomic Network
Architecture" (GANA), interconnected at the top, with each other to show that some input flows from one process to the
other.
A vertical layer provides inputs and enablers in terms of "Use Cases" for the bottom layer and "GANA" for the top
layer. In this vertical layer we gather outcome provided by the AFI's stakeholders (research community, operators'
experience, vendors' experience, customer quality of experience, etc.
The outcome will be the definition of an "Implementable Autonomic Network Architecture" (IANA) composed of
Autonomic functional blocks, reference points, Info Models/Data Models and associated implementation neutral
specifications.
Figure 1: AFI Top-Down & Bottom-up Methodology
In order to meet the operators requirements will be defined, we need to instantiate this "Generic Autonomic Network
Architecture" by applying its prescribing "generic autonomicity and self-management concepts and principles" into an
existing network architecture such as the NGN architecture. The result of this instantiation of GANA is an
"Implementable Autonomic Network Architecture" (IANA) as a production network in the short-term, and evolves into
the mid-term and then long-term.
To achieve this goal, the inclusion of operators' operation requirements in this "GANA" is required. That means, which
reference point should or shall be translated into interface. And which Information Models and Policy Frameworks
should be translated into related rules, data models and protocols (syntax, semantic) from implementation point of view.
This is linked to the choice of the right and cost effective ones from integration point of view in the OA&M/OSS
systems.
This results in the "AFI pre-standard" based in what we named "Implementable Autonomic Network Architecture" as
the major AFI deliverable.
Besides, this instantiation will map the "GANA" on to the hierarchical management architecture at network level,
service level and policy management level of an existing architecture, will result in an "Autonomic architecture" when
the "generic autonomicity and self-management concepts and principles" prescribed by the GANA are applied by fusion
with an existing architecture in use by the industry.
ETSI
7 ETSI GS AFI 001 V1.1.1 (2011-06)
These instantiations or mappings must be driven by operators' use cases. The industry (Equipment suppliers, the OSS
vendors) will play a major role as well.
In this context, end to end inter-domain issues are also treated when it comes to deliver end to end service through
numerous networks or sub-networks (in the case of partioning). Besides, building trust and confidence on the
"Implementable Autonomic Network Architecture" by designing test and validation framework is a major topic of this
AFI Methodology.
1.3 AFI Process & Roadmap
1.3.1 AFI Process
Figure 2 depicts the different steps of the AFI process. It shows strong relationship between the three work items
structuring the AFI work so far. AFI WI#1 specification describes high level operators Requirements, Use Cases and
Scenarios. These requirements are used as input toWI#2 which is in charge of specifying the "Generic Autonomic
Network Architecture".
WI#3 will map and instanciate the GANA to current networks based on scenarios described in WI#1 and by refining the
high level requirements and including operation requirements. The outcome is transforming an existing architecture into
an "Autonomic architecture" or "Autonomic-Aware architecture".
RReesulsultts:s: im improvprovementement of of AFI specAFI specificificatiatioonn
WorkWork iittem 3em 3
ImImplemenplementabletable AAutonoutonomicmic NNetetwwoorrkk
WorkWork Item 1Item 1
ArArcchhiitteeccttuurree ( (IIANANA)A)
HHiigh lgh leevevel Ol Operaperattors ors RequRequireiremmentents, s,
MappiMapping anng and id immplemeplemenntingting o off AFI AFI
UUsse Ce Caaseses & s & SceScenariosnarios
AutonomAutonomicsics R Reeffeerence rence MoModeldel (G (GANA) tANA) too
CurCurrrentent Ne Nettwwoorrksks
-- IInsnstanttantiation iation ofof Re Referenceference m model odel to Nto NGGN N
-- IIntntegration of egration of AutAutonomiconomics fus functinctions in ons in
NGNGN N architarchitectectuure,re, Ad hoc Ad hoc, …, …
WorkWork Item 2Item 2
GGenericeneric AutoAutonomnomicic NetNetwworkork -P-PooCC (e(egg SSupuppoportrt/s/spponsonsor fror from Eom ETTSSII//TTIISSPPAAN NN NGGN N
plplatatffoorm)rm)
ArArcchhitecitecture (Gture (GANA)ANA)
-- TTesest st suuite ite & valid& validation ation camcamppaign & aign &
-- PPlug-Tlug-Teestst & Conf & Conformancormance e (AFI (AFI Logo Logo
PrProoggram)ram)
ResResuultslts:: im improvprovementement of of AFI sAFI specifpecificatiicatioonn

Figure 2: AFI process
In order to consolidate this transformed architecture, conformance tests and validation framework is specified in order
to build trust and confidence in the AFI specification. This validation process is used for improvement purpose of the
AFI specification and could also be used as basis to creating a kind of "AFI logo label/Certification" if needed.
1.3.2 AFI Roadmap
Figure 3 depicts AFI structure, process, roadmap, and deliverables. In this process, AFI stakeholders provide the input
to the WIs (Work Item) on the one hand, and feedback and adjustment, on the other hand, in order to help bridging the
gap or to create new WIs. Maintenance and updating activity is included in this process as well.
ETSI
8 ETSI GS AFI 001 V1.1.1 (2011-06)
UpdatUpdatee-- MMaaiintntenanceenance
WIWIWIWI 1 1 1 1  WIWIWIWI 2 2 2 2
(2(2000099)) (2(2010100)) (2011)(2011)
WIWI 3 3
AFAFAFAFIIII
RRRReeeequiquiquiquirrrreeeemmmmeeeentntntntssss TTTTrrrransansansansllllatatatatiiiioooonnnn i i i innnnttttoooo
AAAAFFFFI and I and I and I and iiiitttts s s s
ststststakehakehakehakeholdoldoldoldeeeersrsrsrs
UsUsUsUse Cae Cae Cae Casesesesessss
GAGANANA IAIANNAA DDDDeeeelivlivlivliverablerablerablerableeeessss
ScenaScenaScenaScenarrrriiiioooossss
FeFeeedbadbacckk//AAdjusdjustmetmenntt
FeedbacFeedbackk//AAdjdjustustmmentent

Figure 3: Depicts AFI structure, process, methodology, roadmap, and deliverables
2 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
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://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.
2.1 Normative references
Not applicable.
2.2 Informative references
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] P. Horn. Autonomic Computing: "IBM's perspective on the State of Information Technology"
http://www.research.ibm.com/autonomic/, Oct 2001, IBM Corp.
[i.2] IBM: "An architectural blueprint for autonomic computing". Technical report, IBM White paper
(June 2005).
[i.3] J.L. Crowley, D. Hall, R. Emonet: "Autonomic computer vision systems" in J. Blanc-Talon (Ed.),
IE EE Advanced Concepts for Intelligent Vision Systems ICIVS 2007.
[i.4] ITU-T Recommendation M.3060/Y.2401 (03/2006): "Principles for the Management of Next
Generation Networks".
[i.5] ETSI TS 188 001 (V1.1.1): "Telecommunications and Internet Converged Services and Protocols
for Advanced Networking (TISPAN); NGN management; Operations Support Systems
Architecture".
[i.6] TeleManagement Forum TR133-REQ V1.2: "NGN Management Strategy: Policy Paper".
ETSI
9 ETSI GS AFI 001 V1.1.1 (2011-06)
[i.7] "White Paper MUSE Business Model in BB Access" Multi Service Access Everywhere FP6
project http://www.ist-muse.org/Deliverables/WhitePapers/White-Paper-Business-roles.pdf.
[i.8] EC funded FP7 EFIPSANS Project: Exposing the Features in IP version Six protocols
http://www.efipsans.org/.
[i.9] EC funded FP7 CARMEN Project: "CARrier grade MEsh Networks" http://www.ict-carmen.eu/.
[i.10] A Requirement Specification by the NGMN Alliance NGMN Recommendation on SON and
O&M Requirements, NGMN alliance, (2008) http://www.ngmn.org/uploads/media/NGMN-
Recommendation-on-SON-and-O-M-Requirements.pdf.
[i.11] EC Funded Autonomic Computing and Networking: "The operators' vision on technologies,
opportunities, risks and adoption roadmap" P1855 Eurescom.
[i.12] Next Generation Mobile Networks Use Cases related to Self Organising Network, Overall
Description, NGMN alliance, 2007.
[i.13] Autonomic Communication, White Paper, Fraunhofer FOKUS November 2004.
[i.14] IEEE 802.11: "IEEE Standard for Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks - Specific requirements -
Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
[i.15] ETSI GS AFI 002: "Autonomic network engineering for the self-managing Future Internet (AFI);
Generic Autonomic Network Architecture".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Autonomic Behaviour (AB): It is linked to understanding how desired element's behaviours are learned, influenced or
changed, and how, in turn, these affect other elements, groups and network [i.13].
autonomic manager element: functional entity that drives a control-loop meant to configure and adapt (i.e. regulate)
the behaviour of a managed resource e.g. a protocol module or some other type of a managed entity such as a
component, by processing sensory information from the managed resource and from other types of required information
sources and reacting to observed conditions by effecting a change in the behaviour of the managed resource to achieve
some goal
autonomic networking: "new networking paradigm" that involves the design of network devices and the overall
network architecture in such a way as to embed "control-loops and feedback mechanisms" that enable the individual
devices and the networked systems as a whole, to exhibit the so-called self-managing properties, namely:
auto-discovery, self-configuration(auto-configration), self-diagnosing, self-repair (self-healing), self-optimization, etc.
NOTE: The term autonomic comes from the autonomic nervous system, which controls many organs and muscles
in the human body. Usually, we are unaware of its workings because it functions in an involuntary,
reflexive manner - for example, we do not notice when our heart beats faster or our blood vessels change
size in response to temperature, posture, food intake, stressful experiences and other changes to which we
are exposed. And our autonomic nervous system is always working [i.2] Alan Ganek, VP Autonomic
Computing, IBM.
context awareness: property of an autonomic application/system that enables it to be aware of its execution
environment and be able to react to changes in the environment [i.1]
ETSI
10 ETSI GS AFI 001 V1.1.1 (2011-06)
Decision Element (DE): ETSI GS AFI 002 [i.15] produced by WI#2 defines in more detail so-called Decision-Making-
Elements (DMEs) referred in short as Decision Elements (DEs) that fulfil the role of Autonomic Manager Elements,
each of which is designed and assigned to autonomically manage and control some Managed Entities (MEs) assigned to
be managed and controlled by a concrete DE. An ME is a protocol or a mechanism implemented by some functional
entity. A Decision Element (DE) in an "Autonomic Manager Element" implements the logic that drives a control-loop
over the "management interfaces" of its assigned Managed Entities (MEs). Therefore, in AFI, self-* functionalities are
functionalities implemented by Decision Element(s).
GANA (Generic Autonomic Network Architecture): Conceptual Architectural Reference Model for Autonomic
Network Engineering, Cognition and Self-Management, whose purpose is to serve as a "blueprint model" that
prescribes design and operational principles of "autonomic decision-making manager elements" responsible for
"autonomic" and "cognitive" management and control of resources (e.g. individual protocols, stacks and mechanisms)
NOTE: It is not an implementation architecture per se. Refer to ETSI GS AFI 002 [i.15] produced by WI#2 for
more details.
Managed Entity (ME): protocol or mechanism implemented by some functional entity that does a specific job for
which it is designed to perform and can be managed by an Autonomic Manager Element (i.e. a Decision Element) in
terms its orchestration, configuration and re-configuration through parameter settings
overlay: logical network that runs on top of another network
EXAMPLE: Peer-to-peer networks are overlay networks on the Internet. They use their own addressing system
for determining how files are distributed and accessed, which provides a layer on top of the
Internet's IP addressing.
self-advertise: An autonomic entity should be able to advertise its self-model, capability description model, or some
information signalling message (such as IPv6 routing advertisement) to the network in order to allow communication
with it or to allow other entities to know whatever is being advertised.
self awareness: autonomic application/system which "knows itself" and is aware of its state and its behaviors [i.1]
NOTE: Knowledge about "self" is described by a "self-model".
self configuration: autonomic application/system should be able to configure and reconfigure itself under varying and
unpredictable conditions [i.1]
self-descriptive: ability of a component or system to provide a description of its self-model, capabilities and internal
state [i.3]
self healing: autonomic application/system should be able to detect and recover from potential problems and continue
to function smoothly [i.1]
self-monitoring: ability of a component or system to observe its internal state, for example, including such
quality-of-service metrics as reliability, precision, rapidity, or throughput [i.3]
self optimisation: autonomic application/system should be able to detect suboptimal behaviors and optimize itself to
improve its execution [i.1]
self organizing: self-organising function in network includes processes which require minimum manual intervention
[i.12]
self partioning: introducing level of automation within the partioning process
self protecting: autonomic application/system should be capable of detecting and protecting its resources from both
internal and external attack and maintaining overall system security and integrity [i.1]
self-regulation: ability of a component or system to regulate its internal parameters so as to assure a quality-of-service
metric such as reliability, precision, rapidity, or throughput [i.3]
ETSI
11 ETSI GS AFI 001 V1.1.1 (2011-06)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AB Autonomic Behaviour
ABGet Available Bandwidth Get
AC ME Admission Control Managed Entity
AF Autonomic Function
AFI Autonomic network engineering for the self-managing Future Internet
AP Access Point
API Application Protocol Interface
App_DE Application Decision Element
BS Base Station
BSS Business Support System
CLI Command-Line Interface
DE Decision Element
DHT Distributed Hash Tables
DME Decision Making Element
E2E End to End
EMS Element Management System
EPC Evolved Packet Core
GANA Generic Autonomic Network Architecture
HAN Home Area Network
IaaS Infrastructure as a Service
IANA Implementable Autonomic Network Architecture
IDS Intrusion Detection Systems
IMS IP Multimedia SubSystem
IPv4/IPv6 Internet Protocol version 4 or 6
ISP Internet Service Provider
KPI Knowledge Plane Information
LTE Long Term Evolution
MANET Mobile Ad-hoc NETworks
ME Managed Entity
NE Network Element
NGN Next Generation Network
NGOSS New Generation Operations System and Software
NMS Network Management System
NO Network Operator
OAM Operating and Maintenance
OPEX OPeration EXpediture
OSS Operation Support System
OTT Over The Top
OVN Overlay Virtual Network
P2P Peer to Peer
QoE Quality of Experience
QoS Quality of Services
QoS_DE Quality of Service Decision Element
Saas Service as a service
SLA Service Level Agreement
SMS Short Message Service
SOHO Small Office Home Office
SON Self Organising Network
TSPEC Traffic Specification
VNO Virtual Network Operator
WI Work Item
ETSI
12 ETSI GS AFI 001 V1.1.1 (2011-06)
4 AFI's Requirements for an Autonomic Network
Figure 4 depicts the global diagram describing the process and tools used by AFI Work Item 1 for designing "AFI
requirements".
The starting point is capturing autonomic issues and global context from top level in order to shape the current and
Future network vision. This serves as input to formulate operators' requirements from operation view point. The result
is shaping AFI high level requirements thanks to a dedicated template as tool.
From the bottom level, this AFI requirement template is refined by inputs coming from AFI Use Cases & Scenarios
structured within appropriate template as tool.
AFI AFI ccaapptturedured aauutotonomnomicsics Issue Issuess an and glod global cbal contexontextt
4.14.1 4.4.22
CuCurrerrenntt NG NGN nN neettwwoorkrk FFuuturturee n neettwworork vik visisionon
4.24.2 4.4.33 4.44.4
OOppeerraattor'or'ss & oth & otheer Rr Requiequirementsrements
4.4.66
AAFFII r reeququiirrememeennttss
AFI requAFI requireiremmentsents
((AAFFII requir requireement tement template)mplate)
AAFFII r reeququirirememeennttss
((AAFI rFI requiremequirement tement tempplate) late)
AFI RAFI Requequireiremmentsents
(A(AFFII requir requireement tement template)mplate)
(A(AFFII req requuiremeiremennt templt templaatete))
AFI UsAFI Use Cae Cassee & Sc & Sceenarinariooss
AAFFI UI Ussee C Caasese & & Sc Scenaenariosrios
((AAFIFI t teemplmplaattee UseUse Cas Casee && S Sccenarenariiooss))
AFI UsAFI Usee C Caassee & Sc & Sceennaarriiooss
((AAFFII te temmpplalatete UseUse Ca Casese & Sc& Sceennaariorioss))
AFAFI UsI Usee Cas Casee & & ScScenaenaririosos
(A(AFFII te temmppllaatete UUssee C Caasese && S Scceennaarriioos)s)
(A(AFFII Use Cas Use Casee && S Sccenenarariioos s tteempmpllaattee))

Figure 4: AFI process and tools for designing requirements & scenarios
4.1 Current NGN network
Next Generation Network (NGN) is a network architecture that almost all operators are deploying. Within NGN, the
core network is based on IP and multiple access technologies and devices that may coexist alongside this IP core
network. IP connectivity among users is a must. IP Multimedia subsystem (IMS) is the first distributed control service
architecture for fixed/wired and mobile access network. It is deployed to facilitate service convergence.
NGN is the current network architecture for operators to fulfil the requirements that arise from new market realities:
• Open competition (especially in terms of new services deployment, to provide the best QoS, to reduce
prices/costs/OPEX)
• Deregulation of markets (e.g. separation between network and service planes)
• Explosion of digital traffic
• Convergence (fixed/mobile)
• Mobility (inside converged networks, between several networks (Web services))
ETSI
13 ETSI GS AFI 001 V1.1.1 (2011-06)
Next Generation Network (NGN) is defined by ITU-T as a layered network and services architecture using a packet-
based transport network and a unified control layer that is able to provide telecommunication services with QoS over
different broadband access networks [i.4]. NGN supports generalized mobility/nomadic functions allowing consistent
and ubiquitous access to services.

SERSERVVIICCEESS
UMUMTTSS
IInntternernetet
GPRGPRSS
CCoorere
NeNettwwororkk
WLWLAANN
TRANSTRANSPPOORTRT COCONTRONTROLL
FIFIXXEEDD
DDEVICEVICESES AACCCCCCEESSSS
Figure 5: NGN Architecture overview
Network and service decoupling is one of the main NGN concepts. Such decoupling is reflected in the NGN
architecture. As it can be viewed in figure 5, there is a clear separation between Service and Transport layers. NGN
covers different access networks through a common IP core. For NGN, it is necessary to have IP connectivity among
users.
4.2 Future network vision
In the future, processing, storage and communication services will be highly pervasive, intertwined and strongly related
to each other. What we expect is that people, smart objects, machines and the surrounding space will all be embedded
with devices such as sensors, RFID tags, etc., defining highly decentralized dynamic network environments of virtual
resources interconnected by wired and wireless connectivity. Overlay networks will be the major means to organize and
aggregate these highly dynamic communication environments.
Virtualization of resources (from networking to processing to storage, etc) will be a key characteristic of future
networks. As a consequence, autonomic features should support functions such as the creation and maintenance of
overlay networks of virtual resources (for instance autonomic features might be integrated with hypervisors'/VMM's
capabilities).
Networks will evolve towards a broader perspective to include not only connectivity resources but also other types of
resources such as processing, storage and things (e.g. terminals, sensors, actuators, etc.). This is a more holistic and
future proof vision of the network environment (useful for analysing various scenarios/use-cases: from zero-
configuration Home to Cloud Computing, to Content Delivery Networks, etc.).
4.3 Operator's requirements
The scope in this clause is mainly focused on end to end services management from user perspective within an evolved
network. Besides, some operators have to deal with the legacy network that is why we need to seek how to adapt
TISPAN, 3GPP, IMS architectures in order to make the introduction of autonomic functions easier and smoother in
physical, virtualized, distributed centralized resources. Therefore, in addition to user's requirements, a set of technical
and management requirements for operators to deal with an autonomic network have also been captured.
ETSI
14 ETSI GS AFI 001 V1.1.1 (2011-06)
The first step is to introduce a "knowledge plane" in the network taking into account the legacy network on the one
hand, and services (IMS), access (TISPAN, 3GPP,) and home access networks (Broadband Forum reference
architecture, "Authone: Autonomic Home Networking" project, for instance), on the other hand. This knowledge plane
must take into account the constraints of all the actors and security concerns. Data in the knowledge plane must be up to
date and granted. Information from different actors could be shared by context defined by an ontology.
Autonomic features would decide locally based on knowledge retrieved from analysed information of the global
network. Based on such knowledge, local decisions would be taken in respect of end to end or global views,
e.g. configuration of network elements from end to end constraints actors view point, mobility control between different
heterogeneous access network (WiFi, Wimax, 2G/3G/LTE), services adapted to user context.
The following set of requirements defines a set of operational requirements for an operator to control an Autonomic and
Self-Managing Future Network. The requirements have implications on the operational principles of autonomic
components of an autonomic network e.g. federation requirements, information sharing, and other types of desired
behaviours in networks (as described later with figure 7) which illustrate a Policy Management framework.
In this context two views need to be highlighted: "cross layers autonomic views" within an operator's network in one
hand, and "cross domain autonomic view" through various domains in this other hand. (By domain, we mean here
"players" as described later with figure 6).
Indeed, from "cross layers autonomic views", an upper layer "cognition function" is able to retrieve from local views a
situated view of its environment. At a lower layer which embeds an Autonomic Function it becomes possible to retrieve
objectives from upper layers in order to make a decision locally with a global objective, to different layers (as described
later with figure 8).
Regarding "cross domain autonomic view", the cognition functions are used here with the goal to disseminate the
knowledge through various domains (as described later with figure 9). Indeed, each "Autonomic Function" will use this
"cognition function" to react locally with a common objective, to different domains. This horizontal autonomics
architecture is required in order to manage end to end services autonomously if needed (players' agreements, regulation
constraints, etc.).
4.4 Management requirements
This clause gathers the set of operational and management requirements for an operator to deal with an autonomic
network. Starting from users' requirements, a set of operational and maintenance requirements are captured for an
operator to fulfil the quality expectations of users. This work is aligned with the NGN management requirements that
can be found in [i.6] and [i.5] where a first level of requirements (level 0) is composed by:
• Customer centric requirements
• Business vision requirements
• Technology requirements
• Operational requirements
• Regulatory requirements
These requirements were studied in order to understand what is needed for the operation of NGN infrastructures and
how an autonomic network can help to simplify such operation. In fact only the Technology and Operational
requirements are covered here.
The first set of requirements in table 2 is user oriented. Users want to have access to adapted services that they choose
with a guarantee of security & quality. This implies requirements from operators' perspective: OAM requirements.
4.4.1 Network management driven by players
In order to translate end user requirements into technical requirements within the operators' networks, the following
template is used as a guideline. It contains the following fields:
• Players
• Network environment
ETSI
15 ETSI GS AFI 001 V1.1.1 (2011-06)
• Scenario
• What is the requirement
• What need to be automated (this field is more linked to WI 2. It is here only to better understand the technical
requirement)
In order to better capture operators' requirements and map them to the relevant scenarios, the methodology used here is
the partioning of the network of operator we named "Network Environment".
Following is an instantiation of this Network environment concept:
• home area network (SOHO network)
• access network
• regional network
• service platform
• content platform
• ad hoc
• IT platform
• User Network
• Other, etc.
Some of the definitions related to the "player" in the present document are derived from the "Muse" project.
Following is an instantiation of this "Player" concept:
• User Network
• User Service
• Subscriber [i.7]
• Application service provider [i.7]
• Multimedia content provider [i.7]
• Multimedia service provider
• Network connectivity provider [i.7]
• Access network provider [i.7]
• Regional network provider [i.7]
• Network service provider [i.7]
• Internet service provider [i.7]
• Packager [i.7] (operators with different players or make the link with different players (VNO))
• Third party
• Identity provider
• Government (regulator)
• Application developer
• OTT: Over The Top (e.g. Google, Apple, Microsoft, etc.)
ETSI
16 ETSI GS AFI 001 V1.1.1 (2011-06)
• Network outsource actor
• Service outsource actor
• User content provider
• Community service provider
• Network community stakeholder
• Social network stakeholder, etc.
Figure 6 shows player dependencies from a network environment point of view. Network environment management is
driven by the different players of the network. There is no longer one operator that owns the whole network, but a web
of players that offer service and network interfaces to others [i.7]. Autonomic technologies must guarantee that a player
to control their own environment and at the same time assure the end to end view, which em
...