CRAWDAD nus/bluetooth

Dataset of Bluetooth contact traces collected in Singapore from end 2005 to early 2006.This is a dataset of real-world Bluetooth contact data colected from shop employees of a shopping mall over six days.

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.

date/time of measurement start: 2005-10-31

date/time of measurement end: 2006-06-21

collection environment: 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.

network configuration: 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.

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

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

Traceset

nus/bluetooth/sql

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

• file: Anonymized_BT_Logs_20070903_1833.sql.gz
• 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.
• measurement purpose: User Mobility Characterization, Human Behavior Modeling, Energy-efficient Wireless Network

nus/bluetooth/sql Trace

• anon_logdata: These Bluetooth contact traces were collected in Singapore with 12 contact probes - 3 static and 9 mobile from end 2005 to early 2006.
• 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: 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.