Abstract
Mobile Opportunistic Networks (OppNets) are infrastructure-less networks consisting of wireless mobile nodes and have been a focus of research for years. OppNets can be scaled up to support rapid growth of wireless devices and technologies, especially smartphones and tablets. Mobile Ad Hoc Networks (MANETs), one of OppNets technologies, have a high potential to be used for facilitating an extension for the Internet and a backup communication platform in disaster situation. However, a connection disruption due to node mobility and unreliable wireless links is possible to trigger a flooding operation of route repair process. This results in transmission delay and packet loss. The flooding of routing packets is an expensive operation cost in MANETs which affects network reliability and wastes limited resources such as network bandwidth and node energy. These are obstacles to practical implementation of MANETs in real-world environment. In this paper, we propose Low Overhead Localized Flooding (LOLF), an efficient overhead reduction routing extension based on Query Localization (QL) routing protocol. The purpose of this work is to control the propagation of routing packets in the route discovery and route repair mechanisms while incurring only a small increase in the size of control information in the packet. Simulation results from extensive experiments show that our proposed method can reduce overall routing overhead, energy consumption, and end-to-end delay without sacrificing the packet delivery ratio compared to existing protocols.
1. Introduction
Currently, Mobile Opportunistic Networks (OppNets) [1] are networking technologies which are highly discussed by researchers and being interested in industries. Depending on the network design, OppNets can provide temporary (or even permanent) infrastructure-less multihop communication. Many types of OppNets are widely discussed and proposed in the last decade, such as Mobile Ad Hoc Networks (MANETs) [2], Delay-Tolerant Networks (DTNs) [3], Wireless Sensor Networks (WSNs) [4], and Wireless Mesh Networks (WMNs) [5]. These types of networks have their own characteristics and are generally designed to use in a different situation. MANETs and DTNs are designed for mobile nodes while most of the nodes in WSNs and WMNs are almost stationary and mainly used in sensing and collecting environmental data. Researchers and industries are now applying these technologies to their applications in today’s market (for example, AdHocDroid [6], FireChat [7], Echo [8], and Briar [9]).
At present, many people use a smartphone for Internet activities such as surfing websites, downloading, and uploading information. This also includes real-time based applications, such as instant messaging and streaming application (VoIP, IPTV, and video conferencing). When looking at OppNets, there are two competitive technologies which have potential to support today’s Internet activities for smartphone users, i.e., DTNs and MANETs. DTNs are designed for the situation that connection establishment is not possible, such as in low-density and high mobility networks where network partition always occurs. A connectionless communication, Store-Carry-Forward [10] mechanism, is deployed in DTNs to distribute user’s data via contact nodes. In contrast, MANETs are connection-oriented communication using smartphones as relay nodes to create end-to-end path for continuous and reliable data transmission. Standard transport-level protocols (i.e., TCP and UDP) are compatible with MANETs without requiring any modification. Therefore, MANETs have the capability to support Internet applications relying on TCP/IP and can also be applied for temporary communication in a disaster situation or extension of the Internet (for some specific purposes, e.g., creating an alternative path for data offloading in a crowded area). This paper will focus on improving performance of MANETs to support the increasing number of users.
Since nodes have limited bandwidth and rely on battery power, a node should send only necessary packets to save these important resources. However, the movement of nodes frequently breaks the communication path and causes a loss of data packets. This also triggers the exchange of routing packets in order to find a new path in MANETs. Ad Hoc On-demand Distance Vector (AODV) [11] is a well-known on-demand routing. First, a source floods a Route Request (RREQ) packet. Then, the destination sends a Route Reply (RREP) packet back along the reverse path to the source. Then, the source can start sending data packets. Even though global flooding is the simplest way to discover a route to a destination, it causes excessive broadcast storm overhead [12], which directly affects the performance of OppNets.
To prevent network-wide flooding, TTL (Time-To-Live) is used to limit flooding scope. The TTL value is decremented by one when a packet is forwarded and will be dropped when the value reaches zero. An initial TTL value will be determined according to specific conditions. The smaller the initial TTL value, the smaller the flooding scope. In DTNs with Epidemic Routing [13], a small initial TTL is calculated to limit flooding scope of data packets. However, its optimal value cannot easily be determined. If it is too small, the data packets may not reach their destinations. In MANETs, it is used to restrict flooding area of RREQ packets causing overhead. Reducing flooding overhead has been widely discussed for decades. The Expanding Ring Search (ERS) technique [14] is deployed in AODV. An initial TTL of RREQ packet is set to a small value at the first route discovery. If fails, it will be conditionally increased for next attempt. The variances of ERS are also proposed in [15, 16] to reduce unnecessary rebroadcast.
Query Localization (QL) technique [17] is based on the hypothesis that most routing protocols construct the shortest path (in hops) if possible. All relay nodes of the constructed path are in the direction of the destination. Therefore, in Query Localization, the routing packets are flooded on the basis of the most recently broken path. Based on this idea, Query Localization does not require a complex calculation. In spite of these advances, there are still opportunities for further enhancements to achieve better performance.
In this paper, we propose Low Overhead Localized Flooding (LOLF) protocol, an extension to enhance the route discovery and the route repair mechanisms of the Query Localization technique. Our method controls the dissemination of the RREQ packet while incurring only insignificant control information overhead. This results in lowered overall routing overhead and less network congestion. Extensive simulations demonstrate that overall performance metrics are improved in our protocol. We choose to implement our method based on AODV due to its simplicity and its wide use by many researchers.
The rest of this paper is organized as follows. Section 2 describes related works. Our proposed model is described in detail in Section 3. Performance evaluation and simulation results are discussed in Section 4. Section 5 summarizes the conclusions of our work.
2. Related Works
Since flooding is the foundation of routing protocols in OppNets, many previous research papers attempt to improve its efficiency. In MANETs, Blocking-Expanding Ring Search (B-ERS) [15], is proposed as an extension to the Expanding Ring Search (ERS). A special stop packet is used to eliminate the propagation of RREQ packets. When a source receives a RREP packet, it broadcasts a stop packet. This packet contains the RREQ originator address and a corresponding RREQ ID. The TTL value in the IP header is set to the hop count to the destination. Whenever a relay node receives a RREQ packet, it waits for a certain back-off delay before rebroadcasting the packet. During the back-off period, if the node receives a stop packet which contains a matched RREQ originator address and RREQ ID, it drops the RREQ packet. Otherwise, if the timer expires and no corresponding stop packet arrives, the node rebroadcasts the RREQ packet. Energy Efficient Expanding Ring Search [16] reduces unnecessary RREQ packets in ERS by preventing nodes which have no successor in the first round of route discovery to participate in the next round. In the first round, each node attaches the address of its predecessor node to every forwarded RREQ. If a node receives a RREQ packet which has its address piggybacked, this means that there are some nodes which have become its successor node. This node will participate in the next ERS route discovery while the others will not. Some quota-based DTNs routing such as Spray & Wait [18, 19] and Spray & Focus [20] also limit the number of times which data packet can be replicated.
Much research focuses on improving the AODV local repair mechanism [21–24]. In original AODV, when a relay node detects a link breakage, it performs a route repair. If the hop count to the destination is not farther than max_repair_ttl, the relay node initiates a local repair mechanism. The data packets are buffered and the node, rather than the source, broadcasts a RREQ packet with a higher destination number to find a new route. Otherwise, the node sends a Route Error (RERR) packet back to its upstream nodes. When the source receives the RERR packet, it broadcasts a new RREQ packet.
In Multihop (MH) repair [21], the multihop neighbor information is used to find a bridge node to replace an unreachable next hop. Each node maintains a list of neighbors up to n hops. When there is a link breakage, the upstream node of the broken link sends a query to find neighbors (up to n hops) which can connect to the downstream node of the broken link. A scheme in [22] modifies the RREQ packet to include both the unreachable next hop address and the destination address as targets to increase the opportunity to find a route to the destination. In Local Route Repair (LRR) [23], the propagation of RREQ packets in local repair is confined to the vicinity of the broken link. The target of the RREQ packet is the next 2-hop node of the broken link while TTL of the packet is set to 2 or 3 in order to reduce the scope of local repairs. Therefore, all relay nodes on the active route have to maintain the address of the next 2 nodes by appending the address of its previous hop to the forwarded RREQ and RREP packets in order to inform its next hop. In [24], the number of RREQ packets can be reduced by applying the Multipoint Relay (MPR) algorithm to avoid redundant broadcasts.
Location-based routing models [25–28] limit the number of flooding nodes by using location information. A special device such as Global Positioning System (GPS) receiver is required in every node to determine location information and velocity. In IBR-AODV [29], an overhearing technique is used to passively learn a route without creating additional overhead. However, this requires the promiscuous mode to be enabled in all nodes.
Salvaging Route Reply (SRR) [30] focuses on decreasing frequency of route discovery in AODV. Every undeliverable RREP packet is salvaged through a new path to a source which possibly avoids unnecessary route discovery. In contrast, Bilateral Route Discovery (BRD) [31] aims to limit a flooding area of route discovery. It divides one large flooding area into two smaller flooding areas to reduce the flooding scope of RREQ packets. When a link breaks, the upstream node of the broken link sends a RERR packet back to the source. In addition, it also sends a small-scope gratuitous RERR packet to notify the destination. After the source or the destination receives the RERR packet, it broadcasts a RREQ packet with TTL set to half of the hop count of a previously known route. If a node receives the RREQ packet from the destination and the source, it can generate and send a RREP packet back to the source.
In DSR over AODV (DOA) [32], some selected intermediate nodes, called waypoint nodes, divide a route between a source and a destination into segments. DOA uses Dynamic Source Routing (DSR) [33] for intersegment routing and uses AODV for intrasegment routing. When the route breaks, the upstream node of the broken hop performs a small scope local repair to the waypoint node of the next segment (or the next two segments) instead of to the destination.
In Workload-based Adaptive Load-balancing (WAL) [34] and Detour [35], the protocols use queue utilization to discard a newly incoming RREQ packet. In [35], the predecessor of the congested node will attempt to find a new path which is able to bypass the congested node. In EXPANSION [36], the signal strength is used to determine the unstable link between each relay node. Then, the protocol attempts to bypass the unstable link or find a bridge node to insert between the unstable links. This is contrary to [21–23] which find bridge nodes only if the link is broken.
Node Caching (NC) [37] allows only nodes which have recently forwarded any data packets to rebroadcast a RREQ packet. It assumes that these nodes are located in a better location than other dead-end nodes. Encounter-Based Routing (EBR) [38] uses the history of rates of node encounters to determine an appropriate amount of message copies the node should forward. A number of data packets are distributed by a node which has a high potential to meet other many nodes. In Extended AODV [39], the RREQ is forwarded by unicasting to the next hop if there is an invalid routing entry to a destination in a routing table. It works based on assumption that a node moves infrequently so that a recently broken route may become available again later.
Dynamic Route Change Algorithm (DRCA) [40] utilizes a Hello packet to perform path shortening. The recently used route entry (destination address, hop count, and sequence number) is attached to the Hello packet. When a relay node receives the Hello packet, if the attached destination sequence number is higher and the attached hop count is smaller than that of its routing table, the node changes its next hop to the Hello packet originator and updates the corresponding route entry with the new hop count and sequence number. DRCA can reduce path length, which reduces the number of forwarding packets and can be applied to repair a broken link.
Query Localization (QL) [17] performs directional flooding by utilizing recently broken route information to limit the area where RREQ packets are rebroadcast (denoted by “request zone”). First, normal route discovery is performed. Then, an intermediate node recognizes whether it acts as a relay for any connection from the RREP packet. When the route is broken, the next route discovery’s RREQ packets will each contain a counter, which is initially set to zero. When a node rebroadcasts the packet, the counter is incremented if the node is not a relay of the broken path. This is done by checking the source IP address in the IP header and the destination IP address in the AODV header of the received RREQ packet. Otherwise, the counter remains untouched (Path locality) or is reset to zero (Node locality). If the counter exceeds the k threshold, the packet is dropped. QL can discover a new path with minimum overhead compared to global flooding. However, in local repair, the upstream node of the broken link has to perform conventional flooding. This is because the downstream nodes of the broken link will not recognize themselves as part of the recent route since the source address of the RREQ packet is the address of the upstream node of the broken link, not the originator of the connection. In addition, many parts of the new route would overlap with the old route if the k threshold were set too low. Our previous work [41] allows relay nodes of a previously broken path to rebroadcast a RREQ packet without checking the source address of the RREQ packet so that QL could be applied to a local repair mechanism of AODV. The number of hops of the recently broken path is used to steer RREQ packets toward a destination, preventing RREQ packets from being rebroadcasted back to a source. This results in lower routing overhead from a reduced number of RREQ packets.
In Query Localization Optimization (QL-O) [42], only the 1-hop neighbors of the recently broken route rebroadcast the RREQ packet. Figure 1 demonstrates the active route from source S to destination D (black node). Arrows illustrate nodes which have a route to destination D while dotted lines represent links between two nodes which are in the transmission range of each other. Each node in the active route (black nodes) broadcasts the routing information of destination D to its 1-hop neighbors (white nodes) periodically. As a result, the neighbors have a route to destination D. The next hop address is set to the node which originates the routing information. When source S starts route discovery, only the 1-hop neighbors which have recently had a route to the destination (white node: U, V, W, X, Y, and Z) rebroadcast the RREQ packet. In addition, each 1-hop neighbor can use the hop count information to decide if it is located nearer to or farther from the destination than the originator of the RREQ packet. For example, when a link from node B to node D is broken, if node B performs local repair, the previously known hop count is also included in the new RREQ packet. Some of the 1-hop neighbors rebroadcast the packet only if their previously known hop count to the destination is less than or equal to that in the packet. For example, only nodes V, W, Y, and Z rebroadcast the RREQ packet. This prevents the RREQ packets from propagating backward to the source. QL-O also has the opportunity to find a bridge node when the route is broken since all 1-hop neighbors have a route to the destination the same as in AODV-BR [43]. These bridge nodes are useful only if they have a fresh route with a higher sequence number than that of the source. The main disadvantage of QL-O is the routing overhead problem since each node in the active route has to advertise the full routing information to its neighbors periodically.
QL and QL-O mechanisms have a high potential for further enhancements in our proposed work. They can be used as an extension for existing on-demand routing protocols (i.e., AODV [11] and DSR [33]) without requiring any complicated computation, promiscuous mode, and sensing devices for routing operation. Table 1 shows the summary of related works.
3. Proposed Model
3.1. Route Discovery
Traditional protocols such as AODV perform omnidirectional flooding in both source repair and local repair which is unsuitable for a low-bandwidth and limited-energy ad hoc network. On the contrary, the directional broadcast technique is now being focused by many researchers. The basic idea of directional flooding is to limit the propagation of a RREQ packet into a small area directed toward the destination. However, it is difficult to determine which node should be a forwarding node due to network decentralization and the node’s mobility. One of interesting solutions is to steer RREQ packets on the basis of a recently broken route. The relay nodes of the previous active route are assumed to be located in a direction to the destination. In this section, we present Low Overhead Localized Flooding (LOLF). Our objective is to limit the initial request zone of the RREQ packet in the route discovery. Our work also prevents the backward propagation of the RREQ packet incurred during the local repair mechanism while requiring small amount of additional control information. This reduces the overall size of routing overhead and results in better performance compared to previous directional flooding protocols, i.e., QL and QL-O.
Figure 2 shows the operations of LOLF when network topology changes. First, the link between nodes is detected from the link-layer acknowledgment and the hello packet mechanism. When route breakage is detected, the upstream node of the broken link chooses to repair the route locally or inform a source node. Then, the selected route establishment method is performed. Finally, the source node and new relay nodes will update their routing tables according to a RREP packet sent directly from the destination or from some nodes which has a fresher route to the destination. These operations are almost similar to AODV, except the route establishment mechanism including the route discovery at a source node and the local repair process at an intermediate node.
In LOLF, we introduce two additional states of route entry in the routing table, valid_active, and in_zone. Normally, in AODV, when the route entry is created or updated from the RREQ, RREP, or Hello packets, the state of the route entry is set to valid to indicate that the route entry is usable. The valid_active state in our protocol provides additional information that the route entry has recently been used or probably will be used for forwarding a data packet. This state allows the node to start maintaining the request zone for the corresponding destination. The in_zone state is used to indicate that a node has recently been located in the request zone of some other active route to the corresponding destination (without having a usable route to the destination). The usage of these states will be described in detail later. Figure 3 shows the overall operations when each packet arrives each node. The node decides which actions it should take for each received RREQ packets. The decision depends on information which is collected from previously received packets to determine if the node is located inside or outside the request zone. This method has a drawback in computational and space complexity. Each node has to process all incoming packet and record some information in the node’s memory. However, this method is worthwhile to eliminate unnecessary RREQ packets.
In the beginning, a source performs global flooding by broadcasting a RREQ packet to a destination in a similar way to AODV. From Figure 4, when a node (i.e., nodes S, A, and B) receives a RREP packet, it creates or updates the route entry of the destination and sets the state of the route entry to valid_active (Figure 5). After the RREP packet arrives at the source, data packets can be sent. During this time, all relay nodes (including the source and the destination) start maintaining local connectivity by broadcasting Hello packets with TTL set to one. In order to maintain the request zone of the currently active route, each Hello packet is also aggregated with the list of only the destination addresses which have a valid_active state in the routing table (Figure 6). Other nodes which only have route entries created from a RREQ or Hello packet (valid state) are not being used for forwarding data packets. These nodes remain silent and do not originate any Hello packets (i.e., nodes W and Z).
On receipt of a Hello packet, a node extracts the list of destinations. For each destination address, if the node does not have a usable route entry of the corresponding destination (either in the valid or valid_active state), this means that the node is located within the request zone of some active route to the destination. The node then sets the state of the corresponding route entry to in_zone and sets the initial lifetime of the state. If the route entry is already in in_zone state, only the lifetime is extended. When the lifetime expires, the state of the route entry is set to invalid to indicate that the node is no longer located within the request zone.
Figure 7 illustrates the route from source S to destination D where the link from node A to node B is broken. When the route breaks, the upstream node of the broken link chooses to perform local repair or inform the source node which depends on user configuration. The AODV specification [11] defines that the intermediate node can perform local repair only if it is located no farther than max_repair_ttl hops away from the destination which is a static variable. However, this may not suitable in MANETs. We have followed the following strategy: the intermediate node performs local repair only if it is located nearer to the destination node than to the source node. This can be determined from the routing table of the intermediate node and from the number of forwarded hops in the header of the data packet.
We will first describe the process of informing the source node and reinitiate route discovery. First, the upstream node of the broken link (node A) increases the sequence number of the destination and changes the state of the corresponding route entry to in_zone (Figure 8). Then, it broadcasts a RERR packet to notify its predecessor node. All relay nodes also do the same processes when they receive a RERR packet from their next hop. After the source (node S) has been informed about the route breakage, it performs a route discovery within the request zone. The RREQ packet originating from the source is expected to be propagated within 1 hop from the recently broken route.
Upon receiving the RREQ packet, a node processes the packet in a similar way as AODV. It decreases the TTL value by one and records the source address and the ID of the packet to prevent further duplicated RREQ packets. The node then responds with a RREP packet if it is the destination or has usable route information to the destination (with higher or equal destination sequence number). Otherwise, it prepares to rebroadcast the RREQ packet. In the first step, the packet is discarded if the new TTL value is equal to zero. Otherwise, the node determines whether it is located within or outside the request zone using the state of the route entry in its routing table. This information is collected from any received routing packets as described earlier.
The node checks its routing table to check if it still has a usable route to the destination of the RREQ packet (valid or valid_active state) with a lower sequence number than that of the RREQ packet. This means that the node is probably the relay node of the old path and is located beyond the broken link in the request zone. In this case, the RREQ packet is rebroadcast. Moreover, if the destination is the neighboring node, the TTL value of the RREQ packet is set to one before rebroadcasting the packet since the destination is located within 1-hop distance. If the state of the route to the destination is in_zone, then the node also rebroadcasts the RREQ packet since it was recently located in the request zone. This state indicates that the node is the upstream node of the broken link or is in the local neighborhood of the recently broken path.
The process of request zone determination can be summarized as illustrated in Figure 9. This attempts to limit the propagation of the RREQ packet in the request zone as previously demonstrated in Figure 7. If none of the conditions is satisfied, it means that the node is not located within the request zone. In this case, it simply drops the RREQ packet. When the RREQ packet arrives at the destination, an RREP packet is sent back to the source. In addition, we simply employ Node Locality of Query Localization to expand the search area. Each RREQ packet contains a counter and a threshold, k. The counter is reset to zero if the RREQ packet is rebroadcast by a node in the request zone. Otherwise, the counter is incremented by one and the RREQ packet is dropped if the counter exceeds the threshold (k). In the first route discovery, the threshold is initially set to zero so that no RREQ packet leaves the request zone. However, if no usable RREP packet arrives at the source in a specific time, the search area is expanded. The threshold value k of the RREQ packet is increased. The source expands the search area several times before giving up and performing a network-wide flooding of RREQ packets.
3.2. Route Repair
When the relay node attempts to perform local repair, the number of forwarding nodes should be kept minimum as much as possible. Figure 10 illustrates the request zone in this situation. Assuming that route beyond node B is disconnected, the RREQ packets originating from node B should only be propagated in the local neighborhood of all downstream nodes of the broken link. The nodes located around the upstream nodes of the broken link should be pruned from the request zone. However, this is difficult for LOLF to determine since each 1-hop neighbor does not maintain the hop count to the destination. Therefore, we propose an extension to LOLF to deal with this situation.
First, node B increases the sequence number of the destination and broadcasts an RREQ packet with a special local repair flag (denoted by RREQLR). When its one-hop surrounding nodes (i.e., nodes A, V, W, Y, and Z) receive the packet, they do not rebroadcast the packet immediately. Instead, each of them checks whether or not it is a predecessor node of the originator of the RREQLR packet. This can be easily done by checking if the destination sequence number of the RREQLR packet is higher than that of its route entry and the RREQLR originator is the next hop of the route entry. If the node is not a predecessor node (i.e., one of nodes V, W, Y, and Z), it delays a rebroadcast process and starts a rebroadcast timer. On the contrary, if the node is a predecessor node (i.e. node A), it drops the RREQLR packet and then immediately originates a Backward Zone Advertisement (BZA) packet.
The BZA packet contains the address of the RREQLR originator, the address of the destination, and the ID of the dropped RREQLR packet. The purpose of the BZA packet is to have all nodes in the local neighborhood of the route to the source discard all RREQLR packets originating from the upstream node of the broken link (node B). Figure 11 shows the summary process when a node receives a BZA packet. When a node receives the BZA packet, it records the address and the ID of the RREQLR originator from the BZA packet. If the node is a predecessor node of the route, it rebroadcasts the packet. Otherwise, the BZA packet is dropped. The BZA packet is broadcast in the same manner as an RERR packet (only by all predecessor nodes of node B, i.e., nodes A and S), except that the source node also rebroadcasts the BZA packet. This is necessary for pruning unnecessary nodes from the request zone and prevents the RREQLR packet from being rebroadcast backward to the source.
When the rebroadcast timer at each of the predecessor nodes expires (which will occur after the BZA packet is originated), if the node receives a corresponding BZA packet (i.e., nodes V and Y), it drops the delayed RREQLR packet since it is located in the direction of the source. Otherwise, the node removes the special flag from the delayed RREQLR packet and rebroadcasts the RREQ packet normally. Other nodes process the received RREQ packet by checking the conditions of the request zone as previously described in Section 3.1. Figure 12 summarizes the RREQLR processing at intermediate nodes. The rebroadcast timer should be set as short as possible but long enough for the broadcast of BZA packets at the first predecessor node (node A) before the timer expires. The delayed rebroadcast of RREQLR packets does not incur much route establishment delay, since it is performed only at the first hop of the local repair.
Consider a simple scenario where each node has transmission radius r in an area A. Each node of the active route is located within r hops from each other as shown in Figure 13. The route from source S to destination D is L hops. The route is usable until node D slowly moves out of the transmission range of node B. In AODV, the RREQ packets are flooded in an omnidirectional way from the originator of the packet. On the other hand, the optimized schemes (QL, QL-O, and LOLF) attempt to steer the RREQ packet in a direction to the destination using the relay nodes of the previously broken route. This clearly shows that these optimized schemes reduce the number of RREQ packets. In theory, as illustrated in Figure 13, the request zone is limited to the transmission radius of all nodes in the active route (including the source and the destination). The number of RREQ packets incurred in QL, QL-O, and LOLF during the route discovery is not considered significantly different in general as these protocols have a similar size to the request zone. However, there are some other factors (e.g., broadcast jitter, frame collision, and the node’s movement) which may affect the rebroadcast of the RREQ packets in the experiment.
In addition, an RREQ packet is also generated when the relay node performs local repair. Assume that node B, which is located l hops away from the destination, begins local repair. The intermediate node performs a normal flooding of RREQ packet during local repair in QL. This results in a large number of the RREQ packets generated in the same level as AODV. In QL-O, the number of broadcast nodes includes all 1-hop neighboring nodes located in the transmission radius of the downstream node of the broken link (gray area). In the same way, in LOLF, the request zone includes all nodes located in the transmission radius of the upstream node of the broken link and all relay nodes along the previously broken route to the destination (gray area and black dotted area), excluding the area which is covered by the BZA packet (nodes V and Y).
Our proposed method will reduce the number of RREQ packets incurred from route discovery and route repair to the same level as QL-O. The number of RREP and RERR packets is not significantly different in each protocol as these packets are sent by unicast (RREP packet) or directional broadcast (RERR packet) method while most routing overhead is overwhelmed by the flooding of RREQ packets. A BZA packet is also forwarded only by upstream nodes of the broken link in each local repair operation. Since the BZA packet is forwarded in the same way as the RERR packet, routing overhead from the BZA packet is increased insignificantly while many unnecessary RREQ packets are pruned from a local repair operation.
For overhead of the Hello packet, the original size of the Hello packet defined in the AODV specification is 160 bits (excluding the IP header). Since QL-O periodically distributes the full routing information of its every active route to the destination (including the destination address, the destination sequence number, the number of hops to the destination, and the lifetime of the information), the size of Hello packet is increased by 104 bits per destination entry. In LOLF, the Hello packet contains only the list of the destination address. There is only 32 bits additional size per destination entry added to the Hello packet. When comparing the overall size of routing overhead, LOLF incurs a lower size of routing overhead than QL-O.
4. Performance Evaluation
We perform a simulation by using Network Simulator 2 (NS-2). The simulation area is set to 1000 × 1000 m2. Each node has an omnidirectional antenna which provides 250 meters transmission range and bidirectional communication. The IEEE 802.11 Distributed Coordination Function (DCF) is used as the MAC layer with 2 Mbps radio bandwidth. The mobility model is Random Waypoint and the node’s speed is uniformly selected from (1, 5) m/s. The pause time is set to zero so that a node moves continuously during the simulation. The simulation time is set to 600 seconds. The warm-up is performed for 300 seconds, and then sources start to send data packets for 300 seconds. The results were averaged from 20 trials with different mobility scenarios. Table 2 shows the summary of simulation parameters.
The following metrics are used to compare the routing performance:(1)Normalized routing overhead: the ratio of the total size of transmitted routing packets (i.e. RREQ, RREQLR, RREP, RERR, Hello, and BZA packet) to the total size of delivered data packets. We represent the routing overhead in terms of size instead of the number of packets since each routing packet of different protocols carries additional data which increases the size of the packet.(2)Energy consumption: the average amount of energy consumed per node per delivered data packet after the simulations are finished.(3)Packet delivery ratio: the ratio of the number of delivered data packets to the number of sent data packets.(4)End-to-end delay: the average amount of time to deliver data packets from source to destination.(5)Route establishment time: the average amount of time that nodes used to discover a valid route to destination.
We compared our proposed protocol LOLF with AODV [11] with Expanding Ring Search [14], Query Localization (QL) [17], and Query Localization Optimization (QL-O) [42]. We employ Node Locality and set the parameter the same as in the original QL and QL-O. The value of the k threshold is set to one and is increased by one in the next round of route discovery if the first attempt fails. If three consecutive attempts fail, conventional flooding in AODV is performed instead. In LOLF, the lifetime of in_zone state is set to 4.5 seconds which is the default timeout for 1-hop neighbor detection in the AODV implementation of NS-2. The BZA waiting time of the delayed RREQLR packet is preliminarily set to 0.015 seconds. We choose this value because the AODV implementation of NS-2 assumes that the 1-hop round trip time (node_traversal_time) is 0.03 seconds. Therefore, we simply assume that the one-way delay of the 1-hop communication is equal to half of the 1-hop round trip time.
The power consumption of the radio state is set to the following value: transmit = 1.38 Watts and receive = 0.97 Watts. These values are taken from the energy consumption measurement of Lucent IEEE 802.11 WaveLAN 2 Mbps PC card in [44].
There are two objectives in this simulation evaluation. In the first evaluation, we varied the number of nodes to show the performance of each protocol in different network densities. The number of nodes is varied from 100, 150, 200 to 400 nodes, and there are 15 sources sending four 512 bytes Constant Bit Rate (CBR) packets per second. In the second evaluation, we varied the number of CBR connections to evaluate each protocol in different congestion levels. The number of connections is varied from 10, 12, 14 to 20 in the scenario that consists of 250 nodes in total. Each source also generates four 512 bytes CBR packets per second.
4.1. Performance with Varied Network Density
Figure 14(a) shows normalized routing overhead in varied network densities. Due to the omnidirectional flooding behavior, it is not surprising that AODV incurs high routing overhead in most network densities. All optimized schemes, QL, QL-O, and LOLF, generate less routing overhead than AODV. QL-O is expected to achieve lower routing overhead because of the limited broadcast area of the RREQ packets. However, QL-O suffers from the large size of the Hello packet since it needs to add the routing information of the destinations. Our optimization to the broadcasting of RREQ and Hello packets can significantly reduce routing overhead in LOLF. The number of RREQ packets is significantly eliminated while only a small amount of overhead from the list of destinations in the Hello packet is added. In a network with 400 nodes, LOLF reduces routing overhead up to 57.9% when compared to QL-O. This confirms that LOLF scales well and is suitable for a large network.
(a)
(b)
Figure 14(b) shows the average energy consumption per node per delivered data packet with a varied number of nodes. As the network size grows, the average energy consumption of all nodes increases. The energy consumption is the consequence of the radio transmission. As a result of routing overhead in Figure 14(a), the average energy consumption of AODV rapidly increases when adding nodes to the network. In LOLF, our protocol maintains lower average energy consumption than others which is the result of lower routing overhead. The amount of energy consumption of LOLF in the network with 400 nodes is 43.5% lower than QL-O.
Figure 15 shows the packet delivery ratio in an increasing number of nodes. The larger the network size is, the more the routing overhead overwhelms network bandwidth, which causes packet loss. In a network with 100 to 150 nodes, all protocols have a similar packet delivery ratio since there is still no impact from routing overhead in the small network size. However, the performance of AODV dramatically decreases in a dense network. The high routing overhead causes high data packet loss in AODV. On the contrary, since LOLF emphasizes overhead reduction (Figure 14(a)), LOLF yields better packet delivery ratio up to 33.1% higher than QL and 23.3% higher than QL-O in a network with 400 nodes.
Figure 16(a) shows the end-to-end delay in different network densities. The end-to-end delay increases when the network scales up since there is higher network congestion from the increasing number of flooding nodes. This means that there are many unnecessary routing packets being rebroadcast repeatedly which leads to more delay in each forwarding process. Since AODV generates enormous routing overhead as exhibited in Figure 14(a), the per-hop forwarding delay of data packets is increased which results in high end-to-end delay. Since QL, QL-O, and LOLF limit the search area of RREQ packets, these protocols achieve lower delay than AODV because the network congestion is alleviated by eliminating unnecessary rebroadcast. In LOLF, the number of RREQ packets is reduced with only a small increase in the size of the Hello packet. However, QL-O has a rapid increase in end-to-end delay when there are many nodes in the network due to overhead of the Hello packet.
(a)
(b)
Figure 16(b) exhibits the route establishment time with varied network sizes. In this metric, QL-O maintains the lowest route establishment time in all network densities. The explanation for this is that nodes in an active route in QL-O periodically distribute up-to-date routing information of the destinations to their 1-hop neighbors. When the route is broken and RREQ packets are generated, all of these neighbors can respond to the RREQ packets immediately. LOLF has a rather high delay in low-density networks. However, the route establishment time only increases slightly in high network density.
4.2. Performance with Varied Number of Connections
Figure 17(a) shows normalized routing overhead with a varied number of connections. The increase in the number of connections directly affects the performance of QL-O and LOLF since the Hello packet has to carry more routing information about the destinations. However, the overall size of transmitted RREQ packets decreases much more than the increase in the size of the Hello packets. In a network with 20 CBR connections, LOLF can further lower overall routing overhead up to 27.2% compared to QL-O. This confirms that LOLF can work well even in a highly congested network. Figure 17(b) shows the average energy consumption of all nodes. The experiment shows that AODV is a high-energy consuming protocol while QL-O and LOLF have similar average energy usage.
(a)
(b)
Figure 18 shows the packet delivery ratio with various number of connections. As the traffic load increases, more data packets are lost due to network congestion. Both QL-O and LOLF have a higher packet delivery ratio since they have similar low routing overhead as previously exhibited in Figure 17(a). This shows that both protocols perform well even in a large network with a high traffic load.
Figure 19(a) shows the end-to-end delay with an increasing number of connections. The end-to-end delay becomes significantly higher as a result of the increase in the number of connections. As QL-O and LOLF generate lower routing overhead than AODV and QL, both protocols maintain low end-to-end delay.
(a)
(b)
Figure 19(b) exhibits route establishment time with different numbers of connections. This follows the same trend as shown in Figure 16(b). AODV requires a lot of time to discover a route to a destination due to congestion from the unnecessary rebroadcast of RREQ packets. LOLF has route establishment time similar to QL, which confirms that limiting the broadcast area to the 1-hop neighbors of the active route does not incur additional delay in route establishment. QL-O still has the lowest route establishment time in this aspect since the 1-hop neighbors of the active route always maintain the route to the destinations.
5. Conclusions
In an era of rapid increase in the number of smartphone users, MANET is an interesting opportunistic networking technology which can be applied for facilitating an extension for the Internet as well as backup communication system. In MANETs, routing overhead is a critical problem for practical implementation in real-world environment. Network disruption caused by node mobility invokes route repair operation and then floods a large number of control packets. This paper proposes LOLF, a low overhead localized flooding protocol based on Query Localization (QL) and Query Localization Optimization (QL-O) to reduce routing overhead of AODV routing protocol. LOLF only adds a small amount of information to the Hello packet of AODV to prepare a local flooding area for each active route. We also present a technique to prevent reverse broadcast when performing local repair without having to maintain the hop count information for all nodes in the local flooding area. Simulation results show that our approach can reduce routing overhead significantly compared to other previous schemes and scales well in a large network. As a result of lowered routing overhead, our protocol also reduces energy consumption and end-to-end delay while maintaining a high packet delivery ratio. LOLF achieves the outperformance at the expense of a longer route establishment time since it minimizes message exchange and does not employ the route-caching mechanism via Hello packet. Consequently, its route establishment time is observed to be longer than that of QL-O but not significantly different from those of QL and AODV.
Data Availability
There is no any data used to support this study.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This research project is financially supported by King Mongkut’s Institute of Technology Ladkrabang (KMITL). In addition, we thank Prof. Kamesh Namuduri from University of North Texas for comments which greatly improved the manuscript.