An Adaptive Routing Algorithm for Wireless Mesh Networks

An Adaptive Routing Algorithm for Wireless Mesh Networks Minseok Oh Department of Electronic Engineering, Kyonggi University, Suwon, Korea [email protected]

Abstract ⎯ Ad hoc networks can be very mobile, where mobile nodes (MNs) are moving frequently relative to one another. The faster the MNs are moving, the more the routing information is required to keep each MNs informed of the route information to other MNs. This paper proposes a hybrid routing algorithm, whose behavior is modified dynamically based on MN's mobility in the network. This would allow using proactive algorithms when a network has low mobility, and allow using reactive algorithms when a network becomes very mobile. In this paper, Destination Sequenced Distance Vector (DSDV) is used as a proactive routing algorithm and Ad hoc On-Demand Vector (AODV) is used as a reactive algorithm. Keywords ⎯ routing protocol, mesh network, ad-hoc network.

1. Introduction Traditional wireless networks are based on the presence of an infrastructure providing wireless access for network connectivity to wireless terminals. This paradigm has reigned for many years in cellular networks, enterprise networks, and variety of public/private networks. However, a new paradigm is becoming more and more popular: peer-to-peer communication, where wireless nodes communicate with each other and create ad hoc mesh networks independently of the presence of any wireless infrastructures. The rapid diffusion of IEEE 802.11 (WLAN) access and the increasing demand for WLAN coverage is driving the installation of a very large number of access points (APs). Although the cost of APs is traditionally not very high (in particular, compared to the cost of cellular equipments), the deployment of APs requires connecting the APs through a wired connection (traditionally Ethernet), and this introduces complexity and high costs for deployment in certain locations. Moreover, due to the limited range of coverage of 802.11, APs may need to be moved often in order to accommodate the increasing traffic demands. Therefore, the deployment of APs by interconnecting them through a wireless link, and specifically the creation of mesh networks based on 802.11, has become an indispensable technique for the growth of next-generation wireless networks. In an IEEE 802.11 mesh network, routing is essential to allow communication between MPs. The IETF MANET working group concentrates on standardizing IP (layer 3) routing protocol functionality suitable for wireless ad hoc networks. They consider two types of protocols, proactive routing protocols and reactive routing protocols [1]. In the proactive routing protocols, nodes periodically exchange

ISBN 978-89-5519-136-3

-2087-

routing tables and maintain the entire topology of the networks, with each node knowing the shortest path to each node in the network. Destination Sequenced Distance Vector (DSDV) and Optimized Link State Routing (OLSR) are commonly used proactive routing algorithms [2]. In the reactive routing protocol, routes are established on demand. Dynamic Source Routing (DSR) and Ad Hoc On-Demand Vector (AODV) are the most commonly used reactive protocols [2]. Proactive algorithms are useful in small networks because the routing overhead in maintaining the routes is low, and since the network size is small, the memory requirement to store the routing table is also low, thus minimizing the delay due to routing table lookups. On the contrary, reactive algorithms are preferable when the network size is large, since the need to store routes towards all the destinations would impose considerable memory requirement and cause lookup delays. The size of mesh networks and the level of mobility depend upon the usage scenario. Mesh networks can be very dynamic networks (i.e., MPs are being added/moved/removed frequently). Therefore, the use of any single routing algorithm, either proactive or reactive, would not be efficient. An adaptive routing algorithm can be used to overcome this issue, whose behavior is modified dynamically by monitoring the change in the network parameter (e.g., size, dynamicity, mobility, etc.) This paper proposes an adaptive routing algorithm, where a proactive algorithm is used when a network has low mobility, and a reactive algorithm is applied when a network becomes very mobile. The algorithm can modify its behavior in real time as the network mobility changes. The paper is organized as follows: In Section II the two different types of routing protocols are described. In Section III, a new adaptive routing protocol is introduced and finally Section IV summarizes the proposal.

2. Two types of routing protocols in wireless ad-hoc networks In this paper the DSDV and AODV routing algorithms are chosen as proactive and reactive algorithms, respectively. Both algorithms are briefed in the following subsections. A. Destination-Sequenced Distance-Vector (DSDV) Routing In traditional distance-vector algorithms, every node i maintains, for each destination x, a set of distances {dij(x)} for each node j that is a neighbor of i. Node i treats neighbor k as a

Feb. 17-20, 2008 ICACT 2008

next hop for a packet destined for x if dik(x) equals minj{ dij(x)}. The succession of next hops chosen in this manner leads to x along the shortest path. To keep the distance estimates up to date, each node monitors the cost of its outgoing links and periodically broadcasts, to all of its neighbors, its current estimate of the shortest distance to every other node in the network. The distance-vector algorithm just described is the classical Distributed Bellman-Ford (DBF) algorithm [3]. Compared to link-state algorithms, it is computationally more efficient, is easier to implement, and requires much less storage space. However, it is well known that this algorithm can cause the formation of both short-lived and long-lived loops [4]. The primary cause for formation of routing loops is that nodes choose their next hops in a completely distributed fashion on the basis of information that may be stale and therefore incorrect. Almost all proposed modifications to the DBF algorithm [5] [6] [7] eliminate the looping problem by forcing all nodes in the network to participate in some form of internodal coordination protocol. Such internodal coordination might be effective when topological changes are rare. However, within an ad hoc mobile environment, enforcing any internodal coordination mechanism will be difficult because of the rapidly changing topology of the underlying routing network. Simplicity is one of the primary attributes that make any one routing protocol preferred over others for implementation within operational networks. The Routing Information Protocol (RIP) [8] is a well-known example for the DBF algorithm. Despite the counting-to-infinity problem, it has proven to be very successful within small internetworks. The usefulness of RIP within an ad hoc environment, however, is limited, as it was not designed to handle rapid topological changes. Furthermore, the techniques of split horizon and poisoned reverse [8] are not useful within the wireless environment for devices that have a single network interface to a restricted broadcast transmission medium. For these reasons, the design goal for an ad hoc mobile environment has been a routing method that preserves the simplicity of RIP yet at the same time avoids the looping problem. The approach is to tag each route table entry with a sequence number so that nodes can quickly distinguish stale routes from the new ones and thus avoid formation of routing loops. Consider a collection of mobile computers, which may be far from any base station that can exchange data along changing and arbitrary paths of interconnection. The computers must also exchange control messages so that all computers in the collection have a (possibly multihop) path along which data can be exchanged. The solution must remain compatible with operation in cases where a base station is available. Packets are transmitted between the nodes of the network using routing tables stored at each node. Each routing table, at each of the nodes, lists all available destinations and the number of hops to each. Each route table entry is tagged with a sequence number that is originated by the destination node. To maintain the consistency of route tables in a dynamically varying topology, each node periodically transmits updates, doing so immediately when significant new information is available. Since we do not assume that the MNs are

ISBN 978-89-5519-136-3

-2088-

maintaining any sort of time synchronization, we also make no assumption about the phase relationship of the update periods between the mobile hosts. These update packets indicate which nodes are accessible from each node and the number of hops necessary to reach them, following traditional distance-vector routing algorithms. (Cost or other metrics might easily replace the number of hops in other implementations) We may permit packets to be transmitted containing either layer-2 (MAC) addresses or layer-3 (network) addresses. Routing information is advertised by broadcasting or multicasting the packets that are transmitted periodically and incrementally as topological changes are detected, for instance, when nodes move within the network. Data is also kept about the length of time between the arrival of the first route and the arrival of the best route for each particular destination. On the basis of the time length, a decision may be made to delay advertising routes that are about to change, thus damping fluctuations of the route tables. The advertisement of possibly unstable routes is delayed to reduce the number of rebroadcasts of possible route entries that normally arrive with the same sequence number. B. Ad hoc On-demand Distance Vector (AODV) Routing The AODV algorithm enables dynamic, self-starting, multihop routing between participating MNs wishing to establish and maintain an ad hoc network. AODV allows MNs to obtain routes quickly for new destinations, and does not require nodes to maintain routes to destinations that are not in active communication. AODV allows MNs to respond to link breakages and changes in network topology in a timely manner. The operation of AODV is loop-free, and by avoiding the Bellman-Ford "counting to infinity" problem offers quick convergence when the ad hoc network topology changes (e.g., when a node moves in the network). When links break, AODV causes the affected set of nodes to be notified so that they are able to invalidate the routes using the lost link. AODV uses symmetric links between neighboring nodes. It does not attempt to follow paths between nodes when one of the nodes cannot hear the other one. Nodes that do not lie on active paths neither maintain any routing information nor participate in any periodic routing table exchanges. When the local connectivity of the MN is of interest, each MN can become aware of the other nodes in its neighborhood by the use of several techniques, including local (not system-wide) broadcasts known as hello messages. The routing tables of the nodes within the neighborhood are organized to optimize response time to local movements and provide quick response time for requests for establishment of new routes. The algorithm's primary objectives are three-fold: to broadcast discovery packets only when necessary, to distinguish between local connectivity management (neighborhood detection) and general topology maintenance, and to disseminate information about changes in local connectivity to those neighboring MNs that are likely to need the information. Route Requests (RREQs), Route Replies (RREPs), and Route Errors (RERRs) are the message types defined by AODV. These message types are received via UDP, and normal IP header processing applies. So, for instance, the

Feb. 17-20, 2008 ICACT 2008

requesting node is expected to use its IP address as the originator IP address for the messages. For broadcast messages, the IP-limited broadcast address (255.255.255.255) is used. This means that such messages are not blindly forwarded. However, AODV operation does require certain messages (e.g., RREQ) to be disseminated widely, perhaps throughout the ad hoc network. The range of dissemination of such RREQs is indicated by the TTL in the IP header. Fragmentation is typically not required. AODV uses a broadcast route discovery mechanism [9], as is also used (with modifications) in the Dynamic Source Routing (DSR) algorithm [10]. Instead of source routing, however, AODV relies on dynamically establishing route table entries at intermediate nodes. This difference pays off in networks with many nodes, where a larger overhead is incurred by carrying source routes in each data packet. To maintain the most recent routing information between nodes, the concept of destination sequence numbers from DSDV is used [11]. Unlike in DSDV, however, each ad-hoc node maintains a monotonically increasing sequence number counter which is used to supersede stale cached routes. The combination of these techniques yields an algorithm that uses bandwidth efficiently (by minimizing the network load for control and data traffic), is responsive to changes in topology, and ensures loop-free routing. The path discovery process is initiated whenever a source node needs to communicate with another node for which it has no routing information in its table. Every node maintains two separate counters: a node sequence number and a broadcast id. The source node initiates path discovery by broadcasting a route request (RREQ) packet to its neighbors. The RREQ contains the fields . The pair uniquely identifies a RREQ. broadcast_id is incremented whenever the source issues a new RREQ. Each neighbor either satisfies the RREQ by sending a route reply (RREP) back to the source, or rebroadcasts the RREQ to its own neighbors after increasing the hop_count. Notice that a node may receive multiple copies of the same route broadcast packet from various neighbors. When an intermediate node receives a RREQ, if it has already received a RREQ with the same broadcast_id and src_addr, it drops the redundant RREQ and does not rebroadcast it. If a node cannot satisfy the RREQ, it keeps track of the following information in order to implement the reverse path setup, as well as the forward path setup that will accompany the transmission of the eventual RREP. There are two sequence numbers included in a RREQ (in addition to the broadcast_id): the source sequence number and the last destination sequence number known to the source. The source sequence number is used to maintain freshness information about the reverse route to the source, and the destination sequence number specifies how fresh a route to the destination must be before it can be accepted by the source. As the RREQ travels from a source to various destinations, it automatically sets up the reverse path from all nodes back to the source [10], as illustrated in Figure 1. To set up a reverse path, a node records the address of the neighbor from which it

ISBN 978-89-5519-136-3

-2089-

received the first copy of the RREQ. These reverse path route entries are maintained for at least enough time for the RREQ to traverse the network and produce a reply to the sender. Figure 1 shows two reverse paths formed via RREQs. D

S

Figure 1. Reverse path formation

Eventually, a RREQ will arrive at a node (possibly the destination itself) that possesses a current route to the destination. The receiving node first checks that the RREQ was received over a bi-directional link. If an intermediate node has a route entry for the desired destination, it determines whether the route is current by comparing the destination sequence number in its own route entry to the destination sequence number in the RREQ. If the RREQ's sequence number for the destination is greater than that recorded by the intermediate node, the intermediate node must not use its recorded route to respond to the RREQ. Instead, the intermediate node rebroadcasts the RREQ. The intermediate node can reply only when it has a route with a sequence number that is greater than or equal to that contained in the RREQ. If it does have a current route to the destination, and if the RREQ has not been processed previously, the node then unicasts a route reply packet (RREP) back to its neighbor from which it received the RREQ. A RREP contains the following information: . D

Timeout S

Figure 2. Forward path formation

By the time a broadcast packet arrives at a node that can supply a route to the destination, a reverse path has been

Feb. 17-20, 2008 ICACT 2008

established to the source of the RREQ. As the RREP travels back to the source, each node along the path sets up a forward pointer to the node from which the RREP came, updates its timeout information for route entries to the source and destination, and records the latest destination sequence number for the requested destination. Figure 2 represents the forward path setup as the RREP travels from the destination D to the source node S. Nodes that are not along the path determined by the RREP will timeout after active_route_timeout and will delete the reverse pointers. A node receiving an RREP propagates the first RREP for a given source node towards that source. If it receives further RREPs, it updates its routing information and propagates the RREP only if the RREP contains either a greater destination sequence number than the previous RREP, or the same destination sequence number with a smaller hop count. It suppresses all other RREPs it receives. This decreases the number of RREPs propagating towards the source while also ensuring the most up-to-date and quickest routing information. The source node can begin data transmission as soon as the first RREP is received, and can later update its routing information if it learns of a better route. In addition to the source and destination sequence numbers, other soft state information is also stored in the route table entries. Associated with reverse path routing entries is a timer, called the route request expiration timer. The purpose of this timer is to purge reverse path routing entries from those nodes that do not lie on the path from the source to the destination. The expiration time depends upon the size of the ad-hoc network. Another important parameter associated with routing entries is the route caching timeout, or the time after which the route is considered to be invalid. In each routing table entry, the address of active neighbors through which packets for the given destination are received is also maintained. A neighbor is considered active (for a destination) if it originates or relays at least one packet for that destination within the most recent active_timeout period. This information is maintained so that all active source nodes can be notified when a link along a path to the destination breaks. A route entry is considered active if it is in use by any active neighbors. The path from a source to a destination, which is followed by packets along active route entries, is called an active path. Note that, as with DSDV, all routes in the route table are tagged with destination sequence numbers, which guarantee that no routing loops can form, even under extreme conditions of out-of-order packet delivery and high node mobility. A MN maintains a route table entry for each destination of interest. Route table information must be kept even for short-lived routes, such as are created to temporarily store reverse paths towards originating RREQs. Each route table entry contains the following information: - Destination IP Address - Next Hop - Hop Count (metric) - Destination Sequence Number - Valid Destination Sequence Number flag - Other state and routing flags (e.g., valid, invalid, repairable, being repaired)

ISBN 978-89-5519-136-3

-2090-

- List of Precursors (active neighbors for this route) - Lifetime (expiration or deletion time of the route) - Network Interface Each time a route entry is used to transmit data from a source toward a destination, the timeout for the entry is reset to the current time plus active_route_timeout. Movement of nodes not lying along an active path does not affect the routing to that path's destination. If the source node moves during an active session, it can reinitiate the route discovery procedure to establish a new route to the destination. When either the destination or some intermediate node moves, a special RREP is sent to the affected source nodes. Periodic hello messages can be used to ensure symmetric links, as well as to detect link failures. Alternatively, and with far less latency, such failures could be detected by using link-layer acknowledgments (LLACKS). A link failure is also indicated if attempts to forward a packet to the next hop fail. Nodes monitor the link status of next hops in active routes. When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred. The RERR message indicates those destinations (possibly subnets) which are no longer reachable by way of the broken link. In order to enable this reporting mechanism, each node keeps a "precursor list", containing the IP address for each its neighbors that are likely to use it as a next hop towards each destination. The information in the precursor lists is most easily acquired during the processing for generation of a RREP message, which by definition has to be sent to a node in a precursor list. Upon receiving notification of a broken link, source nodes can restart the discovery process if they still require a route to the destination. To determine whether a route is still needed, a node may check whether the route has been used recently, as well as inspect upper-level protocol control blocks to see whether connections remain open using the indicated destination. If the source node (or any other node along the previous route) decides it would like to rebuild the route to the destination, it sends out an RREQ with a destination sequence number of one greater than the previously known sequence number, to ensure that it builds a new, viable route, and that no nodes reply if they still regard the previous route as valid. Nodes learn of their neighbors in one of two ways. Whenever a node receives a broadcast from a neighbor, it updates its local connectivity information to ensure that it includes this neighbor. In the event that a node has not sent any packets to all of its active downstream neighbors within hello_interval, it broadcasts to its neighbors a hello message (a special unsolicited RREP), containing its identity and sequence number. The node's sequence number is not changed for hello message transmissions. This hello message is prevented from being rebroadcast outside the neighborhood of the node because it contains a time to live (TTL) value of 1. Neighbors that receive this packet update their local connectivity information to the node. Receiving a broadcast or a hello from a new neighbor, or failing to receive allowed_hello_loss consecutive hello messages from a node previously in the neighborhood, is an indication that the local connectivity has changed. Failing to receive hello messages

Feb. 17-20, 2008 ICACT 2008

from inactive neighbors does not trigger any protocol action. If hello messages are not received from the next hop along an active path, the active neighbors using that next hop are sent notification of link failure. The local connectivity management with hello messages can also be used to ensure that only nodes with bidirectional connectivity are considered to be neighbors. For this purpose, each hello sent by a node lists the nodes from which it has heard. Each node checks to make sure that it uses only routes to neighbors that have heard the node's hello message. To save local bandwidth, such checking should be performed only if explicitly configured into the nodes.

[6] J. J. Garcia-Luna-Aceves, "A Unified Approach to Loop-Free Routing Using Distance Vectors or Link States," Proc. ACM SIGCOMM '89, pp. 212-223, Sep. 1989 [7] P. M. Merlin and A. Segall, "A Fail-Safe Distributed Routing Protocol," IEEE Transaction on Communications, vol. 27, pp. 1280-1287, Sep. 1979 [8] G. Malkin, "RIP Version 2 - Carrying Additional Information, RFC 1388 (proposed standard)," Internet Engineering Task Force, Jan. 1993 [9] M. S. Corson and A. Ephremides, "A Distributed Routing Algorithm for Mobile Wireless Networks," ACM J. Wireless Networks, vol. 1 no. 1, Jan. 1995 [10] D. Johnson and D. Maltz, "Dynamic source routing in ad-hoc wireless networks," In Computer Communications Review, Proceedings of SIGCOMM '96, Aug. 1996 [11] C. Perkins and P. Bhagwat. Routing over Multihop Wireless Network of Mobile Computers. In Computer Communications Review, Proceedings of SIGCOMM '94, vol. 24, no. 4, pp. 234-244, Oct. 1994

3. Adaptive routing protocol We propose an adaptive routing algorithm, where the routing algorithm varies according to mobility of MNs in an ad-hoc network. The algorithm can modify its behavior in real time as the network mobility changes. We presume that mobility can be detected by link breakage. When link breakage with its neighboring nodes is detected, the node which is sending a packet to a destination uses DSDV as a routing algorithm. When link breakage is not detected for a certain amount of time, AODV is used as a routing algorithm. Every node in the network maintains two separate routing tables for proactive and reactive routing algorithms respectively. Routing updates collected from a routing algorithm are stored in the corresponding routing table.

4. Summary A new routing algorithm for mobile mesh network has been proposed. It changes the way it collects routing information based on the mobile nodes' mobility condition in the network. The scheme uses AODV when the mobility is high, and DSDV when it is low. Since the routing protocol adjusts itself to the network mobility, we are sure that it will reduce the routing information traffic, which leaves more resource for user traffic.

5. Acknowledgement This work was supported by Gyeonggi Regional Research Center (GRRC). REFERENCES [1] S. Corson and J. Macker, "Mobile Ad Hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations," IETF RFC 2501, Jan. 1999 [2] J. Broch et al., "A Performance Comparison of Multihop Wireless Ad Hoc Network Routing Protocols," Proc. IEEE MOBICOM, Dallas, TX, Oct. 1998 [3] D. Bertsekas and R. Gallager, "Data Networks 2/e," Prentice-Hall, Englewood Cliffs, NJ, 1992 [4] C. Cheng, R. Riley, S. P. R. Kumar, and J. J. Garcia-Luna-Aceves, "A Loop-Free Bellman-Ford Routing Protocol without Bouncing Effect," Proc. ACM SIGCOMM '89, pp. 224-237, Sep. 1989 [5] J. M. Jaffe and F. Moss, "A Responsive Distributed Routing Algorithm for Computer Networks," IEEE Transactions on Communications, vol. 30, pp. 1758-1762, July 1982

ISBN 978-89-5519-136-3

-2091-

Feb. 17-20, 2008 ICACT 2008