A Load aware Routing (LWR) Based on Local Information

Size: px

Start display at page:

Download "A Load aware Routing (LWR) Based on Local Information"

Colin Mathews
5 years ago
Views:

1 A Load aware Routing (LWR) Based on Local Information Yunjung Yi, Taek Jin Kwon and Mario Gerla University of California, Los Angeles {yjyi, * Telcordia Technologies, Applied Research Abstract - This paper suggests a new load aware routing (LWR) enhancement that improves on-demand routing protocols significantly in ad hoc networks. This paper describes deterministic characteristics of ad hoc networks and suggests improved routing strategies that can sustain the network functionality even under highly stressful data traffic. LWR evenly distributes the load throughout the networks. It also reduces redundant packet flooding which is major limitation of conventional ad hoc routing algorithms. Simulation results illustrate the performance improvements obtained with LRW by using new flooding control over conventional on-demand routings. I. INTRODUCTION An ad hoc network is a fast deployable wireless network that is typically subject to dynamic network topology change due to node mobility. An important performance issue in an ad hoc network is the interference among neighbors. As the interference increases, the performance of system degrades dramatically. One of the most effective ways of dropping such interference is reducing redundant transmissions e.g. unnecessary flooding relays. In fact, ad hoc network routing protocols are after designed based on overhead reduction criteria. There are two leading ad hoc routing schemes. One is proactive routing (e.g. OSPF), and the other is the reactive (on-demand, e.g. AODV) routing. Both routing schemes have drawbacks. Proactive routing usually generates a large and uniform number of control packets to maintain routes no matter how frequently the routes are used. On the other hand, reactive routing finds a route only when it is needed. This method is effective when there are only a few communication pairs, but it is very ineffective when many connections are active. In this paper, we focus on the reactive routing and provide a solution that mitigates drawbacks of reactive routing. Basically the reactive (on-demand) routing has two phases to establish a route: the Route Request phase and the Route Reply phase. In route request phase, flooding is used to propagate a route request packet, and in route reply phase the min hop path selected. However the min hop path is not always the best path in ad hoc networks. Sometimes, a detour through idle links can be the better choice. This paper suggests an improved reactive routing scheme named LWR (Load aware Routing) that chooses better routes by considering local information such as current queue size, and channel utilization. Basic idea of LWR is to drop route request packets at heavily loaded intermediate nodes. This provides an efficient way of establishing an alternate detour when the shortest path is congested. II. RELATED RESEARCH In the past decade, much research on congestion control has been done. There are two major classes of congestion algorithms: TCP and Packet Scheduling scheme [1,2]. They are known to be effective and widely accepted in wired networks. There is an on-going effort to extend them to ad hoc networks [3,4,5]. However ad hoc networks have two major differences in respect to wired networks: node mobility and dynamic bandwidth fluctuation due to interference. LWR is different from existing schemes in that it is a routing algorithm with congestion control. Intermediate nodes drop route request packets when they are overloaded. As the result, congestion control is a byproduct of routing. There are also load aware routing schemes [6,7]. Those works focus on the route reply phase to choose the proper path based on load awareness, while LWR focuses on the route request phase to prevent unnecessary flooding packet forwarding. LWR has unique characteristic. It prevents route request packets from being propagated through heavily loaded nodes. This improves network performance because it reduces not only congestion but also interference caused by redundant control packets. III. LOAD AWARE ROUTING (LWR) As we mentioned, the key idea behind LWR is to reduce unfavorable routes traversing heavy loaded intermediate nodes. In figure 1, we show an example. The shortest path between source and destination goes through congested

2 nodes by conventional reactive routing. By our scheme, an alternate detour path is established instead. LWR has several advantages compared to conventional reactive routing. First, LWR performs call admission control heavily loaded nodes do not participate in a new route discovery. Second, it does reduce redundant network traffic. Those two are the key mechanisms of LWR that sustain the network functionality in a highly stressful condition. As a consequence, data delivery ratio will be higher than for conventional reactive routing even in a saturated network. Best of all, this scheme decreases interference dramatically. It helps improving delivery ratio of both data packet and route control packet. It solves the saturation problem of reactive routing. LWR is selfadaptive in a sparse and lightly loaded situation, the protocol utilizes the efficiency of conventional reactive routing, and in a dense and heavily loaded situation, it controls unfavorable route establishment. The heuristic of LWR is the load level, which can be determined by local information such as channel utilization, queue size, number of active neighbors and value of backoff timer. We exploit all possible local information to estimate accurate load level. Besides queue size, all information is available for the MAC layer. Here we explain the measurement of channel utilization first and then describe the LWR scheme. Source Destination Route Request Packet Drop Request forwarding High Loaded Node Route Reply Figure 1. An example of LWR A. Channel Utilization Measurement The channel status of ad hoc network can be defined as IDLE, TRANSMITTING, RECEIVING, and COLLISION. MAC layer monitors changes of status, and whenever a change happens, duration of previous channel status is accumulated to idle_time, trans_time, recv_time and coll_time respectively. Based on accumulated values (idle_time, trans_time, recv_time, coll_time) channel utilization Ui of node Pi is calculated periodically on every interval I (in sec). Ui can be classified in 4 levels: FULL_IDLE: Ui is very low. HALF_IDLE: Ui is a little low. HALF_FULL: Ui is a little high. FULL_HEAVY: Channel is fully utilized. We determine each threshold based on previous research on the performance of standard [8,9]. We consider channel is fully busy in the following cases: The difference (! max - Ui) " #.! max is the maximum performance of experienced in the scenario at hand. It generally depends on the collision probability and the number of neighbors. # is a small safety margin. P coll > C max. The probability of collision (P coll ) is larger than COLLISION_THRESHOLD (C max ). Under high load situation, some nodes tend to occupy the shared channel longer than the fair (round robin) fraction. This scheme tries to keep channel utilization equal among all active neighbors. The list of active neighbors is managed by timeout and is updated at each packet arrival. Appendix I. shows the algorithm in detail. B. Load aware Routing (LWR) Reactive routing uses two phases to find a route: Route request and Route reply phase. In this paper, we focus on the route request only, since the load aware method in route reply phase requires extra control data. Whenever an intermediate node Pi receives a route request packet, it forwards or drops the packet based on TTL and current load level. It drops the packet only when TTL expires or the load level Li is higher than threshold FULL_HEAVY. A node drops route request flooding packets when the load level Li reaches the near maximum load level. The load level Li is associated with channel utilization Ui, current queue size Qi, number of active neighbors Ni, and the value of backoff timer Bi. The larger those values are, the larger Li is. Those values have following meaning. The channel utilization Ui: If Ui is near saturation point! max, then small increase in offered load would results in a large increase in data packet drop probability. Therefore, in such situation a new route request packet should be dropped. The queue size Qi: Queue size is also an indicator of load level. High Qi means that the queue is fully loaded. The number of neighbors Ni: [8,9] shows that the number of neighbors is critical in determining! max. The backoff timer Bi: Bi represents the number of failures of a data packet transmission. Hence Bi is clearly related to the probability of collision [16]. The intermediate node Pi drops route request packet if Ui is FULL_HEAVY or all 4 values are large enough. The

3 latter condition helps keeping stable performance and prevents saturation. Appendix II. illustrates in more detail the collection of load level measurements. IV. A. Simulation Model SIMULATION AND EXPERIMENTS We evaluate the LWR scheme by comparing the performance with AODV [12,13]. We use the Global Mobile Simulation (GloMoSim) library [1], which is a scalable simulation environment for wireless network. GloMoSim uses Parsec [14]. We implement LWR based on AODV and DCF [15]. We use a CBR (Constant Bit Rate) application, AODV, DCF MAC protocol and TWORAY radio model with 2Mbits/sec-channel bandwidth. TWORAY radio model is similar to the model used in the ns-2 wireless extension [11]. Under no interference, the range at maximum transmission power covers 25m. We place nodes randomly, and simulate 6 seconds for all cases. First we evaluate LWR compared to AODV by using various mobility parameters. We use 1 nodes over 2 x 6m 2 terrain and 4 random CBR connections. Nodes are moving following random waypoint model with speed 2m/s, 4m/s, 8m/s, and 16m/s without pause time. Second we compare LWR and AODV over various offered loads. We use 1 nodes in 2 x 6 m 2 and 2 nodes in 25 x 9 m 2. We increase the number of CBR connections from 1% to 1% the number nodes. Here we use random waypoint model with minimum speed 2 m/s, maximum speed 2 m/s and 1 seconds pause time. For both comparisons, we consider two rates -512 bytes/pkt and 4pkts/sec- at each CBR connection. All values averaged over several simulation experiments using different random seeds. Delivery Ratio (%) B. Simulation Results Figure 2. Delivery Ratio AODV Nodes 1 LWR Nodes 1 B.1. Results based on change of mobility parameter End To End Delay (sec) Normalized Ctrl OH (ctrl pkt #/data pkt#) Figure 3. End-to-End Delay AODV Nodes 1 LWR Nodes AODV Nodes 1 LWR Nodes 1 Figure4. Normalized routing Control Overhead Figures 2 to 4 show that LWR generally works better than ordinary AODV since LWR reduces the control overhead. The performance gain by LWR increases as the mobility increases. B.2. Results based on offered load (Num of nodes =1) Throughput (kbits/sec) Figure 5. Throughput AODV Nodes 1 LWR Nodes 1 Throughout the experiments (Figure 5-7), we can easily see that LWR survives even under heavy traffic loads, while AODV suffers from huge control overhead. Figure 6 shows the average hop count. After saturation point

4 (Offered Load > 6 in Figure 5) the average hop count by AODV increases dramatically because of following reason: congestion increases the probability of packet loss, hence the route requests have a tendency to be forwarded to only low loaded nodes, which might setup longer path. Figure 7 shows that the normalized control overhead of LWR is bounded. In short, LWR solves the saturation problem of AODV. Avg Hop Count Normalized Ctrl OH Figure 6. Average Hop Count AODV Nodes 1 LWR Nodes AODV Nodes 1 LWR Nodes 1 Figure7. Normalized Control Overhead B.3. Results based on offered load (Num of nodes =2) Throughput (kbits/sec) AODV Nodes 2 LWR Nodes 2 Figure 8. Throughput To show the scalability of LWR, we simulate large network. Figure 8 shows that LWR is fairy stable even in a dense and large network. The decline in performance by LWR as a function increasing offered load is gradual, while AODV performance drop dramatically. A possible undesirable consequence of dropping route request packets is loss in connectivity. To gauge this effect, we measure the number of successfully connected pairs with 2 nodes. Recall that LWR drops flooding packet only when the load level is too high. Figure 9 shows the gain in connectivity achieved by LWR. Successful Connection Count AODV Nodes 2 LWR Nodes 2 Figure 9. Number of successfully connected CBR sessions V. CONCLUSIONS This paper has presented a novel load aware routing LWR. The paper has made several contributions. First, LWR guarantees stable performance even when the network is dense and heavily loaded. Second, LWR balances the load using detour paths and avoiding congested areas. Finally, LWR reduces interference caused by flooding packet enormously by dropping flooding packets. Simulation results show that LWR works effectively. TABLE 1. Threshold Values for Channel Utilization INTERVAL 1s RECEIVING_THRESHOLD.15 ALPHA.7 AGR_RECEIVING_THRESHOLD.5 IDLE_THRESHOLD.8 SINGLE_BUSY_THRESHOLD.2 BUSY_THRESHOLD.3 MIN_COLLISION_THESHOLD.5 TRANS_THRESHOLD.15 COLLISION_THRESHOLD.15 COLL_BUSY_THRESHOLD.4 APPENDIX I. Measurement of channel utilization Variables used in our experiment are summarized in Table 1. Values in Table 1 are decided based on [8,9]. ALPHA value is used to mitigate sudden effect. The performance of one transmission over 82.11! single can be calculated easily. And! single is over.8 under our environment. If more than 2 neighbors share the channel, then we drop the packet after channel utilization reaches.7 and keep the fair share to every neighbor. Under collision, we drop maximum throughput threshold to.6 since collision generates more idle time due to backoff. TABLE 2. Pseudo code to calculate fraction of each status

5 # same to coll_rate, recv_rate and trans_rate respectively idle_rate = idle_time / INTERVAL; current_idle_rate = (1 ALPHA) * prev_idle_rate + (ALPHA) * idle_rate; prev_idle_rate = current_idle_rate; TABLE 3. Pseudo code of GetChannelUtilization function. $ Case I: Idle rate is high. if current_idle_rate > IDLE_THRESHOLD then Ui = FULL_IDLE; $ Case II: This node Pi monopoly the channel if numactivenodes == then #monopoly the channel{ if ( current_idle_rate < SINGLE_BUSY_THRESHOLD current_coll_rate > COLLISION_THRESHOLD ( current_coll_rate > MIN_COLLISION_THRESHOLD && current_idle_rate < BUSY_THRESHOLD) ) } $ Case III: More than 2 neighbors if current_idle_rate < BUSY_THRESHOLD then $ Case IV: The collision rate is high. if current_coll_rate > COLLISION_THRESHOLD then $ Case V: The collision rate is moderate if (current_coll_rate > MIN_COLLISION_THRESHOLD) then{ if(current_idle_rate < COLL_BUSY_THRESHOLD) then elsif (current_recv_rate / numactivenodes > RECEIVING_THRESHOLD) elsif (current_trans_rate > TRANS_THRESHOLD) then Ui = HALF_IDLE; elsif (current_recv_rate >AGR_RECEIVING_THRESHOLD) then Ui = HALF_FULL; $ Case VI: The collision rate is low if current_coll_rate < MIN_COLLISION_THRESHOLD { #not much collision if current_idle_rate > COLL_BUSY_THRESHOLD then Ui = HALF_IDLE; # Keep the round robin fraction to every neighbors elseif ((current_idle_rate < COLL_BUSY_THRESHOLD ) && (current_trans_rate > current_recv / numactivenodes)) elsif (current_recv_rate / numactivenodes > RECEIVING_THRESHOLD)) elsif (current_trans_rate > TRANS_THRESHOLD) then Ui = HALF_IDLE; elsif (current_recv_rate >AGR_RECEIVING_THRESHOLD) then Ui = HALF_FULL; } II. GetLoadLevel Values used in our experiment are shown Table 4. TABLE 4. The values for GetLoadLevel CHANNEL_UTIL_PORTION.65 HALF_IDLE.25 BACKOFF_PORTION.15 HALF_FULL.5 NEIGHBOR_PORTION.1 FULL_THRESHOLD.75 QUEUE_PORTION.1 Values of Bi (level of backoff), Ni (level of neighbor) and Qi (level of queue) are one of 4 values like channel utilization Ui. Each element has MIN and MAX values. Based on MIN and MAX, level of each is determined as following. 1: {MIN, (MAX-MIN)*1/4} 2: {(MAX-MIN)*1/4, (MAX-MIN)*2/4} 3: {(MAX-MIN)*2/4, (MAX-MIN)*3/4} 4: {(MAX-MIN)*3/4, MAX} The load level Li of node Pi is determined by using one linear function of four values (Bi, Ni, Qi and Ui). Li = (CHANNEL_UTIL_PORTION * Ui + BACKOFF_PORTION * Bi + NEIGHBOR_PORTION * Ni + QUEUE_PORTION * Qi)/4; if Li % FULL_THRESHOLD, Li = FULL_BUSY if Li % HALF_FULL, Li = FAIRY_BUSY if Li % HALF_IDLE, Li = LITTLE_BUSY Li = FULL_IDLE REFERENCES [1] M. Allman, V. Paxson, and W. Stevens. TCP Specification, IETF, RFC 1633, June [2] S. Floyd and V. Jacobson. Random Early Detection Gateway for Congestion Avoidance, IEEE/ACM Transaction on Networking, Vol. 1, No. 4, August [3] H. Balakrishnan, V. N. Padmanabhan, S. Seshan, and R. H. Katz, A Comparison of Mechanisms for Improving TCP Performance Over Wireless Link), IEEE/ACM Transaction on Networking, December [4] P. Sinha, N. Venkitaraman, R. Sivakumar, and V. Bharghavan, WTCP: A Reliable Transport Protocol for Wireless Wide-Area Networks, Proceedings of MOBICOM, August [5] T. Nandagopal, S. Lu and V. Bharghavan, A Unified Architecture for the Design and Evaluation of Wireless Fair Scheduling Algorithms, Proceedings of MOBICOM'99, August [6] M.R. Pearlman, Z.J. Haas, P. Sholander, and S.S. Tabrizi, On the impact of alternate path routing for load balancing in mobile ad hoc networks, Proceedings of First Annual Workshop on Mobile Ad Hoc Networking Computing. (MobiHOC), 2. [7] S.J. Lee and M. Gerla, Dynamic Load-Aware Routing in Ad hoc Networks, To appear in the Proceedings of ICC 21. [8] G. Bianchi, Performance Analysis of the IEEE Distributed Coordinated Function, IEEE Journals on selected areas in communications, Vol. 18, No. 3, March, 2. [9] F. Cali, M. Conti, and E. Gregori, IEEE Wireless LAN: Capacity and Protocol Enhancement, Proceedings. IEEE INFOCOM, [1] UCLA, Glomosim: A scalable simulation environment for Wireless and Wired Network systems, [11] The Network Simulator NS-2, nsnam/ns [12] C. Perkins and E. Royer. Ad hoc on-demand distance vector routing. In proceedings of the 2 nd IEEE Workshop on Mobile Computing Systems and Applications, [13] C. Perkins, E. Royer, and S. Das. Ad hoc on demand distance vector(aodv) routing, internet-drafts/draft-ieft-manet-aodv-3.txt, 1999 [14] R. Bagrodia, R. Meyer, M. Takai, Y. Chen, X. Zeng, J. Martin, B. Park, and H. Song, Parsec: A Parallel Simulation Environment for Complex Systems, Computer, Vol. 31(1), October 1998, pp [15] IEEE Computer Society LAN MAN Standards Committee, Wireless LAN Medium Access Protocol (MAC) and Physical Layer (PHY) Specification, IEEE Std [16] M. Natkaniec and A.R. Pach, An analysis of the backoff mechanism used in IEEE networks, Proceedings ISCC (IEEE Symposium on Computers and Communications) 2.

Dynamic Load-Aware Routing in Ad hoc Networks

Dynamic Load-Aware Routing in Ad hoc Networks Sung-Ju Lee Internet & Mobile Systems Labs Hewlett-Packard Laboratories Palo Alto, CA 9434-6 sjlee@hpl.hp.com Mario Gerla Computer Science Department University