News

Join the CRAWDAD community

Reset your CRAWDAD account password

Datasets and tools by name

Datasets and tools by release date

Datasets and tools by keyword:

Datasets by measurement purpose:

About the CRAWDAD project

CRAWDAD references in CiteULike

CRAWDAD contributors by country

CRAWDAD members by country

CRAWDAD FAQ

CRAWDAD sponsors

Related websites

 

 Search CRAWDAD via Google:

The upmc/rollernet dataset (v. 2009-02-02)  >  the imote traceset

There is 1 trace in this traceset
download the imote-traces-RollerNet.tar.gz file
from a CRAWDAD mirror:  US UK AU
size="1.0MB" md5="8eac3ece9dd13c8c6c81118b1be96db3" type="gz"
last modified
2009-02-10
reason for most recent change
the initial version.
short description

Traceset of Bluetooth sightings by groups of rollerbladers carrying iMotes.

description

This traceset includes traces of any opportunistic sighting of Bluetooth devices by groups of rollerbladers carrying iMotes in the roller tour in Paris, France.

release date
2009-02-02
date/time of measurement start
2006-08-20
date/time of measurement end
2006-08-20
methodology

I. Data collection and pre-processing:

We tried to keep the processing of data before public release to a minimum, to allow any flexibility for possible research use. Some choices had to be made to reduce power consumption, memory use, and because of specific capabilities of the iMote prototype. Before using these data for your research, it may be important to check that it does not impact any of your findings.

1- periodic desynchronized scanning.

In our experiment, iMotes were distributed to a group of people to collect any opportunistic sighting of other Bluetooth devices (including the other iMotes distributed). Each iMote scans on a periodic basis for devices, asking them to respond with their MAC address, via the paging function.

It takes approximately 5 to 10s to perform the complete scanning. After initial tests, we observe that most of the contacts were recorded with a 5s scanning time, and this value was used in the experiment.

The time granularity between two scannings is 15s. It is important to avoid synchronization of two iMotes around the same cycle clock, as each of them cannot respond to any request when it is actively scanning. Therefore, we implemented a random dephasing on [-5s;+5s] to handle this case.

2- skip-length sequence.

A contact "A sees B" is defined as a period of time where all successive scanning by A receive a positive answer by B. Ideally an information should be kept at the end of each contact period.

After preliminary test it became quite clear that a very large number of contact periods were only separated by one interval. We decided, to avoid memory overflow, to implement a skip sequence of "one", meaning that a contact period will only be stopped after two successive failure of a scanning response. As a consequence, no inter-contact time of less than two intervals could have been observed.

3- Manual Time synchronization.

Time between iMotes is not synchronized by a central entity, and traces belonging to different devices bear times which are relative to the starting time of each device. We recorded the time at which each iMote was first powered up, which corresponds to time 0 at that iMote. After collecting the data, we then converted all times into Unix timestamps (seconds elapsed since 00:00:00 UTC, Jan 1, 1970).

II. iMotes deployment

In the experiment we performed, we were interested in tracking contacts between different mobile users.

The data set has been collected on August 20, 2006. According to organizers and police information, about 2,500 people participated to the rollerblading tour (few rain showers just before the tour resulted in a number of participants below the average). The total duration of the tour was about three hours, composed of two sessions of 80 minutes, interspersed with a break of 20 minutes.

During the tour the iMotes has been deployed in three main group of skaters divided as following: --Staff members which are themselves organized into six groups: -Front left and front right -Rear left and rear right -Front and rear. 25 iMotes were entrusted among these six groups. These positions are relative and may have not been always respected by the skaters. There are two iMotes that always stayed at their assignated positions, one at the front and one at the back of the tour. --Skating associations, which receveid 26 iMotes. This is a group of skilled skaters which were expected to be highly mobile --A set of friends which received 11 iMotes.

The belonging of each iMote ID to one of these groups is described in the trace configuration section.

limitation

As in the Haggle experiments, we observed that a number of MAC addresses recorded were different from a known one only by one or two digit. They were most of the time recorded once for a single time slot. It is clear that at least a part of them comes for a corrupted signal received on the link level by our devices. We filtered the data set retaining only MAC adresses of device that have been seen at least twice.

sanitization

To protect participants privacy, we choose not to release the MAC address, neither from the iMotes nor from other external devices recorded. Every device is given a unique identifier, usually called ID number in this document. Depending on which number, it might be an iMote or another MAC address that were recorded from other active Bluetooth devices around.

 the upmc/rollernet/imote/contacts trace
 how to cite this traceset