CRAWDAD cambridge/haggle (v. 2006-09-15)

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

This data includes a number of traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for a number of days - in office environments, conference environments, and city environments.

All versions of this dataset, oldest to newest: v. 2006-01-31,  v. 2006-09-15,  v. 2009-05-29.

network type: bluetooth

network type: DTN (Delay Tolerant Network)

collection environment:

Four iMote-based experiments were conducted. 

The first included eight researchers and interns working at Intel Research in Cambridge. 

The second obtained data from twelve doctoral students and faculty comprising a research group at the University of Cambridge Computer Lab. 

The third experiment was conducted during the IEEE INFOCOM 2005 conference in Miami where 41 iMotes where carried by attendees for 3 to 4 days.

In the fourth 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.

The sixth experiment (Experiment 6) was conducted for 4 days during Infocom 2006 in Barcelona. Mobilie users in the experiment consist of 70 students and researchers, who were attending the student workshop. The 78 mobile iMotes were used, which have a wireless range around 30 meters. In addition, the 20 stationary (long range) iMotes were deployed, which have more powerful battery and extended radio range (around 100 meters). 

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

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

An anonymised version of our data will be made available to other research groups on demand.

 

Traces

last modified: 2009-08-07

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/infocom2006 was added.

release date: 2009-05-29

date/time of measurement start: 2005-01-06

date/time of measurement end: 2006-04-27

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

 

last modified: 2006-11-14

short description: Traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Intel Research Cambridge Lab.

description: This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Intel Research Cambridge Corporate Laboratory.

reason for most recent change: the initial version

derived: false

release date: 2006-01-31

date/time of measurement start: 2005-01-06

date/time of measurement end: 2005-01-11

format of trace data

=====

"table.Exp1.dat"

is a file describing the contact where a certain device is seen.

 

========================

Examples taken from table.Exp1.dat (two first columns and first rows)

========================

ID #    Class   Incidence       Occurence   :   Total   ID 1    ID 2

                                Contact Time :

1       1       8                               143     0       32

                                                69951   0       4835

 

2       1       8                               168     19      0

                                                68818   1260    0

========================

========================

 

The first column describes the ID of the device.

The second column takes value 1 or 2, it describes whether it is

        1- an internal device (one of iMotes we distributed).

        2- an external device (identified by his MAC address).

We usually give smaller ID to internal nodes. That is the reason why all tables start with devices of class 1.

The third column describes the incidence of this device, namely the number of iMote that recorded its MAC address during this experiment. It is usually between 1 and n for an external device

(where n is the number of iMotes deployed), and between 1 and n-1 for an internal device.

The rest of the table describes the number of contacts (first line) where this device were seen, and the cumulated time of these contacts (second line). Columns correspond to which iMotes recorded this devices. From the example above, node with ID 1 was seen in total 143 time during Experiment 1, and it was seen 32 time by node with ID

The cumulated time where 2 saw 1 is 4835 s. Node 2 was seen 168 time in total, and 19 time by node 1, the total time it saw node 1 is

Note that, as we usually observe, this number may not be symmetric, as interference and the limit of our implementation can create non-mutual sightings. They are, however, usually of the same order.

=====

"MAC3Btable.Exp1.dat" is a file that contains the three first bytes of the MAC address, associated with each ID. It could be useful to identify what is the kind of each external device.

=====

"contacts.Exp1.dat" is a file which describes the contact that were recorded by all devices we distributed during this experiment.

========================

Examples taken from table.Exp1.dat (two first columns and first rows)

========================

1       8       121     121     1       0

1       3       236     347     1       0

1       4       236     347     1       0

1       5       121     464     1       0

1       8       585     585     2       464

========================

========================

The first column gives the ID of the device who recorded the sightings.

The second column gives the ID of the device who was seen

(it may be an iMote, or another device recorded during the experiment).

The third and fourth column describe, respectively, the first and last time when the address of ID2 were recorded by ID1 for this contact.

The fifth and sixth column are here for reading convenience. The fifth enumerate contacts with same ID1 and ID2, as 1,2,... . The last column describes the time difference between the beginning of this contact and the end of the previous contact with same ID1 and ID2. It is by convention set to 0 if this is the first contact for this ID1 and ID2.

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.

configuration

 

================================ Location: Intel Research Cambridge Corporate Laboratory Date: January 2005, Duration: Devices distributed on Thursday, January 6, at 11:30am Devices collected on Tuesday, January 11, in the afternoon (most of the traces last only for three days). ================================ Participants: 16 admin staff, researchers, interns, and admin staff. 1 iMote was left in the kitchen, as a stationary node, during the experiment. ================================ Collected datas: - Data from only 9 iMotes could be collected properly. The others suffered from too much reset. Addresses ID: ID 1 is the stationary node. ID 2-9 are corresponding to mobile iMotes ID 10-128 corresponds to external devices

 

the cambridge/haggle/imote/cambridge trace

 

last modified: 2006-11-14

short description: Trace of Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Camputer Lab at University of Cambridge.

description: This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for six days in Computer Lab at University of Cambridge.

reason for most recent change: the initial version

derived: false

release date: 2006-01-31

date/time of measurement start: 2005-01-25

date/time of measurement end: 2005-01-31

format of trace data

=====

"table.Exp2.dat"

is a file describing the contact where a certain device is seen.

========================

Examples taken from table.Exp2.dat (two first columns and first rows)

========================

ID #    Class   Incidence       Occurence   :   Total   ID 1    ID 2

                                Contact Time :

1       1       8                               143     0       32

                                                69951   0       4835

 

2       1       8                               168     19      0

                                                68818   1260    0

========================

========================

The first column describes the ID of the device.

The second column takes value 1 or 2, it describes whether it is 1- an internal device (one of iMotes we distributed). 2- an external device (identified by his MAC address).

 

We usually give smaller ID to internal nodes. That is the reason why all tables start with devices of class 1.

The third column describes the incidence of this device, namely the

 number of iMote that recorded its MAC address during this experiment. It is usually between 1 and n for an external device (where n is the number of iMotes deployed), and between 1 and n-1 for an internal device.

 

The rest of the table describes the number of contacts (first line) where this device were seen, and the cumulated time of these contacts (second line). Columns correspond to which iMotes recorded this devices. From the example above, node with ID 1 was seen in total 143 time during Experiment 1, and it was seen 32 time by node with ID The cumulated time where 2 saw 1 is 4835 s. Node 2 was seen 168 time in total, and 19 time by node 1, the total time it saw node 1 is

Note that, as we usually observe, this number may not be symmetric, as interference and the limit of our implementation can create non-mutual sightings. They are, however, usually of the same order.

=====

"MAC3Btable.Exp2.dat" is a file that contains the three first bytes of the MAC address, associated with each ID. It could be useful to identify what is  the kind of each external device.

=====

"contacts.Exp2.dat" is a file which describes the contact that were recorded by all devices we distributed during this experiment.

========================

Examples taken from table.Exp2.dat (two first columns and first rows)

========================

1       8       121     121     1       0

1       3       236     347     1       0

1       4       236     347     1       0

1       5       121     464     1       0

1       8       585     585     2       464

========================

========================

 

The first column gives the ID of the device who recorded the sightings.

The second column gives the ID of the device who was seen

(it may be an iMote, or another device recorded during the experiment).

The third and fourth column describe, respectively, the first and last time when the address of ID2 were recorded by ID1 for this contact.

The fifth and sixth column are here for reading convenience. The fifth enumerate contacts with same ID1 and ID2, as 1,2,... . The last column describes the time difference between the beginning of this contact and the end of the previous contact with same ID1 and ID2. It is by convention set to 0 if this is the first contact for this ID1 and ID2.

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.

configuration

 

Location: Computer Lab, University of Cambridge Date: End of January 2005 Duration: Devices distributed on Tuesday, January 25th, 2005 at 14:00am Devices collected on Monday, January 31st, 2005 in the afternoon (most of the iMotes last around 5days) Participants: 19 graduate students from the System Research Group. Collected datas: - Some of the iMotes did not deliver any useful data, as a consequence of accidental hardware reset. Contacts with one of them were discarded from the traces of other iMotes to avoid any consequence on the experimental results. - In total only 12 iMotes could be used to produce this trace, others were suffering from hardward resets. The contacts with these nodes were discarded from the complete - Details of ID number: ID 1-12 are corresponding to iMotes (Class 1) ID 13-223 corresponds to external devices (Class 2)

 

 

cambridge/haggle/imote/infocom trace

 

last modified: 2006-11-14

short description: Trace of Bluetooth sightings by groups of users carrying small devices (iMotes) for four days.

description: This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for four days in Conference IEEE Infocom in Grand Hyatt Miami.

reason for most recent change: the initial version

derived: false

release date: 2006-01-31

date/time of measurement start: 2005-03-07

date/time of measurement end: 2005-03-10

format of trace data

=====

"table.Exp3.dat"

is a file describing the contact where a certain device is seen.

========================

Examples taken from table.Exp3.dat (two first columns and first rows)

========================

ID #    Class   Incidence       Occurence   :   Total   ID 1    ID 2

                                Contact Time :

1       1       8                               143     0       32

                                                69951   0       4835

2       1       8                               168     19      0

                                                68818   1260    0

========================

========================

The first column describes the ID of the device.

The second column takes value 1 or 2, it describes whether it is 
1- an internal device (one of iMotes we distributed). 
2- an external device (identified by his MAC address).

We usually give smaller ID to internal nodes. That is the reason why all tables start with devices of class 1.

The third column describes the incidence of this device, namely the number of iMote that recorded its MAC address during this experiment. It is usually between 1 and n for an external device (where n is the number of iMotes deployed), and between 1 and n-1 for an internal device.

 

The rest of the table describes the number of contacts (first line) where this device were seen, and the cumulated time of these contacts (second line). Columns correspond to which iMotes recorded this devices. From the example above, node with ID 1 was seen in total 143 time during Experiment 1, and it was seen 32 time by node with ID

The cumulated time where 2 saw 1 is 4835 s. Node 2 was seen 168 time in total, and 19 time by node 1, the total time it saw node 1 is 

Note that, as we usually observe, this number may not be symmetric, as interference and the limit of our implementation can create non-mutual sightings. They are, however, usually of the same order.

=====

"MAC3Btable.Exp3.dat"

is a file that contains the three first bytes of the MAC address, associated with each ID. It could be useful to identify what is the kind of each external device.

 

=====

"contacts.Exp3.dat"

is a file which describes the contact that were recorded by all

devices we distributed during this experiment.

 

========================

Examples taken from table.Exp3.dat (two first columns and first rows)

========================

1       8       121     121     1       0

1       3       236     347     1       0

1       4       236     347     1       0

1       5       121     464     1       0

1       8       585     585     2       464

========================

========================

The first column gives the ID of the device who recorded the sightings.

The second column gives the ID of the device who was seen (it may be an iMote, or another device recorded during the experiment).

The third and fourth column describe, respectively, the first and last time when the address of ID2 were recorded by ID1 for this contact.

The fifth and sixth column are here for reading convenience. The fifth enumerate contacts with same ID1 and ID2, as 1,2,... . The last column describes the time difference between the beginning of this contact and the end of the previous contact with same ID1 and ID2. It is by convention set to 0 if this is the first contact for this ID1 and ID2.

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.

 

configuration

Location: Conference IEEE Infocom in Grand Hyatt Miami Date: March 2005 Duration: Devices distributed on March 7th, 2005 between lunch time and 5pm. Devices collected on March 10th, 2005 in the afternoon. Participants: 50 students, attending the student workshop. Collected datas: - 2 iMotes were lost, and 7 did not deliver useful data, as a consequence of accidental hardware reset. Contacts with any of these were discarded from the traces of other iMotes to avoid any consequence on the experimental results. - The first six hours were discarded, as people were attending the same workshop during the first afternoon. - Details of ID number: ID 1-41 are corresponding to iMotes (Class 1) ID 42-274 corresponds to external devices (Class 2)

disruptions to data collection

 

Of the fifty-four iMotes distributed, forty-one yielded useful data, eleven did not contain useful data because of various failures with the battery and packaging, and two were not returned.

limitation

Preliminary tests revealed the following problem: Bluetooth devices on a specific brand of mobile phone did not show up consistently during inquiries (and increasing the inquiry period to ten seconds did not help). Therefore, a small number of nodes were causing the memory to fill too quickly. To avoid this problem, we keep a device in the "in-contact list" even if it is not seen for one inquiry interval. If it comes back in-contact on the next interval, nothing is stored. If it does not, a record is stored as normal. This solves the problem, at the expense of not being able to detect actual cases where a node moved out of range during one two-minute period, and back into range for the next two-minute period.

 

the cambridge/haggle/imote/content trace

 

last modified: 2006-11-14

short description: Traces of Bluetooth sightings by groups of users carrying small devices (iMotes) for two months in the locations around the the city of Cambridge, UK.

description: This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for two months 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.

reason for most recent change: the initial version

derived: false

release date: 2006-01-31

date/time of measurement start: 2005-10-28

date/time of measurement end: 2005-12-21

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).

 

format of trace data

 

========================

Description of the files in each experiment

========================

=====

"MAC3Btable"

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.

=====

"*.dat"

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

following directories:

- SR-10mins-FixLocation

- SR-10mins-Students

- SR-6mins-FixLocation

- LR-2mins

========================

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, 53

Popular supermarket: 38

Central point in the commercial center n?1: 52

Central point in the commercial center n?2: 40

College porter's lodge: 51

Computer lab reception:   54