[Dataset] cambridge/inmotion (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} data set cambridge/inmotion (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion},
  month = oct,  
  year = 2005
}
					

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

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.

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.

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] cambridge/inmotion/tcp (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-tcp-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace set cambridge/inmotion/tcp (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/tcp},
  month = oct,  
  year = 2005
}
					

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

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.

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)

[Traceset] cambridge/inmotion/udp (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-udp-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace set cambridge/inmotion/udp (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/udp},
  month = oct,  
  year = 2005
}
					

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

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.

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)

[Traceset] cambridge/inmotion/web (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-web-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace set cambridge/inmotion/web (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/web},
  month = oct,  
  year = 2005
}
					

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

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 web traffic (HTTP over TCP), we used the Apache
web server with a cache of 6 popular websites1 (including
embedded objects), and used a web crawler to download the
web pages (again including embedded objects) in a cycle.

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.

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: 
- web-bw-delay: bandwidth limit and delay applied 
- web-bw: only bandwidth limit applied
- web-delay: only delay applied
- web: neither bandwidth limit nor delay applied
TRACE: (see description of each trace)
- dadate 
- wireless
- tcpdump
- dump (kismet trace)

[Trace] cambridge/inmotion/tcp/dadate (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-tcp-dadate-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/tcp/dadate (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/tcp/dadate},
  month = oct,  
  year = 2005
}
					

Key press trace for TCP transfer

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.

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.

[Trace] cambridge/inmotion/tcp/kismet (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-tcp-kismet-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/tcp/kismet (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/tcp/kismet},
  month = oct,  
  year = 2005
}
					

Wireless monitoring (kismet) trace for TCP transfer

These are the link layer traces captured by kismet

kismet

[Trace] cambridge/inmotion/tcp/tcpdump (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-tcp-tcpdump-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/tcp/tcpdump (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/tcp/tcpdump},
  month = oct,  
  year = 2005
}
					

tcpdump trace for TCP transfer

These are the tcpdumps of the traffic at the server and client.

tcpdump

[Trace] cambridge/inmotion/tcp/wireless (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-tcp-wireless-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/tcp/wireless (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/tcp/wireless},
  month = oct,  
  year = 2005
}
					

/proc/wireless trace for TCP transfer

This was a cat of /proc/wireless every second

output of /proc/wireless

[Trace] cambridge/inmotion/udp/dadate (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-udp-dadate-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/udp/dadate (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/udp/dadate},
  month = oct,  
  year = 2005
}
					

Key press trace for UDP transfer

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.

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.

[Trace] cambridge/inmotion/udp/kismet (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-udp-kismet-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/udp/kismet (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/udp/kismet},
  month = oct,  
  year = 2005
}
					

Wireless monitoring (kismet) trace for UDP transfer

These are the link layer traces captured by kismet

kismet

[Trace] cambridge/inmotion/udp/tcpdump (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-udp-tcpdump-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/udp/tcpdump (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/udp/tcpdump},
  month = oct,  
  year = 2005
}
					

tcpdump trace for UDP transfer

These are the tcpdumps of the traffic at the server and client.

tcpdump

[Trace] cambridge/inmotion/udp/wireless (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-udp-wireless-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/udp/wireless (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/udp/wireless},
  month = oct,  
  year = 2005
}
					

/proc/wireless trace for UDP transfer

This was a cat of /proc/wireless every second

output of /proc/wireless

[Trace] cambridge/inmotion/web/dadate (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-web-dadate-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/web/dadate (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/web/dadate},
  month = oct,  
  year = 2005
}
					

Key press trace for WEB transfer

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.

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.

[Trace] cambridge/inmotion/web/kismet (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-web-kismet-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/web/kismet (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/web/kismet},
  month = oct,  
  year = 2005
}
					

Wireless monitoring (kismet) trace for WEB transfer

These are the link layer traces captured by kismet

kismet

[Trace] cambridge/inmotion/web/tcpdump (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-web-tcpdump-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/web/tcpdump (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/web/tcpdump},
  month = oct,  
  year = 2005
}
					

tcpdump trace for WEB transfer

These are the tcpdumps of the traffic at the server and client.

tcpdump

[Trace] cambridge/inmotion/web/wireless (v. 2005-10-01)

top

the initial version

@MISC{cambridge-inmotion-web-wireless-2005-10-01,
  author = {Richard Gass and James Scott and Christophe Diot},
  title = {{CRAWDAD} trace cambridge/inmotion/web/wireless (v. 2005-10-01)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/inmotion/web/wireless},
  month = oct,  
  year = 2005
}
					

/proc/wireless trace for WEB transfer

This was a cat of /proc/wireless every second

output of /proc/wireless

[Author] Richard Gass

top

[Author] James Scott

top

[Author] Christophe Diot

top

[Paper] gass-in-motion

top

[Paper] gass-in-motion-tr

top

Wireless networking can support in-motion users by providing occasional 
opportunities to transmit and receive data. We measure the performance of UDP 
and TCP transfers between a car traveling at speeds from 5 mph to 75 mph, and 
an 802.11b access point. We analyze the impact of bandwidth and delay 
limitations in the backhaul network on the feasibility of in-motion transfer 
with typical Internet applications. We observe that in interference-free 
environments, a significant amount of data can be transferred using 
off-the-shelf equipment. We find that performance suffers mostly from network 
or application related problems instead of wireless link issues, i.e., 
protocols with handshakes, bandwidth limitations, and long round-trip times.

[Paper] hadaller-multi-vehicular

top

When a roadside 802.11-based wireless access point is shared by more than one 
vehicle, the vehicle with the lowest transmission rate reduces the effective 
transmission rate of all other vehicles. This performance anomaly degrades both 
individual and overall throughput in such multi-vehicular environments. 
Observing that every vehicle eventually receives good performance when it is 
near the access point, we propose MV-MAX (Multi-Vehicular Maximum), a medium 
access protocol that opportunistically grants wireless access to vehicles with 
the maximum transmission rate. Mathematical analysis and trace-driven 
simulations based on real data show that MV-MAX not only improves overall 
system throughput, compared to 802.11, by a factor of almost 4, but also 
improves on the previously proposed time-fairness scheme by a factor of more 
than 2. Moreover, despite being less fair than 802.11, almost every vehicle 
benefits by using MV-MAX over the more equitable 802.11 access mechanism. 
Finally, we show that our results are consistent across different data sets.