d2.1 initial use cases, scenarios and requirements - cognet · d2.1 – initial use cases,...

107
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

Upload: lamxuyen

Post on 27-Apr-2018

227 views

Category:

Documents


4 download

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.