* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Deployment of a Rational Swarm Routing Algorithm in Ad Hoc
Survey
Document related concepts
Multiprotocol Label Switching wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Internet protocol suite wikipedia , lookup
Airborne Networking wikipedia , lookup
Backpressure routing wikipedia , lookup
Distributed operating system wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Everything2 wikipedia , lookup
Dijkstra's algorithm wikipedia , lookup
Transcript
Proceedings of the 2008 IEEE Systems and Information Engineering Design Symposium, University of Virginia, Charlottesville, VA, USA, April 25, 2008 FPM2Opt.1 Deployment of a Rational Swarm Routing Algorithm in Ad Hoc Networks of Mobile Hosts Jonathan H. Bao Abstract—Mobile ad hoc networks are characterized by many small processors that work together to perform complex tasks with no outside help. These systems are rapidly deployable and can be used to create wireless sensor networks. The challenge lies in developing a protocol that allows the processors to automatically set up multi-hop communication paths among themselves. If the nodes are mobile then the network topology changes when nodes move out of wireless range and nodes may have to reestablish broken paths. The rational swarm protocol developed at the University of Virginia attempts to discover several paths between a source and destination by tracking the quality of each path to minimize the expensive need to perform route discovery when a path breaks. This thesis project deployed rational swarm onto a real system of small Sun SPOTs to serve as a proof of implementation. A graphical user interface allows a user to control and display the system to demonstrate its capabilities to a large audience. M I. INTRODUCTION OBILE ad hoc networks (MANET) are made up of hundreds of small processors that rely on each other for wireless communication. Instead of using large infrastructure to transmit messages long distances, the processors forward messages amongst themselves until the packets reach their destinations. Such networks have applications that range from military surveillance to biomedical monitoring and are characterized by rapidly deployable and flexible applications. The major research problem provided by MANETs stems from developing a routing protocol that automatically enables the processors to set up multihop communication paths. The protocol must establish paths quickly, not use too much battery power or wireless bandwidth, and handle path failure. The problem may be divided into two parts: route discovery and route maintenance [1]. When a node needs to send a message to another destination node and does not know how to route its message through the network, it must perform route discovery. The source node has to broadcast probing messages to find a path to the destination node. Upon hearing the probe, the destination sends a reply message back to the source. The source receives the reply message and knows how to transmit messages to the destination. Manuscript received April 7, 2008. This work was supported in part by NanoVision Technologies Inc and the University of Virginia’s Wireless Internet Center for Advanced Technology. Jonathan Bao is with the Systems Engineering Department, University of Virginia, Charlottesville, VA 22904 USA (mobile: 703-629-8647; email:[email protected]). 1-4244-2366-8/©2008 IEEE Route discovery is a sophisticated algorithm that requires messages to propagate through the network, which costs precious resources in terms of battery power and wireless bandwidth. The best routing protocols seek to reduce the number of route requests required and the number of messages that need to be sent to determine routes. Route maintenance methods must be able to recognize when a path between the source and the destination becomes invalid when a link in the path breaks. In some protocols, each node in the path must broadcast “hello” messages to its neighbors to inform them that a link exists between the node and its neighbors [2]. When a node ceases to receive “hello” messages from its neighbor, it knows that the link has broken, and it has to let everyone using the path between itself and its neighbor know that the path is no longer valid. It sends route error messages to each node depending on the path, and every node must update itself with the new information. Note that this requires nodes to periodically send “hello” messages, which uses resources by clogging the system with packets. The Wireless Internet Center for Advanced Technology (WICAT) at the University of Virginia has defined the major mechanisms of the new rational swarm routing protocol and are currently testing some of the finer details to gain the best performance out of the protocol. Tests were conducted in a simulated environment of dozens of nodes using The Network Simulator (NS-2). This thesis project serves as a proof of implementation that the protocol can work in a real system of wireless mobile processors. Rational swarm was implemented on Sun SPOTs, which are small wireless processors built by Sun Microsystems. In addition to implementation, the project uses a graphical user interface that projects the system of Sun SPOTs onto a computer monitor in real time so users can control and watch the protocol. II. AODV Rational swarm uses many of the mechanisms found in the Ad Hoc On-Demand Distance Vector (AODV) routing protocol; in fact, rational swarm is almost a pure extension of AODV. Perkins and Royer created AODV at the University of California Santa Barbara in 1999 [3]. AODV has several characteristics that make it desirable to use as the basis for a new protocol. AODV was one of the first routing protocols created for MANETs, so it is relatively simple yet completely functional. Many of its characteristics make it attractive over other basic protocols, namely that it is an ondemand protocol and it is a distance vector protocol. 329 A. On-Demand vs. Proactive Protocols On-demand protocols benefit over proactive protocols by reducing overhead and eliminating wasted resources. Overhead in these terms may be defined as any information sent between two nodes that is not actual data used by the applications running on the nodes. Messages used by a protocol that do not contain any application data are the most important source of overhead. It is impossible to entirely eliminate overhead from a protocol; instead we attempt to minimize it. The goal of proactive protocols is to establish paths before they need to be used. Ideally, when a node needs to send a message, it will already know the path to the destination. In order to find paths, a node must broadcast messages throughout the network. In other words, work must be done to find paths. If a node does not use a path that it worked to establish, then it has wasted resources finding a path that it will never use. On-demand protocols such as AODV reduce overhead by never finding paths between nodes that do not need to communicate. A node only tries to find a path to another node when it needs to send data to the other node. Although a node will not waste precious network bandwidth and battery life, the tradeoff is a node may have to wait a long time to allow the route discovery mechanism to find a path before it can send data. In our high-mobility and lowresource application, we prefer to reduce waste and accept delays incurred with an on-demand protocol. node may have to remember long paths and each message will have to contain a lengthy list. Distance vector protocols do not rely on the source knowing the entire path. After route discovery finishes in AODV, each node on a path is responsible for knowing which neighbor to forward a message to in order to reach the destination. For example, in Fig. 2 the source knows it needs to send its message to node 2 to reach the destination. B. Source Routing vs. Distance Vector Protocols The easiest way to describe distance vector protocols is to show how it works and compare it to a protocol that does not use distance vector routing. The Dynamic Source Routing (DSR) protocol uses source routing instead of distance vector routing and offers benefits and drawbacks compared to AODV [4]. After a node performs route discovery to find a route to a destination node using DSR, the source node knows the entire path that must be taken to reach the destination. As an example, the source will know a message must travel from itself to node 2, then on to node 7, and so forth until the destination receives the message, as shown in Fig. 1. III. RATIONAL SWARM ROUTING PROTOCOL Fig. 1. Example of source routing. The source node is responsible for keeping track of the entire path. When the source sends a message to the destination, it will attach the entire path to the message, so when node 2 receives the message from the source it can look at the path and see that it needs to forward the message to node 7. An advantage of this method is that the source can keep track of multiple paths to the destination. However, paths could get very long if there are many nodes in the network. The source 1-4244-2366-8/©2008 IEEE Fig. 2. Example of distance vector routing. Each node is responsible for knowing the next node in the path. However, the source does not know that node 2 has to in turn forward it to node 7. Node 2 is in charge of knowing that all messages for the destination have to go through node 7. Distance vector routing eliminates the need for the source to remember lengthy paths and for messages to contain paths. However, a negative of AODV is it will only establish one path between the source and the destination. If that path breaks, the source will have to initiate route discovery to find a different path. The simple reason for AODV’s inability to remember multiple paths is that if the source had multiple paths to the destination, it would not be able to compare the paths to determine which the best one is. The fundamental difference between AODV and rational swarm is that swarm maintains several metrics to gauge the quality of each path. AODV is restricted to only creating one path between a source and destination because there is no way to determine which path is the best. If the nodes keep track of metrics for a path, then they can make decisions about which path to use. The benefit of remembering multiple paths is that a node is able to switch to a different path if the current path breaks instead of having to perform route discovery to find a new path. Rational swarm measures the quality of paths using two metrics: success rate, which is the percent of packets successfully transmitted between two nodes, and delay, which is the time it takes for a packet to reach its destination. A. Multiple-Path Distance Vector Routing Enabling a distance vector protocol to remember multiple paths creates an advantage over other protocols. To demonstrate the point, we will compare rational swarm to DSR, which uses source routing to maintain multiple paths. Recall in source routing that the source node must keep track of the entire path from the source to the destination. As an example, consider the two-path system shown in Fig. 3. The source knows a message can travel from 1 to 2 to 4, or alternatively a message can travel on the different path 1 to 3 to 4. If the source node discovers that the path it is using breaks, it will decide to switch to the other path. 330 Fig. 3. A two-path system. Messages may either travel along the top path or the bottom path. In distance vector routing, a given node only knows which neighbor to give a message to; it doesn’t know what the path looks like between the neighbor and the destination. After receiving a message, a node may only decide which neighbor to forward the message to, so the maximum number of paths it knows about is the number of neighbors it has. To illustrate, in Fig. 3 the source can only send a message to node 1, so it thinks there is only one path to the destination when in reality there are two. Node 1 is the only one that knows the existence of the two paths because it can either send a message to node 2 or node 3. This characteristic of distance vector routing is very beneficial in route maintenance. Consider that node 1 has chosen to send messages to node 2 and therefore uses the path from the source to 1 to 2 to 4. If node 2 becomes inactive by either turning off or moving out of the network, then the path will break. Node 1 will realize that it can no longer send messages to node 2. Then it can make the decision to use node 3 without having to let any other nodes know. The network automatically adapts to node failure or mobility at the point where the break occurred. Only if node 1 had no paths to the destination (for instance if node 3 then shut off) will it have to send a route error (RERR) message backwards to the source. Even then, if a node receives the RERR message and it has another path to the destination, it will switch to the other path without having to inform any other nodes. B. Success Rate Metric Sometimes messages will not successfully travel between two neighboring nodes even if they are within wireless distance. Failed transmissions may be caused by several factors, such as interference in the radio waves or an excess load on the node receiving the message. Generally, the farther apart two nodes are, the less likely a message will successfully make it from one to the other. Link failure can be extrapolated to an entire path such that there is a probability that a message will not be able to travel between a source and destination even if the path physically exists. For each path, nodes keep track of how often messages are successfully transmitted and stores the knowledge as the path’s success rate. If the success rate of a path drops below a threshold value, then the node will decide the path is too unreliable and it will remove the path from its memory, provided it has another path to the destination. If the unreliable path is the only available path, then the node will resign to continue using it. 1-4244-2366-8/©2008 IEEE When a node X sends a data packet to its neighboring node Y, it expects to receive an acknowledgment, or ACK, from Y stating it has successfully received the packet. If an ACK is not heard after a certain amount of time, node X assumes the message was lost. Let p be a variable with a value of 1 if the message was successfully transmitted and 0 if it was lost. Also, let w be a weight variable that determines how important new information is compared to already known information. After each successful or failed message, node X updates its knowledge of the success rate of the link according to (3). s X ,Y = s X ,Y * (1 − w) + w * p (1) When node Y sends an ACK to node X, it includes its knowledge of the success rate from node Y to the destination node D. We treat the probability of a successful transmission over a link as independent from the other links, so to find the total success rate between X and D we multiply the probabilities. Equation (2) demonstrates this relationship. s X , D = s X ,Y * sY , D (2) C. Delay Metric For each path, a node also keeps track of how long it takes a message to reach the destination. Nodes store the delay times for every path into memory. If a node has multiple paths to reach the same destination, it will use the path with the lowest delay because it is interested in the fastest path possible. Every time a node learns new information about the delay of a path, it will look at all available paths and choose the fastest. This is in contrast to the success rate metric, which only looks at an individual path to determine if it should be removed from memory. In short, nodes use the delay metric to choose the best path, while the success rate metric is used to eliminate bad paths. When a node X sends a data packet to a neighbor Y, it expects to receive an ACK from the neighbor that the message was received. The sending node keeps track of how long it took to receive the ACK after sending the data packet and stores the information as the delay time for the link. As part of the ACK, the neighbor sends how long it takes a message to travel from the neighbor to the destination node D. Thus, the time it takes for a message to travel from X to D is simply a sum of the measurements, shown in (3). d X , D = d X ,Y + d Y , D (3) IV. IMPLEMENTATION This section describes how rational swarm was implemented onto the Sun SPOTs. Rational swarm had been written in the programming language C to run on the agentbased simulator NS-2 by Fernan Pedraza, a graduate student at the University of Virginia, so a large part of the development was simply to translate the program into Java. It was not a blind translation because intimate knowledge of every line of the C code was needed to ensure it needed to be in the Java implementation. There was no documentation on how rational swarm worked, so the C code was used as 331 the main description of the protocol. This section begins with a brief description of the capabilities of Sun SPOTs and then covers the major steps in writing swarm onto the Sun SPOTs. A. Sun SPOTs Sun Small Programmable Object Technologies, or Sun SPOTs, are small processors created by Sun Microsystems [5]. They are specially built to run Java programs and come with a 180 MHz processor and 512K RAM, so they can run any Java program meeting these constraints. A radio and antenna allows each Sun SPOT to wirelessly transmit data using the IEEE 802.15.4 standard for wireless communication. This standard is intended to require little battery power at the cost of slower transmission compared to the 802.11 standard used by computers [6]. Sun SPOTs come in two varieties. The first is a standard Sun SPOT, which is designed to run by itself. In contrast, the second type is a base station, which only operates when connected to a computer. A Sun SPOT uses a battery for power and comes with an LED display that provides output signals while it runs a program. Base stations do not run programs and use the computer for energy. Programs are run on the computer and the base station is used as a radio that allows the computer to send and receive messages to and from the Sun SPOTs. The test system is made up of Sun SPOTs while the graphical user interface uses a base station. B. Routing Table Structure The backbone of any routing protocol is the routing table. The table is responsible for remembering how to get a message from the current node to the destination. The table has an entry for each destination node. Each entry contains all of the information needed about how to send a message to the corresponding destination. For example, a node would look up the entry for destination X to find out how to route a message to X. Each entry has information for each neighbor that the node can send a message to that will be able to forward the message towards X. Recall that each neighbor represents a potential path to the destination. In turn, each path has information about the success rate and delay expected when transmitting data across the path. A visual representation of the layout of the routing table is shown in Fig. 4. Fig. 4. Illustration of the routing table. Nodes look up which neighbor to forward a message to in order to reach a destination. 1-4244-2366-8/©2008 IEEE C. Handling Swarm Messages The most complicated part of the implementation was writing the logic for each node to handle incoming swarm messages. This portion was also implemented in the simulation code. However, a real mastery and understanding of the code was needed as opposed to a simple conversion from C to Java. This section of the program did all of the processing and work, and when the program did not work as intended it was necessary to know how the entire protocol operated in order to fix the problem. In addition, any changes in the structure of the routing table or other structures required wholesale updates of this section. There was a strong desire to simply start from scratch instead of attempting to understand all of the code, but in the end the code was used with many modifications. D. Application Layer Adaptations Up to this point, all of the programming code was adapted from Pedraza’s C code written for NS-2. After that was translated, additional code had to be written to enable the protocol to work on the Sun SPOTs. Rational swarm on the Sun SPOTs is implemented in the highest application layer of the OSI protocol model instead of the lower network layer (please see [7] for more information on OSI). As such, many modifications had to be made from the C code, a few of which are very briefly discussed here. Every Sun SPOT was given an application layer identification number to use as its name. In a real system, a processor would use either its IP address or MAC address as identification. This change allows a user to easily identify Sun SPOTs, which facilitates testing. However, it is important to note that Sun SPOTs automatically use standard IP headers when sending packets to determine the source and destination of a packet. IP headers use IP addresses to identify nodes, so it was necessary to create a custom IP header that use the application layer ID number. The true definition of rational swarm calls for messages to only reach the network layer instead of the application layer. Lower layer protocols transmit one packet at a time and store other outgoing messages in a queue. However, in rational swarm it is necessary to wait for path discovery to complete before sending data because a node cannot send data without a path. An application layer queue stored messages waiting to be sent when a path was being built. Similarly, an outbound queue stored packets while a node waited for an ACK on a previous packet sent to a neighbor. In addition, all timing used to determine path delay times in rational swarm use built-in clocks found in the MAC layer. However, this project uses a custom timer mechanism to make the development simple and eliminate the need to discover how the Sun SPOT built-in timers work. In the simulation code, NS-2 simulated messages traveling from one node to the next. In a real system, messages actually have to be transmitted wirelessly to the destination. Sun SPOTs come with a mechanism that allows programs to transmit messages using broadcast (one source to all neighbors) or unicast (one source to one neighbor). Packets, which are comprised of a IP header, swarm header, 332 and data, had to be converted into a single byte array and then sent to the Sun SPOT functions that transmit them. E. Simulated Test Environment As described in Section III, there is a probability that a message will not successfully travel between two nodes due to interference in the wireless channel or excessive load on the receiver. In order to test how rational swarm reacts to these and other exogenous variables, the chance of a failed transmission is simulated. The user setting up or running the system defines the chance a message will be dropped across a link, and the receiving node randomly decides to ignore messages based upon the probability. In terms of technical implementation, each node stores a success rate number for links between it and every other node. If a link does not exist between two nodes, then the success rate is zero. icons on the display representing each Sun SPOT and the physical layout of the icons must match the Sun SPOTs. When a message travels between two Sun SPOTs, a line should move between the appropriate icons on the display. The display panel begins by displaying an icon for each Sun SPOT. The user may then click and drag the icons so they match the physical layout of the SPOTs. A base station Sun SPOT is connected to the computer and listens to the messages of the system. When a message is heard, it is drawn traveling between the corresponding two icons on the screen. An image of the display panel is shown in Fig. 6. F. Results The project was allocated seven Sun SPOTs to test, which was determined to be enough to show many of the capabilities of rational swarm. Fig. 5. shows one configuration of the seven nodes. The source node on the left needs to send messages to the node on the far right. There are two paths, so when one path deteriorates or breaks the node at the fork can switch to the other path. If both paths break, a route error message will be sent back to the source. Fig. 6. The GUI’s display panel. Fig. 5. Test bed of Sun SPOTs running rational swarm. V. GRAPHICAL USER INTERFACE The test system consisted of seven small Sun SPOTs running the rational swarm algorithm to communicate. Small lights on each Sun SPOT were the only means of watching the routing process. Although the system is impressive and interesting to view, a better display had to be made to easily reach a large audience. The next task was to create a graphical user interface (GUI) that runs on a standard computer that provides more information than blinking lights and can easily be viewed by many people. The GUI built for this project is made up of two parts: the display panel and the control panel. It is based upon a GUI provided by Evan Tschannen of at the University of Virginia used for a similar purpose. The purpose of the display panel of the GUI is to project what is happening on the Sun SPOTs to a computer screen. The rudimentary requirements are simple. There must be 1-4244-2366-8/©2008 IEEE A meaningful presentation would allow the presenter to change the state of the system to demonstrate how the protocol reacts. The control panel allows a user to create scenarios as the system runs. The control panel shows icons for each node and can be arranged into the correct physical layout. It initializes with predetermined links between nodes that can communicate directly with each other, i.e. when the probability of successful transmission between the nodes is greater than zero. In addition, the links are color-coded to represent the quality of the path. A link with a high success rate is green, medium is yellow, and poor is red. At the bottom of the panel is a form that allows the user to change the success rate of a link. The user types in the identification number of each node on either side of the link and the link’s new success rate. When the Update Link Quality button is pushed, the base station connected to the computer will send a message to all of the Sun SPOTs to update their link quality table. Links may deteriorate or increase in reliability when the quality changes. Nodes may become neighbors if the new quality is made positive, or a link may break entirely if the quality is set to zero. Users may easily simulate interference in an area or completely change the layout of the system. The control panel is shown in Figure 5.2. 333 [5] [6] [7] Fig. 7. The GUI’s control panel. VI. CONCLUSION This project has shown rational swarm can work on real devices, while Fernan Pedraza’s simulation shows that the protocol has merit in certain situations and performs better than other standard MANET protocols. The implementation should be moved to a more scalable test bed where the number of physical processors is not a constraint. After a suitable platform is chose, the protocol should be optimized to run on the network layer as designed. This will create a very close relationship between rational swarm and the platform, so the test system should be chosen wisely. In addition, the graphical user interface should be improved to easily allow extensive changes to the network topology and to show state information for paths maintained by each node. ACKNOWLEDGMENT Jonathan H. Bao thanks his technical advisor Barry Horowitz for providing the motivation and resources to complete this project. He also thanks graduate students Fernan Pedraza and Evan Tschannen for providing substantial amounts of programming code and expertise. REFERENCES [1] Johnson, David B. “Routing in Ad Hoc Networks of Mobile Hosts.” Proceedings of the Workshop on Mobile Computing Systems and Applications, IEEE Computer Society. Dec 1994: 158-163 [2] Perkins, C. “RFC 3561: Ad hoc On-Demand Distance Vector Routing.” Jul 2003. Internet Engineering Task Force (IETF). 9 Oct 2007. Available: http://www.ietf.org/rfc/rfc3561.txt [3] Perkins, C.E.; Royer, E.M., "Ad-hoc on-demand distance vector routing," Mobile Computing Systems and Applications, 1999. Proceedings. WMCSA '99. Second IEEE Workshop on , vol., no., pp.90-100, 25-26 Feb 1999 [4] Johnson, David. “RFC 4728: The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4.” Feb 2007. Internet Engineering Task Force (IETF). 9 Oct 2007. Available: http://www.ietf.org/rfc/rfc4728.txt 1-4244-2366-8/©2008 IEEE 334 Sun Microsystems. Home of Project Sun SPOT. Available: http://www.sunspotworld.com/. Accessed March 20, 2008. De Nardis, L.; Di Benedetto, M.-G., "Overview of the IEEE 802.15.4/4a standards for low data rate Wireless Personal Data Networks," Positioning, Navigation and Communication, 2007. WPNC '07. 4th Workshop on , vol., no., pp.285-289, 22-22 March 2007 Zimmermann, Hubert. “OSI Reference Model – The ISO Model of Architecture for Open Systems Interconnection.” IEEE Transactions of Communications, Vol. COM-28, No. 4, April 1980.