[Traceset] umich/virgil/eval_data (v. 2008-03-28)

top

the initial version.

@MISC{umich-virgil-eval_data-2008-03-28,
  author = {},
  title = {{CRAWDAD} trace set umich/virgil/eval_data (v. 2008-03-28)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umich/virgil/eval_data},
  month = mar,  
  year = 2008
}
					

We collected the trace set through war walking, i.e., collecting Wi-Fi beacons 
by walking around the neighborhoods in different cities in the United States, 
for the evaluation of Virgil, an access point selection system.

We briefly summarize our methodology here---for full details, please
refer to our paper: A.J. Nicholson et al., "Improved Access Point
Selection", in proceedings of MobiSys 2006.

We walked each neighborhood with a Compaq iPAQ that contained an
802.11 wireless card. Unlike for the field study data set, we did not
just periodically scan for available APs and test their
capabilities. The Virgil AP selection daemon periodically scanned and
tested APs to locate a usable AP, but once one was found, it stuck
with it until the iPAQ passed out of its radio range.

As a result, users of this dataset will notice significant gaps in
between scan sets. This is the time during which the device was
associated with an access point.

Note: due to a bug, all test results (AP frequency, signal strength,
et cetera) for APs using WEP encryption were mistakenly set to 0 when
Virgil wrote out the logs. This did not affect our results because
none of the algorithms in the evaluation attempted to use these 
encrypted, inaccessible APs. We regret, however, that this data on 
the link-layer properties of these encrypted APs is unavailable to the
user. We recommend the field study dataset for those who require such
data.

Also note that, unlike in the field study, the Virgil daemon caches 
test results for performance. Therefore, once a given AP is seen in a
neighborhood trace, when it is subsequently detected the
application-level tests are not re-run, but rather the cached test
results written out to the log.

[Trace] umich/virgil/eval_data/warwalk (v. 2008-03-28)

top

the initial version

@MISC{umich-virgil-eval_data-warwalk-2008-03-28,
  author = {},
  title = {{CRAWDAD} trace umich/virgil/eval_data/warwalk (v. 2008-03-28)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/umich/virgil/eval_data/warwalk},
  month = mar,  
  year = 2008
}
					

War-walking traceset collected in different cities in the United States for
the evaluation of an access point selection system.

For our evaluation, data was collected in five different
neighborhoods, of three different cities in the United States. All
timestamps in the datafiles are UTC, so the local times must be
calculated accordingly. Because daylight savings time was in effect,
Ann Arbor was UTC-4, Chicago UTC-5, and Seattle UTC-7.

Neighborhoods:

Chicago Loop (loop): the central business district. Data was collected
during the day on a busy workday (Tuesday, 19 July 2005, 3:30-4:35 pm
local time).

Chicago, Wicker Park (wkpk): a high-density residential neighborhood
northwest of downtown. Data collected on Monday, 18 July 2005,
7:40-9:13 am local time.

Chicago, Evanston (evanston): a suburb and college town, north of the
city limits. Data collected on Monday, 18 July 2005, 11:44 am to 3:20
pm.

Downtown Seattle (seattle): the central business district. Data was
collected on Wednesday, 20 July 2005, 7:18pm until 12:03am on July
21st (five hours later).

Ann Arbor, Michigan: the downtown area. Friday, 16 September 2005,
9:41-10:44 am.

For all three neighborhoods, we walked a roughly 1/2 square-mile (1.3
square-kilometer) area on the sidewalk (following the street grid
pattern).

The evaluation data in the eval_data directory. Inside each directory, 
the user will find a schema file, which describes in detail the format 
and proper interpretation of the data files in each dataset.

In the eval_data directory, for each of the five neighborhoods, we provide a
scansets.<neighborhood> file. This file consists of a series of scan
sets. A scan set is defined as the test results for a given set of
APs, whose AP beacons the Virgil daemon detected when searching for a
new AP at a given physical spot.

The first line of each scan set is of the form:

SCAN_SET 3 |2005-07-21_02:19:16.808727

where the "3" denotes this is the third scan set in the neighborhood's
trace, and the remainder of the line is the time instant (in UTC) at
which the scan occured.

The remainder of each scan set consists of a series of lines, where
each line corresponds to an AP in the scan set. Each line is a series
of comma-separated values comprising the test result for the AP in
question:

struct ap_db_entry {
       ssid,        AP SSID
       mac_addr,    AP MAC address
       encryption,  is WEP enabled? {ON,OFF} 
       linkquality, link quality, x/92, from iwconfig
       signallevel, signal level, -x dBm, from iwconfig
       noiselevel,  noise level, -x dBm, from iwconfig
       channel,     frequency (GHz) of the AP
       dhcpsuccess, did AP grant DHCP address? (yes=1, no=0)
       test_results optional test results (described below)
};

If the AP did not grant a DHCP address (dhcpsuccess==0), then the line
terminates with the dhcpsuccess parameter. Otherwise, the next item is
the round-trip-time (RTT) estimate in ms, then the bandwidth estimate
in bytes/sec. Finally, there is a sequence of tuples (port,status),
where port is a TCP port number, and status is one of {CLOSED=1,
OPEN=2, REDIRECTED=3}. Note that these constants are different than
those defined in the field study dataset.

Only the SSIDs and MAC addresses have been altered. Each MAC address
has been mapped from xx:xx:xx:xx:xx:xx format to a string of the form
mac:<neighborhood><uniqid> where uniqid is an increasing value
(starting at 0) for each neighborhood, determined by the order of
appearance in the trace of a given AP.

For example, if the 17th AP seen in the Wicker Park neighborhood had
the MAC address 01:02:03:04:05:06, wherever this value appears in all
log files, it would be replaced with the string "mac:wkpk:0016".

If you are interested in the actual MAC addresses (to determine the
popularity of various manufacturers' APs, for example) please contact
us. We can provide such aggregate information without disclosing
individual AP identities.

The anonymized SSIDs are not tied to AP mac address, because many
different APs often use the same mac address (linksys comes to
mind). Instead we use the 32-bit MD5 hash of each SSID string.