[Traceset] cambridge/haggle/imote (v. 2006-09-15)

top

The trace cambridge/haggle/imote/content was added.

@MISC{cambridge-haggle-imote-2006-09-15,
  author = {James Scott and Richard Gass and Jon Crowcroft and Pan Hui and Christophe Diot and Augustin Chaintreau},
  title = {{CRAWDAD} trace set cambridge/haggle/imote (v. 2006-09-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle/imote},
  month = sep,  
  year = 2006
}
					

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.

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

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

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

[Trace] cambridge/haggle/imote/intel (v. 2006-01-31)

top

the initial version

@MISC{cambridge-haggle-imote-intel-2006-01-31,
  author = {James Scott and Richard Gass and Jon Crowcroft and Pan Hui and Christophe Diot and Augustin Chaintreau},
  title = {{CRAWDAD} trace cambridge/haggle/imote/intel (v. 2006-01-31)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle/imote/intel},
  month = jan,  
  year = 2006
}
					

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

=====
"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
2. 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
1260. 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.

================================
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

[Trace] cambridge/haggle/imote/cambridge (v. 2006-01-31)

top

the initial version

@MISC{cambridge-haggle-imote-cambridge-2006-01-31,
  author = {James Scott and Richard Gass and Jon Crowcroft and Pan Hui and Christophe Diot and Augustin Chaintreau},
  title = {{CRAWDAD} trace cambridge/haggle/imote/cambridge (v. 2006-01-31)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle/imote/cambridge},
  month = jan,  
  year = 2006
}
					

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

=====
"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
2. 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
1260. 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.

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)

[Trace] cambridge/haggle/imote/infocom (v. 2006-01-31)

top

the initial version

@MISC{cambridge-haggle-imote-infocom-2006-01-31,
  author = {James Scott and Richard Gass and Jon Crowcroft and Pan Hui and Christophe Diot and Augustin Chaintreau},
  title = {{CRAWDAD} trace cambridge/haggle/imote/infocom (v. 2006-01-31)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle/imote/infocom},
  month = jan,  
  year = 2006
}
					

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

=====
"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
2. 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
1260. 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.

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)

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.

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.

[Author] James Scott

top

[Author] Richard Gass

top

[Author] Jon Crowcroft

top

[Author] Pan Hui

top

[Author] Christophe Diot

top

[Author] Augustin Chaintreau

top