CRAWDAD pdx/metrofi

Dataset of coverage and performance-related information of MetroFi, a 802.11x municipal wireless mesh network in Portland, Oregon in 2007.This is a dataset of location, signal strength, and performance data of MetroFi, a 802.11x municipal wireless mesh network in Portland, Oregon in 2007. The data was collected by Caleb Phillips and Russell Senior to determine the coverage and performance of the network.date/time of measurement start: 2007-03-25date/time of measurement end: 2007-04-04collection environment: The data was collected during an independent analysis of MetroFi, the municipal wireless network in Portland, Oregon.network configuration: This dataset was collected with a Linux-based sniffer using a Kismet instance configured to channel hop on all 11 channels. The wireless interface was an Atheros chipset using the madwifi driver. The 72 functional APs were located using triangulation and then fine-tuned with a hand-held GPS device. All measurements are passive, with no special access to the network.data collection methodology: We use the standard Unix tools ttcp to test upstream throughput, ICMP ping to test latency and loss, and wget to test downstream throughput. A small script was used to bypass advertisement traps. We also found it necessary to use several watchdog scripts to check for a lost association, GPS issues, and stalled tests. Depending on the results, a random location test might take anywhere from about 60 seconds (the length of time we would wait for an association) to around 7 minutes. We also recorded GPS position and timestamp throughout the test. The results of each test were stored on the USB storage device. At the conclusion of the tests we retrieved and analyzed the results.Tracesetpdx/metrofi/2007Traceset of coverage and performance-related information of MetroFi, a 802.11x municipal wireless mesh network in Portland, Oregon in 2007.file: metrofi.tar.gzdescription: This is a traceset of location, signal strength, and performance data of MetroFi, a 802.11x municipal wireless mesh network in Portland, Oregon in 2007. The data was collected by Caleb Phillips and Russell Senior to determine the coverage and performance of the network.measurement purpose: Network Performance Analysismethodology: Because our tests were carried out without any access to the network infrastructure, our first task was to locate the access points in the POC area. To this end, we drove to every publicly accessible street, collecting signal strength measurements using a battery-powered embedded computer with an external 7 dBi omnidirectional antenna and a GPS device. We used this data to triangulate the position of the APs. Not surprisingly, as other researchers have shown that signal strength is poorly correlated with distance, we were unable to reach a satisfactory level of precision. To obtain the desired precision, we used triangulation information to locate each AP and then took a reading with a hand-held GPS device directly under the AP. From the list of 72 MetroFi access points that we considered to be in the POC network, we constructed a bounding box in latitude and longitude extending 1000 feet beyond the extremities of the access point locations. Because we expected that many locations in the bounding box would fall outside of the POC areas, and because we were not certain how many locations we would be able to measure, we computed an excessive sample of 1001 locations using a random number generator such that each location in the bounding box had an equal probability of being chosen. Locations not within 1000 feet of an access point were immediately excluded. Each remaining location was plotted against orthoimagery using Google Maps. If the location fell in the Willamette River, was inside a building, or was not practically reachable, it was also excluded. Ultimately, the first 250 locations in our sample of 1001 were either excluded on the basis of the criteria above or were visited and measured. We chose to stop at 250 points after finding that this well bypassed our needs in terms of statistical power, both in the POC and overall. We use the standard Unix tools ttcp to test upstream throughput, ICMP ping to test latency and loss, and wget to test downstream throughput. A small script was used to bypass advertisement traps. We also found it necessary to use several watchdog scripts to check for a lost association, GPS issues, and stalled tests (for example, ttcp has a tendency take a very long time on unstable connections). Depending on the results, a random location test might take anywhere from about 60 seconds (the length of time we would wait for an association) to around 7 minutes. In addition to these steps, we also recorded GPS position and timestamp throughout the test.pdx/metrofi/2007 Tracecoverage: Trace of coverage and performance-related information of MetroFi, a 802.11x municipal wireless mesh network in Portland, Oregon in 2007. This is a trace of location, signal strength, and performance data of MetroFi, a 802.11x municipal wireless mesh network in Portland, Oregon in 2007.configuration: This dataset was collected with a Linux-based sniffer using a Kismet instance configured to channel hop on all 11 channels. The wireless interface was an Atheros chipset using the madwifi driver. The 72 functional APs were located using triangulation and then fine-tuned with a hand-held GPS device. All measurements are passive, with no special access to the network. We use the standard Unix tools ttcp to test upstream throughput, ICMP ping to test latency and loss, and wget to test downstream throughput. A small script was used to bypass advertisement traps. We also found it necessary to use several watchdog scripts to check for a lost association, GPS issues, and stalled tests. Depending on the results, a random location test might take anywhere from about 60 seconds (the length of time we would wait for an association) to around 7 minutes. We also recorded GPS position and timestamp throughout the test.format: Besides the README file, there are three pieces of data:1) aps.txt: Locations and MAC addresses of APs 2) stumble_filtered.txt: Received signal strength indicator (RSSI) observations of the APs from the exhaustive war-driving campaign in the network's service area. To turn RSSI into something like Received Signal Strength (RSS) in dBm, simply subtract 95. 3) random.csv: Performance results at a random sample of points within the  coverage area. The fields are listed on the first line.