Traces of Bluetooth sightings by groups of users carrying iMotes.
This data includes a number of traces of Bluetooth sightings by groups of users carrying small devices (iMotes) at locations around the city of Cambridge, UK.
last modified : 2006-12-16
release date : 2006-11-17
date/time of measurement start : 2005-10-28
date/time of measurement end : 2005-12-21
collection environment : In this experiment, we were interested in tracking contacts between different mobile users, and also contacts between mobile users and various fixed locations. Mobile users in our experiment mainly consisted of students from Cambridge University who were asked to carry these iMotes with them at all times for the duration of the experiment. In addition to this, we deployed a number of stationary nodes in various locations that we expected many people to visit such as grocery stores, pubs, market places, and shopping centers in and around the city of Cambridge, UK. A stationary iMote was also placed at the reception of the Computer Lab, in which most of the experiment participants are students.
network configuration : We set up experiments making use of the iMote platform made by Intel Research. iMotes are derived from the Berkeley Mote3, with the current version based around the Zeevo TC2001P system-on-a-chip providing an ARM7 processor and Bluetooth support. Along with a 950mAh CR2 battery, each iMote was enclosed in packaging designed to be convenient for test subjects to continually carry. Two types of packaging were made available : some iMotes were made into keyfobs while others were enclosed in small boxes. Subjects were asked to pick the form factor which allowed them to conveniently keep the iMote with them at all times, with most simply attaching the iMote to their keys.
data collection methodology : To evaluate the different content distribution schemes we propose, we conducted an experiment in the city of Cambridge, UK, in which 20 stationary devices equipped with a Bluetooth contact logger were deployed at popular places. In addition to this, we deployed 40 similar contact loggers on a group of students from Cambridge University. Because we used Bluetooth technology, we gathered interactions not only between the contact loggers, but also with a large number of other Bluetooth enabled devices such as mobile phones or PDAs. iMotes contacts were classified into two groups: iMotes recording the sightings of another iMotes are classified as "internal" contacts, while sightings of other types of Bluetooth devices are called "external" contacts. The external contacts are numerous and include anyone who has an active Bluetooth device in the vicinity of the iMote carriers, thereby providing a measure of actual wireless networking opportunities present at the time. The internal contacts, on the other hand, represent the data transfer opportunities that each of our participants would have, if they were equipped with devices which are always-on and always-carried.
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.
Traceset of Bluetooth sightings by groups of users carrying iMotes.
- files: imote-traces-cambridge.tar.gz
- description: This traceset includes Bluetooth sightings by groups of users carrying small devices (iMotes) at locations around the city of Cambridge, UK.
- measurement purpose: Content Distribution Evaluation
- 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 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 scanning is Ns. Later in this document, the exact values we chose are given. 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 [-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 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). 4- Corrupted MAC address, and discarded mote. 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. 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), should be supposed defective and ignored." We did not discard any iMotes in these data set. We recommend to remove iMotes that were seen only one time for a contact of length 1s.
- 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.
- cambridge: Traces of Bluetooth sightings by groups of users carrying small devices (iMotes).
- configuration: In the experiment we performed, we were interested in tracking contacts between different mobile users, and also contacts between mobile users and various fixed locations. Mobile users in our experiment mainly consisted of students from Cambridge University who were asked to carry these iMotes with them at all times for the duration of the experiment. In addition to this, we deployed a number of stationary nodes in various locations that we expected many people to visit such as grocery stores, pubs, market places, and shopping centers in and around the city of Cambridge, UK. A stationary iMote was also placed at the reception of the Computer Lab, in which most of the experiment participants are students. Here are the different types of iMotes that we deployed: MSR-10 : Mobile Short Range iMotes with an interval of 10 minutes between inquiries. These iMotes were given to a group of 40 students, mostly in the 3rd year at the Cambridge University Computer Lab. The devices were packaged in small boxes (dental floss boxes) to be easy to carry around in a pocket, and used a CR-2 battery (950 mAh) for power. FSR-10 : Fixed Short Range iMotes with an interval of 10 minutes between inquiries. We deployed 15 of these iMotes in fixed locations such as pubs, shops or colleges' porter lodges. We used exactly the same packaging and batteries as the MSR-10. FSR-6 : Fixed Short Range iMotes with an inquiry interval of 6 minutes. These iMotes were equipped with a more powerful rechargeable battery providing 2200 mAh so that we were able to reduce the inquiry interval to 6 minutes. We deployed 2 of these. FLR-2 : Fixed Long Range iMotes with an interval of 2 minutes between inquiries. To increase the area in which these iMotes can discover other devices, four devices were equipped with an external antenna, which provided a communication range that was approximately twice that of the short range iMotes. Furthermore, these iMotes were also equipped with 3 more powerful rechargeable batteries providing 2200 mAh so that we could reduced the inquiry interval to 2 minutes. The experiment started on Friday, October 28th 2005, 9:55:32 (GMT) and stopped on Wednesday, December 21th 2005, 13:00 (GMT).
Description of the files in each experiment
is a file that contains the three first bytes of the MAC address,
associated with each ID. It could be useful to identify the manufacturer
of each external device.
Note that MAC devices from ID=11168 to ID=11421 should be removed because
they may correspond to fake devices. This is the results from MAC
corruption. According to the OUI (Organizationally Unique Identifier)
database we could not have MAC addresses that begin with the first bytes
higher than 0x08.
are files describing the contact recorded by all devices we distributed
during this experiment.
The dat file N.dat represents the data for the iMote with identifier (ID)
N. These data files for the 3 different categories of iMotes are in the
Examples taken from LR-2mins/37.dat
9546 1130504701 1130504701
10536 1130505044 1130505044
4649 1130506372 1130506372
7490 1130506608 1130506615
5905 1130506851 1130506851
8996 1130506851 1130506858
1431 1130506970 1130506970
5639 1130507327 1130507327
6883 1130508255 1130508255
6540 1130508606 1130508613
- The first column gives the ID of the device who was seen by the iMote 37.
- The second and third columns describe, respectively, the first and
last time when the address were recorded for the contact.
- Note, again, that these contacts may not be mutual between a pair of
iMotes, because scanning period of different iMotes are not
synchronized, and because the sightings might not be symmetric.
- Also, times are unix timestamps which correspond to the number of seconds
since midnight January 1, 1970 UTC (referred to as the Epoch).
Globally, the ID have been attributed in the following fashion:
- SR-10mins-Students ( ID in [1:36] )
- LR-2mins ( ID in [37:40] )
- SR-10mins-FixLocation ( ID in [41:52] )
- SR-6mins-FixLocation ( ID in [53:54] )
- External contacts ( ID in [55:inf] )
To ease the understanding of data while keeping a sufficent privacy level,
we provide here an idea of the kind of locations where fixed iMotes were deployed:
Pubs: 41, 45, 46, 47, 50 Shop windows: 37, 39, 42, 43, 44, 48, 49, 53Popular supermarket: 38Central point in the commercial center n?1: 52Central point in the commercial center n?2: 40
College porter's lodge: 51Computer lab reception: 54
The files in this directory are a CRAWDAD dataset hosted by IEEE DataPort.
About CRAWDAD: the Community Resource for Archiving Wireless Data At Dartmouth is a data resource for the research community interested in wireless networks and mobile computing.
CRAWDAD was founded at Dartmouth College in 2004, led by Tristan Henderson, David Kotz, and Chris McDonald. CRAWDAD datasets are hosted by IEEE DataPort as of November 2022.
Note: Please use the Data in an ethical and responsible way with the aim of doing no harm to any person or entity for the benefit of society at large. Please respect the privacy of any human subjects whose wireless-network activity is captured by the Data and comply with all applicable laws, including without limitation such applicable laws pertaining to the protection of personal information, security of data, and data breaches. Please do not apply, adapt or develop algorithms for the extraction of the true identity of users and other information of a personal nature, which might constitute personally identifiable information or protected health information under any such applicable laws. Do not publish or otherwise disclose to any other person or entity any information that constitutes personally identifiable information or protected health information under any such applicable laws derived from the Data through manual or automated techniques.
Please acknowledge the source of the Data in any publications or presentations reporting use of this Data.
Jérémie Leguay, Pan Hui, Jon Crowcroft, James Scott, Anders Lindgren, Timur Friedman, upmc/content, https://doi.org/10.15783/C7388C , Date: 20061117
- imote-traces-cambridge.tar.gz (303.96 kB)
Open Access dataset files are accessible to all logged in users. Don't have a login? Create a free IEEE account. IEEE Membership is not required.
These datasets are part of Community Resource for Archiving Wireless Data (CRAWDAD). CRAWDAD began in 2004 at Dartmouth College as a place to share wireless network data with the research community. Its purpose was to enable access to data from real networks and real mobile users at a time when collecting such data was challenging and expensive. The archive has continued to grow since its inception, and starting in summer 2022 is being housed on IEEE DataPort.