Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks

Transcription

1 Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks C.Jayakumar 1 and C.Chellappan 2 1 Research Scholar, Department of Computer Science and Engineering, Anna University, Chennai, India jayakumar@cs.annauniv.edu 2 Professor &Director, Ramanujan Computing Centre, Anna University, Chennai, India drcc@annauniv.edu Abstract To solve the scalability issue of ad hoc network, a new cluster maintenance protocol is proposed. Clusters may change dynamically, reflecting the mobility of the underlying network. It is therefore difficult to maintain the clusters for efficient routing. For the effective functioning of cluster maintenance the size of the cluster and the cluster head must be chosen carefully in the larger and mobility environment. In this protocol, a node weight heuristic approach is applied with parameters like speed of the node, number of neighbor nodes and associativity. The cluster heads are elected based on these parameters for effective cluster management. 1. Introduction Cluster concepts are used for efficient routing in the larger network [12,13,14,16,17,23,29,41]. In this paper, cluster maintenance protocol has been proposed. For the effective functioning of cluster maintenance protocol, the size of the cluster and the cluster head must be chosen carefully [20]. A node being elected as the clusterhead should have maximum associativity as well as to satisfy a minimum connectivity requirement. Cluster management will be effective as the cluster heads are elected based on various parameters like speed of the node, number of neighbor nodes and associativity with the neighbor nodes. The proposed approach incurs lower overhead during topology updates and also has quicker reconvergence. Though high overhead is incurred initially due to cluster setup and cluster maintenance can be easier in the long run. The cluster maintenance effectively forms the k-clusters reorganization and reduces control packets overhead. Section 2 discuss about related works. Section 3 introduces the system model and novel approach for Cluster formation and maintenance. Data flow diagram of associativity based mobilityadaptive k-clustering protocol is shown in Section 4. Simulation results are analyzed in Section 5 and Conclusion is in Section Related Works In cluster-based routing, the network is dynamically organized into partitions called clusters with the objective of maintaining a relatively stable effective topology [9,17]. The membership in each cluster changes over time in response to node mobility, node failure or new node arrival. A clusterhead does the resource allocation to all the nodes belonging to its cluster [6]. Due to the International Journal of The Computer, the Internet and Management Vol. 14.No.1 (January-April, 2006) pp

2 C.Jayakumar and C.Chellappan dynamic nature of the mobile nodes, their association and dissociation to and from clusters perturb the stability of the network and thus reconfiguration of cluster heads is unavoidable [30]. This is an important issue since frequent change of clusterhead adversely affects the performance of other protocols such as scheduling, routing and resource allocation that rely on it. To solve the scalability issue of ad hoc network, a new cluster maintenance protocol is introduced. This protocol helps efficient routing in cluster through long-lived clusters. The detailed survey of various existing cluster maintenance scheme are discussed below. In hierarchical routing protocols, intracluster (inter-cluster) routing refers to the routing algorithm used to find a route between a source and destination within the same (belonging to different) clusters [3]. Typically, inter-cluster routing is reactive while intra-cluster routing is proactive [5]. The most important requirement in cluster based routing algorithms is to keep clusters as stable as possible, because dynamic change of membership needs more communication between the clusters in order to provide up-to-date membership information. A cluster structure, as an effective topology control means, provides at least three benefits [28]. First, a cluster structure facilitates the spatial reuse of resources to increase the system capacity [21]. Also, a cluster can better coordinate its transmission events with the help of clusterhead residing in it. This can save much resources used for retransmission resulting from reduced transmission collision. The second benefit is in routing, because the set of cluster heads and cluster gateways can normally form a virtual backbone for inter-cluster routing, and thus the generation and spreading of routing information can be restricted in this set of nodes [18]. Last, a cluster structure makes an ad hoc network appear smaller and more stable in the context of each mobile terminal [22]. When a mobile node changes its attaching cluster, only mobile nodes residing in the corresponding clusters need to update the information [4,14]. Thus, local changes need not be seen and updated by the entire network, and information processed and stored by each mobile node is greatly reduced. Clusters may change dynamically, reflecting the mobility of the underlying network. It is therefore difficult to maintain the clusters for efficient routing. The selection of a cluster head for routing in clustered networks is based on heuristics and associativity. Several heuristics have been proposed to choose clusterheads in an ad hoc network. These include (i) Highest-Degree heuristic (ii) Lowest-ID heuristic and (iii) Node- Weight heuristic [1,9,10,11,15,24,25,26,31]. In the assumed graph model of the network, the mobile terminals are represented as nodes and there exists an edge between two nodes if they can communicate with each other directly (i.e., one node lies within the transmission range of another). Let us summarize below these heuristics. a. Highest-Degree Heuristic This approach is a modified version of Parekh [27], which computes the degree of a node based on the distance between that node from others. A node x is considered to be a neighbor of another node y if x lies within the transmission range of y. The node with the maximum degree is chosen to be a clusterhead and any tie is broken by the node ids, which are unique. The neighbors of a clusterhead become members of that cluster and can no longer participate in the election process. This heuristic is also known as the highest-connectivity algorithm. Experiments demonstrate that the system has a low rate of clusterhead changes but the throughput of the system is low. Typically, each cluster was assigned some 62

3 Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks resources, which was shared among the members of that cluster on a round-robin basis [29]. As the number of nodes in a cluster is increased, the throughput of each user drops and hence, a gradual degradation in the system performance is observed. This is the inherent drawback of the Highest- Degree heuristic since the number of nodes in a cluster is not bounded. b. Lowest-ID Heuristic Gerla and Tsai [8] proposed a simple heuristic by assigning a unique id to each node and choosing the node with the minimum id as a clusterhead. However, the clusterhead can delegate its duties to the next node with the minimum id in its cluster. A node is called gateway if it lies within the transmission range of two or more clusters [1]. For this heuristic, the system performance is better compared to the Highest-Degree heuristic in terms of the throughput. Since the environment under consideration is mobile, it is unlikely that node degrees remain stable resulting in frequent clusterhead updates. The drawback of this heuristic is its bias towards nodes with smaller id which leads to the battery drainage of certain nodes. Moreover, it does not attempt to balance the load uniformly across all the nodes. c. Node-Weight Heuristic Basagni [2] assigned node-weights based on the suitability of a node being a clusterhead. A node is chosen to be a clusterhead if its node-weight is higher than any of its neighbor s node-weights. The smaller node id is chosen to break a tie. To verify the performance of the system the nodes were assigned weights, which varied linearly with their speeds but with negative slope. Results proved that the number of updates required is smaller than the Highest- Degree and Lowest-ID heuristics. The concepts of associativity have been used to identify long-lived routes [32]. Longlived clusters reduce the probability that a packet will be routed to the previous cluster of the addressed node, thus reducing the delay and overhead. Though larger clusters are desirable for stability reasons, larger cluster put a heavy premium on cluster heads, and hinders the efficient communication within the cluster. Basagni [1] proposed to use nodes for clusterhead (CH) decisions. He generalized the weight idea such that any meaningful parameter can be used as the weight in order to best exploit the network properties. Weight is defined by mobility related parameter such as speed. This algorithm makes an assumption that the network topology does not change during the execution of the algorithm. Thus, it is proven to be useful for quasi-static networks when the nodes either do not move or move very slowly. The other assumptions are: (i) the messages are guaranteed to be delivered to all of the nodes neighbors within a finite amount of time and (ii) every node is aware of the ids and the corresponding weights of all the nodes which are only one hop away. Basagni [2] further generalized the scheme by Basagni [1], by allowing each CH to have at most k neighboring CHs (instead of none), and by reducing the number of reallocations by introducing a threshold parameter h (that is, there is no reallocation unless a current CH candidate has weight, more than h greater than the weight of previous CH). The simulation measures the clustering stability, i.e., the number of elections and re affiliations per tick. The first set of experiments is with weights associated to nodes speed, while the second one has weights represented by nodes transmission powers. Bettsetter and Krauser [4] investigated the performance of the algorithm by Basagni International Journal of The Computer, the Internet and Management Vol. 14.No.1 (January-April, 2006) pp

4 C.Jayakumar and C.Chellappan [2]. In particular, they evaluated how the cluster stability (i.e., the number of cluster head elections, cluster changes per time step, and cluster lifetime) is influenced by the speed, the choice of the weight, and the failure rate of nodes. The scenarios used by them include a random mobility model and a realistic campus scenario that includes hot spots and streets. Measurements are presented, but no conclusions about stability of the algorithm were derived. Based on Node-Weight Heuristic approach has developed Distributed Mobility Adaptive Clustering (DMAC) algorithm [6]. However, the parameters such as throughput and associativity are not addressed. In this paper node-weight approach is applied with additional parameter associatvity, Number of neighboring nodes. Also new methods for Cluster Reorganization and Mobility adaptive maintenance is introduced. 3. System Model A number of Configuration parameters are used for cluster setup and maintenance. They are listed in the Appendix 3. The proposed system consists of two modules into two phases namely cluster formation and cluster maintenance. 3.1 Cluster Formation Hello Packet Exchange A node will periodically broadcast Hello packets to its neighbors every HELLO_INTERVAL time. A node on receiving Hello packets will update the neighbor table. If an entry is already present in the table for the node, which sent the Hello packet, the entry is updated and the Associativity Tick (AT) corresponding to that node is incremented. If an entry is not present, a new entry is created with the required information from the Hello packet with AT set to 1. Then the node will start a timeout for receiving the next Hello packet. If a node does not receive Hello packets within the HELLO_INTERVAL, it will decrement the AT corresponding to that node and invalidate that entry. If the AT becomes zero, that corresponding entry deleted from the neighbor table Cluster Initialization Cluster Initialization occurs as shown in the Figure 1.1. The shaded nodes are the initiators. This is the initial cluster formation process. All the nodes, which are in Undecided state, start waiting for a random of MAX_WAIT_TIME. The node, which first wakes up, will become the initiator. The initiator will broadcast Cluster Control Claim (CCC) packet with hop count set to K/2, where K is the diameter of the cluster i.e. the number of nodes from one end to other end and start a timer set to CCC_WAIT_TIME. If a node receives a CCC packet from an initiator, it will check first if it has already sent any CCC packet to other initiator. If so it will discard the CCC packet. Otherwise the node will copy the initiator id and the route. After that it will reply to the Initiator by Cluster Control Reply (CCR) packet using the reverse of the route obtained from the CCC packet. The node will decrement the hop count. If the hop count becomes zero, it will discard the CCC packet. Otherwise it will broadcast the CCC packet to its neighbors by updating the route information. After sending CCR packet it will wait for some interval to receive the Cluster Head Indication (CHI) packet. The node, which received the CCC packet, will reply back to the Initiator by CCR packet, which contains the necessary information for electing the cluster head. The information such as speed of node, sum of AT and number of neighbors are all calculated using the Neighbor table. The 64

5 Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks route information is obtained from the CCC packet. The initiator will accept the CCR packets, which arrive within the CCC_WAIT_TIME, other packets will be discarded. Once a CCR packet is received, the information contained in the packet is copied into the Initiator table. A B H S E M F C G J K I N O L D Fig. 1.1 Cluster Initiators Cluster Head Election A B S C E G K H I O N F M J L D Fig. 1.2 Clusters with Cluster Heads The Figure 1.2 represents cluster head (i.e. colored nodes) and its members. When CCC_WAIT_TIME expires, the initiator will start the cluster head election process. The cluster head is elected from eligible candidates. The candidate with the maximum Cluster head factor (CH_FACTOR) is elected as Cluster Head. CH_FACTOR (W) is calculated from speed of node v, NN (number of neighbors), Sum of AT by giving appropriate weights to each factor CH_FACTOR of node v is W v =w1 * M v + w2* NN * w3 * sum_at NN (1.1) where M v is the speed of a node v NN is the number of neighbors sum_at NN is the sum of Associativity Tick of neighbors and w1, w2, w3 are the weighing factors for the corresponding system parameters. 3 wi = 1, i i 0< w < 1 i= 1,2,3 (1.2) International Journal of The Computer, the Internet and Management Vol. 14.No.1 (January-April, 2006) pp

6 C.Jayakumar and C.Chellappan Compute the running average speed for every node till current time T. This gives a measure of mobility and is denoted by M v, as 1 M = (X X ) + (Y Y ) T 2 v t t 1 t T r= 1 {dist(v, v')} t 1 (1.3) where (X t, Y t ) and (X t 1, Y t 1) are the coordinates of the node v at time t and (t 1) respectively. The neighbors of each node v (i.e nodes within its transmission range), which defines its degree d v, as NN = N(v) = Σ {dist(v,v ) <tx range } (1.4) Where tx range is the transmission range um of Associativity tick of neighbor nodes (NN) is calculated as sum _ AT NN NN = AT (1.5) v= 1 here NN is the number of neighbor nodes AT is the associativity tick of node v For every node, compute the sum of the distances, D v, with all its neighbors, as D v = v' N(v) NN (1.6) If the initiator itself is the newly elected cluster head, it will broadcast Cluster Head Indication (CHI) packet to all the members of the cluster. If other node is elected as cluster head, the initiator will send Take Charge (TC) Packet to that node and will wait for the Cluster Head Beacon (CHB) packet to come. The node, which received the TC packet will update its status to Cluster Head and will send CHI packet to all the members 2 of the cluster and will start the necessary events for the cluster head Cluster Head and Member assertion A node on receiving CHI packet will check whether it has any old CHI packet by checking the CHI sequence number. If it is old, it will discard that packet. Otherwise the node will update the Cluster Head information if it is the correct intended CHI packet and will wait for the CHB packet. The Cluster Head after sending CHI packet will start sending CHB packet periodically every CHB_INTERVAL time. CHB contain the information about the cluster as given in the packet format (refer Appendix 2). A node on receiving CHB packet will check for the sequence number. It will discard the packet if it is old. If it is the intended CHB packet, it will update the Cluster Head information and will send Member Beacon (MB) packet to the Cluster Head. The node will start a timeout to receive the next CHB packet. If a member node doesn t receive CHB packet within the CHB_INTERVAL, it will check for any adjacent nodes to join with any other cluster. If it could, it will join with the chosen cluster. Otherwise it will start the cluster formation process again. Cluster Member nodes will send MB packet in response to CHB packet. The necessary information in the packet is calculated from the Neighbor table. The Cluster Head on receiving MB packet from a member node will update the Cluster Head table with the information from the MB packet and will set a timeout for receiving the next MB packet from that member node. If the cluster head does not receive an MB packet from a member, it will delete the entry corresponding to that member from the Cluster head table. It will also update the 66

7 Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks Adjacency Cluster table accordingly by removing the node. 3.2 Cluster Maintenance Cluster Reorganization Every node will check for Cluster reorganization at every REORGANIZATION_INTERVAL period of time. Chlamtac and Farago [7] considered the speed of node for cluster reorganization. In order to increase the performance of cluster reorganization, the following additional factors are considered: Minimum Number of hops (NH) with other clusterheads is given by α = min{nh } (1.7) 1 v Minimum CH_FACTOR (β) of other cluster heads α = min{w } (1.8) 2 v v Associativity ticks with the neighboring nodes of other clusters within its transmission range tx range. α = min{sum _ AT } 3 NN v NN (1.9) The reorganization factor(r) is calculated as R = w i α i 0< wi < 1 and i =1,2,3 (1.10) w = 1 i Once a node has decided to join with some other cluster, it will join by updating the cluster head information and will start the Cluster Reorganization timer. The Advantage of Cluster reorganization is that the cluster will rearrange themselves according to the spatial and temporal stability of nodes in the network and hence the clusters formed will be long lived. Cluster deformation will be very much smaller compared to other clustering algorithms and hence the routing overhead will be minimized due to reduction is the number of maintenance packets required for handling such deformation Mobility Adaptive Maintenance When a new node joins the cluster, it will receive the CHB packet from the Cluster Head. In response to that, it will send MB packet and therefore it now has become a member of the cluster. The cluster head accordingly updates the information in the Cluster Head table and the Adjacency Cluster Table. When a node moves away from a cluster, the MB timeout for that node will occur, since the Cluster head cannot receive any MB packets from that node. Hence it will delete the corresponding entries from the Cluster head table and the Adjacency Cluster table. When the Cluster Head itself moves away, all the nodes in the cluster cannot receive the CHB packet from the cluster head. Hence timeout occurs in all the member nodes. They will try to join with other clusters. If possible they will join. Otherwise, they will start the cluster initialization process Cluster Head Re-election Every REELECTION_INTERVAL of time, the cluster head will check for electing a new cluster head. The eligibility criteria are as follows: NN > MIN_NN sum_at of target cluster > sum_at of nodes in other cluster. sum_at of target cluster > sum_at of current cluster head The node will try to elect a new cluster head. If not possible, it will remain as the cluster head and will schedule the Reelection again after REELCTION_INTERVAL. New Cluster International Journal of The Computer, the Internet and Management Vol. 14.No.1 (January-April, 2006) pp

8 Quality Of Service in Associativity Based Mobility-Adaptive K-Clustering In Mobile Ad-Hoc Networks Hello packet Exchange Any Node in undecided state exchange Node that wakes up first after MAX_WAIT_TIME Initiator Selected Initialization Node that has maximum CH_FACTOR after CCC_WAIT TIME expires Cluster reorganization & maintenance For every RE-ELECTION INTERVAL cluster Head checks for electing new Head Cluster Head Selected Cluster Head Election For every RE-ORGANIZATION INTERVAL nodes are checked for reorganization Cluster Head and Members Communicate and reorganize CHI, CHB, MB packets are used for communication Cluster Head and member assertion Fig. 1.3 Data Flow Diagram 68

9 Quality Of Service in Associativity Based Mobility-Adaptive K-Clustering In Mobile Ad-Hoc Networks Head is elected by calculating REFACTOR (Re-election Factor), which is a speed of node, number of neighbors, sum of AT of target cluster and sum of AT of this cluster. The Cluster head is informed by sending Take charge change (TCC) packet. On Receiving TCC packet, the member node will update its status to cluster Head and will send Cluster Head Change (CHC) packet to its entire member. Then it will start the routine events of a Cluster head. On Receiving CHC packet, the member nodes will update the new cluster head information and will wait for the CHB from the new Cluster head. By Cluster head Re-election, the cluster head is made to be centered in the cluster as for as possible, so that it can manage a number of nodes effectively. Combined with Cluster Reorganization, it makes way for clusters to be long lived with minimum deformations. 4 Data Flow Diagram The overall process of the protocol, which includes Hello Packet Exchange, Cluster Initialization, Cluster Head Election, Cluster Head and Member assertion, Cluster Reorganization, Mobility Adaptive Maintenance and Cluster Head Re-election is shown in Figure Simulation Results The Clustering maintenance protocol has been simulated using the Network Simulator (ns2)[33]. For the simulation of the protocol, all the required data structures, packet format, messages and packet receiving and transmission functions are added to the network simulator (refer Appendix 1 to 3). Clustering protocol is added in the same network layer as AODV and DSR protocol. A new packet type for clustering called CLUSTER is added to the network simulator. It has a lot of subtypes as mentioned in the Appendix 2. To simulate the Clustering protocol in NS, traffic patterns and scenarios of mobile nodes need to be created. Tools are available in NS for generating the traffic patterns and scenarios with custom values for traffic, nodes and their movements (Appendix 3). Number of Clusters Number of Nodes K=2 K=4 K=6 K=8 Fig. 1.4 Number of clusters vs. number of nodes for different K The simulation is run for different values of diameter (K) for different number of nodes (N) and the results are shown in this Section. The Figure 1.4 represents the number of clusters formed for different values of diameter (K) for different number 69

10 C.Jayakumar and C.Chellappan of nodes (N) in the system. From the graph (Figure 6.4) it is found that when K=2 the total number of clusters formed is high when compared to others. The graph shows indicates that as K increases, the number of clusters formed decreases and will help in maintaining the clustering at ease. The Figure 1.5 gives the details of the cluster changes with time, keeping the number of nodes in the system same and the diameter of the cluster same. It can infer that when it is compared to the Distributed mobilityadaptive clustering (DMAC) protocol (Bettstetter and Friedrich 2003), the proposed protocol shows 14.67% improvement performance by keeping the number of cluster changes minimal. Cluster Changes(for n=15, K=4) Number of cluster changes DMAC Proposed Algortihm Pause Time(sec) Fig. 1.5 Number of cluster changes with pause time 6 Conclusion It has been shown that the proposed Clustering protocol has proven to be effective in a variety of mobile scenarios. Though overhead is incurred initially due to cluster setup, cluster maintenance is made easier in the long run. Cluster deformations are greatly reduced due to Cluster Reorganization and Cluster Head Re-election since they result in stable clusters. The node elected as clusterhead has maximum associativity as well as satisfies a minimum connectivity requirement. Cluster Management is effective. The routing efficiency has increased due to long-lived clusters and control packets have reduced. References 1. Basagni S., Distributed Clustering for Ad Hoc Networks, Proceedings of International Symposium on Parallel Architectures, Algorithms and Networks, Australia, pp , Basagni S., Distributed and mobilityadaptive clustering for multimedia support in multi-hop wireless networks, Proceedings of IEEE Fiftieth International Vehicular Technology Conference, Amsterdam, The Netherlands, Vol.2, pp , Belding-Royer E.M., Hierarchical routing in ad hoc mobile Networks, Wireless Communication and Mobile Computing, Vol.2, No.5, pp , Bettsetter C. and Krauser R., Scenariobased stability analysis of the distributed mobility-adaptive clustering DMAC algorithm, Proceedings of the ACM/IEEE Workshop on Mobile Ad Hoc Networking and Computing, Long Beach, CA, USA, pp ,

11 Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks 5. Bettstetter C., The cluster density of a distributed clustering algorithm in ad hoc networks, Proceedings of IEEE International Conference on Communications, Paris, France,Vol.7, pp , Bettstetter C. and Friedrich B., Time and message complexities of the generalized distributed mobilityadaptive clustering (GDMAC) algorithm in wireless multihop networks, Proceedings of IEEE Vehicular Technology Conference, Jeju, Korea, pp.22-25, Chlamtac I. and Farago A., A New Approach to the Design and Analysis of Peer-to-Peer Mobile Networks, Wireless Networks, Vol.5, No.3, pp , Gerla M. and Tsai J.T.C, Multicluster, Mobile, Multimedia Radio Network, Wireless Networks, Vol.1, pp , Gerla M., Kwon T.J. and Pei G, On demand routing in large ad hoc wireless networks with passive clustering, Proceedings of IEEE Wireless Communications and Networking Conference, Vol.1, pp , E. Gafni, D. P. Bertsekas, Distributed Algorithms for Generating Loop-free Routes with Frequently Changing Topology, IEEE Transactions on Communications, Vol. COM-29, No. 1, pp.11-18, January J. J. Garcia-Luna-Aceves, A Unified Approach to Loop-free Routing Algorithm Using Distance Vectors or Link States, Proceedings of ACM SIGCOMM Symposium on Communication, Architectures and Protocols, pp , September Z. J. Haas, M. R. Pearlman, P. Samar, The Interzone Routing Protocol (IERP) for Ad Hoc Networks, IETF draft, June Z. J. Haas, M. R. Pearlman, and P. Samar, The zone routing protocol (ZRP) for ad hoc networks, IETF draft, July A. Iwata, C. Chiang, G. Pei, M. Gerla, and T. Chen, Scalable routing strategies for ad-hoc wireless networks, IEEE J. Select. Areas Commun, vol. 17, no. 8, pp , Aug J. M. Jaffe, F. M. Moss, A Responsive Routing Algorithm for Computer Networks, IEEE Trans. on Communications, pp , July M. Jiang, J. Li and Y.C. Toy, Cluster- Based Routing Protocol, IETF draft, August Joa Ng M. and Lu I.T, A Peer-to-Peer Zone-based Two-level Link State Routing for Mobile Ad Hoc Networks, IEEE Journal on Selected Areas in Communications, 1999, pp Kozat U.C., Kondylis G., Ryu B. and Marina M.K., Virtual Dynamic Backbone for Mobile Ad Hoc Networks, Proceedings of IEEE international Conference on Communications, Vol.1, pp , P. Krishna, Mainak Chatterjee, Nitin H. Vaidya, Dhiraj K. Pradhan, A Clusterbased Approach for Routing in Ad-Hoc Networks, Proceedings of second Symposium on Mobile and Location- Independent Computing, pp.1-10, Lin C.R. and Gerla M., Adaptive Clustering for Mobile Wireless Networks, IEEE Journal on Selected Areas in Communications, Vol.15, No.7, pp , Marsic I. and Sucec J., Clustering overhead for hierarchical routing in mobile ad hoc networks, Proceedings of IEEE Conference on Computer Communications, pp , McDonald A.B. and Znati T.F., A Mobility-based Frame Work for International Journal of The Computer, the Internet and Management Vol. 14.No.1 (January-April, 2006) pp

12 C.Jayakumar and C.Chellappan Adaptive Clustering in Wireless Ad Hoc Networks, IEEE Journal on Selected Areas in Communications, Vol.17, pp , Y. T. Mingliang Jiang, Jinyang Li, Cluster based routing protocol, IETF Internet Draft, draft-ietf-manet-cbrpspec-01.txt, July [Online]. Available: tayyc/cbrp/ 24. J. M. McQuillan, D. C. Walden, The ARPA Network Design Decisions, Computer Networks, Vol.1, No.5, pp , August J. McQuillan, Adaptive Routing Algorithm for Distributed Computer Networks, BBN Report 2331, BBN, Cambridge, MA, J. M. McQuillan, I. Richer, E. C. Rosen, The New Routing Algorithm for ARPANET, IEEE Transaction on Communications, Vol. 28, No. 5, pp , May Parekh A.K., Selecting Routers in Ad hoc Wireless Networks, Proceedings of IEEE International Symposium on Telecommunications, pp.14-21, Rajaraman R., Topology Control and Routing in Ad Hoc Networks: A Survey, ACM SIGACT News, Vol.33, No.2, pp.66-73, Ramanathan R. and Steenstrup M., Hierarchically-organized, multihop mobile wireless networks for quality-ofservice support, ACM/Baltzer Mobile Networks and Applications, Vol.3, pp , Steenstrup M., Cluster-Based Networks, Ad Hoc Networking, Perkins C.E. ed., chapter 4,, pp , Addison-Wesley, M. Schwartz, T. E. Stern, Routing Techniques used in Communication Networks, IEEE Transactions on Communications, pp , April Toh C., Cobb H. and Scott D., Performance evaluation of battery-lifeaware routing schemes for wireless ad hoc networks, Proceedings of IEEE International Conference on Communications, Vol.9, pp , UCB/LBNL/VINT Network Simulator. 72

13 Quality Of Service in Associativity Based Mobility-Adaptive K-Clustering In Mobile Ad-Hoc Networks APPENDIX 1 Data Structures A number of tables are needed for maintaining the information about the neighboring nodes and the cluster. Each node will have certain tables depending on the role it plays. For cluster setup and maintenance, a number of tables are used in the nodes. Nodes, which are elected as Cluster heads, need to create certain tables for maintaining the member information of the cluster. The following are some of the data structures that are needed by the nodes in a cluster environment. Node Information Each node maintains the following information about itself. They exchange this information with other nodes whenever needed. Certain fields are used only when the nodes in a cluster. They are follows: ID: Identifier of the node. It is used to identify a node in a group of nodes in a network. Cluster ID: This is used only when the node is in a cluster. It is usually identifier of the cluster head of the cluster. Weight: This is calculated based on the node capabilities. Some of the parameters used for calculating weight are: Speed of movement of node, Number of neighboring nodes and Sum of Associativity Tick of Neighboring nodes Number of hops (NH): Number of hops this node away from the cluster head. This is used to decide during cluster reorganization. Status: Status of the node indicates whether the node is Undecided, Cluster member or Cluster Head. Undecided state implies that the node is not in any cluster. Gateway: Indicates whether the node is a gateway to other clusters or not. If the node is a gateway, then it has to maintain the gateway information in a gateway table. Number of neighbors (NN): Total number of adjacent nodes. Sum of the Associativity Tick (AT): This is the total sum of all the ATs of the neighbors in the neighbor s table. AT is used to maintain the associativity information. When a new neighbor is found, its AT is set to 0. Periodically all nodes will announce their presence to their neighbors through hello packets. Whenever a hello packets is received from a neighbor, its AT is incremented.if it is not received within the stipulated period of time, its AT is decremented and the valid field is set to 0. When the AT becomes zero, the entry will be deleted. Neighbor Table All nodes will exchange their data with the neighboring nodes using hello packets. Whenever a node receives a hello packet, it is updated in the Neighbors table. Each node maintains the Neighbors table, which contain information about the neighboring nodes. The fields in the neighbors table is described as below Valid: Indicates the validity of the entry. If this is 0, then the entry is invalid ID: Id of the neighbor nodes Status Cluster ID: This is the cluster id of the neighboring node AT Weight: Weight of the neighboring node Cluster head weight Number of hops Initiator table Whenever a node becomes an initiator, it will create the initiator table, which is used 73

14 C.Jayakumar and C.Chellappan to store information about the nodes in the cluster, and used to elect the cluster head based on the various fields of the table. Each node, which replies to the initiator, will have an entry in the initiator table. The information present in this table are shown below: ID: Identifier of the node, which replied to the initiator Weight: Weight of the node sum_ AT: Sum of ATs of all the neighboring node of the node NN Route: Route to this node from the initiator Using the weight, the cluster head is elected. If the initiator itself is the cluster head, then it will start the events corresponding to the cluster head. If some other node is elected as the cluster Head, the initiator will inform that node through the route information The Cluster head uses this cluster head table during routing. This table is used for the proactive routing within the cluster. This table is updated whenever a new node joins the cluster or a node moves away from the cluster. Adjacency Cluster Table The Cluster head also maintains the Adjacency Cluster table for routing with other clusters. The fields in this table are follows. ID: Neighbor cluster identifier List of Gateway: List of gateway nodes, which are adjacent to this neighbor cluster. The Cluster head can choose one of the gateway nodes for routing with other cluster based on the proximity and capability of the gateway node. Cluster head table Whenever a node is elected as the cluster head it will create this table. This table contains entry for each member of the cluster. The following are the fields in the table. ID: Id of the member node sum_at: Sum of ATs of all the neighboring node of the member node Weight: Weight of the member node NH: Number of hops the member node is away from the cluster head sum_at of the cluster: Sum of ATs of all the neighboring nodes of the member node, which belong to this cluster NN Gateway: Indicates whether the node is a gateway or not Route: Route to the member node from the cluster head 74

15 Quality Of Service in Associativity Based Mobility-Adaptive K-Clustering In Mobile Ad-Hoc Networks APPENDIX 2 Various cluster message packet formats Each node exchanges with other nodes a number of messages based on the role, which it plays. The following are the formats of the packets, which are used in a cluster environment. Hello Packet Every node irrespective of whether it is Cluster Undecided, Cluster head or Cluster Member will exchange hello packets with its neighbors. This packet is used to collect information about the neighbor and store them in the neighbor table. The packet format is as follows: NOD E ID STATUS WEIGHT CLUSTE R ID CLUSTER HEAD WEIGHT A node on receiving Hello packet will update its own Neighbor table. If an entry is already present in the table for the node which sent the Hello packet, the entry is updated and the AT corresponding to that node is incremented. If it is not present, a new entry is created with the required information from the Hello packet with AT set to 1. The node will start a timeout for receiving the next Hello packet. If a node doesn t receive Hello packet within the HELLO_INTERVAL, it will decrement the AT corresponding to that node and invalidate that entry. If the AT becomes zero, that entry will be deleted from the neighbor table. Thus this packet is used to keep track of the neighbors. Cluster Control Claim Packet Whenever a node becomes Initiator, it wills first broadcast Cluster Control Claim (CCC) packet with K/2 set as the hop count, NH where K is the diameter of the cluster i.e. the number of nodes from one end to other end. The format of the packet is as follows: INITIATOR ID HOP COUNT ROUTE Route will contain the route from the initiator to the node. A node, which receives this packet, will decrement the hop count. If the hop count becomes zero, the packet will not be broadcasted, but dropped. Otherwise, it will broadcast the packet to its neighbor nodes. The node will reply back to the initiator by sending the Cluster Control Reply packet. Cluster Control Reply packet A node, which received CCC packet, will send Cluster Control Reply (CCR) packet as a reply back to the initiator. CCR packet is source routed using the route information obtained from the CCC packet. The format is as follows. ID WEIGHT sum_at NN ROUTE Route will contain the reverse of the route field in the CCC packet. The information for the packet is obtained from the neighbor table. The initiator on receiving this packet will update the initiator table. Once the timeout for receiving CCR packet is over, cluster head is elected and is informed through Take Charge Packet. Take Charge Packet Take Charge (TC) Packet is the packet sent by the initiator to the new Cluster Head elect. The format of the packet is INITIATOR ID CLUSTER HEAD ID MEMBER NODE ID ROUTE 75

16 C.Jayakumar and C.Chellappan Member node Ids are the identifiers of the nodes, which replied to the initiator. Route is to unicast this packet to the new Cluster Head. Once a node receives this packet, it becomes the Cluster Head and will start the necessary events for the cluster Maintenance. Cluster Head Indication Packet Cluster Head Indication (CHI) Packet is the first packet broadcasted by a Cluster Head on receiving TC packet. All nodes, which receive this CHI packet, will update their status to Cluster Member and store the information about the Cluster Head. The following are the fields in this packet. INITIATOR ID CLUSTER HEAD ID NH CHI SEQUENCE NUMBER The CHI sequence number is used to remove any old packet that is circulated in the cluster. This CHI packet is accepted only by the nodes, which replied back to the corresponding initiator. After this, the cluster head will start broadcasting Cluster Head Beacon packet periodically. Cluster Head Beacon Packet Cluster Head Beacon (CHB) Packet is broadcasted periodically by the Cluster Head to all its members. The information in the packet is as follows: CLUSTER ID WEIGHT NH ROUTE CHB SEQUENCE NUMBER CHB sequence number is used to receive only new CHB packets and drop old ones that are wandering around due to broadcasting in the cluster. The members on receiving the CHB packet will update the required information from the packet, decrement the hop count, update the route and broadcast the packet again to its neighbors. After broadcasting this packet the members will reply to the Cluster Head using Member Beacon (MB) packets. Member Beacon packet Member Beacon (MB) packet is sent by the member nodes to the Cluster Head in response to the CHB packet. The Cluster Head will update the Cluster Head table on receiving this packet. The information s presents in the packet are: Id, Weight, Sum of AT, Sum of AT of this cluster, NN, Number of hops, Gateway, Adjacent Cluster Ids and Route. The information in this packet is stored in the Cluster Head table so that routing can be made proactive using the Route. The gateway information is updated in the Adjacency Cluster table using the Adjacent Cluster IDs of this packet. Also, this information is used in the Cluster head re-election process, which is done periodically to maintain the cluster. Take Control Change Packet Take Control Change (TCC) packet is the packet that is sent by the Cluster Head to the newly elected Cluster Head during the Cluster Head re-election process. The new Cluster Head will then send Cluster Head Change packet to all members of the cluster. The format of the TCC packet is as follows. OLD CLUSTER HEAD ID NEW CLUSTER HEAD ID ROUTE Route is the unicast route to the new Cluster Head elect. This packet is source routed using the route. Cluster Head Change Packet Cluster Head Change (CHC) packet is broadcasted by the new Cluster Head on receiving the TCC packet. The member nodes, which receive the CHC packet, will 76

17 update the information about the new Cluster Head. The format is as follows Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks OLD NEW CLUSTER NH CHC SEQUENCE CLUSTER ID ID NUMBER Each node before broadcasting to its neighbors determines number of hops. CHC sequence number is used to receive only new packets and drop the old circulating packets in the cluster. This packet is broadcasted to the nodes only within this cluster. International Journal of The Computer, the Internet and Management Vol. 14.No.1 (January-April, 2006) pp

18 Quality Of Service in Associativity Based Mobility-Adaptive K-Clustering In Mobile Ad-Hoc Networks APPENDIX 3 MODULES AND THE HANDLERS USED Hello Packet Exchange: Hello_periodic_handler is used to schedule the hello packets after HELLO_INTERVAL of time regularly throughout the simulation. Hello_timeout_handler is called when the hello packet is not received from the particular neighbor for HELLO_INTERVAL. Cluster initialization: For Cluster initialisation Random_wait_handler is used to initially call to wait for random amount of time and send the CCC packet and CCC_wait_handler are used and CCC_wait_handler is scheduled to wait for CCC_WAIT_TIME after sending the CCC packet and collect the CCR packets between that time intervals. Cluster head election: For Cluster head election, Cluster_formation_handler is called after initiator has been collected the packet after sending CCC packet and waited for random amount of time to form the cluster. Cluster head and Member assertion: CHB_periodic_handler is used to send the cluster head beacon to all its members if the node is a Cluster head. Else the member has to respond with MB to the Cluster Heads CHB. This is used to keep track of the members and the route to send the message. Member_timeout_handler is used to wait for some random time after sending the CHB and if it does not receive any MB then this handler is called. CHB_timeout_handler is called if a member does not receive CHB. Cluster reorganization: Reorganization_ periodic_handler called every REORGANIZATION_INTERVAL time is used to change the cluster of a node to the more stabilized group of cluster. It is also used to change the cluster head. Cluster head re-election: The Reelection_periodic_handler is called to elect the new Cluster Head every REELECTION_INTERVAL. Mobility adaptive maintenance: No specific handlers are used for the mobility adaptive maintenance since it is done throughout the program and cannot be separated as a specific handler. Packet Transmission and Reception function The Packet transmission and Reception functions has been developed. The packet transmission functions are sendhello(), sendccc(), sendccr(), sendtc(), sendchb(), sendchi(), sendchc() and sendtcc(). Similarly the packet reception functions namely recvhello(), recvccc(), recvccr(), recvtc(), recvchb(), recvchi(), recvchc() and recvtcc(). Creating random traffic-pattern for wireless scenarios Random traffic connections of TCP and CBR can be setup between mobile nodes using the traffic-scenario generator script. This generator script is available under ~ns/indep-utils/cmu-scen-gen and is called cbrgen.tcl. This script can be used to create CBR and TCP traffics connections between wireless mobile nodes. In order to create a traffic-connection file, the type of traffic connection (CBR or TCP), the number of nodes and maximum number of connection to be setup between them, a random seed and in case of CBR connection, a rate whose 78

19 Quality of Service in Associativity based Mobility-Adaptive K-Clustering in Mobile Ad-hoc Networks inverse value is used to compute the interval time between the CBR packets are needed to be defined. So the command line looks like the following: ns cbrgen.tcl [-type cbr tcp] [-nn nodes] [-seed seed] [-mc connections] [-rate rate] For example, to create a CBR connection file between 20 nodes, having maximum of 8 connections, with a seed value of 1.0 and a rate of 4.0: ns cbrgen.tcl type cbr nn 20 seed 1.0 mc 8 rate 4.0 > cbr-20-test Here cbr-20-test is the traffic pattern file that is generated. Creating node-movements for wireless scenarios The node-movement generator is available under ns/indep-utils/cmu-scengen/setdest directory and consists of setdest {.cc,.h} and Makefile. Run setdest with arguments as shown below:./setdest [-n num_of_nodes] [-p pausetime] [-s maxspeed] [-t simtime] \ [-x maxx] [-y maxy] > [outdir/movement-file] To create a node-movement scenario, 20 nodes are moving with maximum speed of 10.0s m/s with an average pause between movements being 2s, to stop after 200s for a topology boundary of 500 X 500../setdest n 20 p 2.0 s 10.0 t 200 x 500 y 500 > scen-20 test Here scen-20-test is the scenarios file generated. It contains Tcl-scripts for random motion of mobile nodes. Configuration Parameters MAX_WAIT_TIME: Maximum waiting time a node can wait during the random waiting of the cluster initialization process CCC_WAIT_TIME: Time the initiator waits for receiving Cluster Control Reply (CCR) packets after send Cluster Control Claim (CCC) packets. Initiator will accept the only CCR packets, which arrived within this interval. MIN_NN: Minimum number of neighboring nodes required to form a cluster head. HELLO_INTERVAL: Periodic interval for broadcasting HELLO packet to the members of the cluster CHB_INTERVAL: Periodic interval to broadcast Cluster Head Beacon (CHB) packet to the members of the cluster. REORGANIZATION_INTERVAL: Periodic interval to check for reorganization with other clusters. REELECTION_INTERVAL: Periodic interval with which the cluster head checks for electing new cluster head. Running the simulation Include the traffic connection pattern file and the scenario file in the OTcl script file that is used for running the simulation. Instead of other routing protocols, use the Cluster as the routing protocol. Trace generation Running the OTcl scripts generates two file,.tr file and.nam file. The tr files are called trace files and the nam files are used as input to the NAM. The trace files have the format as specified below. Node n sent Hello packet at <time>: This trace shows that then node n has sent Hello packets to its neighbors at time<time> International Journal of The Computer, the Internet and Management Vol. 14.No.1 (January-April, 2006) pp

20 C.Jayakumar and C.Chellappan Node n1 received Hello from Node n2 at <time>: This trace shows that the node n1 has received Hello packet from node n2 at <time> Hello Timeout occurred in n1 for n2 at <time>: This trace indicates that node n2 has moved away from n1, so timeout occurred. Neighbor Table of n at <time>: valid id status at clusterid weight ch_weight num_hops This trace shows the Neighbor Table of node n at time<time> Cluster Formation Handler called for n at <time>: This trace indicates that the cluster formation handler for the node n is called at <time> Random Wait Handler called for n at <time> Initiator table of n at <time>: Id weight sum_at NN route Node n sent CCC at <time> Node n1 received CCR from n2 prevhop n3 at <time> Node n1 sent CCR to n2 at < time> Node n1 received CCR from n2 at <time> Node n woke up at <time> Cluster head is node n at <time> Node n sent CHB at <time> Node n1 sent MB to n2 at <time> Head table of n at <time>: id sum_at this cluster weight num_hops NN gateway route 80