ETSI GS ENI 002 V3.1.1 (2020-12)

Experiential Networked Intelligence (ENI); ENI requirements

RGS/ENI-0015_Requirements

General Information

• Status: Not Published
• Technical Committee: ENI - Experiential Networked Intelligence
• Current Stage: 12 - Completion
• Due Date: 21-Dec-2020
• Completion Date: 10-Dec-2020

Standards Content (Sample)

ETSI GS ENI 002 V3.1.1 (2020-12)






GROUP SPECIFICATION
Experiential Networked Intelligence (ENI);
ENI requirements
Disclaimer
The present document has been produced and approved by the Experiential Networked Intelligence (ENI) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

---------------------- Page: 1 ----------------------
2 ETSI GS ENI 002 V3.1.1 (2020-12)



Reference
RGS/ENI-0015
Keywords
artificial intelligence, management, network,
requirements

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
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.

DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GS ENI 002 V3.1.1 (2020-12)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Introduction . 7
4.1 Categorization of the requirements. 7
5 Service and network requirements . 8
5.1 Overview . 8
5.2 General requirements . 8
5.3 Service orchestration and management . 8
5.4 Network planning and deployment . 8
5.5 Network optimization . 9
5.6 Resilience and reliability . 9
5.7 Security and privacy . 10
6 Functional requirements . 11
6.1 Overview . 11
6.2 Data collection and analysis . 11
6.3 Policy management . 11
6.3.1 General policy management requirements . 11
6.3.2 Context aware related policy requirements . 12
6.4 Data learning . 13
6.5 Interworking with other systems . 13
6.6 Mode of operations . 14
6.7 Model training and iterative optimization . 14
6.8 Mode of deployments . 15
6.9 API requirements . 15
7 Non-functional requirements . 15
7.1 Overview . 15
7.2 Performance requirements . 16
7.3 Operational requirements . 16
7.4 Regulatory requirements . 16
Annex A (informative): Change History . 17
History . 18


ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS ENI 002 V3.1.1 (2020-12)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Experiential Networked
Intelligence (ENI).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI

---------------------- Page: 4 ----------------------
5 ETSI GS ENI 002 V3.1.1 (2020-12)
1 Scope
The present document captures the requirements of how intelligence is applied to the network and applications in
different scenarios to improve experience of service provision and network operation. Also, how intelligence enables
dynamic autonomous behaviour and adaptive policy driven operation in a changing context. The ENI requirements are
based on the ENI use case document and identified requirements from other SDOs. These requirements will form the
base for the architecture design work.
The present document includes:
• Requirements derived from API descriptions
• Requirements derived from System Architecture
• Requirements derived from new use cases
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GR ENI 001: "Experiential Networked Intelligence (ENI); ENI use cases".
[i.2] ETSI TS 102 165-1 (V5.2.3): "CYBER; Methods and protocols; Part 1: Method and pro forma for
Threat, Vulnerability, Risk Analysis (TVRA)".
[i.3] ETSI GR ENI 004: "Experiential Networked Intelligence (ENI); Terminology for Main Concepts
in ENI".
[i.4] ETSI GS NFV-MAN 001 (V1.1.1): "Network Functions Virtualisation (NFV); Management and
Orchestration".
[i.5] Service Operations Specification MEF 55: "Lifecycle Service Orchestration (LSO): Reference
Architecture and Framework".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GS ENI 002 V3.1.1 (2020-12)
[i.6] Regulation (EU) 2016/679 of the European Parliament and of the Council on the protection of
natural persons with regard to the processing of personal data and on the free movement of such
data, and repealing Directive 95/46/EC (General Data Protection Regulation).
[i.7] ETSI GR ENI 003: "Experiential Networked Intelligence (ENI); Context-Aware Policy
Management Gap Analysis".
[i.8] ETSI TS 101 158: "Telecommunications security; Lawful Interception (LI); Requirements for
network functions".
[i.9] ETSI GS ENI 005: "Experiential Networked Intelligence (ENI); System Architecture".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR ENI 004 [i.3] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AI Artificial Intelligence
API Application Programming Interface
BP Back Propagation
CAP Context Aware related Policy
CAPEX CAPital EXpenditure
DC Data Collection
NOTE: Used in the context of servers.
DCA Data Collection and Analysis
DSL Domain-Specific Language
EMS Element Management System
ENI Experiential Networked Intelligence
GDPR General Data Protection Regulation
GPM General Policy Management
IoT Internet of Things
IP Internet Protocol
IT Information Technology
KPI Key Performance Indicator
LI Lawful Interception
LSO RA Lifecycle Service Orchestration - Reference Architecture
LSO Lifecycle Service Orchestration
MANO MANagement and Orchestration
MEC Multi-access Edge Computing
MEF Metro Ethernet Forum
MOP Mode Of Operations
NFV Network Functions Virtualisation
NPD Network Planning & Deployment
OPEX OPerational EXpenditure
OR Operational Requirements
PR Performance Requirements
RA Reference Architecture
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS ENI 002 V3.1.1 (2020-12)
RR Resilience and Reliability
SDN Software Defined Networking
SLA Service Level Agreement
SOM Service Orchestration and Management
SP Security and Privacy
SP.2A Security and Privacy 2A
SP.2B Security and Privacy 2B
SVM Support Vector Machine
TCO Total Cost of Ownership
TVRA Threat, Vulnerability and Risk Analysis
VNF Virtualised Network Function
WAN Wide-Area Network
4 Introduction
4.1 Categorization of the requirements
The present document structure addresses the requirements in the following areas:
1) Service and network requirements:
- General requirements
- Service orchestration and management
- Network planning and deployment
- Network optimization
- Resilience and reliability
- Security and privacy
2) Functional requirements:
- Data collection and analysis
- Policy management
- Data learning
- Interworking with other systems
- Mode of operations
- Model training and iterative optimization
- API requirements
3) Non-functional requirements:
- Performance requirements
- Operational requirements
- Regulatory requirements
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS ENI 002 V3.1.1 (2020-12)
5 Service and network requirements
5.1 Overview
The requirements in this clause are addressed from service and network point of view and are derived directly from the
related use cases.
5.2 General requirements
This clause captures the requirements that are general and independent from other requirements categorized in other
specific clauses.
[GR.1] The ENI framework shall use history data, context, and decisions taken to learn, process and provide responses
to events, whether generated from devices or from management systems.
[GR.2] The ENI framework shall use context information as part of the computations that result in recommendations,
advisement, predictions, and decisions that are used to assist other network systems, e.g. orchestration and management
systems.
NOTE: As an example, MANO (from ETSI GS NFV-MAN 001 [i.4]) or the LSO RA (from MEF [i.5]) are
different types of orchestration and management systems.
[GR.3] The ENI architecture shall be flexible enough to support extensibility.
5.3 Service orchestration and management
This clause captures requirements related to the ENI framework service provisioning, e.g. how to compile the service
intent and orchestrate the service atoms and work flows, as well as automatic service on boarding.
[SOM.1] The ENI framework shall invoke policies based on models that describe and/or define traffic behaviour, such
as SLAs (e.g. past or current telemetry).
[SOM.2] The ENI framework shall support the closed loop control model when different orchestration and management
systems are used.
NOTE 1: As an example, MANO (from ETSI GS NFV-MAN 001 [i.4]) and LSO RA (from MEF [i.5]) are
different types of orchestration and management systems.
[SOM.3] The ENI framework should not directly manage, control or orchestrate physical or virtual entities, either at the
infrastructure level or service level.
NOTE 2: ENI framework may interact with the Orchestration system, EMS or OSS/BSS to influence the state of
the resources or services.
5.4 Network planning and deployment
This clause captures requirements related to network planning and deployment, e.g. how to allocate network resources
to VNFs, or automatic VNF on boarding.
NOTE 1: The network resources that can be managed are not limited to the requirements addressed in this clause.
[NPD.1] The ENI framework shall recommend allocation or retrieval of network resources, e.g. virtual machines,
bandwidth, IPv4 addresses and IPv6 prefixes to end users or service flows, in an intelligent way to improve the
efficiency of resource utilization. This ENI framework function may be implemented in a centralized and/or distributed
manner, according to what is defined in ETSI GR ENI 004 [i.3] and according to ETSI GS ENI 005 [i.9].
[NPD.2] The ENI framework shall assist the network equipment to use the resource pools that are used for resource
allocation (e.g. virtual machines, bandwidth, IP addresses), in an intelligent way in order to improve the efficiency of
resource utilization.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GS ENI 002 V3.1.1 (2020-12)
[NPD.3] The ENI framework should dynamically and intelligently compute and recommend the required network
resources, including both IPv4 and IPv6 resources as well as other resources.
[NPD.4] The ENI framework shall compute the network resources required to dynamically and intelligently deploy a
given network service efficiently.
[NPD.5] IT resources to enable network services shall be managed within the ENI framework.
NOTE 2: Similar capabilities within the data centre are outside the network scope of this phase of ENI.
[NPD.6] The ENI framework shall be capable of understanding the context that a set of devices is operating within.
[NPD.7] The ENI framework shall be capable of performing the proper planning and deployment of resources to ensure
that applicable deployed policies are not violated.
[NPD.8] The ENI System shall identify different types of rollouts for different types of resources that lead to the
upgrade of virtualised software-based resources.
[NPD.9] The ENI System shall, in an efficient and dynamic manner, combine network slices, slice/service prioritization
and resource allocation concepts, e.g. in order to resolve resource allocation conflicts between competing network slices
deployed on top of a shared infrastructure.
5.5 Network optimization
This clause captures requirements related to network optimization, e.g. how to adjust the network configurations to
improve its efficiency and performance, as well as the user experience of the service.
[NO.1] The ENI framework shall collect and process the necessary data according to specific algorithms in order to
achieve network optimization.
NOTE: Data collection and processing algorithms for systems will be specified in the functional architecture.
[NO.2] The ENI framework shall meet or exceed all performance requirements when improving the target performance.
[NO.3] The ENI framework shall support central optimization, local optimization and distributed joint optimization,
according to what is defined in ETSI GR ENI 004 [i.3].
[NO.4] The ENI framework shall support an adaptive optimization process where changes in the environment are
reflected in the results of the optimization.
[NO.5] The ENI framework shall use prioritization and other scheduling and traffic shaping techniques to prevent SLA
violations related with priority services.
[NO.6] The ENI framework shall use AI (e.g. Machine Learning) to identify traffic type and support traffic handling
and QoS assurance for specific type of traffic.
[NO.7] The ENI framework shall support traffic type identification in different granularity levels, including application
types, action types (e.g. sending pictures, voice calls, etc.).
[NO.8] The ENI framework shall support dynamic policy adjustment for a specific flow based on traffic identification
results.
5.6 Resilience and reliability
This clause captures requirements related to resilience and reliability of the network, including fault diagnosis and
prediction, high availability and back up, conflict detection, and rolling back to previous policies and status.
[RR.1] The ENI framework shall intelligently recommend allocation or retrieval of IP addresses without causing
route oscillation.
[RR.2] The ENI framework shall intelligently recommend allocation or retrieval of IP addresses without causing any
interruption in the offered services.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GS ENI 002 V3.1.1 (2020-12)
[RR.3] The ENI framework shall support root cause analysis to diagnose existent faults and potential faults caused by
new cases, according to what is defined in ETSI GS ENI 005 [i.9].
[RR.4] The ENI framework shall support the use of one or more AI algorithms to perform network service fault
prediction.
[RR.5] The ENI framework shall learn and predict the pattern of resource requirements of services.
[RR.6] When optimization of energy consumption is required, which implies a switch of servers, the ENI framework
shall trigger the reallocation of services to appropriate resources in another server.
[RR.7] The ENI framework shall wake up an appropriate number of servers in time to meet the growing resource needs
required by services, after learning and predicting the pattern of resource requirement of those services.
[RR.8] The ENI framework shall provide the operators with the ability to define services that are critical or prioritized.
[RR.9] The ENI framework shall allow the on-going services in a server to be moved from this server to another
without interruption, e.g. during reallocation for energy saving purposes.
[RR.10] The ENI framework shall not interrupt the on-going services on the target servers, e.g. when reallocation of
services from other servers takes place for energy saving purposes.
[RR.11] Energy saving need not be the only criterion for moving a service.
[RR.12] The ENI system shall calculate and propose proper backup actions to the operators in order to prevent or to
mitigate a service degradation or disruption when a planned operation occurs.
[RR.13] The ENI framework shall support the use of one or more intelligent methods to perform network anomaly
(fault, error and unusual behaviour) prediction and prevention.
[RR.14] The ENI framework shall be aware of the impact of adjustment on services and guarantee seamless adjustment
of network slice and high valued services.
5.7 Security and privacy
This clause captures requirements related to security and privacy issues (e.g. it is recommended that data collection
shall be captured in a secure way and not add more security risks). In addition, it is recommended that the collected data
shall be accessible by authorized accounts, and that the privacy of both subscribers and operators are protected.
The requirements indicated in the present document have been derived from application of the ETSI TVRA method
defined in ETSI TS 102 165-1 [i.2], the details of the analysis leading to the requirements have been examined with
respect to the use cases defined in ETSI GR ENI 001 [i.1] and with respect to the terminology defined in ETSI
GR ENI 004 [i.3].
[SP.1] The ENI framework shall use AI (e.g. Machine Learning) to detect abnormal traffic patterns that can lead to
service disruptions or security threats as well as to carry out the identification of abnormally operating devices.
[SP.2] The ENI framework shall provide means to detect a corrupted device.
[SP.2A] The ENI framework shall provide means to identify a corrupted device.
[SP.2B] The ENI framework shall provide means to isolate and remove a corrupted device from the system.
[SP.3] The ENI framework should provide means to indicate to authorized parties the occurrence of potential and
confirmed security threats by using appropriate mechanisms, (e.g. via dedicated interfaces).
[SP.4] The ENI framework shall provide means to invoke policies to isolate threats.
[SP.5] The ENI framework shall be designed in such a way that it complies to the provisions of the GDPR [i.6], when
processing of data (traffic or signalling).
[SP.6] The ENI framework shall allow entities that are involved in services that are subject to LI processing to be
designed in such a manner that they comply with the general provisions of LI as defined in ETSI TS 101 158 [i.8].
[SP.7] Processing for security functions should always be enabled.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI GS ENI 002 V3.1.1 (2020-12)
[SP.8] The addition of any processing in the ENI framework to comply with provisions arising from LI compliance
shall not be visible to an external observer.
NOTE: The consequence of the above is that an external observer should not assert that an LI operation is taking
place by observation of the processing load of the ENI framework.
6 Functional requirements
6.1 Overview
The requirements in this clause are addressed from the architecture point of view.
6.2 Data collection and analysis
This clause captures requirements related to how data is collected and analysed by the ENI framework.
[DCA.1] The ENI framework shall gather network status data (e.g. related to connection or routing protocols in use) as
well as network operational, administrative, and state information (e.g. network configuration).
[DCA.2] The ENI framework shall store the data either as raw data or aggregated data for further analysis, according to
what is defined in ETSI GR ENI 004 [i.3].
[DCA.3] The ENI framework shall provide data analysis functionalities, which make use of collected data in order to
produce intermediate information that will support further analysis.
NOTE 1: Examples of information related to this requirement include network context information (such as time of
the day, device/link state, and location of users).
[DCA.4] The ENI framework shall collect and analyse the necessary data in order to determine traffic patterns.
NOTE 2: This requirement can be governed by national and international regulations on Data Protection and
Privacy.
[DCA.5] The ENI framework shall collect information from the infrastructure.
[DCA.6] The ENI framework shall collect and store the history data to be used for e.g. further analysis, learning
process, etc.
[DCA.7] The ENI framework shall collect and store required run-time data in order to e.g. determine the policy.
[DCA.8] The ENI framework shall provide data collection methods for network KPI status data (e.g. packet loss rate,
latency, throughput) in different granularities (e.g. physical interface, logical interface, flow).
[DC
...