Core Location-Aided Cluster-Based Routing Protocol for Mobile Ad ...

4 downloads 530 Views 1MB Size Report
A local route repair is applied to fix path, while the source or ... T. F. Shih is also with the Department of Computer Science and Information Engineering China ...
Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp223-228)

Core Location-Aided Cluster-Based Routing Protocol for Mobile Ad Hoc Networks TZAY-FARN SHIH † and HSU-CHUN YEN Department of Electrical Engineering National Taiwan University No.1, Sec. 4, Roosevelt Road, Taipei, 106 TAIWAN, R. O. C. Abstract: - Instead of blindly searching for a route in the entire network, the location-based routing protocol uses the location information of mobile nodes to confine routing space into a smaller range that reduces routing overhead and broadcast storm. In this paper, we propose a location-aided cluster-based routing protocol called Core Location-Aided Cluster-based Routing protocol (CLACR). CLACR partitions the entire network into square clusters. In each cluster, a cluster head is selected for routing. Instead of flooding route request packets in the entire network blindly, CLACR computes the desired route by using Dijkstra algorithm in a cluster-by-cluster basis. Only cluster heads, source, and destination nodes are needed to participate in routing procedure that reduce routing overhead tremendously. In order to maintain a shorter path, a route optimization is used to adjust the constructed path dynamically. A local route repair is applied to fix path, while the source or destination nodes roam off a cluster. It is helpful to lengthen the lifetime of route effectively. CLACR can easily be extended to provide geocasting service. Simulation results show that the performance of our routing protocol is better than other protocol. Key-Words: - MANET, Routing Protocol, GPS, Geocasting, Cluster-based routing

1 Introduction

Many graph-based Mobile Ad Hoc Networks (MANET) routing protocols have been proposed [1]–[4]. They search route in the whole network blindly and induce huge routing overhead. Recently, the location-based routing protocol has attracted more attention. Location-based routing uses location information provided by GPS or some other type of positioning device to assist routing process [5]–[8]. The application of location to improve the mobile computing system routing has been suggested in [9]–[16]. As a further advantage, location-based routing supports the delivery of packets to all nodes in a given geographic region in a natural way. This service type is called geocasting [15]–[16]. In this paper, we proposed a cluster-based routing protocol, named Core Location-Aided Cluster-based Routing protocol (CLACR). The characteristics of CLACR are stated as follows. First, the entire network is partitioned into square clusters. In each cluster, a cluster head is selected by a cluster head election algorithm. Only cluster heads, source nodes, and destination nodes participate in the route discovery, route maintenance, and data transmission. †

Using the cluster mechanism, the number of nodes that is responsible for routing and data transfer is decreased considerably. The routing overhead is diminished and the route lifetime is increased tremendously. Second, CLACR computes path using Dijkstra algorithm in a cluster-by-cluster basis. Third, a dynamic route optimization is applied to adjust the changed path dynamically. Forth, a local repair is applied for route recovery that lengthens the route lifetime effectively. CLACR can be extended as a geocasting routing protocol easily, and the location server and cluster head can provide location services for different applications. Simulation results show that the performance of CLACR is better than LAR [9]. The rest of the paper is organized as follows. Section 2 presents the related work and motivation. Our protocol is detailed in Section 3. Section 4 presents the simulation results. Finally, we give the conclusions in Section 5.

2 Related Work and Motivation

Y. Ko and N. H. Vaidya proposed a location-aided routing protocol (LAR) [9]. In LAR, source node

T. F. Shih is also with the Department of Computer Science and Information Engineering China College of Marine Technology and Commerce Taipei, Taiwan 111.

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp223-228)

uses the location of destination to estimate the region that the destination may be appeared, i.e., expected zone. Using the expected zone and the location of source node, source node defines a request zone. The route request packets are only forwarded by nodes within the request zone. When route discovery fails in the first attempt, LAR enlarges the request zone to the entire network and initiates a new route discovery by flooding rapidly. LAR transmits routing packets by broadcast causing a heavy overhead and collision. W. H. Liao et al. proposed a GRID routing protocol [13]. GRID uses the location of source and destination node to confine a routing space and establishes a routing table in a grid-by-grid basis. The grid-based addressing induces all kinds of packet must be sent by broadcast and causes a lot of interference. The gateway election protocol is inefficient. The route maintenance doesn’t guarantee the shortest path is kept. These problems motivated us to propose a protocol to improve performance.

3 The CLACR Routing Protocol 3.1 Overview

In CLACR, the network is partitioned into clusters. The types of node are classified as cluster member (MEM), cluster head (HD), location server (LS) and backup location server (BLS). Only HDs, source, and destination participate in the route discovery, route maintenance, and data transmission process. In each cluster, a HD is selected by a cluster head election algorithm. The LS is elected by a location server election algorithm. The LS provides the location of all nodes and the information of HDs for routing procedure. Instead of flooding route request to search for routes in the entire network blindly, the source node computes route using a Dijkstra algorithm that guarantees to construct a shortest path in cluster-by-cluster basis. In order to maintain a shorter path, a dynamic route adaptation is used to adjust the changed path dynamically. To increase the route lifetime effectively, a local repair is applied to route recovery while source nodes or destination nodes roam off a cluster. The details of CLACR are described in the following sections.

3.2 Network Clustering

Assume that the range of network is a rectangle with a diagonal NsNe , where the location of start point Ns and end point Ne are (Xs, Ys) and(Xe, Ye) respectively. Assuming the network is divided to col × row square clusters and the side length of cluster is d. The number of column and row, i.e., col and row, can be calculated by equation (1) and (2) respectively.

 ( Xe − Xs ) 2   col =  d    (Ye − Ys) 2   row =  d  

(1)

(2)

Assuming the cluster ID of Ns to be (0, 0), then each node i at location (Xi, Yi) can calculates its cluster ID, cls_IDi, as follows:

  ( Xi − Xs ) 2  d 

cls_IDi =  

 , 

 (Yi − Ys) 2  d 

   (3)  

Each node updates and memorizes its more up-to-date cluster ID. Therefore, the network is clustered by the cluster ID.

3.3 Cluster Head Election Protocol

The cluster head election protocol selects the center most node of a cluster as the HD as follows: 1). When the network is initiated and partitioned, each node sets itself as a HD and broadcasts a HEAD_INIT packet with its cluster ID and location for HD contention. When a node in the same cluster receives a HEAD_INIT packet, it compares the location of the HEAD_INIT packet’s sender with the location of its current HD. If the HEAD_INIT packet’s sender is nearer to the cluster center than its current HD, then the sender becomes its new HD. After the contention procedure, the node that elected itself as a HD is the winner. It sets its node type as HD and sends a HEAD packet to inform nodes in the same cluster that it is the new HD. The member in the cluster receives the HEAD packet will set its HD to be the sender of the HEAD packet. 2). A HD periodically broadcasts a HEAD packet to announce that it is alive. If a HEAD does not receive in time, a member node broadcasts a HEAD_ COMPETE packet with its cluster ID and location to its neighbors for HD contention. When a HD received a HEAD_COMPETE, it replies with a HEAD packet to inform the competitor that it is existing and forbid the HD competition. If a more centered member receives the HEAD_ COMPETE, it sends a HEAD_COMPETE to forbid the HD contention. If the competitor does not receive HEAD or HEAD_COMPETE packet in a predefined time period, it elects itself as a new HD and informs its members by HEAD packet. 3). When a HD roamed out a cluster, it selects the center most member in the previous cluster as a new HD. Because the HD has the location of all members, it can easily select a new HD by computation. The

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp223-228)

C15

C25

D1

C35

C44

C34

C24

C55

D2

Request Zone 1

D1

C54

C34

C24

Source node

C13

C12

C23

C22

C33

C43

C53

C13

S

C42

C52

C12

C41 C11

D4

C31

D3

C23

C22

C33

S

Destination node Cluster Head Cluster Member Location Server

Backup Location Server

Each logical node, i.e., Cluster head, stands for a cluster.

Fig. 1 The transformation of clusters in Request Zone to logical nodes.

old HD can handoff all information to the new HD by unicast a HEAD_INFO packet. The information carried in the HEAD_INFO includes location server, neighboring cluster head table, routing table, and the location of members. When the new HD receives a HEAD_INFO, it inherits the information carried in the packet and broadcasts a HEAD to all members and neighboring HDs for cluster head update. 4). When a member has entered into a new cluster, it sends a MEMBER_LOCATION packet for joining request. When the HD receives the MEMBER_ LOCATION, it updates its cluster members table and sends a HEAD to the new member to confirm its membership. If the member does not receive a HEAD in a predefined time interval, it broadcasts a HEAD_COMPETE for HD contention. 5). When a HD receives a HEAD packet from a more centered HD in the same cluster, it silently changes its node type to a MEM. If a HD receives a HEAD from a less centered HD in the same cluster, it replies with a HEAD to forbid the sender’s role of HD. While a HD receives a HEAD from neighboring cluster, it uses this information to update its neighboring cluster head table.

3.4 Location Server Election Protocol

The location server election protocol selects the center most HD in the network to be LS as follows: 1). When the network is initiated, partitioned and HD of each cluster is selected. Every HD elects itself as LS and sends a SERVER_COMPETE packet with its location information to its neighboring HDs for LS contention. When a HD receives a non-duplicate SERVER_COMPETE, it compares the location information carried in the SERVER_COMPETE with its current LS’s location. If the sender of SERVER_COMPETE is closer to the center of the network than its LS, then it sets the sender to be its new LS and forwards the SERVER_COMPETE to its neighboring HDs. Otherwise, it drops the SERVER_COMPETE packet. After the contention

procedure, the HD that elected itself as LS is the winner. It will turn its node type to LS and send a SERVER packet to inform all HDs. Every HD receiving the SERVER sets the sender of the SERVER to be its new LS and records the path to the LS. While the HD that is adjacent to LS receives a SERVER, it sets its node type to BLS. There are at most eight backup location servers (BLS) in the network. The BLSs are used for the backup of LS. If LS fails, the BLS that is closest to the center of the network will be elected to as a LS immediately. This scheme increases the fault tolerance for LS crashes. 2). The LS periodically sends a SERVER to inform that it is alive. If a BLS does not receive a SERVER in a default interval, it sends a SERVER_COMPETE with its location for LS contention. When the LS receiving the SERVER_COMPETE, it replies with a SERVER to announce it is alive, and forbid the competition. If no SERVER is received by the competitor in a default period, it elects itself as a LS. 3). When LS roamed out a cluster, it selects a MEM or BLS that is nearest to the center of its original cluster as a new LS by computation. The old LS delivers all related information by unicast a SERVER_INFO to the new LS. The information carried in the packet includes the location of all nodes and the HD information of all clusters. When the new LS receives the SERVER_INFO, it inherits the information carried in the packet and sends a SERVER packet to announce that it is the new LS.

3.5 Route Construction

If a source node cannot find a route in routing table, it unicasts a location request packet (LREQ) to LS to request the destination’s cluster ID and the map of all HDs in the network. When LS receives a LREQ, it replies with a location reply packet (LREP) that carries the requested information. After receiving the LREP, source node uses the cluster ID of source and destination to define a request zone. A request zone is a rectangle that covers the source cluster and

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp223-228)

destination cluster. The source cluster and destination cluster are located at the end points of the diagonal of the request zone respectively. The request zones 1 in Fig. 1 is defined by the cluster ID of S and D1. Each non-empty cluster in request zone is treated as a logical node. The existence of the HD for all clusters within the request zone can be determined by the map of HDs get from LREP packet. The cost between adjacent logical nodes, i.e., clusters, is assumed to 1. The cost between non-adjacent logical nodes is set to , which means no link exists between them. The Dijkstra algorithm is applied to compute the shortest path from the source cluster to the destination cluster in a cluster-by-cluster basis. If no route can be found in the confined request zone, the request zone will be enlarged to cover the entire network and recomputed again. When a path is found, the source node constructs the route by sending a data packet or a route request packet (RREQ) to destination. The source adds the next hop information, i.e., next cluster ID, to its routing table, and then it encapsulates the rest of path information to the first data packet and sends the data packet to next HD. It uses the next cluster ID as an index to look the next HD up in the neighboring cluster head table. When the next HD receives the data packet, it will retrieve the next hop from the attached path information and adds the next hop information to its routing table, and then it forwards the data packet to next hop again until the data packet reaches the destination. Constructing a route by RREQ packet is the same as piggybacking by a data packet. In our simulation, we used RREQ to build a route. After a route is built, the following data packets have no need to carry path information unless a new route is reconstructed. Data packets are transmitted by unicast in a cluster-by-cluster routing table lookup and a transformation of cluster ID to cluster head basis. Considering the route construction in Fig. 1. First, the clusters in request zone 1 are transformed to logical nodes. Then, S runs Dijkstra algorithm to calculate a shortest path from S to D1, (3, 2) → (2, 3) → (1, 4), where (i, j) is cluster ID. S adds the next hop cluster ID (2, 3) to routing table and looks the HD of cluster (2, 3), i.e., C23, up in its neighboring cluster head table. S encapsulates the remainder route information (1, 4) in the first data packet, and then sends the data packet to next hop node C23. When C23 receives the data packet, it retrieves the next hop cluster ID (1, 4) from the data packet. C23 adds the (1, 4) to routing table and looks the HD of (1, 4), i.e., C14, up in its neighboring cluster head table and relays the data packet to C14. The process repeats until the data packet reaches D1. The path from S to D1 is built by the first data packet in a cluster-by-cluster basis. The

following data packets can be send by a traditional routing table look up manner directly.

3.6 Route Maintenance and Optimization

In Fig. 2(b), while S moved from cluster (2, 1) to (2, 2), the path S → I1 → I2 → I3 → D repaired by GRID is not optimal. Even though there is a shorter path, S → I3 → D, GRID cannot find it. In Fig. 2(c), S moved from (2, 1) to (3, 1). The path built by GRID is S → I4 → I1 → I2 → I3 → D, where the length of path is increased. Although, there is a best path S → I5 → D, but GRID doesn’t find it. A similar situation may occur when destination node roamed away a cluster. To solve the above problems, CLACR applies a route optimization to update a route when the original path has changed. Three fields, traveled_route, traveled_ hopcount, and optimized, are added into data packet for route optimization. The traveled_route and traveled_hopcount fields are used to record the nodes that data packet visited and the hop count from source node to current node, respectively. The optimized field indicates the necessity of route optimization. When a node Ic received a data packet, Ic checks if it is adjacent to a node, says Ip, that this data packet has traveled from the source node to the predecessor of Ic. If the answer is yes, it means that there is a shortcut between Ip and Ic. Ic will replace the next hop cluster ID of the entry to the source node in its routing table with the cluster ID of Ip and set the optimized flag in the data packet to indicate that route optimization is needed. When the data packet reaches its destination, the destination checks traveled_hopcount and optimized. If traveled_hopcount is greater than the predefined threshold of path length, the destination sends a route reply packet (RREP) to inform the source node that the path is too long. The source will calculate a new route. Otherwise, if the optimized is set, the destination sends a RREP to update the routing table of nodes that are in the path to the source. By using route optimization, we get a shorter route on average. CLACR does route optimization for Fig. 2(b) as follows: when the first data packet, which is sent after the movement of S, reaches I2, I2 finds that it is adjacent to S. It replaces the next hop cluster ID of the entry to S in its routing table with the cluster ID (2, 2), and sets the optimized flag. The similar process is repeated while this data packet is forwarded to I3. While D receives the data packet, it finds the optimized is set. It means that route optimization is required, so D sends a RREP along the path to S for route update. A shorter path, S → I3 → D, is constructed by the route update process. Assume that the threshold of path length is 4. As for the case of Fig. 2(c), when the first data packet, which

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp223-228)

I2

3

2

D

I3

I1

1 1

I4 2

2

I5

S

I2

3

S

I1

I5

S I4 2

1

4

I2

3

2

(a)

3

D

I3

I1 I5

S 1

1

3

D

I3

1

4

S

I4 2

(b)

3

4

(c)

Fig. 2 Route maintained by GRID when the source node S roams off. (a) Initial state (b) S moves from cluster (2, 1) to (2, 2) (c) S moves from (2, 1) to (3, 1).    

C14

C24

Request Zone 1

C23

C13

C34 ''

          %$% ' "

C33

) # !& %

)#!

# ("'

(*

#$

S

+-,/.0+21 

,2.31

      %!&

C22

C12

      

!"

 

 

 

 

  

  

Fig. 3 Geocasting from source node S to cluster (1, 4) 4567689 :; ?@

Fig. 4 The success rate of route construction [\]]^_`a bcd ef

~

;A F V

;A ;E

RNS

;A ;D

W-X/YIW2Z

N

;A ; C

X2Y3Z F

O Q

P OM NO K LM

q

k g a k aa

xyz q w

j a i a ruv

h a qrst

g a

|}

TU

wy { q

;A ;B ; B;;

C;;

D ;;

E ; ;

o pq

F7;;;

-€‚I2ƒ

€‚0ƒ k a g aa

h aa

i aa

GIH 86J

7    

Š‹ŒŒ Ž  ‘’“ ” •

   

*

   

%

‡ˆ # !( † !& …

  – —

£¤ ª¢

„   

+-,/.I+21 

,2.31

   

œ– — ¤¨

©

¥¦ § ¡¤ £¢ ¡¢

 

 

 

 

  

0  

Fig. 7 Routing Overhead

is sent after the movement of S, reaches D and D finds that the traveled_hopcount is greater than 4, a route calculation will be initiated again. A shorter path, S → I5 → D, is constructed in the recalculation.

3.7 Geocasting

CLACR can be extended to provide geocasting easily. Fig. 3 shows an example of geocasting in Fig. 1 Request zone 1, where S wants to send packets to cluster (1, 4). To this end, it calculates a route from S to C14 by the method described in Section 3.5, and then C14 needs only to relay packets to all members.

4 Simulation Results

k aaa

Fig. 6 Route lifetime

Fig. 5 Route Setup Time

# ‰$

j aa

lm ^ ]n

›– —

«2¬/­I«2®

™š– —

¬/­3® 

 ˜– —  – — ˜ 

™

› 

œ

  

žIŸ Œ  

Fig. 8 Data Delivery Rate

In order to evaluate the performance of LAR scheme 1 (LAR1) and CLACR, we developed a simulator of CLACR by the GloMoSim library [17]. The simulator of LAR1 was distributed with GloMoSim 2.03. The bandwidth of each node is 2 Mbps. All nodes are located in an area of 1000 × 1000 m2. The mobility model is random waypoint model. The minimum and maximum roaming speed is 0 km/hr and 90 km/hr respectively. The simulation time is 400 seconds. There are four application connections in each run. The traffic generator of each connection is constant bit rate. The packet size is 512 bytes. In Fig. 4, the success rates of route construction for LAR1 and CLACR increase when the network size rises. The larger number of nodes increases the nodes’ cover range and density so that the route

Proceedings of the 10th WSEAS International Conference on COMMUNICATIONS, Vouliagmeni, Athens, Greece, July 10-12, 2006 (pp223-228)

construction success rate increases. The success rates of LAR1 are less than CLACR because the imprecise request zone of LAR induces route discovery failure. The average route setup time of LAR1 is much longer than CLACR, see Fig. 5. In LAR1, all nodes within request zone are responsible for routing. The more nodes participate in route discovery induce more routing traffic. The larger packets transmitted at the same time, the greater chance of collision. Collision may induce retransmission and delay, which can result in a longer route construction time. As Fig. 6 shows, the average route lifetime of CLACR is longer than that of LAR1. This benefit is the characteristic of cluster-based routing. The number of control packets for LAR1 increases when the network size enlarges and is much greater than that of CLACR, see Fig. 7. This charge resulted from the non-cluster nature of LAR1 that causes more nodes to participate in routing and induces a higher routing overhead. Fig. 8 depicts the data delivery rate of CLACR and LAR1. The data delivery rate of CLACR is higher than LAR1. The higher route construction success rate and route lifetime of CLACR prevented data packet loss.

5 Conclusion

In this paper, we proposed a routing algorithm that uses Dijkstra algorithm to calculate route in a cluster-by-cluster basis. Our cluster-based protocol reduces the number of nodes participate in routing. Calculating route by Dijkstra algorithm also reduces a lot of routing traffic and route setup time. In CLACR, the routing packets and data packets are transmitted by unicast, which reduces the probability of collision and diminishes broadcast storm problem. In order to maintain a shorter route, CLACR uses a dynamic route maintenance and optimization algorithm to update route dynamically. CLACR can be extended as a geocasting protocol and provide location service easily. The comparison of CLACR and LAR1 are studied through extensive simulation. The simulation results showed that CLACR has much better performance than LAR1. References: [1] D. Johnson and D. A. Maltz, “Dynamic source routing in ad hoc wireless networks,” Mobile Computing, Kluwere Academic Publishers, 1996. [2] R. Dube et al., “Signal Stability based Adaptive Routing (SSA) for Ad-Hoc Mobile Networks,” IEEE Personal Communication, Feb. 1997, pp. 36-45.

[3] C.-C. Chiang, M. Gerla, and L. Zhang, “Forwarding Group Multicast Protocol (FGMP) for Multihop, Mobile Wireless Networks,” Baltzer Cluster Computing, Vol. 1, No. 2, 1998, pp. 187-196. [4] C. E. Perkins and E. M. Royer, “Ad-hoc On-Demand Distance Vector Routing,” Proc. 2nd IEEE Wksp. Mobile Comp. Sys. and Apps., Feb. 1999, pp. 90-100. [5] E. D. Kaplan. Understanding the GPS: Principles and Applications, Artech House, Boston, MA, Feb. 1996. [6] S. Capkun, M. Hamdi, and J. Hubaux, “Gps-free Positioning in Mobile Ad Hoc Networks,” Proc. Hawaii Int’l. Conf. System Sciences, Jan. 2001. [7] J. Hightower and G. Borriello, “Location Systems for Ubiquitous Computing,” Computer, Vol. 34, No. 8, Aug. 2001, pp. 57–66. [8] K. Pahlavan, X. Li and J. P. Makela, “Indoor Geolocation Science and Technology,” IEEE Communication Magazine, pp. 112-118, Feb. 2002. [9] Y. Ko and N. H. Vaidya, “Location-aided Routing (LAR) in Mobile Ad Hoc Networks,” Proc. MOBICOM’98, Aug. 1998, pp. 66–75. [10] M. Joa-Ng and I.-T. Lu., “A Peer-to-Peer Zone-Based Two-Level Link State Routing for Mobile Ad Hoc Networks,” IEEE JSAC, Vol. 17, No.8, 1999, pp.1415–1425. [11] B. Karp and H. T. Kung, “GPSR: Greedy Perimeter Stateless Routing for Wireless Networks,” Proc. MOBICOM’00, Aug. 2000. [12] R. Jain, A. Puri, and R. Sengupta, “Geographical Routing Using Partial Information for Wireless Ad Hoc Networks,” IEEE Personal Communications, Feb. 2001, pp. 48-57. [13] W.-H. Liao et al., "GRID: A Fully Location-Aware Routing Protocol for Mobile Ad Hoc Networks", Telecommunication Systems, Vol. 18, No. 1, 2001, pp. 37-60. [14] Ivan Stojmenovic, “Position-Based Routing in Ad Hoc Networks,” IEEE Communication Magazine, Jul. 2002. [15] J.C. Navas and T. Imelinski, “Geocastgeographic Addressing and Routing,” Proc. ACM/IEEE MOBICOM ’97, Vol. 3, 1997, pp. 66–76. [16] Y. Ko and N. H. Vaidya, “Geocasting in Mobile Ad Hoc Networks: Location-Based Multicast Algorithms,” WMCSA' 99, Feb. 1999. [17] L. Bajaj, M. Takai, R. Ahuja, K. Tang, R. Bagrodia, and M. Gerla, “GlomoSim: A Scalable Network Simulation Environment”, UCLA Technical Report, #990027, May 1999.