data/20080328174200803282008-03-31the initial versionumich/virgil/eval_data/warwalkWar-walking traceset collected in different cities in the United States for the evaluation of an access point selection system.

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

false2008-03-282005-07-182005-09-16For 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.umich/virgil/eval_data