cambridge/inmotion200510018200510012006-11-14cambridge/inmotionDataset 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.the initial version2006-02-012005-03-142005-03-25151418http://www.cambridge.intel-research.net/~rgass/projects/inmotion/http://www.crawdad.org/wiki/pmwiki.php?n=Main.Dataset.cambridge-inmotionvehicular network802.11802.11bGPSpacket tracetcpdumpNetwork Performance Analysis802.11 infrastructureWe 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.12200510012006-11-14cambridge/inmotion/tcpTraceset of TCP transfers between a moving car and an 802.11b access point.Traceset of TCP transfers between a car traveling at speeds from 5 mph to 75 mph, and an 802.11b access point.the initial version2006-02-012005-03-142005-03-25Network Performance AnalysisWe 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)/download/cambridge/inmotion/sd_experiments_alltcp.tar.gzcambridge/inmotion25200510012006-11-14cambridge/inmotion/tcp/dadateKey press trace for TCP transfer.Key press trace for TCP transferthe initial versionfalse2006-02-012005-03-142005-03-25This 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.cambridge/inmotion/tcp26200510012006-11-14cambridge/inmotion/tcp/kismetWireless monitoring (kismet) trace for TCP transfer.Wireless monitoring (kismet) trace for TCP transfer.the initial versionfalse2006-02-012005-03-142005-03-25These are the link layer traces captured by kismetkismetcambridge/inmotion/tcp27200510012006-11-14cambridge/inmotion/tcp/tcpdumptcpdump trace for TCP transfer.tcpdump trace for TCP transfer.the initial versionfalse2006-02-012005-03-142005-03-25These are the tcpdumps of the traffic at the server and client.tcpdumpcambridge/inmotion/tcp28200510012006-11-14cambridge/inmotion/tcp/wireless/proc/wireless trace for TCP transfer./proc/wireless trace for TCP transfer.the initial versionfalse2006-02-012005-03-252005-03-25This was a cat of /proc/wireless every secondoutput of /proc/wirelesscambridge/inmotion/tcp22200510012006-11-14cambridge/inmotion/udpTraceset of UDP transfers between a moving car and an 802.11b access point.Traceset of UDP transfers between a car traveling at speeds from 5 mph to 75 mph, and an 802.11b access point.the initial version2006-02-012005-03-252005-03-25Network Performance AnalysisWe 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)/download/cambridge/inmotion/sd_experiments_alludp.tar.gzcambridge/inmotion29200510012006-11-14cambridge/inmotion/udp/dadateKey press trace for UDP transfer.Key press trace for UDP transfer.the initial versionfalse2006-02-012005-03-142005-03-25This 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.cambridge/inmotion/udp30200510012006-11-14cambridge/inmotion/udp/kismetWireless monitoring (kismet) trace for UDP transfer.Wireless monitoring (kismet) trace for UDP transfer.the initial versionfalse2006-02-012005-03-252005-03-25These are the link layer traces captured by kismetkismetcambridge/inmotion/udp31200510012006-11-14cambridge/inmotion/udp/tcpdumptcpdump trace for UDP transfer.tcpdump trace for UDP transfer.the initial versionfalse2006-02-012005-03-252005-03-25These are the tcpdumps of the traffic at the server and client.tcpdumpcambridge/inmotion/udp32200510012006-11-14cambridge/inmotion/udp/wireless/proc/wireless trace for UDP transfer./proc/wireless trace for UDP transfer.the initial versionfalse2006-02-012005-03-252005-03-25This was a cat of /proc/wireless every secondoutput of /proc/wirelesscambridge/inmotion/udp23200510012006-11-14cambridge/inmotion/webTraceset of WEB application transfers between a moving car and an 802.11b access point.Traceset of WEB application transfers between a car traveling at speeds from 5 mph to 75 mph, and an 802.11b access point.the initial version2006-02-012005-03-142005-03-25Network Performance AnalysisWe 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)/download/cambridge/inmotion/sd_experiments_allweb.tar.gzcambridge/inmotion33200510012006-11-14cambridge/inmotion/web/dadateKey press trace for WEB transfer.Key press trace for WEB transfer.the initial versionfalse2006-02-012005-03-142005-03-25This 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.cambridge/inmotion/web34200510012006-11-14cambridge/inmotion/web/kismetWireless monitoring (kismet) trace for WEB transfer.Wireless monitoring (kismet) trace for WEB transfer.the initial versionfalse2006-02-012005-03-142005-03-25These are the link layer traces captured by kismetkismetcambridge/inmotion/web35200510012006-11-14cambridge/inmotion/web/tcpdumptcpdump trace for WEB transfer.tcpdump trace for WEB transfer.the initial versionfalse2006-02-012005-03-142005-03-25These are the tcpdumps of the traffic at the server and client.tcpdumpcambridge/inmotion/web36200510012006-11-14cambridge/inmotion/web/wireless/proc/wireless trace for WEB transfer./proc/wireless trace for WEB transfer.the initial versionfalse2006-02-012005-03-252005-03-25This was a cat of /proc/wireless every secondoutput of /proc/wirelesscambridge/inmotion/web15cambridge/hagglecambridge/inmotionRichard Gassrichard.gass@intel.comIntel Research CambridgeIntel Research Cambridge,
15 JJ Thomson Avenue,
Cambridge CB3 0FD, UK+44-1223-767404+44-1223-763456http://www.cambridge.intel-research.net/~rgass/14cambridge/hagglecambridge/inmotionupmc/contentJames Scottjamesscott@acm.org18cambridge/hagglecambridge/inmotionChristophe Diotchristophe.diot@gmail.comParis Research Lab, ThomsonParis Research Lab, Thomson
46, quai A. Le Gallo
92648 Boulogne cedex, FRANCEgass-in-motionRichard GassJames ScottChristophe DiotMeasurements of In-Motion 802.11 NetworkingProceedings of the 7th IEEE Workshop on Mobile Computing Systems and Applications--04--200669-74http://dx.doi.org/10.1109/WMCSA.2006.14Semiahmoo Resort, Washington, USAcrawdadmeasurementwirelesscambridge_inmotioncrawdadcambridge/inmotion20060401gass-in-motion-trRichard GassJames ScottChristophe DiotMeasurements of In-Motion 802.11 NetworkingIRC-TR-05-050--10--2005Intel Research Technical Reporthttp://www.cambridge.intel-research.net/~rgass/papers/tr/irc-tr05050-inmotion.pdfcrawdadWireless 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.measurementwirelesscambridge_inmotioncrawdadcambridge/inmotion20051001