# Performance Analysis of Location-Aware Grid-Based Hierarchical Routing Protocol for Mobile Ad Hoc Networks

Authors: Farrukh Aslam Khan; Wang-Cheol Song; Khi-Jung Ahn
Journal: Wireless Communications and Mobile Computing
 (2018)

---

## Abstract

In this paper, the performance analysis of a hierarchical routing protocol for mobile ad hoc networks (MANETs) called Location-aware Grid-based Hierarchical Routing (LGHR) is performed. In LGHR, the network comprises nonoverlapping zones and each zone is further partitioned into smaller grids. Although LGHR is a location-aware routing protocol, the routing mechanism is similar to the link-state routing. The protocol overcomes some of the weaknesses of other existing location-based routing protocols such as Zone-based Hierarchical Link State (ZHLS) and GRID. A detailed analysis of the LGHR routing protocol is performed and its performance is compared with both the above-mentioned protocols. The comparison shows that LGHR works better than ZHLS in terms of storage overhead as well as communication overhead, whereas LGHR is more stable than GRID especially in scenarios where wireless nodes are moving with very high velocities.


---

## Body

## 1. Introduction

Mobile ad hoc networks (MANETs) are composed of wirelessly connected nodes that form a dynamic autonomous network. In MANETs, nodes communicate with one another without any centralized base station. Over the past several years, a number of MANET routing protocols have been proposed by researchers that include proactive, reactive, and hybrid routing mechanisms [1–9]. Zone Routing Protocol (ZRP) [2] is one of the hybrid routing protocols where a reactive mechanism is initiated for interzone routing and a proactive strategy is performed for intrazone routing. Another existing hybrid routing protocol called Zone-based Hierarchical Link State (ZHLS) is proposed in [4] in which all nodes in a zone communicate in a peer-to-peer manner without any central zone-head. In ZHLS, a proactive link-state routing mechanism is performed within a zone and a reactive zone-search strategy is initiated if the target node appears in a different zone. The main drawback of this routing mechanism is that each node in the network keeps the routing information of the whole zone topology, which is quite costly in case of large numbers of nodes in a zone. In the absence of a centralized authority, each node is bound to keep and update the routing table even if it is not forwarding any packets. Although ZHLS is a location-aware routing protocol, the location information kept by the GPS receiver is not utilized effectively by the protocol. For instance, if a node intends to send a packet to a destination node present in the same zone, it utilizes its intrazone routing table constructed based on the local link-state information. But if the destination lies in another zone, the source node starts a reactive zone-search strategy to obtain the destination node’s zone ID by flooding packets in the whole network. In this case, if the protocol utilizes the location information obtained by the GPS receiver, it can save a number of unnecessary messages flooded throughout the network for searching the zone ID of the destination. Like other location-based routing protocols, a node can easily identify the zone ID of the destination if it knows its physical location. The location can be obtained by using a location server, as done in other location-based routing protocols such as LAR, GRID, GPSR, etc.In GRID [10], which is a location-aware reactive routing protocol, a grid-based routing mechanism is proposed in which each grid has a gateway node and the routing is performed only through gateway nodes in a grid-by-grid manner. The authors of GRID use the term “grid” instead of a zone. A gateway node is elected through a predefined gateway election mechanism. Like all reactive routing protocols, GRID also has a route request and a route reply mechanism to search for a route for sending packets to the destination. A major problem with this protocol is the smaller grid size. Since the main criterion for the gateway election is the shortest distance from the center of the grid, it is highly probable that the gateway nodes move out of the grid very frequently and hence, the nodes inside the grid will initiate the gateway election procedure over and over again, causing the network to become unstable. The GRID protocol does not consider any other metric for the gateway election, e.g., speed or direction of the moving gateway nodes. Moreover, since the routing is performed in a grid-by-grid manner and several grids can be there in a node’s radio range, a packet will have to take several extra hops, thereby making the protocol inefficient.Recently, we proposed a Location-aware Grid-based Hierarchical Routing (LGHR) [11] protocol for MANETs, which addressed the above-mentioned problems in ZHLS and GRID routing protocols and provided a better solution to these problems. In LGHR, each node in the network knows its own location with the help of a GPS receiver. The network is divided into nonoverlapping zones, where each zone is represented in the form of a square. Each zone is controlled by a centralized node called leader. The leader is responsible for maintaining the routing information as well as making routing decisions inside a zone. A zone is further partitioned into smaller grids, where one node is elected as a gateway node and is responsible for forwarding packets to the other nodes. The packets are routed in a gateway-by-gateway manner.In this paper, we perform an extensive evaluation of the LGHR routing protocol. We first analyze the protocol with an example scenario, and then it is compared with both ZHLS and GRID routing protocols. For comparison with ZHLS, the numerical analysis is performed and both ZHLS and LGHR protocols are evaluated for communication as well as storage overheads. The analysis shows that LGHR performs better than ZHLS in terms of both communication and storage overheads generated by all the nodes in the network. The comparison of LGHR is also performed with GRID to analyze their stability in terms of gateway election overhead. In GRID, the election mechanism considers only the distance of a node from the center of the grid. That is, a node is elected as a gateway if it is at the shortest distance from the center of the grid. Once it is elected as a gateway, it starts functioning as a gateway until it leaves its grid. If a gateway moves out of the grid, a new election mechanism will start and another node would be elected as a gateway. In case of LGHR, not only the distance from the center of the grid is considered for electing a gateway, but the velocity of a node is also taken into consideration. This means that a node is elected as a gateway whose relative distance is minimum as compared to the other nodes. The comparison is done by performing simulations for both the protocols. The stability analysis is performed by examining the effects of several parameters on the frequency of gateway elections in a grid.The remainder of the paper is organized as follows: Section2 discusses the related work. The LGHR protocol is discussed in Section 3 with an example scenario, whereas Section 4 discusses the evaluation of LGHR in detail. Finally, Section 5 concludes the paper.


## 2. Related Work

Unlike other mobile wireless networks such as cellular and wireless IP networks having wired backbones and centralized base stations, a MANET neither has a wired backbone nor it has a centralized access point. A wireless node acts both as a host and a router. The network topology changes very frequently as the route from source to destination dynamically changes due to the node mobility. Consequently, searching for an optimal route for a destination with minimum overhead has been a challenging task for researchers over the past several years. Moreover, the limited resources in MANETs such as bandwidth and power have made the designing process of a reliable and stable routing protocol a very challenging task. A routing strategy should be able to efficiently utilize the limited resources and it should adapt to the rapidly changing network conditions.Generally, ad hoc routing protocols can be classified into three main categories, i.e., proactive, reactive, and hybrid routing protocols. All these three kinds of routing protocols can be flat or hierarchical. Moreover, these routing protocols may also be location-aware or location-unaware. Proactive routing protocols make their routing decisions on the basis of prior topology information available, which is provided by nodes in the network. In reactive routing, a path is searched on-demand whenever there is a need to send a message to a destination. Hybrid mechanisms employ both the above strategies depending upon different criteria and situations. The architectures of these three kinds of routing protocols can be either flat or hierarchical and they can be location-aware or location-unaware. Several ad hoc routing protocols have been proposed by researchers during the past several years in the above categories. In the location-unaware category, DSDV [12], OLSR [3], and TBRPF [13] are proactive flat routing protocols, whereas STAR [14] is a proactive hierarchical routing protocol. AODV [9] and DSR [5] are reactive flat routing protocols, whereas CBRP [15] is a reactive hierarchical routing protocol. ZRP [2] is a hybrid flat routing protocol, whereas DDR [16] is a hybrid hierarchical routing protocol. In the location-aware category, DREAM [1] is classified as a proactive flat routing protocol, while LAR [7] and GPSR [6] are reactive flat routing protocols. Moreover, GRID [10] is a reactive hierarchical routing protocol, whereas ZHLS [4] is a hybrid hierarchical routing protocol. A detailed review and classification of ad hoc routing protocols can be found in [17, 18]. Some other recent MANET routing protocols can be found in [19–28].


## 3. Location-Aware Grid-Based Hierarchical Routing Protocol

In our location-aware hierarchical routing protocol, the leader and gateway nodes are introduced. The network is partitioned into nonoverlapping zones and a central node called leader controls each zone. The responsibility of the leader is to maintain the routing information as well as make the routing decisions inside a zone. A zone is further divided into smaller grids, where an elected gateway node is responsible for forwarding packets to the other nodes. The routing is performed in a gateway-by-gateway manner. A detailed description of the working of LGHR can be found in [11].


### 3.1. LGHR Example Scenario

In this subsection, the proposed LGHR protocol is compared with ZHLS with the help of an example. For this purpose, consider a scenario shown in Figure1. The leader node in LGHR constructs the neighbor table based on the information sent by the nodes inside a zone. Similarly, each zone leader sends the zone connectivity information of the neighboring zones to all the other leaders. Based on this information, the leader creates a zone table. The neighbor table for the example scenario is shown in Table 1 and the zone table is shown in Table 2(a). The neighbor table contains the neighbor node information of all the nodes. The position of each node is also written in the neighbor table, which is utilized for constructing the routing tables. In case of LGHR, any node, either gateway or nongateway, is said to be a neighbor of a nongateway node if it lies in the same grid as that of the nongateway node. Thus, the neighbor information sent by all nongateway nodes contains only the neighbor nodes that lie in their respective grids. In Table 1, it can be seen that node 1 has only two neighbors, i.e., nodes 2 and 3. Node 2 is a gateway node, whereas node 3 is a nongateway node. Secondly, neighbors of a gateway node can be nongateway nodes within its own grid and gateway nodes outside its grid that lie in its radio range. Hence, the neighbor information sent by gateway nodes contains the nongateway nodes in their respective grids as well as all the connected gateway nodes in their surrounding grids. The neighbor information sent by gateway nodes does not contain the nongateway nodes in other grids. For example, in Table 1, node 5 has nodes 2, 4, 6, and 8 as its neighbors, where node 4 and 6 are nongateway nodes within its own grid, whereas nodes 2 and 8 are gateway nodes outside its grid. Moreover, nodes 7 and 9 are not its neighbors, though they lie within its radio range. The advantage of such a criterion is to avoid extra information to be stored in the neighbor tables. Since routing is performed only in a gateway-by-gateway manner, the nongateway nodes consider only those nodes as their neighbors that lie in their respective grids. The above-mentioned criterion for a neighbor node is for situations where large numbers of nodes are present in each zone. It may be different for other situations. In case of large numbers of nodes, another possibility can be to allow only gateway nodes to send neighbor information to the leader.Table 1
Neighbor table for all nodes in the example.
Neighbor Table Node Position Neighbors 1 (x1,y1) 2, 3 2 (x2,y2) 1, 3, 5, 8, 10, 19 3 (x3,y3) 1, 2 4 (x4,y4) 5, 6 5 (x5,y5) 2, 4, 6, 8 6 (x6,y6) 4, 5 7 (x7,y7) 8, 9 8 (x8,y8) 2, 5, 7, 9, 10, 19, 25, 28 9 (x9,y9) 7, 8 10 (x10,y10) 2, 8, 11, 12, 19, 25 11 (x11,y11) 10 12 (x12,y12) 10, 17, 13, 14, 19, 20,25 13 (x13,y13) 12, 14 14 (x14,y14) 13, 12 15 (x15,y15) 16, 17 16 (x16,y16) 15, 17 17 (x17,y17) 12, 15, 16, 19, 20, E 19 (x19,y19) 2, 8, 10, 12, 17, 20 20 (x20,y20) 12, 17, 19, E 21 (x21,y21) 8, 22, 25, 27 22 (x22,y22) 21, 26 23 (x23,y23) 24, 25 24 (x24,y24) 23, 25 25 (x25,y25) 8, 10, 12, 21, 23, 24, 26 26 (x26,y26) 25, 22 27 (x27,y27) 21, 28, 29, C 28 (x28,y28) 8, 27, 29 29 (x29,y29) 27, 28Table 2
(a) Zone table for all connected zones in the network. (b) Intrazone routing table for node 8. (c) Interzone routing table maintained by node 17.
(a) Zone Table Zone Neighbor Zones A C, E B G, F C A, G, H D H, I E A, F F B, E G B, C H C, D I D  (b) Intra-zone Routing Table for Node 8 Destination Next Node 1 2 2 2 3 2 4 5 5 5 6 5 7 8 9 8 10 10 11 10 12 10 13 10 14 10 15 19 16 19 17 19 19 19 20 19 21 21 22 21 23 25 24 25 25 25 26 21 27 28 28 28 29 28 E 19 C 28  (c) Inter-zone Routing Table for Node 17 Dest. Zone Next Zone Next Node B E 18 C C 19 D C 19 E E 18 F E 18 G C 19 H C 19 I C 19Figure 1
(a) Local topology inside zone A for our example. The connectivity of gateway nodes with other gateways is shown with solid lines. (b) Complete interzone topology for the example scenario. The dotted line shows connectivity among zones.
(a) (b)The gateway nodes do not necessarily send IDs of the gateways that lie in their adjacent grids. The neighbor nodes are those gateways that come within the radio range of a gateway node. There can be a case where the neighbor node of a gateway lies in a grid not adjacent to its own grid. For example, in Figure1(a), node 19 does not lie in the adjacent grid of node 8 but it is connected with node 8 as it lies within its radio range, and therefore, is considered to be its neighbor. The same rule applies to nodes 2 and 10. The advantage of this gateway-by-gateway routing is that although there is no node in the adjacent grid, if there is a gateway node inside the radio range of a gateway node, it can still route packets through that gateway. Moreover, if the numbers of nodes increase in the network, it will have no or very little effect on the routing performance. Since routes are computed based on the shortest path algorithm, the computed routes will always be the best routes with shortest distance in terms of the number of hops. In GRID protocol, the routing is performed in a grid-by-grid manner even if there are gateways in nonadjacent grids that lie within the radio range of a gateway node. Hence, a number of useless hops have to be taken by each packet, making the routing process inefficient.


#### 3.1.1. Routing Table Construction

The routing table is created based on the shortest path algorithm depending upon the number of hops from the destination node. In other words, a node is selected as a next hop node, if it has the smallest number of hops from the destination node. If there is a situation where more than one path is available having same number of hops for the destination, then in that case, the physical distance is taken into consideration. Since each node that sends its neighbor information to the leader also sends its position, the physical distance between the two nodes can be easily calculated. Hence, if more than one path is available with the same number of hops, the one with the shortest physical distance from the destination would be selected. In Figure1(a), it can be seen that if node 8 wants to send a packet to node 12, it has two paths with the same number of hops, i.e., one via node 19 and the other through node 10. In such a situation, node 8 selects node 10 as the next hop since the physical distance between node 8 and 12 is shorter using node 10 as the next hop than node 19. This can be confirmed from Table 2(b).


#### 3.1.2. Analyzing Routing Entries

In LGHR, a leader creates and maintains both intrazone and interzone routing tables on the basis of neighbor and zone tables. Gateway nodes store their routing tables provided by the leader node but they do not keep the neighbor and zone tables. Moreover, neighbor and zone tables are created on the basis of node connectivity and zone connectivity information, which are almost similar as Node LSPs and Zone LSPs in ZHLS, respectively. Therefore, both intrazone and interzone routing tables can be computed easily for LGHR as well as for ZHLS. The local topology for the example scenario inside a zone is shown in Figure1(a). Solid line represents the direct radio connection between two gateway nodes. Figure 1(b) shows the complete zone-level topology with all the nine zones. The dotted line tells us which zone is connected to which other zone. Considering Figure 1 as an example, the routing entries are analyzed, which are stored in Node LSPs, Zone LSPs, interzone and intrazone routing tables, in case of ZHLS and then these are compared with the entries stored by leader and gateway nodes in LGHR. For the purpose of analysis, an entry is taken as one having one row of information stored in some table in a node. The total number of bytes may differ in different entries.In case of ZHLS, each node stores the Node LSP as well as Zone LSP and also maintains both intrazone and interzone routing tables, which is a huge burden on that node. Table2(b) shows intrazone routing entries stored by node 8 and Table 2(c) shows interzone routing table entries stored by node 17 on the basis of the example scenario in Figure 1. The number of entries stored by these nodes as well as total entries stored by all the nodes are shown in Table 3 for ZHLS. Based on the analysis, the total numbers of entries stored by all nodes are 2072. In case of LGHR, the leader node stores neighbor and zone tables as well as intrazone and interzone routing tables of only gateway nodes as routing is performed only through gateways.Edge Gateway nodes store both intrazone and interzone routing tables, whereasIntermediate Gateway nodes store only intrazone routing tables. Table 4 shows that LGHR stores only 829 entries for one zone in this example. For the purpose of generalization, if it is assumed that the numbers of nodes are uniformly distributed in all zones and the number of gateways is also the same in all zones, then the total number of entries for 9 zones would be 18648 in case of ZHLS and 7461 in case of LGHR. This clearly shows that LGHR stores much less entries than the total entries stored by ZHLS.Table 3
Entries stored by each node and all nodes in a zone in ZHLS.
Protocol Node LSP Entries Zone LSP Entries Intra-zone Routing Table Inter-zone Routing Table Total Entries Entries Stored by Each Node ZHLS 28 9 29 8 74  Entries Stored by All Nodes ZHLS 784 252 812 224 2072Table 4
Entries stored by leader and all gateway nodes in one zone in LGHR.
Protocol Entries Stored By Neighbor Table Entries Zone Table Entries Intra-zone Routing Table Inter-zone Routing Table Total Entries LGHR Leader 28 9 348 48 433 All 6 Edge Gateways 0 0 174 48 222 All 6 Intermediate Gateways 0 0 174 0 174  Total Entries stored by LGHR Protocol 829


## 3.1. LGHR Example Scenario

In this subsection, the proposed LGHR protocol is compared with ZHLS with the help of an example. For this purpose, consider a scenario shown in Figure1. The leader node in LGHR constructs the neighbor table based on the information sent by the nodes inside a zone. Similarly, each zone leader sends the zone connectivity information of the neighboring zones to all the other leaders. Based on this information, the leader creates a zone table. The neighbor table for the example scenario is shown in Table 1 and the zone table is shown in Table 2(a). The neighbor table contains the neighbor node information of all the nodes. The position of each node is also written in the neighbor table, which is utilized for constructing the routing tables. In case of LGHR, any node, either gateway or nongateway, is said to be a neighbor of a nongateway node if it lies in the same grid as that of the nongateway node. Thus, the neighbor information sent by all nongateway nodes contains only the neighbor nodes that lie in their respective grids. In Table 1, it can be seen that node 1 has only two neighbors, i.e., nodes 2 and 3. Node 2 is a gateway node, whereas node 3 is a nongateway node. Secondly, neighbors of a gateway node can be nongateway nodes within its own grid and gateway nodes outside its grid that lie in its radio range. Hence, the neighbor information sent by gateway nodes contains the nongateway nodes in their respective grids as well as all the connected gateway nodes in their surrounding grids. The neighbor information sent by gateway nodes does not contain the nongateway nodes in other grids. For example, in Table 1, node 5 has nodes 2, 4, 6, and 8 as its neighbors, where node 4 and 6 are nongateway nodes within its own grid, whereas nodes 2 and 8 are gateway nodes outside its grid. Moreover, nodes 7 and 9 are not its neighbors, though they lie within its radio range. The advantage of such a criterion is to avoid extra information to be stored in the neighbor tables. Since routing is performed only in a gateway-by-gateway manner, the nongateway nodes consider only those nodes as their neighbors that lie in their respective grids. The above-mentioned criterion for a neighbor node is for situations where large numbers of nodes are present in each zone. It may be different for other situations. In case of large numbers of nodes, another possibility can be to allow only gateway nodes to send neighbor information to the leader.Table 1
Neighbor table for all nodes in the example.
Neighbor Table Node Position Neighbors 1 (x1,y1) 2, 3 2 (x2,y2) 1, 3, 5, 8, 10, 19 3 (x3,y3) 1, 2 4 (x4,y4) 5, 6 5 (x5,y5) 2, 4, 6, 8 6 (x6,y6) 4, 5 7 (x7,y7) 8, 9 8 (x8,y8) 2, 5, 7, 9, 10, 19, 25, 28 9 (x9,y9) 7, 8 10 (x10,y10) 2, 8, 11, 12, 19, 25 11 (x11,y11) 10 12 (x12,y12) 10, 17, 13, 14, 19, 20,25 13 (x13,y13) 12, 14 14 (x14,y14) 13, 12 15 (x15,y15) 16, 17 16 (x16,y16) 15, 17 17 (x17,y17) 12, 15, 16, 19, 20, E 19 (x19,y19) 2, 8, 10, 12, 17, 20 20 (x20,y20) 12, 17, 19, E 21 (x21,y21) 8, 22, 25, 27 22 (x22,y22) 21, 26 23 (x23,y23) 24, 25 24 (x24,y24) 23, 25 25 (x25,y25) 8, 10, 12, 21, 23, 24, 26 26 (x26,y26) 25, 22 27 (x27,y27) 21, 28, 29, C 28 (x28,y28) 8, 27, 29 29 (x29,y29) 27, 28Table 2
(a) Zone table for all connected zones in the network. (b) Intrazone routing table for node 8. (c) Interzone routing table maintained by node 17.
(a) Zone Table Zone Neighbor Zones A C, E B G, F C A, G, H D H, I E A, F F B, E G B, C H C, D I D  (b) Intra-zone Routing Table for Node 8 Destination Next Node 1 2 2 2 3 2 4 5 5 5 6 5 7 8 9 8 10 10 11 10 12 10 13 10 14 10 15 19 16 19 17 19 19 19 20 19 21 21 22 21 23 25 24 25 25 25 26 21 27 28 28 28 29 28 E 19 C 28  (c) Inter-zone Routing Table for Node 17 Dest. Zone Next Zone Next Node B E 18 C C 19 D C 19 E E 18 F E 18 G C 19 H C 19 I C 19Figure 1
(a) Local topology inside zone A for our example. The connectivity of gateway nodes with other gateways is shown with solid lines. (b) Complete interzone topology for the example scenario. The dotted line shows connectivity among zones.
(a) (b)The gateway nodes do not necessarily send IDs of the gateways that lie in their adjacent grids. The neighbor nodes are those gateways that come within the radio range of a gateway node. There can be a case where the neighbor node of a gateway lies in a grid not adjacent to its own grid. For example, in Figure1(a), node 19 does not lie in the adjacent grid of node 8 but it is connected with node 8 as it lies within its radio range, and therefore, is considered to be its neighbor. The same rule applies to nodes 2 and 10. The advantage of this gateway-by-gateway routing is that although there is no node in the adjacent grid, if there is a gateway node inside the radio range of a gateway node, it can still route packets through that gateway. Moreover, if the numbers of nodes increase in the network, it will have no or very little effect on the routing performance. Since routes are computed based on the shortest path algorithm, the computed routes will always be the best routes with shortest distance in terms of the number of hops. In GRID protocol, the routing is performed in a grid-by-grid manner even if there are gateways in nonadjacent grids that lie within the radio range of a gateway node. Hence, a number of useless hops have to be taken by each packet, making the routing process inefficient.


### 3.1.1. Routing Table Construction

The routing table is created based on the shortest path algorithm depending upon the number of hops from the destination node. In other words, a node is selected as a next hop node, if it has the smallest number of hops from the destination node. If there is a situation where more than one path is available having same number of hops for the destination, then in that case, the physical distance is taken into consideration. Since each node that sends its neighbor information to the leader also sends its position, the physical distance between the two nodes can be easily calculated. Hence, if more than one path is available with the same number of hops, the one with the shortest physical distance from the destination would be selected. In Figure1(a), it can be seen that if node 8 wants to send a packet to node 12, it has two paths with the same number of hops, i.e., one via node 19 and the other through node 10. In such a situation, node 8 selects node 10 as the next hop since the physical distance between node 8 and 12 is shorter using node 10 as the next hop than node 19. This can be confirmed from Table 2(b).


### 3.1.2. Analyzing Routing Entries

In LGHR, a leader creates and maintains both intrazone and interzone routing tables on the basis of neighbor and zone tables. Gateway nodes store their routing tables provided by the leader node but they do not keep the neighbor and zone tables. Moreover, neighbor and zone tables are created on the basis of node connectivity and zone connectivity information, which are almost similar as Node LSPs and Zone LSPs in ZHLS, respectively. Therefore, both intrazone and interzone routing tables can be computed easily for LGHR as well as for ZHLS. The local topology for the example scenario inside a zone is shown in Figure1(a). Solid line represents the direct radio connection between two gateway nodes. Figure 1(b) shows the complete zone-level topology with all the nine zones. The dotted line tells us which zone is connected to which other zone. Considering Figure 1 as an example, the routing entries are analyzed, which are stored in Node LSPs, Zone LSPs, interzone and intrazone routing tables, in case of ZHLS and then these are compared with the entries stored by leader and gateway nodes in LGHR. For the purpose of analysis, an entry is taken as one having one row of information stored in some table in a node. The total number of bytes may differ in different entries.In case of ZHLS, each node stores the Node LSP as well as Zone LSP and also maintains both intrazone and interzone routing tables, which is a huge burden on that node. Table2(b) shows intrazone routing entries stored by node 8 and Table 2(c) shows interzone routing table entries stored by node 17 on the basis of the example scenario in Figure 1. The number of entries stored by these nodes as well as total entries stored by all the nodes are shown in Table 3 for ZHLS. Based on the analysis, the total numbers of entries stored by all nodes are 2072. In case of LGHR, the leader node stores neighbor and zone tables as well as intrazone and interzone routing tables of only gateway nodes as routing is performed only through gateways.Edge Gateway nodes store both intrazone and interzone routing tables, whereasIntermediate Gateway nodes store only intrazone routing tables. Table 4 shows that LGHR stores only 829 entries for one zone in this example. For the purpose of generalization, if it is assumed that the numbers of nodes are uniformly distributed in all zones and the number of gateways is also the same in all zones, then the total number of entries for 9 zones would be 18648 in case of ZHLS and 7461 in case of LGHR. This clearly shows that LGHR stores much less entries than the total entries stored by ZHLS.Table 3
Entries stored by each node and all nodes in a zone in ZHLS.
Protocol Node LSP Entries Zone LSP Entries Intra-zone Routing Table Inter-zone Routing Table Total Entries Entries Stored by Each Node ZHLS 28 9 29 8 74  Entries Stored by All Nodes ZHLS 784 252 812 224 2072Table 4
Entries stored by leader and all gateway nodes in one zone in LGHR.
Protocol Entries Stored By Neighbor Table Entries Zone Table Entries Intra-zone Routing Table Inter-zone Routing Table Total Entries LGHR Leader 28 9 348 48 433 All 6 Edge Gateways 0 0 174 48 222 All 6 Intermediate Gateways 0 0 174 0 174  Total Entries stored by LGHR Protocol 829


## 3.1.1. Routing Table Construction

The routing table is created based on the shortest path algorithm depending upon the number of hops from the destination node. In other words, a node is selected as a next hop node, if it has the smallest number of hops from the destination node. If there is a situation where more than one path is available having same number of hops for the destination, then in that case, the physical distance is taken into consideration. Since each node that sends its neighbor information to the leader also sends its position, the physical distance between the two nodes can be easily calculated. Hence, if more than one path is available with the same number of hops, the one with the shortest physical distance from the destination would be selected. In Figure1(a), it can be seen that if node 8 wants to send a packet to node 12, it has two paths with the same number of hops, i.e., one via node 19 and the other through node 10. In such a situation, node 8 selects node 10 as the next hop since the physical distance between node 8 and 12 is shorter using node 10 as the next hop than node 19. This can be confirmed from Table 2(b).


## 3.1.2. Analyzing Routing Entries

In LGHR, a leader creates and maintains both intrazone and interzone routing tables on the basis of neighbor and zone tables. Gateway nodes store their routing tables provided by the leader node but they do not keep the neighbor and zone tables. Moreover, neighbor and zone tables are created on the basis of node connectivity and zone connectivity information, which are almost similar as Node LSPs and Zone LSPs in ZHLS, respectively. Therefore, both intrazone and interzone routing tables can be computed easily for LGHR as well as for ZHLS. The local topology for the example scenario inside a zone is shown in Figure1(a). Solid line represents the direct radio connection between two gateway nodes. Figure 1(b) shows the complete zone-level topology with all the nine zones. The dotted line tells us which zone is connected to which other zone. Considering Figure 1 as an example, the routing entries are analyzed, which are stored in Node LSPs, Zone LSPs, interzone and intrazone routing tables, in case of ZHLS and then these are compared with the entries stored by leader and gateway nodes in LGHR. For the purpose of analysis, an entry is taken as one having one row of information stored in some table in a node. The total number of bytes may differ in different entries.In case of ZHLS, each node stores the Node LSP as well as Zone LSP and also maintains both intrazone and interzone routing tables, which is a huge burden on that node. Table2(b) shows intrazone routing entries stored by node 8 and Table 2(c) shows interzone routing table entries stored by node 17 on the basis of the example scenario in Figure 1. The number of entries stored by these nodes as well as total entries stored by all the nodes are shown in Table 3 for ZHLS. Based on the analysis, the total numbers of entries stored by all nodes are 2072. In case of LGHR, the leader node stores neighbor and zone tables as well as intrazone and interzone routing tables of only gateway nodes as routing is performed only through gateways.Edge Gateway nodes store both intrazone and interzone routing tables, whereasIntermediate Gateway nodes store only intrazone routing tables. Table 4 shows that LGHR stores only 829 entries for one zone in this example. For the purpose of generalization, if it is assumed that the numbers of nodes are uniformly distributed in all zones and the number of gateways is also the same in all zones, then the total number of entries for 9 zones would be 18648 in case of ZHLS and 7461 in case of LGHR. This clearly shows that LGHR stores much less entries than the total entries stored by ZHLS.Table 3
Entries stored by each node and all nodes in a zone in ZHLS.
Protocol Node LSP Entries Zone LSP Entries Intra-zone Routing Table Inter-zone Routing Table Total Entries Entries Stored by Each Node ZHLS 28 9 29 8 74  Entries Stored by All Nodes ZHLS 784 252 812 224 2072Table 4
Entries stored by leader and all gateway nodes in one zone in LGHR.
Protocol Entries Stored By Neighbor Table Entries Zone Table Entries Intra-zone Routing Table Inter-zone Routing Table Total Entries LGHR Leader 28 9 348 48 433 All 6 Edge Gateways 0 0 174 48 222 All 6 Intermediate Gateways 0 0 174 0 174  Total Entries stored by LGHR Protocol 829


## 4. Evaluation of LGHR

In this section, the proposed LGHR protocol is compared with two other ad hoc routing protocols, i.e., ZHLS and GRID. In case of comparison with ZHLS, the mathematical analysis is performed for both ZHLS and LGHR. Based on this analysis, the evaluation and comparison is carried out for both the protocols. The details of the mathematical analysis can be found in [11]. The comparison of LGHR with GRID cannot be fully done in all aspects, as both protocols are different in the basic routing functionality. GRID is a reactive routing protocol, whereas LGHR is a proactive routing protocol. The common thing in both the protocols is that a gateway election mechanism is carried out in each grid. It is shown that the mechanism proposed in LGHR is more robust and stable than the one shown in GRID.


### 4.1. Comparison with ZHLS

For evaluation, the equations of the mathematical analysis done in [11] are used. The proposed protocol LGHR is compared with ZHLS in terms of storage overhead as well as communication overhead generated.


#### 4.1.1. Storage Overhead

Both LGHR and ZHLS protocols are compared separately for 9 and 16 gateways per zone based on the storage overhead analysis. The value for the total number of zones is in the network is 16. The numbers of nodes are increased to 1000 in the whole network. We assume that each grid in a zone contains one gateway and the gateway nodes are separated asEdge andIntermediate Gateway nodes. It can be seen that as we increase the number of nodes in the network, the number of entries stored by both the protocols also increases. However, LGHR performs better than ZHLS in all cases and stores smaller number of entries as compared to ZHLS. The results of the analysis are shown in Figure 2. These results are for one gateway in each grid. Therefore, even if the numbers of nodes are increased in LGHR, there is a very small increase in the number of entries stored, as nongateway nodes are not responsible for storing any tables. Whereas in ZHLS, each node has to store all the required entries and hence, there is a major increase in the storage overhead incurred by the protocol in case of increasing the number of nodes. In the figures, the effect on the storage overhead is shown from the point where the numbers of nodes are the same in both the protocols.Figure 2
Comparison of LGHR with ZHLS in terms of number of entries stored for a network of 1000 nodes having 16 zones in the network. The values are shown for (a) 9 gateways per zone and (b) 16 gateways per zone.
(a) (b)


#### 4.1.2. Communication Overhead

The comparison of the communication overhead for topology creation for both ZHLS and LGHR protocols is shown in Figure3 based on the mathematical analysis. Figure 3(a) shows the comparison for 16 zones and Figure 3(b) shows the comparison for 25 zones in the network. In all cases, the communication overhead generated by LGHR is much less than that of ZHLS. The reason is that, in ZHLS, all nodes send their Node LSPs to all nodes in their zone. Similarly, each Zone LSP is sent to all the nodes. In case of LGHR, nodes in a zone are required to send their neighbor information to only the leader node. Similarly, zone tables are also propagated to only the leader nodes, not to all nodes in the network. Moreover, the leader sends the respective routing tables to only the gateway nodes. Hence, the communication overhead for topology creation by LGHR is much less than the one generated by ZHLS.Figure 3
Communication overhead for topology creation generated by both LGHR and ZHLS protocols in case of (a) 16 zones in the network and (b) 25 zones in the network.
(a) (b)


### 4.2. Comparison with GRID

The comparison of LGHR is performed with GRID protocol to analyze the stability of the protocol in terms of the gateway election overhead. In GRID, the election mechanism considers only the distance of a node from the center of the grid. That is, a node is elected as a gateway if it is at the shortest distance from the center of the grid. Once it is elected as a gateway, it starts functioning as a gateway until it leaves its grid. If a gateway goes out of the grid, a new election mechanism will start and another node would be elected as a gateway. In case of LGHR, not only the distance from the center of the grid is considered for electing a gateway, but the velocity of a node is also taken into consideration. This means that a node is elected as a gateway node whose relative distance from the center of the grid is minimum as compared to the other nodes. This distance is calculated by using the following equation:(1)disti=Xi-Xc2+Yi-Yc2+Vi2Here,Xi and Yi are the position coordinates of the ith announcing node, Xc and Yc are the center coordinates of the grid, and Vi is the velocity of the ith node. Further details about the gateway election procedure can be found in [11]. In both the protocols, the routing is performed by gateway nodes only and nongateway nodes are not responsible for forwarding packets to the other nodes; hence, the gateway node should be able to stay in the grid for longer periods of time. If the gateway node moves out of the grid quite frequently, then each time a gateway moves out, a new election mechanism will be performed. In case of mobile nodes moving with higher velocities, the gateway nodes are more likely to leave the grid frequently. Hence, the protocol will work in a more stable manner when the gateway election procedure is performed less frequently, which means that the gateway node stays inside the grid for longer periods of time. Using this criterion, the gateway election can be considered as a parameter for stability of the routing protocol.The comparison is performed by doing simulations for both the protocols. In order to compare LGHR with GRID, the simulation environment is developed and the results are analyzed. The stability of both the protocols is analyzed by examining the effects of several parameters on the frequency of gateway elections in a grid. The parameters are, (1) velocity of nodes, (2) number of nodes in a grid, (3) size of the grid, and (4) simulation time. For all simulations, the initialization angle is taken to be 150 degrees. The curve parameterα is taken as1. The nodes are generated and placed in a fixed-size grid and then they are moved with given maximum velocities in random directions. Each simulation is performed five times and then the average of all the values is taken.


#### 4.2.1. Effect of Velocity and Number of Nodes

In order to analyze the effect of velocity, the simulations are performed where the total number of nodes are 30, simulation time is 50 units, and grid size = 50 × 50. The results of keeping the number of nodes constant and increasing the velocity are shown in Figure4(a). As shown in the figure, by increasing the velocity of mobile nodes, the number of elections for the gateway node also increases for both the protocols. This is because if nodes are moving with a higher velocity, then there is a higher probability that the nodes will go out of the grid very frequently. Hence, there will be more elections for gateway nodes for both the protocols. For the case of lower maximum velocity, both protocols perform almost the same. As the velocity is increased, the number of elections in case of GRID starts increasing. The reason is that in GRID, there is no consideration of the velocity of mobile nodes and only the distance from the center of the grid is considered in order to elect a gateway. On the other hand, LGHR considers both the distance from the center of the grid as well as the velocity of the mobile nodes for electing a gateway node. Therefore, in case of LGHR, those nodes are elected as gateway nodes that have lower velocities and shorter distances from the center of the grid, hence making the protocol more stable.Figure 4
Comparison of LGHR and GRID in terms of (a) velocity of mobile nodes and (b) number of nodes in a grid.
(a) (b)For the second case, the following parameters are kept constant and the number of nodes is increased: maximum velocity = 150 units, grid size = 50 × 50, and simulation time = 30 units. The maximum velocity of nodes is kept constant as 150 units and the number of nodes is increased up to 100 nodes per grid. Figure4(b) shows that by keeping the velocity constant and increasing the number of nodes, LGHR performs better than GRID. For the case when nodes are equal to 100, the difference between both the protocols becomes smaller. It is observed that if the numbers of nodes in the grid are small, then the difference between both the protocols is large. But as the numbers of nodes are increased in the grid, the difference becomes smaller between both the protocols. Since a grid is a very small part of a zone, the numbers of nodes in a grid are likely to be smaller in number. Therefore, the proposed LGHR protocol performs better than GRID in that case. The results in the figure show that even though the difference between both the protocols is small for 100 nodes, LGHR still performs better than GRID and is more stable even in that case.


#### 4.2.2. Effect of Grid Size and Simulation Time

In order to analyze the effect of grid size in both LGHR and GRID protocols, the following parameters are kept constant: total nodes in a grid = 30, maximum velocity = 150 units, and simulation time = 20 units. Figure5 shows that for smaller grid sizes, LGHR is more stable than GRID as it has less number of elections. As the grid size increases, the performance of both the protocols becomes similar, which means that for larger grid sizes, both the protocols work in almost the same manner. As mentioned earlier, the grid size is usually much smaller than the total size of a zone. Therefore, in realistic scenarios, for smaller grid sizes, LGHR performs better than GRID. We can see in the figure that for smaller grid sizes, more elections are likely to take place, which is due to the fact that the nodes move out of the grid very frequently. On the other hand, when the grid size is large, for example, in case of 100×100 units, the gateway elections are performed only five times in a given simulation time. Hence, the elections take place less frequently when the grid size is large.Figure 5
Comparison of LGHR and GRID in terms of (a) grid size and (b) simulation time.
(a) (b)It is observed that the duration of the simulation also affects the frequency of gateway elections. For this analysis, the following parameters are kept constant: total nodes in a grid = 30, maximum velocity = 150 units, and grid size = 50 × 50. From Figure5(b), it is clear that the simulation time also affects the number of elections performed in a grid by both the protocols. The simulations are performed by keeping the simulation time as 10 units and then increasing it up to 50 units. It is observed that even if the simulation time is increased, LGHR still performs better than GRID. This is another indicator of the stable performance of LGHR in situations where nodes are likely to be present in the network for larger durations. The results clearly depict the effectiveness of the gateway election mechanism used in LGHR over the one used in GRID. Hence, the protocol works in a more stable manner if both the velocity and distance from the center of the grid are taken into consideration while electing the gateway node.


## 4.1. Comparison with ZHLS

For evaluation, the equations of the mathematical analysis done in [11] are used. The proposed protocol LGHR is compared with ZHLS in terms of storage overhead as well as communication overhead generated.


### 4.1.1. Storage Overhead

Both LGHR and ZHLS protocols are compared separately for 9 and 16 gateways per zone based on the storage overhead analysis. The value for the total number of zones is in the network is 16. The numbers of nodes are increased to 1000 in the whole network. We assume that each grid in a zone contains one gateway and the gateway nodes are separated asEdge andIntermediate Gateway nodes. It can be seen that as we increase the number of nodes in the network, the number of entries stored by both the protocols also increases. However, LGHR performs better than ZHLS in all cases and stores smaller number of entries as compared to ZHLS. The results of the analysis are shown in Figure 2. These results are for one gateway in each grid. Therefore, even if the numbers of nodes are increased in LGHR, there is a very small increase in the number of entries stored, as nongateway nodes are not responsible for storing any tables. Whereas in ZHLS, each node has to store all the required entries and hence, there is a major increase in the storage overhead incurred by the protocol in case of increasing the number of nodes. In the figures, the effect on the storage overhead is shown from the point where the numbers of nodes are the same in both the protocols.Figure 2
Comparison of LGHR with ZHLS in terms of number of entries stored for a network of 1000 nodes having 16 zones in the network. The values are shown for (a) 9 gateways per zone and (b) 16 gateways per zone.
(a) (b)


### 4.1.2. Communication Overhead

The comparison of the communication overhead for topology creation for both ZHLS and LGHR protocols is shown in Figure3 based on the mathematical analysis. Figure 3(a) shows the comparison for 16 zones and Figure 3(b) shows the comparison for 25 zones in the network. In all cases, the communication overhead generated by LGHR is much less than that of ZHLS. The reason is that, in ZHLS, all nodes send their Node LSPs to all nodes in their zone. Similarly, each Zone LSP is sent to all the nodes. In case of LGHR, nodes in a zone are required to send their neighbor information to only the leader node. Similarly, zone tables are also propagated to only the leader nodes, not to all nodes in the network. Moreover, the leader sends the respective routing tables to only the gateway nodes. Hence, the communication overhead for topology creation by LGHR is much less than the one generated by ZHLS.Figure 3
Communication overhead for topology creation generated by both LGHR and ZHLS protocols in case of (a) 16 zones in the network and (b) 25 zones in the network.
(a) (b)


## 4.1.1. Storage Overhead

Both LGHR and ZHLS protocols are compared separately for 9 and 16 gateways per zone based on the storage overhead analysis. The value for the total number of zones is in the network is 16. The numbers of nodes are increased to 1000 in the whole network. We assume that each grid in a zone contains one gateway and the gateway nodes are separated asEdge andIntermediate Gateway nodes. It can be seen that as we increase the number of nodes in the network, the number of entries stored by both the protocols also increases. However, LGHR performs better than ZHLS in all cases and stores smaller number of entries as compared to ZHLS. The results of the analysis are shown in Figure 2. These results are for one gateway in each grid. Therefore, even if the numbers of nodes are increased in LGHR, there is a very small increase in the number of entries stored, as nongateway nodes are not responsible for storing any tables. Whereas in ZHLS, each node has to store all the required entries and hence, there is a major increase in the storage overhead incurred by the protocol in case of increasing the number of nodes. In the figures, the effect on the storage overhead is shown from the point where the numbers of nodes are the same in both the protocols.Figure 2
Comparison of LGHR with ZHLS in terms of number of entries stored for a network of 1000 nodes having 16 zones in the network. The values are shown for (a) 9 gateways per zone and (b) 16 gateways per zone.
(a) (b)


## 4.1.2. Communication Overhead

The comparison of the communication overhead for topology creation for both ZHLS and LGHR protocols is shown in Figure3 based on the mathematical analysis. Figure 3(a) shows the comparison for 16 zones and Figure 3(b) shows the comparison for 25 zones in the network. In all cases, the communication overhead generated by LGHR is much less than that of ZHLS. The reason is that, in ZHLS, all nodes send their Node LSPs to all nodes in their zone. Similarly, each Zone LSP is sent to all the nodes. In case of LGHR, nodes in a zone are required to send their neighbor information to only the leader node. Similarly, zone tables are also propagated to only the leader nodes, not to all nodes in the network. Moreover, the leader sends the respective routing tables to only the gateway nodes. Hence, the communication overhead for topology creation by LGHR is much less than the one generated by ZHLS.Figure 3
Communication overhead for topology creation generated by both LGHR and ZHLS protocols in case of (a) 16 zones in the network and (b) 25 zones in the network.
(a) (b)


## 4.2. Comparison with GRID

The comparison of LGHR is performed with GRID protocol to analyze the stability of the protocol in terms of the gateway election overhead. In GRID, the election mechanism considers only the distance of a node from the center of the grid. That is, a node is elected as a gateway if it is at the shortest distance from the center of the grid. Once it is elected as a gateway, it starts functioning as a gateway until it leaves its grid. If a gateway goes out of the grid, a new election mechanism will start and another node would be elected as a gateway. In case of LGHR, not only the distance from the center of the grid is considered for electing a gateway, but the velocity of a node is also taken into consideration. This means that a node is elected as a gateway node whose relative distance from the center of the grid is minimum as compared to the other nodes. This distance is calculated by using the following equation:(1)disti=Xi-Xc2+Yi-Yc2+Vi2Here,Xi and Yi are the position coordinates of the ith announcing node, Xc and Yc are the center coordinates of the grid, and Vi is the velocity of the ith node. Further details about the gateway election procedure can be found in [11]. In both the protocols, the routing is performed by gateway nodes only and nongateway nodes are not responsible for forwarding packets to the other nodes; hence, the gateway node should be able to stay in the grid for longer periods of time. If the gateway node moves out of the grid quite frequently, then each time a gateway moves out, a new election mechanism will be performed. In case of mobile nodes moving with higher velocities, the gateway nodes are more likely to leave the grid frequently. Hence, the protocol will work in a more stable manner when the gateway election procedure is performed less frequently, which means that the gateway node stays inside the grid for longer periods of time. Using this criterion, the gateway election can be considered as a parameter for stability of the routing protocol.The comparison is performed by doing simulations for both the protocols. In order to compare LGHR with GRID, the simulation environment is developed and the results are analyzed. The stability of both the protocols is analyzed by examining the effects of several parameters on the frequency of gateway elections in a grid. The parameters are, (1) velocity of nodes, (2) number of nodes in a grid, (3) size of the grid, and (4) simulation time. For all simulations, the initialization angle is taken to be 150 degrees. The curve parameterα is taken as1. The nodes are generated and placed in a fixed-size grid and then they are moved with given maximum velocities in random directions. Each simulation is performed five times and then the average of all the values is taken.


### 4.2.1. Effect of Velocity and Number of Nodes

In order to analyze the effect of velocity, the simulations are performed where the total number of nodes are 30, simulation time is 50 units, and grid size = 50 × 50. The results of keeping the number of nodes constant and increasing the velocity are shown in Figure4(a). As shown in the figure, by increasing the velocity of mobile nodes, the number of elections for the gateway node also increases for both the protocols. This is because if nodes are moving with a higher velocity, then there is a higher probability that the nodes will go out of the grid very frequently. Hence, there will be more elections for gateway nodes for both the protocols. For the case of lower maximum velocity, both protocols perform almost the same. As the velocity is increased, the number of elections in case of GRID starts increasing. The reason is that in GRID, there is no consideration of the velocity of mobile nodes and only the distance from the center of the grid is considered in order to elect a gateway. On the other hand, LGHR considers both the distance from the center of the grid as well as the velocity of the mobile nodes for electing a gateway node. Therefore, in case of LGHR, those nodes are elected as gateway nodes that have lower velocities and shorter distances from the center of the grid, hence making the protocol more stable.Figure 4
Comparison of LGHR and GRID in terms of (a) velocity of mobile nodes and (b) number of nodes in a grid.
(a) (b)For the second case, the following parameters are kept constant and the number of nodes is increased: maximum velocity = 150 units, grid size = 50 × 50, and simulation time = 30 units. The maximum velocity of nodes is kept constant as 150 units and the number of nodes is increased up to 100 nodes per grid. Figure4(b) shows that by keeping the velocity constant and increasing the number of nodes, LGHR performs better than GRID. For the case when nodes are equal to 100, the difference between both the protocols becomes smaller. It is observed that if the numbers of nodes in the grid are small, then the difference between both the protocols is large. But as the numbers of nodes are increased in the grid, the difference becomes smaller between both the protocols. Since a grid is a very small part of a zone, the numbers of nodes in a grid are likely to be smaller in number. Therefore, the proposed LGHR protocol performs better than GRID in that case. The results in the figure show that even though the difference between both the protocols is small for 100 nodes, LGHR still performs better than GRID and is more stable even in that case.


### 4.2.2. Effect of Grid Size and Simulation Time

In order to analyze the effect of grid size in both LGHR and GRID protocols, the following parameters are kept constant: total nodes in a grid = 30, maximum velocity = 150 units, and simulation time = 20 units. Figure5 shows that for smaller grid sizes, LGHR is more stable than GRID as it has less number of elections. As the grid size increases, the performance of both the protocols becomes similar, which means that for larger grid sizes, both the protocols work in almost the same manner. As mentioned earlier, the grid size is usually much smaller than the total size of a zone. Therefore, in realistic scenarios, for smaller grid sizes, LGHR performs better than GRID. We can see in the figure that for smaller grid sizes, more elections are likely to take place, which is due to the fact that the nodes move out of the grid very frequently. On the other hand, when the grid size is large, for example, in case of 100×100 units, the gateway elections are performed only five times in a given simulation time. Hence, the elections take place less frequently when the grid size is large.Figure 5
Comparison of LGHR and GRID in terms of (a) grid size and (b) simulation time.
(a) (b)It is observed that the duration of the simulation also affects the frequency of gateway elections. For this analysis, the following parameters are kept constant: total nodes in a grid = 30, maximum velocity = 150 units, and grid size = 50 × 50. From Figure5(b), it is clear that the simulation time also affects the number of elections performed in a grid by both the protocols. The simulations are performed by keeping the simulation time as 10 units and then increasing it up to 50 units. It is observed that even if the simulation time is increased, LGHR still performs better than GRID. This is another indicator of the stable performance of LGHR in situations where nodes are likely to be present in the network for larger durations. The results clearly depict the effectiveness of the gateway election mechanism used in LGHR over the one used in GRID. Hence, the protocol works in a more stable manner if both the velocity and distance from the center of the grid are taken into consideration while electing the gateway node.


## 4.2.1. Effect of Velocity and Number of Nodes

In order to analyze the effect of velocity, the simulations are performed where the total number of nodes are 30, simulation time is 50 units, and grid size = 50 × 50. The results of keeping the number of nodes constant and increasing the velocity are shown in Figure4(a). As shown in the figure, by increasing the velocity of mobile nodes, the number of elections for the gateway node also increases for both the protocols. This is because if nodes are moving with a higher velocity, then there is a higher probability that the nodes will go out of the grid very frequently. Hence, there will be more elections for gateway nodes for both the protocols. For the case of lower maximum velocity, both protocols perform almost the same. As the velocity is increased, the number of elections in case of GRID starts increasing. The reason is that in GRID, there is no consideration of the velocity of mobile nodes and only the distance from the center of the grid is considered in order to elect a gateway. On the other hand, LGHR considers both the distance from the center of the grid as well as the velocity of the mobile nodes for electing a gateway node. Therefore, in case of LGHR, those nodes are elected as gateway nodes that have lower velocities and shorter distances from the center of the grid, hence making the protocol more stable.Figure 4
Comparison of LGHR and GRID in terms of (a) velocity of mobile nodes and (b) number of nodes in a grid.
(a) (b)For the second case, the following parameters are kept constant and the number of nodes is increased: maximum velocity = 150 units, grid size = 50 × 50, and simulation time = 30 units. The maximum velocity of nodes is kept constant as 150 units and the number of nodes is increased up to 100 nodes per grid. Figure4(b) shows that by keeping the velocity constant and increasing the number of nodes, LGHR performs better than GRID. For the case when nodes are equal to 100, the difference between both the protocols becomes smaller. It is observed that if the numbers of nodes in the grid are small, then the difference between both the protocols is large. But as the numbers of nodes are increased in the grid, the difference becomes smaller between both the protocols. Since a grid is a very small part of a zone, the numbers of nodes in a grid are likely to be smaller in number. Therefore, the proposed LGHR protocol performs better than GRID in that case. The results in the figure show that even though the difference between both the protocols is small for 100 nodes, LGHR still performs better than GRID and is more stable even in that case.


## 4.2.2. Effect of Grid Size and Simulation Time

In order to analyze the effect of grid size in both LGHR and GRID protocols, the following parameters are kept constant: total nodes in a grid = 30, maximum velocity = 150 units, and simulation time = 20 units. Figure5 shows that for smaller grid sizes, LGHR is more stable than GRID as it has less number of elections. As the grid size increases, the performance of both the protocols becomes similar, which means that for larger grid sizes, both the protocols work in almost the same manner. As mentioned earlier, the grid size is usually much smaller than the total size of a zone. Therefore, in realistic scenarios, for smaller grid sizes, LGHR performs better than GRID. We can see in the figure that for smaller grid sizes, more elections are likely to take place, which is due to the fact that the nodes move out of the grid very frequently. On the other hand, when the grid size is large, for example, in case of 100×100 units, the gateway elections are performed only five times in a given simulation time. Hence, the elections take place less frequently when the grid size is large.Figure 5
Comparison of LGHR and GRID in terms of (a) grid size and (b) simulation time.
(a) (b)It is observed that the duration of the simulation also affects the frequency of gateway elections. For this analysis, the following parameters are kept constant: total nodes in a grid = 30, maximum velocity = 150 units, and grid size = 50 × 50. From Figure5(b), it is clear that the simulation time also affects the number of elections performed in a grid by both the protocols. The simulations are performed by keeping the simulation time as 10 units and then increasing it up to 50 units. It is observed that even if the simulation time is increased, LGHR still performs better than GRID. This is another indicator of the stable performance of LGHR in situations where nodes are likely to be present in the network for larger durations. The results clearly depict the effectiveness of the gateway election mechanism used in LGHR over the one used in GRID. Hence, the protocol works in a more stable manner if both the velocity and distance from the center of the grid are taken into consideration while electing the gateway node.


## 5. Conclusion

In this work, a detailed analysis of the Location-aware Grid-based Hierarchical Routing (LGHR) protocol is performed and the protocol is compared with two other location-aware routing protocols, i.e., ZHLS and GRID. For comparison with ZHLS, the mathematical analysis is performed and based on the analysis, both ZHLS and LGHR protocols are evaluated for storage overhead as well as for communication overhead. Moreover, the effects of increasing the number of nodes as well as zones for both the protocols are analyzed. The analysis clearly indicates that LGHR performs better than ZHLS in terms of storage overhead as well as communication overhead generated by all the nodes. ZHLS uses a hybrid approach, which may be suitable if there are small numbers of nodes in the network. However, when the nodes are increased, ZHLS incurs huge communication overhead as all nodes in a zone proactively send their link-state packets to all other nodes in that zone. Moreover, it has a reactive zone-search mechanism, which is initiated each time a destination is found in a different zone. In LGHR, since only eligible nodes with sufficient resources can opt for becoming a leader, the burden on the leader due to carrying the routing information of other nodes can be ignored. LGHR is also compared with the GRID protocol in terms of stability. The results show that LGHR is more stable than GRID by considering the position of a node as well as its velocity for electing gateways in a grid. In all cases, LGHR outperforms GRID routing protocol and works in a more stable manner.



---

*Source: 1583205-2018-11-01.xml*