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

top

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

@MISC{cambridge-haggle-2006-09-15,
  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. 2006-09-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle},
  month = sep,  
  year = 2006
}
					

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.

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

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

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.

[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] carreras-malware

top

[Paper] chaintreau-opportunistic

top

Studying transfer opportunities between wireless devices carried by humans, we 
observe that the distribution of the inter-contact time, that is the time gap 
separating two contacts of the same pair of devices, exhibits a heavy tail such 
as one of a power law, over a large range of value. This observation is 
confirmed on six distinct experimental data sets. It is at odds with the 
exponential decay implied by most mobility models. In this paper, we study how 
this new characteristic of human mobility impacts a class of previously 
proposed forwarding algorithms. We use a simplified model based on the renewal 
theory to study how the parameters of the distribution impact the delay 
performance of these algorithms. We make recommendation for the design of well 
founded opportunistic forwarding algorithms, in the context of human carried 
devices.

[Paper] chaintreau-pocket

top

Opportunistic networks make use of human mobility and local forwarding in order 
to distribute data. Information can be stored and passed, taking advantage of 
the device mobility, or forwarded over a wireless link when an appropriate 
contact is met. Such networks fall into the fields of mobile ad-hoc networking 
and delay-tolerant networking. In order to evaluate forwarding algorithms for 
these networks, accurate data is needed on the intermittency of connections. 
\par In this paper, the inter-contact time between two transmission 
opportunities is observed empirically using four distinct sets of data, two 
having been specifically collected for this work, and two provided by other 
research groups. \par We discover that the distribution of inter-contact time 
follows an approximate power law over a large time range in all data sets. This 
observation is at odds with the exponential decay expected by many currently 
used mobility models. We demonstrate that opportunistic transmission schemes 
designed around these current models have poor performance under approximate 
power-law conditions, but could be significantly improved by using limited 
redundant transmissions.

[Paper] hsu-nodal

top

[Paper] hui-bubble

top

In this paper we seek to improve understanding of the structure of human 
mobility, and to use this in the design of forwarding algorithms for Delay 
Tolerant Networks for the dissemination of data amongst mobile users. 
Cooperation binds but also divides human society into communities. Members of 
the same community interact with each other preferentially. There is structure 
in human society. Within society and its communities, individuals have varying 
popularity. Some people are more popular and interact with more people than 
others; we may call them hubs. Popularity ranking is one facet of the 
population. In many physical networks, some nodes are more highly connected to 
each other than to the rest of the network. The set of such nodes are usually 
called clusters, communities, cohesive groups or modules. There is structure to 
social networking. Different metrics can be used such as information flow, 
Freeman betweenness, closeness and inference power, but for all of them, each 
node in the network can be assigned a global centrality value. What can be 
inferred about individual popularity, and the structure of human society from 
measurements within a network? How can the local and global characteristics of 
the network be used practically for information dissemination? We present and 
evaluate a sequence of designs for forwarding algorithms for Pocket Switched 
Networks, culminating in Bubble, which exploit increasing levels of information 
about mobility and interaction.

[Paper] hui-conference

top

[Paper] karagiannis-power-law

top

We examine the fundamental properties that determine the basic performance 
metrics for opportunistic communications. We first consider the distribution of 
inter-contact times between mobile devices. Using a diverse set of measured 
mobility traces, we find as an invariant property that there is a 
characteristic time, order of half a day, beyond which the distribution decays 
exponentially. Up to this value, the distribution in many cases follows a power 
law, as shown in recent work. This power law finding was previously used to 
support the hypothesis that inter-contact time has a power law tail, and that 
common mobility models are not adequate. However, we observe that the time 
scale of interest for opportunistic forwarding may be of the same order as the 
characteristic time, and thus the exponential tail is important. We further 
show that already simple models such as random walk and random waypoint can 
exhibit the same dichotomy in the distribution of inter-contact time asc in 
empirical traces. Finally, we perform an extensive analysis of several 
properties of human mobility patterns across several dimensions, and we present 
empirical evidence that the return time of a mobile device to its favorite 
location site may already explain the observed dichotomy. Our findings suggest 
that existing results on the performance of forwarding schemes based on 
power-law tails might be overly pessimistic.

[Paper] musolesi-mobility

top

Validation of mobile ad hoc network protocols relies almost exclusively on 
simulation. The value of the validation is, therefore, highly dependent on how 
realistic the movement models used in the simulations are. Since there is a 
very limited number of available real traces in the public domain, synthetic 
models for movement pattern generation must be used. However, most widely used 
models are currently very simplistic, their focus being ease of implementation 
rather than soundness of foundation. As a consequence, simulation results of 
protocols are often based on randomly generated movement patterns and, 
therefore, may differ considerably from those that can be obtained by deploying 
the system in real scenarios. Movement is strongly affected by the needs of 
humans to socialise or cooperate, in one form or another. Fortunately, humans 
are known to associate in particular ways that can be mathematically modelled 
and that have been studied in social sciences for years. In this paper we 
propose a new mobility model founded on social network theory. The model allows 
collections of hosts to be grouped together in a way that is based on social 
relationships among the individuals. This grouping is then mapped to a 
topographical space, with movements influenced by the strength of social ties 
that may also change in time. We have validated our model with real traces by 
showing that the synthetic mobility traces are a very good approximation of 
human movement patterns.

[Paper] yoneki-community-detection

top

Community is an important attribute of Pocket Switched Networks (PSNs), since 
mobile devices are carried by people who tend to belong to communities in their 
social life. We discover the heterogeneity of human interactions such as 
community formation from real world human mobility traces. We have introduced 
novel distributed community detection approaches and evaluated with those 
traces. This paper describes a series of visualizations to show characteristics 
of human mobility traces including community detection. We focus on extracting 
information related to levels of clustering, network transitivity, and strong 
community structure. The progression of the connection map along the community 
formation process is also visualized.