# DMP of project "Mobility and contact traces from non-intrusive passive measurements" (ANR Mitik)

Aline Carneiro Viana, Nadjib Achir

► To cite this version:

Aline Carneiro Viana, Nadjib Achir. DMP of project "Mobility and contact traces from non-intrusive passive measurements" (ANR Mitik). Inria Saclay - Île de France. 2020, pp.6. hal-04928205

HAL Id: hal-04928205

https://hal.science/hal-04928205v1

Submitted on 4 Feb 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
AGENCE NATIONALE DE LA RECHERCHE (ANR)
DATA MANAGEMENT PLAN

Project full title: Mobility and contact traces from non-intrusive passive measurements

Authors: Aline Carneiro Viana (Inria); Nadjib Achir (Inria/Université Sorbonne Paris Nord)

The Mitik project is funded by the ANR PRC (CE25) for 42 months (selected in the call of 2019). Its scientific starting date is 1st February 2020. It is coordinated by Aline Carneiro Viana, who is a permanent researcher at Inria Saclay and head of the TRIBE research team. The project counts with 2 others academic partners (Sorbonne Université and Université de La Rochelle) and another Inria team (COMETE team).

Mitik's primary objective is the design of an entirely new methodology to help the community obtain real wireless contact traces that are non-intrusive, representative, and independent of third parties. The secondary outcome of the project is be the public release of (1) the measurement tool designed for the easy contact gathering task; (2) contact traces which are clean, processed, and privacy-preserving, i.e., protecting both the anonymity and the location privacy of the users; and (3) their spatiotemporal statistical analysis. At last but not least, we plan to confront the new insights resulted from our analysis with established observations found in the literature, which may invite the research community to revisit opportunistic mobility modeling. We expect that Mitik's outcomes will support non-biased research on the modeling as well as on the leveraging of wireless contact patterns.

The partners will pay special attention to the personal data protection and will be supported by Inria's Data protection officer and ethical committee (COERLE) in order to assure GDPR compliance. Besides, the project will adhere to Inria's policy of open access, and in particular, any publication related to Mitik will be published in the HAL repository (the French public archive for scientific papers).

# 1. DATA DESCRIPTION AND COLLECTION OR RE-USE OF EXISTING DATA

## 1a. How will new data be collected or produced and/or how will existing data be re-used?

The Mitik project proposes to rely on non-intrusive passive measurements to infer nodes' mobility and potential interactions while on the move. The idea is to leverage the fact that mobile devices are likely to transmit Bluetooth and Wi-Fi packets even when users do not explicitly manipulate their devices. In this case, we will need to capture new data within the context of Mitik. For this, Mitik's measurement strategy relies on the physical deployment of passive sniffers over a geographical area. This will require answering the following questions: how many, where, and what type of sniffers have to be deployed. Such questions reveal the need for protocol and hardware specification as well as for optimized placement strategies. Those require taking into consideration factors such as the size of the monitored area, the type of traffic to be measured, and the measurement capabilities of sniffers.

The collection site identified by the partners may cover up to two districts of La Rochelle (downtown district and Minimes district) or less. The perimeter will depend on the means in terms of sniffers and the means that the city wants to give.

These districts were chosen because they represent heterogeneous environments (permanent local mobility, secondary home mobility, and tourist mobility). The local authorities of the city of La Rochelle (in particular the direction for the digital transformation of the agglomeration community and of the city) are interested in this study for better urban and transportation planning in the city. The co-sponsor of the University of La Rochelle in MITIK will act as the interface between the project partners and the town hall and provide information relating to the terms agreed with this local authority.

Prior to the on-site collection phase, there will be a sniffer test phase within each partner. Information about this test will be provided to the population concerned at each of the sites.

## New data capture

The global architecture that will serve as the Mitik project's substrate will combine state-of-the-art approaches with innovative solutions that will consider both user protection and scenario-dependent characteristics from the earliest design steps. Concerning the sniffers hardware we intend to use, the best candidates are Raspberry PIs with at least three Wi-Fi dongles (on different channels) and one Bluetooth dongle – the goal is to improve the possibilities of capturing as many packets as possible. Regarding the software part, we have opted for widely answered software that has proven its robustness and stability, such as OpenSSL, tcpdump, and even the OS, Raspberry Pi OS, and it's base Debian. The main reason is to avoid that the software could crash because of RAM overflow due to bad tool combinations. Our early tests conclude that the combination of these software provides stability for both the system and the required amount of memory resources and CPU. Finally, Sniffers must embed a software stack to gather,
handle, and process data and put it in the right format to be further processed. The design of such software stack as well as its release is one of the objectives of Mitik.

## Use of existing datasets

In the Mitik project, we are not intended to use existing datasets. This is all only because this type of data is not yet available. In fact, the limited availability of adequate publicly available spatiotemporal real contact traces for academic researchers has been a significant obstacle to achieve a richer understanding of issues related to opportunistic communications. The literature on empirical opportunistic networking still provides limited understanding for multiple reasons, including the fact that datasets lack contact precision in space and time, are based on a highly biased inference lacking environmental specificities, or require access to the network infrastructure. *The Mitik project will, therefore, be the first project to provide this data to the community.*

## Constraints on data use

The spatiotemporal aspects of distributed passive measurement make the handling and merging of traces collected by each sniffer a challenging task. This requires advanced approaches for error handling, filtering, and synchronization, packet parsing, as well as merging of traces coming from different sniffers. Furthermore, all of the data used within Mitik can be considered as personal data. In this case, we particularly turn our attention to follow the GDPR directives by using data sanitization rules, i.e., it should not be possible to retrieve the identity of the users from the traces we make available. In this regard, we will anonymize users' identifiers as well as apply controlled noise to any users' location. This should be done while minimizing the impact on the utility of the Mitik outcomes.

The primary objective is to prevent the re-identification of the individual who has generated a given trace. To this purpose, the first level of sanitization will take place at the moment in which a sniffer detects and registers some wireless activity: any information correlated to the identity of the source has to be removed, and the identity replaced by a pseudonym (to maintain the link with the rest of the data collected by other sniffers in the same geographical area). As shown in the literature, pseudo-anonymization, however, is not enough. Hence, we will also employ an obfuscation mechanism where sniffers' collected traces will be merged. Of course, the challenge is to obfuscate data enough to protect the users' privacy while ensuring that the impact on utility is as limited as possible. As much as legally possible, we plan to make the newly captured data available for research purposes, as this type of data is of vital interest since such data does not exist yet.

1b. What data (for example the kind, formats, and volumes), will be collected or produced?

**We do not store sensitive data.** The only thing we collect is the MAC address (of WiFi and Bluetooth wireless interfaces) of devices, which will be replaced by pseudonyms on the sniffers (i.e., before to be sent to secure storage servers behind the firewall of each Mitik's partner) and will be deleted. Since the collecting zones will be of high traffic, the collected information will not be sensible, since there will be no way to retrieve personal information that could lead to a re-identification of the subjects.

In detail, we will collect MAC address, timestamp and sniffer zone and eventually sequential number of the packet. From this collected data, the MAC addresses will be used to generate the pseudonyms (hash) erased immediately afterwards. This corresponds to spatiotemporal data. It is hard to estimate the volume of data collected since this depends on:

(i) the number of users passing by the coverage range of a sniffers;

(ii) the mobility behavior of users -- i.e., users who remains stationary on a sniffer communication range for a long period of time will send more announcement packets, generating thus, a high volume of data (the standard determines a regular time interval for announcements); and

(iii) the type of application using the radio interface of a device -- e.g., if the user is listening music and using her device Bluetooth to connect to her headphone, a large number of packets (from 260 to 320 packets/sec.) could be passively measured by the sniffer; if the user is connecting her device to a smartwatch, the number of packets is expected to be much smaller. The same remark stands for WiFi.

The data format will be text, which is very often used by shared mobility data withing the research community.

Similarly, the size of packets is related to the application and the used wireless technology. In the case of WiFi technology, the maximum frame size is equal to 2312 bytes, while for Bluetooth is about 260 bytes.

The second type of data will be the measurement tool, described hereafter, implemented in C/C++ and Python.
## 2. DOCUMENTATION AND DATA QUALITY

2a. What metadata and documentation (for example the methodology of data collection and way of organising data) will accompany the data?

Mitik will release two types of data with immediate scientific impact. All data release will be followed by a detailed documentation file:

* The first type of data is a **measurement tool** designed for the easy gathering of wireless interactions of individuals. Sniffers must embed a software stack to gather data and put it in the right format to be further processed. We will firstly design and implement all the necessary tools to turn raw packets sniffed at the MAC layer into pre-processed files. Such methodology will be designed to help the community gather real wireless encounters through passive measurements of link-level activities of wireless devices. Second, aided by the strong expertise of the consortium in real experimental campaigns, privacy, and network data analytics, we will make the measurement software as modular as possible so that interested community members have little and straightforward manipulation to perform when conducting their measurement campaigns.

* The second type of data corresponds to the public release of clean, processed, and privacy-preserved **contact traces**, which is dependent on the data collected by different sniffers and the trajectory reconstruction of individuals in the monitored geographical area. Mitik will collect real-world mobility datasets. The partners will pay particular attention to the personal data protection and will be supported by Inria's Data protection officer and ethical committee (COERLE) to assure GDPR compliance. Start of Mitik is conditional to COERLE's agreement. In this context, we have already got the COERLE's agreement, which also states the collected and released data are conform with the GDPR.

* The third type of data is the **analysis code**, i.e., the performed statistical analysis and characterization of the contact patterns. We will rely on open-source software (mostly python-based libraries likes pandas, numpy or matplotlib). We plan to confront such analyses with established observations found in the literature, in particular with the ones related to opportunistic communications.

All data will be accompanied by readme files that explain the data that was captured. This is common in our community. When the data is released for external use, a documentation file will be provided that contains all relevant (and non-personal) details related to the data capture, a common practice mobility datasets. All collected data, methodology tool and analysis code will be made available on **gitlab.inria.fr**.

2b. What data quality control measures will be used?

To ensure code quality, the whole measurement tool will be tested using synthetic generated traces in the Network Simulator 3 (NS-3). The goal here is to validate the tool in a controlled environment using synthetic traces that can be used as ground truth. In order to track the evolution of the code and analysis, we will use the GitLab version-control system of Inria. Besides, all data, measurement tool, and analysis code will be made available on **gitlab.inria.fr**.

In Mitik, the distributed measurements of sniffers performed in different locations and time instances make the handling, the merging, and the per-user generation of traces a very challenge task. This requires advanced approaches for error handling, filtering, and synchronization, packet parsing, as well as merging of traces coming from different sniffers. One of the partners have already produced a software tool for handling and merging traces, which we will adapt to the context of MITIK. (cf. T. Claveirole and M. Dias de Amorim, "Manipulating Wi-Fi Packet Traces with WiPal: Design and Experience", Software: Practice and Experience, vol. 42, n. 5, pp. 585-599, Apr. 2012).

Another aspect is the use of multiple link layer technologies (at least Bluetooth and Wi-Fi). Combining traces from the two sources of packets also requires fine manipulations. Finally, in Mitik, we will propose strategies to leverage packets that involve more than one mobile terminal in case nodes perform device-to-device communications.

Those correspond to challenges MITIK will face and is targeted to deal with. When suitable, we will test and validate the solutions in a simulated environment using NS-3, under (i) the strict implementation of MAC specifications described by the WiFi and Bluetooth standards currently used in mobile devices and (ii) the use of synthetic ground truth traces.

## 3. STORAGE AND BACKUP DURING THE RESEARCH PROCESS

3a. How will data and metadata be stored and backed up during the research?

All released data, measurement tool, and analysis will be made available on **gitlab.inria.fr**. This includes uniquely the data generated. The collection will take place at Université de La Rochelle. The collected data will firstly store at sniffers, where the following measures will be taken:

* A highly secure sniffer access password will be set up;

* Depending on the sniffer model, we will encrypt the storage space;

* The pseudonymization (i.e., hash function) will be done on the sniffer.
Then, sniffers will send the pseudonymized collected data to secured servers behind each partner firewall, where the
following secure measures will be taken:

* The transfer of data from the on-site sniffers (deployed at the city of La Rochelle, cf. 1a here above) to the University of La Rochelle server is done via an encrypted SCP stream and a public key / private key, unique per sniffer;

* The data is then erased on the sniffers, in the La Rochelle laboratory;

* La Rochelle server and those of Inria Saclay and Sorbonne University will securely communicate for mirrored data access for researchers at La Rochelle, at Inria Saclay, and at Sorbonne University; for each of the partners, the following measures will be taken: behind firewalls, SSH access, server mirroring (via an account with a specific port), only researchers authorized to access the servers with the support of a dedicated user key;

* Data remains on secure servers and is not loaded onto workstations, USB sticks, or any external storage devices.

The backup of data will be ensured by the mirroring between the secured servers of the three Mitik partners.

3b. How will data security and protection of sensitive data be taken care during the research

**We do not store any sensitive data.** Besides, as mentioned in the 3a item here above, strict secure measures will be applied to guarantee the protection of the collected data and its handling in a secure environment by authorized researchers, uniquely. Authorized researchers correspond to members (permanent or Mitik's hired members) of all three partners involved in Mitik.

We will rely on off-the-shelf devices and the software consists basically of collecting packets at the MAC layer. The previous experience of partners in real-life measurement campaigns will reduce risks coming from sniffers placement and data collection. Besides, as mentioned in item 1, the partners have strong expertise in differential privacy, utility improvement, trace handling, and analysis and are quite confident with the solutions that will be proposed.

Finally, support for the research team will be provided regarding the data management plan by Laurent Romary, who is Inria's "Research Data" referent.

4. LEGAL AND ETHICAL REQUIREMENTS, CODE OF CONDUCT

4a. If personal data are processed, how will compliance with legislation on personal data and on security be ensured?

The involved research procedure is the least risky and consistent with the goals of MITIK. The partners, together with COERLE's representants (i.e., Inria's Data protection officer and ethical committee) have discussed and well planned all the interventions for the collection that will ensure the privacy and the security of the involved people and their data.

Regarding the information given to the population during data collection, this question poses difficulties for the project leaders because it is necessary to reconcile (i) on the one hand, the information obligation that must be given to the population so that the research team can complies with the GDPR regulations during data collection; and (ii) on the other hand, the biases created by this information. Indeed, the information can result in people turning away from the area or entering the area and generating a lot of traffic to noise the collection. This question was brought to the attention of the DPD of Inria, which is studying with the CNIL the best possible solution.

Note that MAC-layer data will be collected from any wireless device carried by anybody passing by the zone of detection where sniffers will be deployed (passive measurement). So, no recruiting will be necessary. It is possible that particularly vulnerable people with smartphones may pass through the experiment area. In all cases, the measured participants profiles do not affect the study because only the zone of the area where they are, will be detected. As detailed in item 1b, we will only collect MAC addresses, timestamp, the sniffer zone, and eventually, the sequential number of the packet. The MAC address will be replaced by pseudonyms (hashed values) on the sniffers and will be deleted from the sniffers immediately afterwards. Once data of all sniffers is merged, we will proceed with a full anonymization (Task 2 of Mitik) of the data before any further processing (i.e., trajectory reconstruction and contact inference). Since the collecting zones will be of high traffic, the collected information will not be sensible, since there will be no way to retrieve personal information that could lead to a re-identification of the subjects. Finally, we do not store sensitive data.

All data exchanges between partners will be done via an encrypted channel (SSH). In the event of unexpected problems, the project leader will contact the Chairman of COERLE and, where applicable, Inria's data protection officer.
4b. How will other legal issues, such as intellectual property rights and ownership, be managed? What legislation is applicable?

All such issues will be managed by the **Comité Opérationnel d'Évaluation des Risques Enjeux Légaux et thiques of Inria.**

Nobody involved in Mitik project has an ownership or royalty interest in any intellectual property utilized in this protocol. There is no industrial partner involved. The measurement tool, the contact traces, and analysis will be released as a free software, for research purposes. We will use the GitLab version-control system of Inria. The collected raw data will be available uniquely to partners members working on Mitik.

4c. What ethical issues and codes of conduct are there, and how will they be taken into account?

**Not applicable:** no sensible data will be stored, and there will be no way to retrieve personal information that could lead to a re-identification of the subjects.

## 5. DATA SHARING AND LONG-TERM PRESERVATION

5a. How and when will data be shared? Are there possible restrictions to data sharing or embargo reasons?

No collected raw data will be public, only Mitik members will have secure access to it. Final outcomes of Mitik will be available for research purposes to any interested community or research entity. Such outcomes (i.e., the final shared data) concern uniquely: measurement tool and analysis code produced by Mitik as well as the fully anonymized contact traces inferred in Mitik. We will use:

- HAL to share all preprint and papers;

- GitLab (gitlab.inria.fr) and Software Heritage (https://www.softwareheritage.org) to share the measurement tool, contact traces, and analysis, in order to guarantee the reproducibility of the results.

Those will be done at the submission or at the acceptance of a paper. There will be no embargo reasons or data sharing restrictions since no sensible data will be released.

The entire study will take place throughout the duration of the ANR project. If there are a lot of trajectory reconstruction errors, collection campaigns will be repeated during the project.

5b. How will data for preservation be selected, and where data will be preserved long-term (for example a data repository or archive)?

Since no sensible data will be stored, we do not plan to destroy any collected raw data (which will be very useful for future research purposes of involved Mitik members), which will be thus preserved for long period.

The released data will be also preserved for long-term and for research purposes. Hal and Software Heritage will be used to guarantee long-term availability.

5c. What methods or software tools are needed to access and use data?

We will rely on open-source software (mostly python-based libraries likes pandas, numpy or matplotlib). Contact traces will be released in text format. The code of the measurement tool, analysis and the contact traces will be shared through GitLab.

5d. How will the application of a unique and persistent identifier (such as a Digital Object Identifier (DOI)) to each data set be ensured?

A DOI will be available for the data released with publications on HAL. When referring to a released contact trace or code in a publication, we will refer to the precise git commit ID that is a persistent and unique object identifier.

## 6. DATA MANAGEMENT RESPONSIBILITIES AND RESOURCES

6a. Who (for example role, position, and institution) will be responsible for data management (i.e. the data steward)?

The PI (Inria partner) will coordinate the project and set up regular steering and monitoring meetings. The PI will also make sure that the DMP will be implemented and updated. In the event of unexpected problems, the PI will contact the Chairman of COERLE and, where applicable, Inria's data protection officer.
6b. What resources (for example financial and time) will be dedicated to data management and ensuring that data will be FAIR (Findable, Accessible, Interoperable, Re-usable)?

The development of FAIR research and tools are primary goals of Mitik, and will be ensured by construction. Note that preparing code and data for sharing, though very time consuming, is essential in Mitik. It constitutes an integral part of three subtasks of the project, of one research engineer, and two PhD thesis funded by the project.

The Mitik was granted with funding for sniffers and GPU server acquisition, where collected raw data will be firstly stored and handled before public release.