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 sponsors

CRAWDAD contributors by country

CRAWDAD library (Zotero)

CRAWDAD FAQ

Privacy Policy

Contact Us

Related websites

 

 Search CRAWDAD via Google:

The cambridge/haggle dataset (v. 2006-09-15)  >  the imote traceset

There are 3 traces in this traceset
last modified
2006-11-14
short description

Four traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for a number of days.

description

This traceset includes four traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for a number of days - in Intel Research Cambridge Corporate Laboratory, Computer Lab at University of Cambridge, Conference IEEE Infocom in Grand Hyatt Miami, and locations around the city of Cambridge, UK.

reason for most recent change
The trace cambridge/haggle/imote/content was added.
release date
2006-09-15
date/time of measurement start
2005-01-06
date/time of measurement end
2005-12-21
methodology

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 all our experiments, iMotes were distributed to a group of people to collect any opportunistic sighting of other Bluetooth devices (including the other iMotes distributed). Each iMotes scans on a periodic basis for device, 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 test we observe that most of the contacts were recorded with 5s scaning time, and this value was ultimately chosen.

The time granularity between two scanning is 120s. 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. We implemented a random dephasing on [-12s;+12s] 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 two intervals. 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 intervales could have been observed.

3- Manual Time synchronization.

Time between iMotes is not synchronized by a central entity, and traces belonging to different devices bears time which are relative to the starting time of each device. To read all data with the same time axis, devices were started as much as possible at the same time, and a method based on mutual sightings were used to compute manually the shift between different traces. This will certainly prove to be quite accurate for interval of time above 5mn, we cannot claim a complete accuracy for smaller time-scale. And we recommend to compute mutual sightings to check any inaccuracies that we may incur in this data.

The time is expressed in seconds, the origin ( 0s ) corresponds to 12am on the first day of the experiment. Hence time of the day can be computed from it. Again, the operation was to add a constant to all previously synchronized traces, to reflect the time of beginnning of the experiment. We cannot claim high accuracy (under 5mn).

sanitization
  • Anonymization and Address Identifier.

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.

disruptions to data collection
- Corrupted MAC address, and discarded mote. After the first couple of experiments, we observe 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. to ignore this artificial data, we implement the following rule: "Any MAC address that were recorded only once, for a single scanning (that is, related with a unique contact, with length 1s), are supposed defective and ignored." We did not discard any other one: a node that was seen twice, each contact being of length 1s, or a node that was seen once for two successive scanning, was included in the final datasets. Another important aspect is that some iMotes could not come up with data that can be used, mostly due to unfortunate hardware reset, or losses. These devices may still appear in the traces of other iMotes, and are difficult to interpret as they seems to follow an intermittent presence during the experiment. All of them were discarded from the final datasets, to avoid impacting the results in any way.
 the cambridge/haggle/imote/intel trace
 the cambridge/haggle/imote/cambridge trace
 the cambridge/haggle/imote/infocom trace
 how to cite this traceset