[Dataset] cambridge/haggle (v. 2009-05-29)

top

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

@MISC{cambridge-haggle-2009-05-29,
  author = {James Scott and Richard Gass and Jon Crowcroft and Pan Hui and Christophe Diot and Augustin Chaintreau},
  title = {{CRAWDAD} data set cambridge/haggle (v. 2009-05-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle},
  month = may,  
  year = 2009
}
					

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.

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

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.

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.

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

[Traceset] cambridge/haggle/imote (v. 2009-05-29)

top

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

@MISC{cambridge-haggle-imote-2009-05-29,
  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. 2009-05-29)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle/imote},
  month = may,  
  year = 2009
}
					

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.

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

top

the initial version

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

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.

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

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

Due to various hardware problems and the loss of some of the deployed
iMotes, we were able to gather measurement data from 36 mobile
participants and 18 fixed locations.

[Trace] cambridge/haggle/imote/infocom2006 (v. 2009-05-29)

top

the initial version

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

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) for four days in Barcelona, Spain.

This file contains information on Experiment 6, which was conducted during Infocom 2006 in Barcelona

Location: Princesa Sofia Gran Hotel, Barcelona

Date: Monday, April 24th to Thursday April 27th, 2006

Duration:
      Devices distributed on Sundary April 23rd, between 7:00 and 9:00 pm.
      Devices collected back starting from April 26th and on April 27th during the day.
Origin of time:
      All times indicated in the files corresponds to the seconds elapsed 
since the motes were turned on.
      The motes had been all turned on on Sunday April 23rd at 5:01pm 
(which is 61260 seconds after midnight on that day).

Participants:
70 students and researchers, attending the student workshop.

Collected datas:
- 2 iMotes 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.

Participating nodes:
- Nodes with ID#1 through #17 are static long range iMotes iMotes deployed throughout the area.
- The three nodes with ID#18-#20 are long range iMotes that have been placed in lift of the hotel.
- Nodes #21-#98 are participants of the Infocom student workshop.
- Nodes with ID larger or equal than #100 are external devices.

Note that the 20 stationary (long range) iMotes have more powerful battery and 
extended radio range (around 100 meters). 
The 78 mobile iMotes have a wireless range around 30 meters.

Details of the files contained in this dataset:

=====
"infocom06floormap.pdf"
Precise the approximate location and range of the static iMotes deployed.

Please note that among the static nodes
Mezzanine: ID #6, #8 (wrongly indicated on the map as 87239), #9, #10, #12, #17
Floor -1: ID #3, #14, #16,
Floor -2: ID #1, #4, #5, #7, #11, #15
Others: ID#2 (Bar) #13 (Concierge)
Lifts: ID #17, #18, #19

=====
"MAC2id.dat"

is a file that contains the MAC address, associated with each ID 
for the static motes only (others have been removed to preserve 
participants privacy). It allows in particular to relate the node ID 
and the location as mentioned on the floormap.

=====
"table.Exp6.dat"

is a file which describes the amount of contacts between the different 
pairs of devices (Please see the General README for the detailed 
description of this file).

=====
"contacts.Exp6.dat"

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

========================
Examples
========================
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.
Note that the time were computed in seconds, with the zero starting 
on Sunday at 5:01pm (Please see Origin of time above).

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

=====
Profile of participants.

During the experiments, we ask each participants to fill a questionnaire 
with a number of information about this person. We give the full results 
(unfortunately not complete as many participants did not answer the questionnaire fully).

NB: To preserver participants privacy the answer has been reassigned 
to numbers, so that the file allows to know, e.g., which participants 
are from the the same affiliation without disclosing the name of this affiliation.

The folder forms contains:

- The Questionnaire.doc document used for fill the form by participants.
- the answers of each participants in the file corresponding to its ID:
"<ID>.txt"
Please refer to the Questionnaire for the exact formulation of the question.
Here is a summary of what the file contains:
Row 1, 2
- corresponds to name and email addresses.
For confidentiality reasons here they only present the ID of the node.
Row 3
- indicates nationalities of the experimentalist.
Row 4
- the school where the participants completed her or his study
Row 5
- the languages spoken by the participants
Row 6
- the current affiliation(s)
Row 7
- Position: Student/Researcher/Professor
Row 8, 9
- indicates the city and the country of residence
Row 10
- please ignore this field (project membership that was not included)
Row 11
- airport the participant is flying from.
Row 12
- please ignore this field (cellphone/PDA carried, not filled by participants)
Row 13
- please ignore this field (number of Infocom conference attended before)
Row 14
- indicates the hotel where the participant is staying during the conference.
Row 15
- please ignore this field (roommate during the conference, not indicated)
Row 16
- please ignore this field (subway station while in Barcelona, not indicated by participants)
Row 17
- please ignore this field (presenter or not, not indicated by participants)
Row 18
- indicates membership of ACM, IEEE, ComSoc
Row 19
- indicates the list of topics of interest (selected from those of the CFP) 
which are relevant to the research of the participant

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

[Author] James Scott

top

[Author] Richard Gass

top

[Author] Jon Crowcroft

top

[Author] Pan Hui

top

[Author] Christophe Diot

top

[Author] Augustin Chaintreau

top

[Paper] chaintreau-diameter

top

also available as Thomson technical report CR-PRL-2007-07-0001