A Dominating-Set-Based Broadcast Gossip Protocol in Mobile Ad Hoc Networks

Transcription

1 A Dominating-Set-Based Broadcast Gossip Protocol in Mobile Ad Hoc Networks Chun Meng, Meina Song, and Junde Song School of Electronic Engineering Beijing University of Posts and Telecommunications Beijing, China Junmin Jia School of Electronic and Information Engineering North China Electric Power University Baoding, China Abstract Traditional gossip-based protocols rely on underlying routing protocols to disseminate messages. In mobile ad hoc networks, frequent topology changes may incur many route errors, which increase the overhead of maintaining routing information. They also need to maintain a partial or global view of the network, which further increases the overhead. This paper presents a broadcast gossip protocol based on dominating set. Neither does it require maintaining any routing information, nor does it need any partial or global view of the network. In this paper, a dominating set is dynamically constructed through an on-demand three-way join session and is kept connected through connect session. A reduce session is also proposed to reduce the size of a dominating set and the calculation only involves the nodes in the dominating set. Simulation results prove that the proposed protocol can achieve high scalability in terms of reliability and transmission delay. Keywords-mobile ad hoc network; gossip; dominating set I. INTRODUCTION Compared with wired networks, mobile ad hoc networks (MANETs) are more error-prone and the topology might undergo frequent changes due to mobility and switch-offs of mobile hosts. These features pose great challenges for designing efficient and reliable multicast protocol for MANETs. Recently, one class of multicast protocols, called gossip-based protocols, have been proposed and gained popularity among researchers. Gossip was first proposed for dissemination of updates to distributed database [1]. The main idea of this family of protocols is to have each node select a random set of nodes as targets and send messages to them. Due to the randomness of targets, gossip is highly resilient to node failures, link disconnections and topology changes. According to the underlying routing protocol, gossip-based protocols can be classified into two categories. One category relies on underlying routing protocol to transmit messages. Examples of this category include AG [2] and RDG [3]. In MANETs, frequent topology changes may incur many route errors, which will greatly increase the cost of maintaining routing information. This problem will become worse when the size of network increases. Another drawback of this category of gossip is that it requires each node maintain a global or partial view of the network, which further increases the overhead. Another category exploits the broadcast nature of wireless medium. Instead of sending packets to a random set of nodes one by one, a node locally broadcasts one packet and every node in the transmission range will receive it. They don t rely on any underlying routing protocol and thus don t need to maintain any routing information. In addition, they don t require any view of the network. These features make them scale well even in large and highly dynamic network. In this paper, we propose a broadcast gossip protocol based on the dominating-set of a multicast group. A subset of the network is a dominating set of a multicast group if every node of the group is in the subset or is adjacent to at least one node of the subset. Each node in the dominating set is called gateway. In figure 1, B, D and E are group members, and A, B, C form a dominating set of the group. When D wants to send a message m to other group members, it locally broadcasts m. Since A is within the transmission range of D, it receives m and rebroadcasts m to B. This process keeps going on until every node in the dominating set has broadcasted m. In the protocol, by confining data dissemination within the dominating set of the group, a message can be quickly propagated throughout the group. Moreover, this method can significantly reduce network congestion when the size of the network increases because only a small fraction of nodes participate in data dissemination. Figure 1. A dominating set of five nodes. The dotted circle reprents wireless transmission range Dominating-set-based routing in ad hoc wireless network was first proposed by [4]. Similar approaches include backbone-based routing [5] and spine-based routing [6]. However, to our best knowledge, application of this method in multicast has remained undiscovered /08/$ IEEE 1

2 Three important issues must be addressed when applying this approach to multicast protocol. First, since a node might join the group anytime and anywhere, the dominating set must be constructed dynamically to cover the new group member. This paper presents an on-demand method to dynamically construct the dominating set. Second, the dominating set must maintain connected throughout the lifetime of the multicast group to ensure the reliability of data transmission. However, in a highly dynamic network, the mobility and switch-offs of gateways might disconnect the dominating set. In this paper, we solve this problem through connect session, which connects the dominating set immediately after the breakdown of the dominating set. Third, the efficiency of this approach largely depends on the size of dominating set. Unfortunately, finding a minimum dominating set has been proven to be NP-complete. [5], [7] proposed methods to construct close-to-optimal dominating set. However, in these approaches, the calculation of dominating set involves all nodes of the network. In our protocol, only gateways are involved. In addition, it doesn t require maintaining any information about routing and group membership. The rest of this paper is organized as follows: Section II describes the network model and design goals. Section III presents in detail the protocol. The simulation and evaluation of the protocol is given in Section IV. Finally, Section V concludes this paper. II. NETWORK MODEL AND DESIGN GOALS Before presenting the protocol, we briefly describe the network model and design goals. A. Network Model In the network considered, each node has the same transmission radius r, communicating through bi-directional wireless links with each other. The network can be described as a graph G = (V, E), where V represents a set of wireless nodes and E represents a set of edges. An edge {u, v} indicates that both u and v are within their transmission range. N(v) = { u { u, v} E} represents the open neighbor set of node v and N[ v] = N ( v) { v} represents the closed neighbor set of node v. For a subset S V, N ( S) = v S N ( v) is the neighbor set of S and N[ S] = v S N[ v] is the closed neighbor set of S. S g V represents the set of nodes in a group g. A sub-graph G = ( D, E ) is a dominating set of group g if u S g, u N[D]. G is connected if every node pair in D can be connected with a path in E. Following assumptions are also made to simplify the protocol: (1) Nodes in the network will cooperate with each other; (2) Network partition rarely happens during the lifetime of group g since the networks studied in this paper tend to be dense networks; (3) Only a small fraction of nodes will shut down their wireless interfaces during the lifetime of group g. B. Design Goals The proposed protocol will achieve following goals: (1) when a node v joins the group, a dominating set covering v should be quickly constructed; (2) The dominating set of a group g should remain connected during most of the lifetime of group g even when the nodes in the network move considerably fast; (3) The size of the dominating set of group g should be kept small even when the size of group g increases. III. PROTOCOL PRESENTATION This section presents in detail the protocol, which consists of four sessions. Join session defines the operations to dynamically construct a dominating set when a node joins the group. Connect session defines the actions to reconnect the dominating set when a gateway senses the disconnection of the dominating set. Each gateway also performs reduce session to reduce the size of the dominating set each time it senses the changes of neighbors. Dissemination session defines the operations to disseminate a message throughout a group. For the protocol to work, the initiator of a group serves as the first gateway of the dominating set at the beginning of the lifetime of the group. A. Join Session The join session is a three-way handshaking process, which consists of three phases. The first two phases are just like a route discovery process, the purpose of which is to find paths to existing gateways. During the third phase, after a new group member finds a path to a gateway, it sends a confirm message to mark all the nodes along the path as gateways and consequently a dominating set covering the new group member is constructed. The pseudo-codes for join session are shown in figure 2. 1) Request Dissemination Phase When a node wants to join a group, it first calls the procedure Join and sends the identifier of the group (gid) as the parameter. The Join procedure first checks whether the node is a gateway (denoted by dflag i ) or there exist at least one neighboring gateways, i.e., it is already covered by the dominating set, and quits immediately if one of the conditions is satisfied. Otherwise, it generates a request message and broadcasts the message to its neighbors. Note that N i represents the set of IDs of neighbor gateways of node i, the construction of which is presented in Connect Session. After receiving a join request, a node first checks whether it has already received the same request. If it has already received the request, it simply drops the request. Otherwise, it will send a reply to the requestor if it is a gateway or rebroadcast the request if not. Note that every request packet has a ttl (time to live) field that is decreased when the packet is forwarded to other nodes. A request is dropped when its ttl field reaches zero. Note that in the pseudo-codes, R i represents the set of join requests received by node i. One important issue is the so-called broadcast storm problem [8]. In a large network, serious congestion and redundancy could exist if every node participates in the flooding of a packet. Various approaches have been proposed to tackle this problem. In this paper, a simple probabilistic scheme [8] is adopted, in which every node rebroadcasts a packet with a probability p. Simulation results indicate that this simple approach is sufficient to efficiently propagate messages /08/$ IEEE 2

3 in a dense network. Before broadcasting a packet, a node waits for a random amount of time to avoid collisions. 2) Reply Forwarding Phase During this phase, the reply message is forwarded to the requestor along the reverse path the corresponding request is disseminated. Note that the reply message will be dropped during the forwarding process if it has been confirmed before (denoted by replied i ). Finally, the reply message reaches the requestor which responded with a confirm message. Note that the requestor only confirms the first reply it receives and drops subsequent replies. The idea behind this approach is explained below. distance-2 neighborhood, i.e., the neighbors neighborhood, the dominating set is still connected. Otherwise, the dominating set may be disconnected and the leaving gateway s ID is added into a node set S i and a find request for S i is generated and broadcasted to the neighborhood. At the same time, a timer findtimer i is started to monitor whether the find request has been successfully responded or not. Figure 2. Join session at node i 3) Dominating Set Construction Phase During this phase, the confirm message is forwarded along the reverse path the corresponding reply message is forwarded until the confirm message reaches the replier. Each node along the path declares itself as a gateway. After the confirm message arrives at the replier, a connected dominating set covering the requestor is constructed. Because the path of the first reply generally is the shortest path in most cases, only a small number of nodes will be added to the dominating set, causing the resultant dominating set to be small. B. Connect Session The pseudo-codes for connect session are presented in figure 3. In order to maintain the connectivity of a dominating set, each gateway in the dominating set periodically generates a heartbeat message and piggybacks it with the IDs of its neighboring gateways. Then it broadcasts the heartbeat to its neighbors. Upon the reception of the heartbeat, every node will record the transmitter s ID and the piggybacked gateway set. Each node periodically checks the arrival time of the heartbeats (represented by node.lasttime) it recently received. If it hasn t received any heartbeat from a gateway for more than τ seconds, the gateway is removed from its neighbor gateway l set. However, if the leaving gateway can be found in the Figure 3. Connect session at node i However, if the neighbor gateway set becomes empty and no connect session ha been started, the node might be isolated from other gateways. In this case, the isolated node will leave the dominating set if it has served as gateway for more than a threshold T i, also called serve time. Then it restarts a join session to reconnect itself to the dominating set if it is a group member. The serve time mechanism is important to this protocol, which will be discussed in detail in Reduce Session. When a node receives a find request for the first time, it will respond to the requestor with a find reply message if it is among the node list to be found (denoted by req.list) and rebroadcasts the request if there is any node still to be found. Note that each find request has a ttl field that is set to 4 hops initially. In the network considered, a node cannot be far away when it is found to be outside of the transmission range of its neighbors. A small ttl also restricts the finding process within a small region, causing little overhead over the network. While forwarding a find reply, each node along the path marks itself as a gateway. When the reply finally arrives at the /08/$ IEEE 3

4 requestor, it removes the replier s ID from S i and cancels the monitoring timer if S i becomes empty. Two problems exist when applying the connect session in the network considered. First, a find request (or reply) message might be lost due to network congestion. Second, the node to be found might be switched off during the connect session. These problems are solved through a find timer, which is started at the beginning of the connect session and expires after T f seconds. When the timer expires, the requestor first examines whether it is detached from other gateways and marks itself as non-gateway if there is no gateways within vicinity. Otherwise, it bundles all nodes in N(S i ), i.e., the neighbors of the gateways still to be found, into a request message and broadcasts the request. Since only a small fraction of nodes might be switched off during the lifetime of the group, it is reasonable to assume that most of the nodes in N(S i ) can be found and the newly started connect session will reconnect the dominating set. C. Reduce Session We adopt the methods proposed by [7] to reduce the size of a dominating set. Two rules are applied to reduce the size of a dominating set: (1) If N[ u] N[ v] and the id of u is smaller than v, u marks itself as a non-gateway; (2) If N( u) N( v) N( w) and the id of u is the smallest among u, v and w, u marks itself as a non-gateway. However, the approach proposed by [7] involves all nodes in the network and it relies on each node broadcasting heartbeats, which will overburden the network and incur serious congestion. In our protocol, only gateways need to broadcast heartbeats and the calculation of dominating set only involves gateways. Each gateway has a serve time, which is set to T s seconds initially. Each non-gateway group member periodically sends a preserve message to the first gateway in its neighbor gateway set. Upon the reception of a preserve message, a gateway updates its serve time according to the following formula: results show that this pure push approach can achieve a considerably high reliability even when the underlying topology undergoes frequent changes. IV. SIMULATION AND EVALUATION We use ns-2 to simulate an ad hoc network with 100 nodes in a 1000m 1000m area. The movement pattern was defined by Random Waypoint model. Each node moves at the same speed between 5 ~ 20m/s without pausing. Each node has a transmission radius of 250m. The underlying MAC layer can provide a 2Mbps transmission rate. The two-ray ground reflection model was adopted as the propagation model. The network included only one multicast group. At the beginning, one node declared the group and served as the first gateway. Then other nodes consecutively joined the group. Around 60 seconds, one node started to transmit packets to other group members every 200ms. Each packet had a length of 200 bytes. The simulation ended at 360 seconds. Each simulation was carried out 10 times with different scenario files created by ns-2. A. Reliability Figure 4 shows the reliability of the protocol. From figure 4, we can see that the protocol achieves considerably high reliability even though the nodes move very quickly. It can also be observed that the protocol s reliability decreases slightly when the speed increases. An interesting observation is that the protocol s reliability increases slightly when the node density increases. In fact, with more gateways participating in the dominating set when the group size increases, the chance that a group member is isolated from the dominating set might be decreased. The simulation results show that the protocol scale well in terms of reliability when the size of the network and mobility increase. Figure 4 also shows a comparison between our protocol and the well-known RDG protocol. The results show that our protocol achieves better performance. ST = max{ ST, now t0 + τ} (1) new old In the above formula, ST new and ST old represents the new and the old serve time respectively, and t 0 is the time when the node becomes a gateway. τ is an important protocol parameter. Formula (1) ensures that the gateway increases its serve time by no more than a short period of τ. Upon the reception of a heartbeat, a gateway marks itself as non-gateway if one of the two rules is satisfied and it has served for more than its serve time and no connect session is pending. A leaving gateway also broadcasts a leave message with ttl set to 2 hops. This leave message will inform all distance-2 nodes to update their gateway information. D. Dissemination Session When a node wants to transmit a message to other group members, it first locally broadcasts the message. After receiving the message, every gateway will rebroadcast it the first time it is received. Though other mechanism such as the request/resend scheme in TCP can be applied, the simulation Figure 4. Reliability of our protocol in a group of 30, 50, 70 and 80 nodes with the speed varing from 5m/s to 20 m/s. The RDG protocol is also presented with a group of 50 nodes. B. Transmission Delay Figure 5 shows the average transmission delay of the protocol. From the figure, we can see that the average transmission delay increases slightly when the speed increases. This phenomenon is due to the fact that more gateways might /08/$ IEEE 4

5 be added to the dominating set as a result of more disconnections caused by node mobility. We can also observe that the average transmission delay only increases slightly even when the group size increases. This observation indicates that our protocol can achieve high scalability in terms of transmission delay. Figure 7. Average disconnected time of a dominating set when the group consists of 30, 50, 70 and 80 nodes and the speed varies from 5m/s to 20m/s. Figure 5. Average transmission delay of our protocol in a group of 30, 50, 70 and 80 nodes with a speed between 5m/s and 20m/s. C. Dominating Set Figure 6 shows the average number of gateways in the dominating set during the simulation. From this figure, we can observe that the dominating set grows slightly when the mobility of nodes increases. As expected, the average number of gateways increases when the group grows. An interesting observation is that only a small transmission delay degradation is observed when the dominating set grows. This might be explained by the observation that the average shortest hop distance between the source and a group member is close to a constant in spite of the growing of the dominating set. Figure 6. Average number of gateways when the group consits of 30, 50, 70 and 80 nodes and the speed varies from 5m/s to 20m/s. Figure 7 shows the average disconnected time of the dominating set during the simulation. As expected, the disconnected time of the dominating set increases when the mobility of the network increases. However, though more disconnections might happen when the mobility of the network increases, the reliability of our protocol only degrades slightly. The simulation results justify the efficiency of the connect session. V. CONCLUSIONS In this paper, we have proposed a broadcast gossip protocol based on dominating set. We have described the problems when applying a dominating-set-based approach in a multicast protocol and solved these problems by introducing four sessions, i.e., join session, connection session, reduce session and dissemination session. Through simulations we have proved that our protocol scaled well in terms of reliability and transmission delay even when the size of the multicast group and the mobility of the network increase. REFERENCES [1] A.J. Demers et al., Epidemic Algorithms for Replicated Database Maintenance, Proceedings of the sixth annual ACM Symposium on Principles, New York, vol. 22, pp. 8-32, Jan [2] R. Chandra, V. Ramasubramanian, and K. P. Birman, Anonymous Gossip: Improving Multicast Reliability in Mobile Ad-Hoc Networks, 21st International Conference on Distributed Computing Systems. New York, pp , April [3] Jun Luo, P. T. Eugster and J. Hubaux, Route Driven Gossip: Probabilistic Reliable Multicast in Ad Hoc Networks, Twenty-Seond Annual Joint Conference of the IEEE Computer and Communications Societies, vol. 3, pp , March [4] P. Krishna, M. Chatterjee, N. H. Vaidya, and D. K. Pradhan, A clusterbased approach for routing in ad-hoc networks, Proceedings of the Second USENIX Symposium on Mobile and Location-Independent Computing, pp. 1-10, April [5] B. Das, E. Sivakumar, and V. Bhargavan, Routing in ad-hoc networks using a virtual back-bone, Proceedings of the 6th International Conference on Computer Communications and Networks, pp. 1-20, Sept [6] B. Das, R. Sivakumar, and V. Bhargavan, Routing in ad-hoc networks using a spine, IEEE International Conference on Computers and Communications Networks, pp , Sept [7] J. Wu and H. Li, A Dominating Set Based Routing Scheme in Ad Hoc Wireless Network, Proceedings of Third Int'l Workshop Discrete Algorithms and Methods for Mobile Computing and Comm, pp. 7-14, Aug [8] Yu-Chee Tseng, Sze-Yao Ni, Yuh-Shyan Chen, and Jang-Ping Sheu, The broadcast storm problem in a mobile ad hoc network, WINET Wireless Networks, vol. 8, no. 2 3, pp , March May /08/$ IEEE 5