REU 2005 Midterm Report: Wireless Networking and
the Army Shadow Unmanned Aerial Vehicle
Author: David Last
Team Members: Dr. Richard Chapman, Dr. David Umphress, Dr. Drew Hamilton, Dr.
Chwan-Hwa Wu, Shawn Constance, Kevin Richardson, Anthony Friday, James Box,
Alan Hunt, and David Last
With our country at war, the Army is focusing even more on technologies that can
protect our troops and give them a strategic advantage on the battlefield. The Shadow
200 Unmanned Aerial Vehicle (UAV) is a remote reconnaissance aircraft that provides
an aerial view of the battlefield without endangering human pilots. Currently, the ground
support equipment for the Shadow is connected by wires; the system would be more
robust and convenient to use if these links were wireless. Our team is working on
providing a wireless solution for the Shadow system. In order to build our system, we
have performed experiments on the range of 802.11g wireless communications. We
chose MPEG-4 video compression for streaming data because of its high rate of
compression and reliability. Our team has been researching ways to defend against
Denial of Service attacks to make our network more secure. The Army has loaned us a
simulator of the Shadow system so that we can test our ideas on a system that closely
approximates the field equipment that will employ in our final solution. Although we
have made significant progress, there is still much work to be done before we finish this
Our country is at war. Today, our military battles terrorists in Afghanistan and
Iraq, as well as many other places throughout the world. In these battles, intelligence is
critical. Knowing what is happening on the battlefield allows commanders to make
decisions that can save the lives of soldiers. To this end, the Army employs several
different types of Unmanned Aerial Vehicles (UAV) to get a bird’s eye view of the
battlefield with minimal risk to human life. The Shadow 200 UAV is one of the most
commonly used vehicles for this purpose, and it provides a real-time video stream from
its on-board cameras.
The Shadow 200 UAV system includes several components on the ground which
control the UAV and relay the video stream to the commander. Currently, all of these
components are connected by cables. These cables account for a large part of the whole
system’s weight and setup time. Our team was commissioned to find a way to connect
all of the ground control elements wirelessly. Accomplishing this will make the Shadow
UAV system more mobile and less susceptible to wear and tear.
This paper covers the background of the Shadow UAV system and discusses the
special design issues we will face during this project. The Background section presents
the basic layout of the Shadow 200 system. The Wireless Ranges section outlines our
experiments with the range of 802.11g wireless communications. The MPEG-4 Video
Compression section will briefly examine the mechanics of MPEG-4. The Security
Issues section will deal with Denial-of-Service attacks on wireless networks, and our
efforts to resolve with those issues. The UAV Simulation section will briefly discuss our
simulations of the actual Shadow UAV. The Future Plans section outlines what we hope
to accomplish by the end of the project.
For my REU project this summer, I am working with a research team on a project
for the Army’s Shadow UAV (Unmanned Aerial Vehicle – henceforth, the words
Shadow and UAV will be used interchangeably). The team is led by Dr. Chapman, Dr.
Umphress, and Dr. Hamilton; several graduate students and I form the rest of the team.
This project had already been in progress for about a month when I joined the team.
The Shadow UAV is essentially a large remote-controlled airplane. The Army
uses it to get an aerial view of a battlefield so that the
commanders on the ground have more information
about the battle zone. One Shadow UAV unit consists
of 4 to 6 soldiers, 3 Shadow UAVs, and the necessary
The ground support equipment comes in several
different parts. The hydraulic rail launcher is a catapult
built onto a trailer. This launcher is used to get the Shadow into the air. While the
Shadow is in flight, the Ground Data Terminal communicates with it and also relays live
video to the battlefield commander. The
Ground Control Station is used to
control and monitor the UAV while it is
in flight. This system sits in the back of
a Humvee and allows the operator to see
the video feed coming from the UAV.
When the Shadow is ready to land, the
TALS (TUAV(Tactical UAV)
Automated Landing System) takes control of the UAV just prior to landing and guides it
into the runway.
Currently, all of the different elements of the
ground support equipment are connected by cables. The
goal of our project is to build a system which allows all the
elements to communicate wirelessly. The Army wants to
eliminate the cables for several reasons. First, it will
reduce the equipment the team needs to carry. Also, with
no cables to hook up, it will be much easier to set up and
dismantle the system. If a UAV team comes under enemy
fire, they can drive away in the Humvees without
destroying all of the cables. Finally, in an active combat
zone, there are many tanks and smaller vehicles in the area; these can easily damage the
cables by driving over them. Therefore, the Army desires to make the system connected
by wireless links.
Our team faces several challenges as we work through this project. First, we need
to know how we can provide robust wireless communications links, and how far we can
push those links, distance-wise. Next, we have to consider how to defend against
security threats, especially those that are specific to wireless networks. Since the
bandwidth on wireless networks is more limited than on wired networks, we will need to
reduce our traffic to a minimum. Specifically, we will need to compress the video stream
as much as possible, since it is the most bandwidth-intensive part of our network traffic.
Finally, we will need to test our solution on the equipment that the Army will be using in
the field. So far this summer, I have been involved in all of these areas.
Our first concern was how well wireless connections would serve our application.
We needed to be able to measure how robust a wireless link would be, and over what
distance. We knew that we could measure robustness by transmitting packets and then
observing the number of packets dropped and the latency (that is, how long it takes
packets to travel). Therefore, one of our team members wrote a simple program to record
this information. The software is installed on two computers. One of the computers
transmits a number of packets to the other computer (we used 500 as a standard), and the
receiving computer immediately transmits the packets back to the sender. The sender
then counts the packets it receives and records how many packets were lost and also the
latency of those it received correctly. In our experiment, the traffic was passed through a
wireless access point.
We wanted to measure the performance of the wireless link at different distances,
so we needed a large, flat field. We decided to perform our experiments in the field
paralleling the runway at the Auburn-Opelika Airport. At the beginning of our
experiment, we marked off distances from 0 to 2600 feet every 50 feet. For the
experiment, we placed the wireless access point (also called the base station) at 0 feet and
left the reflector laptop close to the access point. We took the transmitter laptop and
transmitted our 500 packets at 0 feet, 50 feet, 100 feet, etc. out to 2600 feet.
We also wanted to see how the performance would be affected by external
antennas. Therefore, we ran our first experiment with no antennas. For the second
experiment, we used an antenna on the base station, but nothing on the transmitter laptop.
For the final experiment, we used antennas on both the base station and the transmitter
The following graphs show the results of one of our experiments. The first set of
graphs shows the percent packet loss at a given distance for each of the runs. On these
graphs, the X-axis is the distance between the base station and the transmitter laptop.
The Y-axis is the percent loss for the transmitted packets.
When we used no antennas, our packet loss was relatively low. However, there
were random spikes of packet loss, and the spikes became more frequent and severe past
No Antennas, % Loss Packets vs. Distance
60 % Loss
1700 feet. When we used an antenna on the base station, our average performance was
worse, but the random spikes were less frequent and less intense. With antennas on the
Antenna on Base Station, % Packets Loss vs. Distance
30 % Loss
base station and the transmitter laptop, the percent loss was low all the way out to 2600
feet. As we were testing, we noted that there was a large antenna on the other side of the
Antennas on Both Ends, % Loss vs. Distance
runway at about 1700 feet. We feel that this may have caused some of the distortions in
our readings around that distance.
The next set of graphs shows the latency and number of packets with that latency
vs. the distance. In these graphs, the X-axis is the distance between the base station and
the transmitter laptop. The Z-axis is the latency of the packets. The Y-axis is the number
of packets with the given latency at the specified distance.
With no antennas, there are a few spikes in slow packets which correspond with
No Antennas, # of Packets(per 500) vs. Distance and Latency
80-89 ms 0-20
5 ms Latency
the spikes in lost packets. When there is an antenna on the base station, there is one small
Antenna on Base Station, # of Packets(per 500) vs. Latency and Distance
# of Packets
0 80-89ms: 0-5
1200 5ms: Latency
spike in latency at the extreme distance. With two antennas, there is no latency at all.
Antennas on Both Ends, # Packets(out of 500) vs. Latency and
Once again, we believe that the radio antenna at 1700 feet may have been
responsible for the spikes in latency around 1700 feet for the no-antenna experiment.
Also, it should be noted that the spikes in latency generally correspond to spikes in packet
loss at the same distance.
MPEG-4 Video Compression
Since a wireless network has limited bandwidth, we needed to minimize the
amount of network traffic. Since the video stream will be the largest portion of the
traffic, we needed to find a way to compress it. MPEG-4 is the industry standard video
compression designed specifically for applications like video streaming. As part of the
project, I did some research into how MPEG-4 compression works.
The basis for MPEG-4 video is the Video Object Plane (VOP). Basically, a VOP
is a self-contained video or a set of computer-generated graphics. Different VOP’s are
laid on top of each other to form the complete video; however, it is possible that a given
video segment may be represented by a single VOP. MPEG-4 video compression codes
each of the VOP’s separately. These VOP’s can be encoded in two different ways. In
intraframe coding, each frame of video is represented independently, while in interframe
coding, a frame of video is represented as its difference from the previous frame.
Consequently, interframe coding works best if the video has little motion, a steady
background, and infrequent scene changes, because then the difference between two
frames can be represented with minimal information. MPEG-4 and most other video
compression schemes use interframe coding to reduce the video file size.
Within the interframe coding scheme, there are three types of VOP frames. An
intracoded VOP (I-VOP) is coded independently. A predictively coded VOP (P-VOP) is
represented as its difference from the previous frame. The bi-directionally coded VOP
(B-VOP) is represented by its difference from the previous frame and the next frame. P-
VOP’s and B-VOP’s provide most of the compression in the video stream, but its easy to
see how even a slight corruption of the data during transmission can lead to a loss of
meaningful synchronization. Therefore, the I-VOP’s are sprinkled throughout the video
stream to serve as reference points for the other frames.
Since networks often drop a significant number of packets, the MPEG-4 standard
provides extra error control for video streaming. Before the video is streamed, each
frame is split into a number of packets, as seen in the second picture, and each packet is
coded independently. In this way, if one of the packets is corrupted in transmission, the
error will propagate to the end of the packet and then stop there, as seen in the fourth
picture. Without the packetization, the error would continue all the way to the end of the
frame. In this way, the effects of errors are reduced substantially.
All networks have security vulnerabilities, but wireless networks face special
risks because of the ease with which an attacker can gain access to the network. Since
our project is basically a wireless network, we needed to address these issues. By the
time the project is complete, we will have dealt with a number of vulnerabilities, but at
this point, we have been focusing mainly on Denial-of-Service (DoS) attacks. In a DoS
attack, a hostile computer joins the network and does something to block or impair
communication between the network elements. In our situation, the most likely attack
would come from a hostile agent flooding the network. Basically, the attacker sends a
large number of packets across the network. This monopolizes a large amount of the
available bandwidth, so packets sent by legitimate network elements are lost or delayed.
Since the video streaming across the network would be the most bandwidth-
intensive application, we decided to simulate an attack on a video stream. For our
experiment, we set up a video stream from one laptop to another through our wireless
access point. A third laptop used the program written for our wireless range experiments
to send a large number of packets to the IP address of the computer receiving the video
stream. When we did this, we saw a significant degradation in the quality of the received
video. The video was jerky and blurred, and we saw a lot of dropped frames.
Once we could simulate an attack, we began to look at ways to defend against this
type of attack. The solution we used was MAC address filtering. The wireless access
point allowed us to list the MAC addresses of the computers we wanted to allow to use
the network; the access point then blocked all others. When we did this, the wireless
access point checks the MAC address that is listed in the header of all packets coming
across the network and drops all packets coming from invalid sources. When we used
this method in our experiment, we were able to successfully block the attacking computer
and restore good-quality video.
However, there is a way for an attacker to bypass this safeguard. If the attacker
knows one of the permissible MAC addresses, it is a simple matter to “spoof”, or fake,
his MAC address. It would be possible for the attacker to monitor the network traffic and
extract the MAC addresses of the network elements from the packets coming across the
network. However, if the packets were encrypted, the MAC addresses would be difficult
to extract. Obviously, this is not a permanent solution; we are continuing to look for
additional ways to safeguard our system.
The final goal of our project is to find a wireless solution for the ground control
elements of the Shadow UAV system. Therefore, it makes sense that we should test our
solutions on the real system. As an intermediate step, we
borrowed a simulator from the Army that approximated the
Shadow’s field equipment. One of the computers we received
was called the Virtual Control Station (VCS); it was one of the
two computers that would actually be seen in the Ground
Control Station (GCS) of the
Shadow setup. The VCS could be
used to control the UAV and view
the video stream coming from it.
The other two computers we
received contained a dedicated
video machine and the MUSE
simulator. The MUSE is an all-
purpose simulator that can represent
a variety of unmanned vehicles. In our case, it simulated the Shadow UAV and the
TALS, feeding flight data and a video stream to the VCS. In this way, we can simulate an
actual Shadow UAV flight.
When we are ready to test our wireless solution, we will design a system to make
all of the communication between the VCS and the MUSE simulator wireless. This will
give us a good idea about how well our solution will work and how robust the
communications links will be. This setup will also provide us with a live demonstration
that we can present to congressional staffers who will be visiting us later in the year.
This simulator will help us complete the final stages of our project.
This project is scheduled to be finished sometime in September 2005. Between
now and then, we have a few more items that we need to address on this project.
First, we need to perform more experiments with the range of 802.11g wireless
communication. So far, we have experimented on a large, flat field in fair weather. This
allowed us to get an idea of how far the wireless connection could extend, but it didn’t
simulate most of the situations the Shadow system will be subjected to in the field. The
Army has specified that when the Shadow system is deployed, the ground elements will
never be more than 500 yards apart. Therefore, we will continue our experiments using a
fixed distance of 500 yards. We will perform the same experiments as before, but we
will be evaluating different terrains. We plan to experiment with wooded terrains, urban
terrains (with lots of concrete), and vehicle-filled terrains (with lots of metal); we will
also run an experiment in rainy weather. Since all of these conditions can adversely
affect the wireless transmissions, we want to see exactly how the system will respond.
We will continue to examine ways to block Denial of Service attacks. Different
members of the team have been researching this topic, and they have proposed several
different ideas. We are also concerned about jamming interfering with our network. In a
jamming attack, an outside source generates a signal of great strength on the same
frequency that the network is using. When this happens, receivers are unable to pick out
the packets over the noise from the jammer. To use an analogy, suppose two people are
having a conversation. A third person comes up and starts yelling right next to them, so
the people cannot hear each other. This is the idea behind a jamming attack. We believe
that we might be able to solve this problem by using “directed” antennas rather than
broadcast antennas. This solution may also make our network harder to hack into.
The ultimate goal of this project is to connect the ground elements of the Shadow
system completely wirelessly. As an intermediate step, we want to make all the
connections between our Ground Control Station and our MUSE simulator wireless.
This will require some improvising for both hardware and software. We will be working
on this in the future once we get the MUSE simulator running.
In order to complete this project and deliver a working solution to the Army, our
team must address many different issues. We have performed several experiments with
the range of 802.11g wireless transmission, but we need to continue until we have
accounted for all the conditions our system could encounter in the field. Our team chose
MPEG-4 to encode our video because it provides a reliable video stream using minimal
bandwidth. We have experimented with guarding against Denial of Service attacks, and
we are continuing to investigate this and other possible security breaches. When we
begin to form our final solution, we will test it on the MUSE simulator as a precursor to
actual deployment. Over the next few months, we will be wrapping up our research and
building our final product. Through the cooperation of our team members on a variety of
issues, we will make the Shadow fly wirelessly.