Mid-Term Report


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mid-Term Report

  1. 1. 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 Abstract 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 project. Introduction 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
  2. 2. 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. Background 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 support equipment. 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
  3. 3. 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. Wireless Ranges 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.
  4. 4. 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 laptop. 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 120 100 80 % Loss 60 % Loss 40 20 0 0 200 300 400 600 700 800 1000 1100 1200 1300 1500 1600 1700 2000 2100 2400 2500 100 500 900 1400 1800 1900 2200 2300 2600 Distance (ft) 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 60 50 40 % Loss 30 % Loss 20 10 0 200 300 600 700 800 1600 1700 2100 2200 2500 2600 0 100 400 500 900 1000 1100 1200 1300 1400 1500 1800 1900 2000 2300 2400 Distance (ft) 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
  5. 5. Antennas on Both Ends, % Loss vs. Distance 3.5 3 2.5 % Loss 2 % Loss 1.5 1 0.5 0 1100 1400 1700 2500 0 100 200 300 400 500 600 700 800 900 1000 1200 1300 1500 1600 1800 1900 2000 2100 2200 2300 2400 2600 Distance (ft) 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 100 80 60 80-100 # Packets 40 60-80 20 40-60 20-40 0 80-89 ms 0-20 0 40-49 ms 200 400 600 9 ms 800 1000 1200 5 ms Latency 1400 1600 1800 1 ms 2000 2200 2400 2600 Distance (ft) the spikes in lost packets. When there is an antenna on the base station, there is one small
  6. 6. Antenna on Base Station, # of Packets(per 500) vs. Latency and Distance 15 # of Packets 10 5 10-15 5-10 0 80-89ms: 0-5 0 40-49ms: 200 400 600 9ms: 800 1000 1200 5ms: Latency 1400 1600 1800 1ms: 2000 2200 2400 2600 Distance (ft) 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 Distance 1 0.8 # Packets 0.6 0.8-1 0.4 0.6-0.8 0.2 0.4-0.6 0 0.2-0.4 80-89ms: 0 40-49ms: 0-0.2 200 400 600 9ms: 800 1000 Latency 1200 5ms: 1400 1600 1800 1ms: 2000 2200 2400 2600 Distance(ft) 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.
  7. 7. 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.
  8. 8. Security Issues 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.
  9. 9. UAV Simulation 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. Future Plans 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.
  10. 10. 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. Conclusion 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.