News

Join the CRAWDAD community

Reset your CRAWDAD account password

Datasets and tools by name

Datasets and tools by release date

Datasets and tools by keyword:

Datasets by measurement purpose:

About the CRAWDAD project

CRAWDAD sponsors

CRAWDAD contributors by country

CRAWDAD library (Zotero)

CRAWDAD FAQ

Privacy Policy

Contact Us

Related websites

 

 Search CRAWDAD via Google:

The pdx/metrofi dataset (v. 2011-10-24)  >  the 2007 traceset

There is 1 trace in this traceset
download the metrofi.tar.gz file
from a CRAWDAD mirror:  US UK
size="804KB" type="gz" md5="91389493d934d5365f1eb6a095298a0c"
last modified
2011-10-24
reason for most recent change
the initial version.
short description

Traceset of coverage and performance-related information of MetroFi, a 802.11x municipal wireless mesh network in Portland, Oregon in 2007.

description

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.

release date
2011-10-24
date/time of measurement start
2007-03-25
date/time of measurement end
2007-04-04
methodology

Because our tests were carried out without any access to the network infras- tructure, 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.

sanitization

We have performed no anonymization as there is no conceivable privacy/anonymity risk to anyone or anything.

 the pdx/metrofi/2007/coverage trace
 how to cite this traceset