[Dataset] upmc/content (v. 2006-11-17)

top

the initial version

@MISC{upmc-content-2006-11-17,
  author = {Jérémie 
Leguay and Anders Lindgren and James Scott and Timur Friedman and Jon Crowcroft and Pan Hui},
  title = {{CRAWDAD} data set upmc/content (v. 2006-11-17)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/upmc/content},
  month = nov,  
  year = 2006
}
					

This data includes a number of traces of Bluetooth sightings 
by groups of users carrying small devices (iMotes) at locations around the city 
of Cambridge, UK.

UPMC Data License
Dear User:

Thank you for your interest in obtaining and using data from the team Networks and 
Performance Analysis of the Laboratoire d'Informatique de Paris6 (LIP6) of the 
University Pierre et Marie Curie (hereinafter "UPMC" hosted by the CRAWDAD's 
Dartmouth College archive (hereinafter referred to as "UPMC Data"). 

Data Licensing Information:

UPMC hereby grants a nonexclusive, nontransferable license to use the UPMC Data for 
educational and research purposes only. The UPMC Data shall not be redistributed 
outside the scope of the terms and conditions of this Agreement without the express 
written prior approval of UPMC. 

User agrees to respect the privacy of those human subjects whose wireless-network 
activity is captured by the UPMC Data. Do not attempt to reverse the anonymization 
process to identify specific MAC addresses, IP address, telephone number, or other 
identifiers, or to identify their actual location. Use only the header information in packet 
traces; do not attempt to extract further information. (Header information specifies the 
type of information that is being transferred over the network, and specifically excludes 
the contents of the data, such as usernames, passwords, filenames, files, or URLs.) 

User agrees to acknowledge the source of the UPMC Data in any publications reporting 
on User's use of it. For example: "We gratefully acknowledge the use of wireless 
Université Pierre & Marie Curie (Paris6)/CNRS data from the team Networks and 
Performances Analysis of the Laboratoire d'Informatique de Paris 6 (LIP6) on the 
CRAWDAD archive." 

UPMC provides the UPMC Data "AS IS," without any warranty or promise of technical 
support, and disclaims any liability of any kind for any damages whatsoever resulting 
from use of UPMC Data. 

UPMC MAKES NO WARRANTIES, EXPRESS OR IMPLIED WITH RESPECT TO 
THE DATA, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY 
OR FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE HEREBY 
EXPRESSLY DISCLAIMED. 

Your acceptance and use of the UPMC Data binds you to the terms and conditions of this 
License as stated herein.

Direction des Relations Industrielles et du Transfert de Technologie
Université Pierre et Marie Curie (Paris6)
19. Cité Voltaire
75001 Paris
France

In this experiment, we were interested in tracking contacts between different mobile users, 
and also contacts between mobile users and various fixed locations. Mobile users in our experiment 
mainly consisted of students from Cambridge University who were asked to carry these iMotes 
with them at all times for the duration of the experiment. In addition to this, 
we deployed a number of stationary nodes in various locations that we expected 
many people to visit such as grocery stores, pubs, market places, and shopping 
centers in and around the city of Cambridge, UK. A stationary iMote was also placed
at the reception of the Computer Lab, in which most of the experiment participants 
are students.

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.

To evaluate the different content distribution schemes we
propose, we conducted an experiment in the city of Cambridge,
UK, in which 20 stationary devices equipped with a
Bluetooth contact logger were deployed at popular places. 
In addition to this, we deployed 40 similar contact loggers 
on a group of students from Cambridge University. Because 
we used Bluetooth technology, we gathered interactions
not only between the contact loggers, but also with
a large number of other Bluetooth enabled devices such as 
mobile phones or PDAs.

iMotes contacts were classified into two groups: iMotes recording the sightings 
of another iMotes are classified as "internal" contacts, while sightings of 
other types of Bluetooth devices are called "external" contacts. The external 
contacts are numerous and include anyone who has an active Bluetooth device 
in the vicinity of the iMote carriers, thereby providing a measure of actual
wireless networking opportunities present at the time.  The internal contacts, 
on the other hand, represent the data transfer opportunities that each of 
our participants would have, if they were equipped with devices which
are always-on and always-carried.

To protect participants privacy, we choose not to release the MAC address,
neither from the iMotes nor from other external devices recorded. Every
device is given a unique identifier, usually called ID number in this
document. Depending on which number, it might be an iMote or another MAC
address that were recorded from other active Bluetooth devices around.

[Traceset] upmc/content/imote (v. 2006-11-17)

top

the initial version

@MISC{upmc-content-imote-2006-11-17,
  author = {Jérémie 
Leguay and Anders Lindgren and James Scott and Timur Friedman and Jon Crowcroft and Pan Hui},
  title = {{CRAWDAD} trace set upmc/content/imote (v. 2006-11-17)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/upmc/content/imote},
  month = nov,  
  year = 2006
}
					

This traceset includes Bluetooth sightings by groups of users 
carrying small devices (iMotes) at 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 our experiment, iMotes were distributed to a group of people to collect
any opportunistic sighting of other Bluetooth devices (including the other
iMotes distributed). Each iMote scans on a periodic basis for devices,
asking them to respond with their MAC address, via the paging function.

It takes approximately 5 to 10s to perform the complete scanning. After
initial tests, we observe that most of the contacts were recorded with a
5s scanning time, and this value was used in the experiment.

The time granularity between two scanning is Ns. Later in this document,
the exact values we chose are given. It is important to avoid
synchronization of two iMotes around the same cycle clock, as each of them
cannot respond to any request when it is actively scanning. Therefore, we
implemented a random dephasing on [-12s;+12s] to handle this case.

2- skip-length sequence.

A contact "A sees B" is defined as a period of time where all
successive scanning by A receive a positive answer by B. Ideally an
information should be kept at the end of each contact period. 

After preliminary test it became quite clear that a very large number of
contact periods were only separated by one interval. We decided, to avoid
memory overflow, to implement a skip sequence of "one", meaning that a
contact period will only be stopped after two successive failure of a
scanning response. As a consequence, no inter-contact time of less than
two intervals could have been observed.

3- Manual Time synchronization.

Time between iMotes is not synchronized by a central entity, and traces
belonging to different devices bear times which are relative to the
starting time of each device. We recorded the time at which each iMote was
first powered up, which corresponds to time 0 at that iMote. After
collecting the data, we then converted all times into Unix timestamps
(seconds elapsed since 00:00:00 UTC, Jan 1, 1970).

4- Corrupted MAC address, and discarded mote.

As in the Haggle experiments, we observed that a number of MAC addresses
recorded were different from a known one only by one or two digit. They
were most of the time recorded once for a single time slot. It is clear
that at least a part of them comes for a corrupted signal received on the
link level by our devices. to ignore this artificial data, we implement
the following rule:

"Any MAC address that were recorded only once, for a single scanning (that
is, related with a unique contact, with length 1s), should be supposed
defective and ignored." We did not discard any iMotes in these data set.
We recommend to remove iMotes that were seen only one time for a contact
of length 1s.

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

[Trace] upmc/content/imote/cambridge (v. 2006-11-17)

top

the initial version

@MISC{upmc-content-imote-cambridge-2006-11-17,
  author = {Jérémie 
Leguay and Anders Lindgren and James Scott and Timur Friedman and Jon Crowcroft and Pan Hui},
  title = {{CRAWDAD} trace upmc/content/imote/cambridge (v. 2006-11-17)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/upmc/content/imote/cambridge},
  month = nov,  
  year = 2006
}
					

This trace includes Bluetooth sightings by groups of users carrying small devices (iMotes) 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] Jérémie Leguay

top

[Author] Anders Lindgren

top

[Author] James Scott

top

[Author] Timur Friedman

top

[Author] Jon Crowcroft

top

[Author] Pan Hui

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

top

Community is an important attribute of Pocket Switched Networks (PSN), because 
mobile devices are carried by people who tend to belong to communities. We 
analysed community structure from mobility traces and used for forwarding 
algorithms [12], which shows significant impact of community. Here, we propose 
and evaluate three novel distributed community detection approaches with great 
potential to detect both static and temporal communities. We find that with 
suitable configuration of the threshold values, the distributed community 
detection can approximate their corresponding centralised methods up to 90% 
accuracy.

[Paper] leguay-opportunistic

top

This paper investigates the feasibility of a city-wide content distribution 
architecture composed of short range wireless access points. We look at how a 
target group of intermittently and partially connected mobile nodes can improve 
the diffusion of information within the group by leveraging fixed and mobile 
nodes that are exterior to the group. The fixed nodes are data sources, and the 
external mobile nodes are data relays, and we examine the trade off between the 
use of each in order to obtain high satisfaction within the target group, which 
consists of data sinks. We conducted an experiment in Cambridge, UK, to gather 
mobility traces that we used for the study of this content distribution 
architecture. In this scenario, the simple fact that members of the target 
group collaborate leads to a delivery ratio of 90\%. In addition, the use of 
external mobile nodes to relay the information slightly increases the delivery 
ratio while significantly decreasing the delay.