A Low-Overhead DVR Based Multicast Routing Protocol for Clustered MANET

Transcription

1 A Low-Overhead DVR Based Multicast Routing Protocol for Clustered MANET B. Gupta, S. Rahimi, R. Jandhyala, and V. Doraiswamy Department of Computer Science, Southern Illinois University, Carbondale, IL , U.S.A. [bidyut, Abstract Recently an efficient clustering protocol has been reported [1] for mobile ad-hoc networks (MANET). The proposed clustered network has been shown to be more stable than the clustered networks as reported in [3] and [4]. In this paper, we have proposed a distance vector based multicast routing protocol for MANETs that are clustered following the idea of [1]. The proposed scheme needs much less amount of information exchange compared to the distance vector routing scheme designed for unclustered network. Because of significant reduction in distance vector routing table size and its adaptable nature to the changing ad-hoc network topology caused by node mobility this proposed multicasting routing protocol has been shown to offer efficient utilization of both limited memory and bandwidth for MANET. Besides, we have also shown how our clustered network can offer efficient resource utilization when CBT routing strategy is used. Keywords: Mobile Ad Hoc Network, Clustering, and Multicast Routing. 1. Introduction Recently some protocols have been reported [3], [4] for dynamically organizing mobile hosts in a mobile ad-hoc network (MANET) [2] into clusters. The main objective of these cluster protocols is to aid in routing. The work in [4] has considered clusters in which every node in a cluster is in the transmission range of every other node in the same cluster. Nanda et.al. [3] have proposed a clustering scheme in which the basic cluster unit is same as in [4]; This work [3] offers smaller number of control messages generated compared to [4] for communication. In [1] a clustering protocol completely different from the above two has been proposed in which the diameter of a cluster is at most 2N (N is a positive integer), a parameter that can be set by the network designer before the network is booted. This protocol [1] offers (a) higher cluster stability than [3], [4] from the viewpoint of the number of new clusters formed out of an existing cluster due to node mobility, and (b) lower number of control message exchanges needed than in [3] when a new node wants to join an existing cluster. In this paper we have considered this kind of clustered mobile ad-hoc networks [1] for its above mentioned advantages and have presented a distance vector based multicast protocol for MANET. This protocol offers much less information exchanges between any two neighboring nodes compared to the distance vector routing (DVR) scheme [5] designed for unclustered networks, thus ensuring efficient utilization of both limited memory of mobile hosts and limited wireless bandwidth. Besides, the presented routing protocol always chooses a better path, if any exists, to reach clusters. We have also discussed how our clustered network can offer efficient resource utilization when CBT routing strategy [6] is used. This paper is organized as follows. Section 2 introduces briefly the architecture of the clustered MANET (a detailed description of the network as well as the cluster formation rules are out of the scope of this paper and can be found in [1]). Section 3 contains the data structures 135

2 needed for multicast routing. In Section 4 we have presented the multicast routing protocol together with an illustration and finally Section 5 draws the conclusion. 2. Architecture A cluster is constructed, maintained, deformed, etc by the movement of the mobile hosts. The cluster restructuring is governed by the data structure, called Cluster Connection (CCT) Packet that is periodically exchanged among the mobile hosts. Structure of the CCT packet that is exchanged among the mobile hosts is stated below [1]. Node-id Cluster Id #hops from cluster head #neighbors Upstream node where, Node-Id is the mobile host s unique address. This can also be the hardware address. Cluster-Id is the Identification of the cluster to which the node (mobile host) belongs. Initially, this is set to Null, until the mobile node becomes a member of a cluster. #hops from the cluster head is the distance from the cluster head. Initially, this field is set to zero until the node becomes a member of a cluster. #neighbors is the count of nodes who are at a distance of 1 hop from this mobile host. This value keeps increasing/decreasing whenever a new node is added/ neighboring node moves away. This field is needed during cluster formation. A node in a cluster is termed as cluster head if it has the maximum number of immediate neighbors in the cluster and is responsible for cluster formation. Upstream node is the immediate neighboring node, through which the mobile host is connected to the cluster head. The cluster formation rules can be found in [1]. We assume the following in the present work: (a) an ad-hoc network is a small dynamically configurable network of mobile hosts, (b) every mobile host has the same transmission range, (c) there is no unidirectional link between two nodes. Two nodes can communicate with each other, if they are in the transmission range of each other. As mentioned earlier the entire network of mobile nodes is divided into clusters where a cluster is a group of ad-hoc hosts. The cluster head node in each cluster is chosen as Data Access Point (DAP). Each DAP keeps track of a table called Access Table which is populated to all other DAPs. The Access Table is modified, only when at least one member in that cluster becomes a member of a new multicast group or when it leaves an existing multicast group. Each DAP forwards whatever it has learned to its neighboring DAPs via Access table. The DAP is like an access point in a cluster, where a sender of multicast packet just queries it to know what other clusters have members which are interested in receiving this multicast packets. It holds records of those clusters whose nodes are members of one or more multicast groups. The Access Tables are interchanged among the different clusters in the network. Note that the information exchanged among the DAPs is only the modified part of the Access Table. Within a cluster, distance vector tables are maintained. Each node within a cluster knows how to reach the other nodes within its cluster. Each such table contains an additional field called multicast group, to determine the multicast groups a node is associated with. A node in a cluster is called a gateway, if it is in the transmission range of another node of a different cluster. Each node in the ad-hoc network is identified by two parameters: 1) Node-Id: this is a unique address for each node in the entire ad-hoc network, and 2) Cluster-Id: each cluster in the network is assigned a unique Address called Cluster- Id. When two nodes come in the transmission range of each other, they first exchange their CCT packets. If their cluster ids match, it means that these nodes are from the same cluster. These nodes then exchange their distance vector tables. If their cluster ids mismatch, these two nodes can now become the gateway nodes used for routing between their respective clusters. Each such DAP s first duty is to inform its respective DAP about the gateway node it has come in contact with. The DAP then selects this node to be the gateway node for multicast information exchange to the 136

3 neighboring cluster if either the hop distance of this gateway node from it is less than that of the existing gateway, or there is no existing gateway node to reach that neighboring cluster. If so, while routing, the DAP sends the multicast data to the new gateway node of the other cluster through the gateway node in its own cluster. 3. Necessary Data Structures The fields in Access Table, maintained by each DAP is shown below: Cluster-Id is the address associated with each cluster having one or more members belonging to a multicast group as specified in the Multicast Group field. Routing node is the node within the cluster from which the foreign cluster can be reached. Each DAP forwards whatever it has learned to its neighboring DAPs, in the form of Access Table. Note that only modified portion of the Access Table is sent to the neighboring clusters. Each DAP, on receiving this table, updates its own Access Table to have the new entries. It also records in its table, the node-id of the node within its cluster, from which the new information was received. The data that is transferred to the neighboring DAPs is only the table containing two fields, namely Cluster-Id and Multicast Group as shown below. This packet is referred as table update packet. Cluster-Ids Multicast Group Whenever a cluster establishes a link with a new cluster, it sends its entire Access Table to the new cluster s DAP. When a sender wants to send multicast data to its receivers a special packet called multicast packet is formed by the DAP, which consists of the fields as shown below: Multicast Clusters Multicast Group Multicast Data where Multicast Clusters are the different clusters in the network, having members belonging to the multicast group of the sender. Multicast Data contains the multicast information. 4. Multicast Routing Scheme It is known that Distance Vector Routing scheme [5] is one of the most efficient routing schemes for static networks. Attempt has been made to apply it to mobile ad-hoc networks that are not clustered. However, the large routing table size (which is 3n for a network of n nodes) that needs to be maintained by each node in this scheme makes it very memory inefficient. Besides, exchanges of such large tables between neighboring nodes results in very inefficient bandwidth utilization, in particular when n is large. The presented multicast protocol is distance vector based, yet it uses much smaller router table per node and so offers much less amount of information exchange between neighboring nodes since the network is clustered. Therefore, it ensures both better memory and bandwidth utilization. The working of the multicast routing scheme is summarized as follows. The scheme is divided into four protocols. These are: Join Protocol, Inter Cluster Link Setup Protocol, Access Table Interchange Protocol, and Multicast Routing Protocol. When a mobile node decides to join a multicast group it first sends a join request to its DAP. The DAP now registers its respective cluster with the group requested by the mobile host and updates its Access Table with this entry. This is how the Join Protocol works. Whenever two nodes come in the transmission range of each other, they first exchange their CCT packets from which they know whether they belong to different clusters or the same cluster. 137

4 If they belong to different clusters, they can possibly become the gateway routers. This decision is made by their respective DAPs. This protocol is called Inter Cluster Link Setup Protocol. Whenever there is a change in the access table entries, the updates have to be sent to the neighboring clusters. Thus DAP sends a table update packet reflecting the change in its Access Table to its neighboring clusters through the gateway nodes. The receiving cluster updates its access table with the new value and sends the updates to its neighboring cluster. This is how the Access Table Interchange Protocol works. Whenever a sender node wishes to send multicast data to a particular multicast group G, it first requests the DAP, to query for the clusters belonging to group G. The DAP queries and sends multicast packet to each of these clusters of group G through the outgoing gateway nodes which can aid in reaching these clusters. Once this packet reaches the neighboring clusters, the duty of each neighboring cluster is to see whether its cluster entry is present in the multicast packet. If present, it delivers the multicast data to its member nodes. It now reformats the multicast packet and sends this to the clusters present in the Multicast Clusters field of the received multicast packet through its gateway routers. This process is repeated until the clusters present in the Multicast Clusters field of the multicast packet become null. It assures that the multicast data has been delivered to the members of multicast group G. This is the working principle of the Multicast Routing Protocol. Below we have stated formally each of these four protocols of the multicast routing scheme. 4.1 Join Protocol Step 1. When a mobile host m ij becomes a member of a multicast group G k, it informs the DAP j about the multicast group G k. Step 2. Access Table update inside a cluster C j will not occur if a node m ij informs its DAP j about its being a member of a multicast group G k, of which an entry has already been recorded in the Access Table. Step 3. The DAP j stores this information in its access table as: a) The cluster-id field is set to the cluster-id of the requesting node as C j b) The multicast group field is set to the multicast group G k, of which the requesting node is now a member. c) The routing node field is left blank because the host m ij is a part of the same cluster. Proc Join ( m ij, G k, DAP j, C j ) Begin If ( m ij joins G k ) if( DAP j already has an entry G k for C j ) updatetable=false; else // update the access table; set cluster-id =C j ; set multicast group =G k ; set routing node =null; updatetable=true; End Proc. 138

5 4.2 Access Table Interchange Protocol Changes occur in the Access Tables only when a multicast group has been created or destroyed in a cluster. A multicast group is said to be created when at least one node requests for participation in one or more multicast groups. Multicast group is said to be destroyed in a cluster, when no more nodes inside that cluster belong to that multicast group. The following steps are executed in the Access Table Interchange Protocol. Step 1. Updated Access Table, following a join protocol is sent to the neighboring clusters. Step 2. The receiving cluster makes changes to its Access Table and propagates the table update packet to the neighboring clusters. Proc AccessTableInterchange (Cj ) Begin // Let C n (l<n<p) denote the neighboring clusters of current cluster C j // DAP j of cluster C j executes all the steps defined in this code. while (true) if( updatetable = = true ) // send an update packet to every neighboring cluster of C j. for (n = l to p) send TableUpdatePacket to each C n ; if(received an TableUpdatePacket from any C n (l<n<p)) if(changes Occur in AccessTable) Construct a new TableUpdate Packet; for (n = l to p) send TableUpdatePacket to each C n ; else drop the received TableUpdatePacket; End Proc 4.3 Inter Cluster Link Setup Protocol Step 1. If a node m ij Є C j receives a CCT packet from m jk Є C k, these two nodes can now become the gateway nodes between clusters C j and C k. Step 2. The DAP j of node m ij decides whether this node can be the potential node to reach the neighboring cluster C j. Step 3.If m ij becomes the new gateway node to reach cluster C j, the Access Table s routing node corresponding to C j is replaced by m ij. Step 4. DAP k of node m jk also performs the checks as in steps 2 & 3. Proc InterclusterLinkSetup ( Cj, C k ) Begin if(m ij Є C j receives a CCT packet from m jk Є C k ) if(dap j decides m ij as gateway node to C k ) 139

6 Change AccessTable j routing node for C k with m ij. if(dap k decides m jk as gateway node to C j ) Change AccessTable k routing node entry for C j with m kj. End Proc In the following protocol a sender to a multicast group may or may not be a member of that multicast group. 4.4 Multicast Routing Protocol Step 1. When a sender m sj in a cluster C j wishes to send a multicast packet to group G k, it first queries DAP j about the clusters, which contain members of the group G k. It gets a response about the different cluster-ids and the gateway nodes to be visited to reach these clusters. Step 2. If two or more cluster ids, which are interested in receiving multicast packets, are reachable from the same gateway node m gj of cluster C j, then a multicast packet will be sent to m gj Step 3.The gateway node m gj sends this multicast data to the corresponding clusters. Step 4: When this multicast packet reaches the gateway node, say m gm of cluster C m, the node m gm checks whether its cluster-id is present in the multicast clusters field. Step 5a: If C m is present in the multicast cluster field, then the multicast data in the packet is sent by m gm to the nodes Є C m, which are the members of the multicast group G k, by looking at the distance vector tables. Step 5b. Now m gm reconstructs the multicast packet by removing C m from the multicast clusters field. Step 6. The gateway node m gm, now sends the multicast packet to its DAP m. Step 7. DAP m checks its Access Table for the Routing Nodes needed to reach other clusters specified in the multicast clusters field. Step 8. The DAP m then routes the multicast packets to the gateway nodes m rm (l<r<t), where m rm denotes the gateway node Є C m used to reach cluster C r. Step 9. Every such receiving gateway Є C m, repeats steps 3 to 9 until the cluster-id field in the multicast packet it has received becomes null. This is the termination condition for the Multicast Protocol. Proc Multicast ( m sj, G k, C ) Begin // C denoted the set containing all the clusters in the network. If (m sj is the sender to group G k )) Enquire DAP j for C m (l m r) C / such that there exists any m nm (Є C m ) also belonging to multicast group G k ; // DAP j now does the following steps If( C m 0) for(each routing node m gj Є Cj for C n (l n r ) C m (l m r) ) DAP j constructs a multicast packet MP[C n (l m r ),G k, MulticastData] ; DAP j sends MP[C n ( l n r ), G k, MulticastData]) to routing node m gj ; m gj delivers the multicast packet to clusters C n (l n r ); 140

7 for(each receiving routing node m rp ) perform MulticastPacketDelivery ( m rp, C n, MP ); else C m (l m r) do not have any member Є G k ; End Proc Sub Proc MulticastPacketDelivery ( m rp, C n, MP ) Begin If ( C p Є C n ( l n r) ) m rp delivers MulticastData to all members Є G k in Cp using the distance vector table entries ; m rp sets MP[C n ( l n r ) - Cp, G k,, MulticastData] ; m rp sends MP to DAP p ; If ( C n ( l n r ) = NULL ) End Proc DAP p retrieves the Routing Nodes for clusters C n ( l n r ) appearing in the multicast clusters field ; for(each m gp Є Cp which is the routing node for C s (l s r ) C n (l n r) ) DAP p sends MP[C s ( l s r ), G k, MulticastData]) to routing node m gp ; m gp delivers the multicast packet to clusters C s (l<s<r ); for(each receiving routing node m rk ) perform MulticastPacketDelivery ( m rk, C s, MP ); End Proc Observe that the Clustering Protocol [1], Join Protocol, Access Table Interchange Protocol, and Inter Cluster Link Setup Protocol run concurrently with the Multicast Routing Protocol An Illustration Case 1: Multicast Packet Delivery, using the above mentioned protocols. Consider initially two clusters C 1 & C 2 as shown in Fig. 1. C 1 DAP 2 DAP1 C 2 m 11 m 21 m 12 Fig. 1 A network of two clusters In C 1, m 11 wishes to join multicast group, say G 1. Then following the Join Protocol, m 11 sends this information to DAP 1, which then updates its Access Table as follows 141

8 C 1 G 1 - DAP 1, then initiates the Access Table Interchange protocol and gives the information about the changes to its data structure to Cluster C 2, passing only two fields as shown in its table update packet below. Cluster-Ids Multicast Group C 1 G 1 m 12 in Cluster C 2 receives this packet and finds that it is a control message for DAP table update from C 1. Mobile node m 12, sends this information to DAP 2, which updates its Access Table as follows: C 1 G 1 m 12 Now, suppose a new cluster named C 3 has been formed in the already existing network of Fig.1 and has a gateway node m 13 which is in the transmission range of a gateway node, say m 22 in C 2 (Fig. 5). Now DAP 2 sends the access table data it learned to C 3. Say, m 32 in C 2 wishes to join multicast group G 1 and also m 42 in C 2 wishes to join multicast group G 2. Thus the DAP 2 will record the following information as shown in Fig. 2 below. C 1 ; C 2 G 1 m 12 ;- C 2 G 2 - Fig. 2 Information recorded by DAP 2 DAP 2 unicasts this information to the clusters C 1 and C 3. The Data Access Points of C 1 and C 3 respectively record the following information as shown in Fig. 3 and Fig. 4 below. C 1 ; C 2 G 1 -; m 21 C 2 G 2 m 21 Fig. 3 Information recorded by the data access point of C 1 C 1 ; C 2 G 1 m 13 ; m 13 C 2 G 2 m 13 Fig. 4 Information recorded by the data access point of C 3 142

9 Let m 23 of C 3 be the sender for multicast group G 1. Fig. 5 shows the network at this stage. C 1 C 3 m 11 ; G 1 DAP1 m 21 m 12 DAP 2 m 22 m 13 DAP 3 m 23 ; s m 42 ; G 2 m 32 ; G 1 C 2 Fig. 5 A new cluster C 3 is formed Following the Multicast Protocol, node m 23 first queries DAP 3 to know the clusters associated with multicast group G 1. Then DAP 3, from its Access Table knows that C 1 and C 2 are the clusters associated with the multicast group G 1. DAP 3 also knows that the gateway routing node to reach C 1 and C 2 is m 13. So DAP 3 sends the multicast packet to m 13 with the following information. Multicast Clusters C 1 ; C 2 Multicast Data MData Node m 13 sends this packet to the reachable node, here m 22. Now, m 22 first parses the Multicast Clusters field of the received multicast packet and finds that C 2 is present in that field. It then sends the multicast data to the members in C 2 G 1. Node m 22 now reconstructs the multicast packet by removing C 2 from the Multicast Clusters field of the received multicast packet. This packet is represented as follows. Multicast Clusters C 1 Multicast Data MData Node m 22 now sends this reconstructed multicast packet to DAP 2 which retrieves the Routing Node for clusters C 1 in the Multicast Clusters field. This routing node is m 12. DAP 2 now sends the multicast packet it has received from m 22, to m 12, which is the routing node to reach cluster C 1. The multicast packet eventually reaches cluster C 1 through node m 21. Node m 21, parses the Multicast Clusters field of the received multicast packet and finds that C 1 is present in that field. It then delivers the multicast data to m 11 G 1 of Cluster C 1. Node m 21, after removing C 1, from the Multicast Clusters field of the received multicast packet, finds that now the value in that field is NULL. Thus it does not take any further action. This is the termination condition for the proposed multicast protocol. Case 2: Inter Cluster Link Setup Protocol aiding Multicast Packet Delivery Assume that a new cluster, C 4 has been formed in the existing network of Fig. 5, and m 14 in cluster C 4 is in the transmission range of m 31 in cluster C 1 (refer to Fig. 6). Thus C 4 gets the table about the multicast group from C 1. Assume that m 24 C 4 joins Group G 2. Thus there will be a change in the values for the Access Table in DAP 4 which is shown in Fig

10 C 1 ; C 2 G 1 m 14 ; m 14 C 2 ; C 4 G 2 m 14; - Fig. 7 Information recorded by DAP 4 Following the Join and Access Table Interchange protocol, changes occur in other clusters in the network. For example, the Access Table of DAP 2 of cluster C 2 records the following information (Fig. 8). C 1 ; C 2 G 1 m 12 ;- C 2 ; C 4 G 2 -; m 12 Fig. 8 Information recorded by DAP 2 Now consider the case, where m 33 C 3 is the sender for multicast group G 2. The multicast packet delivery will be governed similar to Case 1. If m 34 ( C 4 ) and m 32 ( C 2 ) come in the transmission range of each other, then Intercluster Link Setup will be called and each will change its entry corresponding to that neighboring cluster, if there is an entry in the multicast table. The new Access Table for DAP 4 will contain the following information (Fig. 9). C 1 ; C 2 G 1 m 14 ; m 34 C 2 ; C 4 G 2 m 34; - Fig. 9 Latest information recorded by DAP 4 And the new Access Table for DAP 2 of cluster C 2 appears as shown in Fig. 10. C 1 ; C 2 G 1 m 12 ;- C 2 ; C 4 G 2 -; m 32 Fig. 10 Information recorded by DAP 2 Assume that during the time the packet took to reach cluster C 2, nodes m 34 and m 32 have come in the transmission range of each other and changed their access table routing node values. From Fig. 6, it is evident that upon reaching cluster C 2, the multicast packet will be delivered to cluster C 4 now, using the new shorter path setup between C 2 and C 4. Thus the Inter Cluster Link Setup Protocol has aided in more efficient delivery of the multicast packet, without which the multicast packet would have taken the longer path, that is from C 2 to C 1 and then finally to C

11 C 3 C 1 DAP1 m 11 ; G 1 m 21 m 12 C 2 DAP 2 m 22 DAP 3 m 23 m 31 m 34 m 32 ; G 1 m 42 ; G 2 m 13 m 33 ; s m 14 DAP 4 m 24 ; G 2 C 4 Fig. 6 Another new cluster C 4 is formed In the above illustration the following important advantages of our proposed multicasting scheme become evident: (1) it always looks for a possible better (shorter) path to reach clusters, and (2) no complete routing table needs to be exchanged. In general, significant reduction of routing table size and less amount of information exchange make the scheme both memory and bandwidth efficient for mobile ad-hoc networks. 4.6 Storage requirement Below we compare analytically the storage requirement for each mobile host considering the following two situations: 1) DVR is applied on unclustered ad-hoc networks and 2) DVR is applied on the presented clustered ad-hoc network. Assume that the network of n nodes is partitioned into N c number of clusters where N c << n. Without any loss of generality, we assume that on an average, the number of nodes in each cluster is m, such that N c * m = n. When DVR is applied in such a clustered network the distance vector table maintained by each node in a cluster will have a size of 2[m+(N c -1)] instead of 3n which corresponds to the unclustered network. This value 2[m+(N c -1)] becomes very small compared to 3n as n becomes large. Thus, because of this significant reduction of the table size the DVR scheme can be effectively applied to clustered adhoc networks offering efficient utilization of both memory and bandwidth. 4.7 Another Efficient Routing Scheme Core Based Tree (CBT) routing scheme is another important routing strategy that has been used in mobile ad hoc networks [6], [7]. In this routing, only one node (Core) with maximum number of neighbors takes the responsibility of routing multicast packets to all other nodes. Problem arises when this node no longer has the maximum number of neighbors due to node mobility or node failures. Therefore a new Core has to be selected considering all nodes in the network. This is not an easy task to accomplish considering the fact that every node is mobile. It will definitely not be bandwidth efficient since all nodes are to be involved in exchanging information necessary for the selection. However, CBT routing can be applied efficiently in the proposed clustered network in a distributed sense, in which each cluster head can act as a local Core, responsible for routing in its own cluster and communicating (if necessary) to its neighboring cluster heads. If the local core moves away or fails, then selection of a new local Core (cluster head) for this cluster becomes much easier than in [6], [7], because now only the nodes in this cluster plus any new nodes currently visiting this cluster need to be considered. Thus bandwidth utilization will also be better than the works [6], [7] because of fewer number of message exchanges needed for the selection of the core. 145

12 5. Conclusion In this paper, we have proposed a distance vector based multicast routing protocol for clustered MANET. The proposed scheme needs much smaller routing table per host and less amount of (information) exchanges compared to the distance vector routing scheme, applied on unclustered network. These advantages plus its adaptable nature to the changing ad-hoc network topology make this proposed multicasting protocol both memory and bandwidth efficient for MANET. We have also presented an idea about how to apply the CBT routing strategy in our clustered network in order to achieve efficient resource utilization. References [1] V. Doraiswamy, R. Jandhyala, and B. Gupta, An Efficient Dynamic Clustering Protocol for MANET, Proc. ISCA 19 th Int. Conf. Computers and Their Applications, Seattle, March, 2004, pp [2] C.E.Perkins, Mobile Networking in the internet, Mobile Networks and Applications, vol.3, 1998, pp [3] M. Nanda and B. Gupta, Cluster-Based Communication in Mobile Ad-Hoc Networks, Proc. 18 th Int. Conf. on Computers and their Applications, Hawaii, March, 2003, pp [4] A.Bruce MacDonald and Taieb Znati, A Mobility Based Framework for Adaptive Clustering in Wireless Ad-Hoc Networks, IEEE Journal on Selected Areas in Communication, vol 17, no. 8, August 1999, pp [5] Distance Vector Multicasting Protocol draft-ietf-idmr-dvmrp-v3-10.txt (2001). [6] A. Ballerdie, B. Cain, and Z. Zhang, Core Based Trees (CBT version 3) multicast routing protocol specification, Interner Draft, IETF, March, [7] A. Tewari, X. Dong, and B. Gupta, A Dynamic Self-Adaptive Multicast Protocol for Ad-Hoc Networks, Proc. ISCA 17 th Int. Conf. Computers and Their Applications, San Francisco, Apr, 2002, pp