Mobile Undersea Routing Protocol. Michael J. Karell

Transcription

1 Mobile Undersea Routing Protocol BY Michael J. Karell B.A., Quinnipiac University (2005) THESIS Submitted to the University of New Hampshire in partial fulfillment of the requirements for the degree of Master of Science in Computer Science December 200

2 ALL RIGHTS RESERVED c 200 Michael J. Karell

3 This thesis has been examined and approved. Thesis director, Radim Bartoš Associate Professor of Computer Science Elizabeth Varki Associate Professor of Computer Science Michel Charpentier Associate Professor of Computer Science Steven G. Chappell Autonomous Undersea Systems Institute Date iii

4 Dedication To Mom. iv

5 Acknowledgments A number of people have made this paper possible. In particular I wish to thank my advisor, Radim Bartoš, for providing much needed guidance and displaying inconceivable patience. My family and friends for constantly asking me when I would finish my thesis. And lastly, my mother for teaching me never to give up on any endeavor. Ever. v

6 Table of Contents Dedication Acknowledgments Abstract iv v x Introduction 2 Underwater Networks 4 3 Dynamic Source Routing 8 4 Other Work in Ad Hoc Routing 6 5 Mobile Undersea Routing Protocol 20 6 Simulator 28 7 Simulation Results 35 8 Conclusion 44 vi

7 List of Tables 7. Simulation results: 300 second pause time and 500 meter transmission range vii

8 List of Figures 2- Attenuation of acoustic waves in water The Route Discovery process Route Reply Storms An example of DSR Route Maintenance The unidirectional path problem An example of route repair Comparison between Route Discovery and Route Recovery responses to error Comparison between Route Recoveries at,2, and 3 hops from the destination and the Required TTLs Simulator class diagram Event Queue Architecture example Simulation results: time to recover from path failure for transmission range 500 meters Simulation results: time to recover from path failure for transmission range 2000 meters Simulation results: time to recover from path failure for transmission ranges 2500 meters Simulation results: percentage of packets received for transmission ranges 500 meters viii

9 ix 7-5 Simulation results: percentage of packets received for transmission ranges 2000 meters Simulation results: percentage of packets received for transmission ranges 2500 meters Simulation results: total number of packet transmission for transmission range 500 meters Simulation results: total number of packet transmission for transmission range 2000 meters Simulation results: total number of packet transmission for transmission range 2500 meters

10 ABSTRACT Mobile Undersea Routing Protocol by Michael J. Karell University of New Hampshire, December, 200 The myriad barriers to underwater communication provide a new set of challenges for network protocols. Routing protocols which operate in underwater ad hoc networks must react quickly to changing conditions without significant increase in packet overhead or congestion. Dynamic Source Routing Protocol provides a framework for accomplishing these goals. In this paper we present the Mobile Undersea Routing Protocol, which implements this framework and enhances upon it. It uses a limited propagating route request which we call a Route Recovery to quickly and inexpensively recover from routing errors. A Java based network simulator was constructed in order to test and compare the protocols. Statistics were calculated based on packets delivered, total transmissions, and time to recover from a route error as measurements of protocol effectiveness. x

11 Chapter Introduction In most computer systems, communication takes place between stationary nodes with propagation delays of only a few microseconds. New technologies have been made available that allow for high bandwidth pipes even in consumer networks. The protocols that have been designed for these networks take advantage of the speed of communication to make it reliable and robust as well. However, these technologies become useless if they are placed in another medium, specifically water. The problem at hand is finding an acceptable communication technology and a set of protocols to facilitate the communication of Autonomous Undersea Vehicles (AUV). We have considered the attributes of both the medium and the network we intend to create in it, and decided on two goals for our protocol. The first is to decrease the time taken to recover from an error. The second is to maintain a comparable end-to-end packet delivery ratio and total transmissions used to deliver packets and for routing overhead. These goals are to be accomplished under varying degrees of network stability which are introduced by a combination of the mobility of the network and the effective range of acoustic communication. We have researched protocols used for land-based mobile ad hoc networks and considered the inefficiencies inherent in each. The protocol we have chosen to base our work on is Dynamic Source Routing (DSR). Preliminary research into prior work has suggested this protocol would be most conducive to our first goal. The Mobile Undersea Routing Protocol (MURP) has been designed with the specific intent of reducing time to adapt to error and maintaining

12 2 acceptable levels of quality of service in terms of end-to-end delivery ratio and total number of packet transmissions used for inter-node communication. The rest of the document is organized as follows. In Chapter 2 of this document we discuss the effects of the underwater medium on communication and the resulting effect on the possible choices of routing protocols. An analysis of the physical medium is presented, including propagation speeds and attenuation of various forms of waves used in wireless communication. The capabilities of AUVs, and how they affect communication, are also discussed in Chapter 2. In Chapter 3 we discuss the Dynamic Source Routing Protocol as it was originally proposed [2]. The main mechanisms used in DSR are outlined and examined. Route Discovery and Maintenance, the processes by which DSR obtains and maintain source routes between communicating nodes, are covered in detail. Interesting optimizations within DSR that attempt to minimize routing overhead are discussed and critically analyzed. Chapter 4 outlines various papers that present ways to modify and improve Ad Hoc On-Demand Routing using either Dynamic Source Routing or the Ad Hoc On- Demand Distance Vector Routing Protocol (AODV). Each of these outlines is followed by a critical analysis of the weaknesses of the protocol proposed in the corresponding paper. Chapter 5 describes the proposed protocol, which adapts the principles of DSR for use in the underwater environment. The Mobile Undersea Routing Protocol (MURP) utilizes a new mechanism called Route Recovery, which provides a fast and inexpensive method to recover from routing errors due to topology change or intermittent failure. Examples are provided to demonstrate the strengths of the Mobile Undersea Routing Protocol in direct comparison to Dynamic Source Routing.

13 In Chapter 6 we describe the simulator program which was written for this project. The use of object oriented methodologies is discussed and the ways in which they 3 improve the extensibility and ease of use of the program are demonstrated. An emphasis is placed on the principles of polymorphism and inheritance. The program is shown to use a Model View Controller architecture. Event based processing is shown to be used through a simple Queuing architecture. The use of the Spring framework and its dynamic initialization through XML configuration files and object injection is also demonstrated. Design decisions are explained with regards to the implementation of the OSI model for network communication. Finally, in Chapter 7 we provide results from simulations which show the success of MURP at attaining the goals put forth in earlier sections. We describe the network simulator Java program which was designed and implemented for this task, as well as the details of each experimental setup. We provide the measures used to determine the performance of the protocols. We analyze the results to demonstrate in which ways MURP succeeds in its goals.

14 Chapter 2 Underwater Networks In this chapter we first examine the obstacles presented by the underwater medium and how they disrupt communication technologies used in wireless networks. We will explore the various wave forms used in wireless communication and how they succeed or fail underwater. In doing so, we will show that acoustic waves are the only form of communication that is viable in Ad Hoc Underwater Networks. We will then examine how this affects the protocol set chosen to control the end-to-end distribution of packets through the network. We will also discuss the capabilities of the Autonomous Undersea Vehicles and how they affect the parameters used in the development of a protocol. Open air wireless networks generally operate using electromagnetic waves. These technologies are traditionally used for consumer, commercial and municipal networks. Since these networks exist in an unimpeded medium, there is comparatively minimal signal loss and the speed of communication is near to the speed of light. Certain networks are required to function in underwater environments, particularly for scientific or military purposes. In this medium the attenuation, or loss of signal due to absorption, is 45 times the square route of the frequency decibels per kilometer for electromagnetic waves. The absorption of acoustic waves is by contrast several orders of magnitudes lower as shown in Figure 2- [3]. However, the propagation delay of acoustic waves in water is much higher in comparison. The speed of sound in water is estimated to be approximately 500 meters per second [0]. There is also variation 4

15 5 in sound speeds due to changes in temperature, salinity, and hydrostatic pressure. The velocity of sound in water can be more accurately represented by the following empirical formula [2]: c = T T T S( T ) z, where c is velocity in meters per second, T is temperature in degrees Celsius, S is salinity in parts per thousand, and z is depth in meters, which represents hydrostatic pressure. Velocity increases with temperature, salinity and depth. The variation in velocity results in a high degree of unpredictability in the nework. Signal multi-path caused by the waves bouncing off of thermoclines, objects, the ocean surface, or the ocean floor result in further unpredictability in the round trip time of a packet. The protocols associated with standard wireless technologies such as IEEE 802. are not designed with these factors in mind and are therefore not suitable for use with underwater acoustic modems. The capabilities of the AUVs have a significant impact on the choices we have made in the creation of communication protocols for them. One of the main attributes to consider is the mobility of the vehicle. The speed at which the vehicle moves determines how quickly the topology may change, which is directly related to the frequency of errors in routing. It also has an influence on the rate at which information about the networks links becomes stale, which affects the caching policy we choose. Were the vehicles to maintain near perfect formation in movement, speed would be less relevant. However, tidal conditions and variations in system performance forestall the feasibility of such a guarantee [6]. In addition, each AUV is capable of being programmed to carry out an individual mission [7]. It is therefore possible that a group of AUVs would move in independent patterns. In a wireless network, the availability of power is another important consideration. Wireless sensor

16 Figure 2-: Attenuation of acoustic waves in water. 6

17 7 networks tend to focus on reducing overall packet overhead as a means of reducing power consumption [7] [6]. Since the propulsion system, rather than the Network Interface Card and other systems, is the main source of power drain for an active AUV, reduction in total packet overhead is not necessarily a key goal. [5]

18 Chapter 3 Dynamic Source Routing Dynamic Source Routing (DSR) is a network layer protocol designed for use in ad-hoc networks with mobile nodes and multiple hops between end-nodes. It has been tested successfully on a network composed of laptop computers carried by automobiles in a circular path between two stationary nodes. The mechanisms and descriptions of the DSR protocol that we present and discuss in this chapter are based on the paper by David Johnson, David Maltz, and Josh Broch [8] and the DSR RFC [9]. DSR uses source routing, so packets are transmitted with the entire route record, not just the source and destination. The decision of which path to use through the network is made at the source node, rather than distributed through the network at each node in between the source and destination. In a high latency mobile network, one objective is to minimize power consumption and congestion. DSR is useful in this regard because it attempts to reduce routing overhead by routing on-demand. In an on-demand protocol, the routing table of any node will be empty upon startup and until it attempts to send a packet. The table is filled as the node attempts to communicate with other nodes in the network. There is no periodic route sensing to fill the routing table or to remove stale routes from it. An entry is removed from the routing table if and only if it is discovered to be invalid. The mechanisms for caching and removing routes from the routing table are called Route Maintenance and Route Discovery. When a node attempts to send a packet to a node for which it does not have 8

19 9 a route, it initiates a Route Discovery. This is facilitated by a series of messages between the source and destination and the intermediary nodes, which are called Route Requests and Route Replies. The Route Discovery is initiated by broadcasting a Route Request to all nearby nodes. Each successive node sends a new Route Request until it reaches the destination node specified in the Route Discovery. At that point the destination node sends a Route Reply, to which it appends the accumulated route record. Each node receiving the Route Reply will add the route record to its routing table. This procedure is demonstrated in Figure 3-. The figure shows a node A attempting to communicate with destination node G. Node A initiates the Route Discovery by broadcasting a Route Request packet, which is received at neighboring nodes B and C. Each of these receiving nodes appends themselves to the cumulative route record and retransmits the packets. Route Requests broadcast from B and D are received at C and E respectively. This process repeats and broadcast packets from C and E are received at G and F. Since G is the destination of the Route Discovery, it transmits a Route Reply back to the source node A upon receiving the request. The links in this case are assumed to be bidirectional, so the Route Reply follows the reverse path that the Route Request followed. In this case, F also forwards the Route Request to G, but it is received after the broadcast from C, so that Route Request is ignored as a duplicate. Since each message involved in the Route Discovery is broadcast, a node may learn and cache any number of routes to multiple destinations as a result of a single Route Discovery. A Route Reply typically follows a route found in the routing table of the destination node. However, if the routing table does not contain a route back to the source, then a new Route Discovery is initiated with the source and destination reversed. To prevent infinite recursion of Route Discoveries, the Route Reply is appended to each Route Request. In cases in which networks have links that are

20 0 B C D E A G F C E A G F B D B C D E A G B D A G F C E A. B. C. D. B C D E A G F E. F Discovery: A G Response: A,B,C,G Packet: A,B,C,G Figure 3-: The Route Discovery process.

21 guaranteed to be bi-directional, the destination node may reverse the accumulated route record, cache it, and use it to send the Route Reply. Each intermediate node may also cache a route to previous nodes in the route record. Nodes that overhear the request but are unable to forward it may also cache a route back to the source. An important issue to consider is that a single route request may result in numerous simultaneous attempts to return a Route Reply. An example of this can be seen in Figure 3-2. Node S requests a route for node D and nodes A, B, C and E all reply with the routes contained in their route table, which are of varying length. The high volume of Route Replies creates a high probability for congestion problems. In order to prevent this, DSR requires each node to delay its route reply by a random period of time represented by the following formula [8]: d = H (h + r), where H is a small constant delay, which is recommended to be at least twice the propagation delay of the wireless technology being used, h is the number of hops in the route record which is appended to the route reply, and r is random number between 0 and. In this manner, nodes which reply with longer routes to the target node will send their reply later than those with shorter routes. Each node goes into promiscuous receive mode while it waits for the delay to expire and if it receives a route reply with the same source and destination, but fewer hops, it cancels its Route Reply. While it is necessary to do something to prevent inter-symbol interference, there is a disadvantage to this optimization. Information is lost when the nodes cancel their Route Replies. The routes formed through these nodes, while longer, could still be used in the event that the shorter route is broken. A possible solution is to delay the Route Reply before sending it anyway. This would avoid the congestion while still getting as much information about the network as possible.

22 2 B Path to D Route Reply C S A D E Figure 3-2: Route Reply Storms. The group of mechanisms by which DSR ensures that the routing table remains current is called Route Maintenance. The basic requirement of Route Maintenance is that each node be responsible for ensuring that any packet it forwards reaches the next hop. The failure of a node to acknowledge receipt of a packet causes the previous node to return a Route Error to the source of the packet. As with Route Replies, the Route Error generally follows a path to the source found in the routing table, but may use a reversal of the current route record if bi-directional links are ensured. There are three ways a node may acknowledge receipt of a packet. One way is for the underlying MAC protocol to provide link-layer acknowledgement of packets. The 802. wireless MAC protocol is an example of such a protocol. The second way is for the transmitting node to receive acknowledgement when the next hop broadcasts the packet in its attempt to forward it to the next node in the source route. Lastly, should neither of these options be available, DSR may be configured to require a network layer acknowledgement. This acknowledgement may be sent directly to the previous hop only if bi-directional links are ensured. However, the presence of bi-directional links would in most cases mean that either the previous hop would overhear the packet being forwarded or that a MAC protocol requiring link-layer

23 3 acknowledgement is being used. In most cases it will therefore be necessary for any DSR specific acknowledgement to follow a multi-hop path. More important to the efficacy of the protocol is what to do in the case that a route failure is discovered. In DSR, when a node receives a Route Error, it discards the entire associated route and initiates a Route Discovery to attempt to find a new route to that destination. Figure 3-3 shows a simple example of a Route Error and the associated Route Discovery. In the first picture from this example node A communicates with node F using a source route through nodes B and C. It is assumed that nodes D and E were not present when this source route was discovered and therefore are unknown to node A. In the second image, node C has moved out of range of node B and a packet is dropped as a result. As a result, node B transmits a Route Error packet back to the source node A, which must remove the broken route from its route cache and initiate a rediscovery. The Route Discovery packet is then broadcase in turn from nodes A, B, D, and E until it is received at node F. Node F then transmits a Route Response back to node A, which caches the new route and resumes data packet transmission. The storage and use of routes in the routing table can make DSR a very powerful protocol. A node may cache the route records of overheard Route Replies, Route Requests, or data packets in its routing table and use them later either to forward a packet or return to another node requesting a route to a node on that route record. However, should the link through which the node overheard the information be unidirectional, the route would not function. In Figure 3-4, node Y might overhear a Route Reply from node C with the route record C, D, and E. Since the link from C to Y is unidirectional, any attempt by Y to use this route will be unsuccessful. Therefore, a node using overheard information must ensure that the link by which it received the information is bidirectional before caching or using it. Dynamic Source Routing provides basic principles which are very useful for de-

24 4 C Packet: A,B,C,F C Packet: A,B, Error B F B F A A D E D E A. B. Error: B A Discovery: A F A B F A B F D E D E C. D. B F A B F A D E D E E. F. B F Response: A,B,D,E,F A B F D E A D E G. H. Figure 3-3: An example of DSR Route Maintenance.

25 5 A B C D E X Y Z Figure 3-4: The unidirectional path problem. signing a protocol for use in the underwater environment. The reactive nature of the protocol makes it an ideal starting point given the high latency and unstable topology inherent to an Autonomous Undersea Vehicle network. However, given these same problems, the use of unbounded flooding as defined in Route Discovery is considered to be undesirable. A localized route determination is preferred, particularly for use in Route Maintenance to avoid a complete flooding of the network for each change in topology resulting in route failure. Methodologies to limit flooding in the network are explored in subsequent chapters of this thesis.

26 Chapter 4 Other Work in Ad Hoc Routing There has been some attempt in other variations of the DSR protocol and other ad hoc routing protocols to handle link failure and subsequent rediscovery in a more intelligent way. The main goal is to lower the routing overhead associated with Route Request and Route Reply messages used in the Route Discovery and Route Maintenance processes. The works discussed in this section all build upon the framework of either DSR or AODV, but some of the optimizations lead to questions about whether the new protocols are suitable for underwater networks. In this chapter we will critically analyze the protocols proposed and discuss their efficacy and possible ways to improve them. Some papers attempt to divide the networks into partitions in order to create a multilayered network. One such paper proposes the use of Way Point Routing (WPR) [], in which certain nodes are selected to function as Way Points, which divide the network into segments. In theory any two protocols could be used for intra-segment and inter-segment routing, but in this example inter-segment routing is controlled by DSR, while intra-segment routing is handled by the Ad Hoc On- Demand Distance Vector (AODV) routing protocol []. AODV is a distributed routing protocol, meaning that each node contains a routing table with the next address of the next hop needed to reach any destination. The use of both DSR and AODV allows link failure to be handled locally by AODV and Way Point failure to be handled globally by DSR without throwing out the entire route. 6

27 7 Another protocol that partitions the network is the Ad Hoc On-Demand Distance Vector Protocol with Load Balancing (LB-AODV) [4]. This protocol s intention is to reduce overhead by restricting traffic to within groups and designating a group of common nodes to route traffic between the groups. The number of groups is selected so that the difference between the optimal number of mobile nodes (defined as the number of nodes so that each node has 7 neighbors) and the number of mobile nodes that can relay packets from each group is minimal. The number of groups is a tradeoff between the network connectivity and the amount of routing control overhead. [4]. Both LB-AODV and WPR have several similar disadvantages. First, by restricting the paths between nodes, they limit the adaptability of the network. There are fewer available alternative paths in the case of a link disruption. There will also be more congestion over the links between sections and a higher chance of packet loss due to queue overflow. Second, neither paper presents an alternative for the possibility that a section of the network is cut off from the nodes it is allowed to communicate with. In such a case the sectional nature of the protocol would prevent the network from adapting to the new topology and a node could be lost. Speed of recovery from an error is an important consideration of the network and neither of these protocols satisfactorily considers it. The Congestion Adaptive Routing Protocol (CRP) [5] attempts to reduce routing overhead due to errors and speed up error recovery by discovering and storing multiple routes for a single source and destination. One route is chosen as the primary, while the other routes are used as bypasses in the case of primary link failure. When a link in the primary route fails, the message is sent back along that route until it reaches a bypass that has a destination after the failed link. At that point, the bypass is used as the primary route. If the message reaches the source node, a new primary route must be found. An issue that is not considered in CRP is the way in which the

28 8 additional bypass routes are discovered. A single Route Discovery can return multiple routes to the same destination, but some overhead is incurred since it must be assured that multiple routes are found. CRP is also mainly designed to avoid and adapt to congestion. It uses periodic congestion reports to inform the network of which links are congested and route around them using the bypass routes. Since our goal is to minimize the number of packets transmitted, this method of congestion adaptation is not useful to us. Another technique for enhancing Route Maintenance is Query Localization [4]. When a route fails, instead of flooding the network with Route Discoveries, the old route is appended to each Route Discovery message and a counter and threshold value is set to prevent the message from diverging too much from the old route. Every time the Route Discovery reaches a node that is not on the old route, the counter is incremented. When the counter reaches the threshold value, the Route Discovery is dropped. The idea is that when a node moves it is unlikely that the topology will be very different, so the new route should be somewhat similar to the old one. The issue with Query Localization is that it makes assumptions about the topology of the network. It will only work if the network is highly interconnected so that possible paths between two nodes differ only by no more than the threshold. If the threshold is too high, the benefits of localization will be minimal. The other disadvantage of Query Localization is that it limits the amount of information gained from the network from each Route Discovery. There is value in knowing routes to as many nodes as possible. One of the strengths of DSR is that a lot of extra knowledge is gained for every packet sent, which can be used for sending future packets. The protocols outlined in the above sections represent a sample of the improvements to ad hoc routing. While these protocols each have interesting ideas, they were all designed for low-latency environments and their goals are therefore slightly dif-

29 9 ferent from ours. Because the propagation delay in acoustic networks is much larger than other factors, the cost of a long packet is not significantly greater than the cost of a short packet. Therefore, while routing protocols for radio frequency ad hoc networks tend to minimize overhead in terms of bits sent, the protocol we have designed for acoustic networks minimizes overhead in terms of number of transmissions.

30 Chapter 5 Mobile Undersea Routing Protocol The objective of this study is to discern an appropriate routing protocol for communication among fleets of autonomous vehicles in an underwater environment. DSR is a simple protocol which lays the groundwork for the desired application, but it was designed for low latency electromagnetic networks and must therefore be modified to facilitate the high latency of underwater communication. Flooding employed by Route Discovery and Route Maintenance is a major concern in an environment with a high cost per packet in transmission time. The proposed Mobile Undersea Routing Protocol (MURP) improves upon DSR s Route Maintenance with the goal being quicker recovery from errors as well as fewer total transmissions. The mechanism which we have developed for this purpose is called Route Recovery. It replaces the use of full Route Discovery in Route Maintenance and allows for more localized repair of broken routes. The Route Recovery mechanism functions as follows. Instead of propagating Route Errors back to the source and allowing rediscovery to occur there, the node creating the error attempts a single Route Request with a time to live (TTL) set based on the number of remaining nodes on the original source route. The theory behind initiating the route repair from the source of the error as opposed to the source of the original route is based on the fact that in a wireless network the connectivity of the nodes is dependent on physical locality. The next shortest path to the destination is likely to pass through or near the error source since it is likely to be in between the 20

31 2 source and destination. The other reason to start the recovery at the error source is that the transmissions used to return back to the original traffic source are costly in the underwater environment. A TTL field in the route header is used to limit the progagation of the recovery transmission to the local area around the error source. A TTL is an integer valued field set in the packet s header which is initialized to a predetermined value and then decremented at every hop which forwards the packet. Once the TTL reaches zero, the node receiving the packet ceases forwarding it and drops the packet. TTLs are used in many networks to prevent an unbounded exponential propagation of every packet. In this case, since packet transmission underwater is expensive, we use TTL to decrease the overhead associated with Route Discovery. However, a full Route Discovery is still used in the case where local Route Recovery is not economical due to an error occuring at great distance from the destination. It is also used to initialize a node s view of the network prior to transmitting data packets. An example of a Route Recovery is shown in Figure 5-. This contrasts sharply to using DSR s response to errors using Route Maintenance, as shown in Figure 3-3 and discussed in the prior chapter. As in the prior example, in the first image node A has a route to node F through nodes B and C and using this route to send data packets. When node C moves out of communication range of node B, the route is broken and the packet is lost. However, unlike in the example from the previous chapter, instead of sending a Route Error packet to node A, node B originates a Route Recovery marking A as the original source and F as the destination. Nodes D and E receive this transmission in turn and forward it on until it reaches the destination at node F. Once F receives the Route Recovery, it sends the Route Response along the accumulated source route, which includes the truncated original source route from A to B and all nodes which the recovery passed through to reach its destination. At

32 22 this point node A can resume data packet transmissions to F using this new source route. The protocol is configured with a constant minimum TTL to ensure that the request propagates even if very few nodes are left. A constant maximum TTL, above which a Route Recovery is not initiated, is also used to ensure the recovery s scope is not too broad. A recovery bit is set in the error header to notify the source that a recovery was attempted. The source node will then delay its rediscovery attempt by some time large enough to allow the recovery to propagate back first, if successful. If a recovery was not initiated, the node will simply use a full Route Discovery. If the recovery is successful, the destination node will initiate a Route Reply back to the original source. The source should receive this reply prior to attempting the rediscovery and, having recached the lost route, abort the rediscovery and simply transmit a packet along the new route. The intent of this modification is to facilitate quick recoveries in instances where the destination is close by, but allow the source to use Route Discovery to rebuild the topology view with Route Discovery should this fail, or should the failure happen far from the destination. As shown in Figure 5-2, MURP s Route Recovery mechanism is designed to reduce flooding due to error recovery. In the first image of the diagram, a packet is shown traveling from the source to the destination along the thicker arrows and being between the third hop and the destination. The Route Error transmission is sent back to the source and a Route Discovery is initiated, which floods the entire network with packets attempting to reform a route to the destination. A new route to the destination is found, but at a high cost in both time and packet transmissions. In the second image of the diagram, the same error condition occurs, but a Route Recovery with TTL of 2 hops is used in place of the Route Error and full Route Discovery. The Route Error is appended to the Route Recovery to ensure that the source ceases

33 23 C Packet: A,B,C,F C Packet: A,B, Error B F B F A A D E D E A. B. Recovery:A F A B F A B F D E D E C. D. A B F A B F D E D E Response: A,B,D,E,F E. F. Figure 5-: An example of route repair.

34 24 to use the broken route to deliver data packets. The Route Recovery travels to the destination, but is prevented from flooding the entire network with the use of the TTL. It should also be noted that the recovery reaches the destination a full two round trip times earlier in this case due to the Route Recovery being initiated at the error source rather than the original source. In the above example, one hop was remaining on the original source route and two hops were required to route around the broken link. As shown in Figure 5-3, when a network is assumed to be well conneted, the required TTL for a Route Recovery to reach the destination is likely to be one more than the number of hops remaining in the original route. Higher TTL values would be required for loosely connected networks in which few alternate paths exist and each recovery must travel far from the original path to reach its destination. For the experiments in this research, we limit the recoveries to a small TTL with a factor of.5 times the number of hops remaining on the original source route, with a minimum of 2 hops to handle the least case and a maximum of 2 hops to further restrict the scope of the recoveries. This we do under the assumption that localized repair is most valuable under minimal scope. In cases in which the calculated TTL would cause the message to propagate to a large portion of the network, we prefer a full discovery to obtain a complete refresh of the topology information. There are a number of possible measures for success of any routing protocol. From among those we have chosen the three which we feel are most important given the underwater environment. One measure is the total number of transmissions used for packet delivery, including both data packets and packets used for routing mechanisms. In some networks it is desirable to use the routing overhead alone as a data point. However, due to the high cost of each packet transmission in the underwater environment, we choose to use the total packet cost instead of this measure. Another

35 25 RD RD RD RD RD RD S RD RE RD RE RD RD RD RD RD D RD Route Error and Re-Discovery RR RE/RR RE/RR RR RR S D RR RR Route Recovery TTL=2 Figure 5-2: Comparison between Route Discovery and Route Recovery responses to error.

36 26 RE/RR RE/RR RR RR S D Error Hop From Destination TTL=2 required RR RE/RR RR RR RR S D Error 2 Hops From Destination TT=3 required RR RR RR RR RR S RR D Error 3 Hops From Destination TTL=4 required (assuming no reply with cached info) Figure 5-3: Comparison between Route Recoveries at,2, and 3 hops from the destination and the Required TTLs.

37 27 possible measure is the end-to-end delivery time. This would measure the difference between the time the packet is transmitted and the time the packet is received at the destination. We reject this measure as well, since the time taken to deliver each packet for which no error occurs would have a strong influence on this number and is unrelated to the capabilities of the of the routing protocol. The distance between source and destination, which is likely to vary randomly due to the random nature of topologies used, could also have an impact on this measure. We are more interested in the period of time taken by the network to recover from an error. Therefore we measure the recovery time, which is calculated as the difference between the time an error occurs and the time the next packet for that traffic source is received at the destination. This allows us to represent the responsiveness of the protocol to error conditions without respect to the above mentioned variables. A common measure of network performance is throughput. It is the number of successful message deliveries per unit of time. Throughput is often measured in bits per second, but given fixed packet length can be simplified to packets per second. For these experiments, we choose to separate from the time variable and simply consider the percentage of packets delivered over the course of the simulation. This is to show more accurately the reliability of the protocol independently of the speed of delivery. It also prevents the distance between source and destination from having a measurable effect on the statistic. With these measures, we will show MURP to be an efficient and robust protocol.

38 Chapter 6 Simulator In order to facilitate the experiments required for this project, we created network simulator program in the Java programming language. This program utilizes the latest in enterprise Java technology, the Spring programming framework. Spring provides a number of key components in its framework, the most useful of which is the ability to initialize a program and define objects using XML. The object which facilitates this is the FileSystemXmlApplicationContext. When provided with an XML file, this object attempts to initialize all objects defined in the file and set property values given in the object definition. This allows us to modify parameters and, in particular, object types at runtime, without the use of a scripting language such as TCL or a complex property file reading and interpreting process within the Java code. The second key component utilized in the simulator program is inheritance. While this is one of the most basic Java principles, it is critical for the simplicity of the program. We use a shared abstract super class to define all protocols. This class defines how each implementation of a protocol should function, and following this implementation ensures that the protocol will fit into the simulator code without modification to the main simulator program. Any protocol implementation must have a send method and a receive method. The simulator stores each protocol and calls its send or receive method based on events that occur in other protocols or in the simulator s initializing method. The simulator code has references to the specific 28

39 29 protocols used for the simulation. All protocols are stored as the abstract Protocol object, or as in the case of the routing protocol, a more specialized abstract extension of the Protocol class is used to tailor a set of protocols to a specific layer and allow for more layer specific functionality. The program uses a Model-View-Controller architecture which focuses primarily on the controller portion. The view is simplified to a series of logging statements and a print of statistical data at the program s completion. Statistical analysis can be performed both within each protocol and by a separate protocol which watches for events caused by other protocols. In this way statistics can be as simple or complex as the implementor designs. The model is maintained in memory and consists of a set of protocols, a set of agents which represent the topology, and packet objects which are generated by the simulator and by each protocol. The relationships of the classes in the model are outlined in the UML class diagram pictured in Figure 6-. Each packet corresponds to a set of event objects which represent the handling of that packet by a specific protocol at a specific node agent. These events are stored in a priority queue object which is sorted based on the time the event is set to occur. An insertion sort algorithm is implemented as part of the queue and is maintained within the queue implementation. The SimulatorController class runs a loop which pulls the first event from the queue and processes it through the appropriate protocol and as a result generates future events. The SimulatorController class contains references to all protocols, the topology, and the EventQueue class. Each protocol also contains a reference to the topology to allow it to make determinations about the location of nodes and calculate their impact on events generated by that protocol. The time associated with an event is determined by the protocol which generates it. In the case of inter-node communication, an event is generated for every node in range of communication. The group of nodes in range, and the arrival time at each node, is

40 30 determined based on the topology model. Any implementation of a topology model must provide an implementation of the NodeAgent class and that implementation must contain a method providing the location of a node at any given time, which is used by the data link layer protocol to determine the time at which a receive event occurs at that node. The EventQueue class is an extension of the PriorityQueue Java class which implements a comparator to sort its contents based on the time parameter in each Event object. An example of the ways in which events are handled in the queue is outlined in Figure 6-2. In the example, two traffic events, labeled Traffic and Traffic 2, are generated with times 0 and 20 respectively. Traffic event is evaluated first and results in the creation of send event labeled Send A and assigned time 0. Since that event preempts the second traffic event, it is executed first and two receive events are generated based on it. The first is labeled Receive A and given time of 0 and the second is labeled B and assigned a time of 30. The difference is assumed to be based on a difference in propagation delay between the nodes the events represent. Therefore, it is shown in the diagram that Receive A will evaluate before Traffic 2, and Receive B will evaluate afterwards. When Receive A is processed, it generates another send event called Send B. Since we assume that the time to process and transmit is neglegible in this case, the time assigned to the send event is 0 also. The sequence will continue like this until all events have been processed. In this case we consider only generic send and receive event types, rather than the link layer and route layer send and receive events separately, in order to simplify the diagram. Related send and receive events occuring within the same node will always occur in the order of the layers processing due to the natural order of insert provided by the queue for events with equivalent time values. Each event remains in memory until processed and removed from the queue, at which point it becomes eligible for garbage

41 3 collection and will be deleted. The absence of database persistence facilitates quicker processing through reduced I/O time. However, this also results in significant memory usage for each simulation. Simulations for this research used between and 2 gigabytes of memory on average. The controller handles all interaction between the protocols. Each event contains a type identifier which corresponds to a specific protocol layer and direction of transmission. The controller uses this field to determine what protocol to use and which method to call. To facilitate the above mentioned statistical analysis, a set of event types are also provided which reference methods in the Statistics class to collect data. Each protocol must generate the requisite events for the next layer in the stack as well as any desired statistic events. For example, the protocol must generate an application layer receive event when a packet arrives at its destination and data link send events each time it needs to forward a packet. For the purposes of this project, we have simplified the protocol stack to combine data and link layers and eliminated the transport layer, assuming it to use the simple Universal Datagram Protocol. These protocols could be easily implemented by adding references and corresponding events to the controller and modifying the existing protocols to create the appropriate events. Each protocol implementation should also be complemented by a header class. To avoid interoperability issues, a protocol should only use information from its corresponding header. Cross-layer communication is not currently supported, but will be implemented in future work. Upon initialization the simulator generates one packet automatically, as well as the corresponding application layer send event, for each traffic agent. The application layer protocol then executes that event, generates the route layer send event for that packet, and creates the application layer send event for the subsequent packet. In our experiments we use a Constant Bit Rate application protocol, such that the

42 32 next application send event is set to the current time with an added configurable delay. The event queue s sorted insert ensures that these and all subsequent events are processed in the correct order. The simulator program runs on a loop to easily average the results of multiple experiments for each chosen configuration. It generates a new topology and traffic model for each iteration and tabulates the results in the statistics object. Averages and standard deviations of each statistic item are output after all iterations have completed. In order to run simulations using this program, the user needs a set of jar files containing simulator source code and other required libraries, a shell script to start the simulator, a configuration file for logging, and a spring configuration file which will define the parameters for the simulation. The required jar files are spring.jar, log4j.jar, commons-logging.jar and the provided simulator source code, which we named murp.jar after this project. A log4j.properties file must also be included to define the behavior of the logging utility and direct its output. We recommend sending logging output to a file and reserving the standard output for the end of simulation results. The shell script must set the location of each of these things to the class path and then run a Java command to start the simulator. This command must specify a maximum heap size (we use 4096 mb) or else the simulator may run out of memory on larger topologies. The main class to start the simulator is in com.murp.simulator.controller.simulatorcontroller. This class takes the path of the spring config file and the log4j property file as arguments. The log file will print every event in order as it processes, which is mainly useful for debugging protocols. The parameters of the simulation will print to the standard output prior to each run, and statistical results will print after each run for the topology in question. Averaged results for all runs will be printed at the end of the simulation. We recommend redirecting standard output to a separate file for each simulation run. When using one of

43 33..* EventQueue extends PriorityQueue..* values Event nodeagent..* trafficagent Packet eventqueue nodeagent routingheader applicationheader datalinkheader statheader datalinkprotocol SimulatorController applicationprotocol routingprotocol topology NodeAgent..* nodeagents Topology Header Protocol topology trafficagents..* TrafficAgent Figure 6-: Simulator class diagram. the included random topology generators, such as the Random Waypoint Model, the topology must be configured with the xmldirectory property. This property defines the location to which a copy of generated XML for each topology is saved and will allow the viewing of the topology that is generated for debugging purposes. Currently, if the simulator is configured for multiple runs, only the last XML file will be saved since the naming convention is based on the size and type of topology. In the future an incremental value will be used to save all topologies for each execution of the simulator program.