[Dataset] nus/bluetooth (v. 2007-09-03)

top

the initial version

@MISC{nus-bluetooth-2007-09-03,
  author = {Vikram Srinivasan and Anirudh Natarajan and Mehul Motani},
  title = {{CRAWDAD} data set nus/bluetooth (v. 2007-09-03)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nus/bluetooth},
  month = sep,  
  year = 2007
}
					

This dataset contains Bluetooth contact traces collected in Singapore. 
12 contact probes-3 static and 9 mobile-collected data from end 2005 to early 2006. 
We discovered over 10,000 unique devices and recorded over 350,000 contacts 
in this duration.

The increasing sophistication of mobile devices has enabled
several mobile social software applications, which are based on opportunistic
exchange of data amongst devices in proximity of each other.
Examples include Delay Tolerant Networking (DTN) and PeopleNet. In
this context, understanding user interactions is essential to designing
algorithms which are efficient and enhance the user experience. In our
experiment, users were handed Bluetooth enabled phones and asked to
carry them all the time to log information about other devices in their
proximity. Data was logged over several months, with over 350,000 contacts
logged and over 10,000 unique devices discovered in this period.

We chose phones instead of iMotes, since phones are personal devices 
that people already have a reason to carry around. This meant that 
users would remember to recharge the phones and always carry it with
them over long durations (months). Further, mobile phones have more than
6MB of memory whereas iMotes have only 64KB.

Having narrowed down the choice, we picked Nokia 6600 and Panasonic X800
phones as they were the most reliable. In particular, HP PDA's and Sony 
Ercisson's consistently logged fewer devices than the former two devices 
under identical conditions.

The phones and the static devices conducted Bluetooth device discoveries
every 30 seconds and logged the MAC addresses, the date and the time when the
device was found. The static devices were programmed to upload their data to
a central MySQL server once every day. The mobile probes had to transfer their
data by activating a program on their computers that would then automatically
transfer the data from the PC to the central server.

To allow us to get a wide variety of data we chose 12 probes. Of these 3
were static and 9 were mobile. The static devices were customized, line powered,
Bluetooth access points running on embedded Linux and these were placed in
three of the busiest lecture theaters on National University of Singapore campus.
The 9 mobile probes were chosen to get as diverse a sampling of various social
behavior patterns. 5 students on campus, 2 faculty members and 2 students
who lived off campus carried mobile phones with the software that logged the
Bluetooth device discoveries.

[Traceset] nus/bluetooth/sql (v. 2007-09-03)

top

the initial version.

@MISC{nus-bluetooth-sql-2007-09-03,
  author = {Vikram Srinivasan and Anirudh Natarajan and Mehul Motani},
  title = {{CRAWDAD} trace set nus/bluetooth/sql (v. 2007-09-03)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nus/bluetooth/sql},
  month = sep,  
  year = 2007
}
					

This traceset contains Bluetooth contact traces collected in Singapore. 
12 contact probes-3 static and 9 mobile-collected data from end 2005 to early 2006. 
We discovered over 10,000 unique devices and recorded over 350,000 contacts 
in this duration.

To allow us to get a wide variety of data we chose 12 probes. Of these 3
were static and 9 were mobile. The static devices were customized, line powered,
Bluetooth access points running on embedded Linux and these were placed in
three of the busiest lecture theaters on National University of Singapore campus.
The 9 mobile probes were chosen to get as diverse a sampling of various social
behavior patterns. 5 students on campus, 2 faculty members and 2 students
who lived off campus carried mobile phones with the software that logged the
Bluetooth device discoveries. 

After collecting the data we did realize that our choices did give us a varied 
set of behaviors. As expected, the 2 students living off campus logged the most 
contacts, logging around 170 distinct devices for every man day logged. 
Interestingly, the static probes discovered the least number of distinct devices 
per day. The maximum was 13.2 distinct devices per day. This clearly highlights 
the importance of mobility to increasing the potential for opportunistic data 
relay algorithms.

The main challenge faced in collecting the data was the finite battery life.
Due to Bluetooth device discovery being an energy consuming process, phones
would run out of power and the logging would stop. Often phones needed to be
recharged every day in order to log continuously. 

Despite our persistent attempts to remind the probes to keep the
logging program switched on at all times, the participants had a tendency 
to switch it on in crowded areas which skewed the data. The logging program 
would also crash from time to time. This error could occur a few minutes or 
a few days after the logging program was switched on. Despite our best efforts 
we were unable to avoid this error which seems to have originated from 
the OS of the phone. On some of the phones when the program crashed an audible 
beep was made which reminded volunteers to turn on the program.

Due to the format in which the data was logged we were unable to ascertain
the exact times for the occurence of these errors. However, we estimate from
our data that on average the mobile probes were not logging for 24.5% of the
time. From interviews with our probes, these outages seem to have been random
and uniformly distributed over time. While we did miss potential contacts, our
logs clearly mark the beginning and ending of any period when logging was
performed. During these periods all potential contacts were recorded.

We anonymized the 'Address' field and 'Person' field 
by using the MD5 checksum function provided by MySQL.

[Trace] nus/bluetooth/sql/anon_logdata (v. 2007-09-03)

top

the initial version

@MISC{nus-bluetooth-sql-anon_logdata-2007-09-03,
  author = {Vikram Srinivasan and Anirudh Natarajan and Mehul Motani},
  title = {{CRAWDAD} trace nus/bluetooth/sql/anon_logdata (v. 2007-09-03)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/nus/bluetooth/sql/anon_logdata},
  month = sep,  
  year = 2007
}
					

These Bluetooth contact traces were collected in Singapore with 
12 contact probes - 3 static and 9 mobile from end 2005 to early 2006.

The table 'anon_logdata' stores the information logged over a few months 
by over 9 mobile users and 3 static devices. Bluetooth scans were conducted 
every 30 seconds by the devices and the device addresses found, the date and 
time they were found were logged.

The static devices were line powered and were logging at all times. The
phones given to mobile users were switched on and off by their users and hence
we have the notion of search and session numbers. Everytime the user switches
on the logging program a new session is started. The session ends when the
logging program switches off. In every session, everytime the device scans the
environment for other Bluetooth devices the search number is incremented. The
search number at the beginning of every session is 1.

The following are the fields in the table anon logdata.
- index: This field is the primary key for the table.
- Address: This is the address of the Bluetooth devices found. Note that
the address '000000000000' is a dummy address and is used to denote
the beginning of every session. The address 'FFFFFFFFFFFF' is also a
dummy address and is used to denote the time when the session is ended.
However, some sessions do not have this record due to the logging program
crashing.
- Time: Time of the log
- Date: Date of the log
- Day: Day of the log
- Search: Bluetooth scan in a particular at which the device was found.
Value is 0 for all static devices.
- Session: Session number for the user. Value is 0 for all static devices.
- Person: The id of the device conducting the logs. Static devices are denoted
by the 'AxisBoard' prefix.

We anonymized the 'Address' field and 'Person' field 
by using the MD5 checksum function provided by MySQL.

[Author] Vikram Srinivasan

top

[Author] Anirudh Natarajan

top

[Author] Mehul Motani

top

[Paper] natarajan-bluetooth

top

The increasing sophistication of mobile devices has enabled several mobile 
social software applications, which are based on opportunistic exchange of data 
amongst devices in proximity of each other. Examples include Delay Tolerant 
Networking (DTN) and PeopleNet. In this context, understanding user 
interactions is essential to designing algorithms which are efficient and 
enhance the user experience. In our experiment, users were handed Bluetooth 
enabled phones and asked to carry them all the time to log information about 
other devices in their proximity. Data was logged over several months, with 
over 350,000 contacts logged and over 10,000 unique devices discovered in this 
period.1 This paper analyzes this data by charactering the distributions of 
metrics such as contact time and inter-pair-contact time, and introducing 
several other important metrics useful for understanding user interactions. We 
find that most metrics follow a power law, except for inter-pair-contact time. 
We also look for patterns in user interactions, with the hope that these can be 
exploited for better algorithm design.

[Paper] wang-adaptive

top

In many delay tolerant applications, information is opportunistically exchanged 
between mobile devices who encounter each other. In order to effect such 
information exchange, mobile devices must have knowledge of other devices in 
their vicinity. We consider scenarios in which there is no infrastructure and 
devices must probe their environment to discover other devices. This can be an 
extremely energy consuming process and highlights the need for energy conscious 
contact probing mechanisms. If devices probe very infrequently, they might miss 
many of their contacts. On the other hand, frequent contact probing might be 
energy inefficient. In this paper, we investigate the trade-off between the 
probability of missing a contact and the contact probing frequency. First, via 
theoretical analysis, we characterize the trade-off between the probability of 
a missed contact and the contact probing interval for stationary processes. 
Next, for time varying contact arrival rates, we provide an optimization 
framework to compute the optimal contact probing interval as a function of the 
arrival rate. We characterize real world contact patterns via Bluetooth phone 
contact logging experiments and show that the contact arrival process is 
self-similar. We design STAR, a contact probing algorithm which adapts to the 
contact arrival process. Via trace driven simulations on our experimental data, 
we show that STAR consumes three times less energy when compared to a constant 
contact probing interval scheme.