[Dataset] ucdavis/unitrans (v. 2006-11-01)

top

the initial version

@MISC{ucdavis-unitrans-2006-11-01,
  author = {Jason LeBrun and Chen-Nee Chuah},
  title = {{CRAWDAD} data set ucdavis/unitrans (v. 2006-11-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/ucdavis/unitrans},
  month = nov,  
  year = 2006
}
					

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.

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.

[Traceset] ucdavis/unitrans/imote (v. 2006-11-01)

top

the initial version

@MISC{ucdavis-unitrans-imote-2006-11-01,
  author = {Jason LeBrun and Chen-Nee Chuah},
  title = {{CRAWDAD} trace set ucdavis/unitrans/imote (v. 2006-11-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/ucdavis/unitrans/imote},
  month = nov,  
  year = 2006
}
					

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

We 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/HaggleUnitrans

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

[Trace] ucdavis/unitrans/imote/Run1 (v. 2006-11-01)

top

the initial version

@MISC{ucdavis-unitrans-imote-Run1-2006-11-01,
  author = {Jason LeBrun and Chen-Nee Chuah},
  title = {{CRAWDAD} trace ucdavis/unitrans/imote/Run1 (v. 2006-11-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/ucdavis/unitrans/imote/Run1},
  month = nov,  
  year = 2006
}
					

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

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

[Trace] ucdavis/unitrans/imote/Run2 (v. 2006-11-01)

top

the initial version

@MISC{ucdavis-unitrans-imote-Run2-2006-11-01,
  author = {Jason LeBrun and Chen-Nee Chuah},
  title = {{CRAWDAD} trace ucdavis/unitrans/imote/Run2 (v. 2006-11-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/ucdavis/unitrans/imote/Run2},
  month = nov,  
  year = 2006
}
					

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

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

[Trace] ucdavis/unitrans/imote/Run3 (v. 2006-11-01)

top

the initial version

@MISC{ucdavis-unitrans-imote-Run3-2006-11-01,
  author = {Jason LeBrun and Chen-Nee Chuah},
  title = {{CRAWDAD} trace ucdavis/unitrans/imote/Run3 (v. 2006-11-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/ucdavis/unitrans/imote/Run3},
  month = nov,  
  year = 2006
}
					

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

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

[Author] Jason LeBrun

top

[Author] Chen-Nee Chuah

top

[Paper] lebrun-content

top

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