CRAWDAD umich/virgil

We collected the data set through war walking, i.e., collecting Wi-Fi beacons by walking around the neighborhoods in different cities in the United States, for the field study and evaluation of Virgil, an access point selection system.last modified : 2008-03-31release date : 2008-03-28date/time of measurement start : 2005-04-28date/time of measurement end : 2005-09-16collection environment : 802.11 wireless LAN access points (APs) are increasingly widespread in urban areas, with users commonly finding multiple APs on each scan. Therefore, access point selection - determining which AP will provide the best quality of service - is a critical problem. We conducted a small field study to determine the scope of the problem of existing access point discovery and selection system. Armed with the lessons from the field study, we designed a new AP selection system, which we named Virgil. We release two main tracesets: results from a field study (umich/virgil/field_study), and results from the evaluation of our prototype implementation of Virgil (umich/virgil/eval_data).network configuration : For the field study, we walked a 1/2 square mile (1.3 square kilometer) grid of city streets with a PDA containing an 802.11 wireless card. The PDA ran Familiar Linux, a distribution targeted for handheld devices. We used a Compaq iPAQ handheld with an 802.11b wireless LAN card to collect data on the density and properties of different access points in an urban environment. For the evaluation study, we also used different hardware (a different iPAQ) for the evaluation runs than for the field study, due to equipment failure.data collection methodology : For the field study portion of our traces, data was collected in three different neighborhoods of Chicago, Illinois. For the evaluation, data was collected in five different neighborhoods, of three different cities in the United States. Please see the tracesets /umich/virgil/field_study and /umich/virgil/eval_data for the methodology details.sanitization : Only the SSIDs and MAC addresses have been altered. Each MAC address has been mapped to a string of the form mac: 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. mind). We use the 32-bit MD5 hash of each SSID string.Tracesetumich/virgil/field_studyWar-walking traceset collected in different neighborhoods of Chicago, Illinois for the field study of an access point selection system.description: We collected the traceset through war walking, i.e., collecting Wi-Fi beacons by walking around the neighborhoods of Chicago, Illinois for the field study of Virgil, an access point selection system.measurement purpose: Opportunistic Connectivitymethodology: 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. Our field study script repeatedly performed the following process. First, it scanned for AP beacons, then processed each detected AP in turn. For all APs, parameters such as AP MAC address, channel, encryption status, signal strength, et cetera were logged. Next, for AP not using encryption, the script attempted to receive an IP address from the AP via DHCP. The success of this operation was also logged. Finally, for APs that granted a DHCP address, the script ran a series of tests designed to probe the application-visible quality of the Internet connection provided by the AP. The script connected to a reference server at the University of Michigan to estimate the bandwidth and latency to an arbitrary Internet server, and the status (open, closed, or redirected) of 37 common TCP ports.umich/virgil/field_study Traceswarwalk: War-walking traces collected in Chicago, Illinois for the field study of an access point selection system.configuration: For the field study portion of our traces, data was collected in three different neighborhoods of Chicago, Illinois: The Loop (loop): the central business district. Data was collected during the day on a busy workday (Wednesday 4 May 2005, from 10:32 am to 3:47 pm). Wicker Park (wkpk): a high-density residential neighborhood northwest of downtown. Due to inclement weather, data was collected in two different sessions: Thursday 28 April 2005, from 3:40 pm to 5:04 pm, and Monday 2 May 2005, from 10:32 am to 11:40 am. Different areas of the neighborhood were probed on the two collection days, but the user will notice a small number of duplicate APs. We have kept the two traces separate simply for the benefit of CRAWDAD users who may want to draw conclusions from the timestamps in the traces. Evanston (evanston): a suburb and college town, north of the city limits. Data was collected on Thursday 5 May 2005, from 11:02 am to 12:49 pm. 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). For the case of Wicker Park, both days of mapping together cover a 1/2 square-mile area. This methodology was in no way intended to duplicate a realistic mobility pattern, but rather to simply "map-out" each neighborhood so one can draw conclusions in aggregate concerning the quality, availablity and deployment of wireless connectivity in each instance.format:The field study data are in the field_study subdirectory. Inside eachdirectory, the user will find a schema file, which describes in detailthe format and proper interpretation of the data files in each dataset.In the field_study directory, there are two data files for each collection run:trace.: human-readable trace output of the field study script.Keywords "APSCAN begin" and "APSCAN end" delineate theresults of a new scan for AP beacons. The test resultsof each AP are then presented in turn, separated bylines of "#####".ap_info.: comma-separated value file, one line per AP encounteredin the data collection session. The only informationnot present in this file that is in the trace.* fileare timestamps for all operations, and the informationon what groups of AP were discovered at the same time(in the same beacon scan set).Each line of data in the file maps to these values: struct ap_db_entry {ssid, AP SSIDmac_addr, AP MAC addressencryption, is WEP enabled? {ON,OFF}bitrate, Bitrate, in Mb/s, from iwconfiglinkquality, link quality, from iwconfigsignallevel, signal level, from iwconfignoiselevel, noise level, from iwconfigchannel, frequency (GHz) of the APdhcpsuccess, did AP grant DHCP address? (yes=1, no=0) /* Note: everything past this point is always 0 if* dhcpsuccess is 0 */ rtt, round-trip-time to reference server (ms)/* port tests: 0=closed, 1=open, 2=redirected */port_21, ftpport_22, sshport_23, telnetport_25, smtpport_79, fingerport_80, httpport_88, kerberosport_115, sftpport_119, nntpport_123, ntpport_135, rpcport_109, pop-2port_110, pop-3port_143, imap2port_194, ircport_201, appletalkport_369, codaport_443, httpsport_445, sambaport_389, ldapport_636, secure ldapport_750, kerberosport_993, secure imapport_994, secure ircport_995, secure pop3port_1080, socks proxyport_1214, kazaaport_1434, ms sql serverport_2049, nfsport_2430, venus (Coda)port_3306, mysqlport_5010, yahoo messengerport_5190, AOL instant messengerport_5680, cannaport_5800, vncport_6346, gnutellaport_7000, afs/* finally, the bandwidth value */bw, bandwidth to reference server (bytes/s)};The trace.* file can be considered the "primary source". We provide the ap_info.* files as a convenience to the user, so that each user of the data need not write the same script to parse out the most useful information.umich/virgil/eval_dataWar-walking traceset collected in different cities in the United States for the evaluation of an access point selection system.description: 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.measurement purpose: Opportunistic Connectivitymethodology: 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.umich/virgil/eval_data Traceswarwalk: War-walking traceset collected in different cities in the United States for the evaluation of an access point selection system.configuration: 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).format:The evaluation data in the eval_data directory. Inside each directory,the user will find a schema file, which describes in detail the formatand proper interpretation of the data files in each dataset.In the eval_data directory, for each of the five neighborhoods, we provide ascansets. file. This file consists of a series of scansets. A scan set is defined as the test results for a given set ofAPs, whose AP beacons the Virgil daemon detected when searching for anew 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.808727where the "3" denotes this is the third scan set in the neighborhood'strace, and the remainder of the line is the time instant (in UTC) atwhich the scan occured.The remainder of each scan set consists of a series of lines, whereeach line corresponds to an AP in the scan set. Each line is a seriesof comma-separated values comprising the test result for the AP inquestion:struct ap_db_entry {ssid, AP SSIDmac_addr, AP MAC addressencryption, is WEP enabled? {ON,OFF}linkquality, link quality, x/92, from iwconfigsignallevel, signal level, -x dBm, from iwconfignoiselevel, noise level, -x dBm, from iwconfigchannel, frequency (GHz) of the APdhcpsuccess, 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 lineterminates with the dhcpsuccess parameter. Otherwise, the next item isthe round-trip-time (RTT) estimate in ms, then the bandwidth estimatein 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 thanthose defined in the field study dataset.