CRAWDAD cambridge/inmotion

Citation Author(s):
Richard
Gass
Telefonica I+D
James
Scott
Christophe
Diot
Submitted by:
CRAWDAD Team
Last updated:
Tue, 11/14/2006 - 08:00
DOI:
10.15783/C7K592
License:
36 Views
Categories:
Keywords:
0
0 ratings - Please login to submit your rating.

Abstract 

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.

  • kismetWireless monitoring (kismet) trace for TCP transfer
    • configuration: These are the link layer traces captured by kismet
    • format: kismet
  • tcpdumptcpdump trace for TCP transfer
    • configuration: These are the tcpdumps of the traffic at the server and client
    • format: tcpdump
  • wirelessproc/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)

 

Instructions: 

The files in this directory are a CRAWDAD dataset hosted by IEEE DataPort. 

About CRAWDAD: the Community Resource for Archiving Wireless Data At Dartmouth is a data resource for the research community interested in wireless networks and mobile computing. 

CRAWDAD was founded at Dartmouth College in 2004, led by Tristan Henderson, David Kotz, and Chris McDonald. CRAWDAD datasets are hosted by IEEE DataPort as of November 2022. 

Note: Please use the Data in an ethical and responsible way with the aim of doing no harm to any person or entity for the benefit of society at large. Please respect the privacy of any human subjects whose wireless-network activity is captured by the Data and comply with all applicable laws, including without limitation such applicable laws pertaining to the protection of personal information, security of data, and data breaches. Please do not apply, adapt or develop algorithms for the extraction of the true identity of users and other information of a personal nature, which might constitute personally identifiable information or protected health information under any such applicable laws. Do not publish or otherwise disclose to any other person or entity any information that constitutes personally identifiable information or protected health information under any such applicable laws derived from the Data through manual or automated techniques. 

Please acknowledge the source of the Data in any publications or presentations reporting use of this Data. 

Citation:

Richard Gass, James Scott, Christophe Diot, cambridge/inmotion, https://doi.org/10.15783/C7K592 , Date: 20051001

 

Dataset Files

LOGIN TO ACCESS DATASET FILES
Open Access dataset files are accessible to all logged in  users. Don't have a login?  Create a free IEEE account.  IEEE Membership is not required.

Documentation

AttachmentSize
File cambridge-inmotion-readme.txt1.63 KB

These datasets are part of Community Resource for Archiving Wireless Data (CRAWDAD). CRAWDAD began in 2004 at Dartmouth College as a place to share wireless network data with the research community. Its purpose was to enable access to data from real networks and real mobile users at a time when collecting such data was challenging and expensive. The archive has continued to grow since its inception, and starting in summer 2022 is being housed on IEEE DataPort.

Questions about CRAWDAD? See our CRAWDAD FAQ. Interested in submitting your dataset to the CRAWDAD collection? Get started, by submitting an Open Access Dataset.