CRAWDAD dataset nus/bluetooth (v.2007-09-03)

download the Anonymized_BT_Logs_20070903_1833.sql.gz file: from a CRAWDAD mirror: US UK
size="3.9MB" type="gz" md5="88ceea1702e96e4c70934f235df1440c"

last modified

2007-12-04

reason for most recent change

the initial version.

short description

Traceset of Bluetooth contact traces collected in Singapore from end 2005 to early 2006.

description

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.

release date

2007-09-03

date/time of measurement start

2005-10-31

date/time of measurement end

2006-06-21

methodology

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.

disruptions to data collection

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.

sanitization

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

the nus/bluetooth/sql/anon_logdata trace

last modified

2007-12-04

reason for most recent change

the initial version

short description

Bluetooth contact traces collected in Singapore from end 2005 to early 2006.

description

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

derived

false

release date

2007-09-03

date/time of measurement start

2005-10-31

date/time of measurement end

2006-06-21

configuration

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.

format of trace data

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.

sanitization

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

how to cite this traceset