d2.1 initial use cases, scenarios and requirements - cognet · d2.1 – initial use cases,...
TRANSCRIPT
D2.1 – Initial use cases, scenarios and
requirements
Document Number D2.1
Status Final
Work Package WP2
Deliverable Type Report
Date of Delivery 30.11.2015
Responsible Unit IBM
Editors Haytham Assem, Teodora Sandra Buda, Lei
Xu (IBM)
Contributors Alaa Alloush (TUB), Haytham Assem (IBM),
Teodora Sandra Buda (IBM), Marius Corici
(Fraunhofer), Domenico Gallico (IRT) Mohd
Siblee Islam (WIT), Diego Lopez (TID), Udi
Margolin (ALCALU), Angel Martin
(Vicomtech), Alessandro Moschitti (UNITN),
Alberto Mozo Velasco (UPM), Robert Mullins
(WIT), Danny Raz (ALCALU), Elisha
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 2 of 107
Rosensweig (ALCALU), Bruno Ordozgoiti
(UPM), Marco Quartulli (VICOM), Mikhail
Smirnov (FRAUN), Kieran Sullivan (WIT), Joe
Tynan (WIT), Olga Uryupina (UNITN), Gorka
Velez (VICOM), Lei Xu (IBM)
Reviewers Angel Martin (VICOM), Robert Mullins (WIT),
Elisha Rosensweig (ALCALU), Mikhail Smirnov
(FRAUN)
Dissemination level PU
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 3 of 107
Change History
Version Date Status Author (Unit) Description
0.1 14.08.2015 Draft Haytham Assem, Teodora
Sandra Buda, Lei Xu (IBM)
Provided initial template and
deliverable structure
0.2 18.09.2015 Draft All Initial version
0.3 05.10.2015 Draft All Advanced version
0.4 23.10.2015 Draft Angel Martin (VICOM) Review and comments
0.5 23.10.2015 Draft Robert Mullins (WIT) Review and comments
0.6 23.10.2015 Draft Elisha Rosensweig
(ALCALU)
Review and comments
0.7 23.10.2015 Draft Mikhail Smirnov (FRAUN) Review and comments
0.8 04.11.2015 Draft Haytham Assem, Teodora
Sandra Buda, Lei Xu (IBM)
Addressed reviewers’ comments
0.9 20.11.2015 Final Haytham Assem, Teodora
Sandra Buda, Lei Xu (IBM)
Final review and version
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 4 of 107
Abstract
Keywords
This deliverable introduces generic use cases and scenarios based on the identified challenges
in the 5G from the network management perspective. In addition, it specifies the expected
impact of machine learning on the identified use cases, which are exemplified by one or more
scenarios. Metrics are defined for evaluating the various scenarios which will shape the technical
requirements of these scenarios. In addition, the business requirements are introduced in
relation to the benefits towards cognitive network management, security and network integrity
and virtual network platform. This deliverable is expected not only to aid the architecture and
core contribution of the CogNet project but also to serve and inspire the external research
community with a wide range of use cases and scenarios in 5G in which machine learning can
be of great value and impact from the network management perspective.
5G, Machine Learning, Network Management, Network Virtualization, Evaluation Metrics,
Challenges, Use cases, Scenarios, Requirements, Methodology.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 5 of 107
Executive Summary
This document is the public deliverable D2.1 of the H2020 project entitled
Building an Intelligent System of Insights and Action for 5G Network
Management, denoted by CogNet. This deliverable presents the
methodology, the initial use cases and scenarios, and the requirements of
the project and has been constructed from the Tasks 2.1 Usage Scenarios
Analysis and 2.2 Technical and Business Requirements of WP2
Requirements and Architecture of CogNet. The goal of this deliverable was
to identify and define a set of use cases and scenarios and their
requirements, related to the 5G network, specifically from a network
management perspective.
This document introduces six use cases of CogNet based on the
challenges of the future 5G network management, such as network
resource utilization, network performance degradation, and energy
efficiency. The use cases explored in this project are:
Situational Context, presenting how the system will handle
exceptional situations due to external environmental conditions
which cannot be directly detected within telecommunication
systems.
Just-in-time Services, referring to how cognitive network
management techniques will enable the reduction of creation and
deployment time for network services in 5G.
User-Centric Services, moving towards a richer and more complex
service catalogue, with the capacity of tailoring services to the
particular user’s needs.
Optimized Services in Dynamic Environments: enabling the network
to be deployed, scaled and migrated with ease and speed unheard
of in today’s networks, specifically by relying on the virtualization
of the network functions.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 6 of 107
SLA Enforcement, handling in an automated and efficient way the
level of service guaranteed to a user or service by the network
operator.
Collaborative Resource Management, where both the network and
the applications at both endpoints exchange metadata about the
network flows in order to improve network conditions and user
experience.
Furthermore, this deliverable introduces eleven scenarios pivoting around
the above use cases in order to facilitate more specific research questions
of high impact value in a real life situation. Each scenario presents its
definition, technical enablers and user story. The scenarios range from
large scale events prediction and interactive street walking to personalized
security applications and urban mobility awareness.
Finally, this deliverable serves as a guideline to identify the research
questions and their solutions for the other work packages. Based on the
final identified use cases and scenarios, CogNet will propose candidate
solutions to address them. The final set of developed tools will be
integrated from the previous solutions and prove the capabilities of
CogNet to achieve new levels of performance for the next generation
networks.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 7 of 107
Table of Contents
1. Introduction..................................................................................................................... 14
1.1. Background .................................................................................................................................................... 15
1.2. Motivation & Scope .................................................................................................................................... 16
1.3. Structure of the Document ...................................................................................................................... 17
2. Methodology ................................................................................................................... 18
2.1. Terminology ................................................................................................................................................... 18
2.2. Approach ......................................................................................................................................................... 19
3. Limitations and Challenges ............................................................................................ 22
4. CogNet Use Cases ........................................................................................................... 26
4.1. Just-in-Time Services .................................................................................................................................. 26
4.1.1. Definition ............................................................................................................................................... 26
4.1.2. State of the Art .................................................................................................................................... 27
4.1.3. Machine Learning Motivation........................................................................................................ 28
4.2. Optimized Services in Dynamic Environments ................................................................................. 29
4.2.1. Definition ............................................................................................................................................... 29
4.2.2. State of the Art .................................................................................................................................... 30
4.2.3. Machine Learning Motivation........................................................................................................ 30
4.3. User-Centric Services .................................................................................................................................. 32
4.3.1. Definition ............................................................................................................................................... 32
4.3.2. State of the Art .................................................................................................................................... 32
4.3.3. Machine Learning Motivation........................................................................................................ 34
4.4. SLA Enforcement .......................................................................................................................................... 34
4.4.1. Definition ............................................................................................................................................... 34
4.4.2. State of the Art .................................................................................................................................... 35
4.4.3. Machine Learning Motivation........................................................................................................ 36
4.5. Situational Context ...................................................................................................................................... 36
4.5.1. Definition ............................................................................................................................................... 36
4.5.2. State of the Art .................................................................................................................................... 37
4.5.3. Machine Learning Motivation........................................................................................................ 37
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 8 of 107
4.6. Collaborative Resource Management .................................................................................................. 38
4.6.1. Definition ............................................................................................................................................... 38
4.6.2. State of the Art .................................................................................................................................... 39
4.6.3. Machine Learning Motivation........................................................................................................ 40
5. CogNet Scenarios ............................................................................................................ 41
5.1. Large Scale Events ....................................................................................................................................... 42
5.1.1. Rationale ................................................................................................................................................ 42
5.1.2. Presentation .......................................................................................................................................... 43
5.1.3. Technical Enablers .............................................................................................................................. 43
5.1.4. Story ........................................................................................................................................................ 44
5.2. Industry 4.0 (M4I) ......................................................................................................................................... 44
5.2.1. Rationale ................................................................................................................................................ 44
5.2.2. Presentation .......................................................................................................................................... 45
5.2.3. Technical Enablers .............................................................................................................................. 46
5.2.4. Story ........................................................................................................................................................ 46
5.3. Dense Urban Area ........................................................................................................................................ 47
5.3.1. Rationale ................................................................................................................................................ 47
5.3.2. Presentation .......................................................................................................................................... 48
5.3.3. Technical Enablers .............................................................................................................................. 49
5.3.4. Story ........................................................................................................................................................ 49
5.4. Interactive Street Walk ............................................................................................................................... 50
5.4.1. Rationale ................................................................................................................................................ 50
5.4.2. Presentation .......................................................................................................................................... 51
5.4.3. Technical Enablers .............................................................................................................................. 51
5.4.4. Story ........................................................................................................................................................ 52
5.5. Emergency Communication ..................................................................................................................... 53
5.5.1. Rationale ................................................................................................................................................ 53
5.5.2. Presentation .......................................................................................................................................... 54
5.5.3. Technical Enablers .............................................................................................................................. 55
5.5.4. Story ........................................................................................................................................................ 56
5.6. Personal Security Applications ................................................................................................................ 56
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 9 of 107
5.6.1. Rationale ................................................................................................................................................ 56
5.6.2. Presentation .......................................................................................................................................... 57
5.6.3. Technical Enablers .............................................................................................................................. 57
5.6.4. Story ........................................................................................................................................................ 58
5.7. Connected Cars ............................................................................................................................................. 58
5.7.1. Rationale ................................................................................................................................................ 58
5.7.2. Presentation .......................................................................................................................................... 59
5.7.3. Technical Enablers .............................................................................................................................. 60
5.7.4. Story ........................................................................................................................................................ 61
5.8. Urban Mobility Awareness ....................................................................................................................... 61
5.8.1. Rationale ................................................................................................................................................ 61
5.8.2. Presentation .......................................................................................................................................... 62
5.8.3. Technical Enablers .............................................................................................................................. 62
5.8.4. Story ........................................................................................................................................................ 63
5.9. Massive Multimedia Content Consumption ...................................................................................... 64
5.9.1. Rationale ................................................................................................................................................ 64
5.9.2. Presentation .......................................................................................................................................... 65
5.9.3. Technical Enablers .............................................................................................................................. 66
5.9.4. Story ........................................................................................................................................................ 66
5.10. Detection and Reparation of Network Threats ................................................................................ 68
5.10.1. Rationale ................................................................................................................................................ 68
5.10.2. Presentation .......................................................................................................................................... 70
5.10.3. Technical Enablers .............................................................................................................................. 70
5.10.4. Story ........................................................................................................................................................ 71
5.11. Follow the Sun ............................................................................................................................................... 72
5.11.1. Rationale ................................................................................................................................................ 72
5.11.2. Presentation .......................................................................................................................................... 73
5.11.3. Technical Enablers .............................................................................................................................. 73
5.11.4. Story ........................................................................................................................................................ 73
6. Requirements .................................................................................................................. 75
6.1. Technical Requirements ............................................................................................................................ 75
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 10 of 107
6.1.1. Evaluation Metrics Definitions ....................................................................................................... 77
6.1.2. Scenarios Evaluation.......................................................................................................................... 81
6.2. Business Requirements .............................................................................................................................. 88
6.2.1. Cognitive Network Management ................................................................................................. 88
6.2.2. Security and Network Integrity ..................................................................................................... 89
6.2.3. Virtual Network Platform ................................................................................................................. 89
7. Concluding Remarks ....................................................................................................... 90
Appendix A. Use Cases to Challenges Mapping .............................................................. 91
A.1. Just-in-Time Services .................................................................................................................................. 91
A.2. Optimized Services in Dynamic Environments ................................................................................. 91
A.3. User-Centric Services .................................................................................................................................. 92
A.4. SLA Enforcement .......................................................................................................................................... 93
A.5. Situational Context ...................................................................................................................................... 93
A.6. Collaborative Resource Management .................................................................................................. 94
Appendix B. Scenarios to Use Cases Mapping ................................................................ 95
B.1. Large Scale Events ....................................................................................................................................... 95
B.2. Industry 4.0 (M4I) ......................................................................................................................................... 95
B.3. Dense Urban Area ........................................................................................................................................ 96
B.4. Interactive Street Walk ............................................................................................................................... 97
B.5. Emergency Communication ..................................................................................................................... 97
B.6. Personal Security Applications ................................................................................................................ 98
B.7. Connected Cars ............................................................................................................................................. 99
B.8. Urban Mobility Awareness .................................................................................................................... 100
B.9. Massive Multimedia Content Consumption ................................................................................... 100
B.10. Detection and Reparation of Network Threats ............................................................................. 101
B.11. Follow the Sun ............................................................................................................................................ 102
References ............................................................................................................................ 104
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 11 of 107
List of Figures:
Figure 1 CogNet challenges, use cases and scenarios ...................................................................................... 14
Figure 2 CogNet Terminology .................................................................................................................................... 18
Figure 3 Methodology concept map ....................................................................................................................... 19
Figure 4 CogNet ML Approach .................................................................................................................................. 20
Figure 5 CogNet Pillars Triangle ................................................................................................................................ 22
Figure 6 CogNet Challenges ....................................................................................................................................... 23
Figure 7 Use Cases and Challenges Mapping ...................................................................................................... 26
Figure 8 Just-in-Time Services .................................................................................................................................... 26
Figure 9 Optimized Services in Dynamic Environments ................................................................................... 29
Figure 10 User Centric Services .................................................................................................................................. 32
Figure 11 SLA Enforcement ......................................................................................................................................... 34
Figure 12 Situational Context ..................................................................................................................................... 36
Figure 13 Collaborative Resource Management ................................................................................................. 38
Figure 14 Scenarios and Use Cases Mapping ...................................................................................................... 41
Figure 15 Large Scale Events....................................................................................................................................... 42
Figure 16 Industry 4.0 .................................................................................................................................................... 44
Figure 17 M2M platform .............................................................................................................................................. 45
Figure 18 Dense Urban Area ....................................................................................................................................... 47
Figure 19 Interactive Street Map ............................................................................................................................... 50
Figure 20 Emergency Communication .................................................................................................................... 53
Figure 21 Personal Security Applications ............................................................................................................... 56
Figure 22 Connected Cars ............................................................................................................................................ 58
Figure 23 Urban Mobility Awareness ....................................................................................................................... 61
Figure 24 Massive Multimedia Content Consumption ..................................................................................... 64
Figure 25 Detection and Reparation of Network Threats ................................................................................ 68
Figure 26 Eavesdropping in 5G Network ............................................................................................................... 69
Figure 27 Follow the sun scenario ............................................................................................................................ 72
Figure 28 Quality of Service viewpoints and Categories (a)The four viewpoints of QoS. (b) Model
for user-centric QoS categories ................................................................................................................................. 75
Figure 29 CogNet Evaluation Metrics Categories ............................................................................................... 76
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 12 of 107
List of Acronyms:
3G 3rd
Generation mobile networks ML Machine Learning
4G 4th
Generation mobile networks MEC Mobile Edge Computing
5G 5th
Generation mobile networks MNO Mobile Network Operator
ADAS Advanced Driver Assistance
System
N/A Not Applicable
BOSS Business support and Operations
Support
NFV Network Function Virtualization
BYOD Bring Your Own Device NFVi Network Function Virtualization
infrastructure
CAPEX Capital Expenditure NM Network Management
CDN Content Delivery Networks NV Network Virtualization
CDR Call Detail Record OAM Operation, Administration and
Maintenance
CPU Central Processing Unit OPEX Operating Expense
DDoS Distributed Denial of Service PDR Performance Data Record
ETSI European Telecommunications
Standards Institute
QoE Quality of Experience
ICT Information and Communications
Technology
QoS Quality of Service
IO Input Output RAM Random Access Memory
IoT Internet of Things RCA Root Cause Analysis
ISW Interactive Street Walk SDN Software-Defined Networking
IPMI Intelligent Platform Management
Interface
SLA Service Level Agreement
JiT Just-in-Time SLO Service Level Object
M4I M2M for Industry 4.0 SNMP Simple Network Management
Protocol
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 13 of 107
SME Small/Medium-sized Enterprises V2X Vehicle-to-X
TL1 Transaction Language 1 vNSFs Virtual Network Security
Function
V2N Vehicle to Network VoIP Voice over IP
V2V Vehicle-to-Vehicle
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 14 of 107
1. Introduction
CogNet is a European Horizon 2020 project, which aims at making a major contribution towards
autonomic management of telecoms network infrastructure through using the available network
data and applying machine learning (ML) algorithms to yield insights, detect meaningful events
and conditions and respond correctly to them. Specifically, CogNet aims to develop solutions
that will provide a higher and more intelligent level of monitoring and management of networks
and applications, improve operational efficiencies and facilitate the requirements of the 5G.
Figure 1 CogNet challenges, use cases and scenarios
This deliverable’s main objective is to identify the set of challenges, use cases and scenarios of
the CogNet project. These are presented in Figure 1 and capture the future 5G network from a
network management perspective. Moreover, they represent the foundations of CogNet and aim
to guide the technical work in the project. For the reference, in CogNet, this document introduces
the initial identified challenges, use cases, scenarios, and their technical and business
requirements. Further progress made in the project will be reflected by adapting these to real-
world data and infrastructures; therefore, the final set of use cases and scenarios that CogNet will
mainly focus on, and address will be determined and delivered in D2.2 - CogNet final
requirements, scenarios and architecture.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 15 of 107
1.1. Background
As stated by NetWorld2020’s Expert Working Group on 5G [1] [19]:
5G strives to provide a universal ICT infrastructure that addresses wider societal challenges through
a flexible alignment of stakeholder incentives by virtue of being truly programmable, secure,
dependable, privacy preserving, and flexible, while minimizing the costs per bit by efficiently
harnessing all communication capabilities and reducing the system power consumption by
harvesting any kind of accessible energy from the environment.
5G has to deal with fast, heterogeneous multi-tier networks, which are also dynamic in nature.
Network function Virtualization (NFV) and Software Define Networking (SDN) are two key enabler
technologies of 5G, which are going to connect and heavily rely on the cloud services. Network
virtualization, which is mainly the combination of NFV and SDN, helps in provisioning of network
functions, components and devices by means of virtualization and dynamic routing of network
traffic based on service priority and user demands considering the available bandwidth in
different routing paths.
Both SDN and NFV are critically important components of the modernized networking
architecture. Both solutions co-exist in the service deployment, SDN for distribution of
networking resources by applications, NVF for efficient provisioning and management of network
configurations. Both are able to optimize traditional networks for video-streaming services. NFV
model is an open, layered model, where applications are hosted on a shared, common
infrastructure base. NFV leads to cost efficiency, improvements in time-to-market and innovation
in network infrastructure and applications. SDN enables network administrators to manage
network services through abstraction of lower-level functionality. This is achieved by decoupling
the system that makes decisions about where traffic is sent (the control plane) from the
underlying systems that forward traffic to the selected destination (the data plane).
Implementation of SDN results in infrastructure savings, operational savings and flexibility.
The combination of the ongoing transition into all-IP networks (VoIP, LTE, IP DSLAMs) and the
recent introduction of NFV and SDN creates a large industry shift in network design. The new
architecture (which is currently still on the making) will be based on an execution of the network
functions [36] on commodity servers located in small cloud nodes distributed across the network,
and the use of software defined mechanisms [30] that control the network flows. This is a major
turning point in the evolution of networking as we know it and it introduces many new
challenges – in this use case we concentrate on one important challenge: the ability to manage
this highly dynamic system in an efficient way. ETSI has a special working group dealing with
MANO – Management and Orchestration [21] where dynamicity is one of the biggest challenges.
There are several efforts to address these issues like OpenMANO [41] or OpenBaton [40], but the
full details of the actual algorithms needed to actually provide efficient use of resources in this
complex environment are yet to be developed.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 16 of 107
1.2. Motivation & Scope
The project will conduct and exploit leading research in the areas of data gathering, machine
learning, data analytics and autonomic network management. The ultimate objective is to enable
the larger and more dynamic network topologies necessary in 5G, improve the end-user QoS,
and lower capital and operational costs through improved efficiencies and the use of node, link
and function virtualization. CogNet WP2 entitled Requirements and Architecture is responsible for
the three items below:
1. Task 2.1: Identify the Use Cases and Scenarios of the CogNet project that can illustrate
the impact of the advancements of network management in 5G in some real life
scenarios.
2. Task 2.2: Model and design the technical and business requirements for the CogNet
project, covering the representative set of usage scenarios and arranged in a hierarchy
supported by a CogNet information model.
3. Task 2.3: Engineer the high-level architecture of the CogNet system as a harmonious set
of services, service components and configurations that meet the requirements in all
representative deployment domains.
This report is the first WP2 public deliverable and focuses mainly on the activities achieved in
relation to Task 2.1 Usage Scenario Analysis and part of Task 2.2 Technical and Business
Requirements during the first five months in the project. The basic goal of this document is to
provide a common ground for the work that will be carried across all CogNet work packages,
more specifically:
Studying the state-of-the-art approaches in the areas of autonomic network
management in 5G, Big Data, Internet of Things, etc.
Based on the state of the art gathered in the previous step, identifying potential use cases
and scenarios that can illustrate different challenges in network management for the
future 5G network.
Specifying the functional and non-functional service and business-related requirements
(e.g., robustness, resource cost-efficiency, SLAs, QoS, responsiveness / latency,
adaptability, sustainability, trustworthiness).
The results of this deliverable in relation to the use cases and scenarios identified will be used as
an input for the next steps of the project, as follows:
Task 2.2 entitled Technical and Business Requirements in WP2 will be based on this
deliverable as it contains the initial set of use cases, scenario and high level technical and
business requirements.
The high level architecture design in relation to Task 2.3 will emerge from the use cases
and scenarios defined in this deliverable.
The core technical work packages (WP3, WP4 and WP5) will be implemented based on
the identified use cases and scenarios.
Finally, WP6 is responsible for the validation and integration, in which some use
cases/scenarios will be selected to be validated and demonstrated in testbeds.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 17 of 107
1.3. Structure of the Document
After this introductory section, the rest of the document is organized as follows:
Section 2 covers the methodology and the terminology that will be used through the
entire document. Firstly, this section will explain the main terms used and describe how
they are interlinked. Secondly, it will present the overall approach that will be leveraged in
CogNet for achieving its objectives.
Section 3 describes the limitations and challenges expected in the 5G networks from the
network management perspective, also giving some guidelines on how we will approach
such challenges.
Section 4 introduces the main use cases that the CogNet consortium identified from the
perspective of cognitive network management. Each use case description will cover the
definition of the use case in relation to its context and relevance to network
management, use case state of the art in which it covers the existing techniques for
addressing certain network management challenges and finally we illustrate how machine
learning can help in solving these challenges raised from the use case.
Section 5 presents different scenarios that illustrate one or more use cases. Each scenario
contains: (i) the rationale which describes the industrial necessity of the scenario, (ii) the
presentation which outlines the general overview of the scenario, (iii) the technical
enablers which presents mechanisms used for solving the scenario and (iv) the story
which describes a real-life example for the scenario.
Section 6 introduces the main technical requirements, including the metrics used for
evaluating the CogNet scenarios, categorized based on their different areas: machine
learning, network and system performance. The business requirements are also
presented. This section is delivered as part of Task 2.2.
Section 8 summarizes the whole document and gives some guidelines about the future
work.
Appendices: This document contains two appendices in which complementary material is
provided:
o Appendix A: This appendix will present each use case expected challenges based
on the challenges identified in section 5.
o Appendix B: This appendix will illustrate in more details the mapping of the
scenarios to use cases.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 18 of 107
2. Methodology
According to the CogNet vision, leveraging ML models for addressing the 5G network
management challenges is expected to be of great benefit. The benefits of ML have been
demonstrated in many fields, such as health care, banking, however, they are not yet mature in
the network management domain. In the context of CogNet, the ML models are intended to
extract complex features from the network behaviour in order to support automation of network
management, which will also be done potentially using different ML models. The core idea
behind the methodology is that CogNet will show the impact of applying ML in selected use
cases and scenarios from the ones presented in this document based on the testbed and
datasets available to the consortium. To achieve this, the consortium follows the following
process. Firstly, the challenges in relation to network management expected in the future 5G
networks have been identified. Secondly, based on the challenges, several use cases were
identified from the network management point of view in which each use cases can address one
or more challenges. Thirdly, in order to show a real impact, the consortium identified a set of
scenarios closer to the real life context, where each scenario exemplifies one or more use cases.
This section is divided into two parts: (i) the terminology used in the whole document (section
2.1), and (ii) our approach for identifying data sets that are relevant to our use cases and
scenarios (section 2.2).
2.1. Terminology
Figure 2 CogNet Terminology
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 19 of 107
The below terms will be used across the whole document and will define the interlinked
terminology. A diagram illustrating the relationships between the terms is depicted in Figure 2.
Challenge: The main challenges in 5G that CogNet will address. These will be illustrated
by several use cases (defined next), such that each use case can tackle one or more
challenges.
Use Case: Each use case captures certain expected feature and requirement in the future
5G networks in which applying machine learning technologies can be of a great benefit
from the network management point of view. One use case can be illustrated by one or
more scenarios. For instance, the use case entitled Optimized Services in Dynamic
Environments is illustrated by multiple scenarios, such as Follow the Sun and Large Scale
Events.
Scenario: A scenario is written from a real life context in which a typical situation is
foreseen in the future 5G network that the current network management technologies
have difficulty dealing with. One scenario can illustrate one or more use cases. For
instance, the Large Scale Event scenario illustrates both the Situational Context and the
Optimized Services in Dynamic Environments use cases.
Evaluation Metric: Metric defined to evaluate the success of the solutions developed by
CogNet for a given scenario.
Requirement: This illustrates the user’s needs for a given scenario. Requirements will be
used to define clear thresholds or values for the evaluation metrics of that scenario, as
well as help determine the relevant areas of research on the way to meeting such
requirements.
2.2. Approach
Figure 3 Methodology concept map
While there are a variety of ML models, each with different strengths and requirements, at their
core they are all data-driven: the quality of the resultant learning heavily depends on the data.
Furthermore, as they must adapt themselves to the data supplied, the same tools can yield very
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 20 of 107
different results when given different datasets of the same quality, for example from two different
carriers. This is one of the benefits of these tools, as they do not generally presume a specific
architecture or design and thus can adapt to the actual behaviour of the system as illustrated in
Figure 3.
Due to this observation, the hurdles CogNet must cross at the outset are that of data
specification and acquisition, leading up to the selection and application of suitable ML models.
To address this challenge CogNet will –most likely in this order – take the following approach as
summarized by Figure 4:
[a] Determining the datasets to be acquired.
As mentioned above, CogNet has identified
a selection of target scenarios to address.
Each scenario specifies broadly the network
entities involved, both at the network core
and at the network edge, and the specific
challenge the ML model must address. For
each of these scenarios, CogNet will define
the set of datasets relevant and required in
order to tackle the problem. These datasets
must have two properties: realistic i.e.,
represent the actual data available from the
systems under consideration and sufficient/relevant - have data that can, potentially, be
leveraged by the ML models to solve the problem.
[b] Acquiring the target datasets.
Once the desired datasets have been defined, the next step will be to acquire them.
Ideally, this would be done by access to current data from production-grade systems.
However, it is apparent that such data will be rarely achievable. Not only are network
providers unwilling to share this data from their systems, but also as pointed out already
some of the systems being considered in CogNet are not yet in existence, such as a full-
fledged NFV network. Thus, while in CogNet we shall strive to use “real” data when
possible, but not exclusively.
To deal with the problem of data scarcity, CogNet shall develop tools and techniques for
generating the necessary datasets. In additional to classic simulation, one major
contribution CogNet will aim at is dataset extraction techniques, where given some
parameters, one dataset can be used to generate a related dataset of different type. For
example, motion patterns of wireless users can be used to generate traces of traffic rates,
when adding in assumptions on network topology and which applications the users are
operating. The datasets, once acquired or generated, will be hosted on one or several
testbeds (possibly on a per-scenario basis), where the different ML algorithms can be
applied.
Machine Learning Model Selection
Acquire Datasets
Determine Datasets
Figure 4 CogNet ML Approach
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 21 of 107
[c] Selecting suitable machine learning models.
Given the set of datasets to be acquired, and possibly in parallel with acquiring these
datasets, we shall select a set of candidate ML models to be used. The specific models will
have to match several criteria. First, they will have to be suitable for the datasets. For
example, supervised learning techniques assume that there is a training dataset where
the correct answers are known, and which can be used to train the ML tool in advance.
Whether or not such tools can be used will depend on whether or not such gold
label/ground truth datasets are available.
Additional considerations will be taken into account as well. Depending on the scenario,
the speed of the ML model might be more or less significant, for example if we are using
the ML model for fast, online reactions to events. Also, the types of output might depend
on the usage – for example, for automated decision making it might be important that
the justification for the selected action be human-explainable.
In all of the above, CogNet will strive to reuse data and ML techniques for multiple scenarios. This
will help focus our efforts on quality rather than quantity of testbeds and tools, and yield tools
that are generic enough to be used to solve a wide range of problems in the network, hopefully
promoting lean ML techniques and models for the 5G network.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 22 of 107
3. Limitations and Challenges
Current network technologies face two main
obstacles. Firstly, there is no real integration
of new mobile and wireless access systems
(such as broadband systems and IoT) with
legacy networks that support deployed
investment like LTE, 3G, 2G, WiFi, satellite
etc. Secondly, the increasingly huge
amounts of data being managed by the
network make smart network management
necessary. In relation to these difficulties,
several high-level challenges emerge, such
as: (1) the accommodation of new
stakeholders, like data owners, vertical
sectors, public administrations, smart cities,
communities of people, charities and SMEs, (2) new requirements in terms of energy efficiency,
(3) network threats detection and reparation, (4) the design of virtualized network infrastructure,
(5) the management of large amounts of generated data and (6) the definition of and compliance
with new evaluation metrics and their target values, such as increased throughput, decreased
latency, better energy efficiency, reduced service creation time, increased battery lifetime and
better coverage. In order to cope with these emerging requirements, a new generation of
networks is required. This new generation, which will be embodied in what is known as 5G, is
based on a new set of societal and technological challenges to be driven by a joint effort
between industry, academia and public funding agencies.
The core objective of CogNet is to develop an open, scalable and high performing real-time
network management platform that processes data from multiple network nodes and enables
autonomic infrastructure management while demonstrating the capability to scale to the network
topologies and to address the levels of resource optimisation required for 5G. To realise this, the
multi-stakeholder CogNet consortium has identified the three main core areas in which most of
the CogNet research and development will focus on, and which we refer to as CogNet Pillars
Triangle. These are illustrated in Figure 5. Moreover, the challenges that CogNet will focus on
emerge from these pillars and are presented in Figure 6.
Further, each CogNet challenge is presented in detail below:
Network Resource Allocation: This challenge relates to the problem of service demand
prediction and provisioning which allows the network to resize and provision itself, using
virtualization, to serve predicted demand according to parameters such as location, time
and specific service demand from specific users or user groups. From an ICT operator
point of view, the service provisioning, in terms of networking or compute resources,
constitutes an important challenge which deeply conditions CAPEX and OPEX values. In
this context, the most simple and fast approach, is drawing upon overprovisioning which
Service Demand
Prediction
Network Resource
Managment
CogNet
Pillars
Network Resilience & Performance
Figure 5 CogNet Pillars Triangle
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 23 of 107
consists of allocating an amount of
resources larger than required in
order to meet the possible demand
increase avoiding any intervention as
long as the upper limit of resources
allocated will not be exceeded. This
approach could be just fast, simple or
at the most operationally effective,
but not at all efficient. Above all, this
approach is really expensive in terms
of resources and energy consumption,
thus it is not cost effective. It becomes
clear how service demand prediction
would be a radical solution to this
issue, since being able to foresee the
amount of network resources to be allocated to cope with the demand fluctuations
constitutes a great benefit for a network operator. To this end, the ML technologies and
algorithms can provide a considerable contribution as reported in the following sections,
where a wide set of scenarios will explain and demonstrate the impact of these
technologies.
Network Security & Resilience: The emerging 5G ecosystem will pose a new set of
challenges related to security and resilience [6] [18]. CogNet aims to research and
develop real-time mechanisms based on machine learning techniques for providing the
basis of a robust dynamic network ecosystem, in terms of appropriate network function
placement, algorithms for prophylactic preparation for exceptional events and the real-
time expected execution for these events. Moreover, dynamic QoS management,
intrusion and anomaly detection and proactive congestion avoidance, among other
applications in the context of network management and engineering, can highly benefit
from machine learning. For instance, anomaly detection algorithms can be used to
identify serious security issues with autonomic network management and policies to
formulate and take appropriate action. This challenge relates to identifying network
errors, faults or conditions such as congestion at both a network-wide and a local level
and automatically taking mitigating actions to minimize their overall negative impact.
Networks are growing faster every day, reaching formidable levels of complexity and
traffic volume and making the task of managing them prodigious. Furthermore, extrinsic
factors can severely affect the service requirements in a manner which can only be
detected and assessed indirectly by examining the behaviour of the network elements.
For instance, a sudden turn of events in an international conflict might cause a significant
surge in HTTP requests to a news server, which could compromise the availability of the
data. The fact that the actual causes of the changing behaviour are difficult to infer makes
it especially challenging to manage the network, increasing the risk of service
degradation and SLA violation.
CogNet Challenges
Network Resource
Managment
Network Security & Resilience
Network Performance Degradation
Energy Efficiency
Big Data Management
Network Traffic
Managment
Figure 6 CogNet Challenges
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 24 of 107
Network Performance Degradation: In a Network Functions Virtualization infrastructure
(NFVi), it is important to estimate the resource utilization of applications running on top
of that infrastructure. Failure to do so might lead to severe performance degradations of
those applications. So far, studies have shown that servers in many existing data centres
are often severely underutilized due to overprovisioning for the peak demand in order to
avoid performance degradations [8] [9]. This problem can be avoided by gathering
insights into what are the causes of performance degradations and applying the
corrective measures in advance such that these do not occur. For instance, one potential
cause of performance degradations is due to overloading. In [47], the authors describe
this trade-off between the overload avoidance and green computing, namely trying to
keep the utilization of machines low (e.g., in CPU and RAM) to reduce the possibility of
overload in case the resources need increase versus keeping the utilization of machines
high to make efficient use of their energy. In this challenge, CogNet will focus on
detecting and correcting performance degradations using ML in virtualized networks
environments, leading to a higher level of resources utilization while reducing the
possibility of performance degradations, for instance due to overload.
Energy Efficiency: The advanced 5G infrastructure needs to be sufficiently flexible to
adapt and meet unforeseen demand, in alignment with current and future stakeholders’
expectations and needs. In addition, a large adoption of cloud computing and NFV, along
with a smart, programmable management system, will enable a significant reduction in
service deployment time, large savings in energy efficiency and improved network
management in general [7]. In this challenge, CogNet will aim to apply ML for optimizing
performance by better usage of the available network and VM resources while minimizing
overall energy requirements and costs. NFV provides many benefits to the
telecommunications industry. Some of these are openness of platforms, scalability and
flexibility, operating performance improvement, shorter development cycles [24].
Moreover, bringing its virtualization technology into the networking domain helps service
providers reduce equipment, power consumption and accelerate the time-to-market for
new services and network functionalities [37]. The nature of NFV opens the doors to more
flexible management, allowing for fast, dynamic deployment to match current demand in
real time, as well as migrating services to locations with lower energy costs and/or
footprint. In combination with a smart management system, this can lead to down-
scaling strategies that can offer significant savings in energy usage and OPEX [10] [21].
Big Data Management: Huge amounts of data will be generated within 5G networks [7]
[11], which will need to be stored, indexed and leveraged for achieving insights into
network and user behaviour. CogNet will address the data management problem in 5G
environments to unlock network value. This challenge relates to the large amount of
underlying data management problems expected in the 5G networks. For each of the
scenarios devised in this deliverable, the questions we want to address are: given - and
despite of - this type of dynamic behaviour, extract (a) causal dependencies between the
different (virtual and physical) elements of the system so as to assist in gaining a clear
understanding of the system state and where faults originate from. And (b) detect trends
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 25 of 107
in the behaviour of the different (virtual and physical) elements, to be leveraged to detect
anomalies and make predictions regarding future behaviour. All our models will be
applied to scenarios with large volumes of data: we foresee a large number of users
frequently changing their behavior in time and space. This will require a considerable
optimization effort. We plan therefore to invest an extra research effort in parallelization
and efficient optimization of distributed machine learning algorithms. The large amounts
of data that can be generated in this domain make it necessary not only to develop ad-
hoc algorithms, but also to design them in a way that they can be scaled to big, high-
dimensional data sets.
Network Traffic Management: This challenge relates to enabling characteristics of
network traffic flows at a given point in time and place to be used to drive efficient
management of resources and planning decisions. Accurate network traffic identification
forms the foundation of intelligent network management. Without identifying and
measuring traffic flow on the networks, communication, service providers cannot
optimize shared resource utilization and ensure correct billing and charging. To facilitate
better network management, NFV and SDN have been widely proposed to be used in
networks [33] [34] [45]. Based on the historical traffic data, we are looking in CogNet to
develop ML algorithms in order to change network configurations and use NFV to
provision the required resources and services to overcome unusual/usual events.
In order to address these challenges, CogNet has identified a set of use cases that provide
tangible goals to drive the development of the methods and techniques proposed by the project
and to demonstrate the obtained results.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 26 of 107
4. CogNet Use Cases
This chapter will introduce the use cases of CogNet in detail. For each use case we will present its
context and definition, the state-of-the-art techniques for network management addressing it,
and how machine learning can tackle the challenges arising from it. The challenges that will be
addressed in each use case are specified in Figure 7.
Figure 7 Use Cases and Challenges Mapping
4.1. Just-in-Time Services
4.1.1. Definition
Based on an essentially homogeneous physical
infrastructure supported by high-speed links at all the
network segments, the 5G network will have to rely on
software-based mechanisms to build virtual network
infrastructures able to satisfy the particular application
environments according to user needs.
Moreover, to improve the network adaptability and
dynamicity, the network manager will have to support
virtual infrastructures and services that can be deployed
on-demand, from the definitions provided by network
operators and/or authorized users. This reduction of Figure 8 Just-in-Time Services
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 27 of 107
service creation time and the ability to support just-in-time services is one of the main targets of
the 5G PPP, and therefore, cognitive network management techniques can be of great help in
achieving this.
Application scenarios for just-in-time services comprise a wide range, from personalized security
applications, addressing content variety of Internet content by smart CDN node placement to
supporting augmented reality environments in places with a high concentration of public (e.g.,
sport or civic events, artistic performances, touristic spots), and including on-demand
deployment of mission-critical services.
4.1.2. State of the Art
The deployment of new services to satisfy shifting demand patterns as it is done today is
generally not automated and thus involves a set of cumbersome, expensive and inflexible tasks1.
In particular, it requires a group of engineers and technicians to physically move to the point of
interest to undertake a task that can take several weeks, involving considerable expenses in both
human resources and hardware. Furthermore, the decision to deploy new services must be taken
carefully, ensuring that the new requirements being fulfilled are not of an ephemeral nature.
Even when working from a predefined template, the time required for service provisioning is in
the best case several days, and can become much longer when dealing with services tailored to
specific needs. This is caused by several circumstances:
The current limitations of network architecture mostly focused on separated segments
with a complete divergence between mobile and fixed networks.
The infrastructure of the networks is mostly based on specialized physical elements that
require long deployment, maintenance and configuration cycles.
Those infrastructure elements require dedicated management systems tailored to each
one of them, complicating even more dynamic service creation.
Operational systems are specifically tailored to each service, and in many cases they
require more time to deploy than the service-supporting infrastructure itself.
There exists a big gap between business rules, service policies and management systems,
requiring lengthy and error-prone human translations.
There are no automated and formalized channels for customers expressing their
requirements and requesting particular policies to be applied in service requests.
Therefore, to enable just-in-time services able to satisfy on-demand, changing user requirements,
current practice needs to evolve in order to support:
1 Hence the current goal in the 5G PPP objectives of reducing the average service creation
time cycle from 90 hours to 90 minutes
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 28 of 107
1. The correct application of intent declarations provided by operators and/or authorized
users describing the intended goals of the service
a. Interpret close-to-natural language specifications
b. Resolve conflicts among potentially competing requirements
c. Select among available service and function descriptors by matching
requirements and offerings
2. The implementation by means of the appropriate instantiation, placement and
composition of the required network functions
a. Match the infrastructure requirements from network function with the current
infrastructure status to perform an appropriate placement
b. Decide and verify the function chaining mechanisms, according to the available
infrastructural network topology
c. Orchestrate the most efficient and secure instantiation and configuration
sequence
3. The incorporation of the appropriate management policies into the monitor-control loop
of the network orchestration to guarantee the appropriate network behaviour along the
service lifetime
a. Incorporate intent declarations into SLAs to be verified and correction
mechanisms
b. Activate the required monitoring mechanisms and configure them
4. The assurance resources are properly released once the service is de-provisioned
a. Identify possibilities of function reuse
b. Orchestrate the most efficient and secure stop and uninstall sequence
4.1.3. Machine Learning Motivation
The implementation of a cognitive NFV infrastructure able to provide just-in-time services could
help provide the following network management related benefits:
Rapid service deployment: The instantiation of a set of VNFs for the fulfilment of
changing demands can be done almost instantly and remotely.
Demand adequacy: A machine learning based system can decide whether to deploy new
services quickly and optimally.
No additional hardware: The extension of the network resources should not require new
hardware to be purchased. In many cases, the only costs incurred would be those related
to the allocation of virtualized infrastructure.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 29 of 107
Flexibility and reduced risks: Just as an NFVI can grow in size as soon as the system
detects the need for more resources, it can shrink whenever these new demands start to
decay.
These requirements will present themselves in a context of unpredictable, rapidly shifting
network patterns, thus hampering the ability of a network administrator to manage them in real
time. It is therefore necessary to introduce intelligent, autonomous systems with the ability to
make judicious decisions about the network infrastructure on the fly.
This setting can benefit from state-of-the-art reinforcement learning techniques, which design
policies according to the current conditions of the system and a set of user-defined desirable or
undesirable outcomes.
In addition to reinforcement learning, certain specific problems that might come up in this
context could undoubtedly benefit from well-established machine learning methods. It might be
desirable, for instance, to identify virtual machines that are likely to become faulty so that we can
react in a timely fashion. With the adequate data, a machine-learning algorithm might promptly
reveal instances of such events that would otherwise have remained concealed until too late.
4.2. Optimized Services in Dynamic Environments
4.2.1. Definition
5G networks are expected to be inherently more
dynamic and complex in their structure than current
networks. With the advent of Network Function
Virtualization (NFV), Network Functions (NF) will no
longer be tightly coupled with the hardware they are
running on. Instead, when considering network design
and management a decade into the future, major
research activities and standardization bodies state
that many NFs will be virtualized, and thus able to be
deployed, scaled and migrated with ease and speed
unheard of in today’s networks. As a result, while the
topology of the physical network infrastructure shall
evolve on a slow time scale similar to that of current
networks, the dynamics of the virtual/logical topology
will undergo a dramatic change and be allowed to
evolve at much faster rates, in function of customers’ needs and demands. When considering
network management in such an environment, achieving the degree of reliability and stability
that is to be expected of 5G becomes a challenge. Specifically, when the network topology is in
constant flux, it is more difficult to make decisions regarding where to locate services, ensure the
SLA a provider is committed to, and perform Root Cause Analysis (RCA) on system faults.
The more specific issues we will address here (and expanded on later on) are:
Figure 9 Optimized Services in
Dynamic Environments
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 30 of 107
Migration of existing virtual machines (while keeping the service topology intact).
Scaling and healing events (which impact both load and service topology).
Changes in Service Chaining (which keep the machines in place but impacts traffic
routing and intra-service topologies) – for example: some of the flows that go
through service one are now being directly to service three without the need for
service two.
Since the main goal of this use case is to address the dynamic nature of future networks (and
especially 5G), this can be achieved with many different virtual network functions coupled with
various network management tasks such as monitoring, scaling, determining the RCA of a
problem etc. As such it is very natural to combine efforts in this use case with those of other use
cases and various scenarios.
Specifically, the following scenarios are all related to changes occurring in the virtual topology of
the network:
Follow the sun: Many applications will benefit by being co-located with their client
base, thus reducing consumption of network resources and improving response time.
Large scale events (e.g., Olympic Games): The network management system will need
to ensure the efficient provisioning of a high number of new subscribers and their
communication.
Interactive Street Walk: For example, in a shopping mall, users with different interests
should be recommended different services based on their interests.
4.2.2. State of the Art
Many of the telco operators have already experimented to a limited degree with NFV
deployments in their networks and are engaged in a process of lab trials, evaluations and proofs
of concept. However, no major large scale deployments are reported so far (November 2015).
The research community has been addressing network management in general and more
specifically Cloud management extensively in recent years. Conferences like IM (Integrated
Management), NOMS (Network Operations and Management Symposium), CNSM (International
Conference on Network and Service Management) are some of the leading conferences in this
domain. Yet, the specific problem of efficient management in highly dynamic networks does not
have a full practical solution.
4.2.3. Machine Learning Motivation
Machine learning and related mathematical models are well suited to address the scenarios that
pivot around migration and/or scaling of virtual machines. We can consider a variety of
perspectives to tackle these problems.
One approach would be to fit statistical models to metrics of interest in search of relevant
patterns and dynamics. Online learning techniques can be helpful to keep these models
up to date and to make real-time decisions.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 31 of 107
For relatively stationary periods of time in which coarse-grained figures stay the same
(e.g. no significant variations in traffic load), with the right data we can first explore the
potential of well-established optimization techniques. This analysis might show, for
instance, that a high number of concurrent processes per physical machine consistently
hamper responsiveness. From here we could look to minimize that value subject to some
performance guarantee (e.g. each user has access to X resources with a probability of Y).
Assuming we have enough information on the requirements of each VNF and the current
state of the network, we might achieve a near-optimal VM distribution just by periodically
solving the adequate optimization problem. A step forward in this direction would
therefore be to figure out particular metrics that network providers might be especially
interested in minimizing or maximizing. The problem of detecting patterns and
determining in periods of time where the network is semi-stable (that is the change in the
values of the relevant parameters is small during this time period) could be further
refined by exploiting time series analysis and related methods. It is important to note that
the big challenge here is to determine these semi-stable periods and then to apply the
relevant algorithms.
Another type of challenge which ML is well suited for is determining, for example, how
likely each of our VMs is to exceed a workload threshold, or the probability of a network
element's packet queue reaching a certain length. Such situations could result, for
example, in an alarm being raised for the network manager to take action, or an
additional VM being automatically instanced to relieve the active ones.
Topology changes could benefit from graph-based modelling. There exists a plethora of
algorithms for problems stemming from this use case. The specific ones will be selected
once the available data is determined.
For fault RCA, in order to reveal dependencies between events, there are different
exploratory analysis techniques to be leveraged. These range from simple correlation
matrices to unsupervised feature selection and clustering algorithms.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 32 of 107
4.3. User-Centric Services
4.3.1. Definition
Network service users are moving their
requirements beyond an increasing
bandwidth capacity, and towards a richer
and complex service catalogue, with the
capacity of tailoring those services with
the particular user needs. It is not only
about relying on a pervasive network able
to support high-quality connectivity
practically anywhere and anytime, but
about providing a personalized
connectivity experience, supporting
service models beyond the current one-size-fits-all (or almost-all) and subscription-based
patterns. In a 5G network, users should be able to define and personalize services hosted by the
network, choosing how they are built and configured, when they are consumed, and even how
they are charged for.
Support for such personalized services do not only require a highly adaptive infrastructure and
agile mechanisms for orchestrating it, but can obviously benefit from cognitive network
management methods, able to optimize resource usage by predictive management, support
richer service composition by addressing the inherent complexity, and provide a better user
experience by means of smart policy enforcement. Finally, it would support the participation of
third-parties in service provisioning, allowing operators to increase their offering, users to have a
much wider choice, and the creation of an innovation ecosystem around new network
capabilities.
The scenarios for this user-centric services include the provision of personalized applications able
to follow the users for security and other network capabilities (e.g., bandwidth, QoS, IoT
gateways, network-hosted optimization), the availability of advanced mobile helpers like driving
assistants, and the access to personal cloud-based services such as augmented reality, extended
storage, or on-line gaming
4.3.2. State of the Art
The personalization of current network services is mostly based on UE (either mobile or fixed)
identification and very much focused to a reduced catalogue of options related to connectivity
(e.g., port mappings in NAT systems) or multimedia services (e.g., channel subscription in IPTV
platforms) They are based on the identification of the UE, rather than actually the user, in a
database an identifying the services the UE is subscribed to. It is worth noting the common
practice in most operators of having separate identity databases for mobile (usually termed a
PCRF server) and fixed (normally called an AAA server) networks.
Figure 10 User Centric Services
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 33 of 107
Other services required by the users are normally provided by means of Internet application
protocols (typically, some variation of HTTP) in what is commonly known as over-the-top (OTT).
OTT services are extremely popular and useful in all cases that do not demand specific network
characteristics (e.g., latency, jitter, specific bandwidth management) and require full Internet
access, what can be restricted in many of the scenarios considered for 5G.
In order to support user-centric services able to address the scenarios mentioned above, current
practice needs to evolve in order to support:
1. An attribute-based identity management system, able to identify users
a. Independently of their location and UE in use
b. At any time during a network connection
c. And preserve their privacy avoiding data disclosure
2. The correct and direct application of user intent declarations describing the intended
initial goals of the service
a. Interpret close-to-natural language specifications
b. Select among available service descriptors by matching requirements and
offerings
c. Defining the specific SLAs
3. The appropriate orchestration of the required services and their proper configuration
a. With full user location awareness
b. With the evaluation and matching of the required SLAs in front of the network
current and foreseeable conditions
4. The appropriate monitoring to
a. Verify the fulfilment of SLAs
b. Identify faults and react to them
5. The adaptation to changes in
a. User requirements, translating them into new SLAs
b. User location, by performing the appropriate service migrations
c. Network conditions, by performing graceful degradation according to user
requirements
6. The proper release of resources once services are no longer required by the user or it is
not possible to fulfil the requested parameters to a minimum degree.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 34 of 107
4.3.3. Machine Learning Motivation
The User-Centric Services use case focuses on automatically adapting the network to support
highly personalized user experience. The state-of-the-art approach assumes rather simplistic
rule-based personalization. With the expansion of networks, in particular, within the Internet-of-
Things framework, however, we can expect a sharp increase in the amount and the types of users.
This calls for a more flexible and adjustable model, only feasible within a machine-learning based
approach.
We foresee several areas where machine learning can lead to a breakthrough in optimizing the
service personalization, following two main directions: (1) monitoring and prediction for user
demand patterns and (2) learning the optimal policy for the network management.
With the number of users growing very rapidly, a clustering approach would help to differentiate
between groups of users with similar network consumption patterns. Moreover, an unsupervised
dynamic clustering model might account for different types of users. This has a clear advantage
over one-size-fits-all, rule-based and supervised techniques, as it allows the network to be
adapted fast responding to an abrupt change in the users’ behaviour.
User demand is not constant over time and space. For example, traffic consumption might differ
quantitatively and/or qualitatively depending on the time of the day, on the day of the week or
for the workplace compared to home networks. This can be modelled using modern machine
learning techniques for time series analysis.
Automatic learning of the (near-) optimal policy for network management in order to provide
better personalized experience can again be formulated as a challenging machine learning
problem. With the recent advances in reinforcement learning, we can investigate models for
optimizing resource usage in a network in response to different users’ demands. In addition, a
learning-to-rank approach can help discriminate between automatically recommended policies.
4.4. SLA Enforcement
4.4.1. Definition
SLA (Service Level Agreement) Enforcement will
take a salient position in the value proposition
of 5G. SLA refers to the level of service
guaranteed (often through contract ) to a user
or service by the network operator and to a
number of quality of service parameters or
metrics including bandwidth, latency, security,
geographical coverage qualifications,
downtime due to error or faults, and priority
that a user or service may expect where
contention exists. Users may pay a premium to
operators to be guaranteed a higher SLA and
Figure 11 SLA Enforcement
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 35 of 107
certain services (emergency services, government communications) may be required by law to be
given a higher SLA than other services. The issue of geographical coverage is an important one
for SLAs as the guaranteed levels of bandwidth are highly dependent on the availability of
physical resources such as radio antenna in a particular location, the distance of a user from the
antenna, the number of users in the area simultaneously communicating and difficult to predict
factors such as the weather .
Traditionally telecoms equipment is expected to provide 99.999% availability, however with many
modern IT services requiring different levels of guaranteed bandwidth, latency and priority over
other traffic, SLAs have become more important and more differentiated depending on the
nature of the service. For example voice and real time video communications traffic is very
sensitive to factors such as throughput, latency, jitter and other data transmission issues, where
an instantaneous drop below a level or momentary drop of continuity can be perceived by a user.
However data services such as internet web traffic are less sensitive to these types of issues.
Similarly, some types of services may need to take priority if there is contention for resources
such as emergency service communications, and in other SLA and situations, security may be the
critical factor, so special authentication of the sender and receiver, encryption and or selective
routing of data through the network may be a key issue that is addressed through the SLA.
4.4.2. State of the Art
In cloud computing, Infrastructure as a service (IaaS), Platform as a Service (PaaS) and Service as a
Service (SaaS) are three cloud services, having orthogonal relationship among them. Network
function Virtualization (NFV) and Software Define Networking (SDN) are two key enabler
technologies of 5G, which are going to connect and heavily rely on the cloud services. The SLA of
5G network management system is relying on the SLA of NFV, where the SLA of NFV is relying on
the SLA of IaaS, PaaS and SaaS. An SLA agreement depends on the QoS defined by the system.
Beside the functional QoS, there are mainly four kinds aspects related to non-functional QoS,
which are performance, availability, reliability and cost. The example of evaluation metrics used
for these non-functional QoS might be response time, throughput etc. for performance, request
acceptance rate for availability, mean time between failure, minimum time to response etc. for
reliability, and financial cost for cost.
However, a user might not be interested on all these functional and non-functional QoS and the
QoS metrics. Different users might be looking for the different guarantees on different QoS
metrics. Serrano et al. have proposed a system [44], where a user can define his/her Service Level
Object (SLO) related to a particular QoS metric to describe his/her expectation and what will be
penalty for violating it. The SLA for that particular user will be a set of SLOs defined by him/her.
The policies and configurations will be reconfigured according to the updated SLA and a control
program will be responsible to apply the reconfigurations. They have also proposed a language
called Cloud Service Level Agreement language (CSLA) to define various SLOs. Again, Repp et al.
have proposed Web service requirements and reactions policy language (WSRe2Policy) to define
the policies for SLA and the policies for the countermeasures of SLA violations [43].
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 36 of 107
But the SLA enforcement issues in 5G network management should also be addressed by
considering the underlying technologies machine learning, big data and artificial intelligence in
5G. Many QoS metrics will depend on the performance and reliabilities of the algorithms used in
these technologies.
4.4.3. Machine Learning Motivation
This particular use case will demonstrate the use of machine learning in a number of ways. Firstly,
ML will be used to perform demand prediction and pre provision network resources while
reducing resources when no longer needed. Moreover, situational context information can be
used to anticipate exceptional resource demand and also to keep emergency capacity free in an
environment where there is likely to be very high demand or even demand overload. ML will
become useful for applying fair usage policy to users, to create an additional high priority
channels through the network infrastructure and to recognise a legitimate request to create such
a channel (and conversely the ability to identify a bogus request or attempt to subvert the
facility). Finally, ML will serve in recognizing and addressing errors, faults and service
degradations.
4.5. Situational Context
4.5.1. Definition
A situational context is a specific context of
the comprehensive system in which the
normal behaviour is modified (introduces an
unexpected diversity factor), due to external
environmental conditions which cannot be
directly detected within telecommunication
systems. In such a case, a huge amount of
resources may need to be consumed to make
sure the system runs smoothly and no SLAs
are validated. One example of a situational
context is the congestion of the network in a
specific location due to a gathering of a large
number of resource consumers.
Anomalies caused by a situational context are
hard to be detected by the monitoring
system of a telecommunications network that
only tracks the state of the network from a single level of abstraction. To identify a situational
context and its effects, a monitoring system has to correlate and interpret information from
multiple levels of abstraction, and also to take account into related environmental variables.
To tackle the challenge posed by situational contexts, we need to smartly analyse network traffic
and automatically allocate resources to support SDN and NFV that are the cornerstone of 5G
Figure 12 Situational Context
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 37 of 107
network. Machine learning techniques can help us to achieve this. Nowadays, most machine
learning solutions for network management rely on a certain level of supervision to guarantee
the performance. In practice, telecommunication infrastructure could generate trillions of records
every minute and these records represent complex phenomena subject to concept drift and class
imbalance. This makes supervision unfeasible.
There are a number of scenarios related to this use case that can help us to understand the
challenges in the area, including: urban mobility awareness, dense urban area (human related
congestions in shopping centres, train stations, stadiums, enterprises), large scale events (large
scale events that require extensive capacity), emergency communication (the communication
after a catastrophic event when the network is still partially available e.g. Fukushima), connected
cars (the communication between cars for safety and traffic jams), and massive multimedia
content consumption (e.g. Michael Jackson death)
4.5.2. State of the Art
Until now, by using complex dimensioning algorithms a set of rules are given to the system in
order to be able to provide the expected service to the subscribers. This results into a provisioned
system which is able to adapt to a set of “normal” situation. Applying monitoring on networks
provides a very good insight on the dynamicity of the system during “normal” operations that
enables automatic adaptations.
However, the situational contexts will impact even more the network when the communication
system becomes more complex in terms of number of subscribers, the number of functional
layers involved (hierarchy), the number of interactions between services and their intensity, as
well as in providing customized services,. This will result in extreme utilization patterns, referred
further as extreme events, in terms of resources required for specific time periods. As the
monitoring on a single level of abstraction within networks is not able to determine these
extreme events or a pattern for their occurrence, more advanced cognition tools have to be used.
These tools involve monitoring on resources hosted in multiple levels, such as application, service
and physical/virtualized hardware level, and tracking on environmental conditions that will
modify “normal” behaviours of a system, such as extreme weather or large scale events.
Records from different sources will be aggregated, correlated and processed to detect situational
contexts. Once a diagnostic on a situational context is available, the network management
component will schedule and deploy resources to minimize the impact on the system and user
experiences.
4.5.3. Machine Learning Motivation
To tackle the challenges posed by situational contexts, we need to identify extreme events and
then schedule and deploy resources to minimize the impact of these events. Extreme events can
be identified by external environmental conditions or detected based on something unusual or
abnormal within the network. To apply state-of-art unsupervised learning techniques to the 5G
domain, we need to tackle the following challenges:
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 38 of 107
Most of existing solutions consider one single level of abstraction, such as identifying
abnormal cases based on infrastructure level monitoring records only. A challenge in
anomaly detection for situational contexts is to develop solutions that simultaneously
learning at multiple levels of abstraction without any supervisions. The introducing of
multiple levels of abstraction will hide unimportant variation whilst expose important
variation.
Traditional anomaly detection problems assume the data sources and distribution of
data points are not varied with time. This is not the case in the 5G network, in which
the new systems and applications are added frequently, and data generated to track
these new components and resources are changing continuously.
Once an “abnormal” situation has been found out, existing machine learning techniques, such as
support vector machine and deep learning, can be applied to schedule and deploy resources.
4.6. Collaborative Resource Management
4.6.1. Definition
The growing concerns about
privacy among the different actors
in the Internet, and especially
among end users because the
recent revelations about pervasive
monitoring practices [26] by
several governmental agencies
worldwide, are leading to the
generalization of end-to-end
encryption techniques in the
Internet traffic. Encryption is no
longer circumscribed to the exchange of sensitive data (e.g., banking, health, professional
transactions) but has become the default for many other cases, including almost all the most
popular global Internet services such as Facebook, Twitter or YouTube. In this direction, the IAB
has made a statement to the Internet community mentioning encryption as one of the key
elements in the design of future protocols and services [38]. In conclusion, much of the traffic of
the coming 5G networks will be encrypted and that poses serious challenges to current practices
in network resource management.
Many of the current network management practices rely, in one way or another, on the ability of
the network operator to inspect the contents of the packets being forwarded by the networks.
Resource management techniques are applied to guarantee network stability and performance,
to satisfy SLAs, and to enhance user QoE. This is especially critical in the case of mobile networks,
where the shared and limited nature of the radio media imposes additional constraints on the
traffic.
Figure 13 Collaborative Resource Management
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 39 of 107
There is a general agreement among network operators and content providers to explore the
idea of collaborative resource management, where both the network and the applications at both
endpoints (client and server) exchange metadata about the network flows in order to improve
network condition and user experience. One of the key components of this collaborative
management is the possibility of applying heuristics and machine learning techniques to analyse
encrypted traffic flows, so the network can verify and extend the available metadata, aligning it
with current network conditions, and act accordingly.
4.6.2. State of the Art
The current techniques for network performance monitoring and management can only operate
on unencrypted traffic, and most of them rely on the so-called Deep Packet Inspection (DPI), a
general term that implies access to packet contents beyond the boundaries of the network layer
headers (essentially, network addresses and transport protocol in use).
The “depth” of this DPI varies largely, from complete content flow analysis for security scans to
access to the immediately upper layer identifiers (transport port numbers). Given the cost of
really deep inspection, most of the DPI practice is closer to the latter scenario than to the former
one. The 5-tuple (source and destination IP addresses, transport protocol, and source and
destination transport ports) constitute the most common flow coordinates, and are an essential
of the decision mechanisms for load balancers, firewalls and SDN applications in general. At the
application layer, the common level of depth is focused at identifying the requested URLs, that
constitute the essential coordinates for application firewalls, reputation systems or parental
control systems, to name a few.
Encryption just above the transport layer (usually by applying TLS) hides the requested URL from
the elements in the network, while encryption at the transport layer (as proposed by TCPcrypt)
implies reducing the 5-tuple above to a 3-tuple, reducing the possibilities for almost any kind of
traffic engineering.
While there is a general agreement in that these encryption mechanisms enhance user privacy
and contribute to difficult pervasive monitoring, the need for applying sound network
management is acknowledged as well. To align both goals, there are some initial proposals on:
Enabling the exchange of metadata between the network and applications, so both
endpoints and the network element can align their behaviour accordingly. The metadata
should contain both the status of the network (upstream metadata, from the network to
the applications) and the intent and characteristics of flows (downstream metadata, from
the applications to the network).
Applying machine learning methods to characterize the behaviour of encrypted flows,
make predictions on the expected QoE according to their nature (e.g., video, gaming,
Web traffic), and even assess on threats associated with such flows.
While in the latter approach it is obvious the applicability of CogNet, the former will benefit as
well from applying machine learning techniques, as they can be used for summarization of
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 40 of 107
network measurements into consistent recommendations for the upstream metadata, and to
match downstream metadata to network policy and status.
4.6.3. Machine Learning Motivation
The classical approach to network traffic characterization relies on mapping user applications to
well-known ports. However to avoid detection, several applications began to using dynamic port
numbers and port numbers used by commonly used protocols such as HTTP or FTP. Then, many
recent researches concluded that port-based identification of network traffic is ineffective. To try
to solve port-based classification drawbacks, several payload analysis techniques have been
proposed. In these techniques, packet payloads are inspected to determine whether they contain
characteristic signatures of known applications. While this approach is more accurate, it is
resource-intensive, expensive, scales poorly to high bandwidths (i.e. it requires increasing
processing and storage capacity, since a growing number of signatures must be identified), does
not work on encrypted traffic, and causes tremendous privacy and legal concerns. The limitations
of port-based and payload-based analysis have motivated the use of transport layer statistics for
traffic classification. These classification techniques rely on the fact that different applications
typically have distinct behaviour patterns when communicating on a network. Transport layer
statistics such as the total number of packets sent, the ratio of the bytes sent in each direction,
the duration of the connection, inter-packet arrival times, and the average size of the packets,
characterize these behaviours. Therefore, the research community has devoted a great effort to
the study of new traffic characterization and classification mechanisms, with the specific intent of
surpassing the limitations that these traditional approaches based on port and payload analysis
face.
A significant effort can be devoted to the application of machine learning and data mining
techniques to network traffic analysis. The application domains include studying correlations
among data (e.g., association rule extraction for network traffic characterization or for router
misconfiguration), extracting information for prediction (e.g., multilevel traffic classification, Naive
Bayes and Bayesian neural networks), grouping network data with similar properties (e.g.,
clustering algorithms for classification purposes, or for intrusion), and context specific
applications (e.g., multi-level association rules in spatial databases).
To summarize, the most straightforward approach for traffic characterization is to train a classifier
(supervised learning). However, this would take ground truth, i.e. a labelled data set, which can be
hard to come by in a big data context such as network management.
Unsupervised approaches should therefore be envisaged for this task in combination with
domain expert intervention, resulting in semi-supervised techniques. For instance, clustering can
help represent the data in a more compact manner, allowing for human examination of the
dominant traits of the traffic.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 41 of 107
5. CogNet Scenarios
This section introduces the CogNet scenarios. Each of them will present its rationale,
presentation, technical enablers, and story. The use cases that are addressed in each scenario are
presented in Figure 14.
Figure 14 Scenarios and Use Cases Mapping
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 42 of 107
5.1. Large Scale Events
Figure 15 Large Scale Events
5.1.1. Rationale
Mobile communication networks face many challenges when the number of mobile connected
vehicles, devices and mobile users is significantly increased in an area leading to increase load in
the network which will cause congestion in the network. Consequently, the network’s
performance decreases. On the other hand, it is expected from the network providers to ensure
providing services to users/devices regardless of the high density of users in areas or network
congestion or lack of network resources. Moreover, mobile network providers in many cases rely
on news and social media to expect where and when the increase of users will happen and try to
provide the required resources and reconfigure the network. However, not all cases can depend
on social media and news to be expected. Hence, in this scenario we will strive to propose novel
techniques for predicting such usual/unusual events that is expected to impact the network
significantly.
In the Large-scale event detection scenario, we will use network-external data (e.g., Social media
Data, Call Detail Records) to predict large irregular events that can potentially lead to increased
traffic and harm the network performance. For instance, we plan to extract relevant information
from social media, where such events get advertised and discussed. This will potentially have
several advantages over the traditional approach. First, we will be able to tackle irregular events:
for example, outdoors sports competitions, such as Giro d’Italia, attract a lot of spectators, while
happening in different places and thus being difficult to model with network-internal data.
Second, we will be able to predict such events well in advance, which would allow more time for
re-configuring the network. This will provide a valuable time gap allowing for more robust
network management. Third, our methods provide a solution that is complimentary to more
traditional approaches and thus the two can be combined to further boost the performance.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 43 of 107
5.1.2. Presentation
One of the main characteristics of this scenario is that the users are roaming from a large number
of different countries and have different user patterns and service needs, resulting in an
unprecedented network situation. The network has to provide the resources to these new
subscribers. Specifically, with increased roaming there will be many scaling events (up/down) and
relocation of services, once again made possible by virtualization and resulting in a highly
dynamic system.
In the large-scale event detection scenario, we are focusing on events, both virtual and real, that
might lead to a sharp increase in the traffic consumption due to a large number of participants,
such as:
large real-world events (e.g., concerts with a large number of attendees, possibly using
their phones to send heady audio/video data),
large virtual events (e.g., many users attempt to download the same newly released video
simultaneously).
We aim at predicting real-world or virtual events that might cause network overload and
disruption, based on the information about the event and textual streams from social media (e.g.,
Twitter), CDR (Call Detail Records) and other relevant data sources. Large event prediction from
social media relies on a combination of advanced ML approaches for different tasks: event
extraction from individual messages, time-event relation extraction, event matching, classification
of events into "large" (leading to potential network issues) vs. "small" and event monitoring
(static vs. dynamic).
5.1.3. Technical Enablers
The large-scale event detection scenario relies on advanced Machine Learning techniques. We
will build upon state-of-the-art methodology to propose novel ML-based algorithms for
predicting network behaviour, such as:
Data collection system from network base stations. This system collects information
about load and the density of mobile users located in a certain place.
Machine learning algorithms to analyze collected information to detect unusual event
and decide required reconfigurations and VNFs in core network to provide required
services to users.
Advanced Semantic Processing of social media and social streams to extract event
information from the textual input.
Machine Learning for Stream Correlation Analysis to map events extracted from social
media to network consumption patterns.
Anomaly Detection algorithms to identify potential problematic points with network-
internal features.
Network Monitoring to integrate real-time data.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 44 of 107
5.1.4. Story
During Christmas time, many places are hosting Christmas markets. Traditionally, people go to
Christmas markets to meet friends and spend some time together. The density of these areas
varies during the day. These places might be crowded some days or evenings, and other days
might not be. People going there would always like to have a connection with the network and
be able to use its services. Depending on the density, people might not even be able to connect
to the network.
From mobile network perspective, load in the cells covering such places is getting higher.
Numerous mobile users are moving into these cells and requesting for connection. 5G network
depending on machine learning algorithms is analysing data collected from these cells. Core
network detects the unusual situation and decides to provide these cells with extra resources and
provision new resources to be used as long as the network needs. The goal is to keep people
able to connect to the network and use its services regardless the high density in the cells.
5.2. Industry 4.0 (M4I)
Figure 16 Industry 4.0
5.2.1. Rationale
At large the scenario context is Industry 4.0 empowered by M2M towards industrial IoT; more
precisely it is about the environment of a smart factory, considering the smart factory itself as a
black box. Yet more precisely, the scenario is about M2M that facilitate the interaction of a smart
factory with its surrounding environment. The two critical examples of such interaction are supply
chain management and change management.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 45 of 107
5.2.2. Presentation
The "Smart and Tricky" (S&T) is a federation of SMEs
in the branch of high tech industrial tooling that
decided to launch a common Business support and
Operations Support System (BOSS). By deploying the
BOSS all SMEs that participate in the federation
benefit strongly in, among other areas, cost
reduction. As the Figure 16 illustrates, the focus of
the use case is a common environment of smart
factory shared by participating SMEs that facilitates
virtualization of all components within this
environment. By virtualization here we understand
that each participating SMEs instance of BOSS is
running within a (set of interconnected) virtual
machine(s) keeping track of SMEs specific processes,
while the infrastructure and its costs, in which these
VMs are running can be shared between all
federation members.
The focus of this scenario, as perceived by federation
members, can be largely on supply chain management. It became recently obvious that supply
chain management is now more than ever vulnerable because of disruptive risks. The situation is
best explained by the following quote taken verbatim from [12]: Supply chain efficiency, which is
directed at improving a company’s financial performance, is different from supply chain resilience,
whose goal is risk reduction. Although both require dealing with risks, recurrent risks (such as
demand fluctuations that managers must deal with in supply chains) require companies to focus
on efficiency in improving the way they match supply and demand, while disruptive risks require
companies to build resilience despite additional cost.
Disruptive risks tend to have a domino effect on the supply chain: An impact in one area (for
example, a fire in a supply plant) ripples into other areas. Such a risk cannot be addressed by
holding additional parts inventory without a substantial loss in cost efficiency. By contrast,
recurrent risks such as demand fluctuations or supply delays tend to be independent. They can
normally be covered by good supply chain management practices, such as having “the right
inventory in the right place."
Additional benefits to be studied within this use case are:
smart production within federated / virtualized infrastructure,
optimization of supply chain management,
change management within federated / virtualized infrastructure,
sustainable development of federated / virtualized infrastructure.
Figure 17 M2M platform
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 46 of 107
The main operational management challenge is in non-applicability of traditional QoS
requirements, since QoS (e.g., communication latency) depends on both the in-factory situation
(that is on multiplexing of production-oriented processes) and the business process interaction.
Future direction to be explored within this use case: profiling to facilitate BOSS as a service for
newcomers. The main design management challenge is coordinated design of role and policy
domain models.
5.2.3. Technical Enablers
The main enabler of the scenario is an open M2M platform that shall allow the shared use of the
smart factory surround. The platform will be used to develop and validate domain-specific
M2M/IoT applications and services, to integrate various machine devices with operator networks.
It shall support comprehensive M2M/IoT deployment over managed or unmanaged core.
The intermediary layer between multiple managed domains shall integrate service platforms, the
operator network, and devices.
The platform is aligned with IETF, oneM2M and OMA specifications though it is extensible to
specific research needs via re-configurable with high performance.
The following sub-scenarios are covered:
Connectivity management: providing the means to establish the appropriate
communication for the devices when and how is needed as well as to provide the means
to extend the trust into the information received based on device availability
Bootstrapping (of a device, physical or virtual): providing the means for automatic
introduction of multiple devices into the system and the automatic system adaptation to
the new situation
Benchmarking and system customization: providing the means to increase the trust in
device communication as well as optimizing it according to the specific service needs.
The state of the art is represented by the relevant work of ETSI (OneM2M), IIC (Technology WG's),
and IETF (at least ANIMA and SUPA WG's [3]).
Following the major management challenge the motivation for machine learning in the M2M use
case follows from the inherit complexity of the system described mainly by quick changes in the
behaviour due to the need to change configurations rapidly. The success and/or acceptability of
reconfiguration are indicated by a set of evaluation metrics defined for each of registered
profiles. These metrics need to be instantiated rapidly otherwise the benefit of BOSS will be at
risk. To meet the challenge of low latency in the evaluation, the BOSS deploys a machine learning
that attempts to predict future reconfigurations based on previous situations, on current
schedule and actual performance. The case for predictive maintenance [35] can be studied.
5.2.4. Story
The study of this scenario can be elaborated in a number of steps outlined further. An M4I
architecture specification shall enumerate major roles and stakeholders of the scenario, checking
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 47 of 107
with umbrella use cases and similar scenarios. The main outcome of this step would be
identification of communication architecture that is already now can be envisaged to contain two
component architectures: (i) smart factory core network (focus on production processes), and
(ii) smart surround network (focus on gateways) - both with possibly unified management
architecture. The next step will perform the information modelling of M4I. Here, major roles will
be specified and represented in domain models, associated policies shall contribute to the
definition of attack models, while so called "behaviours" shall populate the third asset of the
information model termed "protocols". This shall allow the specification of a set of representative
benchmarks for further testing and possible certification, which will consist of the two sub-steps:
behaviour testing and system testing. This story can be replicated for more than one domain.
5.3. Dense Urban Area
Figure 18 Dense Urban Area
5.3.1. Rationale
With the evolution towards 5G, a massive number of devices are foreseen to be connected to the
network requiring very different communication requirements in terms of when to connect, how
to connect, with which priority and for which duration. This is especially relevant for urban areas
in which smart cities will deploy a large number of sensors and actuators, cars will come with a
large number of sensors, user communication devices will highly diversify (e.g. phone, watch,
wearables, and other sensors), devices pertaining to private networks (e.g. enterprise networks,
manufacturing, logistics), and devices related to security and safety (e.g. webcams, traffic
detection).
Because of this, it is very easy that areas of the network will become highly dense only due to
mobility. In order to be able to still offer real-time communication to all of these devices, one of
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 48 of 107
the main approaches is to over-provision each of the dense areas with enough radio resources to
support the communication requirements. However, with reaching close to the spectral efficiency,
the radio resources are now limited and require more and more base stations in a specific area
with different frequencies (spreading the usage over the spectrum) and in average cell coverage
(to reduce the interference effect), which on their turn require the support for even more
handover procedures and for more sophisticated devices.
Additionally, the mobile users have the tendency to consume a large amount of content at
specific places in the network such as train stations, long traffic lights resulting in a very high
resource consumption peaks (especially when multiple trains arrive in the same train station at
the same time.
To mitigate these dynamic high resources needs in small network areas, there are several
operations that can be performed from the network side, including the adaptation of the radio
environment (through techniques like self-organized networks), better allocation of the different
spectrum pieces to the different base station (dynamic spectrum allocation) and ultimately
creating new connectivity rules for the devices to cope with the specific situation.
Considering the current network stage, these mitigation actions have to be executed at the same
time, depending specifically on the specific mixture at the specific moment in the network area.
However, all these operations require a large number of control messages to be exchanged and
induce a certain delay into the system adaptation.
CogNet will address this challenge by integrating the mobility and resource monitoring of the
operator network with a machine learning tool, by this providing the appropriate predictions for
the flexible adaptation of the network in the specific density areas.
5.3.2. Presentation
In a dense urban area situation, the main issue is to accurately and fast predict the need of
network change in that specific area as to adapt to the momentary needs in time. This is a
specific local operation as the communication has to happen through the available spectrum. In
CogNet, we are looking to leverage the understanding of the real world context towards
predicting and executing appropriate fast adaptations of the network environment to the local
communication needs.
In particular, the dense urban area situation opens several challenges from system flexibility
perspective:
1. Fast prediction of congestion events: a congestion event mitigation will take up to the
order of minutes; therefore, it of utmost importance that the prediction will happen at
least with this duration prior to the event. Additionally, these events can happen very
often, thus the prediction should be determined fast after the acquisition of the data.
2. Determining the appropriate mitigation actions: a very large amount of mitigation
actions are possible. The minimal set (having the minimal operational cost) should be
executed.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 49 of 107
3. Uncertainty in the Relevant Information: a very large amount of information regarding
user mobility, user momentary resource consumption and network situations. The most
appropriate data filtering has to be executed.
Moreover, this scenario will also demonstrate how the autonomous network management system
can respond to particular SLA requirements from a service and ensure that the network enforces
that SLA level within the scope of the particular environment in which it operates.
The three principal features that we are trying to demonstrate: Resilience, Elasticity and Security
need to be demonstrated in this. A number of areas are demonstrated:
Demonstration of how the network management system copes with very high demand
density at particular time and location
Within the context of this environment, there is a specific requirement for a high priority,
very high QoS and secure connection. This is particularly relevant to a 5G scenario as it
shows how a mobile network can be relied on in this type of critical scenario.
Because of the existence of such critical channels in the 5G network, there will need to be
a high level of security surrounding their use and there is a Privacy aspect to this also.
5.3.3. Technical Enablers
The dense urban areas scenario relies on the development of fast adaptable machine learning
algorithms for efficient resource prediction of low duration congestions and for the appropriate
management operations to be taken. The following technical enablers have to be considered:
1. Dense area congestion prediction: providing in due time the information when a specific
area will be congested and how large the congestion area is.
2. Determining the appropriate network adaptation management operations: based on the
current network situation, the adaptation of the system with the minimal number of
actions to the predicted environment.
3. Enforcement of the network adaptive operations to the specific network location.
4. Possibility to distribute the congestion area to other different areas in order to acquire
the local information and to provide network adaptations, transparent to the rest of the
network.
5.3.4. Story
In order to be able to provide a practical implementation for this technical scenario, the following
steps have to be executed.
First, the appropriate network architecture for dense urban areas management has to be
designed. The architecture has to consider the central-edge functionality split and to determine
when predictions and decisions can be deployed in the specific dense areas. Similarly, the
architecture has to consider which management operations can be executed at the edge of the
network and which require centralized control.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 50 of 107
Second, the specific parametrization of a dense urban area has to be provided followed by a set
of mechanisms for acquiring only the relevant system information needed for the prediction and
for the mitigation action selection, including the current state of the specific network area.
Third, the definition of the machine learning functionality and its adaption, considering that large
amounts of training data are available (each dense urban area has its own characteristics which
have to be considered such as the street format, the number of M2M devices, etc.). Finally, the
integration of the machine learning component with the network management system is
required in order to provide local adaptation.
5.4. Interactive Street Walk
Figure 19 Interactive Street Map
5.4.1. Rationale
Among the many potential scenarios that can be considered when matching user identities and
their locations, we have decided to focus on the particular case of Interactive Street Walk (ISW),
an environment which assists business people and tourists in navigating a city unknown to them.
It shows them directions to the main city highlights, informs them about the historical and
cultural heritage of the city, assists them in locating public services, shops and restaurants, and
supports real-time interactions between members of a group.
Current experiences of ISW are mostly related to the use of mapping applications that include
highlights of the surroundings and calculate paths for users, guiding them. However, as shown in
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 51 of 107
the figure above, ISW makes extensive use of augmented reality technologies which blend reality
with digital artefacts.
5.4.2. Presentation
This scenario focuses on assisting the user based on her location in an interactive street walking
environment. Examples for location-based services could be user guiding or advertisements.
These services can be implemented in the network using “service chaining”. As different users will
have different requirements, configurations and interests, the service chain for each can be
different, as well as change over time (e.g., due to changes in pricing, user location in the mall
etc.). Thus, network traffic might experience modifications that up until now were not part of
standard network experience.
ISW requires heavy computations which cannot be handled by the limited processing capacity,
and therefore it will imply the support for personal cloud services, able to provide the required
processing capacity while being only a few milliseconds away from the user.
Finally, ISW will include a 3-D model of a virtual tour guide which can deliver information
collected from a variety of external data sources such as traffic information from the municipal
open-data plat- form, shop and restaurant reviews from TripAdvisor, and advertisements and
promotions from the local shops. This requires the ability to process heterogeneous data streams
with various types of requirements regarding data volume, publishing frequency, and real-time
display.
5.4.3. Technical Enablers
It is very important to provide a prediction mechanism for the specific area in terms of expected
subscribers; a new network density prediction mechanism has to be considered. The prediction
should concentrate not on single device mobility, as this one provides only a small part of the
network, but on the overall system communication needs and load mobility.
A second step is to provide the most appropriate mitigation actions considering the specific area.
Based on the capabilities, communication and mobility patterns of the devices in the area as well
as on the specific services use one of the multiple sharing of environment operations may be
executed either at connectivity level (changing the communication management of the devices),
at core network level (e.g., allocation of more compute resources at the edge or radio, dynamic
allocation of spectrum and SDN control loops).
This types of incidents are rather often, thus a machine learning component can be trained using
real network monitoring for predicting such events and additionally for learning which the best
mitigation actions are.
To achieve these demands, an appropriate orchestration of network and local computing
resources has to be performed, and followed by a continuous monitoring and management of
the deployed resources in order to balance:
The translation of user interests, operator policies, information provider requirements,
and available data streams into infrastructure-oriented ones.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 52 of 107
The alignment of the privacy requirements from users, their expressed interests, and the
different data sources to support a satisfying experience.
The initial deployment and composition of the available functional components
according with the above alignment and user location.
The adaptation of this deployment as the user moves and/or changes their interests.
To achieve these goals, the recently proposed mechanisms of Mobile Edge Computing (MEC) [20]
seem of high applicability. The CogNet project can contribute significantly to this scenario and
the above requirements by:
Supporting an automated translation of human-understandable user interests and policy
expressions into a set of capability requests that can be applied to the available MEC
infrastructure at each point of the network.
Implementing smart placement and migration strategies across the MEC infrastructure,
according the infrastructure status.
The application of smart response to changes in user location, especially applying
predictive methods to enhance service migration on the MEC infrastructure.
5.4.4. Story
A network operator provisions a MEC infrastructure for ISW available for those customers
requesting the service: end users, and application and data providers. Data and application
providers fill the metadata relative to the characteristics of their services. Users activate IWS and
specify their personal interests for the particular walk. The system identifies and composes data
sources and applications for the users at their current locations. The system performs the
deployment and configuration of the composed service at the appropriate nodes of the MEC
infrastructure. The system reacts to specific changes in the conditions, both in the infrastructure
and user interests, as users move and change their locations.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 53 of 107
5.5. Emergency Communication
Figure 20 Emergency Communication
5.5.1. Rationale
Emergency communication is a critical part of the current large scale communication systems. As
part of their license agreements, the carrier-grade operators are committing to an almost
ubiquitous network coverage and to providing a highly available emergency communication
system in case of disasters. Although the network coverage is used for providing services to all
the potential subscribers, the emergency services are not producing any revenue by themselves,
thus being an overhead to the actual communication system business. From this perspective, it is
in the interest of the operators to reduce the cost of the emergency communication systems as
much as possible.
On the other hand, the authorities are interested into gaining access to information on specific
events which may be communicated by the different subscribers which are located close to the
event. Specifically, when a large emergency event happens, a communication storm is created by
a large number of subscribers which want to report their own perspective on the event itself. In
this case, the network will have to be able to select the most appropriate users to communicate
such an event.
Additionally, with the increase usage of M2M networks, an emergency may be considered also
the unexpected malfunctioning of a critical M2M system, such as traffic control robots, massive
factory robots, etc. which may endanger the life of the surrounding subscribers. This effect may
be highly propagated into the network when the malfunctioning happens in a backend control
component (e.g. the traffic light control point in a city). Thus, a means to immediately isolate the
malfunctioning component and to instruct the surrounding ones on the appropriate emergency
behaviour are of the highest importance for the safety of the human beings.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 54 of 107
However, the current system has a uniform admission control to the communication channel.
Each subscriber or machine will receive the right to communicate in the order they request it and
not depending on their relationship to the specific event. Because of this, during emergency
events when communication is required with specific subscribers and with specific machines, this
may not be possible due to the congestion of the network with others trying to communicate the
same event [25].
In order to solve this issue, a new type of admission control system has to be introduced into the
communication networks. The admission control has to be adapted to the specific momentary
priorities, giving the opportunity to use the network for different types of emergency
communication such as towards the industrial management entities (e.g. stopping a
malfunctioning robot, initiating disaster recovery mitigation actions, etc.), towards the authorities
(e.g. blue light safety) as well as to people whose lives would be endangered (e.g. devices of the
people which are considered missing) and to machines which can provide relief actions for the
emergency (e.g. automatic opening of the doors, closing of the elevators and starting of the
ventilation system in case of a fire).
As these type of events are rare and highly dependent on a specific situation, both from the
perspective of the network as well as of the communicating devices importance, a machine
learning mechanism can be deployed to provide the appropriate rules on who is allowed to
communicate to the system and who can be used for further information providing and
actuation. Through the machine learning system, a new dynamic class of connected devices is ad-
hoc created containing the most relevant information providers and actuators, liberating the
network from the inherent congestion of reporting of the same events. Thus, using the same
infrastructure, all the required information can be gathered and all the appropriate actions can be
executed, without adding any additional operational costs. The classification rules should be
dynamically adapted based on the input from the system whether the specific actions were
relieving the emergency. The major outcome of this step will be the design of an appropriate
machine learning component able to manage the admission control of a telecommunication
system in an appropriate manner for the specific event.
Based on the above two steps, the scenario will be further adapted to two specific network
environments: one for large scale communication, like a carrier-grade operator network and one
for machine related emergencies such as wide deployed M2M networks.
CogNet will address this challenge by integrating the admission control mechanism of the
operator network with a cognitive emergency situational context machine learning tool, by this
dynamically differentiating the network functioning during these exceptional events.
5.5.2. Presentation
The main issue with an emergency situation is that a large number of devices will require
communicating, in large amounts redundant information. In the CogNet project we are looking
to leverage the understanding of the real world context towards its application as a new
prioritized admission control schema. From the SLA perspective, this scenario will demonstrate an
example of where a very high concentration of users and / or very heavy usage in a confined area
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 55 of 107
creates a situation where there the network is physically incapable of providing adequate
bandwidth for all users and a best effort or fair usage policy controlled approach is used.
However when a very high importance service is necessitated, in the case described a medical
emergency, the network management system is capable of enforcing the related SLA.
In particular, the emergency situation opens several challenges from admission control network
management functionality perspective:
1. Uncertainty in Emergency Events: Determining that an emergency event has occurred
is one of the main operations which have to be executed. Currently, such a system does
not exist at all in the uniform communication networks.
2. Uncertainty in the Relevant Information Sources: For handling an emergency event
accurately, the (and hopefully only the) relevant information has to be acquired by the
relevant automatic M2M controllers and human based emergency authorities. The main
issue is that a large amount of the information received is multiple-fold while portions of
the information which are of large importance are not able to be received due to the
network congestion.
3. Immediate automatic actions: in case of an emergency due to the malfunctioning of a
machine device (e.g. a robot), the most appropriate automatic actions in regard to
sensing the environment around the device and in regard to providing the appropriate
actuation measures.
4. Admission control: Depending on the type of emergency event, the network should
dynamically modify which devices are allowed to communicate over the specific network
channels in order to ensure that the relevant information sources and the automatic
actions can be executed while removing all the other non-priority communication.
5.5.3. Technical Enablers
A new emergency communication perspective of the communication networks will be given,
providing a description for the specific actors and stakeholders as well as their role shift from
normal to emergency operations. Based on the different roles an architecture will be specified
including two major components: the admission control architecture of the core network and the
machine learning part providing the information on how the admission control has to behave.
The emergency scenario relies on development of advanced machine learning algorithms for
detecting emergency events and for providing dynamic admission control rules to be enforced
into the network. The following technical enablers have to be considered:
1. Emergency Detection: determining that a specific emergency situation occurred which
requires proper dynamic admission control rules. This includes determining which event
happened and how to modify the admission control rules. Moreover, this implies an AAA
(Authentication, Authorisation and Accounting) system that authenticates the emergency
service and qualifies it level of priority in the network.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 56 of 107
2. Situational Information correlation: using a machine learning mechanism to give priorities
to specific devices which can communicate relevant information or can execute
appropriate mitigation actions.
3. Dynamic Admission Control: introducing a new interface towards the subscription profiles
of the communicating devices in order to modify their admission control rules
dynamically according to the emergency detection as part of making more dynamic the
network management mechanism. This implies a system which can control the priority
given to different services being used on the network and direct the other components of
the network to prioritise certain traffic.
5.5.4. Story
Let us consider a situation like an accident at a concert, where an emergency call is put through
and the paramedics arrive on the scene. The paramedics have a sophisticated augmented reality
service that helps them deliver critical medical aid and which requires cloud access and
considerable bandwidth. Because it is a high priority service and can use a special priority
authentication and authorisation method, the 5G network management is able to dynamically
allocate bandwidth specifically for this service and dynamically allocate network resources to
guarantee that the service has all the data requirements necessary. The inelastic RAN bandwidth
availability (at least at short time requirement) means that bandwidth has to be taken from other
users. This is done using an algorithm that attempts to minimise overall disruption while
maintaining QoS and SLA to as many users as possible. When the medical aid is applied and Joe
is brought off the scene and to hospital, the critical service is stopped and the various
bandwidths are restored to the general pool, and any specific network resources allocated to the
service are stopped.
5.6. Personal Security Applications
5.6.1. Rationale
The protection of Internet-connected
devices, such as mobile phones and
laptops, is currently addressed essentially
through the installation of appropriate
specific tools on each device. Personal
firewalls, malware analysers, or parental
control applications are typical examples
of this current practice. However, this
raises several issues: privileged access on
the device is often required, tools may
use a large amount of computational
resources, platform capabilities vary, and
appropriate tools may be unavailable on particular systems. 5G will imply an increase of one to
Figure 21 Personal Security Applications
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 57 of 107
several orders of magnitude in the number of embedded devices connecting to the network, of
which many contain little to no security installed. This includes sensors, controllers and appliances
that fall under the broad definition of the IoT.
5.6.2. Presentation
Service Providers and Network Operators are already starting to provide device and pervasive
access protection from Internet threats by offloading execution of common security applications
away from user devices using NFV technology creating virtual network security functions (vNSFs).
The strongest challenge in this respect has to do with the requirements on user privacy, as
security functions imply the highest sensitivity with respect to privacy, demanding the support of
vNSF personalization. Users must be allowed to define their own security rules and policies, and
connect them with their identities, enjoying a secure usage of the network that preserves their
privacy, and able to be in place whatever the pattern of use or kind of access they are employing.
5.6.3. Technical Enablers
To achieve these demands an appropriate orchestration of resources has to be performed, and
followed by a continuous monitoring and management of the deployed resources in order to
balance:
The translation of user-defined policies (e.g., high-level, human-understandable) into
infrastructure-oriented ones.
The composition of the security intents as expressed by legal requirements, operator
infrastructure protection and policies, and a hierarchy of user policies (e.g., the employer
and the employee in a BYOD environment, parents and children in a home environment).
The initial deployment and composition of the available functional components
according with the above policies.
The adaptation of the deployed security applications to the varying circumstances of
network traffic, live security advisories, and potentially identified threats and attacks.
The CogNet project can contribute significantly to this scenario and the above requirements by:
Supporting an automated translation of human-understandable policy expressions into a
set of capability requests that can be applied to available infrastructure and vNSFs at each
point of the network.
Providing smart policy consolidation mechanisms that can derive new patterns from
previous conflict resolutions by humans (e.g., users, operators).
Implementing smart security function placement strategies, according to the current
infrastructure status, and able to combine virtual and physical implementations.
The application of smart response strategies to events detected by the deployed
functions, deploying new functions or adapting their configuration to satisfy policy
guidelines in the face of such events.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 58 of 107
5.6.4. Story
A network operators provision a catalogue of security functions available for its customers. The
operator defines the business and legal policies applicable to a set of users and a set of different
locations. Corporate administrators define their policy within their corporate network (e.g., office,
hotel, mall, airport). Customers define home policies. Users specify personal security preferences.
The system identifies and composes security functions for the user in different locations. The
system performs the deployment and configuration of the security functions at the appropriate
location. The system reacts to specific changes in the conditions (e.g., new security advisory, new
policy, attack) at the different locations.
5.7. Connected Cars
5.7.1. Rationale
The transportation sector is one of the key sectors that will be benefited by 5G, as stated by
operators [4], car industry [22], and European Commission [2]. This is in line with market demand,
as car connectivity is the highest priority feature requested by consumers in the 20-30 year old
age group in a recent study by BCG [16]. 5G will expand the connectivity possibilities of vehicles,
which will impact not only in infotainment services but also in the safety of the vehicle.
In 2011, more than 30,000 people died on the roads of the European Union, i.e. the equivalent of
a medium town [16]. For every death on Europe's roads there are an estimated 4 permanently
disabling injuries such as damage to the brain or spinal cord, 8 serious injuries and 50 minor
injuries [16]. Moreover, the socio-economic cost of fatal, serious, minor injuries and taking into
account intangible elements is estimated to be about 2% of EU countries' gross domestic product
- around Euro 180 billion and twice the EU's annual budget [15]. Connected cars technologies will
enable cars to communicate with the outside world and this has a great potential for moving
Figure 22 Connected Cars
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 59 of 107
towards safer use of existing roads infrastructure. It is expected in the future that all of the
vehicles will be connected to a centralized traffic management system that will permit passengers
to travel at much higher speed within close proximity within each other and without having a risk
of accident. So fully autonomous driving cars are a motivation for decreasing human errors and
hence decrease significantly the chance of accidents. Another crucial aspect to consider is that
the network must ensure high data rates at potentially high travelling speeds. The latter could
affect the performance of the network, and in such situations, the entire connected cars scenario
could collapse.
5.7.2. Presentation
Vehicles can exchange information with other vehicles (V2V), with the roadside infrastructure
(V2I), with a backend server (e.g., from a vehicle manufacturer or other mobility service providers)
or with the Internet (V2N), with a pedestrian (V2P), etc. The term Vehicle-to-Everything (V2X) is
used to refer to all these types of vehicular communication,
Typical V2X applications or automotive use cases include [5]:
Advanced Driver Assistance Systems (ADAS): the final objective is to increase drivers’
awareness of what is happening on the road around them. In this application, connected
cars periodically provide either status information (e.g., position, speed, acceleration) or
event information (e.g., traffic jam, icy road, fog). This information is usually packed into
stateless, individual messages or probes which are either locally disseminated to
neighbouring vehicles, or sent to a central point (base station, backend) where it can be
aggregated and then again disseminated to other vehicles to make use of it.
Enhanced navigation with High Definition maps: the objective here is to obtain an
enhanced navigation experience. The information given by the GPS is fused with the
information obtained from other sensors, such as cameras, to create a Local Dynamic
Map with the current information of the vehicle surroundings.
Information society on the road: people are demanding high data rate and low latency
connectivity when travelling inside vehicles.
One critical factor in the connected cars scenario is performance. Network performance
degradations could potentially impact people lives by affecting the vehicle safety for instance by
causing delays in the network. The cause of such issues must be detected in advance, and
avoided such that no performance degradations occur in the network.
Moreover, in the current deployments, in order to encompass the connected cars scenario but
also other situational contexts, the system is highly over provisioned (i.e., more resources are
available in the network) based on the peak time connectivity requirements. This requires that a
large amount of resources can be made available very fast by the system at any time. This
continuous time availability is the one that produces the large cost.
Therefore, CogNet will address the following challenges from the network management
perspective in the connected cars scenario:
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 60 of 107
1. Efficient data collection and storage from the network, such as location, throughput,
delay, etc.
2. Efficient processing of large amount of data gathered.
3. Efficient and accurate prediction of service demand and provisioning accordingly the
network such that it can resize and resource itself based on certain parameters such as
location, time, and historical data. This should lead to optimizing performance and the
use of available network and VM resources.
4. Accurate identification of the cause of network resilience issues such that it can identify
network errors, faults or conditions such as congestion that might cause severe
performance degradations.
5. Automatically take mitigating actions to minimise the overall impact of network resilience
issues.
5.7.3. Technical Enablers
In particular, CogNet proposes to address the challenges described in the previous section
particularly for performance degradation detection and correction in the connected cars scenario
by:
1. Load generation: generate synthetic data that can model the connected cars scenario, in
a variety of contexts, such as high density or low populated areas. Another load scenario
considered is high speed travelling such as in a highway, as this represents a serious
challenge for V2V communication.
2. Real data gathering: investigate sources of real open-source data for the purpose of this
scenario, such as the one gathered in the case study conducted in Michigan between
2012 and 2014 [32].
3. Storing and processing the data: Use a distributed storage and distributed processing
platform to analyse the datasets, which should be well-suited for Machine Learning, such
as Spark.
4. Performance degradation detection and prediction: Use data analytics to develop a
better understanding of performance degradation in networks. This could be achieved
by investigating the correlation between network data and network performance
degradations by analysing the performance of the network components such as CPU and
RAM utilization. Gather network resource usage patterns in order to predict potential
future performance degradations.
5. Correct performance degradations: Develop algorithms that can correct the network
topology through NFV orchestration in order to avoid performance degradations.
6. Service demand prediction: Develop algorithms that can predict the service demand in
order to achieve the demands of continuous time availability in a pervasive 5G network.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 61 of 107
5.7.4. Story
An example showing how valuable car to car communication could be is the study conducted in
Michigan between 2012 and 2014. There, nearly 3000 cars were equipped with experimental
transmitters. The study was conducted by the National Highway Traffic Safety Administration
(NHTSA) and the University of Michigan and shows that the technology could prevent more than
half a million accidents and more than a thousand fatalities in the United States every year [32].
In this study and similarly in CogNet the computers in each car will process the various readings
being broadcast by other vehicles 10 times every second, each time calculating the chance of a
collision. Transmitters should also use a dedicated portion of wireless spectrum as well as a new
wireless standard, 802.11p, to authenticate each message [32]. Moreover, in a crowded area, the
network should adapt itself and provide sufficient bandwidth for the cars to communicate
between each other. For instance, before a crowded event (e.g.: Open Air Festival), there is an
expectation of huge volume of cars to reach the event and hence, congested traffic which will
create a huge load on the network in a connected cars deployments. This will open many
challenges whether the network will be able to provide all needed resources to support such
story as any performance degradation in a connected cars story is prohibited since it is a life-
threatening situation.
5.8. Urban Mobility Awareness
Figure 23 Urban Mobility Awareness
5.8.1. Rationale
The future 5G network will entail a massive increase of the number of embedded devices
connected to the network. Cisco Systems Inc. estimates that by the time 5G is deployed there will
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 62 of 107
be 50 billion devices connected to the Internet [13]. These include sensors, controllers and
appliances that fall under the broad definition of the IoT.
Urbanization and modern civilization leads to different functional regions in the city, e.g.,
residential areas, shopping areas, business districts and educational areas, which supports
different needs of people's urban lives and serve as a valuable organizing input for framing
detailed knowledge of certain metropolitan area. This region is either designed by urban planners
or naturally formed according to the people's lifestyle, and would change functions and
territories with the development of a city. Among different scenarios that can be considered in
the future of our cities, we have decided to focus in this scenario in the particular case where
discovering regions of different functionalities can enable a variety of valuable insights for better
managing the network infrastructure.
It is expected that the load on the network will vary from region to another in the city according
to its functionality. In a business district area in the city, the service demand and the load on the
network expected to be less than shopping districts since probably the users at the shopping
districts might rely on the augmented reality applications that can aid them for shopping and
which will increase the load and congestion in the network. Hence, in this scenario we are looking
to cluster cities into regions based on its functionalities and for each region, classifying the
network traffic and based on this classification, recommendations can be made for migrating
some network resources or dynamically configuring the network topology.
5.8.2. Presentation
A smart city, which supports urban mobility awareness, is defined as a city where “investments in
human and social capital and traditional (transport) and modern (ICT) communication
infrastructure fuel sustainable economic development and a high quality of life, with a wise
management of natural resources, through participatory governance” [46]. Although, the
expected growth of different applications that requires different computational and network
consumption (e.g.: Augmented Reality apps, Multimedia streaming apps, etc.) which cannot be
handled by the limited processing capacity, the network mobile usage is expected to vary from
region to another in the city according to its dominant functionality which will impact the type of
applications used in each region. Hence, this scenario focuses on estimating the network
consumption in different regions of cities based on the applications used which will enable
estimating the network resources required when users move from regions to another and hence
being able to dynamically allocate resources on the future Mobile Edge Computing (MEC) which
expects to provide a personal cloud services that is able to provide the capacity requirements
needed for the heavy computations applications.
5.8.3. Technical Enablers
The Urban Mobility Awareness scenario relies on developing advanced machine learning
algorithms for service demand prediction based on the different functionality of regions in the
cities. To achieve this, the CogNet project expects to leverage the following technical enablers for
this scenario:
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 63 of 107
1. Implementing clustering techniques for discovering regions of different functionality in
the cities.
2. Developing semi-supervised learning algorithms for network traffic classification for
predicting the application used from the network and application provider data based on
the regions identified in 1.
3. Developing supervised learning algorithms for predicting the network service demand of
each of the regions identified in 1.
4. Based on 2 & 3, we will strive to develop algorithms for smart response when users move
from certain functional region to another in the city and being able to dynamically
migrate network resources on the network infrastructure based on the expected network
consumption of each of the regions which is estimated from the type of applications used
in each region.
5.8.4. Story
In our future cities, it is expected that the network should be smarter and adaptable according to
the user expected behaviours in the city without over provisioning network resources for
protecting SLA. The cities can always be clustered into different regions with different
functionality. Each is expected to have different usage patterns and network consumption
according to its functionality. For instance, in residential areas the overall mobile network
consumption is expected to be less than shopping areas where there will be a higher likelihood
for using heavy network consumption applications (e.g. AR applications for shopping purposes).
In a real situation, when users move across different regions of the cities, the network is expected
to automatically allocate resources according to the mobility patterns of these users according to
their predicted network consumption based on the used applications which is expected to vary
from certain region to another in the city according to region’s functionality.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 64 of 107
5.9. Massive Multimedia Content Consumption
Figure 24 Massive Multimedia Content Consumption
This scenario focuses on services around a location where an event occurs which requires the
network having to cope with a very high peak in multimedia consumption (e.g., a sports event or
a concert in a stadium, with users sending video recordings across the network).
5.9.1. Rationale
Two-thirds of all internet traffic is video [14], and the number of smart, mobile devices in the
world will double to two billion by 2017 [23]. The continuous evolution of the media
entertainment industry towards enhanced experiences pushes the technologies beyond 4K or
UHD resolutions. The technical challenges combined with today’s consumers viewing habits,
shifted from watching purely linear TV to watching media as part of a multi-screen and multi-
tasking activity. These are changing usage patterns and the role of mobile enabled devices.
The quality of the network experience is an important element in customer satisfaction and
retention. Here, HEVC and MPEG-DASH are keys to the media industry with significant
movements in both adoptions. Encoding standards such as HEVC relieve the bandwidth usage by
minimizing the employed bitrate. Accompanied by MPEG-DASH, multiple bitrate streams are
operated by adjusting the play-out rate to stay within the actual network throughput and device
capability. Thus, adaptive encoding offers similar benefits with the platform having the ability to
allow operators to plan the capacity of their delivery networks to match the average, rather than
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 65 of 107
the peak, usage demands, thus saving considerable CAPEX while maintaining an uninterrupted
user experience by means of simplifying client based switching decisions to allow continuous
viewing.
These technologies catalyze QoS solutions for each connection, however, from the point of view
of the infrastructure and the network, a global optimization for massive media services must be
done. Thus, the network manager or telco operator needs tools to improve QoS in a 5G
environment, such as:
Selection of the most appropriate setup to deliver the best QoS at the best cost (e.g.
policy-based or fully dynamic network selection; support for different layers of QoS with
different levels of cost and service level agreement).
Optimization of traffic when passing across the network (e.g. RAN optimization, specific
video optimization tools, management of applications traffic, congestion control).
These tools meet specific network challenges in 5G comprising of:
a. Scalability (multiparty and long tail paradigm in heavier dense device environments):
CogNet will detect trending contents and viral behaviours. Moreover, CogNet will
compensate extra needs of premium traffic with more flexible ones.
b. Mobility (increased ratio of continuous services, not transactional services): CogNet will
support resource optimization.
c. QoS (increased BW needs related to featured quality displays while keeping latency,
switch sessions transferred seamlessly between devices and 2nd screen): CogNet will
support resource assessment to satisfy SLA avoiding overflow.
d. Dynamicity: CogNet will guide self-configuration, self-optimization and self-healing
system shifting from reactive to proactive.
e. Symmetric traffic patterns where the packet direction is not from the cloud to clients:
CogNet will place new service patterns into the equation to meet these symmetric
services.
f. Efficient resource management to accommodate peak delivery needs while meeting
business costs: CogNet will conduct the operative thresholds to keep network operation
inside business ranges.
5.9.2. Presentation
The explosion in the variety and volume of video apps we use consumes a lot of bandwidth and
makes the capacity of the networks more critical to the user experience. Because of the high
demanding performance of this kind of services from the network, usually the video services are
employed as a marketing application to demonstrate distinctive advances and new features from
a telco operator.
The volume of video affects all parts of the IT infrastructure and the network, posing greater
challenges due to the cost and bandwidth constraints. The answer to video overload is simple:
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 66 of 107
reduce the traffic or add more bandwidth. Hence, techniques like bandwidth optimization,
Quality of Service (QoS), and path selection are vital for the network manager. Therefore, 5G
optimization tools must provide elements of control-path selection and managing prioritization
for different traffic types depending on their importance in a cost effective way.
The goal is to provide the best possible QoS according to the SLA, and the appropriate device
features to overcome technical limitations in order to get a live, fluent and continuous
multimedia experience. The 5G network must transparently deal with mobility, dense or distant
areas, multi-device contexts and geographic distributions. To this end, CogNet will autonomously
improve network agility and flexibility to efficiently support the evolving demands of users.
5.9.3. Technical Enablers
The CogNet project will develop several technologies that can contribute in achieving the
objectives set in this scenario:
Service probing: a client-side embedded system of data collection from end devices that
involves capturing and sharing QoS metrics and benchmarks. This can significantly impact
in the volume and velocity (less data to transfer means less time) of data transfers.
Media service: a next gent standard compliant platform to provide multimedia contents
for massive consumption.
Network monitoring: a system of data collection from network nodes that involves
preprocessing data to allow the node classify the data it generates and identify the most
important and irregular data for submission to network management while filtering
routine and regular data. This can significantly impact in the volume and velocity (less
data to transfer means less time) of data transfers.
Application of machine learning algorithms: to develop a system of service demand
prediction and provisioning which allows the network to resize and resource itself, using
virtualization, to serve predicted demand according to parameters such as location, time
and specific service demand from specific users or user groups.
Smart network control and management: providing infrastructures with efficient and
flexible provisioning of end-to-end differentiated services by means of significantly
improving operations and network efficiencies.
Network Functions Virtualization: enabled by software defined networking (SDN), it plays
an important role to automatically reallocate resources.
5.9.4. Story
Helen will attend to the stadium to enjoy the next football match of Athletic Club of Bilbao and
FC Barcelona. While she is at home, she is watching some historical summaries of past matches
with the best goals in her tablet. Here, network, supported by video technologies such as on-
demand profiles of MPEG-DASH and HLS, and HEVC and SVC encoders, deals with users’ scalability
and on demand QoS. The HTTP based delivery let reuse common internet infrastructure and
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 67 of 107
exploit balancing and mirroring solutions over HTTP. The fragment basis let mitigation of
fluctuating bandwidth conditions especially for mobile networks and buffering impact in the
experience, while HEVC bitrate performance and SVC scalable quality minimize the bandwidth
demand.
As she moves from her home to the subway, she leaves the tablet and continues enjoying the
video on her mobile phone. Here, network, supported by video technologies such as MPEG-DASH,
HLS that enable multi-quality delivery, deals with on demand QoS switching. The media
descriptors design of video fragments based servers brings dynamic adaptation to the network
conditions and the device display features. There are lots of supporters getting in the train in the
stations as she is closer to San Mames stadium. Here, network, supported by video technologies,
such as geo-positioned CDNs, deals with users’ scalability and on demand QoS with a clear
demanding patterns related to geoposition. The setup of media proxies plays a crucial role to
provide a smooth, stable and buffering-free experience in media services.
When she met friends at the surrounding area of the stadium, all decide to make a video
conference to Mikel who did not get a ticket. Here, network, supported by video technologies such
as live profiles of MPEG-DASH and HLS, deals with live QoS. The HTTP stack makes these
technologies transversal to firewalls and NATs making possible to reuse general internet
infrastructure. Already inside the stadium Athletic gets score and journalists access to the replay
video with different angles, slow-mo and UHD quality. Helen accesses to the replay video. Here,
network, supported by video technologies such as on-demand profiles of MPEG-DASH and HLS,
deals with on demand premium QoS. The media descriptors design of video fragments based
servers enable progressive quality offer fitting business models.
Helen records a video where all the people in the stadium is singing and jumping and shares it
with Mikel and other friends. They watch it from their houses immediately. Here, network,
supported by video technologies such as HEVC and SVC encoders, and CDNs, deals with users’
scalability and on demand QoS with clear demanding patterns related to time slot. The setup of
media proxies plays a crucial role to provide a smooth, stable and buffering-free experience in
media services. HEVC bitrate performance and SVC scalable quality optimize the bandwidth
demand. The final score is 4-0 and another person in the stadium records Barcelona coach very
furious. The video gets viral and Helen gets aware of it, enjoys it and shares it with her friends.
Here, network, supported by video technologies such as CDNs, deals with users’ scalability and on
demand QoS with clear demanding patterns related to a specific content. The setup of media
proxies plays a crucial role to provide a smooth, stable and buffering-free experience in media
services.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 68 of 107
5.10. Detection and Reparation of Network Threats
Figure 25 Detection and Reparation of Network Threats
5.10.1. Rationale
In 5G, a large network of heterogeneous networks will connect many computers, mobile devices,
household devices, cars, trains, industries, etc. The communication will be thousands of times
faster than 4G. However, it can be threatened and affected by malware like viruses and worms. A
network management system is required for security issue detection and self-reparation in real
time. The terms ‘fault’, ‘problem’, ‘solution’ used in the section are related to security issues only.
As many network functions, devices and components are virtualised, many images from these
virtualizations can be compromised due to malware like viruses, worms etc. or due to some other
reasons. Therefore, even though the virtualization of network functions and the dynamic
configuration of routing significantly enhance the flexibility of future networks, on the other
hand, it also makes the networks more vulnerable as far as security threats are concerned.
Security threats like eavesdropping could be a big concern for 5G network. For example, let us
consider Figure 26(a), which depicts a tiny portion of 5G network with a few SDN routers. Here,
we observe that data from a mobile user is sent via Router1 to Router2 and then to the internet.
Let us consider that the image of Router1 is compromised by a malware and as a result it is
sending another copy of the data to the attackers via Router3. CogNet should identify the
eavesdropping and take the necessary actions. One potential indicator to identify the
eavesdropping could be the instant doubling of traffic through Router1 and sudden increase of
traffic through Router3. The eavesdropping for a compromised image can be done in two ways.
Firstly, a legitimate router is compromised and it is passing additional copy of data through an
illegitimate path. The eavesdropping at Router2 is an example of this type of eavesdropping, and
it is presented in Figure 26(b). In Figure 26, the black and red solid arrows represent regular
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 69 of 107
legitimate traffics from one router to another and the red dashed arrows represent the redundant
traffics through irregular and illegitimate paths for eavesdropping. Again, an illegitimate router,
which is compromised, can pull the traffic through it by means of masquerading e.g. address
spoofing and become a man-in-the middle and perform eavesdropping. In Figure 26(c), Router4 is
compromised and is performing the second kind of eavesdropping.
Figure 26 Eavesdropping in 5G Network
Furthermore, malicious attacks on 5G networks might occur, such as Distributed Denial of Service
(DDoS), where the intention of the attackers is to down the network instead of stealing valuable
information. The images can be compromised in the 5G network and turned into the bots to
perform the DDoS attacks. Therefore, CogNet should identify the affected images, determine the
causes of being compromised and provide solutions.
Moreover, security issue detection and correction to prevent and overcome the problems should
be performed in real time and automated (self-repairing) and it should also ensure SLA. Machine
learning could be used in order to classify future data to a certain problem category based on a
learning model built from previous data, in order to find, adapt and apply the existing solution
for that problem. ML also helps to find out unusual and unwanted pattern (i.e., outliers). The
classifier in ML can be trained up by many evaluation metrics values as features collected from
the real world 4G network, while the real data of 5G network is unavailable initially. These
evaluation metrics could be the potential indicators of compromised images in the network. For
example, key stats such as average throughput, bits in versus bits out, mean processing time for
the node increases or decreases without explanation, error log entries etc. might be helpful
features for outlier detection and these stats can be used as a feature for the machine learning
application. ML facilitates the network security related fault and threat detection and self-
reparation in 5G network.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 70 of 107
5.10.2. Presentation
Both for SDN and NFV, many virtualizations images will be required, which could become
affected and compromised due to various malwares (e.g., viruses, worms). An image can be faulty
due to a piece of software that should not be installed or running in that image. In this scenario,
we are considering issues related to security only. Therefore, a management system is required in
order to automatically detect the faulty images or devices. Furthermore, the network should be
self-reparable and intelligent to find the optimal solution in time. An additional aspect to
consider is how to incorporate the security related fault detection and auto-reparation system in
the proposed SDN and NFV based architecture. We are considering the following points as the
scope of our scenario:
Detecting potential security threats by means of network events, for example flow
statistics could be retrieved from SDN routers or switches to detect coordinated DDoS
attacks, man-in-the middle attack and eavesdropping etc.
Detecting compromised images in SDN and NFV and attempt to determine the root
cause.
Detecting unusual and uncharacteristic behaviours in various images. This can be
performed with anomaly detection algorithms.
Detecting the presence of worms in underlying hardware, which might be a targeted
virus for a targeted machine, e.g., Stuxnet.
Detecting all potential vulnerable real devices or images of virtual devices and software
to protect them from the further attack.
Detecting faults and finding solutions for fixing them using prior knowledge extracted
from the network and the existing collected security related data.
Self-learning capabilities included in the network in order to restrict further similar
attacks or problems.
5.10.3. Technical Enablers
Machine learning will be used to collect, analyse and trigger automated security counter
measures:
Feature extraction techniques can be applied to find out potential features to categorise
the faults. For example, key metrics such as average throughput, bits in versus bits out,
mean processing time for the node increases or decreases without explanation, error log
entries etc. might be helpful features for anomaly detection.
Various clustering and supervised machine learning techniques can be helpful for
detecting anomalies, faults and unwanted behaviours using the extracted features.
Feature selection techniques can be applied to reduce the number of features to make
the computation faster for various machine learning algorithms and increase the
efficiency.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 71 of 107
Supervised ML can be used to classify a problem using previous experience and several
solutions to fix it. Machine learning is suitable for picking the optimal solution and to
adapt the solution when it is required.
Link mining techniques can be applied to find out the vulnerable nodes and routes in a
network, which are directly or indirectly connected to the node having faulty images.
Moreover, the system architecture should support SDN, and NFV.
Furthermore, techniques like asemantic web, linked data etc. or new data format can be
considered and proposed for the information exchange between the network management
system and SDN or NFV. Various security and trust techniques can be considered to stop further
spreading of the malwares.
5.10.4. Story
A network will be simulated considering either real network data or artificial data or a
combination of both to evaluate various stories. In the artificial network, a significant number of
nodes will be simulated using SDN, NFV and various images for virtual components. A simulation
or prototype of security related fault detection and self-reparation management system will be
developed and connected to the simulated network in order to provide support to simulated
SDN and NFV according to the proposed architecture. A knowledge bank will be constructed by
CogNet and will become part of the system. The knowledge bank shall contain previous
experiences and can be built using real or artificial data or a combination of both. Various
clustering, machine learning and knowledge modelling algorithms will be considered in the
network management system. The network management system will then consider the following
possible situations:
If an image is simulated as compromised by worms, viruses etc. then the system will
detect the locations of the faults, the cause or type of corresponding faults, which are the
details of those simulated worms, virus etc.
Various features are extracted and fed into the machine learning mechanism to find a
solution based on previous experience.
Tasks are prioritized based on the different priority levels identified by SDN. For example,
a node is dealing with many emergency requests and all the requests are getting
sufficient bandwidth for being served through the node. Suddenly, a fault is found in an
image of the node and SDN starts routing the traffics for those emergency requests
avoiding the node. Though the SDN is providing alternative best possible solution, the
alternative is not as good as when the node was serving well. Moreover, this might also
hamper other emergency requests routed via other nodes. Therefore, it becomes crucially
important to fix the problem for that particular node as quick as possible.
CogNet can help to increase the capacity of alternative routes using the backup capacity
made of virtual provisioning by NFV such that the performance will be same while the
faulty node is under reparation.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 72 of 107
CogNet will determine other potentially compromised images and their traces. It should
restore the last uncompromised image. Version control of VNF images may need to be
maintained to support this and to find the last uncompromised image. The network
management system might apply checksum or hashing techniques to find whether an
image is tampered with or not.
CogNet will update its knowledge bank as a self-feedback after identifying and fixing a
problem. The fixing will also consider restricting further repeated similar attacks.
5.11. Follow the Sun
Figure 27 Follow the sun scenario
5.11.1. Rationale
5G networks are expected to be inherently more dynamic and chaotic in their structure than
current networks. With the advent of Network Function Virtualization (NFV), Network Functions
(NF) will no longer be tightly coupled with the hardware they are running on. Instead, when
considering network design and management a decade into the future, it is believed that many
NFs will be virtualized, and thus able to be deployed, scaled and migrated with ease and speed
unheard of in today’s networks. As a result, while the topology of the physical network
infrastructure shall evolve on a slow time scale similar to that of current networks, the dynamics
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 73 of 107
of the virtual/logical topology will undergo a dramatic change and be allowed to evolve at much
faster speeds, in service of customer needs and demands.
When considering network management in such an environment, achieving the degree of
reliability and stability that is to be expected of 5G becomes a challenge. Specifically, when the
network topology is in constant flux, it is more difficult to make decisions regarding where to
locate services, ensure the SLA a provider is committed to, and perform RCA on system faults.
CogNet is well suited for dealing with such a challenge. In current networks, network engineers
and managers often rely on their familiarity with the system behavior over time to determine the
root cause of problems and determine polices to address them. In the future networks, with the
situation changing dynamically, machine learning techniques that address all layers of the
network (physical and virtual) can be integrated in order to detect patterns and find anomalies
faster and more accurately than human operators could.
5.11.2. Presentation
Many applications will benefit by being co-located with their client base, thus reducing
consumption of network resources and improving response time. For example, applications for
drivers info might need to migrate over the course of day (i.e., follow the sun) due to roaming, in
order to be present where there is high traffic volume. Other examples include stock-exchange
applications, video streaming services (including CDNs) and more. These are all made possible in
a cost-effective manner via NFV.
However, these migration patterns, which are semi-regular, will occur in parallel with unexpected,
sudden events, which can impact performance of the applications “following the sun” and the
physical infrastructure. When these events occur, the manner in which to address these issues will
be determined by the analysis of the situation by the algorithms CogNet plans to provide.
5.11.3. Technical Enablers
In order to address this case, we will require (possibly virtual) multi-machine setups with
migration capabilities, and generator tools to generate a variety of loads on the applications
running on these setups. Additionally, the quality of the outcome of our work will be greatly
impacted by the availability of large volumes of real data, containing usage fluctuations over
time, faults and available resources. The large volume is required since that is the type of data we
wish to target in real scenarios, which will pose the challenge of scale. Real data, or data closely
resembling it, is needed from which common loads and their scale can be derived, which can
directly impact which types of algorithms are developed and brought to bear on the problem.
5.11.4. Story
In the future 5G networks, it is expected that the network management system will consider the
time of the day when allocating resources to tasks. In particular, the system will consider the first
wave of change, which considers typical daily patterns of resource usage. Moreover, the system
will consider on top of that the second wave of change which consists of events that might affect
the patterns of utilization for a period of time. For instance, in the case of a large event
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 74 of 107
happening in one region, the network resource manager should identify the event and place
dynamically the low priority tasks from the busy region to a different remote and less busy region
or postpone their execution until the data centre is less busy. Another instance is that
applications for drivers might need to migrate info over the course of day due to roaming, in
order to be present where there is high traffic volume. Other examples include stock-exchange
applications, video streaming services (including CDNs) and more. These are all made possible in
a cost-effective manner via NFV.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 75 of 107
6. Requirements
This section builds on the results of Task 2.2 and presents an initial overview of the technical and
business requirements identified for CogNet project. This represents an ongoing process in
CogNet which will be more specified with the future progress of the project.
6.1. Technical Requirements
There are various standards and metrics defined to measure network quality attributes, from end
to end services metrics, to metrics that defines a node and its corresponding link behaviour.
What is apparent is that these standards are subject to change, refinement and improvement as
new disruptive network technologies evolve. With the development of the 5th generation mobile
networks (5G) and Network function Virtualization (NFV) network topologies, the network now
has virtualized network service components that are being rolled out more and more from the
core to the edge of the Service Providers (SP) network [29] and in some instances into the
Customers Edge device.
This allows non critical traffic to be processed and warehoused closer to the SP’s edge in a
practice called smart loading, where the traffic type is error tolerant and delay insensitive. This
inevitably adds even more flexibility and complexity to the network infrastructure, but splits the
traffic into two types, error tolerant and error intolerant. Error intolerant type traffic such as
sensitive key strokes, shell interaction, cloud document editing and video conference all are
dependent on the characteristics of the network links it transverses and the quality of the end to
end connection. For error tolerant traffic, such as Voice over IP (VoIP), one characteristic of this
end to end type traffic is that it impacts Quality of Experience (QoE) because the traffic is deemed
to be interactive and responsive [28].
(a) (b)
Figure 28 Quality of Service viewpoints and Categories (a)The four viewpoints of QoS. (b)
Model for user-centric QoS categories
T1213060-02
FaxError
tolerant
Conversationalvoice and video
Voice/video messaging
Streaming audioand video
Error
intolerant
Command/control(e.g. Telnet,
interactive games)
Transactions(e.g. E-commerce,WWW browsing,
Email access)
Messaging,Downloads
(e.g. FTP, still image)
Background(e.g. Usenet)
Interactive(delay <<1 s)
Responsive(delay ~2 s)
Timely(delay ~10 s)
Non-critical(delay >>10 s)
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 76 of 107
To ensure that the perceived QoE of an end to end network connection in a 5G network, the
connection must be established in a timely manner and be maintained for the duration of the
session. There are a number of standards detailing how responsive a network connection should
be to the end user and the SP [Figure 28-a].
As specified in standards G.1010 [27], there are eight groupings that encompass a range of
applications. Some of these applications can tolerate some information loss and others cannot
[Figure 28-b]. This will help us to identify primary traffic types that CogNet will try to honour
and/or improve on. To achieve a sustainable end user QoE on a dynamically evolving network
topology, CogNet will strive to source performance and event information from management
systems hosted by the service providers (SP). These management systems track network
activities in two forms: active and passive monitoring.
1. Active monitoring for network learning
Active monitoring type usually possesses events that are hard coded in nature and
sometimes can entail injecting frames into the networks data plane. OAM and TWAMP
would be a good example of frame injection [42] [1]. Simple Network Management
Protocol (SNMP) alarms, Transaction Language 1 (TL1) alarms, OpenFlow alerts, polling
interface counters and specialised probes e.g. NetFlow and sample flow (sFlow), would
combine events together to contribute to a real time and responsive network learning.
The operator deployed active monitoring in its network could set thresholds on
resources, such as 80 percent of the saturation point of CPU load or link traffic. Based on
that, the learning system would be notices that more resources will be need when given
values are higher than the thresholds.
2. Passive monitoring for network learning
Passive monitoring is a more observational duty, where log files generated by different
resources such as cloud infrastructures, Network Management logs, Network Element
Performance Data Records (PDR), Call Data Record (CDRs), and NFV control plane logs,
are all concatenated into further operations.
Both active and passive monitoring can be used track virtualized network resources and services
that are the cornerstone of 5G networks. The evaluation metrics interested by the monitoring
components include:
Figure 29 CogNet Evaluation Metrics Categories
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 77 of 107
Machine Learning: They mainly cover: Precision, Recall, R2
, RMSE and others in which
they will be used to evaluate the accuracy of the Machine Learning algorithms developed
in the project including Supervised, Semi-Supervised and Un-Supervised Learning
Models.
Network: They mainly cover: Node and Link usage evaluation metrics, for instance packet
loss, end-to-end delay, jitter, overall network load, and others. These counters would give
a good indication on network capacity and planning in a dynamic network environment.
System Performance: They mainly cover: Response time, Scalability, Availability,
Reliability and Operational Cost in which will help testing the applicability of the
developed solutions in CogNet in a real life scenario in a telecom network.
Mobile Telecom (Quality): They mainly cover: Accessibility, Retainability and Service
Quality in which will help evaluating the impact of the developed solutions on the end
user quality provided from the Telecom Operator.
Considering the challenges that need to be tackled by CogNet, each evaluation metric is
defined in the next section 6.1.1 based on the previously described categories, and in 6.1.2, we
will further show the relation of some of these metrics to the scenarios evaluation.
6.1.1. Evaluation Metrics Definitions
Category CogNet Evaluation Metrics Metric definition
Machine
Learning
Precision The number of true positive divided
by the sum of the number of false
positive and true positive.
Recall The number of true positive divided
by the sum of the number of true
positive and false negative.
F-score A weighted average of the precision
and recall.
Area Under the Curve (AUC) for the Receiver
Operating Characteristic (ROC )
The probability that a classifier judges
a randomly chosen positive instance
higher than a randomly chosen
negative one work when working
normalised units.
Multiclass classification error rate The percentage of wrong cases in all
cases.
R-squared (R2) It is defined as explained variation
divided by total variation, whose
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 78 of 107
value is always between 0 and 100%.
Root Mean Squared Error (RMSE) The difference between values
predicted by a model and the values
actually observed from the
environment.
Mean Absolute Error (MAE) A quantity used to measure how
close forecasts or predictions are to
the eventual outcomes.
Computational time The computational time spent by
feature selections and machine
learning algorithms.
Network
Packet loss The number of packets fails to reach
their destination.
End-to-end latency The time taken for a single packet to
be transmitted across a network from
source to destination.
Overall network load The amount of spare capacity verses
the amount of traffic in a network.
Network Bandwidth The bit-rate of available or consumed
information capacity on a connection
expressed in bits / second.
Number of subscribers registered per cell One of the Cell load factors.
RAN Congestion and Contention Level Number of users sharing the same
uplink.
Average user bandwidth usage The amount of data per user over a
given time.
Propagation Latency The time spent on a packet to travel
between one place and another.
Network Tolerance The ability of the Network to deal and
adapted to change in New network
patterns.
HTTP Utilization The average HTTP throughput and
the ratio compared to the theoretical
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 79 of 107
maximum.
Initial HTTP Delay The delay between the first HTTP GET
request and the start of the playback.
Stalling Time The sum of all playback interruptions.
Number of quality switches The total number of quality switches
during the playback.
Playback quality The number of segments per
representation and the average
quality achieved.
Inter switching times The time between quality switches.
Network Jitter The variation in the delay of received
packets from source to destination.
Network Node efficiency The performance level of each node
to avoid over-scaled contexts that
affect the business model or under-
scaled contexts that affect the SLA
and the QoS.
System
performance
Response time The time elapsed from request to
response.
Availability The probability of a system working
as required at a given time.
Reliability
The probability of a system producing
expected outputs during the period
of a mission.
System scalability The capability of a system to handle a
growing amount of work.
Operational cost The time and computational power
spent by a given operation.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 80 of 107
Mobile
Telecom
(Quality)
Service performance Round-trip delay The length of time for a signal to be
sent plus the length of time it takes
for an acknowledgment of that signal
to be received.
Application
throughput
The number of transactions per
second an application can handle.
Call Setup time The time from the initiation of a call
request to the beginning of the call
message.
Network Congestion Point of
Interconnection
(PoI) Congestion
The ratio of calls failed over the PoI
(between two operators/ licensees)
due to unavailability of free circuits to
the total call requests for seizure of
PoI circuit.
Connection establishment
(Accessibility)
Traffic Channel
(TCH)
Congestion
The proportion of the number of TCH
assignment failures to the number of
TCH seizure requests.
Standalone
Dedicated
Control Channel
(SDCCH)
Congestion
The probability of failure of accessing
a stand-alone dedicated control
channel during call set up.
Connection maintenance
(Retainability)
Call drop rate The rate of call, due to technical
reasons, is cut off before the speaking
parties had finished their
conversational tone and before one
of them had hung up (dropped calls).
Connection with
good voice
quality rate
The rate of voice call with acceptable
quality.
Service quality Service drop rate The rate of service, due to technical
reasons, is cut off before the
consumer/provider terminates it.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 81 of 107
Handover
success rate
The portion of successful handovers
to handover requests.
Network availability Base Transceiver
Stations (BTSs)
accumulated
downtime
The total outage time of all BTSs in a
given time interval.
Worst affected
BTSs due to
downtime
It is defined as the total number of
worst affected BTSs in a month
divided by the total number of BTSs.
Note that the accumulated downtime
of a BTS during the period of a
month exceeds 24 hours is marked as
worst affected BTS.
6.1.2. Scenarios Evaluation
In this section, the evaluation criteria of each of the specified scenarios in section 3 will be
illustrated referring to some of the evaluation metrics defined in section 6.1.1. At this stage in our
work, it is difficult to determine the exact evaluation metric for each scenario. This is due to the
fact that, without knowing the data we will have available to us, we do not know the exact tools
we can bring to bear. To take just one example, with supervised learning usually we assume there
is a known “ground truth” to which the results of the algorithms we develop can be compared to
as part of the validation and evaluation phase. On the other hand, with unsupervised learning
techniques other, more heuristic measures are used to evaluate the quality of the algorithm
output. Hence, it is expected that the evaluation metric of each scenario will be more defined for
the scenarios with the project progress.
6.1.2.1 Large Scale Events
Since the system depends on machine learning to detect large scale events, the system will be
evaluated from machine learning perspective (Refer to the First Category evaluation metrics in
the table of the section 6.1.1). From machine learning perspective, we plan to adopt two
evaluation strategies to assess the performance of our models. First, we will provide information
extraction-style benchmarking to evaluate our models for extracting events from social streams.
To this end, we will use standard IE measures (precision, recall and F1) and test our system on
existing event datasets. Note that this evaluation will give us an estimation of how the model can
extract events in general, without focus on large events. We will also use the same methodology
to evaluate the system’s ability to predict large events that are potentially harmful for the
network. To this end, we will enhance event datasets with network consumption statistics
extracted from CogNet data.
Second, we envisage an end-to-end evaluation to estimate the impact of our system on the real
network behaviour (Refer to the Fourth Category evaluation metrics in the table of section 6.1.1).
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 82 of 107
To this end, the developed models for this scenario will be combined with the network-internal
approach in collaboration with other CogNet scenarios focusing on network demand prediction,
especially Urban Mobility Awareness and Follow the Sun. Some of the Network evaluation
metrics (Refer to the Second Category evaluation metrics in the table of section 6.1.1), as
adopted within these scenarios, to assess the performance in the end-to-end evaluation. The
selection of these particular evaluation metrics will be defined with the progress of the scenario.
On the other hand, the number of additionally served users after network reconfiguration will be
considered as a potential metric for performance evaluations.
6.1.2.2 Industry 4.0 (M2M)
As it is clear from [31] the evaluation metrics that are in the main focus of federation members
are different from those used in telecommunications. However, there are solid but implicit
relations between the two evaluation metrics sets. Understanding this relation, and its reasonable
implications for cognitive management, are two clear tasks in the scenario evaluation. Such
relation exemplified for example with an appropriate Markov chain will allow predictive
management of BOSS's network as a viable answer to those vulnerabilities experienced (or
possibly experienced) by federation members as seen from e.g. supply chain management
perspective.
As an initial approach for such evaluation the following can be suggested. We shall consider at
the beginning only three telecommunications evaluation metrics of the BOSS network, namely
packet loss, end-to-end latency and overall network load (refer to section 6.1.1 for their
definitions). Those will be stretched in a modelling to such values that will be impacting the
supply chain evaluation metrics. Respective mappings of the two metrics sets computed for a
number of situational contexts (federation size and composition, business processes multiplexing,
demand variation, etc.) shall become an initial set of benchmarking cases.
6.1.2.3 Dense Urban Area
Currently the network is not able to take localized adaptive decisions especially in regard to
differentiating the communication of multiple subscribers in terms of connectivity management,
flexible allocation of counterpart network resources, dynamic allocation of spectrum and of the
devices to the different spectrum areas. Although these features may be partially available in
some network products, their usage is very much reduced due to the need of having the adaptive
decisions a long time prior to the system having a specific congestion situation. Even worse, as
there are multiple layers of mitigation actions that could be taken, there is a strong need for
centralized decisions. However, by introducing real-time machine learning predictions targeted at
specific network areas, all these disadvantages can be drastically reduced giving the opportunity
to distribute the network management functionality while maintaining the cross-layer
management actions correlation. The following evaluations metrics for the scenario are to be
considered:
The accuracy and the time of the prediction of dense area congestions.
The system adaptation performance in terms of:
a. Decision taken for the adaptation from the momentary to the predicted situation.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 83 of 107
b. Mitigation mechanisms for adapting the network.
c. The minimal signalling required for the adaptation decision.
The scalability of the system in terms of:
a. Delay and locality of the data acquisition.
b. Delay and locality of the mitigation operations.
c. Delay and locality of the prediction decisions.
The state consistency of the system when part of the functionality is representing only
specific areas including the closeness to an optimal decision compared with the situation
when the decision is taken having a full system overview.
6.1.2.4 Interactive Street Walk (ISW)
A catalogue with a minimal set of two applications and three data sources must be available,
together with a mechanism (typically, and app), for the ISW activation and interest provision. At
least two scenarios considering different interest expressions must be considered. A user must
activate ISW and a change in interests must be implemented so metadata adaptation is
evaluated. The scenario will also be evaluated based on user movements, as such at least two
speeds (walking, jogging or cycling) must be supported. Predictive methods must be evaluated as
well.
The relevant evaluation metrics in this scenario from section 6.1.1 include:
Time to deploy the ISW environment.
Delay in the application of new interests.
Delay in application and data source handover on the MEC infrastructure.
Resources consumed at the different steps, such as computing and storage at the MEC
nodes, network bandwidth, network configuration (e.g., CLI lines, SDN rules), and
authorization at license servers (if any).
QoE of the ISW.
Adaptability to changes in applications and data sources.
6.1.2.5 Emergency Communication
The emergency scenario here presented relies heavily on the machine learning algorithms which
will be applied on different emergency models correlated to real telecommunication data used,
enabling the classification of the subscribers depending on the event and on the information
communicated. From the perspective of the machine learning and of the core network at the
same time the following metrics are considered which are defined in the previous table of section
6.1.1:
The accuracy in the discovery of the emergency event and of the classification of the
connected devices.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 84 of 107
The system performance in terms of relevant sessions established in order to acquire the
specific event information.
The system performance in term of delay in establishing the appropriate mitigation
actions including:
a. The dynamic modification of the admission control rules.
b. The usage of the new admission control rules.
c. The delay in the actuation procedures relieving the emergency.
The scalability of the system in term of liberating the system from the redundant sessions
in order to allow for the emergency communication to take place.
Adaptation of the admission control rules to the specific device characteristics, allocation
of specific subscriber profiles according to the devices’ characteristics.
Various non-functional QoS metrics will be considered by the CogNet network management
system as well to monitor the SLA enforcement. The metrics will be monitored further if
countermeasures are applied to mitigate the violations of SLAs. Again, SLA enforcement will be
monitored considering various security issues. Others considered are: the number of subscribers
registered per cell, RAN Congestion and Contention Level, average user bandwidth usage and
latency, priority level of medical services versus other services using the same RAN node ,
Medical Service Raw bandwidth and QoS requirements.
6.1.2.6 Personal Security Applications
A catalogue with a minimal set of five security functions must be available, together with a portal
for policy specification in terms close to natural language. For this evaluation, at least two
scenarios comprising three or more policy layers must be considered. Policies must be provided
for the corresponding layers. A user must connect at one of the locations, so policy composition
and deployment are evaluated. Moreover, a policy change must be implemented at the location
scenario so policy adaptation is evaluated. An attack must be simulated at the initial location so
mitigation and adaptability are evaluated. The same user must change the location, so policy
reconfiguration can be evaluated. A policy change must be implemented at the new location so
policy adaptation is evaluated. Finally, an attack must be simulated at the new location so
mitigation and adaptability are evaluated. The relevant evaluation metrics include:
Time to implement a security policy at a given location.
Delay in the enforcement of new policies.
Delay in attack detection and mitigation.
Resources consumed at the different steps, such as computing and storage at the
executing nodes, network bandwidth, network configuration (e.g., CLI lines, SDN rules),
authorization at license servers (if any).
Traffic patterns affected by the implementation.
User awareness of the different locations and their policies.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 85 of 107
6.1.2.7 Connected Cars
In Connected Cars and from the network perspective, the Ofcom Network Performance report
[39] focused on measuring the performance delivered by retail 3G and 4G networks of the UK’s
four national mobile network operators (MNOs): EE, O2, Three and Vodafone. The study was
conducted in five UK cities where 4G services were offered by all four MNOs. The study was
published in April 2015, reporting on results collected at the end of 2014. More details on the
setup can be found in [39]. The following performance for 4G was observed:
Average download speed: 14.7 Mbit/s.
Average upload speed: 13.6 Mbit/s.
Average web browsing speed (lower is better): 0.72 seconds.
Latency: Average speed (lower is better): 53.1 milliseconds.
Similar conclusions were drawn from the Everything Everywhere’s 4G network performance case
study released in 2012 [17]. The connected cars scenario can be developed in two different
configurations, depending on whether the application is based on low-level data (e.g., raw data
from camera sensors) or based on high-level data (objects or events detected) [5]:
High-level data transmission requires a medium data rate (up to 1 Mbit/s) with a very low
tolerance on errors (10-5
).
Low-level data (mainly video streaming) requires a high data rate (up to 10-20 Mbit/s)
with a medium tolerance on errors (10-2
).
The connected cars scenario also requires:
End-to-end latency of less than 5 [ms] for message sizes of about 1600 bytes.
Data is sent either event-driven or periodically with a rate of about 10 Hz.
Minimum throughput: 3Mbit/s. The system under consideration requires high reliability
rather than high throughput [48].
6.1.2.8 Urban Mobility Awareness
As the Urban Mobility Awareness scenario relies heavily on machine learning algorithms applied
on real telecom data used for predicting the service demand in different functional regions of the
cities, the scenario will be evaluated based on the following criteria from the machine learning
and performance perspective:
The accuracy of the clustering algorithms that categorizes different functionality in the
cities.
The accuracy of the service demand prediction algorithms in different clusters/functional
regions of the cities.
The speed of the service demand predictions.
The system performance benefits brought by using machine learning in terms of: a) the
savings in number of network resources utilized, and b) the machines’ utilization level.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 86 of 107
The speed of the dynamic resource allocation which allow quick adaptable resource
allocations when users move from one region to another in a city.
6.1.2.9 Massive Multimedia Consumption
Different requirements come into play for live or on-demand experiences, low latency and flat
jitter. Moreover, 5G networks must host different delivery topologies including distributed
(unicast, peer-to-peer) and centric (multicast) parties. On top of these, the setup is conducted by
extra requirements when premium subscriptions, according to the billing systems, come into the
equation. Some metrics to assess the QoE includes:
HTTP Utilization: The average HTTP throughput and the ratio compared to the theoretical
maximum.
Initial Delay: The delay between the first HTTP GET request and the start of the playback.
Stalling Time: The sum of all playback interruptions.
Number of quality switches: The total number of quality switches during the playback.
Playback quality: The number of segments per representation and the average quality
achieved.
Inter switching times: The time between quality switches.
Scalability: audience is highly volatile, with continuous changes of volume. The good
point is that this volume has a lineal relation to the number of participants and it is easily
profiled (limited set of profiles: session inter-arrival, session length, message inter-arrival,
message length).
Mobility: seamless sessions with handover network support.
Latency: minimizing delivery up to 10 -20ms.
Packet jitter: stable communications path conditions.
Head-end probes and metrics to obtain the round trip metrics (locals are not enough).
Dynamicity: enable streaming switching transparently.
Resource efficiency: the performance level of each node to avoid overscaled contexts that
affect the business model or underscaled contexts that affect the SLA and the QoS.
Communications efficiency: reduced signalling overhead.
Advanced Coding & Modulation: optimizing BW usage.
Cost efficiency: the operational cost to provide a service must fit into the business model.
6.1.2.10 Detection & Reparation Threats
In this scenario in which Machine Learning algorithms will be applied for the sake of detecting
network threats and intrusion attacks, the following initial metrics have been determined for
evaluating this scenario.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 87 of 107
Latency: The delivery time should be minimized many times considering the normal
delivery time in faulty condition.
Scalability: We have to evaluate how well the network management system can support
NFV to utilize and control the backup capacity made of virtual provisioning dynamically
when it is required.
Cost efficiency: The effect of the network management system on the cost of overall
network cost will be evaluated considering CAPEX and OPEX to find whether it is a
feasible solution considering the desire business model.
Performance: The target is to keep the percentage of the unidentified or misidentified
fault and their locations will be very low. High percentage of further vulnerable
components of the network due to the fault will be identified. The further repeated
attacks of identified and fixed problems should be fully out played.
Efficiency: The evaluation of the feature selections and machine learning algorithms will
be evaluated considering the computational time. The required time should be short
enough so that the network management system does not become the cause of
degradation of overall network efficiency and performance.
6.1.2.11 Follow the Sun
In this scenario, which has some overlap with some of the other scenarios, the goal would be to
carry out the good management work despite (in the presence of) the dynamicity. As such, the
relevant evaluation metrics and NM tasks will be used. Beyond that, we would like to evaluate our
approaches further. In this Scenario, the following are possible avenues of evaluation that we will
consider:
If annotated/enriched datasets are available, where the correct answer for an analysis
is known (for example, the root cause of a fault is known based on domain-specific
knowledge), algorithms will be evaluated by their (a) accuracy in determining the root
cause of the fault, (b) the speed in which they are able to determine this cause, and
(c) the amount of data required during training in order to achieve these results.
While the first is important for purposes of correctness, the other two will be
specifically important when considering this tool for online analysis, which will have
stricter performance requirements.
For trend analysis tools, and especially their derivatives (anomaly detection and
prediction), we will additionally evaluate the algorithms for the scenarios we consider
based on how they would behave with or without the said algorithms. For example, if
we detect a trend and use it to predict future load, which is then leveraged to make
decisions regarding placement of new VMs, we can evaluate the system performance
using several network evaluation metrics when taking the predictions into account vs.
when not.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 88 of 107
6.2. Business Requirements
As clearly indicated in the CogNet abstract, the CogNet project will focus on applying machine
learning research to enable the level of network management technology required to fulfil the 5G
vision. However, applying ML techniques and using them in 5G network management is not a
trivial task. In fact, deploying ML techniques (and network analytics at large) requires a certain
readiness from the network. This applies to two main components: the first is the ability to collect
data and made it available to the ML module, and the second is the ability to use the analytics
results in the network management system. While CogNet has very little impact on the
development of commercial NFV/SDN solutions, it can be active in the open source community
as much of the de-facto standards in this domain are based on work done in this community.
ETSI NFV which is the industry standard for defining NFV platforms, and OPNFV (the community
organization led by Linux Foundation to implement NFV as open source) is working with
Openstack to implement the NFV platform as part of Openstack projects. Monitoring and
Analytics is a major cornerstone of any management system including Openstack. Currently,
there are several projects that deal with monitoring including Ceilometer & Monasca and other
related projects including Nova, Neutron, Gnocchi and more.
CogNet is aligned with the requirements of the 5GPPP program. It is primarily focused on the
area of Cognitive Network Management, but also with focus on the areas of security, network
integrity and the management of virtual network functions and SDN as defined by the Pre
Structuring model for the 5GPPP phase 1. Applying CogNet results to networks that have the
ability to collect data and apply policy to the network management system will provide the
following business benefits:
6.2.1. Cognitive Network Management
Contribute to the reduction of CAPEX through the promotion of NFV and SDN
capabilities which are both important future telecoms technologies, helping to reduce the
initial outlay to support 5G technology and reducing the costs of future infrastructure
upgrades.
Reduce network OPEX through the use of novel processes such as SDN, dynamic network
provisioning and virtualised functions.
Improve the technical quality of service, quality of the user experience, dependability and
security of the 5G network.
Enable operators to define, market and deliver a broader range of tightly defined SLAs to
their customers.
Provide the basis for future network management architecture, with particular emphasis
on autonomics and the self-management of networks, which in turn will help to create a
basis for the standardization of policy and network management.
Contribute toward the future development of some of the component frameworks and
open source software being used by the project, such as OpenStack, OpenMano, OPNFV,
OpenDaylight.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 89 of 107
6.2.2. Security and Network Integrity
Improve the Security and reliability of the core network functions and services in the 5G
system. This can be achieved through the identification of irregular system behaviour and
generated data characteristics.
Help ensure the privacy, trust and security for end-users and services in 5G system.
Support the authentication, authorization and accounting solutions to enable and
manage service provisioning for different business areas and models.
Contribute to the relevant standardisation bodies in this area.
6.2.3. Virtual Network Platform
Support the configuration, orchestration, monitoring and lifecycle management of
virtualised network functions.
Achieve significantly improved operations and network efficiencies through the matching
service demand with resources both temporal and spatial and focusing on improving
energy efficiency of the network as a whole.
Provide the underlying network capabilities to support a rich world of 5G end user
applications.
Dramatically reduce the time required to provision and deploy new network services.
Better exploit 5G network capabilities.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 90 of 107
7. Concluding Remarks
The 5G network will pose a wide set of new challenges for network management, mainly related
to resource allocation, security and resilience, performance degradation, energy efficiency, big
data and traffic management. The CogNet project will tackle these based on the identified use
cases and scenarios presented in this deliverable. The technical and business requirements, along
with the scenarios evaluations were also presented.
Each use case captures certain expected features and requirements for the future 5G network,
from a network management perspective. Each use case is introduced by presenting its definition
and context, and is enhanced by the investigations of state-of-the-art techniques for network
management and machine learning.
To support the use cases, facilitate the identification of specific research questions and illustrate a
significant impact in a real-life context, a set of scenarios were identified and presented in this
deliverable. Each scenario is introduced by describing the problems or situations encountered, in
the context of one or more use cases, the limitations of the current state-of-the-art techniques,
and finally how CogNet will potentially leverage machine learning techniques in order to address
these.
CogNet will apply ML techniques to address the identified 5G network challenges, as presented
in the use cases and scenarios sections. The final selection of these use cases and scenarios
depends on the available data and specific requirements of each use case and scenario. The
suitable dataset will be identified based on the following properties: (i) realistic, relevant and
sufficient, and (ii) acquired from production-grade systems or through dataset extraction
techniques.
To achieve the overall goal of CogNet, this deliverable presents the methodology, some of the 5G
challenges relevant to network management, the initial set of use cases and scenarios and the
technical and business requirements. It is intended that the deliverable will not only provide the
groundwork and requirements for the architecture design but also motivate the core contribution
of other work packages. Based on the use cases and scenarios, CogNet will propose candidate
solutions to address the challenges identified in the project. These solutions will be evaluated and
validated on the basis of the given technical and business requirements.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 91 of 107
Appendix A. Use Cases to Challenges
Mapping
A.1. Just-in-Time Services
Challenges Just-in-Time Services
Network resource allocation JiT services would allow for the instant
resizing of the network according to usage
demands.
Network security & resilience Operators and customers would become
able to express, enforce and verify their
security requirements according to their
specific needs at any moment.
Network performance degradation JiT services would allow for the instant
resizing of the network, relieving existing
resources when workloads increase.
Energy efficiency JiT services would allow network managers
to keep resources active just as long as it is
necessary, yielding significant energy
savings.
Big data management For the involved algorithms to perform well,
large volumes of static data and data
streams should be ingested and processed.
Network traffic management The network will adapt traffic patterns to
service requirements, and evaluate further
requests according to present status.
A.2. Optimized Services in Dynamic Environments
Challenges Optimized Services in Dynamic
Environment
Network resource allocation The dynamic nature of VNFs will pose
challenges to allocate and estimate the
required resources in order to ensure
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 92 of 107
optimized and efficient services in the future
5G network.
Network security & resilience The dynamic nature of VNFs will pose
challenges for anomaly detection and other
security monitoring techniques.
Network performance degradation The dynamic nature of VNFs will pose
challenges to ensuring SLAs are met, due to
the need to understand what the root cause
of certain phenomenon is and address them.
Energy efficiency The dynamic nature of VNFs and the NFV
infrastructure will pose challenges and
present opportunities in this area. Once
problems and their root cause are
discovered, this information can be
leveraged to Optimize the power utilization
of the Data Centre.
Big data management N/A
Network traffic management The dynamic nature of VNFs and the NFV
infrastructure will pose challenges and
present opportunities in this area. Once
problems and their root cause are
discovered, this information can be
leveraged to route traffic in optimized
fashion.
A.3. User-Centric Services
Challenges User-Centric Services
Network resource allocation Allow for the instant adaptation of the
network.
Network security & resilience Adapt admission control rules to the specific
device characteristics.
Network performance degradation Allow for the identification of graceful
degradation patterns able to cope with user
SLAs.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 93 of 107
Energy efficiency Keep resources active just as long as they are
required, yielding significant energy savings.
Big data management Large volumes of static data and data
streams should be ingested and processed.
Network traffic management Adapt traffic patterns to applicable SLAs, and
evaluating further needs according to
present status.
A.4. SLA Enforcement
Challenges SLA Enforcement
Network resource allocation The SLA enforcement related to scaling up
and down the capacity depends on the
dynamic resource allocation capacity of the
NFV.
Network security & resilience The security and resilience related challenges
are considered to be the challenges for this
use case, as various QoSs related to those
are the part of SLA
Network performance degradation Figuring out the reliability of estimating the
minimum network performance degradation
time is a big challenge.
Energy efficiency N/A
Big data management The achievement of SLA enforced response
time will heavily depend on the processing
time of data for applying ML algorithms.
Distributed computing and Big data related
challenge will be there.
Network traffic management N/A
A.5. Situational Context
Challenges Situational Context
Network resource allocation Dynamically allocate resource to meet
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 94 of 107
requirement of users and minimize the cost.
Network security & resilience N/A
Network performance degradation Identify the performance degradation
efficiently.
Energy efficiency N/A
Big data management Large amount of data should be processed
and analysed efficiently.
Network traffic management N/A
A.6. Collaborative Resource Management
Challenges Collaborative Resource
Management
Network resource allocation Metadata and identified flow patterns will be
applied to proper resource allocation.
Network security & resilience The combination of downstream metadata
and behavioural flow patterns will allow
identifying threats and applying mitigation
strategies.
Network performance degradation Upstream metadata will inform applications,
while behavioural patterns will help in
previewing degradation cases.
Energy efficiency Pattern identification and metadata
exchange would allow network managers to
keep resources active just as long as it is
necessary.
Big data management For the involved algorithms to perform well,
large volumes of static data and data
streams should be ingested and processed.
Network traffic management The network will adapt to applications
requirements and satisfy use privacy
concerns.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 95 of 107
Appendix B. Scenarios to Use Cases
Mapping
B.1. Large Scale Events
CogNet Use Cases Large Scale Events
SLA Enforcement Ability to predict and react to changing
demand patterns is a crucial component of
SLA enforcement. A high-quality
representation of real and virtual life events
would allow for more accurate prediction of
consumption patterns.
Just-in-Time Services N/A
User-Centric Services N/A
Situational Context Combine network-internal and network-
external properties to achieve a better
representation of the situational context for
network-critical events
Optimized Services in Dynamic Environment Automated reconfiguration of the 5G
network to allow for varying load associated
with particular events. Fast automatic
detection of such events is a necessary
prerequisite here.
Collaborative Resource Management N/A
B.2. Industry 4.0 (M4I)
CogNet Use Cases Industry 4.0 (M4I)
SLA Enforcement The M4I environment can be seen as a
multiplexing platform of multiple SLA's
pertaining to different business roles (e.g. as
per supply chain management example), in
which traditional telecom evaluation metrics
are enriched by M4I-specific ones that
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 96 of 107
originate within the interaction of multiple -
often tangled - hierarchies (e.g., business
processes, factory automation, controlling,
security).
Just-in-Time Services Traffic engineering in M4I systems is the
main focus in this use case. Within M4I
systems the problem can be addressed by
Markov chain models of BOSS behaviour
within a set of performance envelopes per
profile.
User-Centric Services N/A
Situational Context The M4I systems are both consumers and
producers of situational context data at
several levels of multiple interconnected
hierarchies (e.g., factory, automation,
controlling, networking, security).
Optimized Services in Dynamic Environment To enforce and to monitor extended SLA's
the M4I systems will need to maintain M4I-
specific sensor/actuator components within
such complex environments that have to be
properly modelled to be able to protect
extended SLAs.
Collaborative Resource Management N/A
B.3. Dense Urban Area
CogNet Use Cases Dense Urban Area
SLA Enforcement The communication requirements have to be
supported also in dense urban areas.
Just-in-Time Services The main result of this scenario is a JiT
adaptation of specific network area
parameters.
User-Centric Services N/A
Situational Context N/A
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 97 of 107
Optimized Services in Dynamic Environment The network configuration is related to
partial network areas. Moreover, dynamic
network configurations and reconfigurations
are required for the complicated SLA
enforcement.
Collaborative Resource Management The collaborative resource management for
the sake of network traffic classification is
required in order to cluster and predict the
consumption of certain applications used in
the urban crowded areas.
B.4. Interactive Street Walk
CogNet Use Cases Interactive Street Walk
SLA Enforcement SLAs must be enforced to satisfy not only
end-users, but the other network customers
at play: application and data providers
Just-in-Time Services N/A
User-Centric Services ISW and the interests will be associated to
user identities and directly selected by them
Situational Context ISW need to be aware of the user locations
and adapt to network conditions and policies
there
Optimized Services in Dynamic Environment N/A
Collaborative Resource Management There is a need for applying network
classification techniques for the sake of
predicting the resources that are required for
the ISW kind of applications.
B.5. Emergency Communication
CogNet Use Cases Emergency Communication
SLA Enforcement The primary objective of the Emergency
Scenario is to evaluate the system
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 98 of 107
performance to ensure SLA enforcement.
Just-in-Time Services N/A
User-Centric Services N/A
Situational Context The emergency communication is one of the
main situational contexts to be considered.
Moreover, the penalties of violating SLA are
subject to various condition and situation for
our scenario.
Optimized Services in Dynamic Environment The network configuration is related to
admission control. Moreover, dynamic
network configurations and reconfigurations
are required for the complicated SLA
enforcement.
Collaborative Resource Management N/A
B.6. Personal Security Applications
CogNet Use Cases Personal Security Applications
SLA Enforcement Application providers and operators will have
to define the SLA under which applications
will perform, and users will be able to select
and request the enforcement of composed
SLAs, according to the required configuration
Just-in-Time Services Security services derived from the personal
applications will be created on demand
User-Centric Services Security services derived from the personal
applications will be associated to user
identities and directly selected by them
Situational Context Security services derived from the personal
applications will need to be aware of the user
locations and adapt to network conditions
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 99 of 107
and policies there
Optimized Services in Dynamic Environment On-demand creation and mitigation
strategies will require the dynamic
adaptation of the network
Collaborative Resource Management N/A
B.7. Connected Cars
CogNet Use Cases Connected Cars
SLA Enforcement The network must maintain a minimum
bandwidth allocation for each car in the
connected cars scenario in order to ensure
that no collisions will happen between the
connected cars.
Just-in-Time Services Just-in-Time services should be given to
connected cars, for instance despite their
location, such as a crowded area, or isolated
place.
User-Centric Services Personalized driving experience could be
implemented, for instance by gathering data
about previously preferred routes, and
historical traffic data coupled with traffic
analysis from real-time data.
Situational Context Allow dynamic network resource allocation
based on the context and data available from
its users.
Optimized Services in Dynamic Environment Dynamically network reconfiguration based
on data gathered from real network data.
Collaborative Resource Management Network traffic classification will allow giving
higher priority from the network resource
allocation to such critical applications related
to connected cars.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 100 of 107
B.8. Urban Mobility Awareness
B.9. Massive Multimedia Content Consumption
CogNet Use Cases Urban Mobility Awareness
SLA Enforcement Minimum SLA guarantee, based on the
functional regions in cities according to the
expected network load and consumption of
each region.
Just-in-Time Services N/A
User-Centric Services Personalized services, such as personalized
marketing, personalized shopping based on
previously defined or discovered preferences,
or personalized driving based on mobility
patterns.
Situational Context N/A
Optimized Services in Dynamic Environment N/A
Collaborative Resource Management Network traffic classification techniques for
clustering the kind of application and their
required resources based on the location and
the functional region in cities.
CogNet Use Cases Massive Multimedia Content
Consumption
SLA Enforcement Media streaming services such as OTT
services and VoIP/SIP communications brings
high volumes of data and users with highly
heterogeneous SLAs that a 5G network has
to manage.
Just-in-Time Services N/A
User-Centric Services Varying network resources and user mobility
lead to a volatile service performance and
have a significant impact on the user
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 101 of 107
B.10. Detection and Reparation of Network Threats
perceived service quality, QoE. An efficient
network can exploit patterns in media
consumptions inherently coupled to user
recall and social trends to optimize its
performance. Thus, simultaneous out-of-
band channels, such as social network trend
analytics, that can be used if interpreted in a
timely manner, to help further optimize QoE.
Situational Context In a massive multimedia content
consumption scenario, where networks
dimensioned for a specific number of
subscribers bring service degradation,
network elasticity becomes a key factor
turning the infrastructure suitable for large
number of roaming users. Preventive
modelling of traffic congestion and fast re-
routing strategies are mandatory for a media
service provider network where latency and
jitter has a strong impact.
Optimized Services in Dynamic Environment Because of the required performance of
media services, network-based dynamic
prioritization is a basic tool. Moreover, the
introduction of Software-Defined
Networking (SDN) opens a path towards the
realization of an enhanced interaction
between networks and applications. Hence, a
more dynamic and demand-based allocation
of network resources to heterogeneous
applications can be realized.
Collaborative Resource Management N/A
CogNet Use Cases Detection and Reparation of Network
Threats
SLA Enforcement The CNMS will help the controller of SDN to
prevent it from braking down in a condition
when the worms will attack an image in the
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 102 of 107
B.11. Follow the Sun
network and trying to spread though the
network to destroy images to slow down or
break down it.
Just-in-Time Services N/A
User-Centric Services The solution will be different for different
components. So, the features describing the
components should be considered beside
the features related to security faults,
anomalies, threats etc.
Situational Context The SDN is dynamic in nature to support
dramatic changes in demands with changes
in capacities. The CNMS is also considering
the situation to prioritize and solve various
problems.
Optimized Services in Dynamic Environment The components of the network including
controller of the SDN and other images will
be configured and necessary software to
deal with further attacks will be installed by
the CNMS according to the knowledge
mined from the existing previous knowledge.
Collaborative Resource Management N/A
CogNet Use Cases Follow the Sun
SLA Enforcement The challenge here would be to support
migration of virtual resources while keeping
the services these resources supply running
according to the SLA
Just-in-Time Services N/A
User-Centric Services As user base moves, so does the application
move and replicate to continue its support.
User concentration might split into several
sub-groups, each requiring its own
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 103 of 107
application tailored to its needs.
Situational Context Many users which change their location due
to an external event may influence the
placement requirements that are needed for
the “follow the sun” scenario.
Optimized Services in Dynamic Environment Will need to extract (a) causal dependencies
between the different (virtual and physical)
elements of the system so as to assist in
gaining a clear understanding of the system
state and where faults originate from. And
(b) detect trends in the behaviour of the
different (virtual and physical) elements, to
be leveraged to detect anomalies and make
predictions regarding future behaviour
Collaborative Resource Management Detecting patterns from the network
infrastructure and application service level
data in which traffic classification can be
performed for better understanding the type
of application and its requirements which will
result in a better estimation for the amount
of virtual resources required for migration.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 104 of 107
References
[1] Mixed security mode for the two-way active measurement protocol (TWAMP), 2009.
https://tools.ietf.org/rfc/rfc5618.txt.
[2] 5G connectivity to meet demanding services: examples of connected cars and mobile
health, Oct 2015. https://ec.europa.eu/digital-agenda/events/cf/ict2015/item-
display.cfm?id=15141.
[3] Bootstrapping key infrastructures, 2015. https://datatracker.ietf.org/doc/draft-ietf-anima-
bootstrapping-keyinfra/.
[4] Driverless cars, robot surgeons drive Nokia-Alcatel merger, 2015.
http://www.bloomberg.com/news/articles/2015-04-15/nokia-alcatel-union-shows-network-
scramble-ahead-of-5g-rollout.
[5] 5GPP. 5G automotive vision. 2015. https://5g-ppp.eu/wp-content/uploads/2014/02/5G-
PPP-White-Paper-on-Automotive-Vertical-Sectors.pdf.
[6] NGMN Alliance. A deliverable by the NGMN Alliance – NGMN 5G white paper. Technical
report, 2015. https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf.
[7] J.G. Andrews, S. Buzzi, Wan Choi, S.V. Hanly, A. Lozano, A.C.K. Soong, and J.C. Zhang.
What will 5G be? Selected Areas in Communications,IEEE Journal on, 32(6):1065–1082, June 2014.
[8] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy H. Katz, Andrew
Konwinski, Gunho Lee, David A. Patterson, Ariel Rabkin, and Matei Zaharia. Above the clouds: A
berkeley view of cloud computing. Technical report, 2009.
[9] L.A. Barroso and U. Holzle. The case for energy-proportional computing. Computer,
40(12):33–37, Dec 2007.
[10] R. Bolla, C. Lombardo, R. Bruschi, and S. Mangialardi. Dropv2: energy efficiency through
network function virtualization. Network, IEEE, 28(2):26–32, March 2014.
[11] Clark Buckner. Using NFV and big data to unlock network value, 2014.
http://www.informationweek.com/interop/using-nfv-and-big-data-to-unlock-network-value/d/d-
id/1298213.
[12] Sunil Chopra and ManMohan S. Sodhi. Reducing the risk of supply chain disruptions. MIT
Sloan Management Review: Spring 2014, Research Feature, 2014.
http://sloanreview.mit.edu/article/reducing-the-risk-of-supply-chain-disruptions/.
[13] Cisco. Discover new opportunities with cisco IoT system.
http://www.cisco.com/web/solutions/trends/iot/iot-products.html.
[14] Cisco. The zettabyte era — trends and analysis. 2015.
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-
vni/VNI_Hyperconnectivity_WP.html.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 105 of 107
[15] European Commission. The problem road traffic injury consequences. 2010.
http://ec.europa.eu/transport/road_safety/specialist/knowledge/postimpact/the_problem_road_tr
affic_injury_consequences/socio_economic_costs_and_the_value_of_prevention.htm.
[16] European Commission. Statistics – accidents data. 2011.
http://ec.europa.eu/transport/road_safety/specialist/statistics/index_en.htm.
[17] Epitiro. LTE test: Ee 4G network performance – an analysis of coverage, speed, latency and
related key performance indicators, from October 31st to December 20th, 2012. 2013.
http://www.epitiro.com/assets/Reports%20and%20Case%20Studies/EE%204G%20Network%20Pe
rformance%20Dec%2020%202012%20V2.0.pdf.
[18] Ericsson. 5G security – scenarios and solutions. Technical report, 2015.
http://www.ericsson.com/us/res/docs/whitepapers/wp-5g-security.pdf.
[19] Dirk Trossen et al. Networld 2020 ETP expert working group. what is 5G (really) about?
Whitepaper, 2015.
[20] ETSI. Mobile edge computing. http://www.etsi.org/technologies-
clusters/technologies/mobile-edge-computing.
[21] ETSI. Network functions virtualisation (NFV); management and orchestration. 2014.
http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-
MAN001v010101p.pdf.
[22] Matthew Finnegan. BMW: 5G is key to self-driving car deployment, Feb 2014.
http://www.computerworlduk.com/news/it-vendors/bmw-5g-could-be-key-self-driving-car-
deployment-3501253/.
[23] Gartner. Forecast: Pcs, ultramobiles and mobile phones, worldwide, 2012-2019, 2Q15
update. Gartner report, 2015.
[24] H. Hawilo, A. Shami, M. Mirahmadi, and R. Asal. NFV: state of the art, challenges, and
implementation in next generation mobile networks (vEPC). Network, IEEE, 28(6):18–26, Nov 2014.
[25] IAEA. 2011. https://www.iaea.org/NuclearPower/Downloadable/Meetings/2011/2011-10-
10-10-14-WS/11.maeoka.pdf.
[26] IETF. Pervasive monitoring is an attack. RFC7258, 2014. https://www.rfc-
editor.org/rfc/rfc7258.txt.
[27] ITU. 2011. http://www.itu.int/rec/T-REC-G.1010-200111-I.
[28] ITU-T. Series g: Transmission systems and media, digital systems and networks – quality
of service and performance. 2001.
[29] Joon-Myung Kang, Thomas Lin, Hadi Bannazadeh, and Alberto Leon-Garcia. Software-
defined infrastructure and the savi testbed. Testbeds and Research Infrastructure: Development of
Networks and Communities, 2014.
[30] Keith Kirkpatrick. Software-defined networking. Commun. ACM, 56(9):16–19, September
2013.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 106 of 107
[31] klipfolio. Supply chain metrics and kpi examples. http://www.klipfolio.com/resources/kpi-
examples/supply-chain.
[32] Gowthami Kokku. Car to car communication. 2015.
http://gowthamikokku123.blogspot.co.uk/2015/08/car-to-car-communication.html.
[33] Chin-Feng Lai, Ren-Hung Hwang, Han-Chieh Chao, M. Hassan, and A. Alamri. A buffer-
aware HTTP live streaming approach for SDN-enabled 5G wireless networks. Network, IEEE,
29(1):49–55, Jan 2015.
[34] Fidel Liberal. Multimedia content delivery in sdn and nfv-based towards 5g networks. IEEE
COMSOC MMTC E-Letter, 2015.
[35] Joe McKendrick. Predictive maintenance: Teaching old machines new tricks. 2015.
http://www.rtinsights.com/predictive-maintenance-teaching-old-machines-new-tricks.
[36] R. Mijumbi, J. Serrat, J. Gorricho, N. Bouten, F. De Turck, and R. Boutaba. Network function
virtualization: State-of-the-art and research challenges. Communications Surveys Tutorials, IEEE,
PP(99):1–1, 2015.
[37] M. Miyazawa, M. Hayashi, and R. Stadler. vNMF: Distributed fault detection using
clustering approach for network function virtualization. In Integrated Network Management (IM),
2015 IFIP/IEEE International Symposium on, pages 640–645, May 2015.
[38] Cindy Morgan. Iab statement on internet confidentiality. 2014.
https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/.
[39] OfCom. Measuring mobile broadband performance in the UK – 4G and 3G network
performance. 2015. http://stakeholders.ofcom.org.uk/binaries/research/broadband-
research/april15/Ofcom_MBB_Performance_Report_April_2015.pdf.
[40] OpenBaton. https://github.com/nfvlabs/openmano.
[41] Openmano. 2015. https://github.com/nfvlabs/openmano.
[42] Mark Prins and Richa Malhotra. Ethernet operation administration and maintenance
opportunities for the NREN community. Technical report, 2011.
https://tnc2011.terena.org/getfile/406.
[43] Nicolas Repp, Dieter Schuller, Melanie Siebenhaar, Andre Miede, Michael Niemann, and
Ralf Steinmetz. On distributed SLA monitoring and enforcement in service-oriented systems.
International Journal On Advances in Systems and Measurements, 2(1):33–43, June 2009.
[44] Damián Serranoa, Sara Bouchenaka, Yousri Koukib, Frederico Alvares de Oliveira Jr.b,
Thomas Ledouxb, Jonathan Lejeunec, Julien Sopenac, Luciana Arantesc, and Pierre Sensc. SLA
guarantees for cloud services. Future Generation Computer Systems, 54:233–246, 2016.
[45] Xiaofei Wang, Min Chen, T. Taleb, A. Ksentini, and V. Leung. Cache in the air: exploiting
content caching and delivery techniques for 5G systems. Communications Magazine, IEEE,
52(2):131–139, February 2014.
D2.1 – Initial scenarios, use cases and requirements
CogNet Version 0.9 Page 107 of 107
[46] Doug Washburn, Usman Sindhu with Stephanie Balaouras, Rachel A. Dines, Nick Hayes,
and Lauren E. Nelson. Helping cios understand "smart city" initiatives – defining the smart city, its
drivers, and the role of the CIO. 2010. Helping CIOs Understand “Smart City” Initiatives: Defining
the Smart City, Its Drivers, and the Role of the CIO.
[47] Zhen Xiao, Weijia Song, and Qi Chen. Dynamic resource allocation using virtual machines
for cloud computing environment. Parallel and Distributed Systems, IEEE Transactions on,
24(6):1107–1117, June 2013.
[48] Yuan Yao, Lei Rao, and Xue Liu. Performance and reliability analysis of IEEE 802.11p safety
communication in a highway environment. Vehicular Technology, IEEE Transactions on,
62(9):4198–4212, Nov 2013.