CRAWDAD cambridge/inmotion

Dataset of UDP and TCP transfers between a moving car and an 802.11b access point.

Dataset of UDP and TCP transfers between a car traveling at speeds from 5 mph to 75 mph, and an 802.11b access point.

date/time of measurement start: 2005-03-14

date/time of measurement end: 2005-03-25

collection environment: We present measurements from a study of 802.11b networking involving a user in a moving car and a wireless access point (AP). These measurements have been realized in the California desert, a radio interference-free environment (i.e., in absence of 802.11 or other conventional wireless networking signals), in order to be able to understand what networking parameter caused the performance observed.

network configuration: The client is an IBM Thinkpad T41 with integrated Intel Pro/Wireless 2915ABG wireless adaptor. The client communicates with a Linksys WAP55AG access point operating on channel 1 in 802.11b mode only. The APs WAN port is wired to a laptop modeling the backhaul network. That laptop featured an IBM Thinkpad T30 with one built-in ethernet adaptor and one PCMCIA ethernet adaptor. The T30's other ethernet adaptor is connected to the server, an IBM Thinkpad T42. Both the client and server are also equipped with a PCMCIA Netgear WAG511 802.11 wireless adaptor used for network monitoring only. We considered using DHCP, but Ott and Kutscher's analysis showed highly variable performance due to slow retransmission timers. Therefore, we decided to use preset IP addresses for all machines.  The hardware above was chosen to be typical of that used by real users. No external high-gain antennae were used on the clients or the access point, and default link layer parameters were always used. 

The software configuration is as follows. All machines used the Fedora Core 3 Linux distribution, with the default 2.6 Linux kernel. UDP traffic is generated using a bash shell script and the /dev/udp interface. iperf is used to generate the TCP bulk traffic, while the web traffic is generated using the wget program on the client and Apache httpd on the server. The backhaul computer used the Linux tc program with the netem module to implement the bandwidth and delay models.

data collection methodology: The AP is placed at the side of the road on a 160 cm tripod. A GPS unit with reported accuracy of two meters was used to mark the road 500m (well out of AP range) either side of the AP with paint and signs. Each test begins with the client computer on the lap of the passenger in the car well beyond the 500m distance, at which point the test scripts are started and the car comes up to and maintains the target speed. As it passes the first 500m mark, the enter key is pressed on the client causing a timestamp to be recorded. When the client comes into range it automatically associates and begins sending test traffic. As the car passes the end 500m mark, the enter key is pressed again, causing another timestamp to be recorded. We chose to use keypresses for timing instead of GPS for convenience and because the operator can clearly see the sign approaching and time the keypress accurately enough. Even if GPS was used, it would not guarantee the accuracy of the measurements because of the two meter reported accuracy in our unit.

Experimental data is logged in two ways. We generate a tcpdump log on the active network interfaces of both the client and the server. In addition, we used the kismet wireless network monitoring tool at the client and the server to obtain link-layer traces.

Traceset

tcp

Traceset of TCP transfers between a car traveling at speeds from 5 mph to 75 mph, and an 802.11b access point.

• file: sd_experiments_alltcp.tar.gz
• measurement purpose: Network Performance Analysis
• methodology: We used six car speeds: 5, 15, 25, 35, 55 and 75 mph. This target speed served as a guide for the driver. We also measured the average speed by timing the car over the measured test range distance. For TCP bulk traffic (simulating FTP file transfers), a stream of data was sent using 1500 byte packets. We also simulated the effect of the backhaul network, i.e., the network path between the AP and the server. We tested two parameters: a 1 Mbit/s bandwidth limit (simulating a typical DSL access network), and a 100ms latency each way (simulating an inter-continental network path). We tested these effects both separately and together.

note: File names are as follows:

{SS}mph-day{D}.{client/server}.ap.{TRAFFIC_TYPE}.{timestamp}.{TRACE}

VV: car speed,

D: day number (1, 2, 3, or 4),

TRAFFIC_TYPE: 

- tcp-bw-delay: bandwidth limit and delay applied 

- tcp-bw: only bandwidth limit applied

- tcp-delay: only delay applied

- tcpbulk: neither bandwidth limit nor delay applied

TRACE: (see description of each trace)

- dadate 

- wireless

- tcpdump

- dump (kismet trace)

tcp Traces 

• dadate: Key press trace for TCP transfer
• configuration: This file contains the keypresses from the experiment. The AP is placed at the side of the road on a 160 cm tripod. A GPS unit with reported accuracy of two meters was used to mark the road 500m (well out of AP range) either side of the AP with paint and signs. Each test begins with the client computer on the lap of the passenger in the car well beyond the 500m distance, at which point the test scripts are started and the car comes up to and maintains the target speed. As it passes the first 500m mark, the enter key is pressed on the client causing a timestamp to be recorded. When the client comes into range it automatically associates and begins sending test traffic. As the car passes the end 500m mark, the enter key is pressed again, causing another timestamp to be recorded. We chose to use keypresses for timing instead of GPS for convenience and because the operator can clearly see the sign approaching and time the keypress accurately enough. Even if GPS was used, it would not guarantee the accuracy of the measurements because of the two meter reported accuracy in our unit.
• format: The ones of interest are the second, last, and second to last.

    The first entry is the starttime of the experiment.

    The second is when we actually crossed the 1000M start marker.

    The second to last is when we crossed the 1000M end marker.

    And finally, the last is when the experiment ended.

    Any timestamps in the middle represent other indicators that may have a description next to them (e.g.  When a  car passed us).

    However, we did not enforce this rule of logging information.

• kismet: Wireless monitoring (kismet) trace for TCP transfer
• configuration: These are the link layer traces captured by kismet
• format: kismet
• tcpdump: tcpdump trace for TCP transfer
• configuration: These are the tcpdumps of the traffic at the server and client
• format: tcpdump
• wireless: proc/wireless trace for TCP transfer
• configuration: This was a cat of /proc/wireless every second
• format: output of /proc/wireless

udp 

Traceset of UDP transfers between a car traveling at speeds from 5 mph to 75 mph, and an 802.11b access point. 

• file: sd_experiments_alludp.tar.gz
• measurement purpose: Network Performance Analysis
• methodology: We used six car speeds: 5, 15, 25, 35, 55 and 75 mph. This target speed served as a guide for the driver. We also measured the average speed by timing the car over the measured test range distance. To test UDP, we used a stream of data consisting of successive UDP packets with sizes 50, 100, 200, 400, 800 and 1500 bytes. This allowed us to study the effects of packet size on in-motion wireless transfers.

note: File names are as follows:

File names are as follows:

{SS}mph-day{D}.{client/server}.ap.udp.{timestamp}.{TRACE}

VV: car speed,

D: day number (1, 2, 3, or 4),

TRACE: (see description of each trace)

- dadate 

- wireless

- tcpdump

- dump (kismet trace)