Deliverable D1.1 Requirementseuwireless.eu/wp-content/uploads/2019/01/EuWireless_D1.1.pdfnational roadmaps) were studied as well as most relevant R&D projects (e.g. Fed4FIRE, 5G EVE,

H2020-INFRADEV-777517

Project: H2020- INFRADEV-777517

Project Name:

Design of the European mobile network operator for research

(EuWireless)

Deliverable D1.1

Requirements

Date of delivery: 2018/12/20 Version: 1.0

Start date of Project: 2018/01/01 Duration: 24 months


EuWireless PU i

Deliverable D1.1: Technical and operational requirements

Project Number: INFRADEV-777517

Project Name: Design of the European mobile network operator for

research

Project Acronym EuWireless

Document Number: INFRADEV-777517-EuWireless/D1.1

Document Title: Technical and operational requirements

Lead beneficiary: ISW

Editor(s): A. Flizikowski (ISW), M. Safianowska (ISW)

Authors: A. Flizikowski (ISW), Pedro Merino Gómez (UMA),

Laura Panizo (UMA), Álvaro Martín (UMA), Álvaro

Rios (UMA), Bárbara Valera (UMA), Almudena Díaz

(UMA), Jarno Pinola (VTT), Jerry Sobieski (Nordu),

Oscar Castañeda (DEKRA), M. Safianowska (ISW)

Reviewers: Jarno Pinola (VTT), Pedro Merino Gómez (UMA),

Laura Panizo (UMA), Jerry Sobieski (Nordu), Oscar

Castañeda (DEKRA), Janie Baños (DEKRA)

Dissemination Level: PU

Contractual Date of

Delivery:

2018-12-31

Work Package Leader: DEKRA

Status: Final

Version: 1.00

File Name: EuWireless_Deliverable_1.1_Technical and

Operational Requirements_1.0_Final.docx

Abstract

This document presents results of working on requirements collection in the EuWireless

project. The requirements collected here (113 items) will be used in the architecture Work

Package (WP2). These requirements will help defining the pan-European operator

comprehensive solution in the project and, in the future, will pave the way towards the

implementation of such an operator (in the follow up projects). It has to be highlighted that as

pan-European research operator concept is novel the participants of the questionnaires designed

were challenged by their own understanding of the more detailed solutions behind. Thus there

the consortium decided to also adjust the preliminary questionnaire in order to ease the strain

from respondents and simplify the questions to relief the conceptual stress and improve the

feedback from the end-users. Resulting requirements were thoroughly reviewed both internally

and by the project Advisory Board. Results of connected deliverables (especially D1.3 and

D2.1) have been considered during the work.

Keywords


EuWireless PU ii

Requirements, pan-European operator, EuWireless


EuWireless PU iii

LIST OF CHANGES

Version Date Description

0.1 18-07-23 First draft.

0.2 18-07-23 Section 2.1.2 reworked.

0.3 18-11-23 Requirements section (3) updated with new requirements

0.4 18-11-30 Major remaining comments resolved along the document,

requirement description tuned, introduction updated, updated ToC

and figure list

0.41 18-12-04 Updates and corrections introduced by UMA

0.42 18-12-05 Updates and corrections introduced by DEKRA

0.43 18-12-13 Updates and corrections introduced by VTT

0.5 18-12-15 Cleaning of the document performed by ISW

0.51 18-12-17 Introducing section 4.4.2, with questionnaire results

0.52 18-12-18 Resolving the remaining comments with partners

1.0 20-12-18 Summary of questionnaire analysis is corrected and cleaned


EuWireless PU iv

EuWireless Consortium

Universidad de Málaga UMA

DEKRA Testing and Certification DEKRA

Teknologian tutkimuskeskus VTT Oy VTT

IS-Wireless ISW

time.lex TL

NORDUnet A/S NORDU


EuWireless PU v

Executive Summary

This document contains the list of requirements that have been identified for the pan-European

Mobile Network Operator for Research, EuWireless as a result of the actions performed in the

project, including studies of the network needs, workshops, network architecture design,

questionnaires etc.

Chapter 2 of this document describes the baseline use cases that define the motivation for

EuWireless mobile network. These case studies are important sources for requirements, since

they represent a wide variety of researchers that will be potential EuWireless users. Case-studies

helped identify problems faced in the current situation by these researchers. The use cases

presented are the following: “the interconnection of an indoor testbed to licensed spectrum”,

“the extension of the GÉANT Testbed Service (GTS) with mobile network

resources/components”, and “the support for Vehicle to Everything (V2X) testing”. Section 2.3

introduces high level architecture of EuWireless operator for whom the main idea is the ability

to support some kind of private networks for research using the same resources than commercial

MNOs but as if they were isolated networks.

Chapter 3 identifies set of requirements (113) for the design stage of the EuWireless operator.

It means that these requirements will provide a solid baseline for the ongoing projects which

will need to define more software engineering requirements for the implementation stage of the

future work on establishing and enabling operation of such operator in future. Requirements

have been clustered into different types (technical, operational and legal) and elements

according to their placement in relation to the MNO network infrastructure (e.g. overall system,

access nodes, user equipment, spectrum). Methodology behind requirements collection and

structuring follows and adjusted Volere approach as well as it uses the ISO 2011, while in

general the requirement prioritization follows the RFC-style. Specific part of the requirements

are the requirements resulting from the work of task T1.4, which has focused on the connected

car use-case.

Chapter 4 describes in detail a methodological framework that was used to gather

requirements, the sources behind requirements elicitation. Especially methods that were used

are: questionnaires for collecting requirements from stakeholders, SOTA documents analysis

and case studies pioneering MNO network access for research in selected countries. Among all

the 3GPP, ETSI standards were analysed, different roadmaps (e.g. GSMA, GSA, ESFRI,

national roadmaps) were studied as well as most relevant R&D projects (e.g. Fed4FIRE, 5G

EVE, 5G VINI, 5Genesis).

Chapter 5 summarizes the results of the work performed in this deliverable.

This document will be used as a starting point for the design of the architecture and future

implementation of EuWireless.


EuWireless PU vi

Table of Contents

LIST OF CHANGES ................................................................................................................. iii

1 Introduction ........................................................................................................................... 1

2 European Mobile Network Operator for Research ................................................................ 1

2.1 Identified needs from the Case Studies ......................................................................... 2

2.1.1 Indoor Testbeds Without Licensed Spectrum ....................................................... 2

2.1.2 Lack of Mobile Network Components in GTS ..................................................... 5

2.1.3 Need for C-V2X Infrastructure for Testing ........................................................... 7

2.2 EuWireless Generic Use Cases Overview ................................................................... 11

2.2.1 Global Connectivity ............................................................................................ 12

2.2.2 Network Selection ............................................................................................... 14

2.2.3 EuWireless RAN and Subscribers ....................................................................... 16

2.3 EuWireless High-Level Architecture .......................................................................... 18

3 EuWireless Requirements ................................................................................................... 19

3.1 Interfaces and System Design (INT) ........................................................................... 20

3.2 Functional (FUN) ........................................................................................................ 25

3.3 Extensions (EXT) ........................................................................................................ 36

3.4 Operational (OPE) ....................................................................................................... 37

3.5 Management (MNG) ................................................................................................... 40

3.6 Performance (PER) ..................................................................................................... 43

3.7 Measurement and Monitoring (M&M) ....................................................................... 45

3.8 Logistical and Organizational (LOG).......................................................................... 46

3.9 Legal Aspects .............................................................................................................. 47

3.10 List of Requirements ................................................................................................... 47

4 Requirements Collection Methodology ............................................................................... 53

4.1 High-Level Approach .................................................................................................. 53

4.2 Methods and Tools ...................................................................................................... 55

4.2.1 Questionnaire ...................................................................................................... 55

4.2.2 Requirements Collection Methodology ............................................................... 56

4.3 Requirement Candidates Collection and Processing ................................................... 59

4.4 Sources for Requirement Collection ........................................................................... 62

4.4.1 State of the Art (SOTA) ...................................................................................... 62

4.4.2 Questionnaire analysis ......................................................................................... 63

4.4.3 Mobile Network Operators .................................................................................. 73

4.4.4 Standards and Specifications ............................................................................... 75

4.4.5 Other R&D Projects ............................................................................................ 77

4.4.6 Analysis of Legal Framework for Spectrum Sharing .......................................... 78

5 Conclusions ......................................................................................................................... 79


EuWireless PU vii

6 References ........................................................................................................................... 80

7 Appendices .......................................................................................................................... 82

7.1 Appendix1: Online Questionnaires ............................................................................. 82

7.1.1 Questionnaire v1.0 .............................................................................................. 82

7.1.2 Questionnaire v2.0 .............................................................................................. 86

7.2 Appendix 2: Other Requirements (to be considered) .................................................. 89

7.3 Appendix 3: Alternative prioritisation scheme for requirements ................................ 90


EuWireless PU viii

List of Figures

Figure 1. EuWireless overview ..................................................................................................... 2

Figure 2. PerformNetworks testbed overview ............................................................................... 3

Figure 3. Q4Health project overview ............................................................................................ 4

Figure 4. Architecture of GEANT testbed service (without mobile networks support) ................ 5

Figure 5. Example EuWireless demo ............................................................................................ 6

Figure 6. DSRC V2X communication. ......................................................................................... 8

Figure 7. C-V2X communication. ................................................................................................. 8

Figure 8. DEKRA test track for connected cars .......................................................................... 10

Figure 9. EuWireless general use case diagram .......................................................................... 12

Figure 10. Global Connectivity use case diagram ....................................................................... 13

Figure 11. Network selection use case diagramDeploy Private Network: .................................. 15

Figure 12. EuWireless RAN use case diagram ........................................................................... 17

Figure 13. EuWireless high-level architecture ............................................................................ 18

Figure 14. Requirement Identifier naming convention ............................................................... 20

Figure 15. Requirements hierarchy in EuWireless ...................................................................... 54

Figure 16. EuWireless requirements collection process. ............................................................ 60


EuWireless PU ix

List of Tables

Table 1. V2X Use cases .............................................................................................................. 11

Table 2. EuWireless requirement description template ............................................................... 47

Table 3. EuWireless requirement description template ............................................................... 57

Table 4. EuWireless requirement categories definition .............................................................. 60

Table 5. Requirements coverage matrix ...................................................................................... 61


EuWireless PU x

List of Abbreviations

3GPP Third Generation Partnership Project

5GTNF 5G Test Network Finland

AAA Authentication, Authorization and Accounting

AMF Access and Mobility Management Function

API Application Programming Interface

APN Access Point Name

BSW Blind Spot Warning

C-ITS Cooperative Intelligent Transport Systems

C-V2X Cellular Vehicle to Everything

CBRS Citizens Broadband Radio Service

CEPT European Conference of Postal and Telecommunications Administrations

CN Core Network

COTS Commercial Off-the-Shelf

DB Database

DCN Dedicated Core Network

DECOR Dedicated Core Network

DGPS Differential Global Positioning System

DN Distress Notification

DoA Description of Action

DSRC Dedicated Short Range Communications

EC European Commission

ECC Electronic Communications Committee

EEBL Emergency Electronic Brake Lights

eMTC Enhanced Machine Type Communications

eNB Evolved Node B

EPC Evolved Packet Core

ESFRI European Strategy Forum on Research Infrastructures

ETSI European Telecommunications Standards Institute

FCC Federal Communications Commission

FCW Forward Collision Warning

Fed4FIRE Federation for Future Internet Research and Experimentation

FEP High Fidelity Experiment Platform for Mobile Networks

GENI Global Environment of Network Innovations

GDPR General Data Protection Regulation

GLOSA Green Light Optimal Speed Advisory

GPS Global Positioning System

GSA Global Mobile Suppliers Association

GSM Global System for Mobile Communications

GSMA GSM Association

GTS GÉANT Testbed Service

GUI Graphical User Interface

H2020 Horizon 2020

HD High Definition

IMA Intersection Movement Assist

IMSI International Mobile Subscriber Identity

IoT Internet of Things

IP Internet Protocol

IT Information Technology

ITS Intelligent Transportation Systems


EuWireless PU xi

KPI Key Performance Indicator

LBO Local Breakout Offloading

LC LSA Controller

LSA Licensed Shared Access

LR LSA Repository

LTE Long Term Evolution

MEC Multi-access Edge Computing

MIMO Multiple Input, Multiple Output

MNO Mobile Network Operator

NB-IoT Narrowband IoT

NFV Network Functions Virtualization

NMS Network Management System

ODMP Open Data Management Plan

OMF Orbit Management Framework

ORD Open Research Data

OS Operating System

OSS Operations Support System

OTA Over-the-Air

OTDOA Observed Time Difference of Arrival

PLMN Public Land Mobile Network

PoD Point of Deployment

QCI QoS Class Identifier

QoE Quality of Experience

QoS Quality of Service

R&D Research and Development

RAN Radio Access Network

RAT Radio Access Technology

RSU Roadside Unit

RUP Rational Unified Process

SAS Spectrum Access System

SDN Software Defined Networking

SIM Subscriber Identity Module

SLA Service Level Agreement

SOTA State of the art

SWEBOK Software Engineering Body of Knowledge

SWIW Spot Weather Impact Warning

TTG Time To Green

UE User Equipment

V2I Vehicle to Infrastructure

V2N Vehicle to Network

V2P Vehicle to Pedestrian

V2V Vehicle to Vehicle

V2X Vehicle to Everything

VPN Virtual Private Network

VRU Vulnerable Road User

VTRFTV Vehicle Turning Right in Front of a Transit Vehicle

WLAN Wireless Local Area Network

WP Work Package

WZW Work Zone Warnings


EuWireless PU 1

1 Introduction

The deliverable D1.1 is the starting point for defining the catalogue of services offered by the

EuWireless operator in the near future. In D1.1, the consortium is providing a list of

requirements to be used in Work Package 2 (WP2) in order to design the EuWireless

functionalities and a specific architecture that satisfies these requirements from the technical

point of view (to be reported in D2.1, D.2.2, D2.3 and D2.4). This set of requirements also

considers the analysis of the state-of-art enabling technologies dealt with in the parallel task

T1.3, of WP1. Deliverables in WP2 are the actual reference documents to have a clear picture of

the features offered by EuWireless to the researchers.

To increase the readability and relation of requirements to the mobile network architecture and

their type - the requirements have been categorized into two dimensions: (a) reference to an

element in a wireless network architecture and (b) requirements grouping based on the ISO2011

categories (see section 4.2). The requirements provide a comprehensive base to define, in future,

the detailed software system requirements.

An important aspect of this document arise from the definition of three use-cases that navigate

the design of EuWireless architecture and on the other hand validate it, namely:

the interconnection of an indoor testbed to licensed spectrum,

the extension of the GÉANT Testbed Service (GTS) with mobile network

resources/components, and

the support for Vehicle to Everything (V2X) testing.

These use-cases were developed in the consortium but result from the past experiences and

observations of the partners operating in each of the three domains addressed by the use-cases.

The high level architecture that glues together the use-cases under the umbrella of EuWireless

operator is highlighted in section 2.3 but further developed in more details in deliverable D2.1

(“Initial EuWireless Architecture”). The technologies considered by the set of resulting

requirements have been validated during the process of finalizing the work on the D1.3

deliverable (“Enabling technologies”). The latter document provides a comprehensive overview

of technical solutions that should be providing a baseline for the system design. An important

substrate that helps position the requirements and eventually provides a crucial “environmental

factor” for the development of the EuWireless concepts are the legal aspects and constraints.

These aspects have been presented in the separate document D1.2 (“Analysis of regulations in

Europe”) and as such are not considered as separate requirements in this document.

To assure formally relevant and methodological approach for the collection process the

Consortium has relied on well recognized, but adjusted version, of the Volere methodology. It

has been used in the past projects where requirements were collected and was always relevant

and tailored to the projects needs. Resulting requirements were thoroughly validated both

internally by the consortium as well as provided to the members of Advisory Board of the

EuWireless.

2 European Mobile Network Operator for Research

EuWireless is the name of the pan-European research infrastructure and operator proposed to

cover the needs of the research community in mobile communications Research and

Development (R&D) during the next decade. The main novelty is the use of licensed spectrum

and other resources from commercial Mobile Network Operators (MNOs) all across Europe to


EuWireless PU 2

allow the creation of a realistic environment for experimentation. This infrastructure will be

designed in the Horizon 2020 (H2020) project EuWireless during 2018-2019, and it is expected

to be implemented as a follow up of this project with the support of the European Commission

(EC), the European Strategy Forum on Research Infrastructures (ESFRI), the EC member states

and private partners. The initial foreseen scenario (see Figure 1) is the deployment of

EuWireless as an extension to the pan-European network GÉANT1. This section provides an

overview of the new EuWireless infrastructure, focusing on some motivating needs identified

by the research community, the main use cases to be supported and the high-level architecture.

Figure 1. EuWireless overview

2.1 Identified needs from the Case Studies

EuWireless design will be validated with three different case studies:

the interconnection of an indoor testbed to licensed spectrum,

the extension of the GÉANT Testbed Service (GTS) with mobile network

resources/components, and

the support for Vehicle to Everything (V2X) testing.

These case studies are important sources for requirements, since they represent a wide variety of

researchers that will be potential EuWireless users. This section introduces the case studies and

the problems faced in the current situation by these researchers.

2.1.1 Indoor Testbeds Without Licensed Spectrum

Current small-scale testbeds, supporting the research in mobile communication in Europe, can

be represented by the facility PerformNetworks2 at UMA [1] (see Figure 2). This facility

1 https://www.geant.org/Networks/Pan-European_network/Pages/Home.aspx

2 PerformNetworks testbed. http://performnetworks.morse.uma.es


EuWireless PU 3

includes (from left to right): the User Equipment (UE) as commercial or research oriented, the

radio channel, the base stations or radio access, the core network, and the connection to the

Internet or to other facilities with different transport technologies. The whole testbed can be

configured by software to be flexible for generating specific scenarios or replacing components,

and to ensure repeatability of the experiments under the same conditions.

In Europe, there are a number of testbeds like PerformNetworks based on the idea of

reproducing the network at a small-scale inside or around a building, like NITOS3, FUSECO

4 or

w-iLab.t5. Some of these facilities are federated in the Fed4FIRE+

6 project in order to offer a

uniform remote access to researchers. However, real interconnection, like the one proposed in

EuWireless, is missing. Other facilities are software solutions to be used only as a part of an

experimental setup, like the OpenAirInterface7 led by Eurecom. These small-scale testbeds

cover cutting-edge research in any point of the network. Some examples are: scheduling policies

to share or optimize the radio access node, traffic prioritization methods for critical services,

resource allocation for Quality of Service (QoS) improvement in multimedia communications,

the use of the Software Defined Networking (SDN) and Network Functions Virtualization

(NFV) to optimize communications, energy consumption [2], etc. These research activities

contribute to keep the European academy and industry at the top of the rankings in terms of

scientific publications, PhD theses, standards and commercial products.

Figure 2. PerformNetworks testbed overview

However, small-scale testbeds have physical limitations and some relevant parts of the network

need to be emulated, with a negative impact on the results or even preventing some experiments

from being conducted. For instance, they cannot realistically represent a massive number of

users in the same radio access point, or thousands of devices for Internet of Things (IoT)

applications, nor take into consideration the complex reality of a real life deployment.

3 NITOS testbed. http://nitlab.inf.uth.gr/NITlab/nitos

4 FUSECO testbed. https://www.fokus.fraunhofer.de/go/de/fokus_testbeds/fuseco_playground

5 w.iLab.t testbed. http://ilabt.iminds.be/testbeds

6 Fed4FIRE+ project. https://www.fed4fire.eu/

7 OpenAirInterface. http://www.openairinterface.org/


EuWireless PU 4

To clarify this gap, let us consider the scenario in Figure 3. This Figure summarises the

innovations in the H2020 project Q4Health8 to improve the Quality of Experience (QoE) of live

video from the ambulance where a patient is treated by a paramedic. The video should go to the

hospital, where a doctor can send back advice to the paramedic. In addition, a second doctor,

travelling in a different ambulance, will also receive the video for additional advice. The

objective of the project is to provide innovations to increase the QoE at both sides, the hospital

and the second ambulance, in adverse network conditions like high number of users in the area,

heavy network load and mobility. In order to create a dedicated network slice from the patient’s

ambulance to the hospital, and to reduce network traffic when sending video to the second

ambulance, Q4Health consortium developed improvements at different locations: scheduling in

the Radio Access Network (RAN), SDN for backhaul configuration, Multi-access Edge

Computing (MEC) and Fog computing functionality close to the Evolved Node Bs (eNBs),

energy consumption and application level QoS optimization. Unfortunately, none of the

commercial MNOs was open to validate these solutions in their networks nor to allow the

deployment of new eNBs in their licensed spectrum. So, key features like real mobility, access

to the MNO Rx interface of the MNO network, or real deployment of MEC and fog computing

in the production network were not tested.

Figure 3. Q4Health project overview

From the experience in Q4Health and other related projects, the EuWireless consortium has

identified a number of initial requirements for the research infrastructure related to spectrum

use, like the following ones:

Standard interfaces to install R&D network functions (physical or virtual) or services at

different parts of the network. These interfaces will enable truly flexible experience of

mix-and-match approach for selecting the parts of the MNO and the research

infrastructure.

Interfaces to interconnect the EuWireless Points of Deployment (PoD) in order to

enable inter-connections between R&D hardware/software and selected components in

the research network.

Interfaces for remote management of user terminals and/or sensor devices during tests

and trials.

These requirements are also included in the exhaustive list presented in Section 3.

8 Q4Health project. http://q4health.eu/


EuWireless PU 5

2.1.2 Lack of Mobile Network Components in GTS

A second need considered at the beginning of the project is the need to expand GÉANT Testbed

service to support experimentation with mobile network components.

Software developed within the GEANT Network Project has implemented a “generic

virtualization model” (GVM) for networking components and service capabilities. This software

has been deployed within the GEANT core backbone and is offered to network researchers as

the GEANT Testbeds Service (GTS). This service allows researchers to define and realize a

bespoke network environment - spanning Europe - comprised of computational elements,

packet switching/forwarding elements, and transport circuit, all geographically located

according to user requirements (within the cities served by GTS). GTS currently utilizes

automated orchestration processes to reserve and activate high performance “at scale” networks

across GEANT and other participating National R&E Networks.

GVM is technology agnostic – it can be applied to define a wide range of desired network

research resources or functional capabilities which can then be manipulated by a common set of

lifecycle primitives and interconnected with other such virtualized resources to create complex

and large-scale network facilities. EuWireless envisions applying the Generic Virtualization

Model to wireless and cellular service components in order to create a set of virtual resources

that addresses the needs of the wireless research community. For example: The eNB base

station architecture could be defined as a “virtual eNB” with a set of attributes and capabilities

that the user (the researcher) could specify. The GVM service, using the virtualization functions,

would instantiate the resource. The GVM service includes the virtualization layer software that

allocates/partitions the necessary infrastructure components to create the resources. The user

would perceive its own dedicated eNB and would be unaware of how that eNB is insulated or

isolated from other such virtual resources of other users sharing the wireless research

infrastructure.

Figure 4. Architecture of GEANT testbed service (without mobile networks support)

EuWireless poses the notion that the GVM model could be used to even virtualize spectrum

across a metro region and manage that spectrum and the underlying physical RAN to allow

multiple users to utilize the facility in parallel.

The specific resource classes that would be defined for such a generalized virtualization will

depend upon the types of research being considered. High level complex resources (such as a


EuWireless PU 6

metro RAN) can be factored into a minimal set of more basic resource elements that can then be

composed into the high level services the best fit the user communities.

Currently, the GVM model supports computational resources in the form of bare metal servers

and virtual machines, and light weight container objects are on the roadmap. Virtualized SDN

switching/forwarding elements are offered (capable of up to 100Gbps switching), and transport

circuits up to 10Gbps. Composite resources (hierarchical constructs that allow groupings of

common sub-structures to be defined and re-used) are available and continuing to be enhanced.

Together with a graphical user interface, the GTS service (and the GVM software suite) provide

a very forward looking platform into which EuWireless can be integrated and which EuWireless

can leverage for the other non-wireless resources that the research will require.

The Generic Virtualization Model implemented in a GTS style service could provide the

flexibility to deploy advanced wireless services at many levels within the vertical structure of

wireless infrastructure and services. Specific applications could acquire the resource they need

from a pool of compute or switching infrastructure, MEC/FOG models could be evaluated and

service deployed with resources to match the size or scope of the study.

Figure 5. Example EuWireless demo

Presently, the GTS service and the GVM Software Suite do not support wireless objects.

EuWireless plans to develop the user facing resource specifications and then resource control

agents/methods to realize them. To accomplish this, the team must identify and define the

virtual objects that the research community requires. We expect this to yield a set of analogous

physical objects such as VMs, servers, base nodes, switching elements, etc.; high level

constructs such as regional cellular capacity, mobile/floating MEC resources; and/or light

weight logical network functions such as filters, NAT, etc. These sets of virtual objects can then

be factored into atomic base objects that can be implemented within GVM and can be re-

composed to construct a wide range of research facilities.

Finally, GTS and the GVM framework do not simply manage the virtualization of objects.

Implicit in this mapping of virtual resource objects to physical infrastructure is inventory

management, scheduling, allocation, authorization, etc., i.e., it is inherent in a virtualized service

architecture to provide infrastructure allocation and scheduling in addition to the configuring or

infrastructure support the virtualized service objects delivered for the user. For instance, GTS


EuWireless PU 7

manages a pool of server platforms in different cities. These physical servers act as a pool of

candidate platforms for users requesting a “virtual” bare metal server. While GTS allocates a

real physical server to the resource object, it could have as easily mapped the bare metal server

request to X86 emulation software instance. In a wireless venue, this might apply to RAN

components. So, sometimes, virtualization may require access to dedicated hardware that can be

allocated on a schedule to each virtual environment. This does not violate virtualization, it is

just a trivial case of same. While a conventional virtualizable infrastructure is preferred,

sometimes for very pragmatic reasons, the infrastructure is unable to be partitioned effectively

and must be mapped one-to-one to user requests, and shared on a time scheduled basis.

2.1.3 Need for C-V2X Infrastructure for Testing

Vehicular transportation systems are undergoing very important changes due to the appearance

of new technologies improving safety but also many other aspects such as energy saving or

infotainment. Vehicles are getting more and more connected, with the Internet, with other

vehicles, and with nearby infrastructures. New systems are quickly being developed, with

automotive brands spending many resources to improve the passengers experience in terms of

safety and non-safety functionalities. Vehicle to Everything (V2X) technologies allow vehicles

and other road users to receive the position and movement data of other users. At the same time,

the vehicles own position and movement data is broadcasted, so other users can also receive it.

A V2X device will use this information to keep the track of all relevant users around, and will

warn the driver if some potentially dangerous situation occurs. Applications running on top the

V2X protocol stack are in charge of all the necessary calculations.

2.1.3.1 Technologies

At this moment, there are two technologies vying in the V2X to become the automotive industry

standard for vehicular connectivity: Dedicated Short Range Communications (DSRC) and C-

V2X.

On the one hand, DSRC, in the US, and equivalent systems, such as Cooperative Intelligent

Transport Systems (C-ITS) in Europe, use technologies where vehicles communicate with other

vehicles, i.e. Vehicle to Vehicle (V2V), with other road users, i.e. Vehicle to Pedestrian (V2P),

and with road infrastructure, i.e. Vehicle to Infrastructure (V2I) (see Figure 6). These systems

rely on the well-known Wireless Local Area Network (WLAN) standard defined in IEEE

802.11p. DSRC enables vehicle manufacturers to develop safety applications applicable in use

cases such as Forward Collision Warning (FCW), Emergency Electronic Brake Lights (EEBL)

or Blind Spot Warning (BSW).

The Federal Communications Commission (FCC) adopted a Report and Order establishing

licensing and service rules for the DSRC Service in the Intelligent Transportation Systems (ITS)

Radio Service using the 5.9-GHz band (5.850 - 5.925 GHz) in December 2003.

On the other hand, the cellular industry is developing a set of standards, known as C-V2X, that

extends the existing cellular capabilities to provide not only safety applications but also other

non-safety applications such as coordinated driving, autonomous driving, energy saving and real

time local updates, e.g. High Definition (HD) maps. C-V2X has two ways of communication

(see Figure 7). A direct way, without network assistance, even in areas where there is no

network coverage, and a through-the-network communication known as Vehicle to Network

(V2N).


EuWireless PU 8

Figure 6. DSRC V2X communication.

C-V2X can communicate with Roadside Units (RSUs) and with cellular network providing

enhanced safety applications. RSUs are part of the road infrastructure that may be located at

intersections or in other road places allowing communication in localized areas. The advantages

of C-V2X systems are:

May use the resources and features provided by the cellular network.

May connect vehicles to any kind of object that has a sensor or cellular connectivity

(e.g. a pedestrian with a smartphone).

Double range compared to DSRC.

Better latency.

Able to provide new services such as autonomous car, etc.

Includes V2N communication.

Seems better prepared for the future.

Figure 7. C-V2X communication.

However, the DSRC 5.9 GHz band has been available in the US since more than a decade ago,

so it has been intensively tested, while C-V2X standardization is not complete and needs to be


EuWireless PU 9

completed in the future 3GPP releases. Moreover, a FCC DSRC mandate could be imminent,

meaning that the technology would be adopted by several stakeholders.

Currently, any infrastructure for testing should include the possibility to test systems with any of

these two technologies, as both systems are going to coexist in the short-medium time. Even

more, some manufacturer solutions will most probably include a hybrid system including both

DSRC and C-V2X.

2.1.3.2 Requirements

The connected car scenario has specific requirements due to the specific nature of this case

study. Following requirements must be especially taken into account:

V2X systems must support dynamic mobility and high relative velocities between

transmitter and receiver (around 300 km/h).

Safety applications require an extremely low latency.

High reliability and availability is also required for safety applications.

High capacity is a must as strong traffic is expected for some applications (e.g.

infotainment) and due to the high number of users.

Security and privacy.

The types of testing that have to be performed in this scenario are: functionality verification,

performance, privacy and security, interoperability and conformance testing. Laboratory testing,

test track and field test are required in the testbeds.

Figure 8 shows an example of test track for V2X testing.


EuWireless PU 10

Figure 8. DEKRA test track for connected cars

2.1.3.3 Connected Car Applications

Since V2X devices are moving devices by nature, testing them requires the device to move

along a predefined path with a certain velocity profile. The following table specifies the basic

list of the applications that need to be tested. This list will be growing as new use applications

are added.


EuWireless PU 11

Table 1. V2X Use cases

V2V safety V2I/I2V Safety V2I and V2V Safety

Forward Collision Warning

(FCW) Work Zone Warnings (WZW) Distress Notification

(DN)

Emergency Electronic Brake

Lights (EEBL)

Spot Weather Impact Warning

(SWIW)

Intersection Movement

Assist

Intersection Movement Assist

(IMA)

Speed & Curve Compliance Emergency vehicles

Vehicle Turning Right in Front

of a Transit Vehicle

(VTRFTV)

Railroad Crossing Violation

Warning

Blind Spot Warning (BSW) Green Light Optimal Speed

Advisory (GLOSA) / Time To

Green (TTG)

Lane Change Warning/Assist

(LCA) Red Light Violation Warning

Control Loss Warning (CLW)

C-V2X technology allows adding new V2X applications not available with DSRC, that also

need to be tested as for example:

Automated Overtake

Cooperative Collision Avoidance

High Density Platooning

See-Through

Vulnerable Road User (VRU) Discovery

Bird’s Eye View

Remote sensing and control

Remote processing for vehicles

2.2 EuWireless Generic Use Cases Overview

The analysis of the needs described above and the identification of other applications of

EuWireless (obtained from questionnaires, meetings, etc.) has conducted to the definition of

some generic use cases that represent the main goals of EuWireless.

Figure 9 shows the main uses cases identified: 1) global connectivity, 2) network selection and

3) EuWireless RAN. Use cases are represented in this document with UML diagrams. In these

generic use cases, we have identified different actors:

EuW Subscriber: A researcher looking for cellular network connectivity anywhere

EuWireless network has coverage; that is; independently of the country and MNO

providing the service. The EuW Subscriber is equivalent to an eduroam9 user in wired

networks; that is the EuW Subscriber use the same credentials to connect EuWireless

independently from his/her location.

9 https://www.eduroam.org/


EuWireless PU 12

EuW Experimenter: a researcher willing to run experiments in a private wireless

network.

EuW Extender: a researcher that adds new resources to the EuWireless network, such as

eNBs, UEs, Core Network (CN) elements, etc.

MNO: The MNO is the owner of the spectrum, RAN and CN that will be shared with

the EuWireless network.

EuW MNO: Legal entity and/or operator of the foreseen EuWireless Mobile Network

for Research.

Figure 9. EuWireless general use case diagram

In the following subsections, these use cases are described in detail. Each generic use case is

split in a number of more fine-grained use cases. We describe the generic uses cases with

diagrams that summarize the interaction between EuWireless, the users and other external

systems (e.g. the commercial MNO). The following use case diagrams are a first approximation

to the EuWireless system description and could be further adapted or combined to describe

other case studies.

2.2.1 Global Connectivity

2.2.1.1 Motivation

Internet connectivity is crucial for researchers independently of their research area: submit

papers, connect to webinars, access remote data or run experiments. In addition, researchers’

mobility is a common issue due to conference attendance or research internships. European

researchers can use EuWireless to get internet connectivity through cellular networks,

independently of their research domain, anywhere within EuWireless coverage. The global

connectivity is a service equivalent to eduroam Wi-Fi roaming service, which provides internet

connection to researchers and students in Europe using Wi-Fi.

2.2.1.2 Actors and Roles

Three actors are present in this generic use case:

EuW Subscriber: Researcher that wants to get internet access through a cellular

network.

MNO: Commercial mobile network operator that operates in the coverage area and has

an agreement with the EuW MNO.


EuWireless PU 13

EuW MNO: Research mobile network operator that has an agreement with a

commercial MNO to provide coverage in an area with subscribers.

2.2.1.3 Problem Description

In the Global Connectivity use case, a EuWireless’ subscriber (EuW Subscriber) gets internet

connectivity through the MNO networks. EuWireless only performs authentication tasks,

providing trusted subscriber information to the commercial MNO during the access procedure.

Thus, any researcher that wants to benefit from this service should be a EuW Subscriber

following the required administrative procedure (the procedure has to be defined).

Figure 10. Global Connectivity use case diagram

2.2.1.4 Initial Context

EuW MNO has an agreement with a commercial MNO to provide coverage in an area. In this

coverage area, EuW MNO has a set of end users, called EuW Subscribers, which can be

identified using traditional mechanisms. The specific identification or Authentication,

Authorization and Accounting (AAA) procedures are not considered in the description of the

use case.

2.2.1.5 Operational Flows of the Actions

Figure 10 describes the interaction of the actors and the fine-grained use cases that comprises

the global connectivity generic use case.

Request Internet Access:

o A EuW Subscriber initiates the connection procedure by requesting access to

the MNO network.

o The MNO receives the access request of the EuW Subscriber requesting

internet connectivity.

EuW Subs Authentication:

o The MNO identifies the user as a EuW Subscriber and requests EuW MNO for

authentication.

o The EuW MNO provides subscriber authentication information.

Establish Access:


EuWireless PU 14

o The MNO configures its network to provide internet access to the EuW

Subscriber.

Use Internet Connection

o The EuW Subscriber uses the internet connection.

2.2.2 Network Selection

2.2.2.1 Motivation

Experimentation in mobile networks and other verticals, such as V2X or Smart Cities, requires

in many cases large-scale deployments with special network requirements, such as low latency

or high reliability.

EuWireless can provide customized private networks with special requirements in order to

connect research testbed infrastructures with the testbed users or deploy large-scale test trials.


Four actors take part in this generic use case:

EuW Subscriber: End user or device that participates in an experiment. The EuW

Subscriber has to be connected to the research testbed using a network with special

features (e.g. performance).

EuW Experimenter: Researcher that owns and/or manages a research testbed.

MNO: Commercial mobile network operator that operates in the coverage area and has

an agreement with the EuWireless operator.

EuW MNO: Research mobile network operator that has an agreement with a

commercial operator (MNO) to provide coverage in an area with EuW Subscribers.


This generic use case allows the EuW Experimenter, which owns or manages a research testbed,

to deploy a customized private network for specific subscribers in EuWireless. The EuW

subscribers can be part of the testbed trials or not.

The private network connects the EuW Subscribers and the research testbed. Thus, the private

networks make use of the MNO RAN and the EuWireless CN.


EuW MNO has an agreement with a commercial MNO to provide coverage in an area. In this

coverage area, EuW MNO has a set of end users, called EuW Subscribers, which are associated

to a private network. The mechanisms to identify a EuW Subscriber and connect it to the

corresponding private network is not part of the use case. The EuW Experimenter and the EuW

MNO have an agreement to deploy private networks for research in EuWireless on demand. The

administrative procedure to define agreement is not part of the use case (nor the document). The

EuW MNO provides an interface to request a private network deployment. The commercial

MNO and the EuW MNO share information about EuW Subscribers, in particular the list of

subscribers that can connect to a specific EuW private network.


Figure 11 describes the interaction of the actors and the fine-grained use cases that comprises

the network selection use case.

Request Private Network:

o The EuW Experimenter requests the deployment/establishment of a customized

private network in the EuWireless infrastructure. The request must/should

include the list of EuW Subscribers that can connect to it. The interfaces to do

the request have to be defined.

o The EuW MNO receives the request and checks that the request fulfils the

agreement.


EuWireless PU 15

Figure 11. Network selection use case diagramDeploy Private Network:

o The EuW MNO allocates the resources of EuWireless and deploys a private

network with the requirements agreed with the EuW Experimenter.

Update MNO Database (DB):

o The EuW MNO updates the MNO DB with the list of EuW Subscribers that

have to be connected to the EuW Dedicated Core Network (DCN/DECOR).

Manage Private Network:

o The EuW Experimenter can manage his/her private network in order to deploy

new services, network functions, etc.

EuWireless provides a management interface to configure and manage private networks.

Currently, we consider seven network management use cases:

Add Resources: The EuW Experimenter allocates or releases network resources based

on the agreements with the EuW MNO. The Experimenter can also deploy his/her own

resources required to run experiments.

Access Experiment Results: The EuW Experimenter can access his/her experiment

results.

Access Logs: The EuW Experimenter can access network logs that complement the

experiments results.

Request Access:


the commercial MNO network.


EuWireless PU 16

o The commercial MNO receives the access request of the EuW Subscriber

requesting connection to a EuW DCN.

DCN Selection:

o The commercial MNO checks that the requested EuW DCN is available.

o The commercial MNO initiates the procedure to connect the EuW Subscriber to

the EuW DCN.

Establish Access:

o The EuW MNO checks that the EuW Subscriber has permissions to connect to

a specific private network. If so, the EuW MNO provides end-to-end

connection between the EuW Subscriber and the private network.

Use Private Network:

o The EuW Subscriber accesses to the private network to take part in the

experiments.

2.2.3 EuWireless RAN and Subscribers

2.2.3.1 Motivation

The experimentation in mobile networks and other verticals, such as V2X or Smart Cities,

requires in many cases large-scale deployments with special network requirements, such as low

latency or high reliability. EuWireless can provide, at least in some selected PoDs, its own RAN

that directly connects the EuW Subscribers to the EuW CN or to the private networks/testbeds.


EuW Subscriber: End-user or device that has to be connected to the research testbed

using special network requirements. The EuW Subscriber uses a Subscriber Identity

Module (SIM) card provided by the EuW MNO.

EuW Extender: Researcher that wants to add resources (e.g. antenna or a testbed) to the

EuWireless infrastructure.

EuW MNO: Research mobile network operator that has its own RAN in the coverage

area.


This generic use case allows the EuW Extender to extend EuWireless by adding one or multiple

elements to the network (UE, RAN, etc.). In this use case, the EuW MNO provides the RAN

sharing licensed spectrum with a commercial MNO. The agreements signed for spectrum

sharing are not part of the use case, and thus the commercial MNO has no role in the use case.

The EuW subscribers can be part of the testbed trials or not. The private network connects the

EuW Subscribers and research testbed using just the EuWireless infrastructure.


The EuW MNO has the RAN equipment/components in a specific PoD. The RAN uses licensed

spectrum, which is shared with other commercial MNOs, but these MNOs do not take part in

this use case.


EuWireless PU 17

Figure 12. EuWireless RAN use case diagram


Figure 12 shows the interaction of the actors and fine-grained use cases that comprises the

network selection use case.

Request Add Resource:

o The EuW Experimenter requests to add new resources to the EuWireless

infrastructure. The EuW Experimenter has to define some aspects, such as the

PoD where the resources have to be deployed, or the EuW Subscriber that can

use these resources. Currently, two different types of resources can be

supported:

Add new UE.

Add new eNB.

o The EuW MNO determines if the request fulfils the agreements signed with the

experimenter.

Add Resource:

o The EwW MNO can make some pre-deployment tests of the new resources to

ensure the network robustness and security of EuWireless.

o The EuW MNO deploys the requested resources in the locations (i.e. PoD)

selected by the experimenter and configures the infrastructure accordingly.

Request Access:


the EuW MNO network.

o The EuW MNO receives the access request of the EuW Subscriber.

Establish Access:


EuWireless PU 18

o The EuW MNO checks that the EuW Subscriber has permission to connect to a

specific private network that uses the new resources. If so, the EuW MNO

provides end-to-end connection between the EuW Subscriber and the private

network.

Use Private Network:

o The EuW Subscriber accesses the private network to take part in the

experiments.

2.3 EuWireless High-Level Architecture

Figure 13 summarizes the project approach to the global architecture of EuWireless. The main

idea is the ability to support some kind of private networks for research using the same

resources than commercial MNOs but as if they were isolated networks. Such private networks,

or testbeds, could for instance correspond to an outdoor testbed, a GTS virtual testbed, or a C-

V2X test track. EuWireless should work as a pan-European broker to use MNO resources in

order to produce such private networks for research.

Figure 13. EuWireless high-level architecture

In order to deploy efficiently a flexible pan-European infrastructure for research, the EuWireless

architecture relies on the concept of PoD, which represents EuWireless own resources in a

specific location.

EuWireless resources range from hardware and software of a typical mobile network operator,

such as the different components of the CN or the RAN, to the new components required to

share spectrum, e.g. in case of Licensed Shared Access (LSA), or to connect research testbeds

and configure experiments.

The proposed architecture is distributed and flexible. Each EuWireless PoD is deployed in a

specific location and can include a different set of components depending of the requirements of

the researchers and the agreements with the local commercial MNOs. The EuWireless PoDs are

interconnected in order to support pan-European and cross-border experiments. In addition, this


EuWireless PU 19

pan-European research infrastructure can be extended with new PoDs in order to improve the

coverage or support new mobile technologies.

3 EuWireless Requirements

This section presents requirements defining the pan-European mobile network operator for

research (EuWireless).

The sources of the requirements will be presented in Section 4.4 of this document. These

requirements have been collected by the consortium in the first year of the EuWireless project.

The requirements are classified according to a two-dimensional matrix as defined in Section 4.3.

The two dimensions are defined as follows:

Type of requirement (Dimension 1)

Technical

Interfaces and System Design (INT): System design aspects including interfaces,

architecture, repositories and user interfaces.

Functional Requirements (FUN): Main functionalities provided by EuWireless, but

also aspects related to experimentation topology, network provisioning capabilities,

access to the experimentation infrastructure, experiment resources sharing and

adjustment, isolation of experiment resources, mobility management, direct access

to the shared components, etc.

Extensions (EXT): Potential extension, growth, etc.

Operational

Operational requirements (OPE): Conditions required by the system to operate,

including human factors, ergonomics, availability, maintainability, reliability, and

security.

Management (MNG): Management of the infrastructure addressing user terminals,

testbeds, mobile networks, experiments, mobility and radio resources.

Performance (PER): Quantitative performance indicators (e.g. rates, velocities).

Measurement and Monitoring (M&M): Mechanisms to measure and monitor the

experiments performed in EuWireless infrastructure/network.

Logistical and Organizational (LOG): Logistical conditions needed to use the

network, such as sustenance (i.e. provision of facilities, level of support, support

personnel, spare parts, training, technical documentation, etc.), packaging, handling,

shipping and transportation.

Legal aspects:

Legal Aspects (LEG): Compliance with EU regulations.

Architecture element (Dimension 2)

Overall system (GEN): Affects several architecture elements.

User Equipment (UE): Related to the User equipment.

Access Nodes (AN): Related to the access nodes (e.g. RAN), except the spectrum

used.

Spectrum (SPE): Related to the frequencies to be used.

Transport Network (TN): Related to the network between the Access Network and

the Core network.

Core Network (CN): Core network requirements.

Interfaces MNO/Internet (SGI): Related to interfaces between network elements.

Multi-access edge computing (MEC). Related to Multi-Access Edge Computing

architecture element.

The identifier of each individual requirement (ID) is created as shown in Figure 14.

Requirement Identifier naming convention


EuWireless PU 20

Figure 14. Requirement Identifier naming convention

It has to be highlighted that further in the document there will be different names used with

regards to networks in scope of EuWireless: slicing, private networks, experiment networks.

Slicing is a technique rooted at the core of the 5G environment that enables the creation of

multiple isolated virtual networks over a common shared physical infrastructure in an efficient

way. These virtual networks can be created “on-demand” in order to meet specific needs of

applications, devices, customers or operators, as stated in D1.3. Private networks connect the

EuW Subscribers and research testbed using just the EuWireless infrastructure. Virtual Private

Networks (VPNs) could be defined as a less flexible version of a slice. Experiment network

“coverage” will be an e2e topology dependent on a use-case and may span across multi-domain

networks of different testbeds and operators depending on the definition of the final

architecture.

3.1 Interfaces and System Design (INT)

Id INT-GEN-001

Description EuWireless must provide standardised and open interfaces that are shared

between all foreseen testbeds/networks so that researchers can connect

network functions and services (physical or virtual) under the framework

of EuWireless.

Rationale Required in the generic use cases to install R&D hardware/software.

Examples include APIs and platforms for sharing virtual network

functions and common ontologies for resource specifications, data

integration and big data analysis, and sensors and IoT services.

Priority Must

Condition -

Source DoA, [7] – pp.5

Verification T

Version 1.0

Id INT-GEN-002

Description EuWireless shall provide standardised and open interfaces so that

researchers can connect services.

Rationale Required in the generic use cases to install R&D services.

Priority Must

Condition -

Source DoA

Verification T

Version 1.0


EuWireless PU 21

Id INT-GEN-003

Description EuWireless shall provide different configuration interfaces based on user

profiles.

Rationale EuWireless generic use cases.

Priority Must

Condition -

Source UMA testbed provider

Verification I

Version 1.0

Id INT-GEN-004

Description EuWireless should provide a Graphical User Interface (GUI) for private

networks/testbeds and experiments set up based on GTS GUI or similar.

Rationale Required for GTS case study.

Priority Should

Condition -

Source GTS case study

Verification I

Version 1.0

Id INT-GEN-005

Description EuWireless should support the interconnection of multiple Evolved

Packet Cores (EPCs) to a shared RAN, sharing the RAN elements and the

radio resources.

Rationale Results from standards.

Priority Should

Condition -

Source Standard 3GPP TS 23.251

Verification D

Version 1.0

Id INT-GEN-006

Description EuWireless should maintain a repository or log of past experiments.

Rationale Researchers needs.

Priority Should

Condition -

Source Consortium experience

Verification D

Version 1.0

Id INT-GEN-007

Description EuWireless should support the deployment of past experiment settings

(e.g. infrastructure configuration) and the repetition of the experiment.

Rationale Researchers needs.

Priority Should

Condition -


Verification T

Version 1.0

Id INT-GEN-008


EuWireless PU 22

Description EuWireless should provide interfaces with mobile network controller

platform.

Rationale Consortium experience.

Priority Should

Condition -


Verification D

Version 1.0

Id INT-GEN-009

Description EuWireless architectural components should encompass the underlying

network technologies in a generic way.

Rationale EuWireless shall be up-to-date even with the ongoing standardization of

future releases of 5G and beyond.

Priority Should

Condition -


Verification I

Version 1.0

Id INT-GEN-010

Description EuWireless should provide clear and updated documentation regarding

how to use EuWireless for experiments.

Rationale EuWireless experimenters needs.

Priority Should

Condition -

Source Consortium experience, Fed4FIRE reports on open calls [3],[4],[5],[6]

Verification I

Version 1.0

Id INT-GEN-011

Description EuWireless should provide a dedicated forum for information exchange

and support.

Rationale EuWireless experimenters needs.

Priority Should

Condition -


Verification I

Version 1.0

Id INT-GEN-012

Description EuWireless should provide V2X communications over the PC5 and over

LTE-Uu.

Rationale V2X communication modes defined by 3GPP for V2X use case.

Priority Shall

Condition -

Source 3GPP TS 23.285

Verification I

Version 1.0

Id INT-GEN-013


EuWireless PU 23

Description EuWireless shall create an environment to create private network for

research.

Rationale Experimentation in public networks could disrupt service to real users,

EuWireless must prevent that kind of interference.

Priority Must

Condition -

Source DoA

Verification T

Version 1.0

Id INT-GEN-014

Description EuWireless shall support multiple concurrent users in their own private

network.

Rationale To offer an attractive pan-European service to experimenters, several

users must be able to use the network at the same time, without interfering

with one another.

Priority Must

Condition -

Source DoA

Verification T

Version 1.0

Id INT-GEN-015

Description EuWireless shall be deployed in several countries to offer a pan-European

service.

Rationale The EuWireless infrastructure should not be concentrated in a geographic

area to promote equal opportunity of access and performance to

researchers located across Europe.

Priority Must

Condition -

Source DoA

Verification T

Version 1.0

Id INT-SGI-001

Description EuWireless shall define interfaces to interconnect PoDs.

Rationale EuWireless concept and generic use cases.

Priority Must

Condition -

Source DoA

Verification T

Version 1.0

Id INT-SGI-002

Description EuWireless shall define interfaces for remote configuration.

Rationale EuWireless concept and generic use cases.

Priority Must

Condition -

Source DoA

Verification T

Version 1.0


EuWireless PU 24

Id INT-SGI-003

Description EuWireless shall define interfaces to connect external R&D

infrastructures (testbeds).

Rationale End-user needs and UMA testbed case study.

Priority Must

Condition -

Source DoA, [7]

Verification D

Version 1.0

Id INT-AN-001

Description EuWireless shall support coexistence/interworking with IEEE 802.11p

V2X technologies.

Rationale Useful for experiments and V2X case study.

Priority Must

Condition -

Source Case studies

Verification D

Version 1.0

Id INT-AN-002

Description EuWireless should support coexistence/interworking with other non-

3GPP RATs (e.g. Lora, Thread, ZigBee).

Rationale Useful for experiments.

Priority Should

Condition -

Source Case studies

Verification D

Version 1.0

Id INT-AN-003

Description EuWireless should support a high density of UEs.

Rationale Required for reproducing Enhanced Machine Type Communications

(eMTC) and V2X scenarios.

Priority Should

Condition -

Source EuWireless consortium, [8]

Verification T

Version 1.0

Id INT-AN-004

Description EuWireless should support flexible distribution of RAN functionalities in

the overall network architecture.

Rationale Virtualisation of RAN resources and their flexible distribution in the

overall architecture based on test case needs are important enablers for

RAN sharing and slicing.

Priority Should

Condition -

Source DoA, [27]

Verification T


EuWireless PU 25

Version 1.0

Id INT-AN-005

Description EuWireless must support configurable joint radio resource management

(RRM) to differentiate traffic between EuWireless users and MNO’s

users, which span along the slice: from spectrum, through RAN and up to

a core network.

Rationale EuWireless should enable new algorithms to be easily introduced for

resource allocation, using the NFV/SDN interfaces and also applying data

analytics to optimize performance.

Priority Must

Condition -

Source [7] – pp.14

Verification D

Version 1.0

Id INT-SPE-001

Description EuWireless shall be capable of interfacing with multiple methods of

spectrum sharing and access e.g. LSA and Spectrum Access System

(SAS).

Rationale Required to include spectrum management frameworks into EuWireless

architecture. EuWireless should provision specific interfaces (e.g. to the

LSA Controller (LC), LSA Repository (LR)).

Priority Must

Condition -


Verification D

Version 1.0

3.2 Functional (FUN)

Id FUN-SPE-001

Description Controlled and harmonized method to access regulated spectrum shall be

provided for the users of EuWireless.

Rationale EuWireless concept, end-user needs and existing standards.

Priority Must

Condition -

Source DoA

Verification D

Version 1.0

Id FUN-SPE-002

Description Dynamic yet flexible spectrum sharing methods should be supported in

order to enable flexible utilization of regulated spectrum.

Rationale The spectrum sharing methods in RAN should support dynamic access, in

order to better adapt to the changing needs in different experiments and

trials. Besides that, EuWireless architecture should be agnostic with

respect to which particular spectrum sharing method has been chosen.

Priority Should

Condition -

Source DoA


EuWireless PU 26

Verification D

Version 1.0

Id FUN-GEN-001

Description R&D hardware/software provided by EuWireless shall get disconnected

(upon request) automatically from the commercial MNO infrastructure.

Rationale Security requirements and the critical infrastructures protection

objectives.

Priority Must

Condition -

Source DoA

Verification I

Version 1.0

Id FUN-GEN-002

Description It should be possible to utilize external base stations (e.g. one from small

testbeds) with own or operator EPCs using the MNO spectrum.

Rationale UMA testbed case study. Small testbed providers may be interested in

providing base stations and/or EPC, but the spectrum and additional

parameters have to be configured by the MNO providing the spectrum.

Priority Should

Condition -


Verification D

Version 1.0

Id FUN-GEN-003

Description Virtualization of mobile network components and services should be

supported throughout the EuWireless and MNO infrastructures.

Rationale EuWireless and MNO infrastructures should have extensive support for

virtualization of network elements and services in order to facilitate the

implementation of the overall EuWireless concept.

Priority Should

Condition -

Source DoA

Verification D

Version 1.0

Id FUN-GEN-004

Description GTS should be supported over testbed infrastructure.

Rationale If GTS is going to be the main way to interact with the testbeds or even

whole experiments, the new testbeds/components should be integrated

with GTS by utilizing the GTS Application Programming Interface (API).

Priority Should

Condition -

Source GTS case-study

Verification D

Version 1.0

Id FUN-GEN-005

Description The access to experiments should be transparent to the experimenter.


EuWireless PU 27

Rationale EuWireless private network (slice) should be selectable based on SIM

card or any other means of authentication.

Priority Should

Condition -

Source TS 123.251 V11.4.0 (2013), pp.9

Verification I

Version 1.0

Id FUN-GEN-006

Description Experimenters could utilize the GTS service to deploy his/her

experiments allocating EuWireless and MNO resources.

Rationale To use GTS in a cellular environment, GTS should be interfaced with the

resources available in mobile networks. In addition, it should be able to

delegate certain operations to external entities (a commercial MNO may

not allow direct modification of all its network elements as GTS expects).

Priority Should

Condition -

Source GTS case-study

Verification D

Version 1.0

Id FUN-GEN-007

Description EuWireless should offer various (customizable) resource sharing options

to be used by the experimenters (e.g. as defined by the 3GPP).

Rationale Various sharing options will eventually map to different maturity levels of

the “sharing solution”. It is also possible that some options will be faster

time to market than others.

Priority Should

Condition -

Source SCF191

Verification I

Version 1.0

Id FUN-GEN-008

Description EuWireless should support Commercial Off-the-Shelf (COTS) UEs and

some dedicated terminals (experimental platforms).

Rationale The terminals supported should cover: (a) regular phones and (b)

phones/UEs with extended functionalities (e.g. carrier aggregation,

Narrowband-IoT (NB-IoT), etc.) (c) vehicles with UEs on board (d) IoT

devices (e) road side units (f) and others.

Priority Should

Condition -

Source Consortium experience, questionnaire

Verification D

Version 1.0

Id FUN-GEN-009

Description EuWireless operator should support effective isolation techniques of

RAN/CN resources during the experiment and also interact with MNO

policies in order to support specific mechanism e.g. Local Breakout

Offloading (LBO) and other that help remove a strain from commercial


EuWireless PU 28

network (e.g. SGi interface) of an operator.

Rationale Required to integrate the management planes and to coordinate the

optimization mechanisms for transport networks of MNOs, e.g.,

fronthaul, midhaul or backhaul.

Priority Should

Condition -

Source Consortium experience, questionnaires

Verification D

Version 1.0

Id FUN-GEN-010

Description EuWireless shall coordinate with other MNOs broadcast services e.g. to

provide warning system services.

Rationale Requested by standards.

Priority Must

Condition -

Source 3GPP TS 23.501, p. 4.5

Verification T

Version 1.0

Id FUN-GEN-011

Description EuWireless shall offer outdoor coverage for field testing in realistic usage

environments.

Rationale Required in case studies

Priority Must

Condition -

Source DoA

Verification D

Version 1.0

Id FUN-GEN-012

Description EuWireless should support research in orchestration of ultra-dense

networks.

Rationale Topics include (but are not limited to):

Distributed cloud and RAN interworking

Implementation of network functions in software

Network elasticity and live cycle management

Orchestration and management mechanisms

Security algorithms for cloud Operating System (OS) platforms

Priority Should

Condition -

Source State of the art, [7] – pp.21

Verification D

Version 1.0

Id FUN-GEN-013

Description EuWireless should support research in transversal mobile R&D topics.

Rationale Topics include (but are not limited to):

Radio resource management

Security, privacy, and reliability at all levels


EuWireless PU 29

QoE and QoS provisioning

5G/LTE/Wi-Fi enabled MEC

Energy management

Self-organizing networks

MEC/Fog computing

Low latency communications

High Reliability

New Internet protocols for mobile networks

Priority Should

Condition -

Source State of the art, [7] – pp.21

Verification D

Version 1.0

Id FUN-GEN-014

Description EuWireless shall provide experiment validation capabilities in order to

assure fulfilment of the needs of a particular experiment.

Rationale EuWireless shall provide mechanisms to check a number of aspects, such

as Service Level Agreements (SLAs), real network capabilities, etc.

EuWireless should cooperate with MNO’s/testbed provider’s policies and

admission control in order to verify whether a requested experiment can

be provisioned and requested quality (e.g. of a network slice) eventually

guaranteed.

Priority Must

Condition -

Source DoA

Verification D

Version 1.0

Id FUN-GEN-015

Description EuWireless architecture and designed experiment provisioning, execution

and monitoring mechanisms, should support state information sharing in

communication between stakeholders to improve the quality of decision

making in management processes.

Rationale ESFRI workshops 2017.

Priority Should

Condition -

Source [7] – pp. 15

Verification I

Version 1.0

Id FUN-GEN-016

Description EuWireless shall minimize the impact on the resources of UE with limited

resources supporting V2X applications.

Rationale V2X devices could have limited resources (processing, battery, storage,

etc.).

Priority Must

Condition V2X case study

Source 3GPP TS 22.185 v15.0.0 [R-5.1-014]

Verification D


EuWireless PU 30

Version 1.0

Id FUN-AN-001

Description EuWireless should be able to interface with the RAN slicing/multi-

tenancy framework in the MNO’s infrastructure in order to better

facilitate isolation, addition and removal of R&D hardware/software for

wireless access trials.

Rationale RAN slicing is one of the main enablers for introduction of isolated

resources in the radio interface. It also facilitates EuWireless’ integration

with the MNO’s network operation and management.

Priority Should

Condition -

Source DoA

Verification T

Version 1.0

Id FUN-AN-002

Description EuWireless shall support sharing the same Public Land Mobile Network

(PLMN) to connect the UE to different EPCs.

Rationale Required by UMA testbed case study. The PLMN identifies the operator

providing the service to the user. There is a need for means to share the

same PLMN if we want to differentiate “normal” users (provided by

commercial MNO) and experimental ones who may want to access

EuWireless EPC's interfaces. Possible implementation is DCN/DECOR.

Priority Must

Condition -


Verification D

Version 1.0

Id FUN-AN-003

Description EuWireless shall support message transfer between UEs when served or

not served by the same PLMN supporting V2X communications.

Rationale Messages between UEs must arrive even if they use different PLMNs.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-005]

Verification D

Version 1.0

Id FUN-AN-004

Description EuWireless shall provide means to prioritize message transmission among

UEs supporting V2X application.

Rationale Required by the V2X case study and various applications. The connected

car system uses cellular network as well as other technologies and

systems such as road infrastructure. These technologies shall work co-

operatively.

Priority Must


Source 3GPP TS 22.185 v5.0.0 [R-5.1-006]

Verification D


EuWireless PU 31

Version 1.0

Id FUN-AN-005

Description EuWireless shall provide means to prioritize transmission of messages

according to their type (e.g. safety vs. non-safety).

Rationale Required by the V2X case study and various applications. Safety related

messages must be delivered before any other type of messages.

Priority Must


Source 3GPP TS 22.185 v15.03.0 [R-5.1-007]

Verification D

Version 1.0

Id FUN-AN-006

Description EuWireless shall be able to vary the transmission rate and range of the

V2X communication based on service conditions (e.g., UE speed, UE

density).

Rationale Some conditions, such as traffic conditions, may require that the

EuWireless network needs to modify some transmission parameters to

adapt to such conditions. For example, UEs at high speed require a

different data rate from the network; also the range of V2X

communication may need to be reduced in locations with a heavy density

of UEs.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-008]

Verification D

Version 1.0

Id FUN-AN-007

Description EuWireless shall inform to the UE whether it supports V2X.

Rationale Information about the support or lack of support of V2X services must be

broadcasted by the EuWireless network, so any device connecting to the

network will be aware whether V2X service is available.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-010]

Verification D

Version 1.0

Id FUN-AN-008

Description The experiment network (or slice) shall provide means for an application

server and the RSU to control the area and the size of the area where the

messages are being distributed.

Rationale Required for effective information exchange patterns in V2X case study.

The V2X system shall/may include several elements additionally to the

network such as RSUs, and a V2X Application Server. There should be

means provided by EuWireless and the underlying MNO network

infrastructure (e.g. MEC, LBO) that support defining information

exchange patterns while ensuring certain level of SLA to be met.

Priority Must


EuWireless PU 32


Source 3GPP TS 22.185 v15.0.0 [R-5.1-011]

Verification A

Version 1.0

Id FUN-AN-009

Description EuWireless should make available any supported positional accuracy

improvement techniques, e.g. Differential Global Positioning System

(DGPS) and/or Observed Time Difference of Arrival (OTDOA), in a

resource efficient way to a subscribed UE supporting V2X application.

Rationale If EuWireless has any means to improve the accuracy of the UEs

positioning, it should make these techniques to UEs subscribed to a V2X

service.

Priority Should


Source 3GPP TS 22.185 v15.0.0 [R-5.1-015]

Verification A

Version 1.0

Id FUN-AN-010

Description The network shall be capable of transferring periodic broadcast messages

between two UEs supporting V2X application with variable message

payloads.

Rationale The network must fulfil V2X message size requirements of 50-300 bytes,

not including security-related message component.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.2-2-001]

Verification D

Version 1.0

Id FUN-AN-011

Description EuWireless shall be capable of transferring event-triggered messages

between two UEs supporting V2X application with variable message

payloads.

Rationale The network must fulfil V2X message size requirements that can be up to

1200 bytes, not including security-related message component.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.2-2-002]

Verification D

Version 1.0

Id FUN-AN-012

Description EuWireless shall be able to distribute information in a resource efficient

way to large numbers of UEs supporting V2X application.

Rationale This requirement provides a way to distribute information to many UEs at

the same time, i.e., some kind of broadcasting information. Moreover, this

requirement calls for additional components to be provided in the MNO

network that enable “information distribution” as close to access network

as possible (e.g. MEC, LBO).


EuWireless PU 33

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-009]

Verification A

Version 1.0

Id FUN-AN-013

Description EuWireless should support research in topics related to spectrum

management and antenna techniques.

Rationale Research topics include (but are not limited to):

Radiofrequency device design solutions for 5G mm-wave

communications systems.

Antenna design solutions for 5G mm-wave communication

systems.

Smart communication techniques, such as beamforming, Multiple

Input, Multiple Output (MIMO), distributed-MIMO, massive-

MIMO, etc.) for 5G mm-wave communication systems.

Antenna measurement systems (anechoic and reverberation

chambers) and Over-the-Air (OTA) measurement systems at mm-

wave frequencies.

Priority Should

Condition -

Source State of the art

Verification D

Version 1.0

Id FUN-CN-001

Description EuWireless should be able to interface with the CN (and transport)

slicing/multi-tenancy in the MNO’s infrastructure in order to facilitate

addition and removal of R&D hardware/software for networking and

service trials.

Rationale Existing legal constrains. Slicing also facilitates EuWireless’ integration

with the MNO’s network operation and management.

Priority Should

Condition -

Source DoA

Verification A

Version 1.0

Id FUN-CN-002

Description In the information broadcast system, each cell in shared RAN shall

include information concerning available core network operators in the

shared network. The available core network operators shall be the same

for all cells of a Location Area in a shared RAN.

Rationale Results from standards.

Priority Must

Condition -

Source TS 123.251 V11.4.0 (2013), section 4.2.2

Verification D

Version 1.0


EuWireless PU 34

Id FUN-CN-003

Description UE shall show the name of the PLMN-id it has registered with. In case of

a shared network, it is the PLMN-id of the chosen core network operator.

Rationale Results from standards analysis.

Priority Must

Condition -

Source TS 123.251 V11.4.0 (2013), section 4.3

Verification I

Version 1.0

Id FUN-CN-004

Description EuWireless should support research in topics related to orchestration of

ultra-dense networks.

Rationale State of the art includes topics such as:

NFV, NVF Infrastructure, and Virtual Infrastructure Managers

Priority Should

Condition -

Source State of the art

Verification D

Version 1.0

Id FUN-UE-001

Description Experimenters’ UEs shall behave as regular UEs in conventional

networks with respect to Access and Mobility Management Functions

(AMF).

Rationale The switching to EuWireless CN or private networks/slices for

experimentation, Access Point Name (APN), etc., should be performed by

standards based procedures. In this way, EuWireless infrastructure can be

introduced into a MNO network in a seamless way.

Priority Must

Condition -


Verification I

Version 1.0

Id FUN-UE-002

Description EuWireless should support UE roaming.

Rationale Researchers should be able to perform experiments, also remotely, in

different European countries. This requires support for international

roaming.

Priority Should

Condition -

Source DoA

Verification D

Version 1.0

Id FUN-UE-003

Description EuWireless shall support various types of traffic from experimenters, also

ones which would otherwise be not allowed (or require separate

agreements) in a commercial MNO network (e.g. video). Still the traffic

flow(s) characteristics should be policed/shaped to fit within the agreed


EuWireless PU 35

SLA.

Rationale Required to enable virtually unrestricted data traffic profiles for

experiments, as it is an important showstopper within today’s MNO

networks.

Priority Must

Condition -


Verification D

Version 1.0

Id FUN-UE-004

Description A UE supporting V2X application shall be able to be pre-configured by

the 3GPP network with parameters to be used for the transmission and

reception of messages when not served by E-UTRAN supporting V2X

communication.

Rationale The UE shall be able to communicate when it is not served by E-UTRAN.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-002]

Verification D

Version 1.0

Id FUN-UE-005

Description A UE supporting V2X application shall be able to transmit and receive

messages when served or not served by E-UTRAN supporting V2X

communication

Rationale The UE shall be able to communicate when it is or not served by E-

UTRAN.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-003]

Verification D

Version 1.0

Id FUN-UE-006

Description An RSU shall be able to transmit/receive messages to/from a UE

supporting V2X application.

Rationale The RSU shall communicate with other UE devices.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-004]

Verification D

Version 1.0

Id FUN-UE-007

Description A UE supporting V2X application shall be able to identify whether E-

UTRAN supports V2X communication.

Rationale The UE shall identify if the E-UTRAN allows V2X communications.

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-010]


EuWireless PU 36

Verification D

Version 1.0

Id FUN-MEC-001

Description EuWireless shall provide means for distribution of messages from a UE

supporting V2X application to locally relevant application servers.

Rationale Part of the functionality of the V2X application server (responsible of

managing the V2X service) may be transferred to local application servers

(reduce traffic and latency).

Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-5.1-011a]

Verification D

Version 1.0

3.3 Extensions (EXT)

Id EXT-GEN-001

Description EuWireless should support large scale testing, including cross border

testing.

Rationale Required in V2X case study.

Priority Should

Condition -

Source V2X case study

Verification I

Version 1.0

Id EXT-GEN-002

Description EuWireless should support advanced experiment resource planning.

Rationale Required to plan resources allocation in the future.

Priority Should

Condition -


Verification I

Version 1.0

Id EXT-SGI-001

Description EuWireless should support the inclusion of new or existing remote

outdoor/indoor testbeds.

Rationale Required for use cases. There should be procedures and processes defined

by EuWireless architecture (for interfaces see INT-SGI-003) to facilitate

inclusion of new testbeds. These processes/procedures need to be

identified and aligned between EuWireless and MNOs, so that they are

manageable and accountable, but first of all enable EuWireless operation.

Priority Should

Condition -


Verification I

Version 1.0


EuWireless PU 37

3.4 Operational (OPE)

Id OPE-SGI-001

Description EuWireless shall ensure the secure interconnection of new or existing

testbed.

Rationale Secure communication need to be assured for both data and control

connections between MNO, EuWireless and a testbed provider in order to

fulfil security requirements of the flows. It can be implemented e.g. as

Virtual Private Network (VPN) or other secure protocol and/or additional

mechanisms.

Priority Must

Condition -


Verification D

Version 1.0

Id OPE-GEN-001

Description EuWireless shall offer state-of-the-art trust, identity and security enablers

for its subscribers.

Rationale Utilisation of EuWireless infrastructure must be safe for its users and for

the user data.

Priority Must

Condition -

Source DoA

Verification I

Version 1.0

Id OPE-GEN-002

Description EuWireless shall offer multitude of privacy preserving technologies and

techniques for user data anonymization, encryption, etc.

Rationale Required in order not to violate any data/user preserving regulations in

EU, e.g. the General Data Protection Regulation (GDPR).

Priority Must

Condition -

Source User needs

Verification I

Version 1.0

Id OPE-GEN-003

Description EuWireless shall support end-to-end encryption and isolation of all

communication and test traffic.

Rationale Required to guarantee the privacy of the EuWireless subscribers and their

tests. According to the Report from the EU/US Future Networks

Workshop [7] there is accelerating drive to encrypt user data as well as

protocol headers, which will render useless existing methods for

transferring and maintaining relevant network information that today are

implicit in nature (i.e., they use deep packet inspection).

Priority Must

Condition -

Source DoA, [7]

Verification D

Version 1.0


EuWireless PU 38

Id OPE-GEN-004

Description Isolation between the data traffic originating from the EuWireless

experiments and the user data traffic in an MNO network shall be

guaranteed.

Rationale Traffic related to experiments should never interfere with MNO user data.

Priority Must

Condition -

Source User needs

Verification D

Version 1.0

Id OPE-GEN-005

Description EuWireless shall implement authentication, authorisation and accounting

mechanisms.

Rationale Needed for secure subscriber management.

Priority Must

Condition -

Source EuWireless use cases

Verification I

Version 1.0

Id OPE-GEN-006

Description EuWireless subscriber identification, authentication and authorization

shall be supported through both MNO and EuWireless access networks.

Rationale The user should be able to authenticate with the EuWireless network

using any device.

Priority Must

Condition -

Source EuWireless use cases

Verification D

Version 1.0

Id OPE-GEN-007

Description The UE utilised by EuWireless subscribers during trials shall be

identifiable in the network.

Rationale The device must be identified in the network as a requirement of the

3GPP protocols.

Priority Must

Condition -

Source EuWireless use cases and 3GPP standards [9][10][11]

Verification D

Version 1.0

Id OPE-GEN-008

Description EuWireless shall provide an option for tests/measurements without end-

to-end encryption and/or with anonymised data.

Rationale Experiments related to the control/data plane functionality of the network

must be able to access this traffic unencrypted.

Priority Must

Condition -


EuWireless PU 39

Source User needs

Verification D

Version 1.0

Id OPE-GEN-009

Description EuWireless must be able to track resources being used within experiment

(experiment network) and deliver accounting data to the business

processes.

Rationale Accountability of the EuWireless services.

Priority Should

Condition -


Verification I

Version 1.0

Id OPE-GEN-010

Description Both EuWireless and the commercial network operator shall be able to

charge for network resource usage when messages are transferred by a UE


Rationale Required by standards.

Priority Must

Condition -

Source 3GPP TS 22.185 v15.0.0 [R-5.1-013]

Verification I

Version 1.0

Id OPE-GEN-011

Description The V2X network entities shall be able to authenticate the source of the

received data communications.


Priority Must

Condition -

Source 3GPP TS 33.185 v14.1.0

Verification D

Version 1.0

Id OPE-GEN-012

Description The transmission of data between V2X network entities shall be integrity

protected.


Priority Must

Condition -


Verification D

Version 1.0

Id OPE-GEN-013

Description The transmission of data between V2X network entities shall be

confidentiality protected.


Priority Must


EuWireless PU 40

Condition -


Verification D

Version 1.0

Id OPE-GEN-014

Description The transmission of data between V2X network entities shall be protected

from replays.


Priority Must

Condition -


Verification D

Version 1.0

Id OPE-GEN-015

Description The network shall provide bullet-proof security and privacy.

Rationale SIM/International Mobile Subscriber Identity (IMSI) only provides

network authentication, but does not protect privacy; MNOs must not be

able to re-construct identity, location and speed of connected car users.

Vehicles should communicate without pre-shared keys.

Priority Must

Condition -

Source Optimizing 5G for V2X, [38]

Verification I

Version 1.0

Id OPE-GEN-016

Description EuWireless should provide means to support cyber security scanning of

the new elements (software and hardware) introduced by experimenters

when performing dedicated experiments with new hardware and software

solutions.

Rationale Any new hardware or software introduced by experimenter (based on

prior agreement with EuWireless operator) must be subject to formal and

practical verification of its vulnerability level and only hardware and

software components that have passed such control can be attached to a

network slice under consideration.

Priority Should

Condition -

Source [7]

Verification I

Version 1.0

3.5 Management (MNG)

Id MNG-UE-001

Description EuWireless shall provide mechanisms to manage and configure the UE

and/or sensor device through a remote connection.

Rationale Remote operation of UE should be possible through EuWireless and

MNO infrastructures.

Priority Must


EuWireless PU 41

Condition -

Source DoA

Verification T

Version 1.0

Id MNG-UE-002

Description EuWireless should provide mechanisms to manage and configure the UE

and/or sensor device through an MNO network (Over-The-Air).

Rationale EuWireless shall provide signalling commands to the UE to configure

different parameters (Internet Protocol (IP) address, APN, QoS Class

Identifier (QCI), etc.) and trigger various procedures (attach, handover,

etc.), so researcher has a wide range of possibilities to test.

Priority Should

Condition -


Verification D

Version 1.0

Id MNG-GEN-001

Description EuWireless must provide management and control interfaces of network

components under test.

Rationale EuWireless has to provide mechanisms to manage and configure any

network component to be tested.

Priority Must

Condition -


Verification T

Version 1.0

Id MNG-GEN-002

Description EuWireless shall provide default network configurations (profiles) that

can be directly used by the researchers.

Rationale Entering the network of an operator for experimentation should be

comparable in complexity to preparing experiment in other testbeds, such

as Fed4FIRE, not harder.

Priority Must

Condition -

Source Experience from a network operator.

Verification D

Version 1.0

Id MNG-GEN-003

Description EuWireless should support different experiment definition languages.

Rationale EuWireless shall support (and be compatible with) most popular

experiment definition tools/languages (e.g. ns-2/ns-3, Python, etc.), which

are currently most popular within the online experimentation testbeds

(F4F, GENI, etc.).

Priority Should

Condition -

Source EuWireless questionnaire

Verification I


EuWireless PU 42

Version 1.0

Id MNG-GEN-004

Description EuWireless shall store used network and UE configuration (e.g. channel

models, user profiles, etc.) in a way they can be reused.

Rationale EuWireless should enable capturing, pre-processing and publishing

research data such as channel models, propagation models, and mobility

models.

Priority Must

Condition -


Verification I

Version 1.0

Id MNG-GEN-005

Description EuWireless network and UE configuration shall be stored in a recognized

data format.

Rationale EuWireless experiment management platform should provide support for

exposing metadata about the network configuration (and experimenting)

capabilities in place. Priority Must

Condition -


Verification I

Version 1.0

Id MNG-GEN-006

Description EuWireless management platform should enable the MNOs with means

for flexible customization of which parts of its networks are available for

sharing and under which conditions.

Rationale The process of defining sharing rules and conditions should be flexible so

that the MNO can adjust its settings to the business strategy and

economical needs. For example, the platform should enable the following

options:

Identifying the eNBs available for sharing (e.g. area-based,

hierarchical sharing e.g. macro vs small cell).

Identifying under what time constraints eNB (or its resources) is

available for sharing.

Defining the resources available for sharing in a given part of the

infrastructure or geographical area.

Priority Should

Condition -

Source Consortium experience, questionnaire

Verification I

Version 1.0

Id MNG-GEN-007

Description Different agreements shall be stablished in order to connect MNOs or

testbeds to EuWireless platform. Based on such agreements specific

experiment capabilities will be available.

Rationale The real capabilities of MNO/testbed/UEs shall be reflected under various


EuWireless PU 43

information databases.

Priority Must

Condition -


Verification I

Version 1.0

Id MNG-GEN-008

Description EuWireless should provide common management platform and operations

framework addressing the issue of inter-testbed connectivity and

federation, or extending the federation concept from testbed-level to

(wireless) node level, enabling the creation of heterogeneous testbed

infrastructures through mixing platforms owned by different parties.

Rationale Different networks and their elements should be available in a fine-

grained way for inclusion under the umbrella of new experiments.

Priority Must

Condition -

Source EuWireless questionnaire, [7] – pp.9

Verification I

Version 1.0

3.6 Performance (PER)

Id PER-GEN-001

Description The radio access network shall be capable of transferring messages via

3GPP network entities between a UE and an application server both

supporting V2N application with an end-to-end delay no longer than 1000

ms.


Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-2. 2.1-004]

Verification T

Version 1.0

Id PER-GEN-002

Description The radio access network shall be capable of supporting a communication

range sufficient to give the driver(s) ample response time (e.g. 4 seconds).


Priority Must

Condition -

Source 3GPP TS 22.185 v15.0.0 [R-2. 2.4-001]

Verification D

Version 1.0

Id PER-GEN-003

Description The network shall support multi-Gbps capacity for high message volumes

and user amounts in V2I and V2V scenarios.

Rationale Some applications, e.g. related to safety and infotainment, require large

data bandwidths either very locally or for a larger coverage area.

Priority Must


EuWireless PU 44



Verification T

Version 1.0

Id PER-AN-001

Description The radio access (network) shall be capable of transferring messages

between two UEs supporting V2V and or V2P application, directly or via

an RSU, with a maximum latency of 100ms.


Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-2. 2.1-001]

Verification T

Version 1.0

Id PER-AN-002

Description The radio access (network) shall be capable of transferring messages

between a UE supporting V2I application and an RSU with a maximum

latency of 100ms.


Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-2. 2.1-002]

Verification T

Version 1.0

Id PER-AN-003

Description The radio access (network) shall be able to support high reliability

without requiring application-layer message retransmissions.


Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-2. 2.1-005]

Verification D

Version 1.0

Id PER-AN-004

Description The radio access (network) shall be able to support a maximum frequency

of 10 messages per second per transmitting UE.


Priority Must


Source 3GPP TS 22.185 v15.0.0 [R-2. 2.1-001]

Verification T

Version 1.0

Id PER-AN-005

Description For particular usage only, i.e., pre-crash sensing, the radio access

(network) should be capable of transferring messages between two UEs

supporting V2V application with a maximum latency of 20ms.


EuWireless PU 45


Priority Should


Source 3GPP TS 22.185 v15.0.0 [R-2. 2.1-002]

Verification T

Version 1.0

Id PER-AN-006

Description The network shall support dynamic mobility and high relative velocities

between transmitter and receiver for V2V scenarios.

Rationale Requires increased reaction times at highway speeds (e.g. > 4 seconds),

up to 280 km/h relative speeds (included LTE Rel.14 160 km/h absolute

vehicle speeds) and up to 500 km/h relative speeds (5G target).

Priority Must



Verification D

Version 1.0

Id PER-MEC-001

Description The network shall support extremely low latencies for V2V scenarios.

Rationale From 100 ms end-to-end latency in LTE Rel.14 towards 1 ms latency

design target for 5G. Messaging across different MNOs presents a

challenge.

Priority Must



Verification D

Version 1.0

Id PER-MEC-002

Description The network shall provide high reliability and availability for V2I and

V2V scenarios.

Rationale Multi-connectivity for reliability. Global Positioning System (GPS) -

based time synchronization when vehicles are out of network coverage.

Priority Must



Verification D

Version 1.0

3.7 Measurement and Monitoring (M&M)

Id M&M-GEN-001

Description EuWireless shall open data for researchers.

Rationale The European Commission has launched the Open Research Data (ORD)

pilot in the H2020 project. Overall, the Open Data Management Plan

(ODMP), reproducibility and interoperability features should be

considered at a very early stage of the design.

Priority Must

Condition -


EuWireless PU 46

Source DoA, [7]

Verification A

Version 1.0

Id M&M-GEN-002

Description EuWireless shall provide experimenter level probes and measurements in

an end-to-end manner for monitoring services, infrastructure, user

demands and experience with consideration of multiple stakeholders.

Rationale EuWireless system shall provide probes and measurements to

experimenters, if possible in a processed way (as opposed to raw open

data), according to the nature of the experiment and the equipment

involved.

Priority Must

Condition -

Source DoA, [7]

Verification D

Version 1.0

Id M&M-GEN-003

Description EuWireless shall provide multiple configurable network monitoring

options per experiment.

Rationale The granularity of monitoring data per experiment shall be configured to

control extra overhead resulting from increased monitoring exposure for

an experiment.

Priority Must

Condition -

Source DoA

Verification D

Version 1.0

Id M&M-GEN-004

Description EuWireless shall provide performance tools for technologies comparison.

Rationale It shall include methods to compare performance parameters of different

technologies for the selected use cases.

Priority Must

Condition -

Source DoA

Verification D

Version 1.0

3.8 Logistical and Organizational (LOG)

Id LOG-GEN-001

Description From the legal point of view, EuWireless should be a MNO that manages

its own resources and provides network services. But it will sometimes

act as a VMNO (or Home PLMN) when using MNOs RAN and CN

Rationale The operator of the EuWireless infrastructure must be a legal entity

registered as an MNO in most of the European countries.

Priority Should

Condition -

Source DoA


EuWireless PU 47

Verification D

Version 1.0

3.9 Legal Aspects

This group of requirements refers to the need to be compliant with current EU regulations

regarding spectrum access. All the analysis performed in this regard has been included in the

D1.2 deliverable.

3.10 List of Requirements

The requirements defined in this document are listed in the table below.

Table 2. EuWireless requirement description template

Id Description Version

INT-GEN-001 EuWireless must provide standardised and open interfaces that

are shared between all foreseen testbeds/networks so that

researchers can connect network functions and services (physical

or virtual) under the framework of EuWireless.

1.0

INT-GEN-002 EuWireless shall provide standardised and open interfaces so

that researchers can connect services.

1.0

INT-GEN-003 EuWireless shall provide different configuration interfaces based

on user profiles.

1.0

INT-GEN-004 EuWireless should provide a Graphical User Interface (GUI) for

private networks/testbeds and experiments set up based on GTS

GUI or similar.

1.0

INT-GEN-005 EuWireless should support the interconnection of multiple

Evolved Packet Cores (EPCs) to a shared RAN, sharing the

RAN elements and the radio resources.

1.0

INT-GEN-006 EuWireless should maintain a repository or log of past

experiments.

1.0

INT-GEN-007 EuWireless should support the deployment of past experiment

settings (e.g. infrastructure configuration) and the repetition of

the experiment.

1.0

INT-GEN-008 EuWireless should provide interfaces with mobile network

controller platform.

1.0

INT-GEN-009 EuWireless architectural components should encompass the

underlying network technologies in a generic way.

1.0

INT-GEN-010 EuWireless should provide clear and updated documentation

regarding how to use EuWireless for experiments.

1.0

INT-GEN-011 EuWireless should provide a dedicated forum for information

exchange and support.

1.0

INT-GEN-012 EuWireless should provide V2X communications over the PC5

and over LTE-Uu.

1.0

INT-GEN-013 EuWireless shall create an environment to create private

network for research

1.0

INT-GEN-014 EuWireless shall support multiple, concurrent users in their own

private network

1.0

INT-GEN-015 EuWireless shall be deployed in several countries to offer a pan-

European service

1.0

INT-SGI-001 EuWireless shall define interfaces to interconnect PoDs. 1.0


EuWireless PU 48

INT-SGI-002 EuWireless shall define interfaces for remote configuration. 1.0

INT-SGI-003 EuWireless shall define interfaces to connect external R&D

infrastructures (testbeds).

1.0

INT-AN-001 EuWireless shall support coexistence/interworking with IEEE

802.11p V2X technologies.

1.0

INT-AN-002 EuWireless should support coexistence/interworking with other

non-3GPP RATs (e.g. Lora, Thread, ZigBee).

1.0

INT-AN-003 EuWireless shall support a high density of UEs 1.0

INT-AN-004 EuWireless should support flexible distribution of RAN

functionalities in the overall network architecture.

1.0

INT-AN-005 EuWireless must support configurable, joint radio resource

management to differentiate traffic between EuWireless users

and MNO’s users that spans along the slice: from spectrum,

through RAN and up to a core network.

INT-SPE-001 EuWireless shall be capable of interfacing with multiple

methods of spectrum sharing and access e.g. LSA and Spectrum

Access System (SAS).

1.0

FUN-SPE-001 Controlled and harmonized method to access regulated spectrum

shall be provided for the users of EuWireless.

1.0

FUN-SPE-002 Dynamic yet flexible spectrum sharing methods should be

supported in order to enable flexible utilization of regulated

spectrum.

1.0

FUN-GEN-001 R&D hardware/software provided by EuWireless shall get

disconnected (upon request) automatically from the commercial

MNO infrastructure.

1.0

FUN-GEN-002 It should be possible to utilize external base stations (e.g. one

from small testbeds) with own or operator EPCs using the MNO

spectrum.

1.0

FUN-GEN-003 Virtualization of mobile network components and services

should be supported throughout the EuWireless and MNO

infrastructures.

1.0

FUN-GEN-004 GTS should be supported over testbed infrastructure. 1.0

FUN-GEN-005 The access to experiments should be transparent to the

experimenter.

1.0

FUN-GEN-006 Experimenters could utilize the GTS service to deploy his/her

experiments allocating EuWireless and MNO resources.

1.0

FUN-GEN-007 EuWireless should offer various (customizable) resource sharing

options to be used by the experimenters (e.g. as defined by the

3GPP).

1.0

FUN-GEN-008 EuWireless should support Commercial Off-the-Shelf (COTS)

UEs and some dedicated terminals (experimental platforms).

1.0

FUN-GEN-009 EuWireless operator should support effective isolation

techniques of RAN/CN resources during the experiment and also

interact with MNO policies in order to support specific

mechanism e.g. Local Breakout Offloading (LBO) and other that

help remove a strain from commercial network (e.g. SGi

interface) of an operator.

1.0

FUN-GEN-010 EuWireless shall coordinate with other MNOs broadcast services

e.g. to provide warning system services.

1.0

FUN-GEN-011 EuWireless shall offer outdoor coverage for field testing in

realistic usage environments.

1.0

FUN-GEN-012 EuWireless should support research in orchestration of ultra- 1.0


EuWireless PU 49

dense networks.

FUN-GEN-013 EuWireless should support research in transversal mobile R&D

topics.

1.0

FUN-GEN-014 EuWireless shall provide experiment validation capabilities in

order to assure fulfilment of the needs of a particular experiment.

1.0

FUN-GEN-015 EuWireless architecture and designed experiment provisioning,

execution and monitoring mechanisms, should support state

information sharing in communication between stakeholders to

improve the quality of decision making in management

processes.

1.0

FUN-GEN-016 EuWireless shall minimize the impact on the resources of UE

with limited resources supporting V2X applications

1.0

FUN-AN-001 EuWireless should be able to interface with the RAN

slicing/multi-tenancy framework in the MNO’s infrastructure in

order to better facilitate isolation, addition and removal of R&D

hardware/software for wireless access trials.

1.0

FUN-AN-002 EuWireless shall support sharing the same Public Land Mobile

Network (PLMN) to connect the UE to different EPCs.

1.0

FUN-AN-003 EuWireless shall support message transfer between UEs when

served or not served by the same PLMN supporting V2X

communications.

1.0

FUN-AN-004 EuWireless shall provide means to prioritize message

transmission among UEs supporting V2X application.

1.0

FUN-AN-005 EuWireless shall provide means to prioritize transmission of

messages according to their type (e.g. safety vs. non-safety).

1.0

FUN-AN-006 EuWireless shall be able to vary the transmission rate and range

of the V2X communication based on service conditions (e.g.,

UE speed, UE density).

1.0

FUN-AN-007 EuWireless shall inform to the UE whether it supports V2X. 1.0

FUN-AN-008 The experiment network (or slice) shall provide means for an

application server and the RSU to control the area and the size of

the area where the messages are being distributed.

1.0

FUN-AN-009 EuWireless should make available any supported positional

accuracy improvement techniques, e.g. Differential Global

Positioning System (DGPS) and/or Observed Time Difference of

Arrival (OTDOA), in a resource efficient way to a subscribed

UE supporting V2X application.

1.0

FUN-AN-010 The network shall be capable of transferring periodic broadcast

messages between two UEs supporting V2X application with

variable message payloads

1.0

FUN-AN-011 EuWireless shall be capable of transferring event-triggered

messages between two UEs supporting V2X application with

variable message payloads.

1.0

FUN-AN-012 EuWireless shall be able to distribute information in a resource

efficient way to large numbers of UEs supporting V2X

application.

1.0

FUN-AN-013 EuWireless should support research in topics related to spectrum

management and antenna techniques.

1.0

FUN-CN-001 EuWireless should be able to interface with the CN (and

transport) slicing/multi-tenancy in the MNO’s infrastructure in

order to facilitate addition and removal of R&D

hardware/software for networking and service trials.

1.0


EuWireless PU 50

FUN-CN-002 In the information broadcast system, each cell in shared RAN

shall include information concerning available core network

operators in the shared network. The available core network

operators shall be the same for all cells of a Location Area in a

shared RAN.

1.0

FUN-CN-003 UE shall show the name of the PLMN-id it has registered with.

In case of a shared network, it is the PLMN-id of the chosen

core network operator.

1.0

FUN-CN-004 EuWireless should support research in topics related to

orchestration of ultra-dense networks.

1.0

FUN-UE-001 Experimenters UEs shall behave as regular UEs in conventional

networks with respect to Access and Mobility Management

Functions (AMF).

1.0

FUN-UE-002 EuWireless should support UE roaming. 1.0

FUN-UE-003 EuWireless shall support various types of traffic from

experimenters, also ones which would otherwise be not allowed

(or require separate agreements) in a commercial MNO network

(e.g. video). Still the traffic flow(s) characteristics should be

policed/shaped to fit within the agreed SLA.

1.0

FUN-UE-004 A UE supporting V2X application shall be able to be pre-

configured by the 3GPP network with parameters to be used for

the transmission and reception of messages when not served by

E-UTRAN supporting V2X communication.

1.0

FUN-UE-005 A UE supporting V2X application shall be able to transmit and

receive messages when served or not served by E-UTRAN

supporting V2X communication.

1.0

FUN-UE-006 An RSU shall be able to transmit/receive messages to/from a UE


1.0

FUN-UE-007 A UE supporting V2X application shall be able to identify

whether E-UTRAN supports V2X communication.

1.0

FUN-MEC-001 EuWireless shall provide means for distribution of messages

from a UE supporting V2X application to locally relevant

application servers.

1.0

EXT-GEN-001 EuWireless should support large scale testing, including cross

border testing.

1.0

EXT-GEN-002 EuWireless should support advanced experiment resource

planning.

1.0

EXT-SGI-001 EuWireless should support the inclusion of new or existing

remote outdoor/indoor testbeds.

1.0

OPE-SGI-001 EuWireless shall ensure the secure interconnection of new or

existing testbed.

1.0

OPE-GEN-001 EuWireless shall offer state of the art trust, identity and security

enablers for its subscribers.

1.0

OPE-GEN-002 EuWireless operator shall offer multitude of privacy preserving

technologies and techniques for user data anonymization,

encryption, etc.

1.0

OPE-GEN-003 EuWireless shall support end-to-end encryption and isolation of

all communication and test traffic.

1.0

OPE-GEN-004 Isolation between the data traffic originating from the

EuWireless experiments and the user data traffic in an MNO

network shall be guaranteed.

1.0

OPE-GEN-005 EuWireless shall implement authentication, authorisation and 1.0


EuWireless PU 51

accounting mechanisms.

OPE-GEN-006 EuWireless subscriber identification, authentication and

authorization shall be supported through both MNO and

EuWireless access networks.

1.0

OPE-GEN-007 The UE utilised by EuWireless subscribers during trials shall be

identifiable in the network.

1.0

OPE-GEN-008 EuWireless shall provide an option for tests/measurements

without end-to-end encryption and/or with anonymised data.

1.0

OPE-GEN-009 EuWireless must be able to track resources being used within

experiment (experiment network) and deliver accounting data to

the business processes.

1.0

OPE-GEN-010 Both the Home PLMN and Visitor PLMN operators shall be

able to charge for network resource usage when messages are

transferred by a UE supporting V2X application.

1.0

OPE-GEN-011 The V2X network entities shall be able to authenticate the

source of the received data communications.

1.0

OPE-GEN-012 The transmission of data between V2X network entities shall be

integrity protected.

1.0


confidentiality protected.

1.0


protected from replays.

1.0

OPE-GEN-015 The network shall provide bullet-proof security and privacy. 1.0

OPE-GEN-016 EuWireless should provide means to support cyber security

scanning of the new elements (software and hardware)

introduced by experimenters when performing dedicated

experiments with new hardware and software solutions.

1.0

MNG-UE-001 EuWireless shall provide mechanisms to manage and configure

the UE and/or sensor device through a remote connection.

1.0

MNG-UE-002 EuWireless should provide mechanisms to manage and

configure the UE and/or sensor device through an MNO network

(Over-The-Air).

1.0

MNG-GEN-001 EuWireless shall provide management and control interfaces of

network components under test.

1.0

MNG-GEN-002 EuWireless shall provide default network configurations

(profiles) that can be directly used by the researchers.

1.0

MNG-GEN-003 EuWireless should support different experiment definition

languages.

1.0

MNG-GEN-004 EuWireless shall store used network and UE configuration (e.g.

channel models, user profiles, etc.) in a way they can be reused.

1.0

MNG-GEN-005 EuWireless network and UE configuration shall be stored in a

recognized data format.

1.0

MNG-GEN-006 EuWireless management platform should enable the MNOs with

means for flexible customization of which parts of its networks

are available for sharing and under which conditions.

1.0

MNG-GEN-007 Different agreements shall be stablished in order to connect

MNOs or testbeds to EuWireless. Based on such agreements

specific experiment capabilities will be available.

1.0

MNG-GEN-008 EuWireless should provide common management platform and

operations framework addressing the issue of inter-testbed

connectivity and federation, or extending the federation

concept from testbed-level to (wireless) node level, enabling the

1.0


EuWireless PU 52

creation of heterogeneous testbed infrastructures through

mixing platforms owned by different parties.

PER-GEN-001 The radio access network shall be capable of transferring

messages via 3GPP network entities between a UE and an

application server both supporting V2N application with an end-

to-end delay no longer than 1000 ms.

1.0

PER-GEN-002 The radio access network shall be capable of supporting a

communication range sufficient to give the driver(s) ample

response time (e.g. 4 seconds).

1.0

PER-GEN-003 The network shall support multi-Gbps capacity for high message

volumes and user amounts in V2I and V2V scenarios.

1.0

PER-AN-001 The radio access (network) shall be capable of transferring

messages between two UEs supporting V2V and or V2P

application, directly or via an RSU, with a maximum latency of

100ms.

1.0

PER-AN-002 The radio access (network) shall be capable of transferring

messages between a UE supporting V2I application and an RSU

with a maximum latency of 100ms.

1.0

PER-AN-003 The radio access (network) shall be able to support high

reliability without requiring application-layer message

retransmissions.

1.0

PER-AN-004 The radio access (network) shall be able to support a maximum

frequency of 10 messages per second per transmitting UE.

1.0

PER-AN-005 For particular usage only, i.e. pre-crash sensing, the radio access

(network) should be capable of transferring messages between

two UEs supporting V2V application with a maximum latency

of 20ms.

1.0

PER-AN-006 The network shall support dynamic mobility and high relative

velocities between transmitter and receiver for V2V scenarios.

1.0

PER-MEC-001 The network shall support extremely low latencies for V2V

scenarios.

1.0

PER-MEC-002 The network shall provide high reliability and availability for

V2I and V2V scenarios.

1.0

M&M-GEN-

001

EuWireless shall open data for researchers. 1.0

M&M-GEN-

002

EuWireless shall provide experimenter level probes and

measurements in an end-to-end manner for monitoring services,

infrastructure, user demands and experience with consideration

of multiple stakeholders.

1.0

M&M-GEN-

003

EuWireless shall provide multiple configurable network

monitoring options per experiment.

1.0

M&M-GEN-

004

EuWireless shall provide performance tools for technologies

comparison.

1.0

LOG-GEN-001 From the legal point of view, EuWireless should be a network

operator that manages its own resources and provides network

services.

1.0


EuWireless PU 53

4 Requirements Collection Methodology

4.1 High-Level Approach

To collect end users’ requirements, the consortium as a whole has constructed the targeted

questionnaires. Then, the responses have been compared with the list of candidate requirements

derived from the documents such as DoA, standards and white papers. Other approaches for

collecting end-users’ needs have been investigated including workshops, focus groups, open

discussion among others. However, from the perspective of risk mitigation and universalism10

provided by the questionnaires, this method has been selected as the main tool.

The following rationale has been identified for the questionnaire-based interviews:

Provide a unified approach for requirements collection process across partners.

Include capabilities to perform both qualitative and quantitative analysis (depending on

the type of questions issued).

Ease of use with large groups of respondents (especially representing citizens).

Enable variety of modes to collect responses (onsite, offline, online).

Provide baseline (excuse) for interactive discussions with end users.

Can be used as navigating tool during discussion (set of control questions).

Enables an easy approach to derive statistics based on subset of build-in quantitative

questions.

One of the identified disadvantages of the questionnaire approach was the fact that it is quite a

time consuming process. From the perspective of a stakeholder, answering the questionnaire

demands additional insights into the EuWireless architecture and technologies required to

implement the system.

The overall approach to specify end user requirements is based on the Volere methodology

adjusted to the EuWireless project purposes (for more details please refer to Section 4.2).

However, during the process of choosing a methodology alternative approaches, as well as

templates to requirements formalization, have been analysed. For example, the Rational Unified

Process (RUP) and the Software Engineering Body of Knowledge (SWEBOK) [12] have been

considered.

Figure 15 shows the requirements lifecycle in the EuWireless project. The resulting

requirements were consulted with relevant stakeholders and the project Advisory Board

members to wider consultations. The D1.1 deliverable delivers consolidated “design

requirements” that will further help in defining the architecture of the pan-European mobile

operator for research. Still these requirements should further be turned into requirements for

software development, e.g. when the “implementation project” as of INFRADEV H2020 R&D

call would be targeted.

10

Universalism refers to the fact that independent on the method used to ask the questions during

interviews/surveys the answers were always aligned with relevant questions from the questionnaire. This

way questionnaire should be treated as a universal format for collecting answers.


EuWireless PU 54

Figure 15. Requirements hierarchy in EuWireless

Thus, the EuWireless project is not aiming at providing requirements that can directly be used

according to a typical flow of an Information Technology (IT) system design process. Instead,

the requirements are more addressing the design phase of the overall architecture of such a pan-

European mobile network operator. The list of requirements is a solid baseline for future

projects, which will start implementing such architecture in Europe. It is also advisable that the

EuWireless requirements are promoted and cooperatively utilized with other alliances and

organizations, which, in turn promote pan-European, or even more international, approaches to

assure unified and integrated research infrastructures like e.g. ESFRI, Federation for Future

Internet Research and Experimentation (Fed4FIRE), Global Environment of Network

Innovations (GENI), etc. The liaisons with such complementary groups are assured under

careful control in WP4, which also maintains contacts towards other similar projects funded by

EC.

The EuWireless consortium is aware that the design requirements presented in Section 3 may

require additional standardization efforts, because major changes might be needed to implement

incremental changes at communication endpoints (e.g. user terminals) or at MNO infrastructure

along the communication path. However, as the results of the EuWireless project shall provide

directions for future developments within the network infrastructures of MNOs and research

organizations, they should also be aligned with initiatives like ESFRI for increased synergy.

ESFRI, as a promotor of EU-US cooperation, has expressed some concerns and requirements in

their recent report [7]: “[…] Many of these issues will require standardization (whether through

existing SDOs or via an open-source project) because they hinge on incremental changes at

endpoints as well as at various points in the Internet core. Furthermore, policies will need to be

expressed with globally consistent semantics. In particular, differences in approaches to privacy

(i.e., reduction of information radiated about encrypted user traffic by these mechanisms) will

be a key point of collaboration and coordination across US and EU. Experimentation with these

mechanisms will require global testbeds (i.e., diversity in latency/bandwidth of access networks

and in network management policies) to be useful.”.


EuWireless PU 55

4.2 Methods and Tools

In order to implement the general approach mentioned above, a set of methods and tools has

been identified.

4.2.1 Questionnaire

The main method to collect requirements has been surveying end users. The questionnaires

defined to this end will be presented in the rest of the section. The consortium has used a clear

definition of “a universal procedure” for each of the partners contacting end-users. First, a set of

candidate questions were defined by the consortium in an iterative process. Then, a subset of the

best candidate questions were included in the questionnaire.

The preliminary version of the questionnaire (v1.0), as it was published on the project website11

,

is presented in the Appendix 7.1.1. The following listing presents questions that had been

nominated as the final ones:

1. Why establishing a pan-European R&D mobile operator would be needed to support the

current process of mobile networks oriented experimentation?

2. Are you familiar with any wireless testbed services around Europe (e.g Géant Testbed

Services, Fed4Fire, Genie, etc.) that is providing wireless network facilities of a kind?

3. What do you believe, are the main barriers for the emergence of pan-EU R&D mobile

operator? (e.g. "high cost of large scale build out of infrastructure", "it is not possible to

test in licensing spectrum", "lack of SLA guarantees", etc.)?

4. What incentives should be there for Mobile Network Operators (MNOs) to share its

infrastructure? (e.g. "some discounts on OPEX costs", "improved network/QoE after

introducing validated research", "press release", "early access to results", etc.)

5. Which are the key "technical" enablers that would foster emergence of pan-EU R&D

mobile operator?

6. Which are the key "operational" enablers that would foster emergence of pan-EU R&D

mobile operator?

7. Please enumerate most interesting use-cases for utilizing MNOs infrastructure if access

to their infrastructure is provided in a managed way (e.g. “new mechanisms testing

(improved handover, HARQ, scheduler)”, “new functionalities testing (D2D, NB-IoT,

etc.)”, “functionalities testing for cluster of stations (handover, scheduling, interference

cancelling, etc.)”, “services testing (e.g. NFV), etc.).

8. As a small testbed owner/technology provider (e.g. F4F) can you name 1-5 needs

regarding the access to the commercial mobile network operator infrastructure from

your experience so far? (e.g. validate and verify algorithms, evaluate infrastructure

components, collect and export data, open data availability, etc.)

9. What are today the key barriers for performing comprehensive (e2e) research on mobile

networks, based on your experience so far? (e.g. number of real UE available, difficult

to deploy new algorithms, diversity of testbed APIs, etc.)

10. Which elements of the MNO infrastructure, you would like to have access to (i.e. share)

when experimenting - e.g. spectrum, devices, new network features (carrier

aggregation, VoLTE, NB-IoT, etc.), the internal network interfaces, etc.?

11. How you would like to access the infrastructure of the MNO (e.g. via browser GUI, via

web service, via NMS, other) through the pan-EU R&D mobile operator?

12. What type of guarantees would you expect from the pan-EU R&D mobile operator in

order to comfortably perform your experiment? (SLA, dedicated resources, continuous

monitoring of vital statistics, etc.).

11

EuWireless questionnaire: https://euwireless.eu/questionnaire

https://euwireless.eu/questionnaire


EuWireless PU 56

13. In what way would you like to interact with the data from your experiment – please

describe the optimal way you would like to be able to collect data (e.g. online/offline,

web-interface, access to a database/cloud, other please specify, etc.).

Most of the questions above are open and request the responder to provide multiple answers,

prioritizing their relevance from 1-5 (5 is highest relevance). At the beginning of the

questionnaire, users are asked to provide their role. However, based on the feedback that quite

high number of open questions was considered by the responders challenging and required more

time to answer, the consortium decided to simplify the questionnaire and provide only closed

questions. The complete set of questions is provided below (Appendix 7.1.2 includes the

complete set of questions and possible answers):

1. Should it be available, would you use a mobile network operator for research?

2. How would you use the mobile network operator for research?

3. Are you familiar with any of these network testbed services around Europe?

4. Which technologies would you like the mobile network operator for research to

provide?

5. Which coverage area would you require the mobile network operator for research to

provide?

6. Select the research network technical enablers most relevant for you

7. Select the research network operational enablers that would foster emergence of a pan-

EU operator?

8. Based on your experience, what are today the key barriers for performing

comprehensive (e2e) research on mobile networks?

9. Which elements of the MNO infrastructure would you like to have access to when

experimenting?

10. How would you like to access the testing and configuration data at the research

network?

11. What type of support would you expect from the mobile network operator for research

in order to comfortably perform your experiment?

12. What type of security guarantees would you expect from the mobile network operator

for research in order to comfortably perform your experiment?

13. Would you pay for using a mobile network operator for research?

14. Please provide any additional comments you have on the mobile network operator for

research.

The analysis of answers from the questionnaires was utilized as one of the important inputs to

the requirements elicitation process described below.

4.2.2 Requirements Collection Methodology

The Volere methodology has been chosen as a starting point for this work, adapting its

requirements specification template to the particularities and needs of EuWireless.

Each of the partners responsible for requirements gathering was asked to approach the

requirements identification phase according to their experience. All partners have used the

common questionnaire during interviews with stakeholders. Using a common methodology has

formalized the process and unified the approach, leading to more coherent results. Volere is a

methodology that does not require a complex analysis to be applied. A common methodology

organizes gathering, classification and assessment of the requirements. It also provides tools for

requirements management, providing the means to trace the identification, definition,

assessment, formalisation and, if necessary, improvement of the requirements gathered. The

requirement collection template presented in Table 3 was defined to describe requirements.


EuWireless PU 57

Table 3. EuWireless requirement description template

Id XXX-YYY-000

Description Text of requirement comes here

Rationale Some additional rationale

Priority MoSCoW priority specification

Condition -

Source <source of requirement>

Verification I-A-D-T

Version X.X

ID is a unique identification of the requirement and combines of the type and number of

requirement. First three letters (XXX) refers to a requirement main category

(Dimension 1), and the following letters (YYY) refer to relevant architectural

component (Dimension 2). Then follows a number that identifies sequential number

within the particular requirement group.

The first three letters (Dimension1) refer to:

o Interfaces and System Design (INT)

o Functional Requirements (FUN)

o Extensions (EXT)

o Physical Constraints (PHY)

o Environmental Conditions (ENV)

o Design Constraints (DES)

o Operational requirements (OPE)

o Management (MNG)

o Performance (PER)

o Measurement and Monitoring (M&M)

o Logistical and Organizational (LOG)

o Financial Constraints (FIN)

o Legal Aspects (LEG)

Remaining three letters (YYY = Dimension2) identify element of architecture:

o Overall system (GEN)

o User Equipment (UE)

o Access Nodes (AN)

o Spectrum (SPE)

o Transport Network (TN)

o Core Network (CN)

o Interfaces MNO/Internet (SGI)

o Multi-access edge computing (MEC)

Description provides an explanation of the requirement.

Source indicates the origin of a given requirement (i.e., DoA, end-user questionnaires,

state-of-the-art, consortium experience).

Rationale provides additional relevant information to the requirement description, e.g.

reference requirements, comments, examples, etc.

Priority is determined by the importance of the requirement, according to MoSCoW

methodology [39]. The priority is described with MUST, SHOULD, COULD and


EuWireless PU 58

WOULD12

priority indicating the status for requirement to be considered during the

project.

o Requirements derived from the DoA are prioritized as MUST. This means that

they have the highest priority in the further realization and will be carefully

studied and considered during the project.

o All requirements having the SHOULD priority will be also considered, and the

consortium should make the best effort to consider them at the design stage of

the project.

o The COULD priority represents requirements that are desirable but not

necessary. They can be included if time and resources permit.

o The WOULD priority means that the requirement will not be realized during

the project, but may be considered for the future work.

The stakeholder community involvement in the requirements evaluation and

prioritization is subject to interviews and workshops planned for the first, second year

of the project respectively. Thus, priorities of particular requirements may change

according to project progress and when the intermediate project results will be achieved.

Moreover, for clarity it is worth mentioning that there exist other types of prioritization,

which may be more “feature oriented” – example alternative is presented in appendix

7.3 . But consortium has decided to follow the typical RFC-like terminology.

Condition identifies the condition required for the requirement to be valid (e.g.

identification of target scenario or case study).

Verification field is used to indicate the requirement will be validated. There are four

different means of validation (each identified by a letter):

o Inspection (I) is a visual verification of an item.

o Analysis (A) is a verification based upon analytical evidences obtained by

calculation, without intervention on the verified item. The techniques used are

modelling, simulation and forecasting.

o Demonstration (D) is a verification of operational characteristic observable by

the overseeing of the functioning component without physical measurement.

o Test (T) is a verification of functional characteristics that are measurable and

directly or indirectly reachable.

Version shows the evolution of the requirement.

o All requirements at the stage of D1.1 final version are set to “1.0”.

Furthermore, the requirements should be used for the evaluation of the project pilot results at

the end of the project. A set of well-defined and unambiguous requirements is presented, not

only as input for any further specification and development, but also as part of the evaluation

framework. Typical very detailed description of requirements is necessary for IT project that is

delivering some implementation. Such level of very detailed requirements is not planned for the

EuWireless project. However, requirements defined in this project will mainly contribute to

architecture and functional specification of the EuWireless operator. The Volere methodology

defines 5 main requirements groups:

Functional and data requirements: describe the crucial capabilities that the product

needs to have, the functions carried out or the processing actions need to be taken.

Non-functional requirements: specify the properties of the product, which need to be

satisfied, including performance, usability, look and feel, or security requirements.

Project drivers: the business-related forces, including the purpose of the project and all

stakeholders’ objectives.

12

Occasionally, the WOULD may be replaced by WON’T. The main difference is that a requirement

classified by the WON’T priority level is not to be included on any future developments of EuWireless.


EuWireless PU 59

Project constraints: restrictions on the product design, including restrictions for the

hardware, software to be used, the way of implementation; which may all be different

depending on the particular business practices.

Project issues: describe conditions under which the project will be done. It is necessary

for presenting the comprehensive view of all factors that may have impact on the

project success.

The Volere methodology has been adjusted in order to best meet the specifics and challenges of

the EuWireless project – especially the one that EuWireless is not a typical IT project. The

first two groups, i.e., functional and non-functional requirements, are the main scope of the

requirements gathered within this deliverable. Other aspects, such as “project drivers”, are more

in the scope of the business strategy of the EuWireless project, although aspects such as

stakeholder’s objectives are visible by the means of collecting end user feedback. Therefore, the

business-related factors, including “project drivers” and “project constraints”, are not in the

scope of this document, as discussion on the business aspects has already been partially covered

within the DoA and will also be done as part of the work on the exploitation plan in WP4. The

same applies to the project issues, which in case of EuWireless can be understood as the

potential project risks (in this case also as market drivers) and will be covered by the

EuWireless exploitation plan in WP4.

However, in order to provide also some more detailed means to trace requirements coverage in

the project, the consortium has decided to utilize more fine-grained number of categories for

functional/non-functional requirements based on the ISO2011 standard. The approach is

presented in the Section 4.3 for requirements coverage analysis and requirements fine-grained

categorization.

4.3 Requirement Candidates Collection and Processing

The Figure 16 depicts the process to collect preliminary requirements and apply first validation

phase. The project has defined two questionnaires; (a) first version at the beginning of the

project (M3) containing the same set of questions as the final questionnaire, but the questions

were more open in nature, and (b) the final questionnaire with more closed-questions so that

stakeholders can address it in an easier way. The simplified final version was created so that a

larger number of stakeholders could be effectively reached with the questionnaire remotely.

At the beginning (M3), the main sources for requirements were the DoA, case study analysis

and preliminary responses to the first version of the questionnaire. In the next stage, a number

of preliminary stakeholders’ interviews were realized as well as more detailed investigation of

the case studies (mainly connected car analysis in task T1.4). In the third step, the simplified

version of questionnaire was prepared and distributed to potential respondents. In addition, an

in-depth analysis of the state-of-the-art was done (e.g. D1.3). The detailed approach to analyse,

improve and crosscheck the collected requirements is described in Section 3.

In order to record and better track the EuWireless requirements, a matrix with two dimensions

has been considered:

Dimension 1 comprises functional and non-functional requirements ordered in multiple

groups based on the adaptation of the ISO2011 standard [13].

Dimension 2 provides architectural elements of EuWireless.

The two dimensions are defined in the ID field definition in Table 3 in Section 4.2.2. Dimension

1 is based on the guide to the Software Engineering Body of Knowledge [12] and the ISO2011

standard. However, it has been adjusted to the project context and needs. Dimension 1

comprises most of the requirements groups from ISO2011 but some were decided to be out of


EuWireless PU 60

interest for EuWireless. In addition, other groups were missing in our opinion. In these cases,

the groups have been added to the requirement categories. Table 4 presents the requirement

categories used for EuWireless and their relation to ISO2011 with rationale.

Figure 16. EuWireless requirements collection process.

Table 4. EuWireless requirement categories definition

Category from

ISO2011

Category in

EuWireless

Rationale for update

Interfaces Interfaces &

System Design

This category collects all the system design aspects

including interfaces, architecture, repositories and user

interfaces.

Functional Functional This category refers to the main functionalities

provided by EuWireless (and described in generic use

cases), but also includes aspects related to

experimentation topology, network provisioning

capabilities, access to the experimentation

infrastructure, experiment resources sharing and

adjustment, isolation of experiment resources, mobility

management, direct access to the shared components,

etc.

Extensions Extensions This category defines potential extension, growth, or

scalability issues during the life of the system.

Operational Operational This category defines the operational conditions or

properties that are required for the system to operate or

exist, including human factors, ergonomics,

availability, maintainability, reliability, and security.

N/A Management This category contains aspects related to management

of the experimentation infrastructure addressing the

management of user terminals, testbeds, mobile

networks, experiments, mobility and radio resources.


EuWireless PU 61

This category is not present in the ISO2011 standard.

Performance Performance This category defines quantitatively the extent, or how

well, and under what conditions a function or task is to

be performed (e.g. rates, velocities). They are

quantitative requirements of system performance and

are verifiable individually. Note that there may be

more than one performance requirement associated

with a single function, functional requirement, or task.

N/A Measurement

and Monitoring

This category is related to the process of measurement

and monitoring of experiment performance indicators

in connection with the underlying infrastructure Key

Performance Indicators (KPIs). It consists of

monitoring and measurement of mechanisms used

within the infrastructure and introduced by

experimenters, data and protocols composing the

experiment (whether overlay or the main

infrastructure) as well as multiple statistics required for

research and accounting purposes. This category is not

present in the ISO2011 standard.

Logistical Logistical and

Organizational

This category defines the logistical conditions needed

by the continuous utilization of the system. These

requirements include sustenance (i.e. provision of

facilities, level of support, support personnel, spare

parts, training, technical documentation, etc.),

packaging, handling, shipping and transportation.

Cost and

Schedule

Constraints

Financial This category defines, for example, the cost of a single

deployment point (PoD) of the system, the expected

delivery date of the first deployment point, etc.

Physical

Constraints

(PHY)

N/A This category was not considered useful by the

EuWireless

Design

Constraints

(DES)


EuWireless

Environmental

Conditions

(EXP)


EuWireless

In order to define means for requirements coverage control, i.e. to monitor for potentially

missing requirements, the two dimensions have been utilized together to provide a requirement

matrix presented in Table 5. Each row represents a category of Dimension 1, while Dimension 2

categories are represented in the columns. A cell contains indicators of the requirements under

each category. Table 5. Requirements coverage matrix

Cat.

Overall

System

(GEN)

User

Equipment

(UE)

Access

Nodes

(AN)

Spectrum

(SPE)

Transport

Network

(TN)

Core

Network

(CN)

Interfaces

MNO

Internet

(SGI)

MEC

(MEC)


EuWireless PU 62

Tec

hn

ical

INT (15)

FUN (16)

EXT (1)

INT (0)

FUN (7)

EXT (1)

INT (5)

FUN (13)

EXT (0)

INT (1)

FUN (2)

EXT (0)

INT (0)

FUN (0)

EXT (0)

INT (0)

FUN (4)

EXT (0)

INT (3)

FUN ()

EXT (0)

INT (0)

FUN (1)

EXT (0)

Op

erat

ion

al

OPE (16)

MNG (7)

PER (3)

M&M (4)

LOG (1)

OPE (0)

MNG (2)

PER (0)

M&M (0)

LOG (0)

OPE (0)

MNG (0)

PER (6)

M&M

(0)

LOG (0)

OPE (0)

MNG (0)

PER (0)

M&M

(0)

LOG (0)

OPE (0)

MNG

(0)

PER (0)

M&M

(0)

LOG (0)

OPE (0)

MNG

(0)

PER (0)

M&M

(0)

LOG (0)

OPE (1)

MNG (0)

PER (0)

M&M

(0)

LOG (0)

OPE (0)

MNG (0)

PER (0)

M&M (0)

LOG (0)

Leg

al

See D1.2

4.4 Sources for Requirement Collection

As mentioned in the introduction, the work done in WP1 is the input to the design of the pan-

European mobile network operator architecture in WP2. This section on requirement sources

helps to identify both requirements and technologies to be analysed in Task 1.3 “Enabling

technologies” and in WP2.

Multiple sources of requirements have been used in order to assure a comprehensive approach

and consider various perspectives for validating the rationale and need for each requirement.

The sources behind the requirements can be grouped into three key categories:

Stakeholders, who are the main source of the drivers and needs, which also state the

problems to be solved.

Standard specifications such as 3GPP, research papers, whitepapers, reports and other

documents.

The specialized case-study drivers and needs, i.e. outdoor testbeds operating on licensed

spectrum, GTS with mobile network components and various C-V2X testing scenarios.

The set of requirements extracted from the use cases and case studies, together with the

identified key enabling technologies and the initial EuWireless architecture, will be discussed

with stakeholders in later phases of the project. Based on the collected feedback, the details of

the requirements and the architecture can be refined.

It needs to be also recalled (after Figure 15) that the expected result of the EuWireless

requirement specification phase is to deliver validated and tuned requirements (so called design

stage requirements) to the implementation stage, based on:

Meetings with stakeholders during the first year of the project (until the final delivery of

deliverable D1.1 at M12). After this period, the project will also continue to have

meeting with already contacted key stakeholders for deeper discussions.

Cross-reading and checking performed internally by the project partners.

Feedback from the enabling technologies analysis (reported in deliverable D1.3 at M10)

and

The design of the initial architecture of a pan-European mobile operator for research

(reported in deliverable D2.1 at M12).

4.4.1 State of the Art (SOTA)

EuWireless Description of Action (DoA) [14] is utilised as the main source for general high-

level requirements for the overall concept of the pan-European mobile network operator for

research. The requirements extracted from the DoA are mainly functional. Some non-functional


EuWireless PU 63

requirements, e.g. related to the interfaces, operations, management and design of the

EuWireless infrastructure, are also originating from the high-level system definitions extracted

from the DoA. The role of the high-level DoA-based requirements is to act as a baseline for the

more detailed requirements coming from the EuWireless’ key stakeholders and use cases.

GENI Wireless initiative is the main reference for EuWireless in the international scope. In [15],

the author describe the architecture of GENI edge cloud computing network in the form of

compute and storage systems, a mobile 4G Long Term Evolution (LTE) edge and a high-speed

campus network. All these solutions are deployed in the form of GENI Racks connected via

high-speed fibre to LTE eNBs across twelve campuses in the US, all interconnected via a

nationwide research network. The GENI mobile computing resource manager is based on the

Orbit Management Framework (OMF) and provides seamless access to the computing resources

via the GENI Portal for experimentation, scheduling, data collection and processing of

ubiquitous computing applications. This approach is quite similar to the case study of GTS

expanded with LTE components. However, the objective of EuWireless is to provide more than

the LTE eNBs in the campuses, giving the European researchers access to more resources from

the MNOs.

The High Fidelity Experiment Platform for Mobile Networks (FEP) environment presented in

[16] combines commercial networks and research resources to obtain a large-scale

experimentation environment. They use real Android mobile phones in the commercial network

complemented with tools like FEP by adopting Fedora, NS-3, VirtualBox and Docker. This

approach is very close to the Monroe project [17], where scalability is provided thanks to a

number of ad-hoc monitoring platforms working as mobile phones connected to commercial

networks. Compared to EuWireless, these proposals only expect to use commercial phones as

execution/monitoring nodes, but no control on other MNO elements like eNBs or advance use

of the spectrum are expected.

Many other testbeds designed for experimentation with wireless and cellular networks are

focussed on indoor deployments, and EuWireless could take from them ideas on how to monitor

and control the experiment lifecycle or the actual applications and KPIs. Most detailed

descriptions are in the FIRE Book [18].

4.4.2 Questionnaire analysis

First the consortium performed a preliminary (trial), open question questionnaire among

partners and a couple of external respondents in order to extract the topics for a closed-question

final questionnaire. This questionnaire consisted of 13 questions which are listed in section

Błąd! Nie można odnaleźć źródła odwołania.. There were nine participants. Below we

summarize the answers to the questions.

Question Preliminary questionnaire summary of responses

Q1 Almost all respondents indicated that access to commercial MNO infrastructure is

essential to validate new technologies and that there is a need for open large-

scale trials and pilots in realistic field conditions, as well as in realistic telecom

infrastructures, which is not currently fully possible. The respondents noted that

due to the legal obligation for commercial MNO to not allow interference in

production networks, the production and experimental networks was not

currently feasible and testing on commercial MNOs is restricted. For example, it

is hard to get the data from MNOs, and perform fully customized trials. Existing

testbeds are mainly focused on indoor and miss the mobility component, the

testing on fully commercial infrastructures is right now only available for

fixed networks. All this, according to respondents, results in curbing the research

in licensed spectrum as compared to unlicensed spectrum. Setting up an operator

dedicated for research would help to simplify testing, by removing the need to


EuWireless PU 64

set up the whole environment by an experimenter. Especially for 5G, which has a

modular architecture, testing will thus be more accessible to SMEs. Moreover, the

respondents pointed out that there should be access to such infrastructure in an on-

demand way (ad-hoc access and pay-per-use charging) and more customizable

testing environment than commercial MNO should be provided. Also important to

respondents is that such solution would decrease costs of testing. Some

researchers also pointed out that such a solution could increase the collaboration

between commercial MNOs and research groups. However, one respondent

also highlighted the fact that creating a pan European operator does not necessarily

have to be a solution to the aforementioned problems. What is needed, according

to respondents, is the isolation the resources at the MNO level. One respondent

pointed out that they are not sure the project can address the needs of both

commercial and academic researchers, which is a valid point that should be taken

into closer consideration by EuWireless (in categories of risk).

Q2 70% of respondents is familiar with online testbeds.

Q3 As main capability that would enable future experimentation respondents

listed spectrum sharing (60% of respondents) and costs and incentives for

MNOs (40% of respondents). As further barriers respondents listed business related issues SLAs and vendor

lock- in, lack of regulations, lack of technical solutions and lack of business

models

Q4

As the main incentive for MNOs respondents pointed out early access to

results. Other very important aspects listed by respondents are: (a) reduction in

spectrum fees, (b) isolation of testing from commercial services, (c) access to

value added (e.g. from big data) and (d) clearer business models/value added.

As less valuable incentives the respondents listed: (a) business models/clarifying

revenue stream,(b) getting talents from research teams and (c) improved PR.

Finally, as least important, they listed: new revenue opportunities, discounts on

OPEX/financial compensation, visibility, government stimuli, access to improved

functionalities or expecting improved QoE after implementing results.

Q5

As the most important technical enablers respondents listed: access to spectrum

(85% of respondents), access to specific components of the verticals like IoT,

cars, UEs, etc. (60% of respondents), access to test environments (70% of

respondents).

Other technical enablers listed by respondents included reconfigurability,

availability of new/relevant 3GPP specifications in the MNO offer (DÉCOR,

MOCN), new features, like: e2e slicing, scheduling, local breakout, carrier

aggregation (CA), and security.

Q6

Regarding the operational enablers considered as important respondents listed

Accessibility (95% of respondents), Cost (95% of respondents), Privacy (60% of respondents), Security (45% of respondents)

Other listed operational enablers included: Regulatory incentives, Experimentation

governance needed, and Ease of use.

Q7 As the most interesting use cases the respondents listed

applying big data analytics,

new functionalities testing (D2D, NBIoT, etc.),

comparison between countries,

being able to test various algorithms with particular RAN settings,

testing of applications and communication protocols in real network

conditions,

large scale trials in cities (e.g. public events).

As less interesting use cases the respondents listed: QoS/QoE tests, functionality


EuWireless PU 65

testing for cluster of stations (handover, scheduling, interference cancelling, etc.),

ability to switch elements of RRH (experimental, SoC, etc.) and verify and

validate research solutions of interest, and international trials (e.g. mobility).

As least interesting use cases the respondents listed:

Comparison between users' profiles,

services testing (e.g. NFV),

access to a selected area infrastructure (e.g. eNBs/BS scoped on the map),

selection of particular resources which should be "rented" per experiment

(e.g. isolation of MNO HW/SW elements);

using scripting languages or WWW GUI to define experiments in nice

way, long term trials e.g. sensing.

Q8 As the most important benefits the respondents listed:

Ability to extend R&D networks to the mobile device,

NB-IoT testing,

the need to validate and verify algorithms (scheduler, centralized

scheduler, spectrum sharing etc.),

access to the latest features and devices that support them, field testing on

regulated spectrum.

As less important benefits the respondents listed:

QoE analytics in commercial networks,

create and evaluate new use cases,

the need to evaluate various implementations of infrastructure

components.

As minor benefits the respondents listed:

access to Call Detail Records (CDR),

collection and export of wide range of results and network statistics,

straightforward ways to collect/dump/export data during experiment.

As least important benefits the respondents listed the availability of open data

from past experiments for easy experiment configuration (e.g. plug and play, click

to deploy, etc.).

Q9

As the most important barriers the respondents listed:

Exploring the real variety of users' profiles,

Lack of access to regulated/licensed spectrum,

lack of complete and reliable open-source eNB software,

limited access to reasonable number of real UEs in the field when/where

needed for experimenting,

non-repetitive behavior of the network.

As a little less important barriers the respondents listed:

exploring the variety of networks' settings,

cost of infrastructure deployment,

difficult to test/validate a single algorithm/component,

high cost of using commercial networks for research,

unknown network configuration.

As minor barriers the respondents listed: fragmentation of testbed systems (no

common GUI, interfaces, means to store and process-data, etc.), no access to

realistic field-testing locations.

As least important barriers the respondents listed:


EuWireless PU 66

the existing experimental HW is not stable,

performing experiment is sometimes very time consuming and

repeating it not possible,

no single dashboard/entry point to perform experiments (Simulate,

emulate, field tests) and then compare results between various modalities

of experiment

Q10

As most important the respondents listed:

RAN virtualization,

eNB: MAC, PHY for resource allocation algorithms/mechanisms,

the basic requirement is access to spectrum and access to base stations to

program the use of the allocated spectrum,

NB-IoT,

internal network interfaces.

As less important the respondents listed:

spectrum sharing – algorithms and settings,

RRM algorithms,

the network infrastructure,

including new features (devices, radio access points),

VoLTE,

CDR-Call Detail Records.

As minor importance the respondents listed: spectrum that allows to test all

spectrum-related functionalities (e.g. carrier aggregation), various mechanisms:

carrier aggregation, Comp, MEC, NFV and, mobility settings, packet data

gateways, VoLTE

As least important the respondents listed: access to internal LTE interface

statistics, UEs - for testing, validation and mobility, control signaling, content

delivery servers.

Q11

As most popular choices the respondents specified browser or web service (60% of

respondents) and NMS (10% of respondents).

Respondents also pointed out that Access to the MNO infrastructure should

be consistent with access to other testbed facilities in existing core networks and that access should be dynamic and programable.

Q12

As most important the respondents listed: Access to raw data, Deterministic

performance, dedicated resources for some time / isolation, privacy & security,

SLA

As less important the respondents listed: Access to network settings, dedicated

resources, SLA for services on a "pay as you go" basis, Continuous monitoring of

vital statistics.

As minor importance the respondents listed: high freedom of algorithms

implementation, virtualization, time scheduled experiments, dedicated resources,

end-to-end monitoring visibility, SLA.

As least important the respondents listed: continuous monitoring of vital statistics,

policy based (script based) experiment configuration, script reuse.

Q13 Respondents would like to have both online and offline option for data access.

Download detail data to process offline (eg. CSV format) in non-real time or

access to online analysis of less detailed data with measurements and visualization

(web interface, GUI) in real time. Some of them would also like to be able define

triggers for log recording. Respondents also pointed out that key questions

should be addressed about data privacy and security.


EuWireless PU 67

The preliminary questionnaire served as a basis to formulate the questions and possible answers

in the final questionnaire. In the final questionnaire there were 20 participants. The final

questionnaire consisted of 14 questions which are listed in section Błąd! Nie można odnaleźć

źródła odwołania.. Below we summarize the results of this questionnaire.


EuWireless PU 68

Question Final questionnaire summary of responses

Q1 The majority of respondents were either scientific research institutes (35%) or

industry research departments (25%) or SMEs (25%).

Q2 65% of respondents declared intention to use a mobile network operator for

research while 30% were not sure and only 5% would not use such a system.

Q3 Majority of respondents would use the mobile operator for research to test new

network components (40%), test wireless devices in a controlled live-alike

scenario (40%), or in a specific scenario, eg. InterRAT handovers (40%).


EuWireless PU 69

Q4

The respondents are mostly familiar with the GEANT (42%), Fed4Fire (31.6%),

and Triangle (31.6%). Many respondents are also not familiar with any testbed

services in Europe (31%).

Q5

Majority of respondents would like to have access to 5G (90%) and 4G (60%)

technologies, many are also interested in Wi-Fi (35%).

Q6 Most respondents are interested in local area coverage (68.4%), city coverage


EuWireless PU 70

(63.2%) and indoor coverage (52.6%).

Q7 The most relevant enablers listed by respondents were access to spectrum (73.7%),

access to test environments with bad/good coverage (68.4%) and access to

verticals, e.g. emergency services connected cars (57.9%).

Q8 According to respondents the most important enablers that would foster the

emergence of a pan-EU operator are: accessibility (57.9%), ease of configuring the

test or experiment (57.9%) other enablers include cost (36.8%) and Access to

detailed eNB/core settings (36.8%).


EuWireless PU 71

Q9

The most important barriers listed by respondents are access to specific network

infrastructure (75%) and obtaining required network functionalities, like data

bandwidth, new services, etc. (55%).

Q10

The elements of the MNO infrastructure that the respondents were most interested

in having access to were spectrum (78.9%), devices (68.4%), data and control

plane (52.6%).


EuWireless PU 72

Q11

Most respondents woild like to access data via a web browser with a GUI (75%)

and web service (45%).

Q12

When asked about the support expected from mobile operator for research

(EuWireless) most respondents indicates the dedicated support from such operator

(76.6%), or helpdesk (58.8%) as vital. Around 50% of respondents would

appreciate continuous monitoring of vital statistics and only 25% indicated the

need for SLA. In the consortium opinion such feedback is at least questionable, as

it is hard to imagine that EuWireless “slice of resources” provided to researchers

would not guarantee strong isolation from commercial traffic and stable QoS.


EuWireless PU 73

Q13 Most respondents are not sure they would pay for such a pan-European operator

for research (45%), almost one third would not pay (30%) and one fourth would

not consider a payment problematic (25%). It definitely shows that there is a need

for relevant business models, that enable operation of EuWireless operator.

Relevant business model would remove strain from the “hesitators” or would

provide financing from alternative sources.

What can be seen is that responses to relevant questions in both questionnaires are aligned and

complement each other. Lots of interesting information was collected in the first (trial)

questionnaire as the questions were open. This way a number of “non regulated” responses

appeared. Still it looks like in the case of EuWireless too many degrees of freedom left to

respondents is not perfect solution for any respondent due to excessive (solution) search space

for respondents.

4.4.3 Mobile Network Operators

This section first addresses a top-down approach on how to effectively access MNO’s

resources, especially on the aspects of getting access to the regulated spectrum. Some potential

paths towards MNOs and some examples of the existing partnerships in EU, which tackle the

problem of missing 5G experimental research environments, are also provided from the

countries of some of the project partners, i.e. Poland and Finland. The more specific and

detailed analysis of regulatory context in most countries in Europe is performed in Task 1.2 and

will be reported in the D1.2 deliverable (to be delivered by M12).


EuWireless PU 74

4.4.3.1 MNO Roadmaps

The GSM Association (GSMA) and the Global Mobile Suppliers Association (GSA) market

reports [19], [20] are utilised to gather information on the global trends and timelines related to

MNO infrastructure and business development plans. The general information available from

these reports is mainly used to assess the feasibility of the requirements stemming from other

sources. If some of the collected requirements are seen to be hard to fulfil in the near future, e.g.

due to missing technical enablers in the MNO roadmaps, development of alternative solutions

can be taken into consideration when the EuWireless architecture is specified. Moreover, this

information is especially valuable when a gap analysis between the EuWireless requirements,

standardisation roadmaps and MNO technology deployment/migration plans are performed.

More details related to the plans of the European MNOs will be gathered in interviews during

the first year of the EuWireless project. The interviews will also be used to assess the MNOs’

willingness to move from currently prevailing bilateral collaboration agreements towards more

open R&D cooperation and network sharing methods in the future.

From the regulation perspective, the most important method to dynamically access MNO-

owned regulated spectrum in Europe should be based on LSA. The scope and definition of this

spectrum management approach is introduced in the European Conference of Postal and

Telecommunications Administrations’ (CEPT) Electronic Communications Committee (ECC)

Report 205 [21]. This report is utilised when defining the functional requirements for spectrum

sharing in the EuWireless context. The work on specific enablers related with spectrum sharing

is performed under Task 1.3 and reported in deliverable D1.3 (at M10).

4.4.3.2 Case Studies in Poland and Finland

The base station vendors and academia cooperate with each other around the world. Recently in

Poland, the first LTE network has been established to be utilized for research purposes and

demonstrations at AGH University in cooperation with Nokia. It consists of servers, five base

stations located outside and inside the building, antennas and purchased license for the radio

band. The LTE network, which operates on the LTE campus, consists of several base stations

and a fully functional backbone network and servers located in the laboratory. Exactly the same

elements comprise the LTE networks used by operators. Of course, academic base stations have

licenses to use licensed frequencies. Owing to this, scientific staff and students will be able to

conduct research using a real mobile network that operates under real conditions. This type of

research has a much greater scientific value, because the conducted experiments include all

physical phenomena, which is extremely difficult to reflect in the laboratory Błąd! Nie można

odnaleźć źródła odwołania.. The main topics to be addressed are IoT and 5G as the base

stations have been customized for the research purposes.

A similar approach has been used also in Finland, where the 5G Test Network Finland (5GTNF)

testbed sites in different cities utilize either commercial LTE frequency bands or 5G candidate

frequencies for their field-testing facilities. For example, in the city of Oulu, the local 5G test

network has deployed outdoor macro cell and indoor small cell coverage to both VTT Oulu and

University of Oulu campus areas by loaning the licensed frequencies directly from the Finnish

MNOs. For the prototype 5G radios in the test network, the 5G test frequencies are loaned from

Nokia, which is the main equipment vendor in the network. In addition, test licenses for LSA

trials in other frequency bands have been applied directly from the Finnish Communications

Regulation Authority (FICORA) for indoor use in Oulu and for outdoor use in the city of

Ylivieska, where Centria University of Applied Sciences hosts a large LSA field-testing site as

part of the national 5GTNF ecosystem. All of the loaned and applied licenses are temporary,

managed with bilateral fixed term contracts, and valid only for the specific locations where the

test network operates. However, even though the licenses are temporary, the loaning and


EuWireless PU 75

licensing procedures are lightweight and the processing times related to the handling of the

applications are short.

In general, starting from 2018, many regulators in EU have enabled the free access to the few

frequency bands for 5G. This has happened e.g. in Poland, where currently the 5G strategy

documents are being defined. Some interesting topics covered in this document are (among

others): access to spectrum, trials/testbeds capabilities and needs, etc. [23]. Similar documents

are defined across Europe to help managing 5G developments and deployments in a top-down,

systematic way.

4.4.4 Standards and Specifications

In this section, a list of the most relevant reference standards and specifications is presented and

divided into groups related to network sharing, virtualisation, dynamic spectrum sharing and

connected cars. In addition to the requirement specification, the listed documents are used in

Task 1.3 in order to study the enabling technologies that will support the design and

implementation of EuWireless pan-European research infrastructure.

4.4.4.1 Enabling Technologies

The following technical specifications and reports have been considered to study network

sharing enablers:

3GPP TR 22.951: Service aspects and requirements for network sharing [23].

3GPP TS 23.060: General Packet Radio Service (GPRS). Service description.

3GPP TS 23.236: Intra-domain connection of Radio Access Network (RAN) nodes to

multiple Core Network (CN) nodes.

3GPP TS 23.251: Network Sharing; Architecture and functional description [25].

3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved

Universal Terrestrial Radio Access Network (E-UTRAN) access.

3GPP TS 23.501: System Architecture for the 5G System. Stage 2 [26].

3GPP TS 23.502: Procedures for the 5G System.

3GPP TS 23.503: Policy and Charging Control Framework for the 5G System.

3GPP TR 23.707: Architecture enhancements for dedicated core networks; Stage 2.

3GPP TR 23.799: Study on Architecture for Next Generation System.

3GPP TR 28.802: Study on management and orchestration of network slicing for next

generation network.

3GPP TS 28.530: Management of 5G networks and network slicing. Concepts, use

cases and requirements.

3GPP TS 37.340: Evolved Universal Terrestrial Radio Access (E-UTRA) and NR.

Multi-connectivity.

3GPP TS 38.300: NR. NR and NG-RAN Overall Description [27].

3GPP TS 38.401: NG-RAN. Architecture description [28].

3GPP TR 38.801: Study on new radio access technology: Radio access architecture and

interfaces [29].

These standards contain the architecture options for 4G network sharing and 5G network

deployments. Availability of different features in European MNO infrastructures is assessed by

analysing the industry roadmaps and during the MNO interviews.


EuWireless PU 76

The following standards and technical reports have been considered to study NFV and SDN

technologies, including the aspects of network security, reliability and robustness:

ETSI GS NFV-EVE 005: Network Functions Virtualisation (NFV); Ecosystem; Report

on SDN Usage in NFV Architectural Framework.

ETSI GS NFV-REL 003: Network Functions Virtualisation (NFV); Reliability; Report

on Models and Features for End-to-End Reliability

ETSI GS NFV-REL 004: Network Functions Virtualisation (NFV) Assurance; Report

on Active Monitoring and Failure Detection.

ETSI GS NFT-TST 001: Network Functions Virtualisation (NFV); Pre-deployment

Testing; Report on Validation of NFV Environments and Services.

ETSI GS NFV-TST 002: Network Functions Virtualisation (NFV); Testing

Methodology; Report on NFV Interoperability Testing Methodology.

IETF RFC 7426: SDN: Layers and Architecture Terminology

In order to include the essential technical requirements related to dynamic spectrum sharing into

the EuWireless requirement specification, the following LSA standards from the European

Telecommunications Standards Institute (ETSI) and the 3rd

Generation Partnership Project

(3GPP) are utilised:

ETSI TR 103 133: Mobile broadband services in the 2 300 MHz – 2 400 MHz

frequency band under Licensed Shared Access regime [30].

ETSI TS 103 154: System requirements for operation of Mobile Broadband Systems in

the 2 300 MHz – 2 400 MHz band under Licensed Shared Access (LSA) [31]

ETSI TS 103 235: System architecture and high level procedures for operation of

Licensed Shared Access (LSA) in the 2 300 MHz – 2 400 MHz band [32]

ETSI TS 103 379: Information elements and protocols for the interface between LSA

Controller (LC) and LSA Repository (LR) for operation of Licensed Shared Access

(LSA) in the 2 300 MHz – 2 400 MHz band [33]

3GPP TR 32.855: Study on OAM support for Licensed Shared Access (LSA) [34].

3GPP TS 28.301: Licensed Shared Access (LSA) Controller (LC) Integration Reference

Point (IRP); Requirements [35].

These standards lay the foundation on how LSA should be integrated into the mobile network

infrastructure and define the required interfaces and signalling procedures that must be

supported.

4.4.4.2 Connected car

Currently there are mainly two technologies competing to take the leadership in V2X

communications: DSRC and C-V2X. The following standards from ETSI and 3GPP have been

considered to define the essential technical requirements for both DSRC and C-V2X.

The following standards have been considered for the DSRC technology:

ETSI TR 102 638: Intelligent Transport Systems (ITS); Vehicular Communications;

Basic Set of Applications; Definitions.

ETSI TS 102 637-1: Intelligent Transport Systems (ITS); Vehicular Communications;

Basic Set of Applications; Part 1: Functional Requirements.

ETSI TS 102 940: Intelligent Transport Systems (ITS); Security; ITS communications

security architecture and security management.


C2C-CC Demonstrator 2008; Use Cases and Technical Specifications.


EuWireless PU 77


Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic

Service.

Vehicle Safety Communications –Applications (VSC-A). Final Report (NHTSA).

C-V2X technology is being defined by 3GPP. Following standards have been used to elaborate

the connected car case study requirements:

3GPP TS 22.185 V15.0.0 Service requirements for V2X services; Stage 1 (Release 15)

3GPP TS 23.285 V15.1.0 Architecture enhancements for V2X services (Release 15).

3GPP TS 23.501 V15.2.0 System Architecture for the 5G System; Stage 2.

3GPP TS 23.501 V15.2.0 Security aspect for LTE support of Vehicle-to-Everything

(V2X) services.

4.4.5 Other R&D Projects

EuWireless communication, exploitation and dissemination plan [36] contains a preliminary list

of identified R&D projects, associations and organisations for liaison. The presented list is not

meant to be exhaustive, but offers a starting point for discussions on cooperation and

information sharing between the EuWireless consortium and third parties. From the EuWireless

requirement specification perspective, the liaison groups focusing on activities related to the

EuWireless use cases and case studies are the most probable sources for additional requirement

candidates. In addition, the groups working on recommendations and specifications in the area

of key enabling technologies for network sharing are seen as a potential requirement candidate

source.

Regarding the Fed4FIRE project, the consortium has direct access to the experience related to

Fed4FIRE experimentation as one of partners in EuWireless (UMA) is also a Fed4FIRE testbed

provider. EuWireless partners who are members of the Fed4FIRE project utilised their access to

deliverables of Fed4FIRE with summaries of 1st and 2

nd open calls [3],[4],[5],[6] to structure the

requirements. They have provided a very interesting set of requirements received directly from

multiple end users (experimenters). Moreover, EuWireless partners have been able to discuss

with the Fed4FIRE teams during face-to-face meetings at various events. After preparing the

current set of requirements, the Fed4FIRE deliverables have been thoroughly analysed to check

for potential missing requirements.

The H2020 5G related projects funded recently from the ICT-17-2018 call will build end-to-end

5G networks for validation of the 5G KPIs and experimentation with specific vertical use cases

[37]. The three projects called 5G EVE, 5G VINNI and 5GENESIS will address common trends

like real virtualization of the core network, full end-to-end slicing, APIs to verticals or support

to control and monitor the experiment lifecycle. All these areas could help to define EuWireless

requirements and architectural solutions. Although EuWireless ends at the of 2019, the

consortium will consider the collaboration with projects funded in the upcoming ICT calls ICT-

19-2019 (Advanced 5G validation trials across multiple vertical industries) and ICT-20-2019

(5G Long Term Evolution). Projects funded in ICT-19-2019 will validate 5G technology and

architecture for specific verticals, while projects funded in ICT-20-2019 will cover improving

technological challenges such as virtualisation, security and radio access technologies.

Clearly, these projects would benefit from the implementation of a pan-European research

infrastructure such as EuWireless. At this stage, EuWireless use cases and architecture could be

used as input for these projects. In addition, the lessons learned in these projects are valuable for

a future implementation of EuWireless.


EuWireless PU 78

4.4.6 Analysis of Legal Framework for Spectrum Sharing

The legal documents are analysed in Task 1.2 and summarized in the deliverable D1.2. The

reader is referred to read this document for legal domain information.


EuWireless PU 79

5 Conclusions

The activities performed in WP1 of the EuWireless project have resulted in a list of

requirements of different nature. The list of requirements is at the moment ready for further

usage in the architectural works of the WP2 and also available for collecting further

stakeholders feedback during the ongoing dissemination events (e.g. TCN2019, EuCNC2019).

However the consortium will treat the list of requirements as a baseline document for remaining

activities in the project.

These requirements have been classified according to the types of requirements of the network,

such as functional or performance, but also, they have been classified taking into account the

network architecture elements where such requirements are going to be handled (access nodes,

core network, interfaces, etc.). In this two-dimensions classification, 9 types of requirements

have been identified (interfaces and system design, functional, extensions, operational,

management, performance, measurement and monitoring, logistical and organizational and legal

aspects) and 8 relevant architecture elements (overall system, user equipment, access nodes,

spectrum, transport network, core network and MEC, multi-access edge computing).

The consortium would like to highlight that in general during the whole process of requirements

gathering there was many valuable insights from external respondents, as well as from the

different SOTA sources and the project Advisory Board. But the general outcome of the process

is even higher conviction that there indeed a missing capability of pan-European operator for

research. Lots of interesting feedback was gathered from the respondents and triggered many

internal discussions and helped to converge between partners on the more aligned vision of

what the target shape of EuWireless operator should be. This way further work in WP2 will rely

on this solid based of requirements as a navigating light for architecture design.


EuWireless PU 80

6 References

[1] Almudena Díaz-Zayas, César A. García-Pérez, Álvaro M. Recio-Pérez, Pedro Merino

Gómez: “PerformLTE: A Testbed for LTE Testing in the Future Internet”. WWIC 2015:

46-59.

[2] Álvaro M. Recio-Pérez, Almudena Díaz, Pedro Merino: “Characterizing Radio and

Networking Power Consumption in LTE Networks.” Mobile Information Systems 2016:

2752961:1-2752961:10 (2016).

[3] Fed4FIRE. Deliverable “D10.1 – Report on first open call experiments”. Submission date

13/02/2015. Available at: https://www.fed4fire.eu/wp-content/uploads/2016/10/d10-1-

report-on-first-open-call-experiments.pdf

[4] Fed4FIRE. Deliverable “D10.2 – Evaluation report on first open call experiments”.

Submission date 16/02/2015. Available at: https://www.fed4fire.eu/wp-

content/uploads/2016/10/d10-2-evaluation-of-1st-open-call-experiments.pdf

[5] Fed4FIRE. Deliverable “D10.3 – Report on second open call and SME experiments”.


content/uploads/2016/10/d10-3-report-on-second-open-call-and-sme-experiments.pdf

[6] Fed4FIRE. Deliverable “D10.4 – Evaluation report on 2nd open call experiments”.


content/uploads/2016/10/d10-4-evaluation-of-2nd-open-call-experiments.pdf

[7] Serge Fdida, Ivan Seskar, Peter Steenkiste, Brecht Vermeulen (Eds.) “Report from the

EU/US Future Networks Workshop”. November 11, 2017. Available at:

https://fed4fire.eu/wp-content/uploads/sites/10/2017/11/eu_us-future-networks_final.pdf

[8] Rachid El Hattachi and Javan Erfanian (Eds.). NGMN Alliance “NGMN 5G white

paper”.

https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2015/NGMN_5G_

White_Paper_V1_0.pdf

[9] 3rd

Generation Partnership Project. “General Packet Radio Service (GPRS) enhancements

for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access” 3GPP TS

23.401 v15.4.0, June 2018

[10] 3rd

Generation Partnership Project. “3GPP System Architecture Evolution (SAE);

Security architecture”. 3GPP TS 33.401 v15.4.0, June 2018

[11] 3rd

Generation Partnership Project. “Evolved Packet System (EPS); Mobility

Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces

based on Diameter protocol”. 3GPP TS29.272 v15.4.0, June 2018

[12] Pierre Bourque and Richard E. Fairley. “The Guide to the Software Engineering Body of

Knowledge v3”. IEEE Computer Society Press, Los Alamitos, CA, USA 2014.

ISBN:0769551661 9780769551661

[13] ISO/IEC/IEEE. 2011. “Systems and Software Engineering - Requirements Engineering”.

Geneva, Switzerland: International Organization for Standardization (ISO)/International

Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE),

(IEC), ISO/IEC/IEEE 29148.

[14] EuWireless project, “Description of Action,” V1.3, 13.10.2017.

[15] A. Gosain and I. Seskar, "GENI wireless testbed: An open edge ecosystem for ubiquitous

computing applications," 2017 IEEE International Conference on Pervasive Computing

and Communications Workshops (PerCom Workshops), Kona, HI, 2017, pp. 54-56. doi:

10.1109/PERCOMW.2017.7917520

[16] T. Zhang, S. Zhao, B. Cheng, B. Ren and J. Chen, "FEP: High Fidelity Experiment

Platform for Mobile Networks," in IEEE Access, vol. 6, pp. 3858-3871, 2018. doi:

10.1109/ACCESS.2018.2793943

[17] Özgü Alay, Andra Lutu, Miguel Peon-Quiros, Vincenzo Mancuso, Thomas Hirsch,

Kristian Evensen, Audun Hansen, Stefan Alfredsson, Jonas Karlsson, Anna Brunstrom,

https://www.fed4fire.eu/wp-content/uploads/2016/10/d10-2-evaluation-of-1st-open-call-experiments.pdf


https://www.fed4fire.eu/wp-content/uploads/2016/10/d10-4-evaluation-of-2nd-open-call-experiments.pdf


https://fed4fire.eu/wp-content/uploads/sites/10/2017/11/eu_us-future-networks_final.pdf

https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2015/NGMN_5G_White_Paper_V1_0.pdf

https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2015/NGMN_5G_White_Paper_V1_0.pdf


EuWireless PU 81

A. Ssafari Khatouni, Marco Mellia and Marco Ajmone Marsan: Experience: An Open

Platform for Experimentation with Commercial Mobile Broadband Networks,

ACM MOBICOM 2017.

[18] Martin Serrano, Michael Boniface, John Domingue, Nikolaos Isaris, Thanasis Korakis,

and Hans Schaffers. 2017. Building the Future Internet Through FIRE: 2016 FIRE Book -

a Research and Experimentation Based Approach. River Publishers, Wharton, TX, USA.

[19] GSM Association, “The Mobile Economy 2018,” GSMA Intelligence Report, 2018

[20] Global mobile Suppliers Association, “Evolution from LTE to 5G - April 2018 Update,”

GSA Report, April 2018.

[21] Electronic Communications Committee, “Licensed Shared Access (LSA),” ECC Report

2015, February 2014.

[22] “Nokia and AGH the polish university launches first private LTE network”

https://www.nokiakrakow.pl/en/blog/first-academic-lte-network-poland-will-be-opened-

agh

[23] Polish Ministry of Digitization, “We want to be the European leader in 5G”,

https://www.gov.pl/documents/31305/204093/we_want_to_be_the_european_leader_in_

5g.pdf/50625814-feef-2f35-ca17-e4cb30131aa6, 29.11.2018

[24] 3rd

Generation Partnership Project, “Service aspects and requirements for network sharing

– Release 14,” 3GPP TR 22.951, March 2017.

[25] 3rd

Generation Partnership Project, “Network Sharing; Architecture and functional

description – Release 14,” 3GPP TS 23.251, September 2017.

[26] 3rd

Generation Partnership Project, “System Architecture for the 5G System; Stage 2 –

Release 15,” 3GPP TS 23.501, March 2018.

[27] 3rd

Generation Partnership Project, “NR and NG-RAN Overall Description; Stage 2 –

Release 15,” 3GPP TS 38.300, March 2018.

[28] 3rd

Generation Partnership Project, “NG-RAN; Architecture description – Release 15,”

3GPP TS 38.401, March 2018.

[29] 3rd

Generation Partnership Project, “Study on new radio access technology: Radio access

architecture and interfaces,” 3GPP TR 38.801, March 2017.

[30] European Telecommunications Standards Institute, “Mobile broadband services in the 2

300 MHz – 2 400 MHz frequency band under Licensed Shared Access regime,” ETSI TR

103 133, July 2013.

[31] European Telecommunications Standards Institute, “System requirements for operation of

Mobile Broadband Systems in the 2 300 MHz – 2 400 MHz band under Licensed Shared

Access (LSA),” ETSI TS 103 154, October 2014.

[32] European Telecommunications Standards Institute, “System architecture and high level

procedures for operation of Licensed Shared Access (LSA) in the 2 300 MHz – 2 400

MHz band,” ETSI TS 103 235, October 2015.

[33] European Telecommunications Standards Institute, “Information elements and protocols

for the interface between LSA Controller (LC) and LSA Repository (LR) for operation of

Licensed Shared Access (LSA) in the 2 300 MHz – 2 400 MHz band,” ETSI TS 103 379,

January 2017.

[34] 3rd

Generation Partnership Project, “Study on OAM support for Licensed Shared Access

(LSA) – Release 14,” 3GPP TR 32.855, March 2016.

[35] 3rd

Generation Partnership Project, “Licensed Shared Access (LSA) Controller (LC)

Integration Reference Point (IRP); Requirements – Release 14,” 3GPP TS 28.301, June

2017.

[36] EuWireless project, “Communication, exploitation and dissemination plan” Deliverable

D4.2, Version 1.0, April 2018.

[37] Alessandro Bedeschi, 5GPPP Press Release. “EC Launches 5G PPP Phase 3 with three

new projects”, June 20, 2018. Available at https://5g-ppp.eu/ec-launches-5g-ppp-phase-3-

with-three-new-projects/

[38] Optimizing 5G for V2X, http://www.ieeevtc.org/conf-admin/vtc2016fall/29.pdf

https://www.gov.pl/documents/31305/204093/we_want_to_be_the_european_leader_in_5g.pdf/50625814-feef-2f35-ca17-e4cb30131aa6

https://www.gov.pl/documents/31305/204093/we_want_to_be_the_european_leader_in_5g.pdf/50625814-feef-2f35-ca17-e4cb30131aa6

https://5g-ppp.eu/ec-launches-5g-ppp-phase-3-with-three-new-projects/

https://5g-ppp.eu/ec-launches-5g-ppp-phase-3-with-three-new-projects/

http://www.ieeevtc.org/conf-admin/vtc2016fall/29.pdf


EuWireless PU 82

[39] https://en.wikipedia.org/wiki/MoSCoW_method

7 Appendices

7.1 Appendix1: Online Questionnaires

7.1.1 Questionnaire v1.0

1. Why establishing a pan-European R&D mobile operator would be needed to support the

current process of mobile networks oriented experimentation?

Please enumerate your arguments (bullet points) and where suitable shortly motivate your

answer.

2. Are you familiar with any wireless testbed services around Europe (e.g Geant Testbed

Services, Fed4Fire, Genie, etc.) that is providing wireless network facilities of a kind?

Yes

No

Sample links:

https://www.geant.org/Services/Connectivity_and_network/GTS

https://www.fed4fire.eu/

If your answer is yes then please provide:

Testbed name (or hyperlink):

1-5 key differentiating points of this service:

1-5 missing functionalities/capabilities:

3. What do you believe, are the main barriers for the emergence of pan-EU R&D mobile

operator? (e.g. "high cost of large scale build out of infrastructure", "it is not possible to test in

licensing spectrum", "lack of SLA guarantees", etc.)?

Please identify 2-5 and try to prioritize (i.e. 5 - critical priority, 4 - high priority, 3 reasonable

priority; 2 - mediocre priority; 1 - rather low priority)

5:


EuWireless PU 83

4:

3:

2:

1:

4. What incentives should be there for Mobile Network Operators (MNOs) to share its

infrastructure? (e.g. "some discounts on OPEX costs", "improved network/QoE after

introducing validated research", "press release", "early access to results", etc.)



5:

4:

3:

2:

1:

5. Which are the key "technical" enablers that would foster emergence of pan-EU R&D mobile

operator?

Access to spectrum

Access to specific components of the vertical markets (e.g. cars, IoTs, UEs, etc)

Access to test environments with good coverage

Others

If other, please specify separated by ";"

6. Which are the key "operational" enablers that would foster emergence of pan-EU R&D

mobile operator?

Cost

Accessibility

Privacy


EuWireless PU 84

Security

Others

If other, please specify separated by ";"

7. Please enumerate most interesting use-cases for utilizing MNOs infrastructure if access

to their infrastructure is provided in a managed way (e.g. “new mechanisms testing

(improved handover, HARQ, scheduler)”, “new functionalities testing (D2D, NBIoT, etc)”,

“functionalities testing for cluster of stations (handover, scheduling, interference cancelling,

etc.)”, “services testing (e.g. NFV), etc.).

Please identify 2-5 most important use-cases, please note that the list below is NOT connected

to priorities this time.

5:

4:

3:

2:

1:

8. As a small testbed owner/technology provider (e.g. F4F) can you name 1-5 needs

regarding the access to the commercial mobile network operator infrastructure from your

experience so far? (e.g. validate and verify algorithms, evaluate infrastructure components,

collect and export data, open data availability, etc.)

This question is addressed not only to “Testbed owners” and their needs but also to various

kinds of “technology providers” like e.g. SMEs, vendors, etc. who develop solutions (SW,

algorithms, HW) for more in –depth access to MNOs infrastructure for performing

tests/experiments and evaluations



5:

4:

3:

2:


EuWireless PU 85

1:

9. What are today the key barriers for performing comprehensive (e2e) research on

mobile networks, based on your experience so far? (e.g. number of real UE available,

difficult to deploy new algorithms, diversity of testbed APIs, etc.)


priority; 2 - mediocre priority; 1 - rather low priority). Please try to argument "why" given

aspect requires access to MNO infrastructure

5:

4:

3:

2:

1:

10. Which elements of the MNO infrastructure, you would like to have access to (i.e.

share) when experimenting - e.g. spectrum, devices, new network features (carrier

aggregation, VoLTE, NB-IoT, etc.), the internal network interfaces, etc.?



5:

4:

3:

2:

1:

11. How you would like to access the infrastructure of the MNO (e.g. via browser GUI, via

web service, via NMS, other) through the pan-EU R&D mobile operator?




EuWireless PU 86

5:

4:

3:

2:

1:

12. What type of guarantees would you expect from the pan-EU R&D mobile operator in

order to comfortably perform your experiment? (SLA, dedicated resources, continuous

monitoring of vital statistics, etc.).



5:

4:

3:

2:

1:

13. In what way would you like to interact with the data from your experiment – please describe

the optimal way you would like to be able to collect data (e.g. online/offline, web-interface,

access to a database/cloud, other please specify, etc.)

7.1.2 Questionnaire v2.0

Title: Mobile network operator for research

Introduction: EuWireless project objective is to design the first pan-European mobile network

operator to support research in mobile networks using regulated spectrum. Your inputs will help

us to improve our target.

1. Please select your role

a. Scientific / Research institute

b. Research department (Industry)

c. SME (mobile networks, products, services)

d. Agency managing research infrastructure


EuWireless PU 87

e. National/EU regulator

f. Association (e.g. 5G-PPP)

g. EU initiative (e.g. PPP)

h. NREN manager

i. Mobile operator

j. Standarization body

k. HW / SW vendor for mobile networks

l. Non-EU agency / institution

m. Inne:

n. 2. Should it be available, Would you use a mobile network operator for research?

a. Yes

b. No

c. I do not know

3. How would you use the mobile network operator for research?

a. General Research

b. Deploy and evaluate novel or experimental network concepts at scale.

c. Test network components

d. Test functions virtualization

e. Benchmark Network components

f. Test my own HW/SW developments e.g. Base station, virtual components

g. Test wireless devices in a controlled live-alike scenario

h. Test wireless devices in specific scenarios (e.g. difficult to get in real life such

as interRAT handovers)

i. Test wireless devices / network components in heavy traffic load scenarios

j. Other:

k. 4. Are you familiar with any of these network testbed services around Europe?

a. GÉANT

b. Fed4fire

c. TRIANGLE

d. None

e. Other:

f. 5. Which technologies would you like the mobile network operator for research to

provide?

a. 5G

b. 4G

c. 3G/2G

d. Wi-Fi

e. Other:

f. 6. Which coverage area would you require the mobile network operator for research to

provide?

a. Indoor

b. Local area (e.g. 1x1 km2)

c. City

d. Whole country

e. Pan-european

f. Cross-border (between countries)

7. Select the research network technical enablers most relevant for you


EuWireless PU 88

a. Access to spectrum (e.g. bands)

b. Access to verticals (Emergency services, connected cars, etc.)

c. Access to test environments with bad/good coverage

d. Other:

e. 8. Select the research network operational enablers that would foster emergence of a pan-

EU operator?

a. Cost

b. Security

c. Privacy

d. Accessibility

e. Ease of configuring the test/experiment,

f. Access to detailed eNB/core settings

g. Legal issues

h. Organizational issues

i. Other:

j. 9. Based on your experience, What are today the key barriers for performing

comprehensive (e2e) research on mobile networks?

a. Get network configuration information

b. Set network traffic conditions conveniently

c. Obtain required network functionalities (data bandwidth, new services, etc).

d. Get acccess to specific network infrastructure

e. Inne:

f. 10. Which elements of the MNO infrastructure would you like to have access to when

experimenting?

a. Spectrum

b. Devices

c. Data plane

d. Control plane

e. End to end statistics

11. How would you like to access the testing and configuration data at the research

network?

a. Via web browser with GUI (Graphical User Interface)

b. Via web service

c. Via NMS (Network Management System)

d. Other:

e. 12. What type of support would you expect from the mobile network operator for research

in order to comfortably perform your experiment?

a. SLA (Service Level Agreement)

b. Dedicated resources

c. Continuous monitoring of vital statistics

d. Support Helpdesk

e. Other:

f. 13. What type of security guarantees would you expect from the mobile network operator

for research in order to comfortably perform your experiment?

a. Anonimization

b. Data Encription


EuWireless PU 89

c. Exclusive access to resources

d. Other:

e. 14. Would you pay for using a mobile network operator for research?

a. Yes

b. No

c. I do not know

15. Please provide any additional comments you have on the mobile network operator for

research.

7.2 Appendix 2: Other Requirements (to be considered)

This section will keep track of other requirements that have emerged during the consolidation of

the intermediate version of D1.1 deliverable. The purpose of the section is to list the identified

requirements candidates that needs to be processed further before the final version of the

document.

Challenges foreseen by EU/US joint analysis group have been gathered from a report by ESFRI

[7]:

1. RC1.ESFRI (INT): “[…] Defining APIs and open source platforms that are shared

between the US and the EU (and more broadly) is an important enabler for future

collaborative research. Examples include APIs and platforms for sharing virtual

network functions and common ontologies for resource specifications, data integration

and big data analysis, and sensors and IoT services” (pp. 5)

a. EuWireless VNFs should be described using open and standardized descriptors

2. RC2.ESFRI (INT): “[…] platforms have to evolve from academic and research use to

industrial experimentation that also implies open/unified interfaces and ease of use for

large-scale experiments in order to reduce support requirements” (pp.9)

3. RC3.ESFRI (MNG): “[…] need for common management platform and operations

framework addressing the issue of inter-testbed connectivity and federation, or

extending the federation concept from testbed-level to (wireless) node level, enabling

the creation of heterogeneous testbed infrastructures through mixing platforms owned

by different parties.” (pp.9)

4. RC4.ESFRI (LOG):“[…] Need for city/municipality partnership“(pp.9)

5. RC5.ESFRI (LOG): “[…] Managing the expectation of high level of availability and

reliability of the testbed (requiring dedicated support personnel and 24/7 operation)”

(pp.9)

6. RC6.ESFRI (LOG): “[..] The importance of varying levels of user support (i.e.

supporting novice, intermediate and advanced users)”(pp.9)

7. RC7.ESFRI (??): “[…] More explicit support for awareness of data path properties

throughout the stack, and the ability to forward traffic along distinct paths based on

information other than the destination prefix, will allow for richer optimizations of

network treatment per flow and traffic type” (pp.10)

8. RC8.ESFRI (OPE): “[…] multi-domain trust issues should be addressed when enabling

end-to-end path provisioning.” (pp. 12)

a. Rationale: “[..] trust and privacy concerns are also important and vary based on

the class of VNF (smart forwarding versus deeper packet inspection).

Placement of trusted functions (e.g., caching) in untrusted foreign environments

introduces additional challenges”


EuWireless PU 90

9. RC9.ESFRI (INT): “[…] The desired situation we are targeting is for capabilities

providing mechanisms for Service Providers (e.g. verticals, OTT) and Network

Operators to work together in the management of resources required for control and

distribution of content and service delivery. This challenge requires research both

horizontally (resource allocation across stakeholders) and a vertically (User-centric

interfaces).” (pp.14)

10. RC10.ESFRI (FUN): “[…] EuWireless should enable new algorithms to be easily

introduced for resource allocation, using the NFV/SDN interfaces and also applying

data analytics to optimize performance” (pp.14)

11. RC11.ESFRI (FIN, LOG): “[…] There is need for access rules harmonization including

addressing fees and quotas was also mentioned. This extends to sharing of user groups

and should be pushed beyond typical academic organizations to include corporations,

SMEs and verticals. The discussion also touched base on various other issues related to

operation, access and monetization. They are related to hosting equipment, hosting

services and hosting people”

Requirements resulting from analysis of the Fed4FIRE open call’s evaluations [3],[4],[5],[6]:

1. RC1.F4F: It is important to perform measurements acquisition on reserved nodes via

scripts scheduled to run automatically

2. RC2.F4F: access to multiple MNO-infrastructure elements should be unified

3. RC3.F4F: there should be a simple way to connect multiple domains (e.g. MNOs,

testbeds) into an e2e slice in order to ease the capabilities for tests including multiple-

domains (e.g. moving between geographical locations) at the same time (pp.10,

[F4F.D10.2])

4. RC4.F4F: the documentation on accessing and using the EuWireless infrastructure for

experiments should be well documented and centralized under single online repository.

There should also be a dedicated forum for information exchange and support (pp.10,

[F4F.D10.2])

5. RC5.F4F: EuWireless should support advanced experiment resource planning, e.g. to

also consider planning resources allocation in the future (pp.11, [F4F.D10.2])

6. RC6.F4F: EuWireless should provide complete images of VNFs ready to be deployed

as profiles (i.e. complete configuration of RAN, CN, or an e2e slice

7. RC7.F4F: What is missing […] is a more autonomic setup and running of the

experiment. As an experimenter, I would like to design my experiment and then having

an engine that finds the resources and the measurement tool on my behalf (pp. 21,

[F4F.D10.4])

Above-mentioned lists related to potential new requirements need to be compared and verified

with the requirements collected to subsections Błąd! Nie można odnaleźć źródła odwołania.-

3.9. We need to check if they are already covered or if they provide rationale for new

requirements.

7.3 Appendix 3: Alternative prioritisation scheme for requirements

As requirements are prone to eventually become features, the field called “Priority” is then

becoming more important that it looks like in the early stages. My suggestion is that, instead of

assigning a priority like “Must” or “Should”, sometimes the following prioritization approach

can be selected to add more granularity, figures and definitions:






EuWireless PU 91

Priority Name Description

1 Critical Without meeting this requirement, the service is not possible

2 Important Although service is still possible without this requirement,

the overall quality of the service/users experience could be

negatively affected

3 Good to have Without this requirement, the service is not affected, but

having it is perceived as extra value from the users in

quantifiable terms

4 Cosmetic This requirement does not affect the service, but could give

subjective impressions on the product quality and

convenience

Documents

Deliverable D1.1 Requirementseuwireless.eu/wp-content/uploads/2019/01/EuWireless_D1.1.pdfnational roadmaps) were studied as well as most relevant R&D projects (e.g. Fed4FIRE, 5G EVE,