#  Introduction

This deliverable includes two important topics, Data Management Plan (DMP) and
Data Protection Agencies (DPA) Notifications.

Any research project DMP should describe what data the project will generate,
whether and how it will be exploited or made accessible for verification and
re-use, and how it will be curated and preserved.

CogNet project will participate in the EC’s Pilot on Research Data, and to
this end it will deposit relevant data in a research data repository. The
benefits from data sharing will include creating a community around the
dataset, where publications allow validation of results. This will lead to
more collaboration and advanced research, citing the dataset and thus making
project results more visible with greater impact.

To maximise the extent of the data dissemination, CogNet will implement
provisions for third parties to access, mine, exploit and reproduce the data,
including the information necessary for validating project’s results.

This document establishes the plan to satisfy the EC expectations for data
management, which are the following:

  * Any Horizon 2020 project is invited to submit a DMP as an early project deliverable if it is relevant to their research. 

  

  * All projects submitting a research proposal to ‘Research and Innovation Actions’ and ‘Innovation Actions’ are required to include a short outline of their general data management policy. 

  

  * All projects which are successfully funded under the Pilot on Open Research Data are expected to produce an initial DMP deliverable within the first six months of the project 

  

  * Each of the required points for the DMP should be addressed on a dataset-by-dataset basis. 

  

  * List file types, formats, and the reuse potential for other researchers. 

  

  * Where possible use existing metadata standards which will allow for potential integration with other datasets. 

  

  * Explain how your data will be shared, and the level of access to be provided (and why). 

  

  * Use a repository service to deposit your data and where possible make it and the underlying metadata accessible to third parties, free of charge. 

  

  * Arrange backup and storage procedures which are most suited to the partners and nature of your project. 

  

  * Complete more detailed DMPs at regular intervals throughout your project when changes occur or as a minimum in the run up to mid-term and final reviews. 

  

The DMP addresses the main elements of the data management policy that will be
used by the project participants with regard to all datasets. Hence, it also
establishes some procedural mechanisms for participants with the
responsibilities of Data Controllers and Processors. For each dataset, the
following aspects will be considered:

  1. _OVERVIEW OF POLICIES_ : with respect to relevant bordering international initiatives and programs. 

  

  2. _ROLES_ : identifying the different participants, the rules played and their responsibilities. 

  

  3. _DATA SET REFERENCE AND NAME_ : identifier for the data set to be produced. 

  

  4. _DATA SET DESCRIPTION_ : description of the data that will be generated or collected, its origin (in case it is collected), nature, scale, to whom it could be useful, and whether it underpins a scientific publication. Information on the existence (or not) of similar data and the possibilities for integration and reuse. 

  

  5. _STANDARDS AND METADATA_ : reference to existing suitable standards of the discipline. If these do not exist, an outline on how and what metadata will be created. 

  

  6. _DATA INFRASTRUCTURE_ : details of data production and provision assets. 

  

  7. _DATA SHARING_ : description of how data will be shared, including access procedures, embargo periods (if any), outlines of technical mechanisms for dissemination and necessary software and other tools for enabling re-use, and definition of whether access will be widely open or restricted to specific groups. Identification of the repository where data will be stored, if already existing and identified, indicating in particular the type of repository (institutional, standard repository for the discipline, etc.). In case the dataset cannot be shared, the reasons for this should be mentioned (e.g. ethical, rules of personal data, intellectual property, commercial, privacy-related, security-related). 

  

  8. _ARCHIVING AND PRESERVATION (INCLUDING STORAGE AND BACKUP)_ : description of the procedures that will be put in place for long-term preservation of the data. Indication of how long the data should be preserved, what is its approximated end volume, what the associated costs are and how these are planned to be covered. 

  

  

In addition, any project that produces, collects or processes research data
should also take into account that data used to produce the research results
of the project should be:

  1. _DISCOVERABLE_ : identifiable by means of a standard identification mechanism (e.g. Digital Object Identifier). 

  

  2. _ACCESSIBLE_ : the data and associated software are produced and/or used in the project accessible and in what modalities, scope, licenses (e.g. licensing framework for research and education, embargo periods, commercial exploitation, etc.). 

  

  3. _ASSESSABLE AND INTELLIGIBLE_ : covering the capacity of third parties of accessing and using data with a short learning curve. 

  

  4. _USEABLE BEYOND THE ORIGINAL PURPOSE FOR WHICH IT WAS COLLECTED_ : easing the application of the data in other domains or sectors. 

  

  5. _INTEROPERABLE TO SPECIFIC QUALITY STANDARDS_ : allowing data exchange between researchers, institutions, organisations, countries, etc. (e.g. adhering to standards for data annotation, data exchange, compliant with available software applications, and allowing re-combinations with different datasets from different origins). 

  

  

The following sections of the document are:

  * Section 2 - Data Management Plan: This section describes how each of the aforementioned data management aspects will be tackled in CogNet. During the different updates of this deliverable the details for each identified database will be included. 

  

  * Section 3 - Data Protection Agency Notifications: This section includes the plan to obtain the required certification and notification of the data protection agencies of the member states where research is being carried out. Notifications, when applicable, will acknowledge receipt of notification of the project in the jurisdiction of Data Protection Agencies. During the different updates of this deliverable all the notifications sent and their receipts will be included. 

  

This deliverable is not a fixed document, and it will evolve during the
lifespan of the project to include updates on both data management related
information (e.g. details on datasets), and also updates related to the
notifications to the applicable Data Protection Agencies (including those
outside of Europe: e.g. WeFi data collected in USA). It is expected that at
least one update per year will be needed.

#  Data Management Plan

In section 1 Introduction the different aspects that have to be considered
when managing each and all of the datasets have been described. The following
sub-sections present the details of each of these aspects.

##  Overview of policies

Here the plan includes exploration activities to detect and apply existing
procedures from:

  * Departments from the consortium that have data management guidelines. 

  

  * Groups from outside the consortium that have data management guidelines. 

  

  * Institutions/agencies that establish mandatory data protection and security policy. 

  

  * Mandatory formal standards to improve accessibility and intelligibility for third parties. 

  

The concrete actions here comprise:

  * List any relevant institution on data management, data sharing and data security. 

  

  * Clarify relevance of servers’ location with the data. 

  

##  Roles and responsibilities

###  DMP coordinator

This section appoints the responsible party for data management. The DMP
coordinator, Vicomtech-IK4 (ES), as leader of the Task 1.5 Data Protection and
privacy management, is responsible for implementing the DMP, and ensuring it
is reviewed and revised.

###  DMP participants

As established in the Consortium Agreement (CA) 10.7.1 each party agrees to
comply with all obligations and requirements of its corresponding national
data protection legislation and the Data Protection Directive 95/46/EEC and to
provide all legal documents and certifications strictly required for
compliance with such legislation to the Consortium designated Party for data
protection control.

While in 10.7.2 The Parties agree that any Background, Results, Confidential
Information and/or any and all data and/or information that is provided,
disclosed or otherwise made available between the Parties during the
implementation of the Action and/or for any Exploitation activities (“Shared
Information”), shall not include personal data as defined by Article 2,
Section (a) of the Data Protection Directive (95/46/EEC) (hereinafter referred
to as “Personal Data”). Accordingly each Party agrees that it will take all
necessary steps to ensure that all Personal Data is removed from the Shared
Information, made illegible, or otherwise made inaccessible (i.e. deidentify)
to the other Parties prior to providing the Shared Information to such other
Parties.

Finally, 10.7.3 notwithstanding the preceding paragraph, if Personal Data is
involved and/or needed during the implementation of the Action and/or for any
Exploitation activities, each Party who provides or otherwise make available
to any other Party Shared Information containing Personal Data (“Contributor”)
notifies this disclosure to the Consortium designated Party for data
protection control and represents that: (i) it has the authority and/or the
authorisation to disclose the Shared Information, if any, which it provides to
the Parties under this CA; (ii) where legally required and relevant, it has
obtained appropriate informed consents from all the individuals involved, or
from any other applicable institution, all in compliance with applicable
regulations; and (iii) there is no restriction in place that would prevent any
such other Party from using the Shared Information in accordance with and for
the purpose of the Agreement.

###  DMP processing phases

There are four main types of research data:

  * **Observational data** : captured in real time, typically cannot be reproduced exactly. 

  

  * **Experimental data** : from labs and equipment, can often be reproduced but may be expensive to do so. 

  

  * **Simulation data** : from models, can typically be reproduced if the input data is known. 

  

  * **Derived or compiled data** : after data mining or statistical analysis has been done, can be reproduced if analysis is documented. 

  

The 5G networking data processed in CogNet centres on 3 phases:

  * First, a static non-synthetic dataset ( _**observational** _ ) captured from a real infrastructure, to establish research activities with a static dataset. This dataset will enable Machine Learning algorithms simulations and training; essentially processed by WP2, WP3, WP4 and WP5. 

  

  * Second, a live synthetic ( _**simulation** _ ) / non-synthetic ( _**experimental** _ ) dataset captured in real time from a testbed or lab infrastructure to monitor it and test optimization strategies coming from the Machine Learning algorithms in a controlled infrastructure; essentially processed by WP3, WP4 and WP5. 

  

  * Third, a live non-synthetic dataset ( _**observational** _ ) captured in real time from a telco operator infrastructure to monitor it and apply optimization strategies coming from the Machine Learning algorithms. In this case, data will be the central part of the demonstration and validation in WP6. 

  

For the first phase, CogNet has the intention of buying an anonymized
collection of information from end user devices to network infrastructure
nodes including information about network performance, application engagement
and performance. This dataset for the first phase must satisfy directives for
data protection of personal data.

It has not been declared in the Consortium Agreement (CA) who is responsible
for this first phase dataset, but all the project coordinator (TSSG) will
perform the sourcing/purchase process. The reason, CogNet is not itself a
legal entity such as a foundation or limited liability company. Thus, the
responsibility of this dataset will fall on TSSG.

Regarding the second phase, during the project some experiments using testbeds
or labs will be done and the captured datasets could be interesting to the
research community, in this case the infrastructure owner keeps the data
rights.

For the third phase, the telco operator that provides the monitored
infrastructure owns the data captured from there.

###  DMP collaborative responsibilities

The responsibilities over the data depend on which EU state has jurisdiction
over the ownership and the processing of the data in the CogNet project. This
question is answered by determining who is responsible, i.e. who is
_**'controller'** _ as that term is defined in the Data Protection Directive
(95/46/EEC). This is the entity that "determines the purposes and means of the
processing of personal data".

CogNet is itself not a legal entity such as a foundation or limited liability
company. Thus, the responsibility for data protection will fall on the member
of CogNet who is the ‘ _**controller** _ ’, the entity which collects and owns
the data in question. When data is shared between parties, the recipient is a
_**'processor'** _ and may use the data only as specified by the controller.
Thus, the decisive factor is which entity collected the data. Each of these
parties is responsible for notifying its local data protection authority.

###  DMP responsibilities

The following responsibilities will apply to datasets on a per-dataset basis:

  * data acquisition / capture (raw) o For pre-existing datasets owned by any of the CogNet partners, the partner that owns that dataset and makes it available to the project will be the Data Controller. 

    * For acquisition of new dataset, we will apply what was defined in section 5 of CogNET’s Description of the Action: “ _For the purpose of the project TSSG will be the Data Controller and Robert Mullins the Point of Contact_ ”. 

  

    * For creation or capture of new datasets, the partner(s) that create or capture the dataset will be the Data Controller(s). This applies to all types of research data (observational, experimental, simulation, and derived or compiled data). 

  

  

  * metadata production (derived) - machine learning research participants. 

    * In parallel activities, each participant is responsible for their metadata and an aggregator responsible will be defined according to the volume of metadata aggregated by each individual. This means bigger volume generator establishes aggregation mechanism and format. 

  

    * In case of pipelined processing, each participant is responsible for their metadata and for aggregating it on top of the available metadata. 

  

  

  * data sharing – The Data Controller will determine the details of how data will be shared, including access procedures, embargo periods (if any), outlines of technical mechanisms for dissemination and necessary software and other tools for enabling re-use, and definition of whether access will be widely open or restricted to specific groups. Similarly, the Data Controller will identify the repository where data will be stored, if already existing and identified, indicating in particular the type of repository (institutional, standard repository for the discipline, etc.). Recommendations from OpenAIRE project such as depositing in Zenodo repository data and publications will be the starting point before making any decision on data sharing. 

  

  * Data archiving and preservation (including storage and backup) – depending on each dataset the data archiving and preservation procedures that will be put in place for longterm preservation of the data will be responsibility of the corresponding Data Controller. This includes the indication of how long the data should be preserved, what is its approximated end volume, what the associated costs are and how these are planned to be covered. 

  

##  Data set reference and name

As described in detail in section 2.2.3 the 5G networking data that will be
processed in CogNet pivot around 3 phases: static non-synthetic dataset
(observational), live synthetic (simulation)/non-synthetic(experimental)
dataset, and live non-synthetic dataset (observational).

Both raw captured and metadata processed information will be included in the
dataset. In each phase the dataset will be generated/bought and processed
different datasets targeting the same information but from different
infrastructures. For each dataset the corresponding Data Controller will
assure that the above information is defined:

  * Contact Name - telephone and email contact details 

  

  * Date of First Version - Date the first version was completed 

  

  * Date of Last Update - Date it was last changed 

  

##  Data set description

###  General description

CogNet will harvest 5G networking data with anonymized collections of
information from end user devices to network infrastructure nodes including
information about network performance, application engagement and performance.

A preliminary data category would cover:

  * Device data 

  

  * Connectivity data o Primary connected network - canonical network name (/WLAN/SSID/BSSID or 

  

/3GPP/PLMN/CellLAC/CellID or /3GPP2/SID/NID/BSID) o Specific Network
Technology – connected network interface (Wi-Fi, GPRS, EDGE, HSPA+, LTE, …)

  * Usage data (total and per session) o Rx- amount of data downloaded on the network by a device (in bytes) o Tx –amount of data uploaded on the network by a device (in bytes) o avgRx - average downlink throughput observed on the network by a device (in bps) o avgTx \- average uplink throughput observed on the network by a device (in bps) o maxRx - maximum downlink throughput observed on the network by a device (in bps) o maxTx - maximum uplink throughput observed on the network by a device (in bps) o avgLatencyRx - average downlink latency observed on the network by a device (in bps) o avgLatencyTx - average uplink latency observed on the network by a device (in bps) o maxLatencyRx - maximum downlink latency observed on the network by a device 

  

(in bps) o maxLatencyTx - maximum uplink delay latency on the network by a
device (in bps) o avgJitterRx - average downlink jitter observed on the
network by a device (in bps) o avgJitterTx - average uplink jitter observed on
the network by a device (in bps)

  * KPI indicators related (local-node and global-infrastructure): 

    * Indicators/counters composed for too late HOs, too early HOs, HOs to a wrong cell and HOs subsequent to a connection setup (HO-related) o Number of HOs (incoming+outgoing) o Ping-pong handovers o Handover success rate (HOSR) o Bit error rate (BER) o Block error rate (BLER) o Outage 

  

  

  
<table>  
<tr>  
<th>

**CogNet**

</th>  
<th>

**Version 1.0**

</th>  
<th>

</th>  
<th>

**Page 13 of 33**

</th> </tr> </table>

  * Average throughput o Number of calls K10 Hours and/or data communicated o Call set-up success rate (CSSR) o System/cell load information o Energy expenses o OPEX linked to energy expenses o Access delay o Call setup delay o Handover delay o Block call rate (BCR) o Drop call rate (DCR) o support for ubiquitous communication o support for emergency calls o support for lawful interception o network neutrality o QoS delivery: 

    * capacity 

  

    * delay 

  

    * packet loss 

  

    * guaranteed capacity 

  

    * preemption o Resource consumption 

  

    * energy 

  

    * network capacity 

  

    * compute 

  

    * storage 

  

    * caches o Resource consumption: 

  

    * signalling 

  

    * sub-optimal data paths 

  

    * management overhead (incl. monitoring) 

  

  

  * Contextual data (location, velocity, movement mode, etc.) 

  

  
<table>  
<tr>  
<th>

**CogNet**

</th>  
<th>

**Version 1.0**

</th>  
<th>

</th>  
<th>

</th>  
<th>

**Page 14 of 33**

</th> </tr> </table>

  * Session start time - Date and time of day, milliseconds resolution o Geo-location source used when session started –GPS 

  

Where this information will be organised around:

  * Geo Binned to keep a reference of the network performance with a specific area. A postprocessor will aggregate data and measures for each area cell visited by the devices 

  

  * Session records triggered by connectivity events related to: 

    * connectivity changes in the employed network interface 

  

  

Besides, as we plan to manage data coming from virtual machines we will have
related datasets containing parameters such as:

  * CPU 

  

  * RAM usage 

  

  * Disk usage 

  

  * Network usage 

  

  * User/system load 

  

  * Network traffic categories 

  

  * Incoming VNF traffic 

  

  * Outcoming VNF traffic 

  

  * VNF allocation time 

  

  * VNF instantiation time 

  

  * Number of VNF 

  

  * Types of VNF 

  

###  Format

Different features captured have standard format and units, such as the GPS
position or the speed, or _de facto_ formats such as availability,
utilization, CPU load delay or bandwidth throughput.

Moreover, the general format the probes records networking data will have an
analytical structure influenced and partially inherited from the data
collection acquired for the first phase. Hence, despite the high density of
nodes and the decentralised nature of the assets we will create a common and
homogeneous data format coming from heterogeneous infrastructures and systems.

###  Accuracy and Volume

Our aim is to apply real-time policies 5G networks can be dynamically adapt to
next generation challenges. This way, live monitoring and real time decision-
making would just involve stateless data. However, the nature of the use cases
and scenarios that require Machine Learning algorithms to detect the trends
and patterns require a time window of data that spans last 24 hours in order
to include the different human behaviours during a daily life cycle.

So the different factors that come into the data volume equation are:

  * the number of nodes and end devices 

  

  * the time window (historical values) 

  

  * the sampling frequency 

  

  * the number of features captured 

  

  * the metadata created for each asset 

  

Because the input data has a short historical memory, machine learning is
required to achieve real time performance and the effect of the decisions
taken must be ready immediately (<1 second - <1 minute, depending on the SLA
and the change dimension), the dataset provided covers 24 hours.

###  Origin

As described in detail in section 2.2.3 the 5G networking data that will be
processed in CogNet pivot around 3 phases: static non-synthetic dataset
(observational), live synthetic (simulation)/non-synthetic(experimental)
dataset, and live non-synthetic dataset (observational).

For the first phase, CogNet has the intention of buying an anonymized
collection of information gathered from end user devices including information
about network performance, application engagement, end user demand and usage
patterns and performance. These datasets can come from:

  * telco operators partners belonging the consortium 

  

  * companies specialized in big data platform to enable network operators to optimize resources using the largest sample database of its kind 

  

  * other projects or communities that share and provide networking datasets 

  

For the second phase, CogNet partners will collect their own datasets from
their controlled testing and experimental environments.

For the final phase, the datasets will come from telco operators that
participate in the CogNet consortium.

When dealing with new or non-anonymised data, CogNet will follow the best
practices and recommendations made by the Article 29 Data Protection Working
Party in their Opinion 05/2014 on Anonymisation Techniques  1  to
appropriately anonymise the data.  
  
<table>  
<tr>  
<th>

**CogNet**

</th>  
<th>

</th>  
<th>

**Version 1.0**

</th>  
<th>

</th>  
<th>

</th>  
<th>

**Page 16 of 33**

</th> </tr> </table>

##  Standards and metadata

Network monitoring is an important function in network management because it
helps achieve three goals in network management: performance monitoring, fault
monitoring, and account monitoring.

###  Standards

Concerning the standards to be considered, the list to be taken into account
for the formal dataset structure, nomenclature and taxonomy is:

  * RFC 2819  2  , 4502  3  Remote Network Monitoring Management Information Base 

  

  * SMIv2  4  is the naming structure used for naming monitored objects. 

  

  * MIB-II  5  defines how the set of objects monitored can be defined. The attributes of these objects should have network monitoring values. 

  

  * NETCONF  6  is a network management protocol developed and standardized by the IETF  7  . It provides mechanisms to install, manipulate, and delete the configuration of network devices. 

  

  * YANG  8  is a data modelling language for the NETCONF network configuration protocol that was developed by the NETMOD working group in the IETF. 

  

  * IF-MAP  9  is an open standard that makes it possible for any authorized device or system to publish information to an IF-MAP server, to search that server for relevant information, and to subscribe to any updates to that information. 

  

  * SNMP/SNMPv2  10  internet standardized protocol on network management. It is used extensively for network monitoring functions such as collection errors and user statistics. SNMPv2 provides the information exchange and backbone for network monitoring. 

  

  * RMON/RMON2  11  is the standard of how to monitor internet traffic. This is a standard that is supposedly implemented by internet device vendors so that a network using RMONcompliant devices can be monitored using RMON-compliant software. RMON standard provides remote monitoring. Basically, RMON-compliant devices are created to check the status of the network. 

  

  * SMON provides network monitoring to switched networks. 

  

  * ATM-RMON is designed for ATM networks. This is a new standard based on RMON-like features. 

  

So the data collection will be done according to standardised data
capture/recording process. The captured data will be collected employing
generic networking probes already available at the network nodes or NFV assets
and other specifically developed and deployed over the end-user devices.

###  Versioning

Concerning the dataset versioning, folders structure and filenames, to help
people to find the data, the title/reference will include who created or
contributed to the data, date of creation and under what conditions it can be
accessed. Thus, each instance recording a network monitoring session would
have this naming convention:

  * infrastructure identifier (telco operator or lab) 

  

  * machine learning algorithms and version applied (highlighting that the dataset is being influenced by some deployed CogNet policies) 

  

  * date and time 

  

  * _[main service(s)]_ when possible including the stimulus to the network, main service(s) processed and delivered by the network and accessed by the users 

  

###  Structure

According to the previous standards, and the structure for data aggregation
that they establish, individual metadata will be aggregated. In the case of
the metadata generation and the link to the base values, CogNet
Standardization leader T7.3 (TID) will lead and coordinate the work within the
consortium to define a format to do it.

Concerning the methodology to do it, Network Management System (NMS)
activities focuses on two alternatives:

  * the management network and the production network may either be separated physically (out-band management segment) or 

  

  * the management network and the production network may share the same physical infrastructure (the VLAN segment of the network). 

  

This aspect is still under discussion and will be decided in the WP2
Architecture deliverable (D22).

NMS should include three components:

  * configuration management 

  

  * log management 

  

  * network monitoring 

  

  
<table>  
<tr>  
<th>

**CogNet**

</th>  
<th>

</th>  
<th>

</th>  
<th>

</th>  
<th>

**Version 1.0**

</th>  
<th>

**Page 18 of 33**

</th> </tr> </table>

This is because the decisions taken from the monitored network data effect the
network behaviour and hence, the dataset from this moment. The dataset will be
accompanied by a timed log bookmarking the decisions taken. Thus, the
documentation that will accompany the data helps secondary users to understand
and reuse it.

To control the consistency and quality of data collection, 2 consecutive
samples (24 hours each) will be taken under similar social dimension
conditions (working days, starting at the same time). Because the network
conditions can be very changeable with highly dynamic behaviour and we want to
keep these singularities no processes such as calibration, data entry
validation, peer review of data or representation will be done.

Concerning analytical and procedural information management, a preliminary
process performed by the Machine Learning ‘ _**processor’** _ will remove
repeat samples or measurements.

###  Vocabulary

The variables, vocabularies, units of measurement are being defined in the WP2
activities around the definition of Use Cases and scenarios (D21). At this
moment, the parameters considered are led by typical telecom KPIs.

##  Data infrastructure

For the Network monitoring ( _**'controller'** _ ), including the probes to
get networking values such as errors and user statistics, there are two
alternatives:

  * the management network and the production network may either be separated physically (out-band management segment) or 

  

  * they may share the same physical infrastructure (the VLAN segment of the network). 

  

This aspect is still under discussion and it will be decided in the WP2
Architecture deliverable (D22).

Moreover, the Network Manager (‘ _**processor’** _ ) needs infrastructure to
manage and process the data volume that comes from the Machine Learning
algorithms (e.g. performance degeneration detection or traffic
prioritization). The specific platform is still under discussion and it will
be decided in the WP2 Architecture deliverable (D22). Its implications on the
DMP will be analysed then.

##  Data sharing

Here most of the aspects related to copyright and Intellectual Property Rights
(IPR) issues have been established in the 5G infrastructure Collaboration
Agreement between each beneficiary with the EC in respect of a particular 5G
Action and the Consortium Agreement.

###  Ownership

The CA does not establish ownership for each data collection but how it is to
be split across partner sites in collaborative research activities.

Here, the DMP states who will own the copyright and IPR of any data that
CogNet will collect or create. Considering the dataset as the monitored values
plus the metadata and produced logs. For each dataset the ownership will be
shared:

  * data captured - telco operator or lab provider not only provide infrastructure but the probes or the setup to deploy them 

  

  * metadata production - machine learning research participants o In parallel activities, each participant owns the metadata generated o In case of pipelined processing, each participant owns the metadata generated 

  

###  Licensing

Regarding the licensing for reuse or any restrictions on the reuse of third-
party data we have to keep in mind (as it is described in detail in section
2.2.3) that the 5G networking data that will be processed in CogNet pivots
around 3 phases: static non-synthetic dataset (observational), live synthetic
(simulation)/non-synthetic (experimental) dataset, and live non-synthetic
dataset (observational).For the first phase, CogNet has the intention of
buying an anonymous collection of information from end user devices to network
infrastructure nodes including information about network performance,
application engagement and performance. So this data collection cannot be
shared.

Considering permissions to reuse third-party data and any restrictions needed
on data sharing, the datasets generated in the second and the final stage the
will be in an Open Access basis (for non-commercial research/educational use
only) from the project’s end.

###  Ethics

The first aspect to consider is the management of any ethical issues. This
responsibility falls on the CogNet 'controller' who have to:

  * gain formal consent for data preservation, sharing and reuse. 

  

  * protect the identity of participants via anonymisation. 

  

  * assure data is stored, transferred and handled securely. 

  

The DMP coordinator, Vicomtech-IK4 (ES) will monitor that guidelines and
recommendations collected in the DMP have been translated to project
development.

###  Accessibility

The retention period of all data and information collected, stored and
processed for the dataset will be for 5-years following the end of the
project. During this period, unless otherwise decided by the consortium
members, the database functionality will remain the same as during the project
duration.

The dataset will be accessible through the CogNet portal and if no other
decision has been made with respect to the database by the consortium members,
the datasets will be attached to the CogNet wiki for open-access.

A record will track entities reusing the CogNet dataset by means of a data
sharing agreement. These third parties will not have rights for re-
distribution or of publishing the dataset partially or totally requiring the
reference to the dataset in any publication or derived product. Any potential
users that want to get access to the data will be under the DMP conditions
respecting the sensitivity of data. Here, a nondisclosure agreement would give
sufficient protection for confidential data.

Any potential user that wants the get access would be guided to:

  1. submit a "request" to the dataset _**controller** _ from the CogNet consortium (TSSG). This request will contain: 

     * full name 

  

     * organization and department 

  

     * email address 

  

     * description of intended use 

  

  

  2. After reviewing the request. If the _**controller** _ approves it, the user will receive an email with a special link to verify the email address. 

  

  3. Then the user is asked to agree to and sign the following terms of access: [RESEARCHER_FULLNAME] (the "Researcher") has requested permission to use the 5G networking dataset (the "Dataset"). In exchange for such permission, Researcher hereby agrees to the following terms and conditions: 

    1. Researcher shall use the Database only for non-commercial research and educational purposes. 

  

    2. _**Controller** _ makes no representations or warranties regarding the Dataset, including but not limited to warranties of non-infringement or fitness for a particular purpose. 

  

    3. Researcher accepts full responsibility for his or her use of the Dataset and shall defend and indemnify _**controller** _ , including their employees, Trustees, officers and agents, against any and all claims arising from Researcher's use of the Dataset, including but not limited to Researcher's use of any copies of copyrighted dataset that he or she may create from the Dataset. 

  

    4. Researcher may provide research associates and colleagues with access to the Dataset provided that they first agree to be bound by these terms and conditions. 

  

    5. _**Controller** _ reserves the right to terminate Researcher's access to the Database at any time. 

  

    6. If Researcher is employed by a for-profit, commercial entity, Researcher's employer shall also be bound by these terms and conditions, and Researcher hereby represents that he or she is fully authorized to enter into this agreement on behalf of such employer. 

  

    7. The law of the _**Controller’s** _ country shall apply to all disputes under this agreement. 

  
  

  

  

##  Archiving and preservation

###  Availability

The database will be accessible through the CogNet portal for five years
following the end of the project. During this period, unless otherwise decided
by the consortium members, the database functionality will remain the same as
during the project duration.

In this 5-year period and if no other decision has been made with respect to
the database by the consortium members, the datasets will be attached to the
CogNet wiki for open-access.

Once the dataset becomes public after the project end, the consortium will
publish the dataset in a chosen third-party service, ensuring that this does
not conflict with any legal jurisdiction in which data are held or the
protection of sensitive data.

###  Security

Because data managed is not confidential and not related to personal data or
trade secrets and it will be anonymized the risks to data security are minimum
but still managed according to ISO 27001. The following security requirements
have been identified and are presented:

  * _Access Control (Authorization)_ . CogNet dataset repository must be capable of controlling the level of access that each user has depending on their role. There must be appropriate mechanisms to define and enforce such access control (e.g. firewalls, file systems permissions, secure log-in) including physical control. _This is provided by the IT department of the dataset maintainer or by the dataset repository technology itself_ . 

  

  * _Authentication_ . It must guarantee that the system being accessed is the intended one and that the user is who claims to be. _During the project, the partners will have access using a private password. Once the datasets become public an e-mail based mechanism will grant access_ . 

  

  * _Non-Repudiation_ . To ensure the capability to prevent users from denying that data files were accessed, altered or deleted, auditing processes must be implemented. _This is provided by the IT department of the dataset maintainer or by the dataset repository technology itself_ . 

  

  * _Data Confidentiality_ . Within the scope of the project, the protection of information from unauthorized access and disclosure must be preserved by restricting per-user access and encrypting the information during transmission and also during storage. After the defined retention period expires, ensure information erasure/destruction. _This is provided by the IT department of the dataset maintainer or by the dataset repository technology itself_ . 

  

  * _Communication Security_ . Communication only flows through encrypted communication channels. _This is provided by the IT department of the dataset maintainer or by the dataset repository technology itself_ . 

  

  * _Data Integrity_ . CogNet must protect data from unauthorized, uncontrolled, or accidental alteration during storage or transmission with the use of checksum values, hash functions and digital signatures. _This is provided by the IT department of the dataset maintainer or by the dataset repository technology itself_ . 

  

  * _Availability_ . Back-up mechanisms are a desirable property, mainly to avoid Denial of Service (DoS) attacks. _This is provided by the IT department of the dataset maintainer or by the dataset repository technology itself_ . 

  

##  Discoverable

By means of the project portal the datasets can be discovered. Moreover, the
project publications and dissemination activities done in WP7 will bring
visibility of the results and datasets coming from CogNet to the academia and
research communities.

##  Accessible

The datasets will be accessible through a FTP server to be downloaded
following the accessing mechanism described before.

##  Assessable and intelligible

Thanks to the use of standards and a proper and documented metadata annotation
the datasets will ensure a usable dataset in a short time. The activities done
in WP7 will target this aspect.

##  Useable

CogNet aims solutions for a higher and more intelligent level of automated
monitoring and management of networks and applications improve operational
efficiencies and facilitate the requirements of 5G. The same way CogNet will
employ the datasets to find underlying connections to detect trends, patterns
and symptoms towards a specific diagnostic enabling automatic decision making
to deploy preventive or corrective policies, this data that reflects human
activities could be used in other domains or sectors such as smart cities,
traffic road planning, energy production, etc.

##  Interoperable

Because there is not a standard for storing this kind of information the
interoperability to allowing data exchange between researchers, institutions,
organisations, countries, etc. and the re-combination with different datasets
from different origins is very difficult. It always needs of a human
interpretation of the data structure to manually create a data map. However,
the utilization of standards for data capturing and the documented annotation
will ease the data exchange. This aspect will be reviewed in WP7 (D731, D732).

#  Data Protection Agency Notifications

According to applicable data protection law it may be necessary to notify data
protection authorities in the jurisdiction where RTD activities will be
carried. At the initial stage of the CogNet project the exact requirements and
due diligence have been scoped and defined within the jurisdictions where the
research will take place.

The conclusions of the review of the applicable data protection law in the
jurisdiction where RTD activities will be carried out in CogNet are that it
will be necessary to notify the applicable Data Protection Agencies (DPA) of
Ireland, Spain, and Italy, whereas in the case of Germany and Israel we
understand that the law does not require these notifications. The notification
procedures that have been followed are described in Article 29 Working Group
document “Vadmecum on Notification Requirements”  12  .

The rest of this section presents the conclusions of the review of the
applicable data protection law in the jurisdiction where RTD activities will
be carried out in CogNet.

As stated in Section 5 of the project proposal, the notification requirements
vary from one country to another and therefore no single timeline can be
provided for completion of all notification procedures.

In addition to the initial notifications, before testing phases of the CogNet
project, the respective national DPAs of the participant countries where the
field-trials, demonstrations, and feasibility experimentations will take place
will be notified of the projects testing phases and more specifically on the
personal data of the voluntary participants that will be utilized.

##  Spanish Data Protection Agency Notification: ES

This section includes the formal acknowledgement of receipt of notification of
the CogNet project in the jurisdiction of the DMP coordinator, i.e. the
document received from the Spanish Data Protection Agency on behalf of the
agency’s Director that confirms the registration of the CogNet file.

The Spanish Data Protection Agency (AEPD in the Spanish acronym) is the public
law authority overseeing compliance with the legal provisions on the
protection of personal data. In order to guarantee effective compliance with
the Organic Act on Data Protection (LOPD), which is the basis of the system to
ensure the right to protect personal data, the adequate involvement of all
agents is essential.

The AEPD is of the understanding that its functions must always be conducted
with the priority objective of guaranteeing the protection of individual
rights. Accordingly, actions are taken specifically aimed at enhancing
citizens’ capacity to effectively contribute to data protection.

Some of the outstanding activities performed by the Spanish Data Protection
Agency are the dissemination of activities and of the right to protection of
personal data, direct assistance in response to citizens’ queries, and
procedures to protect rights of individuals.

One of the most important instruments for better protecting the rights of
citizens is the registry of filing systems. The evolution of the data on the
filing systems registered at the Data Protection General Registry (RGPD) is
considered a significant reference regarding compliance with the Data
Protection Laws.

The AEPD encourages the adoption of rules that are meant to complete the legal
framework for data protection, and it also contributes to ensuring that the
right to data protection is treated correctly in the legal provisions adopted
with purposes that have no specific relation to data protection.

Many of the important topics affecting data protection are of an international
scope and certain concerns, such as security, reach well beyond national
boundaries. Therefore, this important international dimension is present in
all of the activities of the AEPD, which has been and continues to be involved
in a number of international forums.

###  Agency Notification: ES

The CogNet information has being registered as a Privately Owned File (Fichero
de Titularidad Privada), by introducing the required information in the
Spanish Data Protection General Registry. As specified in Article 14 of the
Organic Act on Data Protection, the right to consult the Registry enables any
person to become acquainted of the existence of treatments of personal data,
its purpose and the identity of the data controller.

Notifications to the AEPD can be done in the following  _link_ .

**Figure 1 - Notification sent to the Spanish DPA**

The information contained in the CogNet file registered in the Spanish Data
Protection Agency has also being included in Vicomtech-IK4’s Security Document
in compliance with the Organic Act on Data Protection. The information
notified to the Agency regarding personal data protection of the project is
structured as explained below.

###  Private Ownership File: Detailed Information: ES

**Figure 2 - Details of the notification sent to the Spanish DPA**

##  Notification Processes: IE, IT, DE, ISR

Besides the aforementioned notification to the Spanish Data Protection Agency,
the required certification and approval of the data protection agencies of the
remaining participating states (i.e. Ireland, Italy, Germany and Israel) where
research has been carried out are presented in this section.

###  Notification to the Data Protection Commissioner: IE

This section includes the formal notification regarding the CogNet project to
the Irish Data Protection Authority, the office of the Data Protection
Commissioner which was established under the 1988 Data Protection Act. The
Data Protection Amendment Act, 2003, updated the legislation, implementing the
provisions of EU Directive 95/46. The Acts set out the general principle that
individuals should be in a position to control how data relating to them is
used.

Registration with the Data Protection Commissioner can be done in the
following  _link_ .

The notification to the Data Protection Commissioner has not been completed at
the time of writing this first version of this deliverable. In the next update
of this document the notification receipt will be included here.

###  Notification to the Garante per la protezione dei dati personali: IT

This section includes the formal notification regarding the CogNet project to
the Italian Data Protection Authority (Garante per la protezione dei dati
personali), an independent authority established to protect the fundamental
rights related to the processing of personal data, and to ensure respect for
individuals' dignity.

Notifications to the Garante per la protezione dei dati personali can be done
in the following  _link_ .

The notification to the Garante per la protezione dei dati personali has not
been completed at the time of writing this first version of this deliverable.
In the next update of this document the notification receipt will be included
here.

###  Notification to the Der Bundesbeauftragte für den Datenschutz und die
Informationsfreiheit: DE

The main legal source of data protection in Germany is the
(Bundesdatenschutzgesetz) (BDSG), which implements Directive 95/46/EC on data
protection. Additionally, each German state has a data protection law of its
own. There are sectoral laws, including the Telecommunication Act
(Telekommunikationsgesetz), which applies to providers of telecommunication
services. The German Act Against Unfair Competition (Gesetz gegen den
unlauteren Wettbewerb) (the “UCA”) dated 3 July 2004 and the revised German
Telecommunications Act (Telekommunikationsgesetz) (the “TA”) dated 22 June
2004 (with the TA being applicable only to telecommunications service
providers in addition to the UCA) both implemented Article 13 of the Privacy
and Electronic Communications Directive. Further, the TMA may be amended to
implement the Citizens’ Rights Directive as regards the storage of cookies.
Note that German data protection law does not apply if a controller located in
another country of the European Economic Area (EEA) collects, processes or
uses personal data within Germany.

The collection, processing and use of personal data is only admissible if
expressly permitted by the BDSG or any other legal provision, or if the data
subject has expressly consented in advance.

The Federal Republic of Germany is a federation of 16 states which are not
just provinces but states with their own original sovereign rights and
legislative responsibilities. The supreme power of the State is divided
between the federal and the state governments. The federal system of
government also affects the supervision of data protection.

In Germany there are 20 different federal and regional supervisory authorities
responsible for monitoring the implementation of data protection. Data
protection supervision in the private sector comes under the responsibility of
the states. However, there is one exception: the telecommunications and postal
services companies. Those firms are monitored by the federal government which
has assigned that task to the Federal Data Protection Commissioner (Der
Bundesbeauftragte für den Datenschutz und die Informationsfreiheit).

According to Art 4 d and 4 e of FDPA Data Controllers have to notify if they
engage in data storing and processing for the purpose of transferring data for
business reasons; all others are exempted. According to the aforementioned Act
(FDPA) all automated processing procedures have to be registered with the
competent supervisory authority. However, this rule is not applied if the
entity has appointed a data protection official (“privacy officer” under
Directive 95/46/EC).

Therefore, according to our interpretation of the German law  13  , CogNet
does not need to be registered or notified, provided a Data Protection
Official is appointed by the controller, which is the case, as Fraunhofer
Gesellschaft has been appointed CogNet Data Protection Official in Germany.
Therefore, the Data Protection Official at Fraunhofer Gesellschaft has been
duly informed by the controller and keeps the information as set out by the
law. For the CogNet project, an information note has been submitted to the
Data Protection Official at Fraunhofer Gesellschaft to comply with the
registration requirements set out in article 4e of the German Federal Data
Protection Act. As required, the Data Protection Official at Fraunhofer
Gesellschaft was informed of the elements as required under German
legislation, including the name of the controller, the name of the persons
responsible for the data processing, the persons authorised to access the data
and the purposes. Shall it be needed, a consent form will be prepared for
volunteers giving them duly information of their rights and a clear overview
of what data will be processed for what purposes during the field-trials,
demonstrations, and feasibility experimentations of the project.

###  Notification to the Israeli Law Information and Technology Agency
(ILITA): ISR

EU Commission published on January 31, 2011, an announcement on the adequacy
of data protection law in Israel  14  . The Article 29 Working Party’s
favourable opinion on the level of adequacy under Israeli law  15  ,
contributed to the adoption of the decision, as well.

Article 1 of the aforementioned Commission Decision says:

  1. _For the purposes of Article 25(2) of Directive 95/46/EC, the State of Israel is considered as providing an adequate level of protection for personal data transferred from the European Union in relation to automated international transfers of personal data from the European Union or, where they are not automated, they are subject to further automated processing in the State of Israel._

  

  2. _The competent supervisory authority of the State of Israel for the application of the legal data protection standards in the State of Israel is the ‘Israeli Law, Information and Technology Authority (ILITA)’, referred to in the Annex to this Decision._

  

  

The decision set out a variety of findings that served as grounds for
declaring data protection in Israel to be in conformity with EU standards. The
Commission favourably mentions the semiconstitutional status of the right to
privacy under the Human Dignity and Liberty basic law; the similarity in
standards between the EU Data Protection Directive and Israel’s Privacy
Protection Act; the existence of data protection provisions in legislation
related to the financial, health and public sectors; the availability of
administrative and judicial remedies; and the independence of the country’s
data protection authority – the Israeli Law Information and Technology Agency

(ILITA)  16  .

Privacy is a constitutional right under Article 7 of Basic Law: Human Dignity
and Liberty. In addition, the Privacy Protection Act, 5741-1981 (“PPA”),
contains specific privacy legislation. Chapter B of the PPA deals with data
protection. The PPA entered into force in 1981. The Privacy Law requires that
the owner of a database register a database with ILITA if:

  * The database contains information on more than 10,000 people; 

  

  * The database contains sensitive information on any number of people; 

  

  * The database includes information on persons, and the information was not delivered to this database by them, on their behalf or with their consent; 

  

  * The database belongs to a public body; or 

  

  * The database is used for direct mail services. 

  

The registration system is based on registration of databases, as opposed to
data controllers. Hence, if a data controller has several databases, such as
human resources, customer data, and suppliers, it must register each database
separately. In 2014, ILITA amended the database registration procedures,
requiring the filing of a far more detailed application form than before,
specifying, amongst other things, the methods and sources of data collection
and the types of data in a database.

The term “database” refers to a collection of data processed by computer but
excludes information consisting solely of basic contact details if such
details are not in themselves likely to infringe an individual’s privacy.

The PPA restricts data transfers to third parties, including corporate
affiliates, within or outside of Israel. An additional layer of regulation
applies to international data transfers under the Privacy Protection
Regulations (Transfer of Data to Databases Outside of Israel), 2001 (the
“Transfer Regulations”). The Transfer Regulations apply to both inter- and
intra-entity transfers of personal data outside of Israel. They permit
transfers to: (i) EU Member States; (ii) other signatories of Council of
Europe Convention 108; and (iii) a country “which receives data from Member
States of the European Community, under the same terms of acceptance”.

Therefore, according to our interpretation of the Israeli PPA, at this initial
stage of the CogNet project it is not foreseen the need to obtain
authorisation from the Database Registrar.

#  Conclusions

This document has provided guidelines that will deliver simple and practical
help during the implementation and validation stages of the CogNet platform,
support compliance on underlying legal framework and promote the adoption of
best data management practices.

The DMP establishes a set of guidelines meeting each of the fundamental topics
to be considered. These guidelines cover aspects such as applicable policies,
roles, standards, infrastructures, sharing strategies, data processing,
storage, retention and structure, legal compliance and compliance with market
standards and best ethical and privacy practices, identification,
accessibility, intelligibility, legitimate use for other purposes. These
guidelines will be adopted at the early stages of the project.

At the time this first version of the DMP was written, the datasets to be
utilized by the platform have not been fully defined and therefore their
description and the exact procedures to be adopted have not been discussed
extensively.

Moreover, to satisfy all the regulations, all applicable Data Protection
Agencies (DPA) of the countries of the partners belonging to the CogNet
project have been or are in the process of being notified (Ireland, Spain, and
Italy), The DPA in Germany has not been notified as, in accordance to the
Germany law, a Data Protection Official (Fraunhofer Gesellschaft) has been
appointed by the controller. With regard to Israel, no database has been
registered to the Data Protection Agency in Israel at this stage of the CogNet
project we do not foresee any dataset in Israel to have information on more
than 10,000 people, to contain sensitive information on any number of people,
to include information on persons, and the information was not delivered to
this database by them, on their behalf or with their consent, to belong to a
public body, or to be used for direct mail services.