ucdavis/unitrans2006110122200611012007-03-01ucdavis/unitransBluetooth connectivity dataset collected on a bus system at UC Davis.

This data set includes several traces about the available Bluetooth connectivity during a typical day on the Unitrans bus system at University of California, Davis.

the initial version2006-11-012006-01-242006-03-039596http://www.bluespotting.org/Projects/HaggleUnitranshttp://www.crawdad.org/wiki/pmwiki.php?n=Main.Dataset.ucdavis-unitransBluetoothDTNvehicular networkContent Distribution EvaluationbluetoothDTN (Delay Tolerent Network)Wireless researchers have the problem of a lack of real-world mobility/connectivity data for doing simulation to evaluate various protocols, applications, and so on. The purpose of the experiment is to collect information about the available Bluetooth connectivity during a typical day on the Unitrans bus system at UC Davis.We equipped each bus with a small wireless sensor node (Intel iMote) to build a real public transit-centric network.We aimed to detect two buses that are close to each other, as well as any visible bluetooth devices that are used on the bus. Everytime an iMote sees another Bluetooth device (another iMote, or a cellphone/laptop/PDA with bluetooth capability), it logs the occurance, and for how long the other device was visible.34200611012007-03-01ucdavis/unitrans/imoteBluetooth connectivity traceset collected on a bus system at UC Davis.

We collected information about the available Bluetooth connectivity during a typical day on the Unitrans bus system at University of California, Davis.

the initial version2006-11-012006-01-242006-03-03Content Distribution EvaluationWe collected real-world data using Intel iMotes, which contain an ARM core as well as a Bluetooth radio stack. The motes run a simple Bluetooth inquiry program. Periodocally (e.g., every 2 minutes) the device does an inquiry for a duration (e.g., 5 seconds). All devices detected during this inquiry period are noted. These experiments give a list of contacts - with start and end times - that a particular mote has during its lifetime. For each experiment, the polling interval was 2 minutes, and the inquiry duration was 5 seconds.MACs are anonymized using a consistent hashing scheme.This data can also be found in SQLite3 database format, along with some Python tools for parsing the SQLite database. The tools are here: http://www.bluespotting.org/Projects/HaggleUnitransThere were some fixes to the data from the raw data obtained from the iMote: *Erroneous lines are omitted (if they don't contain 3 values) *Corrupted MAC addresses are dropped *Corrupted time values are dropped (less than 0) *The time base is adjusted after a reset to try and keep it approximately the same. *Corrupted MACs that ambiguously resolve to more than one mote are dropped *Corrupted MACs that resolve to exactly one mote by flipping one or two bits are fixed and kept. -Note: external device MACs may also be corrupted, but this is not accounted for./download/ucdavis/unitrans/unitrans.tar.gzucdavis/unitrans76200611012007-03-01ucdavis/unitrans/imote/Run1Trace of Bluetooth sightings by a group of students carrying the motes at UC Davis.

Trace of Bluetooth sightings by a group of students carrying the motes at UC Davis.

the initial versionfalse2006-11-012006-01-242006-01-27A student experiment that ran from Jan 24th, 2006 at 4:20pm until Jan 27th 2006 around noon. All of the students in a networking class carried the motes around during their day.The text files are named according the anonymized ID of the mote from which the data was collected. The format of the files is just a series of lines. Each line contains four values: <seen_vendor> <seen_id> <start> <end> <since_this> <since_any> Information about the fields: seen_vendor: vendor portion of MAC for the Bluetooth device seen in this contact. seen_id: anonymized device portion for the Bluetooth device seen in this contact. start: The start time for the contact (in seconds since boot) end: The end time for the contact (in seconds since boot) since_this: The amount of time passed since this mote last saw the device in this contact. since_any: The amount of time passed since this mote saw *any* other device before this contact. Some lines may contain all zeros. This indicates that a reset occurred between the previous line and the following line. The ramification of this is that for data collected after this time, we can no longer be sure about synchronization between this mote and the other motes.ucdavis/unitrans/imote77200611012007-03-01ucdavis/unitrans/imote/Run2Trace of Bluetooth connectivity experiment on the Unitrans bus system at UC Davis.

Trace of Bluetooth connectivity experiment on the Unitrans bus system at UC Davis.

the initial versionfalse2006-11-012006-01-302006-02-03The first bus run, on Jan 30th, 2006 until Feb 3rd, 2006. Each bus in the UC Davis Unitrans system received one mote near the front of the bus. Many motes ran until the end of the week, although some were dead when we collected them back.The text files are named according the anonymized ID of the mote from which the data was collected. The format of the files is just a series of lines. Each line contains four values: <seen_vendor> <seen_id> <start> <end> <since_this> <since_any> Information about the fields: seen_vendor: vendor portion of MAC for the Bluetooth device seen in this contact. seen_id: anonymized device portion for the Bluetooth device seen in this contact. start: The start time for the contact (in seconds since boot) end: The end time for the contact (in seconds since boot) since_this: The amount of time passed since this mote last saw the device in this contact. since_any: The amount of time passed since this mote saw *any* other device before this contact. Some lines may contain all zeros. This indicates that a reset occurred between the previous line and the following line. The ramification of this is that for data collected after this time, we can no longer be sure about synchronization between this mote and the other motes.ucdavis/unitrans/imote78200611012007-03-01ucdavis/unitrans/imote/Run3Trace of Bluetooth connectivity experiment on the Unitrans bus system at UC Davis.

Trace of Bluetooth connectivity experiment on the Unitrans bus system at UC Davis.

the initial versionfalse2006-11-012006-02-272006-03-03The second bus run, on Feb 27th, 2006 until March 3rd, 2006. An advertisement was placed on buses during this run, asking students to turn their Bluetooth radios on.The text files are named according the anonymized ID of the mote from which the data was collected. The format of the files is just a series of lines. Each line contains four values: <seen_vendor> <seen_id> <start> <end> <since_this> <since_any> Information about the fields: seen_vendor: vendor portion of MAC for the Bluetooth device seen in this contact. seen_id: anonymized device portion for the Bluetooth device seen in this contact. start: The start time for the contact (in seconds since boot) end: The end time for the contact (in seconds since boot) since_this: The amount of time passed since this mote last saw the device in this contact. since_any: The amount of time passed since this mote saw *any* other device before this contact. Some lines may contain all zeros. This indicates that a reset occurred between the previous line and the following line. The ramification of this is that for data collected after this time, we can no longer be sure about synchronization between this mote and the other motes.ucdavis/unitrans/imote95ucdavis/unitransJason LeBrunjblebrun@ece.ucdavis.eduElectrical and Computer EngineeringUniversity of California, Davis96ucdavis/unitransChen-Nee Chuahchuah@ece.ucdavis.eduElectrical and Computer EngineeringAssociate ProfessorUniversity of California, Davishttp://www.ece.ucdavis.edu/~chuahlebrun-contentJason LeBrunChen-Nee ChuahMobiShare '06: Proceedings of the 1st international workshop on Decentralized resource sharing in mobile computing and networking-09-200663-65

Los Angeles, California

Bluetooth, DTN, vehicular networhttp://doi.acm.org/10.1145/1161252.1161269In this poster, we introduce our Bluespots project, in which a small computer on a bus serves as a Bluetooth Content Distribution (BCD) station in a university public transit scenario. An important feature of the application space that we envision is that it depends only on single hops between devices. The primary form of communication will be between user mobile devices and Bluespots, or information waypoints. In later incarnations of this system, larger-scale dissemination can be achieved by using application-level peer-to-peer connections. However, we do not think of the system as a general data transit system. We consider it more as an implementation of social networking, in which users only participate in functions that are in line with their own interests and goals.wireless-meas,crawdadmeasurementwirelessucdavis_unitranscrawdaducdavis/unitrans20060001