Traffic-Aware and Low-Overhead Routing Protocol for MANETs

Mohammed Alsheakhali, Fahed Awad

Department of Computer Engineering Jordan University of Science and Technology

Irbid, Jordan msm_705@yahoo.com, fhawad@just.edu.jo

Abstract - In this paper, a new routing protocol, called Traffic-Aware and Low-Overhead Routing Protocol (TALORP) is proposed. The TALORP protocol, which is an enhancements of the Low-Overhead Routing Protocol (LORP), uses backup routes to mitigate the flooding problem that is frequently used to repair link failures. It also takes into account the traffic flows on different paths toward the destination in order to select the shortest and the least-congested path. The simulation results demonstrated that TALORP achieves better performance compared to LORP under all traffic conditions in terms of packet delivery ratio and end-to-end delay but at the cost of higher routing overhead.

Keywords – Traffic-aware; Low-overhead; Ad hoc; MANET;

Routing; Performance evaluation; Simulation

I. INTRODUCTION

A mobile ad hoc network (MANET) consists of mobile nodes that are interconnected by wireless-multi-hop communication paths. Ad hoc networks have no fixed infrastructure. They can be created and used anytime and anywhere. The node in these networks acts as both a host and a router. Designing an efficient routing protocol for MANET is a great challenge due to the limited resources of the nodes such as network bandwidth, and battery power, and due to the mobility of nodes, which causes the network topology to change frequently. The frequent change in the topology occasionally causes some links to fail as neighboring nodes move away from each other. Therefore, repairing link failures and maintaining the active routing paths while coping with the nodes’ limited resources and maintaining acceptable overall performance is one challenging problem. In this paper, a new protocol, called Traffic-Aware and Low Overhead Routing Protocol (TALORP) that is based on the Low Overhead Routing Protocol (LORP) [8], is proposed. TALORP combines the benefits of using the hop count and the traffic intensity as metrics in the route selection process. TALORP selects the shortest path. However, if there are multiple shortest paths, it selects the path that has the least sum of waiting packets in the queues along this path.

II. RELATED WORK

The Ad-hoc On-demand Distance-Vector (AODV) routing algorithm [3] was designed for ad hoc mobile networks. Many routing protocols have been designed based on the AODV protocol which is adopted by the networking group of the Internet Engineering Task Force (IETF) [2].

Cheng et al. [8] proposed LORP that repairs the broken route by using information provided by nodes overhearing the main route's communication. When links go down, LORP intelligently replaces the failed links with backup ones that are adjacent to the main route. Simulation results demonstrated that this protocol achieves better performance than the major ad hoc routing protocols such as AODV and DSR in terms of the packet delivery ratio, control packet overhead, and communication delay under light and moderate traffic conditions. However, its performance is degraded under high traffic conditions. The reason for this degradation is that LORP does not guarantee the use of the shortest path during the route maintenance phase after a link is broken. In addition, it does not attempt to avoid the highly congested nodes along the route to the destination.

Vibrant et al. [9] proposed a load aware routing in ad hoc (LARA) networks protocol. LARA uses the traffic density and the hop count on the paths to decide which one to use. The traffic density at any node in LARA is defined as the sum of its queue length and the queue lengths of its neighbors. Each node will add its queue status in the hello messages, which are exchanged among the nodes, in order to allow each node to know the load information of its neighbor. LARA uses broadcast of control packets to discover and maintain the routing paths, which causes a large overhead.

III. THE TAILORP PROTOCOL

TALORP combines the benefits of the shortest path and the traffic-aware routing protocols by adding some modifications to LORP. These modifications were made to both the route construction and the route maintenance phases in order to ensure that the shortest and the least congested route to the destination is always used. The main difference between TALORP and LORP is that LORP uses the hop count as the primary metric only during the route construction

978-1-4244-2829-8/08/$25.00 ©2008 IEEE

phase given that no secondary metric is used. However, during the route maintenance phase, it attempts to recover the broken route as fast as possible using the first available alternative route regardless of whether it provides the shortest path to the destination or not. TALORP, on the other hand, uses the hop count as primary metric and the traffic intensity as a secondary metric during both the route construction and route maintenance phases. Therefore, LORP does not guarantee the use the shortest path to the destination while TALORP does. Hence, LORP performs a fast local route recovery process, while TALORP performs more of an optimum global route recovery process, which explains the expected additional control overhead incurred by TALORP.

A. Route Construction A routing path is constructed only when a node needs to

communicate with another node. Assume that a source node S needs to send a packet to some destination node D. The source node will first check if node D is in its main route table (MRT). If it is, packets will then be sent directly to the next-hop node as specified by the corresponding entry. If there is no route to node D, the main route construction process begins with the source node S sending a main route request (MREQ) to all its neighbors. Every host that receives the MREQ acts exactly the same as the source node does. MREQ is thus flooded over the network, and will eventually arrive at node D if a path exists.

When node D receives a MREQ, as shown in Fig. 1, it sends back a main route reply (MRRP) with the values H and Q to the node (say Z) from which MREQ was received. The value H represents the hop number from this node to the destination, and the value Q represents the sum of the queue lengths towards the destination. Once node Z receives MRRP for the first time, it does the following:

• Adds a main route entry for node D to its MRT. • Increments the H value by one. • Adds its interface queue length to the queue length

field in the MRRP. • Sends the MRRP, together with the new H and Q

values to the host from which it received the MREQ . Every host that receives MRRP for the first time acts the

same as node Z until node S receives the MRRP and updates its MRT accordingly.

When a node receives more than one MRRP from different paths, if the new MRRP has a greater hop count (larger H value) than the old MRRP, the new MRRP is discarded. When a node receives more than one MRRP with the same hop count, it compares their Q values. If the new MRRP has a greater Q value, it is discarded. If the new MRRP has a smaller Q values, the node updates its MRT, increments the H value, adds its queue length to the MRRP, and sends it to the node from which the MREQ was received. In Fig. 1, node S receives MRRP from the two different paths “D→Z→Y→X→W→S” and “D→E→C→B→A→S” with minimum hop count. Therefore, node S selects the path with the smaller sum of queue lengths (the first path in this example) and the main routing path is established from node S to D.

Main RouteActive LinkRoute Reply

Figure 1. Main route construction and message sniffering [8]

In LORP, the route construction process does not depend

on the queue length. It uses only the hop count to build the main route. Consider Fig. 1 for example, when node S receives MRRP from the above two paths, it has no criteria to decide which path to use. Mainly, it chooses the first path, of which the MRRP arrives first.

B. Route Maintenance The route maintenance phase consists of two parts: the

main route message sniffering and the route repairing.

1) The main route message sniffering: Message sniffering is the process of overhearing the packets transmitted on the main route by the neighboring nodes that are within the radio range. TALORP uses the main route message sniffering stage exactly the same way as LORP does. It begins after packets start to be delivered through the main route. With the broadcast nature of wireless communication, a node would naturally ‘‘overhear’’ the packets transmitted by their neighboring nodes that are within the radio range. In case a node, which is not part of the main route, overhears a data packet transmitted by a neighbor on the main route, it records the H value included within the packet header in its height table. If more than one such packet is received, the average of the received H values is calculated and then recorded in its height table. The recorded H value can later be used to assist in repairing the broken route and to restrain the flooding of control packets. Fig. 1 illustrates the sniffering process.

2) Route Repairing: When a link on the main route is

broken, the upstream node of this link will find out this breakage in a period of time and then initiate the main route repairing process by broadcasting a repair query (REPQ), which contains the height value of the initiating node. Each node that receives the REPQ packet would first check if it is the destination of the route. If it is, a repair reply (REPR) packet is sent back to the node from which the repair query (REPQ) packet was received. Otherwise, it compares the height value (denoted as reqH ) contained in the REPQ packet

to its own height value (denoted as tH ) in the height table in order to determine what the next step will be. If reqH is greater than (or equal to) tH , which means very likely the route repairing request was sent from a node that is closer to the source node, the receiving node would then rebroadcast the REPQ to the nodes that are closer to the destination. Hence, the REPQ packet remains propagating until it reaches the destination node, which might receive multiple REPQ packets. However, if reqH is smaller than tH or the node has no tH in its height table, the REPQ packet is dropped. Each intermediate node in the reverse path will depend on the hop count and the queue length to decide whether to forward or drop the REPR packet. Fig. 2 illustrates the route repair process as node Y moves out of the radio range of its upstream node X. The new main route is determined to be “S→W→X→B→C→E→D”.

IV. SIMULATION RESULTS

GloMoSim2.03 (Global Mobile Information Systems Simulation) [10] [11] [12] was used to compare the performance of TALORP and LORP.

A. Simulation Environment The same simulation environment was used for both

protocols for fair comparison. In this environment, the simulation area was a 2200m × 600m rectangular region with 100 mobile nodes moving within it. Each node is placed randomly inside the region. The mobility model that is used in the simulation is the random waypoint. In this model, once the simulation begins, each node moves toward a randomly selected location with a random speed ranging from 0 to 20m per second. When the node reaches the intended location, it stops for a fixed time called the pause time. After the pause time elapses, the node randomly selects another location and proceeds towards it in a similar manner. The detailed simulation parameters are listed in Table 1.

Figure 2. REPQ and REPR message flow in TALORP

TABLE I. SIMULATION PARAMETERS

Parameter Type Parameter Value Simulation time 500 s Simulation terrain 2200 × 600 m Number of nodes 100 Mobility model Random waypoint Mobility 0-20 m/s Pause Time 0 s Transport protocol UDP Radio frequency 2.4 GHz Channel bandwidth 2 Mbps MAC protocol 802.11 Transmission range 250 m CBR data rate 3 packets per second Packet Size 64 bytes

B. Performance Metrics

The performance metrics used in this paper are the metrics that are usually used in literature to evaluate the performance of routing protocols, which are:

1. Packets Delivery Ratio: The ratio of the number of packets received to the number of originated packets by the application layer.

2. Average End-to-End Delay: The average delay taken by the sent data packet from the source to the destination as measured by the application layer. This includes all the delays incurred during route acquisition, queuing, and processing at intermediate nodes, and the retransmission delay at the MAC layer caused by the packet collisions.

3. Routing Overhead: The total number of control packets transmitted during the simulation time. For packets sent over multiple hops, each transmission of a packet (by each hop) counts as one transmission.

C. Results and Analysis The performance metrics listed above were used to

evaluate and compare the performance of TALORP, and LORP protocols. For each scenario, the performance metrics were evaluated as functions of the amount of traffic load, which is represented by the number of concurrent disjoint sessions allowed. The number of sessions ranged between 10 and 50 per scenario. Each session involves 2 of the participating nodes in a conversation. Hence, with 10 sessions, only 20% of the participating nodes are busy sending or receiving, while with 50 session, all participating nodes are sending or receiving in addition to relying packets to other nodes. Therefore, with 10 sessions, the network traffic load is considered low, with 20 to 30 sessions it is considered moderate, and with 40 to 50 sessions, it is considered heavy. For each of the simulation scenarios used, the pause time was fixed at zero (i.e.; continuous mobility), which represents the worst case for node mobility. Each

simulation scenario was repeated a number of times each with a different seed for the random generator. The results of all scenarios were averaged and plotted. The standard deviation of most scenarios ranged between 5% and 20% around the average.

In the following sections, the simulation results for each performance metric are presented and discussed.

a) Packet Delivery Ratio (PDR): Fig. 3 depicts the impact of the traffic load on PDR. TALORP outperforms LORP at all traffic loads. However, at high traffic load, the performance of both LORP and TALORP start to drop significantly. Fig. 6, which summarizes the relative performance of TALORP and LORP, depicts that TALORP delivers 9% to 24% more packets than LORP at all traffic loads, with an increased relative performance as the traffic intensifies.

b) End-to-End Delay: Fig. 4 depicts the impact of the traffic load on the end-to-end delay. Similar to PDR, TALORP outperforms LORP at all traffic loads. Fig. 6 depicts that TALORP is 13% to 49% faster than LORP at all traffic loads with a peak relative performance around moderate traffic loads.

c) Routing Overhead: Fig. 5 depicts the impact of the traffic load on the total number of control packet used. LORP outperforms TALORP at all traffic loads. Fig. 6 depicts that TALORP uses 9% to 49% more control packets than LORP at all traffic loads. However, as the traffic load intensifies, the difference in the number of control between the two protocols gets smaller with the minimum at heavy traffic loads.

d) Analysis of the Results: It is obvious from the results that TALORP generally performs better than LORP under all traffic conditions in terms of PDR and end-to-end delay but at the cost of the control overhead incurred. The reason for such performance improvement is that TALORP uses the shortest and least congested path to transfer data. Using such path decreases the collision probability along the path, hence, increases PDR and the speed of delivering such packets. On the other hand, LORP uses the shortest path during the main route construction phase without paying attention to the relative traffic intensity on the selected path. However, when a link failure occurs, LORP attempts to repair the failure as fast as possible using the backup route, regardless of the length or the congestion status of the alternative path. This may potentially lead to using longer and more congested paths towards the destination, which increases the data loss probability, hence, decreasing PDR and slows down the packet delivery speed, but with less overall control overhead needed. At severe traffic conditions, the overall performance of both LORP and TALORP seems to drop rapidly. The reason is that as the traffic intensifies, and with the continuous movement of nodes, it is likely that the probability of packet collisions and link failures increases. This triggers both protocols to continuously attempt to repair the broken links, but with the continuous movements of the very busy nodes, most of these attempts would most likely fail or timeout, which, as a result, causes more delivery failures and longer delivery delays.

30%

40%

50%

60%

70%

80%

90%

10 20 30 40 50

Packet Delivery Ratio

Number of Sessions

TALORP LORP

Figure 3. PDR vs. Traffic Load

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

10 20 30 40 50

End‐to‐End

 Delay (sec)

Number of Sessions

TALORP LORP

Figure 4. End-to-End delay vs. Traffic Load

50

100

150

200

250

300

10 20 30 40 50

Control Packets (thou

sand

s)

Number of Sessions

TALORP LORP

Figure 5. Control packets vs. Traffic Load

‐60%

‐40%

‐20%

0%

20%

40%

60%

10 20 30 40 50

Percen

t Improvem

ent /

 Degradation

Number of sessions

PDR E‐to‐E Delay Control OH

Figure 6. Percent Relative Performance

V. CONCLUSION

The simulation results demonstrated that the proposed TALORP protocol provides better overall performance than the LORP protocol under all traffic conditions and under continuous node mobility. Compared to LORP, TALORP outperforms LORP since it overcomes the main drawbacks of LORP by taking into account the traffic intensity towards the destination combined with using the shortest path. In most cases, TALORP provides higher packet delivery ratio and shorter end-to-end delay, but at the cost of higher control overhead.

The performance evaluation of the proposed protocol is to be extended to include other metrics such as the computation and memory overhead and to include other well-known standard routing protocols such as the AODV protocol.

REFERENCES [1] S. Murthy, J.J. Garcia-Luna-Aceves, “A routing protocol for packet radio networks”, in: ACM MOBICOM”, 1995, pp. 86–94. [2] C.E. Perkins, “Ad hoc on demand distance vector (AODV) routing”, in: IETF Internet-Draft, draft-ietf-manet-aodv-00.txt, November 1997. [3] C.E. Perkins, E.M. Royer, “Ad-hoc on-demand distance vector routing”, in: Proceedings of the Second IEEE Workshop on Mobile Computing Systems and Applications, 1999, pp. 99–100. [4] D.B. Johnson, D.A. Maltz, “Dynamic Source Routing in Ad-Hoc Wireless Networks”, Mobile Computing, Kluwer, Dordrecht, 1996, pp. 153–181. [5] M.S. Corson, V.D. Park, “Temporally ordered routing algorithm (TORA) Version 1”, functional specification, Internet-Draft, draft-ietfmanet-tora-spec-00.txt, November 1997. [6] V.D. Park, M.S. Corson, “A highly adaptive distributed routing protocol for mobile ad hoc networks”, in: Proceedings of INFOCOM, 1997, pp. 1405–1413. [7] Z.J. Haas, “The zone routing protocol (ZRP) for ad-hoc networks”, IETF Internet Draft, draft-zone-routing-protocol-00.txt, November 1997. [8] C YU, T.K. Wu, R. Cheng, “A low overhead dynamic route repairing mechanism for mobile ad hoc networks”, computer communications 30(5), 2007, pp. 1152-1163. [9] V. saigal, A. Nayak, S. Pradhan, R.Mall, “Load balanced routing in mobile ad hoc networks”. Computer Communications, 2004; 27(3): pp. 295–305. [10] Qualnet Simulator: http://www.qualnet.com. [11] J. Nueve, “A Comprehensible GloMoSim Tutorial”. [Accessed Feb 2007]. Available from :< http://externe.emt.inrs.ca/users/nuevo /. > [12] X. Zeng, R. Bagrodia, M. Gerla, “GloMoSim: a library for parallel simulation of large-scale wireless networks”, Proceedings of PADS’98

)1998.( .