Yi Gong
Content
Aalto University School of Science and Technology Faculty of Information and Natural Sciences
Yi Gong
A Flexible Simulation Framework for Hierarchical Clustering on Wireless Sensor Networks
Master's Thesis Espoo, June 30, 2010
Supervisors: Professor Antti Ylä-Jääski, Aalto University Assistant Professor Markus Hidell, The Royal Institute of Technology Instructor: Pin Nie M.Sc. (Tech.), Aalto University
Aalto University School of Science and Technology Faculty of Information and Natural Sciences Degree Programme of Security and Mobile Computing
ABSTRACT OF MASTER'S THESIS
Author: Yi Gong Title of thesis:
A Flexible Simulation Framework for Hierarchical Clustering on Wireless Sensor Networks
Date: June 30, 2010 Pages: 10 + 82 Professorship: Data Communications Software Code: T-110 Supervisors: Professor Antti Ylä-Jääski Assistant Professor Markus Hidell Instructor: Pin Nie M.Sc. (Tech.)
In Wireless Sensor Networks, a clustering algorithm is a good option to reduce redundant data transmission and organize nodes e ciently for long life span. In this thesis, we mainly introduce, implement and evaluate a novel exible hierarchical clustering algorithm on middleware layer based on Publish/Subscribe paradigm. The goal of our algorithm is to provide the ve features, scalability, energy e ciency, fault tolerance, load balancing and multi-level clustering. Our algorithm includes three protocols. Flat Clustering protocol constructs a 2-level clustering network structure. Function Delegation protocol provides the fault tolerance and load balancing features. Multi-Level Clustering protocol builds up a more than 2-level clustering network structure. The thesis also studies several popular simulators and explicates the design and implementation of our algorithm on the ns-2 simulator. Then, we evaluate the algorithm from dierent angles. Based on our simulation, we optimize key parameters for our algorithm and nd that the performance and the energy e ciency of our algorithm are promising, especially in the bridge topologies.
Keywords: Language:
Wireless Sensor Network, Hierarchical Clustering Algorithm, Simulation, NS-2 English
ii
Abstrakt
I trådlösa sensornätverk är ett kluster algoritm ett bra alternativ för att minska överflödig dataöverföring och organisera noder effektivt för lång livslängd. I denna avhandling presenterar vi i första hand, genomför och utvärderar en ny flexibel hierarkisk klustring algoritm på mellanprogram skikt baserat på Publish/Subscribe paradigm. Målet med vår algoritm är att ge de fem funktioner, skalbarhet, energieffektivitet, feltolerans, lastbalansering och flera nivåer klustring. Vår algoritm omfattar tre protokoll. Flat Clustering protokoll konstruerar en 2-nivå klustring nätstruktur. Function Delegation protokollet ger feltolerans och lastbalansering funktioner. Multi-Level Clustering protokoll bygger upp en mer än 2-nivå klustring nätstruktur. Avhandlingen undersöker också flera populära simulatorer och tydliggör utformningen och genomförandet av vår algoritm på ns-2 simulator. Därefter utvärderar vi algoritmen från olika vinklar. Baserat på vår simulering, optimering vi nyckelparametrar för vår algoritm och upptäcker att prestanda och energieffektivitet i vår algoritm är lovande, särskilt i bro topologier.
Nyckelord:
NS-2
Trådlöst Sensornätverk, Hierarkisk Klustring Algoritm, Simulering,
iii
Acknowledgements
This study was carried out at the data communications software research lab in School of Science and Technology, Aalto University, Espoo, Finland. First of all, I would like to thank Prof. Antti Ylä-Jääski (Aalto University) and Assistant Prof. Markus Hidell (KTH). Their high-level guidance and supervision pointed out a clear direction for my research. Also, I would like to express my gratitude to my instructor, Pin Nie (Aalto University) who had been working closely with me. His instructions provided a great deal of help and valuable suggestions for my study and always kept me on the right track. Furthermore, I would also like to thank all my colleagues, Zhihua Jin, Bo Li, Andre Schumacher and Shekar Nethi for their support of my work. Finally, I would like to address my deepest gratitude to my family and friends for providing support during my studies.
Espoo, June 30, 2010
Yi GONG
iv
Abbreviations and Acronyms
ACA AODV BCH CH CM DSDV DSR GPSR IC ISMO LR-WPAN OOP SH WSN Autonomous Component Architecture Ad hoc On-Demand Distance Vector Routing Backup Cluster Head Cluster Head Cluster Member Destination-Sequenced Distance-Vector Routing Dynamic Source Routing Greedy Perimeter Stateless Routing Integrated Circuit Intelligent Structural Health Monitoring System Low-Rate Wireless Personal Area Network Object Oriented Programming Cluster Sub-Head Wireless Sensor Network
v
Contents
Abbreviations and Acronyms 1 Introduction
1.1 1.2 1.3 1.4 1.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . Objectives and Scopes . . . . . . . . . . . . . . . . . . . . . . Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . .
v 1
1 3 4 5 6
2 Clustering Algorithm
2.1 2.2 2.3 2.4 2.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . De nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8 8
Flat Clustering Protocol . . . . . . . . . . . . . . . . . . . . . 10 Function Delegation Protocol . . . . . . . . . . . . . . . . . . 13 Multi-Level Clustering Protocol . . . . . . . . . . . . . . . . . 16
3 Current State of Simulator
3.1 3.2 3.3 3.4 J-Sim
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Implementation
4.1 vi
23
Protocol Stack and Platform . . . . . . . . . . . . . . . . . . . 23
4.2 4.3 4.4 4.5 4.6
Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Main Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Flat Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Function Delegation . . . . . . . . . . . . . . . . . . . . . . . 34 Multi-Level Clustering . . . . . . . . . . . . . . . . . . . . . . 36
5 Evaluation
5.1 5.2 5.3
39
Simulated Environment . . . . . . . . . . . . . . . . . . . . . . 39 Test Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Simulation Analysis . . . . . . . . . . . . . . . . . . . . . . . . 43 5.3.1 5.3.2 5.3.3 Flat Clustering . . . . . . . . . . . . . . . . . . . . . . 43 Delegation Protocol . . . . . . . . . . . . . . . . . . . . 54 Hierarchical Clustering . . . . . . . . . . . . . . . . . . 57
6 Conclusion and Future Work
6.1 6.2
67 73 80
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A Implemenation of RockAgent Class B Usage of RockAgent
A.1 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2 Parameters and Functions . . . . . . . . . . . . . . . . . . . . 73
vii
List of Tables
3.1 5.1 5.2 5.3 5.4 Comparison of dierent simulators . . . . . . . . . . . . . . . 21
ns2 Energy Model . . . . . . . . . . . . . . . . . . . . . . . . . 41 Flat clustering results . . . . . . . . . . . . . . . . . . . . . . . 54 Hierarchical clustering results in the bridge case . . . . . . . . 64 Hierarchical clustering results in the matrix case . . . . . . . . 65
viii
List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 3.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Network architecture . . . . . . . . . . . . . . . . . . . . . . . 8 Flat clustering protocol . . . . . . . . . . . . . . . . . . . . . . 11 Node joins an existing cluster . . . . . . . . . . . . . . . . . . 12 Delegation protocol . . . . . . . . . . . . . . . . . . . . . . . . 14 SUB lost during the process of delegation . . . . . . . . . . . . 15 Hierarchical clustering protocol . . . . . . . . . . . . . . . . . 16 Comparison of dierent simulator packages . . . . . . . . . . . 21 General protocol stack of a node . . . . . . . . . . . . . . . . . 24 Modi ed schematic of a node under the CMU monarch wireless extensions to ns [22] . . . . . . . . . . . . . . . . . . . . . . . 25 Simple RockAgent class collaboration diagram . . . . . . . . . 26 General packet structure . . . . . . . . . . . . . . . . . . . . . 29 Message driven handlers . . . . . . . . . . . . . . . . . . . . . 31 Time driven handlers . . . . . . . . . . . . . . . . . . . . . . . 31 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Flat clustering state diagram . . . . . . . . . . . . . . . . . . . 33 Delegation state diagram . . . . . . . . . . . . . . . . . . . . . 35
4.10 Hierarchical clustering state diagram . . . . . . . . . . . . . . 37 5.1 5.2 5.3 Bridge and matrix topologies with diagonal connection . . . . 40 Isolated nodes number in the bridge case . . . . . . . . . . . . 44 Isolated nodes number in the matrix case . . . . . . . . . . . . 44
ix
5.4 5.5 5.6 5.7 5.8 5.9
Convergence time in the bridge case . . . . . . . . . . . . . . . 46 Convergence time in the matrix case . . . . . . . . . . . . . . 47 System energy consumption regarding to nodes number in the bridge case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 System energy consumption regarding to nodes number in the matrix case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Saved system energy percentage in the bridge case . . . . . . . 50 Saved system energy percentage in the matrix case . . . . . . 51
5.10 System energy consumption regarding to duty cycle in the bridge case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.11 System energy consumption regarding to duty cycle in the matrix case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.12 Recovery time in the bridge case . . . . . . . . . . . . . . . . . 55 5.13 Recovery time in the matrix case . . . . . . . . . . . . . . . . 56 5.14 Convergence time in the 3-level clustering bridge case . . . . . 58 5.15 Convergence time in the 4-level clustering bridge case . . . . . 58 5.16 Convergence time in the 3-level clustering matrix case . . . . . 59 5.17 Convergence time in the 4-level clustering matrix case . . . . . 59 5.18 System energy consumption regarding to node numbers in the hierarchical bridge case . . . . . . . . . . . . . . . . . . . . . . 61 5.19 System energy consumption regarding to node numbers in the hierarchical matrix case . . . . . . . . . . . . . . . . . . . . . 62 5.20 System energy consumption regarding to duty cycle in the hierarchical bridge case . . . . . . . . . . . . . . . . . . . . . . 63 5.21 System energy consumption regarding to duty cycle in the hierarchical matrix case . . . . . . . . . . . . . . . . . . . . . 65 A.1 RockAgent Class Collaboration Diagram . . . . . . . . . . . . 74
x
Chapter 1 Introduction
With the eye-catching development in Wireless Sensor Networks (WSN), there are various emerging applications, such as monitoring structural health, hazardous area surveillance and disaster management. For instance, sensors could be deployed on a bridge to sample vibrations in dierent places and adopt algorithms such as [24] to monitor structural health. In these applications, sensor nodes have the capability of detecting surrounding conditions, such as vibration, temperature and illumination. And these sensors are usually low cost tiny nodes with limited energy and data processing capability, and need to communicate with each other to establish a dedicated network for a prede ned mission. Such applications face several challenges, such as multi-hop communication, large scalability, and how to organize nodes e ciently for long life span. Recently researchers have focused on grouping sensor nodes into clusters. The main idea of clustering is to organize nodes into a cluster structure. Every cluster has a leader and several members, named cluster head(CH) and cluster member(CM) respectively. Normally in a cluster, CMs communicate with its CH and the CH is responsible for the communication with nodes outside the cluster. With clusters, a WSN is able to achieve large scalability, provide reachability, conserve communication bandwidth, stabilize a network topology and aggregate data.
1.1 Related Work
Researchers have designed and developed lots of standards and protocols to solve problems regarding to communication, scalability, energy e ciency and 1
CHAPTER 1.
INTRODUCTION
2
so on. IEEE 802.15.4 [37] has become a popular standard which speci es the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs). Based on the IEEE 802.15.4, speci cations attempt to oer complete solutions to WSN with upper layer supports, such as ZigBee [15], WirelessHART [13] and MiWi [23]. In addition, recently several modi cations [33, 41] of IEEE 802.11 [14] are also available for WSN considering energy e ciency. Several ad-hoc routing protocols have been applied in WSN to provide multihop routing, such as Ad hoc On-Demand Distance Vector (AODV) routing [35], Destination-Sequenced Distance-Vector (DSDV) routing [36] and Dynamic Source Routing (DSR) [29]. Finally, a number of clustering algorithms have been designed for WSNs [32]. Existing clustering solutions can save energy and extend system lifespan by grouping sensor nodes into clusters and employing data aggregation at cluster heads(CH). Clustering has the following advantages. Firstly, clustering originally aims at providing great scalability for WSNs because a network cannot maintain a large number of nodes only with MAC standards and multi-hop routings. Furthermore, clustering could stabilize the network topology and also reduce the maintenance overhead. Moreover, clustering can conserve communication bandwidth because it limits the communications between CMs and a CH within a cluster and reduce the redundant data transmission among sensor nodes. Finally, data aggregation algorithms could be applied on CHs to further reduce the transmission data and relaying messages, thus prolonging the life span of clusters. There are numerous clustering algorithms proposed for WSNs [27, 20, 25, 18, 40, 34, 46, 16, 21, 45, 19, 17, 43]. Usually, these algorithms focus on the following ve features, scalability, fault tolerance, load balancing, energy e ciency and multi-level clustering, but few of them could provide all these features. Algorithms such as [40, 34, 27] usually use random number based mechanisms to select CHs and form clusters. For instance, [40] uses random time and Node ID together to select CHs, [34] counts down a random integer and [27] uses probability to decide CHs. However, such a way to select CHs ignores the residue energy on those nodes, thus causing a good probability of a low energy node selected as a CH. As a CH usually consumes more energy than normal nodes, a cluster with a low energy CH will fail quite soon. Algorithms such as [44, 21] take residue energy of a node and probability together into consideration while selecting CHs. [44] goes through three time phases, Initialization, Repetition, and Finalization phase, to form clusters
CHAPTER 1.
INTRODUCTION
3
and takes residue energy and probability into consideration while deciding CHs in the rst phase. And [21] also considers residue energy and could achieve more well-balanced cluster sizes than [44] in a network. However, they do not specify whether their algorithms provide fault tolerance for CHs and load balancing among nodes. Without fault tolerance for CHs, a single CH failure will result in the failure of its whole cluster, not to mention failures of multiple CHs. And load balancing among nodes could prolong the life span of clusters. Algorithms such as [46, 18, 45, 25] all have the feature of self maintenance and could recover from nodes failure usually by associating a node with multiple CHs or other methods. However, the methods usually result in clustering overlapping, which could complicate the association management and cause extra energy consumption. A better way is to assign a backup CH to deal with CHs failure and reduce the clustering overlapping. Algorithms [20, 16] could form a cluster structure with more than 2 levels. With a multi-level clustering structure, it is possible to apply more complex distributed algorithms in networks and is probably to be more energy e cient. But [20] does not take energy into consideration while selecting CHs, and [16] does not specify whether it supports self maintenance feature to recover from CH failure. Finally, the algorithm [19] could form a network with high average of cluster sizes but [19] does not support multi-level clustering and does not specify whether it takes residue energy into consideration while selecting CHs. Based on the above discussions, few clustering algorithms could take scalability, load balancing, fault tolerance, energy e ciency and multi-level clustering together into consideration. Furthermore, the above mentioned solutions are usually tightly coupled with lower layers or speci c to certain application so that it is di cult to change the lower layer protocols. And due to the constraints of the lower layer implementation and complex hardware details, developers face numerous challenges for application development[26].
1.2 Problem Statement
There are mainly four challenges in WSNs: 1. MAC standards and routing protocols are not enough to e ciently organize a large scale WSN with numerous nodes, especially in the condition that each node sends data to the sink node simultaneously
CHAPTER 1.
INTRODUCTION
4
and periodically. 2. A WSN usually contains a large number of nodes capable of sampling data at high rates and generating huge volumes of data. These huge data consume limited resources on the nodes and often result in redundant data transmission, which consumes bandwidth and battery. In most cases, network communication is the main source of power consumption in WSN [28]. 3. Nodes in WSNs usually have limited battery, which causes heavy energy constraint on WSN applications for long lifespan. 4. Large sampled data may expire during the forwarding process before they reach the sink node due to long latency in wireless transmission, thus resulting in extra consumptions on limited resources in the whole network. In addition, clustering algorithms also faces the following two challenges: 1. Existing cluster algorithms usually focus on certain features while missing other features. Few of them could take scalability, load balancing, fault tolerance, energy e ciency and multi-level clustering structure all into consideration. 2. Existing solutions are usually tightly coupled with lower layers or speci c to certain application so that it is di cult for application layer development as well as lower layer modi cations. In general, in order to solve all the above mentioned problems, there needs a novel clustering algorithm for sensor nodes to aggregate data so as to reduce redundant transmissions, perform localized computation so as to increase non-volatile information throughput, and optimize energy consumption so as to prolong the system lifespan.
1.3 Objectives and Scopes
According to Sec. 1.1, existing cluster algorithms are inadequate to solve the problems mentioned in Sec. 1.2. So, in order to tap into the full the favorable aspects of the existing algorithms while avoiding the unfavorable ones, we introduce a generic novel exible hierarchical clustering algorithm
CHAPTER 1.
INTRODUCTION
5
on middleware layer based on Publish / Subscribe paradigm. The algorithm takes scalability, load balancing, fault tolerance, energy e ciency and multilevel clustering all into consideration. Moreover, our algorithm serves as a middleware-based approach, which hides the low layer details and provides uniform friendly interfaces for the upper layer, thus easing application development. Furthermore, our algorithm is loosely coupled with lower layers, thus capable of working on dierent routing protocols and MAC standards. In addition, with the Publish/Subscribe paradigm, our algorithm could support great network scalability as well as provides topology exibility. And our algorithm includes three protocols, namely protocol, protocol and protocol aiming at constructing a multi-level cluster structure in a WSN from the bottom up.
tion Delegation
Flat Clustering Hierarchical Clustering
Func-
In order to validate the design of this new algorithm and evaluate its performance in a relatively short period with low expense, we decide to simulate this algorithm on a simulator. There are several popular simulators including NS-2 [9], J-Sim [6], OMNeT++ [12] and so on. NS-2 is a well-known, open-source discrete event network simulator popular in academia for its extensibility and plentiful online documentation. J-Sim is a component-based, compositional simulation environment based on the autonomous component programming model. OMNeT++ is also a component-based, modular and open-architecture discrete event network simulator with many simulation frameworks. We also refer to a survey [38], look into and test dierent simulators. Finally, we design, implement and simulate a exible simulation framework for this algorithm on the NS-2 simulator and gain several results considering protocol performance and energy e ciency. Based on our simulation, we optimize key parameters for our algorithm and nd that the performance and the energy e ciency of our algorithm are promising, especially in the bridge topologies.
1.4 Methods
Four main research methods are applied in this thesis. These are:
• Literature review • Simulator survey • Design and implementation • Simulations and results analysis
CHAPTER 1.
INTRODUCTION
6
Literature review builds up a sound foundations for this thesis work. In addition, simulator survey provides the understandings of advantages as well as disadvantages of dierent simulators and helps us select the suitable simulator for our work. Moreover, design and implementation on a simulator provide the basis for simulations. Finally, simulations and results analysis help us to validate and optimize our original design as well as evaluate our algorithm in all aspects.
1.5 Structure of the Thesis
In the following sections, Chapter 2 rst explains our framework for the clustering algorithm including its three protocols. Then, we look into and analyze three popular simulators, J-Sim, OMNeT++ and NS-2 in Chapter 3. In Chapter 4 there is a detailed description of our implementation on NS2. After that, Chapter 5 explicates the simulation criteria and test cases, lists and analyzes the simulation results. Finally, we conclude our work in Chapter 6.
Chapter 2 Clustering Algorithm
In this chapter, we introduce our clustering algorithm, which consists of three protocols, Flat Clustering Protocol, Function Delegation Protocol and Multi-level Clustering Protocol. We give detailed explanations of the three protocols and also show their sequence diagrams. In addition, since we nd some aws during the implementation and simulation, we also make some improvements to the original design. Our clustering algorithm has the following advantages. With our algorithm, the network could form a cluster structure from the bottom up and all nodes are self-adaptive, which means users do not need to specify the role for each node beforehand. When nodes initiate and try to form the structure, they will decide roles and actions by themselves. Moreover, our clustering algorithm is a location-based, Pub/Sub middleware and able to control the formation of clusters. Therefore, it oers more exibility for application developers to adjust the clustering scope and granularity to ful ll the requirements of the application services while developers could also select the lower layer routing protocols and MAC standards according to the real requirements. In addition, our algorithm could form a cluster structure network with fault tolerance and load balancing features because the second function delegation protocol could handle the failure of heads in the structure. Furthermore, since our algorithm supports multi-level clustering structure with 3 or even more level clusters, this kind of multi-level structure could enable the network to be more energy e ciency in some cases according to our simulation in Sec.5.
7
CHAPTER 2.
CLUSTERING ALGORITHM
8
Sink Node
CH(2)
CH(1)
SH(1)
SH(1)
Node
CM(0) CM(0)
CM(0)
CM(0)
CM(0)
CM(0)
CM(0)
Figure 2.1: Network architecture
2.1 Architecture
Generally speaking, our algorithm aims at forming a wireless sensor networks into the following logic cluster structure shown in Figure 2.1. The number in the brackets in the gure represents the level of a node. From left to right, rst there is a single node that does not join a cluster. We consider it is a newly initiated node trying to join a cluster nearby. Then, beside that node, there is a at (2-level) cluster which consists of a level-1 CH (Cluster Head) and two level-0 CMs (Cluster Member). In the at cluster, CMs send data to the CH, and the CH aggregates the received data and sends the merged data to the sink node. In the right part of the gure, there is a multi-level (3-level) cluster composed of two at clusters. The heads of the two at clusters now serve as SH (Sub Cluster Head) and send the aggregated data to their CH instead of the sink node. The level-3 CH further aggregates the data and then sends the merged data to the sink node. Hence, the data ow is from the bottom up in this structure.
2.2 De nitions
Before the introduction of the three protocols, we need to de ne four roles of a node, six message types and three time phases.
CHAPTER 2.
CLUSTERING ALGORITHM
9
Firstly, a node in our clustered network could have 4 roles, , , and . stands for a node which just starts and does not join a cluster. always stands for a level-0 node which has already joined a cluster and sends data to its CH periodically. stands for a node which is the top head for a cluster. It receives all data from its CMs or SHs, aggregates and sends them to the sink node. Finally, stands for a node which is a head but not the top head in a multi-level cluster. A SH receives data from its CMs or SHs, aggregates and sends them to its upper CH or SH.
(Cluster Member) CH (Cluster Head) Node CH SH
Node CM SH (Sub Cluster Head) CM
In addition, our algorithm de nes 6 types of messages:
• ADV: ADV stands for "Advertise". ADV contains the energy, the level, the capability and the location of the sending node. The energy contains the residue energy value of the sending node. The level is the current level of the sending node. The capability tells what kind of data the sending node could provide, for instance, illumination, temperature etc. And the location tag shows the location of the sending node. Nodes only form clusters among the ones with the same location tag. So, when nodes start, they broadcast ADVs to others to exchange necessary information and declare their appearance. • SUB: SUB stands for "Subscribe". A CH usually sends SUB to recruit nodes. SUB also contains the type of data that the CH is interested in so that the receiver could send that kind of data to the CH in the future if it joins that cluster. • PUB: PUB stands for "Publish". There are two cases that a node sends PUB. In one case, when a node receives SUB from a CH, it immediately sends back PUB to the CH to acknowledge its participation to its cluster. In another case, when a CM has entered the stable state, it periodically sends PUB to the CH which contains the interested data. • INV: INV stands for "Invite". When nodes form a cluster, the CH usually selects a node with the highest energy as its backup CH. Then the CH sends INV which contains all the details of its current members to that node. On receiving INV, that node stores the information and becomes BCH (Backup Cluster Head). In case that the CH fails, the BCH could take over the cluster immediately with the previously received information. • NTF: NTF stands for "Notify". It has several options, such as RETIRE etc. Generally speaking, usually this message is sending from a head
CHAPTER 2.
CLUSTERING ALGORITHM
10
to its BCH to notify a certain event.
• ACK: ACK stands for "Acknowledge". Nodes usually send this message to acknowledge the receiving of certain messages, such as PUB, INV and NTF.
Moreover, in order to form a cluster structure by our algorithm, a node usually need to go through three time phases, , and . In time phase, a node usually broadcasts ADVs which contain the energy value of the sending nodes and stores the information of received ADVs. In time phase, CHs usually send SUB messages to recruit members. Other nodes wait for SUB messages, and reply with PUB messages on receiving SUB to con rm its participation in a cluster. On receiving a PUB message, a CH considers the sender as its member and sends back ACK. On receiving ACK, a node considers ACK as the con rmation for its participation and becomes a CM. phase is a stable phase. After nodes have joined a cluster, they all go to DONE phase and perform certain actions periodically depending on their roles. For instance, in DONE phase, a CM periodically sends data to its CH.
T1 T2
T1 T2
DONE
DONE
2.3 Flat Clustering Protocol
Flat Clustering Protocol is the basic protocol for our clustering algorithm and forms a network into a at (2-level) clustering structure. Figure 2.2 shows the process of the basic at clustering protocol. When nodes initiate, they immediately go into T1 phase. Then, during T1 phase, nodes broadcast ADV messages. An ADV message contains four kinds of important information, the location, the level, the capability and the energy value of the sending node. The location tag enables location based clustering. A node only receives messages with the same location tag as its own. Therefore, a cluster only contains nodes with the same location tag. In addition, for the at clustering protocol, a node in this time phase only receives ADVs with the same level as its own. Furthermore, the capability contains the capabilities of the sending node, which could be useful for the application services. For instance, if a node could sample temperature and illumination, the capability will contain these two types. Moreover, the energy value represents the residue energy of a sending node. When a node receives an ADV message, it caches all the information. And when T1 phase times up, nodes decide whether it could be a CH according to the residue
CHAPTER 2.
CLUSTERING ALGORITHM
11
Node
Node
Node
Periodically Broadcast ADV Periodically Broadcast ADV T1
CH
SUB SUB T2 PUB PUB ACK
CM
ACK
CM
Figure 2.2: Flat clustering protocol
energy locally. If the energy value of a node itself is the largest among all the energy values it receives, it will promote to be a CH. Then, all nodes go into T2 phase. In T2 phase, in order to recruit members, a CH rst sends SUB messages to all the nodes that it has received their ADV messages during T1 phase. The SUB message contains the capabilities (types of data) that the CH wants to subscribe. Upon receiving a SUB message, the node caches the SUB information and sends back a PUB message with its own residue energy. Upon receiving the PUB message, the CH considers the sender has become its member and sends back an ACK message for acknowledgement. Upon receiving the ACK message, the node now knows it has already joined the cluster and becomes a CM. When T2 times up, all nodes go to DONE phase. DONE phase is a stable phase and it has no time limit. During DONE phase, CMs send data to its CH and CHs aggregate the received data and send the merged data to the sink node. For this basic at clustering protocol, we have improved the original design in the following aspect. In the original design, there is no ACK message
CHAPTER 2.
CLUSTERING ALGORITHM
12
from CH to nodes for acknowledgement. We add this ACK due to the reason that any message could be delayed or lost during the transmission. Without ACK, a node considers it has already joined the cluster and become CM when it receives SUB. If the PUB message is lost or does not arrive at the CH in time during T2 phase, the CH actually does not recruit this node. Then in DONE phase, the CM sends data to the CH but the CH discards the data because it is not its member. And currently, we have no mechanism for CH to inform CM this issue. We could design such a mechanism but it delays that node to realize this issue. The node has already been in DONE phase for some time and needs to go back to T1 phase again, thus increasing the time for forming the structure. What's worse, the node may not need to send data immediately in DONE phase, thus dramatically increasing the detection time. We can solve this issue by an extra ACK. In this case, a node only con rms its participation on receiving ACK from its CH. So, if the PUB is lost or does not arrive in time, the node will directly go back to T1 phase when T2 phase times up because it will not receive ACK. Moreover, if the ACK is lost, the case is that the CH considers the node has joined its cluster but actually not. In this case, the CH could recruit the node immediately when it receives the ADV of the node again. And if the node joins another cluster, the CH could purge the record for this node by a timeout mechanism.
Node Broadcast ADV T1 SUB PUB ACK
CH
DONE
T2
CM
Figure 2.3: Node joins an existing cluster
CHAPTER 2.
CLUSTERING ALGORITHM
13
Besides of the condition in Figure 2.2, in a network there exists the situation that a node could join an existing cluster as shown in Figure 2.3. In such a case, on receiving an ADV, if the CH could recruit more members, it sends back a SUB message. On receiving the SUB message, the node immediately switches from T1 phase to T2 phase and replies with a PUB message. Then the CH replies with ACK and recruits this node. Finally the node receives the ACK message and becomes a CM. Moreover, if a SUB, PUB or ACK message is lost during the transmission, after T2 times up the node will go back to T1 phase and try to join a cluster again. We also improve the original design in this condition. A node will go directly into T2 time phase if it receive a SUB message from a CH during T1 time phase. In the original design, during T1 phase, a node caches or blocks SUB messages instead of directly going to T2 phase. Obviously, either caching or blocking SUB messages will results in the delay or even the failure for a node to join an existing cluster. So the improvement both exceeds the time and increases the probability for forming clusters. And we also apply this improvement to the basic at clustering process in Figure 2.2.
2.4 Function Delegation Protocol
In WSNs, nodes are prone to various failures, such as loss of connectivity due to low quality communications, battery depletion, and malfunction hardware owing to harsh environment. Usually, deployment of redundant nodes could relieve the in uence of nodes failure. However, a cluster network could not tolerate the failure of cluster heads. The failure of a single CH will result in the data loss of a whole cluster, not to mention the failure of multiple CHs. Moreover, CHs receive more messages and the data aggregation causes more computing overhead on CHs, thus resulting in faster battery depletion on CHs than other nodes. As a result, considering the fault tolerance for CHs and the load balance for energy consumption among nodes, our clustering algorithm includes the second protocol protocol as shown in Figure 2.4. Generally speaking, a CH selects a Backup Cluster Head (BCH) among its members. Not only could a BCH detects the failure of its CH and takes over, but also the CH could inform the BCH to take over due to the low energy itself. As a result, the protocol enables nodes in a cluster to take turns to be CH for the balance of energy consumption among nodes as well as prolong the lifespan of a cluster.
Function Delegation
Figure 2.4 shows the process of the Function Delegation protocol. After nodes form a cluster, a CH selects the one with the highest energy among its
CHAPTER 2.
CLUSTERING ALGORITHM
14
CH DONE INV ACK DONE
CM
CM DONE
CM DONE
BCH
NTF(RETIRE) ACK(BCH_START) T1
Node
T2
CH
SUB
Node
SUB T2 PUB PUB ACK
T2
Node
T2
CM
ACK DONE INV ACK
CM BCH
Figure 2.4: Delegation protocol
members, and sends an INV message to invite it to be BCH. The INV message contains all the information of the members in the existing cluster. Upon receiving the INV message, the CM stores all the information, becomes BCH and sends back ACK for acknowledgement. Then the cluster works normally for a relatively long time. During that time, the CH sends heartbeat packets to BCH periodically so that the BCH could track the aliveness of its CH. And if there are changes among cluster members, the CH sends updates to the BCH for updating member information. Then, two cases could trigger the BCH taking over process. In one case, the loss of several sequential heartbeats could trigger the BCH taking over. In another case, due to its low energy, the CH could send a NTF(RETIRE) message to the BCH to inform it to take over as shown in Figure 2.4. The NTF message contains the option of RETIRE. Upon receiving the message, the BCH sends back ACK and promotes to be CH. Then it goes to T2 phase and sends SUB messages to the existing members in the cluster. The BCH has the information of these members because the previous INV message from the former CH contains
CHAPTER 2.
CLUSTERING ALGORITHM
15
CH DONE NTF(RETIRE) ACK(BCH_START) T1
BCH DONE
CM DONE
CM DONE
Node
T2
CH
SUB
Node
SUB PUB ACK T2
T2
CM
SUB (Resend)
Node
PUB ACK DONE INV
T2
CM
ACK
BCH
Figure 2.5: SUB lost during the process of delegation
the information. Then the process continues as the at clustering protocol. In addition, the retired CH could either try to join a cluster or shut down itself according to real requirements. For the Function Delegation Protocol, we also improved the original design in the following aspects. The original design does not specify the time phase of BCH during the taking over process. In our modi cation, we design it to go back to T2 phase to simplify the design. Furthermore, the original design only enables the BCH to send SUB once and does not take the SUB lost into consideration. In our modi cation shown in Figure 2.5, we think it is very important to resend a SUB message if the BCH does not receive replies because besides of recruiting members, in this case the SUB message also has the function to inform a CM the failure of its CH. If a CM does not receive a SUB from the BCH, it will still send data to the original CH which might have already been down. By implementing the resending mechanism for SUB, we would like to ensure CMs also notify the failure of the CH immediately.
CHAPTER 2.
CLUSTERING ALGORITHM
16
CH(L)
CH(L)
CH(L)
Periodically Broadcast ADV Periodically Broadcast ADV T1 Local Delegation SUB PUB T2 ACK PUB
CH(L+1)
SUB
SH(L)
ACK
SH(L)
INV DONE ACK
BCH (L)
Figure 2.6: Hierarchical clustering protocol
2.5 Multi-Level Clustering Protocol
In WSNs, a 2-level clustering structure has its bene ts, such as fast speed of forming the structure and energy saving. However, if an algorithm could form a clustering structure with more than 2 levels, there could be more bene ts. Firstly, in a relatively large scaled network, with a 2-level clustering structure, there are many CHs sending data to the sink nodes through long multi-hop routings at almost the same time, thus causing tra c jamming especially at the sink node. With a 3-level or 4-level clustering structure, a higher level CH could further aggregate several messages to one and send it to the sink node, thus reducing the number of messages received at the sink node and relieving the tra c jamming. Furthermore, instead of sending messages through long multi-hop routes, SHs could send it to its nearby upper level CH and CHs could aggregate messages into one and send them through relatively short routes. In such a way, the network could further reduce the long multi-hop transmissions and be more energy e ciency.
CHAPTER 2.
CLUSTERING ALGORITHM
17
Therefore, based on the above two protocols, we design the third protocol protocol. The basic idea is that after nodes form at clusters and CHs select BCHs, the level-1 CHs of these clusters go through a similar process as the at clustering protocol to form multilevel clusters. Figure 2.6 shows the process and the numbers in the brackets represent the level of a node. Firstly, CHs(L) go back to T1 phase and also broadcasts ADV messages. On receiving an ADV message, a CH(L) checks the location and the level. The CH(L) only tries to form a higher level cluster with the same level and location CHs. Then, after T1 times up, a CH(L) also decides locally whether or not it could be a CH(L+1) for this higher level cluster based on self residue energy and then go to T2 phase. If it could be, instead of sending SUBs immediately, it rst executes the delegation process. It sends NTF(RETIRE) to its own BCH for retirement. After receiving ACK from the BCH, which means the BCH will take the place of it in the existing cluster, the CH(L) promotes to be CH(L+1). Then the process is almost the same as the at clustering protocol except that if CHs join the multi-level cluster of CH(L+1), they become SH instead of CM. When the multi-level cluster has been formed, the CH(L+1) also invites a SH(L) to be its BCH.
Multi-Level Clustering
Furthermore, the process of BCH taking over in a multi-level clustering is dierent from the at one. The BCH not only needs to recruit members in the existing cluster, but also needs to inform the upper level CH for its taking place of the original SH if necessary.
Chapter 3 Current State of Simulator
With the eye-catching development in wireless network elds, there appear more and more algorithms and protocols. Some of them aim at medium or large scale networks while some of them are speci c to applications and services. In order to validate a protocol logic as well as test its performance, the direct way is to implement and run it on real devices. However, developers usually have limited devices and developing on real hardware takes long time. Therefore, researchers prefer to use software simulators to simulate the protocol and shorten the developing time. As a result, there appear several famous simulators, such as NS-2, J-Sim and OMNeT++. For our simulation, the simulator needs to provide the following supports.
• Implementation of IEEE 802.11 or 802.15.4 standard • Implementation of multi-hop routing protocols • Energy Model to track the energy consumption of each node
Based on the above three criteria, we look into three simulators, J-Sim, OMNeT++ and NS-2, in the following part of this chapter and select the one suitable for our protocol simulation.
3.1 J-Sim
"J-Sim is a component-based, compositional simulation environment." [6].
The concept of Autonomous Component Architecture (ACA) is its core idea, 18
CHAPTER 3.
CURRENT STATE OF SIMULATOR
19
which is similar to software integrated circuit (IC) design architecture. Because the programming language for J-Sim is Java, which supports a good Object Oriented (OO) programming model, J-Sim could take advantage of it and use the concepts such as interface, inheritance and so on to realize an ACA-based simulator. In J-Sim, there is a concept called "Contract", which speci es how an initiator (caller) and a reactor (callee) ful ll a certain task. And contracts could be further divided into two categories: component contract and port contract. For component contract, a component includes several classes for realizing functions, and could be comparable to an IC chip in hardware. For port contract, a component has several ports and components usually communicate with each other through these ports, which are also comparable to Pins of an IC chip. With component and port, J-Sim could be exible for users to use dierent components and for developers to develop their own components. And most of these components could work with each other through ports. Besides of Java for realizing functions in J-Sim, for simulations J-Sim implements "Script" to organize all the components and de ne how the whole system should work. In the latest version of J-Sim, it implements TCL/Java, an extension to core TCL, as its script language. If we look into J-Sim packages, we can nd it provides a Wireless Package and a Sensor Network Package that could be useful if we want to implement and simulate our protocols on J-Sim. In the wireless package, J-Sim provides the implementation of IEEE 802.11 MAC and routing protocols such as AODV, GPSR [30] etc. However, there is no energy model in this package. Instead, in the Sensor network package, J-Sim also provides the implementation of IEEE 802.11 MAC and an energy model, but there is no routing protocol. Therefore, neither of the two packages could meet all our three criteria. And Java is a two-edged sword for a simulator. On one hand, it is easy and fast to implement a protocol by using Java compared with other languages, such as C/C++. On the other hand, Java program tends to have a lower performance than programs in C/C++. However, we need to simulate our protocol for a relatively large network and for long time. The performance of a simulator is also quite important to us. Consequently, J-Sim is not a good option for us.
CHAPTER 3.
CURRENT STATE OF SIMULATOR
20
3.2 OMNeT++
OMNeT++ is a relatively new simulator, which "is an extensible, modular,
component-based C++ simulation library and framework, with an Eclipsebased IDE and a graphical runtime environment." [12] It uses C++ as the
programming language to realize protocol logics and adopts NED as a script language for setting up simulation environment. There are several projects going on for developing frameworks on OMNeT++, such as INET [3], INETMANET [4], Mobile framework [8], MiXiM [7] and Castalia [2]. If we look into these frameworks, only Castalia and INETMANET could be useful for our simulation. Castalia provides several MAC standard implementations, such IEEE 802.15.4 CSMA/CA, T-MAC [39], S-MAC [42] and so on. However, Castalia only provides simpleTreeRouting and multipathRingsRouting [1], which is not enough for our simulation. For the INETMANET framework, it provides both 802.11 and 802.15.4 MAC implementations, several routing protocols, e.g. AODV, and the energy model. However, the implementation of IEEE 802.15.4 and the energy model is still under test, which could be unreliable. Therefore, the INETMANET framework in OMNET++ could be a backup option for our simulation if we cannot nd a better one.
3.3 NS-2
The Network Simulator - ns-2 is a famous and long-lived simulator. It started as a variant of REAL network simulator [31] from 1989 and evolved during the past few years. Now NS has version 2 and version 3 available online. Since ns-3 [11] is relatively new and still under development, we only take ns-2 into consideration. NS-2 is also an open-source discrete event network simulator which uses C++ as its programming language and adopts TCL as its script language. Usually developers uses C++ to program the protocol logic in ns-2 and users use TCL to write scripts, which serves as "glue" to combine several protocols and form the simulation environment. In addition, since ns-2 has evolved for a long time, it is also popular in academia for its extensibility and plentiful online documentation. And because ns-2 uses C++ as programming language, its performance is better than those written in Java. If we look into the ns-2 all-in-one package, it basically provides the implementation for both IEEE 802.11 and 802.15.4 standards, routing protocols such as AODV, DSDV and DSR, and the energy model. Therefore, ns-2
CHAPTER 3.
CURRENT STATE OF SIMULATOR
21
could also be a good option for our simulation.
3.4 Comparison
Now we have looked into three simulators and known about their advantages as well as disadvantages. We conclude our ndings in Figure 3.1 and Table 3.1.
Figure 3.1: Comparison of dierent simulator packages
Simulator Development Community Docs & Extension Tools Scale Performance Dev. Di culty
J-Sim Closed Few Some Some Medium Slow Easy
OMNeT++ Ongoing Some Some Some Large Fast Medium
NS2 Ongoing Some Many Many Medium Fast Hard
Table 3.1: Comparison of dierent simulators J-Sim is not a good option for our simulation because neither of its two packages meets our three criteria. For OMNeT++, Castalia is not a good option because it has poor routing protocol support. INETMANET meets all three criteria but the IEEE 802.15.4 implementation and energy model are still under test, which could be unreliable. So INETMANET could be a backup option if we cannot nd a better one. NS2 all-in-one package
CHAPTER 3.
CURRENT STATE OF SIMULATOR
22
provides all the necessary packages and meets our three criteria. And it has abundant documentations and extension packages. However, it is more di cult to develop a protocol on ns-2 than on other two simulators and ns-2 only uses single thread when running one simulation. We could spend some time on learning ns-2 and use script to run several simulations simultaneously to exceed the simulation process. Therefore, we nally decided to develop and simulate our protocol on ns-2 simulator.
Chapter 4 Implementation
In this chapter, we give a detailed description of how we implement our algorithms on ns-2 platform. Sec. 4.1 gives a general introduction to the protocol stack, and describes the NS-2 platform and how we hook our protocols with NS-2. Then, we explain several important data structures in our implementation in Sec. 4.2. Next, Sec.4.3 describes the several key functions of the implementations. Finally, in Sec. 4.4, 4.5 and 4.6, we explain all the implementation details of the three protocols.
4.1 Protocol Stack and Platform
Figure 4.1 shows the protocol stack of our implementation and simulation. From the bottom up, nodes communicate with each other through a wireless channel. Then, if we look into a node, it has the Wireless Physical Layer as its network interface. Above on it, we could use either IEEE 802.11 or 802.15.4 as the MAC layer of a node. Above on the MAC layer there is the IP layer. On the IP layer, we rst adopt certain routing protocols to provide multi-hop routing support, for example, AODV, DSR etc. Finally, we implement our protocols on the IP layer with the routing support. This protocol stack is quite e cient for our implementation because it provides routing supports and does not use transport layer protocols, thus reducing the overhead in the packet head. Furthermore, we implement and simulate our protocol on ns-2.29 all-in-one package [10]. And if we look into our protocol stack on the ns-2 simulator, Figure 4.2 shows its structure. In the gure, each square represents a class which implements certain protocols or functions. And in the simulation, 23
CHAPTER 4.
IMPLEMENTATION
24
Clustering Protocol Routing protocols IP Layer 802.15.4/802.11 WirelessPhy Node Wireless Channel
Figure 4.1: General protocol stack of a node
TCL scripts serves as "glue" to "mix up" these classes and also speci es the simulation environment. In Figure 4.2, from bottom up rst ns-2 has the channel class for dealing with the wireless transmission among all nodes. Above on it, each node has the NetIF class serves as the wireless physical layer. The NetIF could call Radio Propagation Model and Energy Model during the simulation. In our simulation, we use the two-ray ground re ection as the radio propagation model and also use energy model for tracking energy consumption. Then, the up target of the NetIF is the MAC class. In our simulation, we use the class that implements the IEEE 802.15.4 standard. Next, between the LL (Link Layer) class and the MAC, there is an IFq class which could implements certain queue mechanisms. In our simulation, we use the drop tail queue and it could cache at most 50 packets. Moreover, above on the IFq, there is the LL class which could also call the ARP class. The ARP class implements a basic ARP protocol. Next, after addr demux and port demux in the gure, we rst have the RTagent (Routing Agent) working on port 255 to provide routing support. In our simulation, we use the AODV routing protocol for all the simulations. Then, with the routing support, we implement our protocols in the Rock Agent class, which directly inherits the Agent class in ns-2. In addition, our Rock Agent class could also directly get or modify the self energy value in the energy model, which is a cross layer implementation.
CHAPTER 4.
IMPLEMENTATION
25
Rock_Agent port demux IP address entry_ addr demux defaulttarget_ RTagent (AODV) 255
SELF_ENERGY
uptarget_ LL downtarget_
arptable_ ARP
IFq downtarget_
Wireless Node
Radio Propagation Model
mac_
MAC
uptarget_ uptarget_ energy_model_
downtarget_ propagation_ NetIF
energy_model
channel_
uptarget_
Channel
Figure 4.2: Modi ed schematic of a node under the CMU monarch wireless extensions to ns [22]
CHAPTER 4.
IMPLEMENTATION
26
Figure 4.3: Simple RockAgent class collaboration diagram
4.2 Data Structure
Before the descriptions of our data structures, we rst look into ns-2. The implementation of ns-2 is totally based on Object Oriented Programming (OOP). OOP uses objects to design applications and dierent design patterns could be applied in programs. In this way, a program is easy to understand and has great exibility for further extension. This kind of design is suitable for large scaled software and the code size is relatively large. However, we decide not use such a method to implement our algorithm because after the implementation on the ns-2 simulator, in the future we would like to port the implementation to the real hardware devices, which has limited processing capability and memory. So, considering the limited capabilities of the hardware, we have to give up the design patterns and implement our algorithm in a way similar to procedure oriented programming, which has better performance and smaller code size compared with OOP. Therefore, we implement protocol logics and most functions in a single class named RockAgent. Figure 4.3 shows the collaboration and relationship among the classes and
CHAPTER 4.
IMPLEMENTATION
27
data structures in our implementation. For more details about the classes and functions, please refer to Appendix A.
• RockClass: public TclClass
RockClass inherits the TclClass, which serves as a shadow class in TCL during the running time of simulations.
• RockAgent: public Agent
RockAgent is the main class for our implementation. We implement our algorithm in this class. And all the following classes are its friend classes.
• Rock State Timer: public TimerHandler
Rock State Timer inherits the TimerHandler class and is responsible for T1 and T2 phases time-up events. In ns-2, the classes inheriting TimerHandler could serve as a timer for its protocols. Basically, such a class has the functions to register or cancel itself on the time schedule for a certain period and has another expire function as a callback function for the time schedule. For instance, Rock State Timer could register itself in 2 seconds for T1 phase. After 2 seconds, the expire function of Rock State Timer will be called and execute the actions for T1 timing up. In this way, ns-2 could realize the time driven events.
• Rock PrBrADV Timer: public TimerHandler
Rock PrBrADV Timer is responsible for periodically broadcast ADV messages during T1 phase.
• Rock KeepAlive Timer: public TimerHandler
Rock KeepAlive Timer is the timer registered as soon as a node goes into DONE phase. It is responsible for periodical tasks in DONE phase. Dierent roles of nodes could have dierent tasks. For instance, a CM usually needs to send data to its CH. A BCH also needs to check the aliveness of its CH periodically.
• Rock HDADV Timer: public TimerHandler
CHAPTER 4.
IMPLEMENTATION
28
Rock HDADV Timer is responsible for blocking one-level less ADV messages. When a CH is in DONE phase and its cluster members do not reach the maximum cluster size, a CH could still listen for one-level less ADV in order to recruit new members. If the number of received ADV nodes plus the number of cluster members is more than the number of maximum cluster size, we register this timer and blocks receiving any more one-level less ADV. After the registered time, the CH could again listen for one-level less ADV if its cluster does not reach the maximum cluster size. In this way, we could control the cluster size and reduce the unnecessary transmissions and delays. For instance, if a CH could recruit only one more member but it receives two ADVs from two nodes almost at the same time. If it replies to all of them, one of them could not join the cluster and have to go another round. By our method in this case, the cluster head blocks receiving one level less ADV after it receives the rst ADV. And another node does not talk with this cluster head and could join another cluster.
• Rock Timeout Timer: public TimerHandler
Rock Timeout Timer is responsible for packet retransmission. For instance, if a CH sends an INV message to a CM, it will register this timer for a certain period and wait for an ACK. If the CH does not receive an ACK for the INV within the registered period, the callback function for the timer will resend the INV message again. Furthermore, a node in our protocol usually needs the following structures and tables to store information.
pro le t is a table that stores all the self information, such as its role, energy,
time phase etc. Moreover, it also contains ags for switching between states.
ngb table, ngb lvl table, sub table, pub table and backup table have the same structure of node table t composed of node entry t. ngb table and ngb lvl table
are responsible for storing the received same level and one-level less ADV information respectively. sub table contains the information about self head and pub table stores the information about members of a CH. A BCH stores the received INV information in a backup table.
fwd table has the structure fwd table t composed of fwd entry t. It is responsible for forwarding broadcast ADVs. And rock headinfo is responsible for the storage of head information on the sink node.
Finally, we de ne our packet structure as shown in Figure 4.4. We do not specify the bytes for each item because these items could have dierent bytes according to dierent implementation platforms and hardware. In general,
CHAPTER 4.
IMPLEMENTATION
29
General Packet Structure Type Id Seq Level Location Length Payload
ADV Packet ADV Id Seq Level Location Length
ADV Payload Capability Energy
SUB Packet SUB Id Seq Level Location Length
SUB Payload Interest_nu Interests[] m
PUB Packet PUB Id Seq Level Location Length
PUB Payload Result_nu m Results[]
Results Item Structure Type Value Quality
INV Packet INV Id Seq Level Location Length
INV Payload Number Backup table[]
Backup Table Structure Id NTF Packet NTF Id Seq Level Location Length Addr Level Energy Capability Location Seq NTF Payload Ntf_option Ntf payload ACK Payload Id Seq Level Location Length ACK_Seq ACK_Type
ACK Packet ACK
Figure 4.4: General packet structure
CHAPTER 4.
IMPLEMENTATION
30
there are six types of packets as we de ne in our algorithm and every type of packets has the following same items: type, id, seq, level, location and length. Type represents the type of a message. Id is the identi cation number of the sending node. Each node in the network should have a unique id. Then, Seq is the sequence number of the current packet. Level contains the level value of the sending node. Next, Location is a number pre-con gured on each node. Only the nodes with the same location number could form clusters. Finally, Length represents the length of the payload. Moreover, for each type of messages, we de ne dierent payloads. The ADV payload contains the capability and the residue energy value of the sending node. Then, the SUB payload has an array that contains the types of data that the sending node wants to subscribe, and the total number of records in the array. Next, in the PUB payload, there is a "result num" item representing the total number of records in the following results array. In the results array, each record contains three items, type, value and quality, which are useful to application services. Moreover, the INV payload contains the "Num" item that shows the total number of records in the following backup table. Each record of the backup table usually contains the information of a node, such as its ID, address, level and so on. In addition, the NTF payload contains the "ntf option" and "ntf payload" if necessary. The "ntf option" represents the type of NTF, e.g., RETIRE. Finally, the ACK payload has the "ack seq" and "ack type". The "ack seq" is the sequence number of the packet that the ACK message wants to acknowledge. And the "ack type" is the type of the acknowledged packet.
4.3 Main Functions
Because our algorithm includes two types of events, Message Driven Events and Time Driven Events, the implementation also includes functions for dealing with these two types of events. Firstly, we have the following message driven event handlers as shown in Figure 4.5. Basically, our RockAgent class inherits the Agent class which has a virtual function called recv(). When a packet arrives, the program will call this function for dealing with the packet. The RockAgent class overrides the recv() function and this function serves as the basic message driven event handler. Then, the recv() calls one of the 6 message handlers according to the type of the received message. There are 6 message handlers, ADV, SUB, PUB, INV, NTF and ACK handlers dealing with dierent types of messages respectively.
CHAPTER 4.
IMPLEMENTATION
31
recv
ADV
SUB
PUB
INV
NTF
ACK
Figure 4.5: Message driven handlers
State_update
T1_handler
T2_handler
Done_handler
Figure 4.6: Time driven handlers
Besides of the message driven event handlers, the implementation also includes the following time driven event handlers as shown in Figure 4.6. The state update function is the main time driven handler. When a node switches from one time phase to another time phase, it calls the state update. Then, based on the current time phase, state update calls T1 handler, T2 handler, or Done handler respectively. Moreover, the above functions are not enough to deal with all time driven events. The implementation also includes the following timers in Figure 4.7. Generally speaking, these timers register a time point in the future. When the program arrives at that time point, it calls the expire function of the timer. The expire is a virtual function of TimerHandler class and our timers inherit the TimerHandler class and override its expire function. Then, the expire function calls dierent callback functions in the RockAgent Class respectively. And we have explained the main usages for these timers in the descriptions of the main classes in Sec. 4.2.
CHAPTER 4.
IMPLEMENTATION
32
Rock_State_Timer::expire
Rock_PrBrADV_Timer::expire
Rock_HDADV_Timer::expire
RockAgent::T1_time_up
RockAgent::T2_time_up
RockAgent::Send_ADV
RockAgent::hd_adv_timer_callback
Rock_KeepAlive_Timer::expire
Rock_Timeout_Timer::expire
RockAgent::keep_alive
RockAgent::timeout_callback
Figure 4.7: Timers
4.4 Flat Clustering
We design the 3 protocols respectively and this section includes the implementation details for the at clustering protocol. Figure 4.8 shows the state switching of a node in the at clustering protocol. After the initialization, a node goes into state. In that state, the node broadcasts and receives ADV messages. Upon receiving an ADV message, the node stores or updates the sending node information in its ngb table. Then, when T1 times up, the node determines whether it is CH or not locally. On one hand, if it is a CH, it goes to state and recruits its members by sending SUB messages. When receiving the PUB message, the CH deletes the record of the sending node from ngb table and stores its information in pub table. Therefore, pub table contains all the information of its members. On the other hand, if the node is not a CH after T1 phase, it goes to state. In that state, the node waits for a SUB message and replies with a PUB message. We implement the FCFS (First-Come, First-Served) mechanism for SUB. In other words, the node only replies to the rst coming SUB message in T2 phase. Then, when receiving the ACK message from the CH, it stores the information of the CH in sub table and becomes a CM. Then, after T2 times up, CHs that succeed in recruiting members will clean their ngb table and go to state while CMs that have joined a cluster will clean their ngb table and go to state. When a CH is at phase, it also listens for ADVs and recruits members. Finally, nodes in these two
(T1, Node)
(T2, Head)
(T2, Node)
(Done, Member)
(DONE, Head) (DONE, Head)
CHAPTER 4.
IMPLEMENTATION
33
Send/Recv ADV
T1, Node
No member
T1 time up T2 time up, still Node, not reach Retry Limit
Send SUB
Recv ADV, Reply SUB
Determine CH
CH
T2, Head
T2 time up
Has member
Done, Head
Not CH
Recv SUB, Reply PUB Recv PUB, Reply ACK T2 time up, no member, reach Retry Limit Recv PUB, Reply ACK
T2, Node
Recv SUB, Reply PUB
T2 time up, still Node, reach Retry Limit
Done, Node
Recv ACK T2 time up
T2, Member
Done, Member
Figure 4.8: Flat clustering state diagram
states start to work according to the requirements of upper layer application services. In addition, in order to exceed the clustering process and increase the probability of successful clustering, when a node at state receives a SUB message, it immediately goes to and replies with a SUB message. Moreover, it is possible that after T2 times up, a node at state does not receive SUB or ACK, and a node at state is not able to recruit any member. In these conditions, nodes roll back to state and try another round to join a cluster. Furthermore, the is the maximum rounds that the node could retry. And this value could be adjusted according to dierent situations. However, it is still possible that after reaching the retry limit, a node still cannot join a cluster. The node will then go to state and send data directly to a sink node periodically. We de ne such a kind of nodes as . In our simulations in Chapter 5, we control the percentage of such a kind of nodes to be less than 5%.
Node) (T1, Node) Retry Limit
(T1, Node) (T2, Node)
(T2, (T2, Head)
(Done, Node)
Isolated Nodes
Therefore, after the at clustering process, a node nally goes to the following
CHAPTER 4.
IMPLEMENTATION
34
three stable states, , and . In Done phase, these nodes perform dierent actions respectively according to their roles. nodes send sampled data to its head. nodes aggregate data and send them to the sink node. And nodes directly send sampled data to the sink node.
(Done, Head) (Done, Node)
(Done, Head) (Done, Member) (Done, Member)
(Done, Node)
4.5 Function Delegation
The aim of the Function Delegation Protocol is to provide fault tolerance for CHs, load balance among cluster members as well as the basis for the multi-level clustering protocol. Figure 4.9 shows the state switching of the function delegation protocol. From the point of a CH, when it goes into the state, it selects its BCH with the highest energy among its members. Actually, the CH looks into its pub table and selects the record with the highest energy. Then, the CH sends an INV message to that CM to invite it as its BCH and waits for ACK. If the CH gets ACK in time, it considers the selection of BCH successful. Then, the cluster runs in a stable state for quite a long time until the CH residue energy is below a certain value. The value could be adjusted according to dierent situations. Next, the CH has low energy and sends a NTF(RETIRE) message to its BCH to trigger the BCH taking over process. After receiving an ACK message from the BCH, it rolls back to and tries to join a cluster as a normal member.
(Done, Head)
(T1, Node)
Besides of the above normal process, we also take error handling into consideration. One case is that the CH may not be able to receive an ACK after it sends an INV message to a node. In this case, the CH waits for a certain period and resends the INV. If times of resending the INV reaches a certain value (Retry Limit), the CH deletes this record from its pub table and starts the process for selecting a new BCH. If the CH continues such a process and nally there is no record in the pub table, the CH rolls back to to try to join a cluster. Another case is that when the CH wants to retire, it may not be able to receive the ACK for the NTF(RETIRE). The CH also resends the NTF and waits for the ACK. If the resending times reach the retry limit, the CH will delete this BCH record from its pub table and start to select a new BCH. After selecting a new BCH, it will also send NTF to the new BCH and go to .
(T1, Node)
(T1, Node)
From the point of a BCH, the process is relatively simple. Before the BCH becomes a BCH, it is just a normal member. It may either in DONE phase or
CHAPTER 4.
IMPLEMENTATION
35
Send INV, wait ACK Reach INV Retry Limit, delete this record, try another record.
ACK lost, Resend INV / NTF Reach Retry Limit and No CM || Recv ACK(BCH_START) Recv ACK
Done,Head
Reach NTF Retry Limit, delete this BCH, Select New BCH.
T1, Node
Energy low, send NTF(RETIRE)
Delegation Head State Diagram
Recv INV, reply ACK
Done/T2, Member
Done/T2, Member(BCH)
Recv NTF (RETIRE) reply ACK || 3 DET Lost BCH takeover
T2, Head
Delegation BCH State Diagram
Figure 4.9: Delegation state diagram
T2 phase and when it receives an INV message from its CH, it stores the INV information in its backup table, immediately sends back ACK and considers itself as a BCH. Then, two cases could trigger the BCH taking over process. One case is that the BCH receives a NTF(RETIRE) from its CH. Another case is that the BCH detects the failure of the CH by loss of 3 sequential heartbeat packets (DET) from the head. In the normal case, the CH sends a heartbeat packet (DET) to the BCH every duty cycle. The threshold value of sequentially loss of heartbeat packets could be adjusted according to real conditions. In both two cases, the BCH starts the taking over process and goes into state to recruit the original members in the cluster.
(T2, Head)
Therefore, the Function Delegation protocol could provide the 2-level clustered network with fault tolerance and load balance features and also serves as the base for the multi-level clustering protocol.
CHAPTER 4.
IMPLEMENTATION
36
4.6 Multi-Level Clustering
With the Flat Clustering protocol and the Function Delegation protocol, our algorithm now could form a WSN into a at (2-level) clustering structure with fault tolerance and load balance supports. However, the algorithm still lacks the feature of forming network into multi-level (more than 2 level) clustering structure. That kind of structure bene ts the energy e ciency and further relieves the tra c jamming at a sink node, thus increasing the life span and the scalability of WSNs. In addition, dierent level heads could have dierent tasks and application developers could implement more complex algorithms in a multi-level tree structure. Therefore, we propose the third protocol protocol.
Multi-Level Clustering
Figure 4.10 shows the state switching of the multi-level clustering structure. The upper part of the gure shows the normal at clustering state switching with slight modi cations. The lower part shows the state switching for heads to forming a multi-level clustering structure. After initialization, all nodes rst try to form a at (2-level) clustering structure according to the at clustering protocol. There is a slight dierence when a level-1 CH goes into Done phase. If the network aims at forming a multi-level (more than 2 levels) clustering structure, instead of going to state, a CH goes to state, selects a BCH and then goes to state.
(Done, Head)
(Done, SubHead) (T1, SubHead)
Then, it comes to the lower part of the gure. Basically, in order to form a higher level cluster among SHs, a SH goes through a process similar to the at clustering protocol. And the selection of a head is still based on the residue energy. However, there are several dierences. After T1 times up and the SH determines itself as the top head for the multi-level cluster, it adds its level and goes into state. In that state, instead of recruiting members immediately, it rst sends NTF(RETIRE) to its BCH to trigger the taking over process in the current cluster so as to let the BCH to take over its position. After it receives ACK from the BCH, it goes to . In that state, the node becomes the top CH and starts to recruit members. Instead of being CM, all its members have the role of SH. Then, after T2 times up, SHs go to Done phase while the top CH still checks if it reaches the maximum level of the multi-level clustering. If not, it will go to , select a BCH and then go to to try to form a even higher level cluster. Moreover, if the network aims at forming a 4 or more levels clustering structure, when in T2 phase the level-up SH wants to retire from the current multi-level cluster, its BCH also needs to
(T2, SubHead(lvl up))
Head(lvl up))
(T2,
(Done, SubHead)
(T1, SubHead)
CHAPTER 4.
IMPLEMENTATION
37
Send/Recv ADV
Flat Clustering Process with Modification
T1, Node
No member, not reach Retry Limit T1 time up T2 time up, still Node, not reach Retry Limit Send SUB Has member Reach Max lvl
Recv ADV, Reply SUB
Select BCH
Determine CH
CH
T2, Head
T2 time up
Done, Head
Not CH
Recv SUB, Reply PUB Recv PUB, Reply ACK T2 time up, no member, reach Retry Limit Not reach Max lvl Recv PUB, Reply ACK Recv ACK, lvl < max lvl
T2, Node
Recv SUB, Reply PUB
T2 time up, still Node, reach Retry Limit
Done, Node
Done, SubHead
T1, SubHead
Recv ACK T2 time up
Select BCH
T2, Member
Done, Member
Send/Recv Same lvl ADV
Multi-Level Clustering Process
Recv ACK, lvl < max lvl
T1, SubHead
T1 time up ngb_table empty ngb_table not empty Determine CH T2 time up, Not join cluter, not reach Retry Limit Not CH CH Recv ACK, Delegation succeeds Send NTF, wait ACK Send SUB Recv ADV, Reply SUB Has member
No member, not reach Retry Limit Reach Max lvl
Select BCH
T2, SubHead(lvl up)
T2, Head(lvl up)
T2 time up
Done, Head(lvl up)
Recv SUB, Reply PUB
Delegation Failed Recv PUB, Reply ACK T2 time up, Not Join Cluster, reach Retry Limit
T2 time up, no member, reach Retry Limit Not reach Max lvl
Recv PUB, Reply ACK
T2, SubHead
Recv SUB, Reply PUB T2 time up, joined cluster
Done, Head
Done, SubHead(lvl up)
Recv ACK Select BCH
Done, SubHead
Figure 4.10: Hierarchical clustering state diagram
CHAPTER 4.
IMPLEMENTATION
38
retire from its cluster rst and then take the place of the level-up SH. Furthermore, our multi-level clustering protocol also takes the error handling into consideration. First, if T1 times up and a SH does not receive any ADV (ngb table empty), it will go back to again to retry instead of going to and waiting for T2 timing up. This process could help SHs to exceed the process of retry and increase the possibility of forming a multi-level clustering. Moreover, If a SH at does not receive any SUB, it will also roll back to and retry. In addition, if a SH at fails in the delegation process, it will decrease its level, go to and select a new BCH. Besides, after T2 times up and a top CH does not recruit any SH, it will also decrease its level and go back to state for retry. Finally, if a SH reaches the retry limit after certain rounds, it needs to go to state with its existing level. In the cases with relatively few nodes, the network may not be able to form the maximum-level clustering structure. For instance, if a network wants to form a 4-level clustering structure and it only has one level 2 CH or the existing level-2 CHs could not hear each other, the 2-level CHs should stop retrying and go into a stable state.
(T2, SubHead)
(T1, SubHead)
Head)
(T2, SubHead) (T1, SubHead) (T2, SubHead(lvl up)) (T2, SubHead) (T1, SubHead) (Done,
Finally, during the process of forming a multi-level cluster structure, those SHs who could not promote to be the top CH should also recruit members at the same time because there could be nodes that previously did not join cluster and are still trying. Otherwise the percentage of isolated nodes will increase in the network according to our simulation. As a result, nodes only at do not recruit members. Furthermore, we divide the original ngb table into two separate tables, ngb table and ngb lvl table. The ngb table stores the information with the same level ADV while the ngb lvl table contains the one-level less ADV information. In such a way, a node could deal with dierent level ADV messages respectively so as to recruit members and form multi-level clusters simultaneously.
(T2, SubHead(lvl up))
Consequently, the multi-level clustering protocol provides the feature of multilevel clustering to our algorithm together with the at clustering and the function delegation protocol.
Chapter 5 Evaluation
In this chapter, in order to evaluate the performance of our clustering protocol and validate its energy e ciency under dierent situations, we conducted extensive simulations with dierent network sizes and topologies on the ns2 simulator (version 2.29). In addition, we also studied several key parameters, such as durations for dierent time phases, retry times etc., to optimize clustering convergence speed and maximize energy e ciency. In the following sections, we rst introduce the simulation environment and basic settings in Sec. 5.1. Then, Sec. 5.2 de nes the test criteria. Finally, in Sec. 5.3, we show and analyze the simulation results.
5.1 Simulated Environment
Because our work is part of the ISMO project [5] and the algorithm will probably be put into practice on a bridge to monitoring structural health or in a well-structured environment, we simulate our protocol in the following two topologies, bridge and matrix topologies with diagonal connections shown in Figure 5.1. In these two topologies, the distance of two direct neighbor nodes (not diagonal) is 100m. And the maximum transmission radius of each node is 150m. So, each node could reach its direct and diagonal neighbors within one hop, as shown by the line in the gure. In addition, we place the sink node at the middle of the left side. And normally its two or three neighbors could reach it within one hop. Furthermore, our simulation has the following preconditions: 1. Each node has the initial energy of 100 + 5% Joule and starts randomly 39
CHAPTER 5.
EVALUATION
40
Figure 5.1: Bridge and matrix topologies with diagonal connection
within the 1st second. 2. For each node, we set its T1 phase to 2 seconds and T2 phase to 4 seconds according to the simulation of isolated nodes in Sec. 5.3.1. 3. A node iterates the process of trying to join a cluster if it fails in the previous round. Nodes will iterate several times if necessary until the network forms a stable at cluster structure. We de ne one time of iteration as a Round. Nodes can iterate for maximum 3 rounds in the bridge topology and maximum 5 rounds in the matrix topology according to the simulation of isolated nodes in Sec. 5.3.1. 4. The initial TTL of an ADV message is 2, which means a node can only reach its direct neighbor (one hop). And the ADV TTL increases by one per every two rounds. 5. In the energy consumption simulation, we use the energy model object provided in ns2. Table 5.1 shows the values for our ns2 energy model. We set txPower to 0.138 Watt and rxPower to 0.142 Watt respectively according to the calculation based on the real hardware measurement results. Furthermore, after the network forms a stable cluster network, when a head sends a data packet to the sink node, it deducts extra 25% of the transmission energy consumption of that data packet as the computing overhead for data aggregation. In sleep mode between transmission cycles, we consider the node consumes energy close to zero
CHAPTER 5.
EVALUATION
41
because this kind of energy consumption varies according to dierent implementations. initialEnergy txPower rxPower 100+5% Joule 0.138 Watt 0.142 Watt
Table 5.1: ns2 Energy Model
6. All simulations were repeated 10 times to calculate the mean value.
5.2 Test Criteria
Basically, we de ne 2 kinds of parameters:
• parameters that could aect the performance of our protocols • parameters that could show the performance of our protocols
We de ne the following parameters as the rst kind:
• T1 and T2 time phase
Since every node usually needs to go through T1 and T2 phase sequentially in a round, T1 and T2 together is the time of each round. The period of T1 and T2 time phase could aect the total time for our algorithm to form a cluster structure, thus aecting convergence speed of our algorithm. In addition, the periods of T1 and T2 respectively also aect the number of isolated nodes after each round, which means we need to nd the proper periods for T1 and T2 respectively in our simulation to minimize the isolated nodes after a round.
• Hop/TTL
We discuss the TTL for broadcast and unicast respectively. In our protocol, only ADV messages are broadcast. So, the broadcast TTL limits the physical range of an ADV message. In some sense, it also decides the physical coverage of a single at cluster because nodes declare their existence by broadcasting ADV messages. In addition, the broadcast TTL could also aect the convergence speed of our algorithm.
CHAPTER 5.
EVALUATION
42
And for the multi-level clustering protocol, each node should also adjust its broadcast TTL according to its level so as to balance between the tra c overhead and the probability of nding same level nodes to form a cluster. The unicast TTL limits the whole network size. Nodes themselves decide their own roles as CM, CH or SH, and it is possible that a node anywhere in the network could become a CH. Therefore, each node in the network should be able to unicast packets to the sink node through a multi-hop route. Then, the unicast TTL limits the network size. Considering the latency and the possibility of packet loss, we limit the TTL for unicast packets to 32, which is a common value for IP packets. As a result, the maximum number of nodes in our bridge case is 62.
• Cluster Size
The cluster size de nes how many CMs a SH or CH could recruit. The cluster size aects the total number of heads in the network and the energy e ciency because usually the more the cluster size is, the more energy a cluster could save. But instead, with more members, the battery of a head drains out more quickly, thus shortening the life span. Moreover, in the multi-level clustering protocol, the cluster size could also limit the maximum level that the structure could form.
• Maximum Level
In the multi-level clustering protocol, we could limit the maximum level of a node, thus limiting the maximum level of the cluster structure as well as the physical coverage of one multi-level cluster.
• Packet Loss Rate
This parameter is useful for testing the Function Delegation protocol. We can test how fast the network could recover if some heads in the network fail with dierent packet loss rate. In addition, we also need to know the maximum tolerable packet loss rate for our algorithm. The maximum tolerable packet loss rate is a threshold value. Within this threshold value, our algorithm could maintain a stable cluster structure in the network. The following parameters belong to the second kind:
• Convergence Time
CHAPTER 5.
EVALUATION
43
Convergence time is the period from the time point when the network starts the clustering process to the time point when all nodes nish the clustering process. The convergence time could tell the performance for the at clustering, the 3-level or more level clustering process.
• System Energy Consumption
System energy consumption is the energy consumption for all nodes within a certain period. By recording the system energy consumption, we can compare the energy e ciency between non-cluster networks and our clustered networks with dierent levels. Moreover, by studying the simulation results, it is also possible for us to predict the energy gain and ratio of energy saving in dierent cases.
• System Recovery Time
System recovery time is a period starting from the time point when some heads fail in a network till the time point that the network becomes stable again. This value could tell the performance of the function delegation protocol. Based on the above mentioned two kinds of parameters, we performed the following simulations in Sec. 5.3.
5.3 Simulation Analysis
5.3.1 Flat Clustering
The at clustering protocol is the basic protocol which builds 2-level cluster structure for networks. In order to optimize and evaluate the protocol, we did the following three simulations, isolated node number, average convergence time and energy e ciency.
Isolated node number
After one round of cluster process, it is possible that there exist nodes which do not join clusters. We de ne this kind of nodes as Isolated Nodes. Either excessive message delay or competing cluster heads will cause isolated nodes. If isolated nodes repeat more rounds, they will eventually join existing clusters.
CHAPTER 5.
EVALUATION
44
40 35 30
Isolated Nodes(%)
Bridge (T1, T2) (2,2) (2,3) (2,4) (3,2) (3,3)
25 20 15 10 5 0
0
2
Round
4
6
Figure 5.2: Isolated nodes number in the bridge case
70 60
Isolated Nodes(%)
Matrix (T1, T2) (2,2) (2,3)
50 40 30 20 10 0
(2,4) (3,2) (3,3)
0
2
Round
4
6
Figure 5.3: Isolated nodes number in the matrix case
CHAPTER 5.
EVALUATION
45
In addition, T1, T2 durations and total rounds are important factors for the clustering protocol. With relatively long T1 and T2 durations, more nodes could nish the clustering process in one round and fewer isolated nodes need to take another round. However, with relatively short T1 and T2 durations, each round takes less time, thus shortening the time for the whole network clustering process. And dierent durations for T1 and T2 could also aect the clustering process. In addition, the fewer rounds it takes, the faster the network completes a cluster structure. As a result, by this simulation we would like to nd the optimal T1, T2 durations and rounds in dierent cases for our protocol to achieve the minimum isolated nodes in the shortest time. In this simulation, we simulate the conditions of 60 nodes in the bridge case and 64 nodes in the matrix case. We take rounds as X axis and the percentage of isolated nodes to total nodes as Y axis. And the cluster size is 5. In order to control the clustering process in a relatively short time, we limit the duration of each round for no more than 6 seconds. From Figure 5.2 and Figure 5.3, in both the bridge and matrix topologies, it is obvious that the curve with (2, 4) has the best performance because with the increase of rounds, its percentage of isolated nodes decreases more dramatically than the values of other curves. In the bridge topology, the percentage of isolated nodes decreases to about 5% within 3 iterations while in the matrix topology within 5 iterations, the percentage of isolated nodes decreases to about 5%. Therefore, for the following simulations, we could x T1 time to be 2 seconds, T2 time to be 4 seconds because it shows the best performance in the both cases. In addition, we de ne that if the percentage of isolated nodes is less than 5% of the total nodes, the network has completed the clustering process. As a result, we could also consider that the bridge topology takes 3 rounds to complete the clustering process while the matrix topology takes 5 rounds.
Convergence time
The convergence time is an important factor to evaluate the speed of at clustering process. The faster speed (short convergence time) bene ts network initialization. And three parameters, , could in uence the convergence time. In our simulation, we record the average at cluster completion time regarding to the increase of total nodes number. The convergence time of one node is from the point that the node sends the rst ADV message to the point that
topology and cluster size
total nodes number, network
CHAPTER 5.
EVALUATION
46
10.0
9.5
Average Convergence Time (sec)
9.0
8.5
8.0
7.5
7.0
Bridge
6.5
Cluster Size 4 6
6.0
5.5
8 10
0 20 40 60
5.0
Total Number of Nodes
Figure 5.4: Convergence time in the bridge case
the node goes into the stable DONE phase. The average convergence time takes all nodes into account and calculates the mean value. Based on the previous simulations, T1 and T2 phases are set to 2 and 4 seconds respectively to optimize clustering process. We tested four dierent cluster sizes (4, 6, 8 and 10) on the two network topologies. Figure 5.4 and Figure 5.5 show the average convergence time of at clustering in the bridge and matrix topologies. In the bridge case of Figure 5.4, the average convergence time becomes stable for all curves when the number of nodes exceeds 20. It implies that the increase of nodes number aects the convergence time for small size networks on bridge topology. For relatively large networks, convergence time tends to approach a constant value. Furthermore, we can see that the curve of cluster size 4 is above the other curves. The longer convergence time is caused by the bridge topology, where a node can reach ve neighbors within one-hop distance. With cluster size of 4, one neighbor node is likely to perform the second round of clustering process to join another cluster, thus increasing the average convergence time. In the matrix case of Figure 5.5, the average convergence time rises dramatically with the increase of the node number when the node number is less
CHAPTER 5.
EVALUATION
47
11.0 10.5 10.0 9.5 9.0 8.5 8.0 7.5 7.0 6.5 6.0 5.5 5.0 0 20 40 60
Average Convergence Time (sec)
Matrix Cluster Size 4 6 8 10
Total Number of Nodes
Figure 5.5: Convergence time in the matrix case
than 16. For more than 16 nodes matrix cases, the average convergence time reaches a plateau but still increases slightly with the increase of the node number. It is due to the fact that with the increase of nodes, more nodes need to run extra rounds of clustering process to join existing clusters or form new clusters. In 4 to 16 nodes cases, the nodes running extra rounds rises dramatically while in 16 to 64 cases such kind of nodes increases slightly. In both the bridge and matrix cases, the average convergence time stays within two iterations of clustering process for most network scales. The time overhead is acceptable. In practice, people usually deploy multiple sink nodes at dierent positions for large-scale networks. Therefore, in our simulation, we use 64 nodes as the biggest network unit for one sink node.
Energy E ciency
After the simulations of isolated node number and convergence time, we have optimized several parameters of our protocol, such as T1 and T2 time phase, and also evaluate the performance of our protocol. In this part, we continue to evaluate the energy consumption of the at clustering protocol in the following two simulations and compare the results with the ones of the non-cluster networks.
CHAPTER 5.
EVALUATION
48
1200
Bridge
System Energy Consumption (J)
1000 800 600 400 200 0 0
non-cluster Cluster Size 4 6 8 10
10
20
30
40
50
60
Total Number of Nodes
Figure 5.6: System energy consumption regarding to nodes number in the bridge case
1250
Matrix
System Energy Consumption (J)
1000
non-cluster Cluster Size 4
750
6 8 10
500
250
0 0 20 40
Total Number of Nodes
60
Figure 5.7: System energy consumption regarding to nodes number in the matrix case
CHAPTER 5.
EVALUATION
49
• System energy consumption regarding to nodes number in the 2 topologies with dierent cluster sizes
In this simulation case, we record the energy consumption in 1000 seconds of the clustered topology in comparison with the non-cluster topology regarding to the increase of nodes with dierent cluster sizes. Nodes in the non-cluster network send data to the sink node per duty cycle (every 5 seconds) via multi-hop routes. In the clustered network, member nodes send data to the cluster heads per duty cycle. Cluster heads aggregate and send the merged data to the sink node per duty cycle. The sink node is at the middle on the left side. We did the simulation in both bridge and matrix topologies with four dierent cluster sizes. This case helps us to nd the relationship with the saved energy and the network size, and the eect of dierent cluster sizes in such conditions. Figure 5.6 and Figure 5.7 shows the system energy consumptions in clustered networks on two dierent topologies in contrast to non-cluster networks. Gaps between curves of non-cluster networks and at cluster networks illustrate the gain of saved energy with dierent cluster sizes. we rst focus on the system energy consumption regarding to dierent cluster sizes for the clustered networks. We can nd that in the bridge topology with more than 20 nodes, the system energy consumption decreases with the increase of cluster size. For example, in Figure 5.6, it is obvious that the at cluster network with cluster size 4 consumes relatively more energy than the networks with other cluster sizes. Therefore, in relatively large bridge topologies, the at clustering with larger cluster size could save more energy. In Figure 5.7, It is also true that the larger the cluster size is, the more energy a clustered network could save. It is a case in point that the clustered matrix network with cluster size 10 consumes less energy than the ones with other cluster sizes. In both above two gures, the larger the cluster size, the more energy it could save. It is reasonable because with the increase of cluster size, a head could recruit more members and the number of heads in the network also decreases. As a result, there will be more one or two-hop packet transmissions between members and heads, and less long multi-hop packet transmissions between heads and the sink node, thus reducing the total energy consumption. However, Figure 5.6 and Figure 5.7 are not enough to show the improvement of the energy e ciency of our algorithm. If we would like to observe the energy e ciency considering the increase of nodes number, we could use Equation 5.1 to calculate the Saved System Energy Percentage (es %) for two
CHAPTER 5.
EVALUATION
50
80
Saved System Energy (%)
60
40
Bridge
20
Cluster Size 4 6 8
0
10
0
20
40
60
Total Number of Nodes
Figure 5.8: Saved system energy percentage in the bridge case
topologies, which represents the percentage of saved system energy in clustered networks compared with the system energy consumption of non-cluster networks. In the equation, e1 stands for the system energy consumption of clustered networks with dierent cluster sizes respectively. And e2 always stands for the system energy consumption of non-cluster networks. Moreover, es stands for saved energy between a non-cluster network and a cluster network with certain number of nodes and cluster size. And es % is the percentage of saved system energy compared with the system energy consumption of non-cluster networks.
es = e2 − e1 , es % = es /e2 = (e2 − e1 )/e2 ∗ 100%
(5.1)
Based on Equation 5.1, Figure 5.8 and Figure 5.9 show the results of es % regarding to nodes numbers with dierent cluster sizes in the bridge and matrix cases. The X axis represents nodes numbers and the Y axis stands for es %, saved system energy percentage. In Figure 5.8, we focus on the saved system energy percentage regarding to nodes number. With the increase of nodes number, the saved system energy percentage rises dramatically with less than 40 nodes and then reaches a plateau for about 70% when nodes are more than 40 in the bridge case.
CHAPTER 5.
EVALUATION
51
60
50
Saved System Energy (%)
40
30
Matrix
20
Cluster Size 4 6
10 0 20 40
Total Number of Nodes
8 10
60
Figure 5.9: Saved system energy percentage in the matrix case
Therefore, the curves imply that when nodes are less than 40, the nodes number actually aects the energy e ciency of our clustered networks. When nodes number is more than 40, the saved system energy percentage is about 70% regardless of nodes number. In Figure 5.9, it is also the case that the saved system energy percentage soars up when node are less then 40 nodes, and when nodes are more than 40, the percentage reaches a plateau of about 55%. Therefore, we can reach the following two conclusions. The larger cluster size could save more energy. And with bigger network scales, for our at clustering the saved system energy percentage tends to reach a stable value, 70% for the bridge case and 55% for the matrix case. Moreover, the bridge case has better energy e ciency by adopting our at clustering because in the bridge case, the average transmission distance in hops decreases a lot compared with non-cluster networks. In both cases, our cluster algorithm can save considerable energy.
• System energy consumption regarding to duty cycle in the 2 topologies with dierent cluster sizes
CHAPTER 5.
EVALUATION
52
3000
System Energy Consumption (J)
Bridge Non-Cluster
2500 2000 1500 1000 500 0 0
20 40 60 Flat Cluster 20 40 60
100
200
300
Duty Cycle
400
500
Figure 5.10: System energy consumption regarding to duty cycle in the bridge case
In this simulation case, we record the energy consumption over duty cycle with a xed cluster size ve on three dierent network sizes. The system running time equals the product of duty cycle number multiplying the interval, which is ve seconds in this case. The simulation tells us how much energy can be saved along with the increase of time in the network. Figure 5.10 and Figure 5.11 show the energy saving over time in terms of duty cycle in clustered networks on two dierent topologies in contrast to noncluster network. The gap between dash curves (non-cluster networks) and solid curves (clustered networks) illustrates the gain of energy e ciency under dierent network scales. The bigger network saves more energy in cluster topology, especially for bridge case. The energy saving increases dramatically over time. Since all curves are approximately straight, we can construct linear models to predict the energy saving under a given network topology and scale. Suppose the tted functions for cluster and non-cluster topology are given respectively by
y1 = ax + c, y2 = bx + d
(5.2)
where x is the number of duty cycle, y1 stands for non-cluster and y2 stands for at clustering. Therefore, the following equations could present the value
CHAPTER 5.
EVALUATION
53
3000 2800 2600 2400 2200 2000 1800 1600 1400 1200 1000 800 600 400 200 0 0
Matrix Non-Cluster 36 49 64 Flat Cluster 36 49 64
System Energy Consumption (J)
100
200
300
Duty Cycle
400
500
Figure 5.11: System energy consumption regarding to duty cycle in the matrix case of saved energy (∆y ) and the improvement ratio of energy e ciency
∆y = y1 − y2 = sx − i ∆y y1 − y2 bx + d = =1− y1 y1 ax + c
(5.3)
(5.4)
Because y1 stands for non-cluster and y2 stands for at clustering, the constants s and i has dierent meanings. s stands for the saved energy per duty cycle, which represents how much energy a at cluster network could save with each extra duty cycle compared with a non-cluster network. Furthermore, i represents the initial energy consumption for building a at cluster structure network. And with these equations, we can predict the energy saving and ratio of energy gain in a given time point. For example, when nodes number is 60 in bridge case, two functions for non-cluster and at cluster topology are:
y1 = 5.855x + 5.617, y2 = 1.816x + 19.487 ∆y = y1 − y2 = 4.039x − 13.87
(5.5) (5.6)
CHAPTER 5.
EVALUATION
54 (5.7)
∆y 1.816x + 19.487 =1− . y2 5.855x + 5.617
According to the above equations, the system energy gain is about 4.039 Joule per duty cycle. And when duty cycles are more than 4, the 60 nodes network with at cluster consumes less energy than the non-cluster one. We can also predict the energy gain and the ratio of energy for the 60 nodes bridge case. For instance, when the system runs for 600 duty cycles (i.e., x=600), the clustered topology saves about 2409.53 Joules energy, which saves about 68.5% energy compared with non-cluster topology. nodes 20 40 60 Bridge s 0.338 1.749 4.039 i 2.881 7.688 13.870 nodes 36 49 64 Matrix s 0.959 1.684 2.708 i 13.086 24.177 45.655
Table 5.2: Flat clustering results Moreover, we calculate and list the s and i value separately in Table 5.2. According to the gure, it is obvious that s increases with the nodes number in both the bridge and matrix cases, which illustrates the energy gain per duty cycle rises with the nodes number. In addition, i rises with the nodes number also. It is reasonable that the more the nodes are, the more energy the initial clustering process consumes. Hence in short, the gain of energy e ciency in our at clustering protocol is a signi cant advantage.
5.3.2 Delegation Protocol
The delegation protocol is the protocol that provides fault tolerance for CH failures and also is the basis for the multi-level clustering protocol. We did the following simulation to evaluate the performance of this protocol with dierent packet loss rates.
System recovery time regarding to packet loss rate in the 2 topologies
In this simulation, after the network has formed a cluster structure, we introduce a failure of random 10% of CHs simultaneously. We record the recovery
CHAPTER 5.
EVALUATION
55
55
50
Bridge Total Node Number
45
20 40 60
40
Recovery Time (sec)
35
30
25
20
15
10
5
0 0.0 0.1 0.2 0.3 0.4 0.5
Packet Loss Rate
Figure 5.12: Recovery time in the bridge case
time to test the performance of our delegation function. The recovery time starts from the time point when 10% CHs fail to the time point when the cluster structure becomes stable again. In this simulation, we also take the eect of packet loss rate on network connectivity into consideration. In the poor link quality environment, heartbeat signal or SUB / PUB / ACK messages loss will cause re-clustering and new node join. Recovery process may take several rounds to complete. We take packet loss rate as X axis and system recovery time as Y axis, and expect to nd how external environment condition aects the recovery time of the whole network. In Figure 5.12, we can nd that in the 20 nodes bridge networks, the system recovery time rises slightly all the time with the increase of packet loss rate. Furthermore, in the 40 and 60 nodes bridge networks, the system recovery time increases slightly with packet loss rate less than 0.35. However, when the packet loss rate is more than 0.35, the system recovery time soars up. The slight increase of the system recovery time may due to the fact that with the increase of the packet loss rate, the original members of the failed CHs may need to take extra rounds to join a cluster. Nevertheless, the latter situation that the recovery time soars up could be owing to the fact that the network itself cannot maintain the stable cluster structure due to the high packet loss rate. A BCH considers its CH has already failed due to excessive
CHAPTER 5.
EVALUATION
56
70
Matrix
60
Total Node Number 36
50
49 64
Recovery Time (sec)
40
30
20
10
0 0.0 0.1 0.2 0.3 0.4 0.5
Packet Loss Rate
Figure 5.13: Recovery time in the matrix case
loss of the heartbeat signals from CH while in fact the CH still works, thus triggering the taking over process. And later that CH discovers that it has no member and will try to join a cluster as a CM. This situation eventually cause the dramatically increase of the system recovery time. Therefore, we can reach the conclusion that with less than 0.35 packet loss rate, the system recovery time of our protocol in the bridge case is about 25 seconds. And 0.35 is the maximum tolerable packet loss rate for our protocols to maintain a cluster structure in the bridge case. In Figure 5.13, we can also nd the above mentioned situations. With the packet loss rate less than 0.35, system recovery time of all networks increases slightly and is also about 25 seconds. However, when the loss rate is more than 0.35, the system recovery time starts to soar up. Therefore, 0.35 could be a threshold for our clustering protocol to maintain a stable network. Consequently, our conclusion is that the system recovery time in both cases is about 25 seconds with less than 0.35 packet loss rate. And the maximum tolerable packet loss rate is 0.35. By the way, if the protocol needs to maintain the cluster structure with more than 0.35 packet loss rate, we should either increase the tolerance of the loss of heartbeats or try to realize reliable transmission in some sense.
CHAPTER 5.
EVALUATION
57
5.3.3
Hierarchical Clustering
Based on the at clustering and the delegation protocols, the multi-level clustering protocol could form networks into 3 or more level clustering structure. We also did several simulations to evaluate the performance as well as its energy e ciency. In order to achieve a better performance, according to our simulations, we optimize the following parameters based on the level (the lowest node has level 0). Currently, we de ne ∆T as 1 second and ∆TIMEOUT as 0.5 seconds based on our simulations.
T 1 = 2 + ∆T ∗ level T 2 = 4 + ∆T ∗ level T T L = 2 + level2 T IM EOU T = 1 + ∆T IM EOU T ∗ level
(5.8) (5.9) (5.10) (5.11)
Convergence time
For the hierarchical clustering protocol, the convergence time is also an important factor to evaluate the performance of the hierarchical clustering process. The shorter the time is, the faster a network could form a stable structure and start to send data. As a result, we did a simulation similar to the convergence time simulation of the at clustering protocol. We recorded the average cluster completion time regarding to the increase of total nodes number. The convergence time of one node is from the point that a node starts to the point that the node reaches the stable DONE phase. The average convergence time takes all nodes into account and calculates the mean value. We also tested four dierent cluster sizes (4, 6, 8 and 10) on the two network topologies. The following gures show the average convergence time of hierarchical clustering in the bridge and matrix topologies aiming at 3 and 4 level clustering structures. In both Figure 5.14 and Figure 5.15, in the bridge case with less than 20 nodes, the average convergence time increases dramatically with the increase of nodes. And when the nodes are more than 20, the average convergence time reaches a plateau. In addition, with more than 20 nodes, the average convergence time uctuates around 12.75 seconds for 3-level structure and 16 seconds for 4-level structure. These values are acceptable for the time overhead of forming a hierarchical clustering structure.
CHAPTER 5.
EVALUATION
58
14.5
14.0
Average Convergence Time (sec)
13.5
13.0
12.5
12.0
11.5
11.0
10.5
Bridge 3-level clustering
10.0
4 6 8
9.5
9.0
10
0 20 40 60
Total Number of Nodes
Figure 5.14: Convergence time in the 3-level clustering bridge case
18.0 17.5 17.0
Average Convergence Time (sec)
16.5 16.0 15.5 15.0 14.5 14.0 13.5 13.0 12.5 12.0 11.5 11.0 10.5 10.0 9.5 9.0 0 20 40
Bridge 4-level clustering 4 6 8 10
60
Total Number of Nodes
Figure 5.15: Convergence time in the 4-level clustering bridge case
CHAPTER 5.
EVALUATION
59
16 15
Average Convergence Time (sec)
14 13 12 11 10 9 8 7 0 20 40
Total Number of Nodes Matrix 3-level clustering 4 6 8 10
60
Figure 5.16: Convergence time in the 3-level clustering matrix case
20 19
Average Convergence Time (sec)
18 17 16 15 14 13 12 11 10 9 8 7 0 20 40
Total Number of Nodes Matrix 4-level clustering 4 6 8 10
60
Figure 5.17: Convergence time in the 4-level clustering matrix case
CHAPTER 5.
EVALUATION
60
For the matrix cases, in both Figure 5.16 and Figure 5.17, the curves for most cluster sizes increase dramatically from 4 nodes to 9 nodes but decrease from 9 nodes to 16 nodes and then increase again. The reason for such a tendency is that networks with less than 9 nodes usually cannot form a 3-level clustering structure every time because CHs are too few and they may not be able to hear each other. Therefore, these CHs may still try to nd each other for several rounds before they go to DONE phase and send data, thus increasing the average convergence time. However, in the cases with 16 or more nodes, the networks are more likely to form a 3-level or 4-level cluster structure with more CHs. Hence, CHs could quickly form another cluster and go to DONE phase instead of trying several rounds. Furthermore, with more than 20 nodes, the average convergence time also rises slightly with the increase of nodes. The maximum average convergence time for 3 and 4-level clustering is less than 20 seconds, which is still acceptable. In addition, there is obvious dierence of average convergence time among dierent cluster sizes. In both 3 and 4-level cases, the average convergence time of cluster size 4 is usually longer than those of other sizes and the one with cluster size 8 shows the shortest time. To explain this phenomenon, in the matrix cases usually a node can reach more than 4 neighbors within one-hop distance and central nodes usually have 8 neighbors. With cluster size of 4, one or more neighbor nodes are likely to perform the second round of clustering process to join another cluster, thus increasing the average convergence time. However, with the cluster size 8, a CH is likely to accept all its neighbors as its CMs. Therefore, a larger cluster size (8 according to the gures) is preferred for the matrix topologies.
Energy e ciency
For the hierarchical clustering protocol, we also did two simulations similar to the ones of the at clustering protocol and observed the tendency of system energy consumption regarding to nodes number and duty cycle respectively.
• System energy consumption regarding to nodes number in the 2 topologies with dierent cluster sizes
In this simulation case, we record the energy consumption in 1000 seconds of the 3-level clustered topology in comparison with the at topology regarding to the increase of the node number with dierent cluster sizes. In the hierarchical structure networks, member nodes send data to its SUB Head (SH) every 5 seconds (i.e., duty cycle interval). SHs again aggregate and send the
CHAPTER 5.
EVALUATION
61
400
Bridge
System Energy Consumption (J)
300
Flat Cluster 4 6 8
200
10 3-level Cluster 4
100
6 8 10
0 0 20 40 60
Total Number of Nodes
Figure 5.18: System energy consumption regarding to node numbers in the hierarchical bridge case
merged data to their SH or CH. Finally, CHs also aggregate and send data to the sink node. The sink node is in the middle on the left side. We did the simulation in both bridge and matrix topologies with four dierent cluster sizes. We expect to nd the dierence of the energy consumption among dierent cluster sizes with dierent node numbers. Figure 5.18 shows that with less than 20 nodes, the 3-level clustering networks consume a little bit more energy than the at ones within 1000 seconds. And when nodes are more than 20, the 3-level clustering networks saves more energy. Based on this nding, it is reasonable that the at clustering has better energy saving than the hierarchical one in the small-scale networks. Because with the 3-level clustering in small-scale networks, the level-2 CHs are few and it is possible that those level-2 CHs happen to be far away from the sink node and those level-1 SHs close to the sink node have to send packets to those CHs. Packets actually go a detour to a farther node, and the farther node aggregates and sends the packet to the sink node along another long multi-hop route, thus resulting in more system energy consumption compared with the at case. Figure 5.19 shows that regardless of cluster sizes, the 3-level clustering networks consumes more energy than the at clustering networks within 1000
CHAPTER 5.
EVALUATION
62
600 500 400 300 200 100 0 0 20 40
Total Number of Nodes Matrix Flat Clustering 4 6 8 10 3-level Clustering 4 6 8 10
System Energy Consumption (J)
60
Figure 5.19: System energy consumption regarding to node numbers in the hierarchical matrix case
seconds in the matrix case. There are two possible reasons that cause such a phenomenon. One is that a hierarchical clustering network actually consumes more energy than the at clustering ones. Another reason is that the initial process for a 3-level clustering may consumes more energy than the one for a at clustering and the running time is too short to show the gain of energy saving. We will discuss it and nd the reason in the next simulation. In both Figure 5.18 and Figure 5.19, we can nd the similar phenomenon to the at cluster that the larger the cluster size is, the more energy the network could save. The curve of the cluster size 4 with 3-level clustering is usually above other curves. For example, if we look at the point of 60 nodes in Figure 5.18, it shows that with the increase of cluster size, the energy consumption decreases. It is the same reason as we mentioned in Sec. 5.3.3. The more nodes a cluster could contain, the less SHs or CHs are in the network, thus reducing the long multi-hop transmission from SHs to CHs and CHs to the sink node and saving energy.
• System energy consumption regarding to duty cycle in the 2 topologies with dierent number of nodes
CHAPTER 5.
EVALUATION
63
1500 1400 1300
System Energy Consumption (J)
1200 1100 1000 900 800 700 600 500 400 300 200 100 0 0
Bridge Flat 20 40 60 3-level 20 40 60 4-level 20 40 60
100
200
300
400
500
600
700
800
Duty Cycle
Figure 5.20: System energy consumption regarding to duty cycle in the hierarchical bridge case
In this simulation case, we record the energy consumption over duty cycle with a xed cluster size ve on three dierent network sizes. The system running time equals the product of duty cycle number multiplying the interval, which is ve seconds in this case. And we compare the energy consumptions of at, 3-level and 4-level clustering networks to nd out the best levels for certain cases. In Figure 5.20, it is obvious that multi-level clustering networks (either 3 or 4level structure) consumes less energy than the at clustering for all number of nodes in the bridge case. And the longer the running time is, the more energy the multi-level clustering networks could save. In addition, if we focus on the 3-level and 4-level networks, except for the 20 nodes networks, the 4-level clustering networks save a little bit more energy than the 3-level ones, and the gain of energy saving also increases with the elapse of time. We can also use the Function 5.3 and calculate the s and y respectively. Here, y1 always represents the non-cluster network while y2 could be at, 3-level and 4-level cluster respectively. And we use Equation 5.12 to calculate simp . simp stands for the improvement percentage between two s values. s1 always stands for the at s while s2 could be 3-level and 4-level s respectively. Table 5.3 shows the results.
CHAPTER 5.
EVALUATION
64 3-level 4-level i(J) i(J) 4.139 5.143 11.241 14.779 20.655 25.885 s improvement
bridge at 3-level nodes s(J) s(J) 20 0.338 0.377 40 1.749 1.882 60 4.039 4.612 Note: simp column is the
3-level 4-level 4-level at simp s(J) simp i(J) 11.28% 0.344 1.56% 2.881 7.60% 1.916 9.56% 7.688 14.19% 4.645 15.00% 13.870 percentage of the 3-level or 4-level compared with the at s
Table 5.3: Hierarchical clustering results in the bridge case
∆s = s2 − s1 , simp = ∆s/s1 = (s2 − s1 )/s1 ∗ 100%
(5.12)
According to s and simp in Table 5.3, the gain of energy per duty cycle between 3-level and 4-level clustering is too trivial and far less than the gain between at and 3-level clustering. For the 20 nodes bridge topology, the 4level clustering even consumes more energy than the 3-level clustering while for the 40 and 60 nodes cases, the simp of 4-level only increases by less than 2% in the 40 nodes case and by less than 1% in the 60 nodes case compared with the simp of 3-level. In addition, the initial energy consumption for setting up the cluster structure also rises with levels. Therefore, considering convergence time, energy gain and the initial energy consumption, we can reach the conclusion that in the bridge case, the 3-level clustering structure is the best choice. For the matrix cases in Figure 5.21, it shows a situation dierent from Figure 5.20. Since several curves are quite close to each other, we also use the Function 5.3 and calculate the s and i respectively. Here, y1 always represents the non-cluster network while y2 could be at, 3-level and 4-level cluster respectively. And we also use Equation 5.12 to calculate the simp . simp stands for the improvement percentage between two s values. s1 always stands for the at s while s2 could be 3-level and 4-level s respectively. Table 5.4 shows the results. Firstly, we compare the conditions of at clustering with the ones of the 3level clustering. In the 36 nodes networks, the simp of the 3-level clustering is -0.26%, which means there is no gain of energy saving with the increase of time between the 3-level and at clustering in the 36 nodes matrix topology. However, in the 49 nodes networks, we can nd that the simp of the 3-level is 0.88%. So, there is a trivial increase of energy saving between the 3-level and the at clustering with the increase of time. But the improvement is too
CHAPTER 5.
EVALUATION
65
2200 2000
System Energy Consumption (J)
1800 1600 1400 1200 1000 800 600 400 200 0 0
Matrix Flat 36 49 64 3-level 36 49 64 4-level 36 49 64
100
200
300
400
500
600
700
800
Duty Cycle
Figure 5.21: System energy consumption regarding to duty cycle in the hierarchical matrix case
matrix at 3-level nodes s(J) s(J) 36 0.959 0.956 49 1.684 1.699 64 2.708 3.095 Note: Gain column is the
3-level 4-level 4-level at simp s(J) simp i(J) -0.26% 0.890 -7.13% 13.086 0.88% 1.605 -4.70% 24.177 14.32% 2.742 1.28% 45.655 percentage of the 3-level or 4-level compared with the at s
3-level 4-level i(J) i(J) 20.059 29.076 35.987 45.844 62.289 74.814 s improvement
Table 5.4: Hierarchical clustering results in the matrix case
CHAPTER 5.
EVALUATION
66
trivial. In the 64 nodes networks, the simp of the 3-level is 14.32%, which is a big improvement in the energy gain per duty cycle. Furthermore, if we take 4-level clustering networks into consideration, it is obvious that 4-level clustering consumes more energy than the 3-level clustering and there is no energy gain between 4-level and 3-level clustering in all conditions in the matrix topology. And if we compare the 4-level clustering with the at one, we can nd except for the 64 nodes matrix, the 4-level clustering even consumes more energy than the at one. As a result, the 4-level clustering is not worthy of consideration for energy e ciency in the matrix case. Therefore, we conclude that with less than 49 nodes in the matrix case, it is enough to form a at clustering structure for energy e ciency. When the nodes are more than 64, the 3-level clustering structure is a better option. Finally, we can also use the Equation 5.2, 5.3 and 5.4 to predict the energy gain and the ratio of energy gain, and take the 64 nodes matrix topology with the at and 3-level clustering as an example. The following equations are for 3-level and at clustering in the 64 nodes case:(y2 stands for at clustering and y3 stands for 3-level clustering)
y2 = 2.712x + 62.522, y3 = 2.325x + 79.157 ∆y = y2 − y3 = 0.387x − 16.635 ∆y 0.387x − 16.635 = . y2 2.325x + 79.157
(5.13) (5.14) (5.15)
According to the above equations, the system energy gain is about 0.387 Joule per duty cycle. And when duty cycles are more than 43, the 64 nodes network with 3-level clustering consumes less energy than the one with at clustering. With these equations, we can also predict the energy saving in a given time point. For instance, when the system runs for 3000 duty cycles (i.e., x=3000), the clustered topology saves about 1144.365 Joules and about 16.22% energy consumption compared with at cluster topology. The gain of energy e ciency between 3-level and at clustering in the long run in such a case is signi cant. Hence, we can reach the conclusion that in the bridge case, the 3-level clustering structure is the best choice for energy e ciency while in the matrix case, the at clustering structure is the best choice for the topologies with less than 64 nodes. In the 64 nodes matrix case, a 3-level clustering is the best choice for energy e ciency.
Chapter 6 Conclusion and Future Work
6.1 Conclusion
To sum up, in this thesis work, we rst review several related clustering algorithms and nd their aws. Then, we introduce our algorithm including 3 protocols, Flat Clustering protocol, Function Delegation protocol and Multi-Level Clustering protocol, and describe our improvements to the original design. These three protocols together could provide the following ve features, scalability, fault tolerance, load balancing, energy e ciency and multi-level clustering. Next, in order to evaluate our algorithm in a short time with low expense, we decide to use simulator and look into three popular ones, J-Sim, OMNeT++ and NS-2. NS-2 meets our requirements and serves as our evaluation tool. In addition, we explain the implementation of our algorithm and provide detailed data structures and state diagrams. Finally, we simulate three protocols respectively under dierent conditions and reach some conclusions. We validate our algorithm and nd it quite promising in performance and energy e ciency, especially in the bridge case. For instance, networks with our at clustering protocol could save considerable energy compared with non-cluster networks. And our 3-level clustering could save more energy than the at clustering in the bridge cases.
6.2 Future Work
We have simulated our algorithm on NS-2 simulator with several conditions. More test cases could be performed for further evaluating the algorithm, for instance, simulation of the whole network life span and tracking the energy 67
CHAPTER 6.
CONCLUSION AND FUTURE WORK
68
consumption on each node. And we could simulate more topologies, e.g., randomly deploying certain number of nodes in a xed area or even 3D topologies. In addition, it is a complex problem to provide fault tolerance for a multi-level clustering network. More studies and researches could focus on that problem. Moreover, the period of T1 and T2 time phase are key to the clustering algorithm and should be adjusted according to the network scale. So, more simulations are needed to nd relationship between T1, T2 phase and the network size. Finally, the algorithm of selecting a CH needs further improvement. Currently, our algorithm totally bases on the residue energy for the CH selection. The node with the highest residue energy among its neighbors could automatically become a CH. However, more conditions could be taken into consideration for selecting a CH, for example, locations of the nodes, received signal strength etc. If a node is near the sink node, which means it could reach the sink node with fewer hops, it could be more probable to be a CH than others. In this way, the node that is close to the sink node could become CH, thus reducing the hops of transmission between CHs and the sink node and saving more energy. What's more, when recruiting members, a CH could also have criteria and prefer those nodes with relatively low energy, strong signal strength and few hops to reach. In this way, a node with low energy and near to a CH could become its member, thus making a cluster more stable and energy e ciency.
Bibliography
[1] Castalia - user manual version 2.3. http://castalia.npc.nicta.com. au/pdfs/Castalia%20-%20User%20Manual.pdf/. [2] Castalia, a simulator for wsns. http://castalia.npc.nicta.com.au/. [3] Inet framework for omnet++ 4.0. http://inet.omnetpp.org. [4] Inetmanet. http://github.com/inetmanet/inetmanet. [5] Ismo - intelligent structural health monitoring system. http://mide. tkk.fi/en/ISMO. [6] J-sim. http://sites.google.com/site/jsimofficial/. [7] Mixim project. http://mixim.sourceforge.net/. [8] Mobility framework sourceforge.net. for omnet++.
http://mobility-fw.
[9] The network simulator - ns-2. http://www.isi.edu/nsnam/ns/. [10] Ns-2.29 all-in-one package. http://ftp.isi.edu/nsnam/dist/. [11] ns-3. http://www.nsnam.org/wiki/index.php/Main_Page. [12] Omnet++. http://www.omnetpp.org/. [13] WirelessHART.
http://www.hartcomm.org/protocol/wihart/ wireless_technology.html.
[14] IEEE 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Speci cations. Tech. rep., IEEE Computer Society, June 2007. [15] ZigBee Speci cation. Tech. rep., ZigBee Alliance, 2008. 69
BIBLIOGRAPHY
70
[16]
An Energy E cient Hierarchical Clustering Algorithm for Wireless Sensor Networks. In IEEE INFOCOM 2003 (2003). http://www.ieee-infocom.org/2003/papers/ 42_02.PDF.
Bandyopadhyay, S., and Coyle, E. J. Bandyopadhyay, S., and Coyle, E. J. An energy e cient hierarchical clustering algorithm for wireless sensor networks, 2003.
[17] [18]
Conference of the IEEE Computer and Communications Societies (INFOCOM¡¯ 01) (April 2001).
[19]
Chan, H., and Perrig, A.
A clustering scheme for hierarchical control in multi-hop wireless networks. In Proceedings of 20th Joint
Banerjee, S., and Khuller, S.
uniform cluster formation. In Proceedings of the First European Workshop on Sensor Networks (EWSN) (2004), pp. 154171.
Demirbas, M., Arora, A., and Mittal, V. Floc: A fast local clustering service for wireless sensor networks. In Workshop on De-
Ace: An emergent algorithm for highly
[20]
pendability Issues in Wireless Ad Hoc Networks and Sensor Networks (DIWANS/DSN (2004).
[21]
the IEEE International Conference on Distributed Computing in Sensor Systems(DCOSS¡¯05) (June 2005).
[22] [23] [24] [25]
Fall, K., and Varadhan, K.
Ding, P., Holliday, J., and Celik, A. Distributed energy e cient hierarchical clustering for wireless sensor networks. In Proceedings of
nsnam/ns/doc/ns_doc.pdf.
The ns Manual. http://www.isi.edu/
MiWi Wireless Networking Protocol Stack. Tech. rep., Microchip Technology Inc., 2007.
Flowers, D., and Yang, Y.
An algorithm for evaluation of nite trigonometric series. American Mathematical Monthly 65 (1958), 3435.
Goertzel, G.
Fault-tolerant clustering of wireless sensor networks. In Proceedings of the IEEE Wireless Communication and Networks Conference (WCNC 2003) (March 2003).
Gupta, G., and Younis, M.
[26]
Middleware: middleware challenges and approaches for wireless sensor networks. In IEEE Distributed Sys. Online, vol. 7, pp. 1¨C23 (2006).
Hadim, S., and Mohamed, N.
BIBLIOGRAPHY
71
[27]
Heinzelman, W. R., Chandrakasan, A., and Balakrishnan,
Energy-e cient Communication Protocols for Wireless Microsensor Networks. In Proc. Hawaaian Int'l Conf. on Systems Science (January 2000). http://wind.lcs.mit.edu/papers/leach-hicss.ps.
H.
[28]
ing for sensor networks. In Proceedings of the 3rd international symposium on Information processing in sensor networks (IPSN '04) (2004), ACM, pp. 205214. The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4. Tech. rep., IETF - Network Working Group, February 2007. http://tools.ietf.org/ html/rfc4728.
Johnson, D., Hu, Y., and Maltz, D.
Hohlt, B., Doherty, L., and Brewer, E.
Flexible power schedul-
[29]
[30] [31] [32]
Gpsr: Greedy perimeter stateless routing for wireless networks. pp. 243254.
Karp, B. Keshav, S.
Real 5.0 overview, 1997.
Adaptive data fusion for energy e¡Àcient routing in wireless sensor networks. In IEEE Transactions on Computers (2006). vol. 55, pp. 12861299,.
Luo, H., Luo, J., Liu, Y., and Das, S. Nadeem, T., and Agrawala, A.
[33]
Performance of IEEE 802.11 based Wireless Sensor Networks in Noisy Environments. Tech. rep., Department of Computer Science, University of Maryland, 2005. An algorithm for group formation in an amorphous computer. In Proceedings of the Tenth International Conference on Parallel and Distributed Systems (PDCS (1998).
Nagpal, R., and Coore, D.
[34]
[35]
Ad hoc On-Demand Distance Vector (AODV) Routing. RFC 3561, The Internet Engineering Task Force - Network Working Group, July 2003. http://tools.ietf. org/pdf/rfc3561.pdf.
Perkins, C., Belding-Royer, E., and Das, S.
[36]
Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers. http://www.cs.virginia.edu/~cl7v/cs851-papers/ dsdv-sigcomm94.pdf.
Perkins, C. E., and Bhagwat, P. Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and Schooler, E.
[37]
Std 802.15.4-2006. Tech. rep., IEEE Computer Society, 2006.
IEEE
BIBLIOGRAPHY
72
[38]
A Survey of Simulation in Sensor Networks. http://portal.acm.org/citation.cfm?id= 1578022.1578901.
Singh, C. P., Vyas, O. P., and Tiwari, M. K.
[39]
An adaptive energy-e cient mac protocol for wireless sensor networks. In Proceedings of the 1st
van Dam, T., and Langendoen, K.
international conference on Embedded networked sensor systems(SenSys 03) (2003), pp. 171180.
[40]
Xu, K., and Gerla, M.
A heterogeneous routing protocol based on a new stable clustering scheme. In Proceeding of IEEE Military Communications Conference (MILCOM 2002) (October 2002).
Ye, W., Heidemann, J., and Estrin, D.
[41]
protocol for wireless sensor networks. In Proceedings of the IEEE Infocom (New York, NY, USA, June 2002), USC/Information Sciences Institute, IEEE, pp. 15671576.
Ye,
An energy-e cient mac
[42]
In Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies(INFOCOM 2002). Vol.3 (2002), pp. 15671576. mac protocol for wireless sensor networks. Distributed clustering in ad-hoc sensor networks: A hybrid, energy-e cient approach. In in Proceedings of IEEE INFOCOM (2004), pp. 629640.
Younis, O., and Fahmy, S.
W.,
Heidemann,
J.,
and
Estrin,
D.
An energy-e cient
[43]
[44]
Heed: A hybrid, energy-e cient, distributed clustering approach for ad hoc sensor networks. IEEE Transactions on Mobile Computing 3 (2004), 366379.
Younis, O., and Fahmy, S.
[45]
Distributed formation of overlapping multi-hop clusters in wireless sensor networks. In Proceedings of the 49th Annual IEEE Global Communication Conference (Globecom 06)) (November 2006).
Youssef, A., Younis, M., Youssef, M., and Agrawala, A.
[46]
Gs3: Scalable self-con guration and selfhealing in wireless sensor networks. pp. 5867.
Zhang, H., and Arora, A.
Appendix A Implemenation of RockAgent Class
A.1 Class
Figure A.1 shows the detailed class collaboration, including all the parameters and functions. We describe the usage of these parameters and functions in Sec. A.2.
A.2 Parameters and Functions
This section includes the usage for the parameters and functions in the RockAgent Class.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
// show detailed process or not int i s s t a r t ; // check i f started int fwdbroadcast_ ; // forward broadcast ADV or not int c t r ; // for state_update , control packets sending in a time phase int BTTL; // Broadcast ADV TTL int BBTTL; // Broadcast ADV TTL base value double T1_DURATION; // T1 time
double T2_DURATION;
int v e r b o s e ;
73
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
74
Figure A.1: RockAgent Class Collaboration Diagram
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
75
16 17 double T1_T2_DELTA; 18 19 double adv_br_interval_ ; 20 21 double WAIT_PUB_DURATION; 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62
T2 time Delta value for adjusting T1 and T2 according to l e v e l p e r i o d i c a l l y broadcast adv i n t e r v a l timeout for waiting for PUB ( for HEAD in DONE phase , recved ADV, replied SUB and wait for PUB) double TIMEOUT_RESEND; // wait time for timeout int RETRY_LIMIT; // retry time li mi t of a node trying to join c l u s t e r s int MAX_LEVEL; // max l e v e l for the hierarchical cl uste ring double done_time_point ; // record the l a s t done time int sent_pkt_num ; // record the t o t a l send number of packets int sent_msg_num ; // record the t o t a l send number of messages double i n i t _ e n e r g y ; // i n i t energy double c u r r e n t _ e n e r g y ; // current energy , only update when sending ADV ofstream LogFile ; // LogFile ofstream int t o t a l n o d e s ; // records the t o t a l nodes in the simulation double PUB_INTERVAL; // Periodically sent PUB INTERVAL int n o _ c l u s t e r ; // sig for no_cluster network int test_energy_consumption ; // sig for t e s t i n g energy consumption int f i x _ c l u s t e r ; // true i f t e s t fix_cluster , f a l s e i f not int f a u l t _ t o l e r a n c e ; // true i f t e s t f a u l t tolerance double COMPUTING_CONS; //computing overhead energy consumption for HEAD node double ENERGY_LIMIT; // energy lower limit , i f head has energy l e s s than this , send NTF RETIRE double HEAD_INFO_TIMEOUT; // for purge timeout head info in sink node double down_head_rate ; // for f a u l t tolerance test , the percentage of head to be shutdown node_entry_t bch_record ; // for debugging and solving segmentation f a u l t
// // // //
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
76
63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
// my profile , store s e l f values node_table_t ngb_table ; // neighbor t abl e node_table_t ∗ ngb_lvl_table ; // for store one l e v e l lower ADV node info node_table_t sub_table ; // sub table , when received sub , put i t in . node_table_t pub_table ; //pub table , when received pub , put i t in . node_table_t backup_table ; // backup_table , to store backup information fwd_table_t fwd_table ; // for ADV forward // sink node store head info WirelessPhy ∗ n e t i f _ ; // pointer to the network interface object Mac802_11 ∗mymac ; // pointer to the MAC layer object AODV∗ aodvagent ; // pointer to the AODV object EnergyModel ∗ energy_model ; // pointer to the EnergyModel object
Rock_State_Timer rock_state_timer_ ; − Rock_PrBrADV_Timer rock_prbradv_timer_ ; r o c k _ h e a d i n f o sink_hhead ;
profile_t profile ;
98 Rock_Timeout_Timer rock_sub_timeout_timer_ ; 99 Rock_Timeout_Timer rock_inv_timeout_timer_ ; 100 Rock_Timeout_Timer rock_ntf_timeout_timer_ ;
// for T1 T2 time up event // for p e r i o d i c a l l y broadcast ADV Rock_KeepAlive_Timer rock_keepalive_timer_ ; // for keep a l i v e in Done phase Rock_HDADV_Timer rock_hdadv_timer_ ; // for HEAD in DONE phase dealing with ADV that is one l e v e l l e s s than HEAD' s 97 // the following timers are for timeout resend event
Here are the functions in the RockAgent Class.
1 2 RockAgent ( ) ; 3
4 v i r t u a l int command ( int argc , const char ∗ const ∗ argv ) ; 5 6 ∗ ∗
// construction function // start , stop , and set variables are done here . communication with t c l ; override command in Agent Class / I n i t i a l i z a t i o n functions /
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
77
7 void i n i t _ n o d e ( ) ; 8 9 int g e t _ l o w e r _ l a y e r ( ) ; 10 11 12 ∗ ∗ 13 ∗ 14 void s t a t e _ u p d a t e ( ) ; 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
void t1_handler ( ) ; void t2_handler ( ) ; void done_handler ( ) ; void t1_time_up ( ) ;
// i n i t i a t e the node i t s e l f // get pointers to the lower layer / Timer functions / / Handlers for time stat events ∗ / // state_update for time_driven event and handlers // The following are handlers for T1, T2 and Done time state events
/ ∗ Callback functions for timers dealing with time −up events ∗ / // T1 time up callback void t2_time_up ( ) ; // T2 time up callback void hd_adv_timer_callback ( ) ; // callback function for rock_hdadv_timer , dealing with one l e v e l l e s s ADV void k e e p _ a l i v e ( Rock_KeepAlive_Timer ∗ t i m e r ) ; //In Done phase , execute periodical tasks void t i m e o u t _ c a l l b a c k ( msg_type_t type ) ; // timeout resend callback function void c a n c e l _ a l l _ t i m e r s ( ) ; //Cancel a l l timers / ∗ Handlers for message events ∗ / v i r t u a l void r e c v ( Packet ∗ , Handler ∗ ) ; // callback function for receiving a Rock AGT packet ; override recv in Agent Class // handlers for d i f f e r e n t types of message
void void void void void void void
ADV_handler ( Packet ∗ SUB_handler ( Packet ∗ PUB_handler ( Packet ∗ INV_handler ( Packet ∗ NTF_handler ( Packet ∗ ACK_handler ( Packet ∗ DET_handler ( Packet ∗ pkt ) ; pkt ) ; pkt ) ; pkt ) ; pkt ) ; pkt ) ; pkt ) ;
void si n k _ r e c v _ h a n d l e r ( Packet ∗ pkt ) ;
// for handling PUB msg received by sink / ∗ Message sending functions ∗ / // general send functions for SUB, PUB INV, NTF etc .
void send_msg ( int type , node_entry_t ∗ entry , Packet ∗ pkt ) ;
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
78
53 54 55 56 57 58 59 60
void send_ADV ( ) ; void send_SUB ( node_entry_t ∗ e n t r y ) ; void s u b s c r i b e _ t a b l e ( node_table_t ∗ t a b l e ) ; void void void void
//send sub to a l l the entry in the ta bl e
; 61 void send_DET( uint16_t b c h i d ) ; 62 63 int forward_Broadcast_ADV ( Packet ∗ pkt ) ; 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93
send_PUB( node_entry_t ∗ e n t r y ) ; send_INV ( node_entry_t ∗ e n t r y ) ; send_NTF( uint16_t i d ) ; send_ACK( node_entry_t ∗ entry , uint16_t seq , msg_type_t type )
//send DET from head to BCH for l ink broken detection // forward broadcast ADV messages ; return 1 i f the packet needs forwarding ; return 0 i f not . / ∗ Table functions ∗ / int update_node_table ( node_table_t ∗ t a b l e , Packet ∗ pkt ) ; // return the update entry index in the node table , i f not updated , return −1 void c l e a r _ t a b l e ( node_table_t ∗ node_table ) ; // clear one ta bl e void c l e a r _ t a b l e s ( ) ; // clear a l l t a b l e s int d e l _ r e c o r d _ i n _ t a b l e ( node_table_t ∗ node_table , uint16_t i d ) ; // delete a record from a table , return 1 i f succeed in deleting , return 0 i f not int i s _ i n _ t a b l e ( node_table_t ∗ t a b l e , uint16_t i d ) ; // i f in table , return the index ; ; i f not , return −1 node_entry_t ∗ find_top_energy_record ( node_table_t ∗ t a b l e ) ; // return the pointer to the record with the l a r g e s t energy in the tab le ; return NULL i f ta bl e empty node_entry_t ∗ f i n d _ r e c o r d ( uint16_t id , node_table_t ∗ t a b l e ) ; // find a record based on id , return that record i f found ; return NULL i f not int t a b l e _ p u r g e ( node_table_t ∗ t a b l e ) ; // for maintain t ab le and delete outdated records / ∗ List Functions ∗ /
void i d _ i n s e r t ( uint16_t id , uint8_t l e v e l ) ; void id_remove ( uint16_t i d ) ; void id_purge ( ) ; int id_total_number ( ) ; void determine_ch ( ) ;
HeadInfo ∗ id_lookup ( uint16_t i d ) ;
94 b o o l select_BCH ( ) ;
/ ∗ Other functions ∗ / // c a l l ed when T1 times up , the nodes s e l f determines whether i t is Head
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
79
95 96 void BCH_takeover ( ) ; 97 98 99 100 101
// s e l e c t BCH, return f a l s e i f failed , return true i f ok // get the pointers of the MAC and WirelessPhy layers , return TCL_OK or TCL_ERROR void count_pkt_msg ( int fwd ) ; // count the t o t a l sent msg and t o t a l sent pkt void shutdown ( ) ; //shutdown the node
Appendix B Usage of RockAgent
We list the RockAgent parameters and commands in TCL and explain their usage in this part.
1 2 3 set r o c k a g e n t [ new Agent /Rock ] 4 5 6 $ns attach − agent $node_ ( $count ) $ r o c k a g e n t 7
# the following is about our RockAgent Usage # set a new rock agent
The following code explains how to new a rock agent in a TCL script.
# attach i t to the node
The following part explains the usage of RockAgent parameters.
1 $ r o c k a g e n t set ADV_broadcast_interval_ 1 2
3 4 $ r o c k a g e n t set forward_broadcast_ADV_ t r u e 5 6 7 $ r o c k a g e n t set v e r b o s e t r u e 8
# set the i n t e r v a l of p e r i o d i c a l l y broadcast ADV in T1 phase, default value is 1 # set true i f a node forward others ADV, f a l s e not, default is false # set true i f you want to see a l l logs and outputs during run time, set f a l s e not # no longer used, set the p a c k e t s i z e , now could control by the class i t s e l f # set the base ADV TTL value, default is 2
80
9 10 $ r o c k a g e n t set p a c k e t S i z e _ 20 11 12 13 $ r o c k a g e n t set BTTL_ 2 14
APPENDIX B.
USAGE OF ROCKAGENT
81
15 16 $ r o c k a g e n t set T1_DURATION_ 2 17 18 19 $ r o c k a g e n t set T2_DURATION_ 4 20 21 22 $ r o c k a g e n t set T1_T2_DELTA 0 . 5 23
# set the T1 duration, default is 2 sec # set the T2 duration, default is 4 sec # set the delta value for increase of T1 and T2 per l e v e l up, default value is 0 .5 sec # set the time length for a CH to block ADV and wait for PUB. default value is 5 sec # set the timeout time, default value is 1 sec # set the retry li mi t for rounds, default is 5 # set the max l e v e l a node could reach, default is 1 , which means a f l a t c l u s t e r . ( node l e v e l s t a r t s from 0) # no longer used, the code can get the init_energy automatically # t e l l a node the t o t a l number of nodes in the simulation # set duty cycle l e n g t h , default is 5 # set the sink node address
$ r o c k a g e n t set s i n k $ v a l ( nn ) $ r o c k a g e n t set PUB_INTERVAL 5 $ r o c k a g e n t set t o t a l n o d e s $ v a l ( nn ) $ r o c k a g e n t set i n i t _ e n e r g y 100
24 25 $ r o c k a g e n t set WAIT_PUB_DURATION_ 5 26 27 28 $ r o c k a g e n t set TIMEOUT_RESEND 1 29 30 31 $ r o c k a g e n t set RETRY_LIMIT 2 32 33 34 $ r o c k a g e n t set MAX_LEVEL 1 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
51 52 $ r o c k a g e n t set f i x _ c l u s t e r f a l s e 53
# set true i f simulate non − cluster network, f a l s e i f not, default is f a l s e # set true i f simulate fix_cluster (no delegation, a CH w i l l shutdown i t s member i f the CH f a i l s ) , default is f a l s e # set true i f t e s t energy consumption
$ r o c k a g e n t set n o _ c l u s t e r f a l s e
54 55 $ r o c k a g e n t set test_energy_consumption f a l s e 56 57 ( t h e node w i l l p e r i o d i c a l l y send PUB t o CH and CH a l s o send t o t h e s i n k node ) , default i s f a l s e
APPENDIX B.
USAGE OF ROCKAGENT
82
58 59 $ r o c k a g e n t set f a u l t _ t o l e r a n c e f a l s e 60
61 62 $ r o c k a g e n t set Computing_Energy_Consumption 0 . 0 0 0 0 8 7 4 1 5 63 set t h e computing e n e r g y consumption for data a g g r e g a t i o n e v e r y duty c y c l e J o u l e . D e f a u l t i s 0 . 0 0 0 0 8 7 4 1 5 J o u l e 64 65 $ r o c k a g e n t set ENERGY_LIMIT 10 66 67 default v a l u e i s 10 J o u l e 68 69 $ r o c k a g e n t set down_head_rate 0 . 1 70
# set true i f need f a u l t tolerance ( Function Delegation ) support, default is f a l s e
# set the Energy Low l i m i t . I f a CH detects i t s energy l e s s than t h i s value, i t w i l l t r i g g e r BCH take over. # In f a u l t tolerance t e s t , the percentage of CHs in the network to be shut down. default is 0 .1 (10%)
The following part introduces the commands that could be called in a TCL script:
1 2 $rockagent s t a r t 3 4 5 $rockagent stop 6
# s t a r t the rock agent # stop the rock agent, actually just print out something, write log f i l e and do not actually stop # shutdown the rock agent, also shutdown the r e l a t i v e energy_model and the WirelessPhy o b j e c t . Usually ju st executed in the code, not d i r e c t l y in a t c l s c r i p t # No longer used. Re initiate a node. #Only excute when the rockagent is on the sink node. Shutdown certain percentage of Chs randomly at the c a l l i n g time. # d i r e c t l y change the energy value in the enery_model o b j e c t .
7 8 $ r o c k a g e n t shutdown 9
10 11 $ r o c k a g e n t r e s t a r t 12 − 13 14 $ r o c k a g e n t sink_shutdown_random_head 15 16 17 $ r o c k a g e n t s e t − e n e r g y $ v a l u e 18
Yi Gong
A Flexible Simulation Framework for Hierarchical Clustering on Wireless Sensor Networks
Master's Thesis Espoo, June 30, 2010
Supervisors: Professor Antti Ylä-Jääski, Aalto University Assistant Professor Markus Hidell, The Royal Institute of Technology Instructor: Pin Nie M.Sc. (Tech.), Aalto University
Aalto University School of Science and Technology Faculty of Information and Natural Sciences Degree Programme of Security and Mobile Computing
ABSTRACT OF MASTER'S THESIS
Author: Yi Gong Title of thesis:
A Flexible Simulation Framework for Hierarchical Clustering on Wireless Sensor Networks
Date: June 30, 2010 Pages: 10 + 82 Professorship: Data Communications Software Code: T-110 Supervisors: Professor Antti Ylä-Jääski Assistant Professor Markus Hidell Instructor: Pin Nie M.Sc. (Tech.)
In Wireless Sensor Networks, a clustering algorithm is a good option to reduce redundant data transmission and organize nodes e ciently for long life span. In this thesis, we mainly introduce, implement and evaluate a novel exible hierarchical clustering algorithm on middleware layer based on Publish/Subscribe paradigm. The goal of our algorithm is to provide the ve features, scalability, energy e ciency, fault tolerance, load balancing and multi-level clustering. Our algorithm includes three protocols. Flat Clustering protocol constructs a 2-level clustering network structure. Function Delegation protocol provides the fault tolerance and load balancing features. Multi-Level Clustering protocol builds up a more than 2-level clustering network structure. The thesis also studies several popular simulators and explicates the design and implementation of our algorithm on the ns-2 simulator. Then, we evaluate the algorithm from dierent angles. Based on our simulation, we optimize key parameters for our algorithm and nd that the performance and the energy e ciency of our algorithm are promising, especially in the bridge topologies.
Keywords: Language:
Wireless Sensor Network, Hierarchical Clustering Algorithm, Simulation, NS-2 English
ii
Abstrakt
I trådlösa sensornätverk är ett kluster algoritm ett bra alternativ för att minska överflödig dataöverföring och organisera noder effektivt för lång livslängd. I denna avhandling presenterar vi i första hand, genomför och utvärderar en ny flexibel hierarkisk klustring algoritm på mellanprogram skikt baserat på Publish/Subscribe paradigm. Målet med vår algoritm är att ge de fem funktioner, skalbarhet, energieffektivitet, feltolerans, lastbalansering och flera nivåer klustring. Vår algoritm omfattar tre protokoll. Flat Clustering protokoll konstruerar en 2-nivå klustring nätstruktur. Function Delegation protokollet ger feltolerans och lastbalansering funktioner. Multi-Level Clustering protokoll bygger upp en mer än 2-nivå klustring nätstruktur. Avhandlingen undersöker också flera populära simulatorer och tydliggör utformningen och genomförandet av vår algoritm på ns-2 simulator. Därefter utvärderar vi algoritmen från olika vinklar. Baserat på vår simulering, optimering vi nyckelparametrar för vår algoritm och upptäcker att prestanda och energieffektivitet i vår algoritm är lovande, särskilt i bro topologier.
Nyckelord:
NS-2
Trådlöst Sensornätverk, Hierarkisk Klustring Algoritm, Simulering,
iii
Acknowledgements
This study was carried out at the data communications software research lab in School of Science and Technology, Aalto University, Espoo, Finland. First of all, I would like to thank Prof. Antti Ylä-Jääski (Aalto University) and Assistant Prof. Markus Hidell (KTH). Their high-level guidance and supervision pointed out a clear direction for my research. Also, I would like to express my gratitude to my instructor, Pin Nie (Aalto University) who had been working closely with me. His instructions provided a great deal of help and valuable suggestions for my study and always kept me on the right track. Furthermore, I would also like to thank all my colleagues, Zhihua Jin, Bo Li, Andre Schumacher and Shekar Nethi for their support of my work. Finally, I would like to address my deepest gratitude to my family and friends for providing support during my studies.
Espoo, June 30, 2010
Yi GONG
iv
Abbreviations and Acronyms
ACA AODV BCH CH CM DSDV DSR GPSR IC ISMO LR-WPAN OOP SH WSN Autonomous Component Architecture Ad hoc On-Demand Distance Vector Routing Backup Cluster Head Cluster Head Cluster Member Destination-Sequenced Distance-Vector Routing Dynamic Source Routing Greedy Perimeter Stateless Routing Integrated Circuit Intelligent Structural Health Monitoring System Low-Rate Wireless Personal Area Network Object Oriented Programming Cluster Sub-Head Wireless Sensor Network
v
Contents
Abbreviations and Acronyms 1 Introduction
1.1 1.2 1.3 1.4 1.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . Objectives and Scopes . . . . . . . . . . . . . . . . . . . . . . Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . .
v 1
1 3 4 5 6
2 Clustering Algorithm
2.1 2.2 2.3 2.4 2.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . De nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8 8
Flat Clustering Protocol . . . . . . . . . . . . . . . . . . . . . 10 Function Delegation Protocol . . . . . . . . . . . . . . . . . . 13 Multi-Level Clustering Protocol . . . . . . . . . . . . . . . . . 16
3 Current State of Simulator
3.1 3.2 3.3 3.4 J-Sim
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Implementation
4.1 vi
23
Protocol Stack and Platform . . . . . . . . . . . . . . . . . . . 23
4.2 4.3 4.4 4.5 4.6
Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Main Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Flat Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Function Delegation . . . . . . . . . . . . . . . . . . . . . . . 34 Multi-Level Clustering . . . . . . . . . . . . . . . . . . . . . . 36
5 Evaluation
5.1 5.2 5.3
39
Simulated Environment . . . . . . . . . . . . . . . . . . . . . . 39 Test Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Simulation Analysis . . . . . . . . . . . . . . . . . . . . . . . . 43 5.3.1 5.3.2 5.3.3 Flat Clustering . . . . . . . . . . . . . . . . . . . . . . 43 Delegation Protocol . . . . . . . . . . . . . . . . . . . . 54 Hierarchical Clustering . . . . . . . . . . . . . . . . . . 57
6 Conclusion and Future Work
6.1 6.2
67 73 80
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A Implemenation of RockAgent Class B Usage of RockAgent
A.1 Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2 Parameters and Functions . . . . . . . . . . . . . . . . . . . . 73
vii
List of Tables
3.1 5.1 5.2 5.3 5.4 Comparison of dierent simulators . . . . . . . . . . . . . . . 21
ns2 Energy Model . . . . . . . . . . . . . . . . . . . . . . . . . 41 Flat clustering results . . . . . . . . . . . . . . . . . . . . . . . 54 Hierarchical clustering results in the bridge case . . . . . . . . 64 Hierarchical clustering results in the matrix case . . . . . . . . 65
viii
List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 3.1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Network architecture . . . . . . . . . . . . . . . . . . . . . . . 8 Flat clustering protocol . . . . . . . . . . . . . . . . . . . . . . 11 Node joins an existing cluster . . . . . . . . . . . . . . . . . . 12 Delegation protocol . . . . . . . . . . . . . . . . . . . . . . . . 14 SUB lost during the process of delegation . . . . . . . . . . . . 15 Hierarchical clustering protocol . . . . . . . . . . . . . . . . . 16 Comparison of dierent simulator packages . . . . . . . . . . . 21 General protocol stack of a node . . . . . . . . . . . . . . . . . 24 Modi ed schematic of a node under the CMU monarch wireless extensions to ns [22] . . . . . . . . . . . . . . . . . . . . . . . 25 Simple RockAgent class collaboration diagram . . . . . . . . . 26 General packet structure . . . . . . . . . . . . . . . . . . . . . 29 Message driven handlers . . . . . . . . . . . . . . . . . . . . . 31 Time driven handlers . . . . . . . . . . . . . . . . . . . . . . . 31 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Flat clustering state diagram . . . . . . . . . . . . . . . . . . . 33 Delegation state diagram . . . . . . . . . . . . . . . . . . . . . 35
4.10 Hierarchical clustering state diagram . . . . . . . . . . . . . . 37 5.1 5.2 5.3 Bridge and matrix topologies with diagonal connection . . . . 40 Isolated nodes number in the bridge case . . . . . . . . . . . . 44 Isolated nodes number in the matrix case . . . . . . . . . . . . 44
ix
5.4 5.5 5.6 5.7 5.8 5.9
Convergence time in the bridge case . . . . . . . . . . . . . . . 46 Convergence time in the matrix case . . . . . . . . . . . . . . 47 System energy consumption regarding to nodes number in the bridge case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 System energy consumption regarding to nodes number in the matrix case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Saved system energy percentage in the bridge case . . . . . . . 50 Saved system energy percentage in the matrix case . . . . . . 51
5.10 System energy consumption regarding to duty cycle in the bridge case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.11 System energy consumption regarding to duty cycle in the matrix case . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.12 Recovery time in the bridge case . . . . . . . . . . . . . . . . . 55 5.13 Recovery time in the matrix case . . . . . . . . . . . . . . . . 56 5.14 Convergence time in the 3-level clustering bridge case . . . . . 58 5.15 Convergence time in the 4-level clustering bridge case . . . . . 58 5.16 Convergence time in the 3-level clustering matrix case . . . . . 59 5.17 Convergence time in the 4-level clustering matrix case . . . . . 59 5.18 System energy consumption regarding to node numbers in the hierarchical bridge case . . . . . . . . . . . . . . . . . . . . . . 61 5.19 System energy consumption regarding to node numbers in the hierarchical matrix case . . . . . . . . . . . . . . . . . . . . . 62 5.20 System energy consumption regarding to duty cycle in the hierarchical bridge case . . . . . . . . . . . . . . . . . . . . . . 63 5.21 System energy consumption regarding to duty cycle in the hierarchical matrix case . . . . . . . . . . . . . . . . . . . . . 65 A.1 RockAgent Class Collaboration Diagram . . . . . . . . . . . . 74
x
Chapter 1 Introduction
With the eye-catching development in Wireless Sensor Networks (WSN), there are various emerging applications, such as monitoring structural health, hazardous area surveillance and disaster management. For instance, sensors could be deployed on a bridge to sample vibrations in dierent places and adopt algorithms such as [24] to monitor structural health. In these applications, sensor nodes have the capability of detecting surrounding conditions, such as vibration, temperature and illumination. And these sensors are usually low cost tiny nodes with limited energy and data processing capability, and need to communicate with each other to establish a dedicated network for a prede ned mission. Such applications face several challenges, such as multi-hop communication, large scalability, and how to organize nodes e ciently for long life span. Recently researchers have focused on grouping sensor nodes into clusters. The main idea of clustering is to organize nodes into a cluster structure. Every cluster has a leader and several members, named cluster head(CH) and cluster member(CM) respectively. Normally in a cluster, CMs communicate with its CH and the CH is responsible for the communication with nodes outside the cluster. With clusters, a WSN is able to achieve large scalability, provide reachability, conserve communication bandwidth, stabilize a network topology and aggregate data.
1.1 Related Work
Researchers have designed and developed lots of standards and protocols to solve problems regarding to communication, scalability, energy e ciency and 1
CHAPTER 1.
INTRODUCTION
2
so on. IEEE 802.15.4 [37] has become a popular standard which speci es the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs). Based on the IEEE 802.15.4, speci cations attempt to oer complete solutions to WSN with upper layer supports, such as ZigBee [15], WirelessHART [13] and MiWi [23]. In addition, recently several modi cations [33, 41] of IEEE 802.11 [14] are also available for WSN considering energy e ciency. Several ad-hoc routing protocols have been applied in WSN to provide multihop routing, such as Ad hoc On-Demand Distance Vector (AODV) routing [35], Destination-Sequenced Distance-Vector (DSDV) routing [36] and Dynamic Source Routing (DSR) [29]. Finally, a number of clustering algorithms have been designed for WSNs [32]. Existing clustering solutions can save energy and extend system lifespan by grouping sensor nodes into clusters and employing data aggregation at cluster heads(CH). Clustering has the following advantages. Firstly, clustering originally aims at providing great scalability for WSNs because a network cannot maintain a large number of nodes only with MAC standards and multi-hop routings. Furthermore, clustering could stabilize the network topology and also reduce the maintenance overhead. Moreover, clustering can conserve communication bandwidth because it limits the communications between CMs and a CH within a cluster and reduce the redundant data transmission among sensor nodes. Finally, data aggregation algorithms could be applied on CHs to further reduce the transmission data and relaying messages, thus prolonging the life span of clusters. There are numerous clustering algorithms proposed for WSNs [27, 20, 25, 18, 40, 34, 46, 16, 21, 45, 19, 17, 43]. Usually, these algorithms focus on the following ve features, scalability, fault tolerance, load balancing, energy e ciency and multi-level clustering, but few of them could provide all these features. Algorithms such as [40, 34, 27] usually use random number based mechanisms to select CHs and form clusters. For instance, [40] uses random time and Node ID together to select CHs, [34] counts down a random integer and [27] uses probability to decide CHs. However, such a way to select CHs ignores the residue energy on those nodes, thus causing a good probability of a low energy node selected as a CH. As a CH usually consumes more energy than normal nodes, a cluster with a low energy CH will fail quite soon. Algorithms such as [44, 21] take residue energy of a node and probability together into consideration while selecting CHs. [44] goes through three time phases, Initialization, Repetition, and Finalization phase, to form clusters
CHAPTER 1.
INTRODUCTION
3
and takes residue energy and probability into consideration while deciding CHs in the rst phase. And [21] also considers residue energy and could achieve more well-balanced cluster sizes than [44] in a network. However, they do not specify whether their algorithms provide fault tolerance for CHs and load balancing among nodes. Without fault tolerance for CHs, a single CH failure will result in the failure of its whole cluster, not to mention failures of multiple CHs. And load balancing among nodes could prolong the life span of clusters. Algorithms such as [46, 18, 45, 25] all have the feature of self maintenance and could recover from nodes failure usually by associating a node with multiple CHs or other methods. However, the methods usually result in clustering overlapping, which could complicate the association management and cause extra energy consumption. A better way is to assign a backup CH to deal with CHs failure and reduce the clustering overlapping. Algorithms [20, 16] could form a cluster structure with more than 2 levels. With a multi-level clustering structure, it is possible to apply more complex distributed algorithms in networks and is probably to be more energy e cient. But [20] does not take energy into consideration while selecting CHs, and [16] does not specify whether it supports self maintenance feature to recover from CH failure. Finally, the algorithm [19] could form a network with high average of cluster sizes but [19] does not support multi-level clustering and does not specify whether it takes residue energy into consideration while selecting CHs. Based on the above discussions, few clustering algorithms could take scalability, load balancing, fault tolerance, energy e ciency and multi-level clustering together into consideration. Furthermore, the above mentioned solutions are usually tightly coupled with lower layers or speci c to certain application so that it is di cult to change the lower layer protocols. And due to the constraints of the lower layer implementation and complex hardware details, developers face numerous challenges for application development[26].
1.2 Problem Statement
There are mainly four challenges in WSNs: 1. MAC standards and routing protocols are not enough to e ciently organize a large scale WSN with numerous nodes, especially in the condition that each node sends data to the sink node simultaneously
CHAPTER 1.
INTRODUCTION
4
and periodically. 2. A WSN usually contains a large number of nodes capable of sampling data at high rates and generating huge volumes of data. These huge data consume limited resources on the nodes and often result in redundant data transmission, which consumes bandwidth and battery. In most cases, network communication is the main source of power consumption in WSN [28]. 3. Nodes in WSNs usually have limited battery, which causes heavy energy constraint on WSN applications for long lifespan. 4. Large sampled data may expire during the forwarding process before they reach the sink node due to long latency in wireless transmission, thus resulting in extra consumptions on limited resources in the whole network. In addition, clustering algorithms also faces the following two challenges: 1. Existing cluster algorithms usually focus on certain features while missing other features. Few of them could take scalability, load balancing, fault tolerance, energy e ciency and multi-level clustering structure all into consideration. 2. Existing solutions are usually tightly coupled with lower layers or speci c to certain application so that it is di cult for application layer development as well as lower layer modi cations. In general, in order to solve all the above mentioned problems, there needs a novel clustering algorithm for sensor nodes to aggregate data so as to reduce redundant transmissions, perform localized computation so as to increase non-volatile information throughput, and optimize energy consumption so as to prolong the system lifespan.
1.3 Objectives and Scopes
According to Sec. 1.1, existing cluster algorithms are inadequate to solve the problems mentioned in Sec. 1.2. So, in order to tap into the full the favorable aspects of the existing algorithms while avoiding the unfavorable ones, we introduce a generic novel exible hierarchical clustering algorithm
CHAPTER 1.
INTRODUCTION
5
on middleware layer based on Publish / Subscribe paradigm. The algorithm takes scalability, load balancing, fault tolerance, energy e ciency and multilevel clustering all into consideration. Moreover, our algorithm serves as a middleware-based approach, which hides the low layer details and provides uniform friendly interfaces for the upper layer, thus easing application development. Furthermore, our algorithm is loosely coupled with lower layers, thus capable of working on dierent routing protocols and MAC standards. In addition, with the Publish/Subscribe paradigm, our algorithm could support great network scalability as well as provides topology exibility. And our algorithm includes three protocols, namely protocol, protocol and protocol aiming at constructing a multi-level cluster structure in a WSN from the bottom up.
tion Delegation
Flat Clustering Hierarchical Clustering
Func-
In order to validate the design of this new algorithm and evaluate its performance in a relatively short period with low expense, we decide to simulate this algorithm on a simulator. There are several popular simulators including NS-2 [9], J-Sim [6], OMNeT++ [12] and so on. NS-2 is a well-known, open-source discrete event network simulator popular in academia for its extensibility and plentiful online documentation. J-Sim is a component-based, compositional simulation environment based on the autonomous component programming model. OMNeT++ is also a component-based, modular and open-architecture discrete event network simulator with many simulation frameworks. We also refer to a survey [38], look into and test dierent simulators. Finally, we design, implement and simulate a exible simulation framework for this algorithm on the NS-2 simulator and gain several results considering protocol performance and energy e ciency. Based on our simulation, we optimize key parameters for our algorithm and nd that the performance and the energy e ciency of our algorithm are promising, especially in the bridge topologies.
1.4 Methods
Four main research methods are applied in this thesis. These are:
• Literature review • Simulator survey • Design and implementation • Simulations and results analysis
CHAPTER 1.
INTRODUCTION
6
Literature review builds up a sound foundations for this thesis work. In addition, simulator survey provides the understandings of advantages as well as disadvantages of dierent simulators and helps us select the suitable simulator for our work. Moreover, design and implementation on a simulator provide the basis for simulations. Finally, simulations and results analysis help us to validate and optimize our original design as well as evaluate our algorithm in all aspects.
1.5 Structure of the Thesis
In the following sections, Chapter 2 rst explains our framework for the clustering algorithm including its three protocols. Then, we look into and analyze three popular simulators, J-Sim, OMNeT++ and NS-2 in Chapter 3. In Chapter 4 there is a detailed description of our implementation on NS2. After that, Chapter 5 explicates the simulation criteria and test cases, lists and analyzes the simulation results. Finally, we conclude our work in Chapter 6.
Chapter 2 Clustering Algorithm
In this chapter, we introduce our clustering algorithm, which consists of three protocols, Flat Clustering Protocol, Function Delegation Protocol and Multi-level Clustering Protocol. We give detailed explanations of the three protocols and also show their sequence diagrams. In addition, since we nd some aws during the implementation and simulation, we also make some improvements to the original design. Our clustering algorithm has the following advantages. With our algorithm, the network could form a cluster structure from the bottom up and all nodes are self-adaptive, which means users do not need to specify the role for each node beforehand. When nodes initiate and try to form the structure, they will decide roles and actions by themselves. Moreover, our clustering algorithm is a location-based, Pub/Sub middleware and able to control the formation of clusters. Therefore, it oers more exibility for application developers to adjust the clustering scope and granularity to ful ll the requirements of the application services while developers could also select the lower layer routing protocols and MAC standards according to the real requirements. In addition, our algorithm could form a cluster structure network with fault tolerance and load balancing features because the second function delegation protocol could handle the failure of heads in the structure. Furthermore, since our algorithm supports multi-level clustering structure with 3 or even more level clusters, this kind of multi-level structure could enable the network to be more energy e ciency in some cases according to our simulation in Sec.5.
7
CHAPTER 2.
CLUSTERING ALGORITHM
8
Sink Node
CH(2)
CH(1)
SH(1)
SH(1)
Node
CM(0) CM(0)
CM(0)
CM(0)
CM(0)
CM(0)
CM(0)
Figure 2.1: Network architecture
2.1 Architecture
Generally speaking, our algorithm aims at forming a wireless sensor networks into the following logic cluster structure shown in Figure 2.1. The number in the brackets in the gure represents the level of a node. From left to right, rst there is a single node that does not join a cluster. We consider it is a newly initiated node trying to join a cluster nearby. Then, beside that node, there is a at (2-level) cluster which consists of a level-1 CH (Cluster Head) and two level-0 CMs (Cluster Member). In the at cluster, CMs send data to the CH, and the CH aggregates the received data and sends the merged data to the sink node. In the right part of the gure, there is a multi-level (3-level) cluster composed of two at clusters. The heads of the two at clusters now serve as SH (Sub Cluster Head) and send the aggregated data to their CH instead of the sink node. The level-3 CH further aggregates the data and then sends the merged data to the sink node. Hence, the data ow is from the bottom up in this structure.
2.2 De nitions
Before the introduction of the three protocols, we need to de ne four roles of a node, six message types and three time phases.
CHAPTER 2.
CLUSTERING ALGORITHM
9
Firstly, a node in our clustered network could have 4 roles, , , and . stands for a node which just starts and does not join a cluster. always stands for a level-0 node which has already joined a cluster and sends data to its CH periodically. stands for a node which is the top head for a cluster. It receives all data from its CMs or SHs, aggregates and sends them to the sink node. Finally, stands for a node which is a head but not the top head in a multi-level cluster. A SH receives data from its CMs or SHs, aggregates and sends them to its upper CH or SH.
(Cluster Member) CH (Cluster Head) Node CH SH
Node CM SH (Sub Cluster Head) CM
In addition, our algorithm de nes 6 types of messages:
• ADV: ADV stands for "Advertise". ADV contains the energy, the level, the capability and the location of the sending node. The energy contains the residue energy value of the sending node. The level is the current level of the sending node. The capability tells what kind of data the sending node could provide, for instance, illumination, temperature etc. And the location tag shows the location of the sending node. Nodes only form clusters among the ones with the same location tag. So, when nodes start, they broadcast ADVs to others to exchange necessary information and declare their appearance. • SUB: SUB stands for "Subscribe". A CH usually sends SUB to recruit nodes. SUB also contains the type of data that the CH is interested in so that the receiver could send that kind of data to the CH in the future if it joins that cluster. • PUB: PUB stands for "Publish". There are two cases that a node sends PUB. In one case, when a node receives SUB from a CH, it immediately sends back PUB to the CH to acknowledge its participation to its cluster. In another case, when a CM has entered the stable state, it periodically sends PUB to the CH which contains the interested data. • INV: INV stands for "Invite". When nodes form a cluster, the CH usually selects a node with the highest energy as its backup CH. Then the CH sends INV which contains all the details of its current members to that node. On receiving INV, that node stores the information and becomes BCH (Backup Cluster Head). In case that the CH fails, the BCH could take over the cluster immediately with the previously received information. • NTF: NTF stands for "Notify". It has several options, such as RETIRE etc. Generally speaking, usually this message is sending from a head
CHAPTER 2.
CLUSTERING ALGORITHM
10
to its BCH to notify a certain event.
• ACK: ACK stands for "Acknowledge". Nodes usually send this message to acknowledge the receiving of certain messages, such as PUB, INV and NTF.
Moreover, in order to form a cluster structure by our algorithm, a node usually need to go through three time phases, , and . In time phase, a node usually broadcasts ADVs which contain the energy value of the sending nodes and stores the information of received ADVs. In time phase, CHs usually send SUB messages to recruit members. Other nodes wait for SUB messages, and reply with PUB messages on receiving SUB to con rm its participation in a cluster. On receiving a PUB message, a CH considers the sender as its member and sends back ACK. On receiving ACK, a node considers ACK as the con rmation for its participation and becomes a CM. phase is a stable phase. After nodes have joined a cluster, they all go to DONE phase and perform certain actions periodically depending on their roles. For instance, in DONE phase, a CM periodically sends data to its CH.
T1 T2
T1 T2
DONE
DONE
2.3 Flat Clustering Protocol
Flat Clustering Protocol is the basic protocol for our clustering algorithm and forms a network into a at (2-level) clustering structure. Figure 2.2 shows the process of the basic at clustering protocol. When nodes initiate, they immediately go into T1 phase. Then, during T1 phase, nodes broadcast ADV messages. An ADV message contains four kinds of important information, the location, the level, the capability and the energy value of the sending node. The location tag enables location based clustering. A node only receives messages with the same location tag as its own. Therefore, a cluster only contains nodes with the same location tag. In addition, for the at clustering protocol, a node in this time phase only receives ADVs with the same level as its own. Furthermore, the capability contains the capabilities of the sending node, which could be useful for the application services. For instance, if a node could sample temperature and illumination, the capability will contain these two types. Moreover, the energy value represents the residue energy of a sending node. When a node receives an ADV message, it caches all the information. And when T1 phase times up, nodes decide whether it could be a CH according to the residue
CHAPTER 2.
CLUSTERING ALGORITHM
11
Node
Node
Node
Periodically Broadcast ADV Periodically Broadcast ADV T1
CH
SUB SUB T2 PUB PUB ACK
CM
ACK
CM
Figure 2.2: Flat clustering protocol
energy locally. If the energy value of a node itself is the largest among all the energy values it receives, it will promote to be a CH. Then, all nodes go into T2 phase. In T2 phase, in order to recruit members, a CH rst sends SUB messages to all the nodes that it has received their ADV messages during T1 phase. The SUB message contains the capabilities (types of data) that the CH wants to subscribe. Upon receiving a SUB message, the node caches the SUB information and sends back a PUB message with its own residue energy. Upon receiving the PUB message, the CH considers the sender has become its member and sends back an ACK message for acknowledgement. Upon receiving the ACK message, the node now knows it has already joined the cluster and becomes a CM. When T2 times up, all nodes go to DONE phase. DONE phase is a stable phase and it has no time limit. During DONE phase, CMs send data to its CH and CHs aggregate the received data and send the merged data to the sink node. For this basic at clustering protocol, we have improved the original design in the following aspect. In the original design, there is no ACK message
CHAPTER 2.
CLUSTERING ALGORITHM
12
from CH to nodes for acknowledgement. We add this ACK due to the reason that any message could be delayed or lost during the transmission. Without ACK, a node considers it has already joined the cluster and become CM when it receives SUB. If the PUB message is lost or does not arrive at the CH in time during T2 phase, the CH actually does not recruit this node. Then in DONE phase, the CM sends data to the CH but the CH discards the data because it is not its member. And currently, we have no mechanism for CH to inform CM this issue. We could design such a mechanism but it delays that node to realize this issue. The node has already been in DONE phase for some time and needs to go back to T1 phase again, thus increasing the time for forming the structure. What's worse, the node may not need to send data immediately in DONE phase, thus dramatically increasing the detection time. We can solve this issue by an extra ACK. In this case, a node only con rms its participation on receiving ACK from its CH. So, if the PUB is lost or does not arrive in time, the node will directly go back to T1 phase when T2 phase times up because it will not receive ACK. Moreover, if the ACK is lost, the case is that the CH considers the node has joined its cluster but actually not. In this case, the CH could recruit the node immediately when it receives the ADV of the node again. And if the node joins another cluster, the CH could purge the record for this node by a timeout mechanism.
Node Broadcast ADV T1 SUB PUB ACK
CH
DONE
T2
CM
Figure 2.3: Node joins an existing cluster
CHAPTER 2.
CLUSTERING ALGORITHM
13
Besides of the condition in Figure 2.2, in a network there exists the situation that a node could join an existing cluster as shown in Figure 2.3. In such a case, on receiving an ADV, if the CH could recruit more members, it sends back a SUB message. On receiving the SUB message, the node immediately switches from T1 phase to T2 phase and replies with a PUB message. Then the CH replies with ACK and recruits this node. Finally the node receives the ACK message and becomes a CM. Moreover, if a SUB, PUB or ACK message is lost during the transmission, after T2 times up the node will go back to T1 phase and try to join a cluster again. We also improve the original design in this condition. A node will go directly into T2 time phase if it receive a SUB message from a CH during T1 time phase. In the original design, during T1 phase, a node caches or blocks SUB messages instead of directly going to T2 phase. Obviously, either caching or blocking SUB messages will results in the delay or even the failure for a node to join an existing cluster. So the improvement both exceeds the time and increases the probability for forming clusters. And we also apply this improvement to the basic at clustering process in Figure 2.2.
2.4 Function Delegation Protocol
In WSNs, nodes are prone to various failures, such as loss of connectivity due to low quality communications, battery depletion, and malfunction hardware owing to harsh environment. Usually, deployment of redundant nodes could relieve the in uence of nodes failure. However, a cluster network could not tolerate the failure of cluster heads. The failure of a single CH will result in the data loss of a whole cluster, not to mention the failure of multiple CHs. Moreover, CHs receive more messages and the data aggregation causes more computing overhead on CHs, thus resulting in faster battery depletion on CHs than other nodes. As a result, considering the fault tolerance for CHs and the load balance for energy consumption among nodes, our clustering algorithm includes the second protocol protocol as shown in Figure 2.4. Generally speaking, a CH selects a Backup Cluster Head (BCH) among its members. Not only could a BCH detects the failure of its CH and takes over, but also the CH could inform the BCH to take over due to the low energy itself. As a result, the protocol enables nodes in a cluster to take turns to be CH for the balance of energy consumption among nodes as well as prolong the lifespan of a cluster.
Function Delegation
Figure 2.4 shows the process of the Function Delegation protocol. After nodes form a cluster, a CH selects the one with the highest energy among its
CHAPTER 2.
CLUSTERING ALGORITHM
14
CH DONE INV ACK DONE
CM
CM DONE
CM DONE
BCH
NTF(RETIRE) ACK(BCH_START) T1
Node
T2
CH
SUB
Node
SUB T2 PUB PUB ACK
T2
Node
T2
CM
ACK DONE INV ACK
CM BCH
Figure 2.4: Delegation protocol
members, and sends an INV message to invite it to be BCH. The INV message contains all the information of the members in the existing cluster. Upon receiving the INV message, the CM stores all the information, becomes BCH and sends back ACK for acknowledgement. Then the cluster works normally for a relatively long time. During that time, the CH sends heartbeat packets to BCH periodically so that the BCH could track the aliveness of its CH. And if there are changes among cluster members, the CH sends updates to the BCH for updating member information. Then, two cases could trigger the BCH taking over process. In one case, the loss of several sequential heartbeats could trigger the BCH taking over. In another case, due to its low energy, the CH could send a NTF(RETIRE) message to the BCH to inform it to take over as shown in Figure 2.4. The NTF message contains the option of RETIRE. Upon receiving the message, the BCH sends back ACK and promotes to be CH. Then it goes to T2 phase and sends SUB messages to the existing members in the cluster. The BCH has the information of these members because the previous INV message from the former CH contains
CHAPTER 2.
CLUSTERING ALGORITHM
15
CH DONE NTF(RETIRE) ACK(BCH_START) T1
BCH DONE
CM DONE
CM DONE
Node
T2
CH
SUB
Node
SUB PUB ACK T2
T2
CM
SUB (Resend)
Node
PUB ACK DONE INV
T2
CM
ACK
BCH
Figure 2.5: SUB lost during the process of delegation
the information. Then the process continues as the at clustering protocol. In addition, the retired CH could either try to join a cluster or shut down itself according to real requirements. For the Function Delegation Protocol, we also improved the original design in the following aspects. The original design does not specify the time phase of BCH during the taking over process. In our modi cation, we design it to go back to T2 phase to simplify the design. Furthermore, the original design only enables the BCH to send SUB once and does not take the SUB lost into consideration. In our modi cation shown in Figure 2.5, we think it is very important to resend a SUB message if the BCH does not receive replies because besides of recruiting members, in this case the SUB message also has the function to inform a CM the failure of its CH. If a CM does not receive a SUB from the BCH, it will still send data to the original CH which might have already been down. By implementing the resending mechanism for SUB, we would like to ensure CMs also notify the failure of the CH immediately.
CHAPTER 2.
CLUSTERING ALGORITHM
16
CH(L)
CH(L)
CH(L)
Periodically Broadcast ADV Periodically Broadcast ADV T1 Local Delegation SUB PUB T2 ACK PUB
CH(L+1)
SUB
SH(L)
ACK
SH(L)
INV DONE ACK
BCH (L)
Figure 2.6: Hierarchical clustering protocol
2.5 Multi-Level Clustering Protocol
In WSNs, a 2-level clustering structure has its bene ts, such as fast speed of forming the structure and energy saving. However, if an algorithm could form a clustering structure with more than 2 levels, there could be more bene ts. Firstly, in a relatively large scaled network, with a 2-level clustering structure, there are many CHs sending data to the sink nodes through long multi-hop routings at almost the same time, thus causing tra c jamming especially at the sink node. With a 3-level or 4-level clustering structure, a higher level CH could further aggregate several messages to one and send it to the sink node, thus reducing the number of messages received at the sink node and relieving the tra c jamming. Furthermore, instead of sending messages through long multi-hop routes, SHs could send it to its nearby upper level CH and CHs could aggregate messages into one and send them through relatively short routes. In such a way, the network could further reduce the long multi-hop transmissions and be more energy e ciency.
CHAPTER 2.
CLUSTERING ALGORITHM
17
Therefore, based on the above two protocols, we design the third protocol protocol. The basic idea is that after nodes form at clusters and CHs select BCHs, the level-1 CHs of these clusters go through a similar process as the at clustering protocol to form multilevel clusters. Figure 2.6 shows the process and the numbers in the brackets represent the level of a node. Firstly, CHs(L) go back to T1 phase and also broadcasts ADV messages. On receiving an ADV message, a CH(L) checks the location and the level. The CH(L) only tries to form a higher level cluster with the same level and location CHs. Then, after T1 times up, a CH(L) also decides locally whether or not it could be a CH(L+1) for this higher level cluster based on self residue energy and then go to T2 phase. If it could be, instead of sending SUBs immediately, it rst executes the delegation process. It sends NTF(RETIRE) to its own BCH for retirement. After receiving ACK from the BCH, which means the BCH will take the place of it in the existing cluster, the CH(L) promotes to be CH(L+1). Then the process is almost the same as the at clustering protocol except that if CHs join the multi-level cluster of CH(L+1), they become SH instead of CM. When the multi-level cluster has been formed, the CH(L+1) also invites a SH(L) to be its BCH.
Multi-Level Clustering
Furthermore, the process of BCH taking over in a multi-level clustering is dierent from the at one. The BCH not only needs to recruit members in the existing cluster, but also needs to inform the upper level CH for its taking place of the original SH if necessary.
Chapter 3 Current State of Simulator
With the eye-catching development in wireless network elds, there appear more and more algorithms and protocols. Some of them aim at medium or large scale networks while some of them are speci c to applications and services. In order to validate a protocol logic as well as test its performance, the direct way is to implement and run it on real devices. However, developers usually have limited devices and developing on real hardware takes long time. Therefore, researchers prefer to use software simulators to simulate the protocol and shorten the developing time. As a result, there appear several famous simulators, such as NS-2, J-Sim and OMNeT++. For our simulation, the simulator needs to provide the following supports.
• Implementation of IEEE 802.11 or 802.15.4 standard • Implementation of multi-hop routing protocols • Energy Model to track the energy consumption of each node
Based on the above three criteria, we look into three simulators, J-Sim, OMNeT++ and NS-2, in the following part of this chapter and select the one suitable for our protocol simulation.
3.1 J-Sim
"J-Sim is a component-based, compositional simulation environment." [6].
The concept of Autonomous Component Architecture (ACA) is its core idea, 18
CHAPTER 3.
CURRENT STATE OF SIMULATOR
19
which is similar to software integrated circuit (IC) design architecture. Because the programming language for J-Sim is Java, which supports a good Object Oriented (OO) programming model, J-Sim could take advantage of it and use the concepts such as interface, inheritance and so on to realize an ACA-based simulator. In J-Sim, there is a concept called "Contract", which speci es how an initiator (caller) and a reactor (callee) ful ll a certain task. And contracts could be further divided into two categories: component contract and port contract. For component contract, a component includes several classes for realizing functions, and could be comparable to an IC chip in hardware. For port contract, a component has several ports and components usually communicate with each other through these ports, which are also comparable to Pins of an IC chip. With component and port, J-Sim could be exible for users to use dierent components and for developers to develop their own components. And most of these components could work with each other through ports. Besides of Java for realizing functions in J-Sim, for simulations J-Sim implements "Script" to organize all the components and de ne how the whole system should work. In the latest version of J-Sim, it implements TCL/Java, an extension to core TCL, as its script language. If we look into J-Sim packages, we can nd it provides a Wireless Package and a Sensor Network Package that could be useful if we want to implement and simulate our protocols on J-Sim. In the wireless package, J-Sim provides the implementation of IEEE 802.11 MAC and routing protocols such as AODV, GPSR [30] etc. However, there is no energy model in this package. Instead, in the Sensor network package, J-Sim also provides the implementation of IEEE 802.11 MAC and an energy model, but there is no routing protocol. Therefore, neither of the two packages could meet all our three criteria. And Java is a two-edged sword for a simulator. On one hand, it is easy and fast to implement a protocol by using Java compared with other languages, such as C/C++. On the other hand, Java program tends to have a lower performance than programs in C/C++. However, we need to simulate our protocol for a relatively large network and for long time. The performance of a simulator is also quite important to us. Consequently, J-Sim is not a good option for us.
CHAPTER 3.
CURRENT STATE OF SIMULATOR
20
3.2 OMNeT++
OMNeT++ is a relatively new simulator, which "is an extensible, modular,
component-based C++ simulation library and framework, with an Eclipsebased IDE and a graphical runtime environment." [12] It uses C++ as the
programming language to realize protocol logics and adopts NED as a script language for setting up simulation environment. There are several projects going on for developing frameworks on OMNeT++, such as INET [3], INETMANET [4], Mobile framework [8], MiXiM [7] and Castalia [2]. If we look into these frameworks, only Castalia and INETMANET could be useful for our simulation. Castalia provides several MAC standard implementations, such IEEE 802.15.4 CSMA/CA, T-MAC [39], S-MAC [42] and so on. However, Castalia only provides simpleTreeRouting and multipathRingsRouting [1], which is not enough for our simulation. For the INETMANET framework, it provides both 802.11 and 802.15.4 MAC implementations, several routing protocols, e.g. AODV, and the energy model. However, the implementation of IEEE 802.15.4 and the energy model is still under test, which could be unreliable. Therefore, the INETMANET framework in OMNET++ could be a backup option for our simulation if we cannot nd a better one.
3.3 NS-2
The Network Simulator - ns-2 is a famous and long-lived simulator. It started as a variant of REAL network simulator [31] from 1989 and evolved during the past few years. Now NS has version 2 and version 3 available online. Since ns-3 [11] is relatively new and still under development, we only take ns-2 into consideration. NS-2 is also an open-source discrete event network simulator which uses C++ as its programming language and adopts TCL as its script language. Usually developers uses C++ to program the protocol logic in ns-2 and users use TCL to write scripts, which serves as "glue" to combine several protocols and form the simulation environment. In addition, since ns-2 has evolved for a long time, it is also popular in academia for its extensibility and plentiful online documentation. And because ns-2 uses C++ as programming language, its performance is better than those written in Java. If we look into the ns-2 all-in-one package, it basically provides the implementation for both IEEE 802.11 and 802.15.4 standards, routing protocols such as AODV, DSDV and DSR, and the energy model. Therefore, ns-2
CHAPTER 3.
CURRENT STATE OF SIMULATOR
21
could also be a good option for our simulation.
3.4 Comparison
Now we have looked into three simulators and known about their advantages as well as disadvantages. We conclude our ndings in Figure 3.1 and Table 3.1.
Figure 3.1: Comparison of dierent simulator packages
Simulator Development Community Docs & Extension Tools Scale Performance Dev. Di culty
J-Sim Closed Few Some Some Medium Slow Easy
OMNeT++ Ongoing Some Some Some Large Fast Medium
NS2 Ongoing Some Many Many Medium Fast Hard
Table 3.1: Comparison of dierent simulators J-Sim is not a good option for our simulation because neither of its two packages meets our three criteria. For OMNeT++, Castalia is not a good option because it has poor routing protocol support. INETMANET meets all three criteria but the IEEE 802.15.4 implementation and energy model are still under test, which could be unreliable. So INETMANET could be a backup option if we cannot nd a better one. NS2 all-in-one package
CHAPTER 3.
CURRENT STATE OF SIMULATOR
22
provides all the necessary packages and meets our three criteria. And it has abundant documentations and extension packages. However, it is more di cult to develop a protocol on ns-2 than on other two simulators and ns-2 only uses single thread when running one simulation. We could spend some time on learning ns-2 and use script to run several simulations simultaneously to exceed the simulation process. Therefore, we nally decided to develop and simulate our protocol on ns-2 simulator.
Chapter 4 Implementation
In this chapter, we give a detailed description of how we implement our algorithms on ns-2 platform. Sec. 4.1 gives a general introduction to the protocol stack, and describes the NS-2 platform and how we hook our protocols with NS-2. Then, we explain several important data structures in our implementation in Sec. 4.2. Next, Sec.4.3 describes the several key functions of the implementations. Finally, in Sec. 4.4, 4.5 and 4.6, we explain all the implementation details of the three protocols.
4.1 Protocol Stack and Platform
Figure 4.1 shows the protocol stack of our implementation and simulation. From the bottom up, nodes communicate with each other through a wireless channel. Then, if we look into a node, it has the Wireless Physical Layer as its network interface. Above on it, we could use either IEEE 802.11 or 802.15.4 as the MAC layer of a node. Above on the MAC layer there is the IP layer. On the IP layer, we rst adopt certain routing protocols to provide multi-hop routing support, for example, AODV, DSR etc. Finally, we implement our protocols on the IP layer with the routing support. This protocol stack is quite e cient for our implementation because it provides routing supports and does not use transport layer protocols, thus reducing the overhead in the packet head. Furthermore, we implement and simulate our protocol on ns-2.29 all-in-one package [10]. And if we look into our protocol stack on the ns-2 simulator, Figure 4.2 shows its structure. In the gure, each square represents a class which implements certain protocols or functions. And in the simulation, 23
CHAPTER 4.
IMPLEMENTATION
24
Clustering Protocol Routing protocols IP Layer 802.15.4/802.11 WirelessPhy Node Wireless Channel
Figure 4.1: General protocol stack of a node
TCL scripts serves as "glue" to "mix up" these classes and also speci es the simulation environment. In Figure 4.2, from bottom up rst ns-2 has the channel class for dealing with the wireless transmission among all nodes. Above on it, each node has the NetIF class serves as the wireless physical layer. The NetIF could call Radio Propagation Model and Energy Model during the simulation. In our simulation, we use the two-ray ground re ection as the radio propagation model and also use energy model for tracking energy consumption. Then, the up target of the NetIF is the MAC class. In our simulation, we use the class that implements the IEEE 802.15.4 standard. Next, between the LL (Link Layer) class and the MAC, there is an IFq class which could implements certain queue mechanisms. In our simulation, we use the drop tail queue and it could cache at most 50 packets. Moreover, above on the IFq, there is the LL class which could also call the ARP class. The ARP class implements a basic ARP protocol. Next, after addr demux and port demux in the gure, we rst have the RTagent (Routing Agent) working on port 255 to provide routing support. In our simulation, we use the AODV routing protocol for all the simulations. Then, with the routing support, we implement our protocols in the Rock Agent class, which directly inherits the Agent class in ns-2. In addition, our Rock Agent class could also directly get or modify the self energy value in the energy model, which is a cross layer implementation.
CHAPTER 4.
IMPLEMENTATION
25
Rock_Agent port demux IP address entry_ addr demux defaulttarget_ RTagent (AODV) 255
SELF_ENERGY
uptarget_ LL downtarget_
arptable_ ARP
IFq downtarget_
Wireless Node
Radio Propagation Model
mac_
MAC
uptarget_ uptarget_ energy_model_
downtarget_ propagation_ NetIF
energy_model
channel_
uptarget_
Channel
Figure 4.2: Modi ed schematic of a node under the CMU monarch wireless extensions to ns [22]
CHAPTER 4.
IMPLEMENTATION
26
Figure 4.3: Simple RockAgent class collaboration diagram
4.2 Data Structure
Before the descriptions of our data structures, we rst look into ns-2. The implementation of ns-2 is totally based on Object Oriented Programming (OOP). OOP uses objects to design applications and dierent design patterns could be applied in programs. In this way, a program is easy to understand and has great exibility for further extension. This kind of design is suitable for large scaled software and the code size is relatively large. However, we decide not use such a method to implement our algorithm because after the implementation on the ns-2 simulator, in the future we would like to port the implementation to the real hardware devices, which has limited processing capability and memory. So, considering the limited capabilities of the hardware, we have to give up the design patterns and implement our algorithm in a way similar to procedure oriented programming, which has better performance and smaller code size compared with OOP. Therefore, we implement protocol logics and most functions in a single class named RockAgent. Figure 4.3 shows the collaboration and relationship among the classes and
CHAPTER 4.
IMPLEMENTATION
27
data structures in our implementation. For more details about the classes and functions, please refer to Appendix A.
• RockClass: public TclClass
RockClass inherits the TclClass, which serves as a shadow class in TCL during the running time of simulations.
• RockAgent: public Agent
RockAgent is the main class for our implementation. We implement our algorithm in this class. And all the following classes are its friend classes.
• Rock State Timer: public TimerHandler
Rock State Timer inherits the TimerHandler class and is responsible for T1 and T2 phases time-up events. In ns-2, the classes inheriting TimerHandler could serve as a timer for its protocols. Basically, such a class has the functions to register or cancel itself on the time schedule for a certain period and has another expire function as a callback function for the time schedule. For instance, Rock State Timer could register itself in 2 seconds for T1 phase. After 2 seconds, the expire function of Rock State Timer will be called and execute the actions for T1 timing up. In this way, ns-2 could realize the time driven events.
• Rock PrBrADV Timer: public TimerHandler
Rock PrBrADV Timer is responsible for periodically broadcast ADV messages during T1 phase.
• Rock KeepAlive Timer: public TimerHandler
Rock KeepAlive Timer is the timer registered as soon as a node goes into DONE phase. It is responsible for periodical tasks in DONE phase. Dierent roles of nodes could have dierent tasks. For instance, a CM usually needs to send data to its CH. A BCH also needs to check the aliveness of its CH periodically.
• Rock HDADV Timer: public TimerHandler
CHAPTER 4.
IMPLEMENTATION
28
Rock HDADV Timer is responsible for blocking one-level less ADV messages. When a CH is in DONE phase and its cluster members do not reach the maximum cluster size, a CH could still listen for one-level less ADV in order to recruit new members. If the number of received ADV nodes plus the number of cluster members is more than the number of maximum cluster size, we register this timer and blocks receiving any more one-level less ADV. After the registered time, the CH could again listen for one-level less ADV if its cluster does not reach the maximum cluster size. In this way, we could control the cluster size and reduce the unnecessary transmissions and delays. For instance, if a CH could recruit only one more member but it receives two ADVs from two nodes almost at the same time. If it replies to all of them, one of them could not join the cluster and have to go another round. By our method in this case, the cluster head blocks receiving one level less ADV after it receives the rst ADV. And another node does not talk with this cluster head and could join another cluster.
• Rock Timeout Timer: public TimerHandler
Rock Timeout Timer is responsible for packet retransmission. For instance, if a CH sends an INV message to a CM, it will register this timer for a certain period and wait for an ACK. If the CH does not receive an ACK for the INV within the registered period, the callback function for the timer will resend the INV message again. Furthermore, a node in our protocol usually needs the following structures and tables to store information.
pro le t is a table that stores all the self information, such as its role, energy,
time phase etc. Moreover, it also contains ags for switching between states.
ngb table, ngb lvl table, sub table, pub table and backup table have the same structure of node table t composed of node entry t. ngb table and ngb lvl table
are responsible for storing the received same level and one-level less ADV information respectively. sub table contains the information about self head and pub table stores the information about members of a CH. A BCH stores the received INV information in a backup table.
fwd table has the structure fwd table t composed of fwd entry t. It is responsible for forwarding broadcast ADVs. And rock headinfo is responsible for the storage of head information on the sink node.
Finally, we de ne our packet structure as shown in Figure 4.4. We do not specify the bytes for each item because these items could have dierent bytes according to dierent implementation platforms and hardware. In general,
CHAPTER 4.
IMPLEMENTATION
29
General Packet Structure Type Id Seq Level Location Length Payload
ADV Packet ADV Id Seq Level Location Length
ADV Payload Capability Energy
SUB Packet SUB Id Seq Level Location Length
SUB Payload Interest_nu Interests[] m
PUB Packet PUB Id Seq Level Location Length
PUB Payload Result_nu m Results[]
Results Item Structure Type Value Quality
INV Packet INV Id Seq Level Location Length
INV Payload Number Backup table[]
Backup Table Structure Id NTF Packet NTF Id Seq Level Location Length Addr Level Energy Capability Location Seq NTF Payload Ntf_option Ntf payload ACK Payload Id Seq Level Location Length ACK_Seq ACK_Type
ACK Packet ACK
Figure 4.4: General packet structure
CHAPTER 4.
IMPLEMENTATION
30
there are six types of packets as we de ne in our algorithm and every type of packets has the following same items: type, id, seq, level, location and length. Type represents the type of a message. Id is the identi cation number of the sending node. Each node in the network should have a unique id. Then, Seq is the sequence number of the current packet. Level contains the level value of the sending node. Next, Location is a number pre-con gured on each node. Only the nodes with the same location number could form clusters. Finally, Length represents the length of the payload. Moreover, for each type of messages, we de ne dierent payloads. The ADV payload contains the capability and the residue energy value of the sending node. Then, the SUB payload has an array that contains the types of data that the sending node wants to subscribe, and the total number of records in the array. Next, in the PUB payload, there is a "result num" item representing the total number of records in the following results array. In the results array, each record contains three items, type, value and quality, which are useful to application services. Moreover, the INV payload contains the "Num" item that shows the total number of records in the following backup table. Each record of the backup table usually contains the information of a node, such as its ID, address, level and so on. In addition, the NTF payload contains the "ntf option" and "ntf payload" if necessary. The "ntf option" represents the type of NTF, e.g., RETIRE. Finally, the ACK payload has the "ack seq" and "ack type". The "ack seq" is the sequence number of the packet that the ACK message wants to acknowledge. And the "ack type" is the type of the acknowledged packet.
4.3 Main Functions
Because our algorithm includes two types of events, Message Driven Events and Time Driven Events, the implementation also includes functions for dealing with these two types of events. Firstly, we have the following message driven event handlers as shown in Figure 4.5. Basically, our RockAgent class inherits the Agent class which has a virtual function called recv(). When a packet arrives, the program will call this function for dealing with the packet. The RockAgent class overrides the recv() function and this function serves as the basic message driven event handler. Then, the recv() calls one of the 6 message handlers according to the type of the received message. There are 6 message handlers, ADV, SUB, PUB, INV, NTF and ACK handlers dealing with dierent types of messages respectively.
CHAPTER 4.
IMPLEMENTATION
31
recv
ADV
SUB
PUB
INV
NTF
ACK
Figure 4.5: Message driven handlers
State_update
T1_handler
T2_handler
Done_handler
Figure 4.6: Time driven handlers
Besides of the message driven event handlers, the implementation also includes the following time driven event handlers as shown in Figure 4.6. The state update function is the main time driven handler. When a node switches from one time phase to another time phase, it calls the state update. Then, based on the current time phase, state update calls T1 handler, T2 handler, or Done handler respectively. Moreover, the above functions are not enough to deal with all time driven events. The implementation also includes the following timers in Figure 4.7. Generally speaking, these timers register a time point in the future. When the program arrives at that time point, it calls the expire function of the timer. The expire is a virtual function of TimerHandler class and our timers inherit the TimerHandler class and override its expire function. Then, the expire function calls dierent callback functions in the RockAgent Class respectively. And we have explained the main usages for these timers in the descriptions of the main classes in Sec. 4.2.
CHAPTER 4.
IMPLEMENTATION
32
Rock_State_Timer::expire
Rock_PrBrADV_Timer::expire
Rock_HDADV_Timer::expire
RockAgent::T1_time_up
RockAgent::T2_time_up
RockAgent::Send_ADV
RockAgent::hd_adv_timer_callback
Rock_KeepAlive_Timer::expire
Rock_Timeout_Timer::expire
RockAgent::keep_alive
RockAgent::timeout_callback
Figure 4.7: Timers
4.4 Flat Clustering
We design the 3 protocols respectively and this section includes the implementation details for the at clustering protocol. Figure 4.8 shows the state switching of a node in the at clustering protocol. After the initialization, a node goes into state. In that state, the node broadcasts and receives ADV messages. Upon receiving an ADV message, the node stores or updates the sending node information in its ngb table. Then, when T1 times up, the node determines whether it is CH or not locally. On one hand, if it is a CH, it goes to state and recruits its members by sending SUB messages. When receiving the PUB message, the CH deletes the record of the sending node from ngb table and stores its information in pub table. Therefore, pub table contains all the information of its members. On the other hand, if the node is not a CH after T1 phase, it goes to state. In that state, the node waits for a SUB message and replies with a PUB message. We implement the FCFS (First-Come, First-Served) mechanism for SUB. In other words, the node only replies to the rst coming SUB message in T2 phase. Then, when receiving the ACK message from the CH, it stores the information of the CH in sub table and becomes a CM. Then, after T2 times up, CHs that succeed in recruiting members will clean their ngb table and go to state while CMs that have joined a cluster will clean their ngb table and go to state. When a CH is at phase, it also listens for ADVs and recruits members. Finally, nodes in these two
(T1, Node)
(T2, Head)
(T2, Node)
(Done, Member)
(DONE, Head) (DONE, Head)
CHAPTER 4.
IMPLEMENTATION
33
Send/Recv ADV
T1, Node
No member
T1 time up T2 time up, still Node, not reach Retry Limit
Send SUB
Recv ADV, Reply SUB
Determine CH
CH
T2, Head
T2 time up
Has member
Done, Head
Not CH
Recv SUB, Reply PUB Recv PUB, Reply ACK T2 time up, no member, reach Retry Limit Recv PUB, Reply ACK
T2, Node
Recv SUB, Reply PUB
T2 time up, still Node, reach Retry Limit
Done, Node
Recv ACK T2 time up
T2, Member
Done, Member
Figure 4.8: Flat clustering state diagram
states start to work according to the requirements of upper layer application services. In addition, in order to exceed the clustering process and increase the probability of successful clustering, when a node at state receives a SUB message, it immediately goes to and replies with a SUB message. Moreover, it is possible that after T2 times up, a node at state does not receive SUB or ACK, and a node at state is not able to recruit any member. In these conditions, nodes roll back to state and try another round to join a cluster. Furthermore, the is the maximum rounds that the node could retry. And this value could be adjusted according to dierent situations. However, it is still possible that after reaching the retry limit, a node still cannot join a cluster. The node will then go to state and send data directly to a sink node periodically. We de ne such a kind of nodes as . In our simulations in Chapter 5, we control the percentage of such a kind of nodes to be less than 5%.
Node) (T1, Node) Retry Limit
(T1, Node) (T2, Node)
(T2, (T2, Head)
(Done, Node)
Isolated Nodes
Therefore, after the at clustering process, a node nally goes to the following
CHAPTER 4.
IMPLEMENTATION
34
three stable states, , and . In Done phase, these nodes perform dierent actions respectively according to their roles. nodes send sampled data to its head. nodes aggregate data and send them to the sink node. And nodes directly send sampled data to the sink node.
(Done, Head) (Done, Node)
(Done, Head) (Done, Member) (Done, Member)
(Done, Node)
4.5 Function Delegation
The aim of the Function Delegation Protocol is to provide fault tolerance for CHs, load balance among cluster members as well as the basis for the multi-level clustering protocol. Figure 4.9 shows the state switching of the function delegation protocol. From the point of a CH, when it goes into the state, it selects its BCH with the highest energy among its members. Actually, the CH looks into its pub table and selects the record with the highest energy. Then, the CH sends an INV message to that CM to invite it as its BCH and waits for ACK. If the CH gets ACK in time, it considers the selection of BCH successful. Then, the cluster runs in a stable state for quite a long time until the CH residue energy is below a certain value. The value could be adjusted according to dierent situations. Next, the CH has low energy and sends a NTF(RETIRE) message to its BCH to trigger the BCH taking over process. After receiving an ACK message from the BCH, it rolls back to and tries to join a cluster as a normal member.
(Done, Head)
(T1, Node)
Besides of the above normal process, we also take error handling into consideration. One case is that the CH may not be able to receive an ACK after it sends an INV message to a node. In this case, the CH waits for a certain period and resends the INV. If times of resending the INV reaches a certain value (Retry Limit), the CH deletes this record from its pub table and starts the process for selecting a new BCH. If the CH continues such a process and nally there is no record in the pub table, the CH rolls back to to try to join a cluster. Another case is that when the CH wants to retire, it may not be able to receive the ACK for the NTF(RETIRE). The CH also resends the NTF and waits for the ACK. If the resending times reach the retry limit, the CH will delete this BCH record from its pub table and start to select a new BCH. After selecting a new BCH, it will also send NTF to the new BCH and go to .
(T1, Node)
(T1, Node)
From the point of a BCH, the process is relatively simple. Before the BCH becomes a BCH, it is just a normal member. It may either in DONE phase or
CHAPTER 4.
IMPLEMENTATION
35
Send INV, wait ACK Reach INV Retry Limit, delete this record, try another record.
ACK lost, Resend INV / NTF Reach Retry Limit and No CM || Recv ACK(BCH_START) Recv ACK
Done,Head
Reach NTF Retry Limit, delete this BCH, Select New BCH.
T1, Node
Energy low, send NTF(RETIRE)
Delegation Head State Diagram
Recv INV, reply ACK
Done/T2, Member
Done/T2, Member(BCH)
Recv NTF (RETIRE) reply ACK || 3 DET Lost BCH takeover
T2, Head
Delegation BCH State Diagram
Figure 4.9: Delegation state diagram
T2 phase and when it receives an INV message from its CH, it stores the INV information in its backup table, immediately sends back ACK and considers itself as a BCH. Then, two cases could trigger the BCH taking over process. One case is that the BCH receives a NTF(RETIRE) from its CH. Another case is that the BCH detects the failure of the CH by loss of 3 sequential heartbeat packets (DET) from the head. In the normal case, the CH sends a heartbeat packet (DET) to the BCH every duty cycle. The threshold value of sequentially loss of heartbeat packets could be adjusted according to real conditions. In both two cases, the BCH starts the taking over process and goes into state to recruit the original members in the cluster.
(T2, Head)
Therefore, the Function Delegation protocol could provide the 2-level clustered network with fault tolerance and load balance features and also serves as the base for the multi-level clustering protocol.
CHAPTER 4.
IMPLEMENTATION
36
4.6 Multi-Level Clustering
With the Flat Clustering protocol and the Function Delegation protocol, our algorithm now could form a WSN into a at (2-level) clustering structure with fault tolerance and load balance supports. However, the algorithm still lacks the feature of forming network into multi-level (more than 2 level) clustering structure. That kind of structure bene ts the energy e ciency and further relieves the tra c jamming at a sink node, thus increasing the life span and the scalability of WSNs. In addition, dierent level heads could have dierent tasks and application developers could implement more complex algorithms in a multi-level tree structure. Therefore, we propose the third protocol protocol.
Multi-Level Clustering
Figure 4.10 shows the state switching of the multi-level clustering structure. The upper part of the gure shows the normal at clustering state switching with slight modi cations. The lower part shows the state switching for heads to forming a multi-level clustering structure. After initialization, all nodes rst try to form a at (2-level) clustering structure according to the at clustering protocol. There is a slight dierence when a level-1 CH goes into Done phase. If the network aims at forming a multi-level (more than 2 levels) clustering structure, instead of going to state, a CH goes to state, selects a BCH and then goes to state.
(Done, Head)
(Done, SubHead) (T1, SubHead)
Then, it comes to the lower part of the gure. Basically, in order to form a higher level cluster among SHs, a SH goes through a process similar to the at clustering protocol. And the selection of a head is still based on the residue energy. However, there are several dierences. After T1 times up and the SH determines itself as the top head for the multi-level cluster, it adds its level and goes into state. In that state, instead of recruiting members immediately, it rst sends NTF(RETIRE) to its BCH to trigger the taking over process in the current cluster so as to let the BCH to take over its position. After it receives ACK from the BCH, it goes to . In that state, the node becomes the top CH and starts to recruit members. Instead of being CM, all its members have the role of SH. Then, after T2 times up, SHs go to Done phase while the top CH still checks if it reaches the maximum level of the multi-level clustering. If not, it will go to , select a BCH and then go to to try to form a even higher level cluster. Moreover, if the network aims at forming a 4 or more levels clustering structure, when in T2 phase the level-up SH wants to retire from the current multi-level cluster, its BCH also needs to
(T2, SubHead(lvl up))
Head(lvl up))
(T2,
(Done, SubHead)
(T1, SubHead)
CHAPTER 4.
IMPLEMENTATION
37
Send/Recv ADV
Flat Clustering Process with Modification
T1, Node
No member, not reach Retry Limit T1 time up T2 time up, still Node, not reach Retry Limit Send SUB Has member Reach Max lvl
Recv ADV, Reply SUB
Select BCH
Determine CH
CH
T2, Head
T2 time up
Done, Head
Not CH
Recv SUB, Reply PUB Recv PUB, Reply ACK T2 time up, no member, reach Retry Limit Not reach Max lvl Recv PUB, Reply ACK Recv ACK, lvl < max lvl
T2, Node
Recv SUB, Reply PUB
T2 time up, still Node, reach Retry Limit
Done, Node
Done, SubHead
T1, SubHead
Recv ACK T2 time up
Select BCH
T2, Member
Done, Member
Send/Recv Same lvl ADV
Multi-Level Clustering Process
Recv ACK, lvl < max lvl
T1, SubHead
T1 time up ngb_table empty ngb_table not empty Determine CH T2 time up, Not join cluter, not reach Retry Limit Not CH CH Recv ACK, Delegation succeeds Send NTF, wait ACK Send SUB Recv ADV, Reply SUB Has member
No member, not reach Retry Limit Reach Max lvl
Select BCH
T2, SubHead(lvl up)
T2, Head(lvl up)
T2 time up
Done, Head(lvl up)
Recv SUB, Reply PUB
Delegation Failed Recv PUB, Reply ACK T2 time up, Not Join Cluster, reach Retry Limit
T2 time up, no member, reach Retry Limit Not reach Max lvl
Recv PUB, Reply ACK
T2, SubHead
Recv SUB, Reply PUB T2 time up, joined cluster
Done, Head
Done, SubHead(lvl up)
Recv ACK Select BCH
Done, SubHead
Figure 4.10: Hierarchical clustering state diagram
CHAPTER 4.
IMPLEMENTATION
38
retire from its cluster rst and then take the place of the level-up SH. Furthermore, our multi-level clustering protocol also takes the error handling into consideration. First, if T1 times up and a SH does not receive any ADV (ngb table empty), it will go back to again to retry instead of going to and waiting for T2 timing up. This process could help SHs to exceed the process of retry and increase the possibility of forming a multi-level clustering. Moreover, If a SH at does not receive any SUB, it will also roll back to and retry. In addition, if a SH at fails in the delegation process, it will decrease its level, go to and select a new BCH. Besides, after T2 times up and a top CH does not recruit any SH, it will also decrease its level and go back to state for retry. Finally, if a SH reaches the retry limit after certain rounds, it needs to go to state with its existing level. In the cases with relatively few nodes, the network may not be able to form the maximum-level clustering structure. For instance, if a network wants to form a 4-level clustering structure and it only has one level 2 CH or the existing level-2 CHs could not hear each other, the 2-level CHs should stop retrying and go into a stable state.
(T2, SubHead)
(T1, SubHead)
Head)
(T2, SubHead) (T1, SubHead) (T2, SubHead(lvl up)) (T2, SubHead) (T1, SubHead) (Done,
Finally, during the process of forming a multi-level cluster structure, those SHs who could not promote to be the top CH should also recruit members at the same time because there could be nodes that previously did not join cluster and are still trying. Otherwise the percentage of isolated nodes will increase in the network according to our simulation. As a result, nodes only at do not recruit members. Furthermore, we divide the original ngb table into two separate tables, ngb table and ngb lvl table. The ngb table stores the information with the same level ADV while the ngb lvl table contains the one-level less ADV information. In such a way, a node could deal with dierent level ADV messages respectively so as to recruit members and form multi-level clusters simultaneously.
(T2, SubHead(lvl up))
Consequently, the multi-level clustering protocol provides the feature of multilevel clustering to our algorithm together with the at clustering and the function delegation protocol.
Chapter 5 Evaluation
In this chapter, in order to evaluate the performance of our clustering protocol and validate its energy e ciency under dierent situations, we conducted extensive simulations with dierent network sizes and topologies on the ns2 simulator (version 2.29). In addition, we also studied several key parameters, such as durations for dierent time phases, retry times etc., to optimize clustering convergence speed and maximize energy e ciency. In the following sections, we rst introduce the simulation environment and basic settings in Sec. 5.1. Then, Sec. 5.2 de nes the test criteria. Finally, in Sec. 5.3, we show and analyze the simulation results.
5.1 Simulated Environment
Because our work is part of the ISMO project [5] and the algorithm will probably be put into practice on a bridge to monitoring structural health or in a well-structured environment, we simulate our protocol in the following two topologies, bridge and matrix topologies with diagonal connections shown in Figure 5.1. In these two topologies, the distance of two direct neighbor nodes (not diagonal) is 100m. And the maximum transmission radius of each node is 150m. So, each node could reach its direct and diagonal neighbors within one hop, as shown by the line in the gure. In addition, we place the sink node at the middle of the left side. And normally its two or three neighbors could reach it within one hop. Furthermore, our simulation has the following preconditions: 1. Each node has the initial energy of 100 + 5% Joule and starts randomly 39
CHAPTER 5.
EVALUATION
40
Figure 5.1: Bridge and matrix topologies with diagonal connection
within the 1st second. 2. For each node, we set its T1 phase to 2 seconds and T2 phase to 4 seconds according to the simulation of isolated nodes in Sec. 5.3.1. 3. A node iterates the process of trying to join a cluster if it fails in the previous round. Nodes will iterate several times if necessary until the network forms a stable at cluster structure. We de ne one time of iteration as a Round. Nodes can iterate for maximum 3 rounds in the bridge topology and maximum 5 rounds in the matrix topology according to the simulation of isolated nodes in Sec. 5.3.1. 4. The initial TTL of an ADV message is 2, which means a node can only reach its direct neighbor (one hop). And the ADV TTL increases by one per every two rounds. 5. In the energy consumption simulation, we use the energy model object provided in ns2. Table 5.1 shows the values for our ns2 energy model. We set txPower to 0.138 Watt and rxPower to 0.142 Watt respectively according to the calculation based on the real hardware measurement results. Furthermore, after the network forms a stable cluster network, when a head sends a data packet to the sink node, it deducts extra 25% of the transmission energy consumption of that data packet as the computing overhead for data aggregation. In sleep mode between transmission cycles, we consider the node consumes energy close to zero
CHAPTER 5.
EVALUATION
41
because this kind of energy consumption varies according to dierent implementations. initialEnergy txPower rxPower 100+5% Joule 0.138 Watt 0.142 Watt
Table 5.1: ns2 Energy Model
6. All simulations were repeated 10 times to calculate the mean value.
5.2 Test Criteria
Basically, we de ne 2 kinds of parameters:
• parameters that could aect the performance of our protocols • parameters that could show the performance of our protocols
We de ne the following parameters as the rst kind:
• T1 and T2 time phase
Since every node usually needs to go through T1 and T2 phase sequentially in a round, T1 and T2 together is the time of each round. The period of T1 and T2 time phase could aect the total time for our algorithm to form a cluster structure, thus aecting convergence speed of our algorithm. In addition, the periods of T1 and T2 respectively also aect the number of isolated nodes after each round, which means we need to nd the proper periods for T1 and T2 respectively in our simulation to minimize the isolated nodes after a round.
• Hop/TTL
We discuss the TTL for broadcast and unicast respectively. In our protocol, only ADV messages are broadcast. So, the broadcast TTL limits the physical range of an ADV message. In some sense, it also decides the physical coverage of a single at cluster because nodes declare their existence by broadcasting ADV messages. In addition, the broadcast TTL could also aect the convergence speed of our algorithm.
CHAPTER 5.
EVALUATION
42
And for the multi-level clustering protocol, each node should also adjust its broadcast TTL according to its level so as to balance between the tra c overhead and the probability of nding same level nodes to form a cluster. The unicast TTL limits the whole network size. Nodes themselves decide their own roles as CM, CH or SH, and it is possible that a node anywhere in the network could become a CH. Therefore, each node in the network should be able to unicast packets to the sink node through a multi-hop route. Then, the unicast TTL limits the network size. Considering the latency and the possibility of packet loss, we limit the TTL for unicast packets to 32, which is a common value for IP packets. As a result, the maximum number of nodes in our bridge case is 62.
• Cluster Size
The cluster size de nes how many CMs a SH or CH could recruit. The cluster size aects the total number of heads in the network and the energy e ciency because usually the more the cluster size is, the more energy a cluster could save. But instead, with more members, the battery of a head drains out more quickly, thus shortening the life span. Moreover, in the multi-level clustering protocol, the cluster size could also limit the maximum level that the structure could form.
• Maximum Level
In the multi-level clustering protocol, we could limit the maximum level of a node, thus limiting the maximum level of the cluster structure as well as the physical coverage of one multi-level cluster.
• Packet Loss Rate
This parameter is useful for testing the Function Delegation protocol. We can test how fast the network could recover if some heads in the network fail with dierent packet loss rate. In addition, we also need to know the maximum tolerable packet loss rate for our algorithm. The maximum tolerable packet loss rate is a threshold value. Within this threshold value, our algorithm could maintain a stable cluster structure in the network. The following parameters belong to the second kind:
• Convergence Time
CHAPTER 5.
EVALUATION
43
Convergence time is the period from the time point when the network starts the clustering process to the time point when all nodes nish the clustering process. The convergence time could tell the performance for the at clustering, the 3-level or more level clustering process.
• System Energy Consumption
System energy consumption is the energy consumption for all nodes within a certain period. By recording the system energy consumption, we can compare the energy e ciency between non-cluster networks and our clustered networks with dierent levels. Moreover, by studying the simulation results, it is also possible for us to predict the energy gain and ratio of energy saving in dierent cases.
• System Recovery Time
System recovery time is a period starting from the time point when some heads fail in a network till the time point that the network becomes stable again. This value could tell the performance of the function delegation protocol. Based on the above mentioned two kinds of parameters, we performed the following simulations in Sec. 5.3.
5.3 Simulation Analysis
5.3.1 Flat Clustering
The at clustering protocol is the basic protocol which builds 2-level cluster structure for networks. In order to optimize and evaluate the protocol, we did the following three simulations, isolated node number, average convergence time and energy e ciency.
Isolated node number
After one round of cluster process, it is possible that there exist nodes which do not join clusters. We de ne this kind of nodes as Isolated Nodes. Either excessive message delay or competing cluster heads will cause isolated nodes. If isolated nodes repeat more rounds, they will eventually join existing clusters.
CHAPTER 5.
EVALUATION
44
40 35 30
Isolated Nodes(%)
Bridge (T1, T2) (2,2) (2,3) (2,4) (3,2) (3,3)
25 20 15 10 5 0
0
2
Round
4
6
Figure 5.2: Isolated nodes number in the bridge case
70 60
Isolated Nodes(%)
Matrix (T1, T2) (2,2) (2,3)
50 40 30 20 10 0
(2,4) (3,2) (3,3)
0
2
Round
4
6
Figure 5.3: Isolated nodes number in the matrix case
CHAPTER 5.
EVALUATION
45
In addition, T1, T2 durations and total rounds are important factors for the clustering protocol. With relatively long T1 and T2 durations, more nodes could nish the clustering process in one round and fewer isolated nodes need to take another round. However, with relatively short T1 and T2 durations, each round takes less time, thus shortening the time for the whole network clustering process. And dierent durations for T1 and T2 could also aect the clustering process. In addition, the fewer rounds it takes, the faster the network completes a cluster structure. As a result, by this simulation we would like to nd the optimal T1, T2 durations and rounds in dierent cases for our protocol to achieve the minimum isolated nodes in the shortest time. In this simulation, we simulate the conditions of 60 nodes in the bridge case and 64 nodes in the matrix case. We take rounds as X axis and the percentage of isolated nodes to total nodes as Y axis. And the cluster size is 5. In order to control the clustering process in a relatively short time, we limit the duration of each round for no more than 6 seconds. From Figure 5.2 and Figure 5.3, in both the bridge and matrix topologies, it is obvious that the curve with (2, 4) has the best performance because with the increase of rounds, its percentage of isolated nodes decreases more dramatically than the values of other curves. In the bridge topology, the percentage of isolated nodes decreases to about 5% within 3 iterations while in the matrix topology within 5 iterations, the percentage of isolated nodes decreases to about 5%. Therefore, for the following simulations, we could x T1 time to be 2 seconds, T2 time to be 4 seconds because it shows the best performance in the both cases. In addition, we de ne that if the percentage of isolated nodes is less than 5% of the total nodes, the network has completed the clustering process. As a result, we could also consider that the bridge topology takes 3 rounds to complete the clustering process while the matrix topology takes 5 rounds.
Convergence time
The convergence time is an important factor to evaluate the speed of at clustering process. The faster speed (short convergence time) bene ts network initialization. And three parameters, , could in uence the convergence time. In our simulation, we record the average at cluster completion time regarding to the increase of total nodes number. The convergence time of one node is from the point that the node sends the rst ADV message to the point that
topology and cluster size
total nodes number, network
CHAPTER 5.
EVALUATION
46
10.0
9.5
Average Convergence Time (sec)
9.0
8.5
8.0
7.5
7.0
Bridge
6.5
Cluster Size 4 6
6.0
5.5
8 10
0 20 40 60
5.0
Total Number of Nodes
Figure 5.4: Convergence time in the bridge case
the node goes into the stable DONE phase. The average convergence time takes all nodes into account and calculates the mean value. Based on the previous simulations, T1 and T2 phases are set to 2 and 4 seconds respectively to optimize clustering process. We tested four dierent cluster sizes (4, 6, 8 and 10) on the two network topologies. Figure 5.4 and Figure 5.5 show the average convergence time of at clustering in the bridge and matrix topologies. In the bridge case of Figure 5.4, the average convergence time becomes stable for all curves when the number of nodes exceeds 20. It implies that the increase of nodes number aects the convergence time for small size networks on bridge topology. For relatively large networks, convergence time tends to approach a constant value. Furthermore, we can see that the curve of cluster size 4 is above the other curves. The longer convergence time is caused by the bridge topology, where a node can reach ve neighbors within one-hop distance. With cluster size of 4, one neighbor node is likely to perform the second round of clustering process to join another cluster, thus increasing the average convergence time. In the matrix case of Figure 5.5, the average convergence time rises dramatically with the increase of the node number when the node number is less
CHAPTER 5.
EVALUATION
47
11.0 10.5 10.0 9.5 9.0 8.5 8.0 7.5 7.0 6.5 6.0 5.5 5.0 0 20 40 60
Average Convergence Time (sec)
Matrix Cluster Size 4 6 8 10
Total Number of Nodes
Figure 5.5: Convergence time in the matrix case
than 16. For more than 16 nodes matrix cases, the average convergence time reaches a plateau but still increases slightly with the increase of the node number. It is due to the fact that with the increase of nodes, more nodes need to run extra rounds of clustering process to join existing clusters or form new clusters. In 4 to 16 nodes cases, the nodes running extra rounds rises dramatically while in 16 to 64 cases such kind of nodes increases slightly. In both the bridge and matrix cases, the average convergence time stays within two iterations of clustering process for most network scales. The time overhead is acceptable. In practice, people usually deploy multiple sink nodes at dierent positions for large-scale networks. Therefore, in our simulation, we use 64 nodes as the biggest network unit for one sink node.
Energy E ciency
After the simulations of isolated node number and convergence time, we have optimized several parameters of our protocol, such as T1 and T2 time phase, and also evaluate the performance of our protocol. In this part, we continue to evaluate the energy consumption of the at clustering protocol in the following two simulations and compare the results with the ones of the non-cluster networks.
CHAPTER 5.
EVALUATION
48
1200
Bridge
System Energy Consumption (J)
1000 800 600 400 200 0 0
non-cluster Cluster Size 4 6 8 10
10
20
30
40
50
60
Total Number of Nodes
Figure 5.6: System energy consumption regarding to nodes number in the bridge case
1250
Matrix
System Energy Consumption (J)
1000
non-cluster Cluster Size 4
750
6 8 10
500
250
0 0 20 40
Total Number of Nodes
60
Figure 5.7: System energy consumption regarding to nodes number in the matrix case
CHAPTER 5.
EVALUATION
49
• System energy consumption regarding to nodes number in the 2 topologies with dierent cluster sizes
In this simulation case, we record the energy consumption in 1000 seconds of the clustered topology in comparison with the non-cluster topology regarding to the increase of nodes with dierent cluster sizes. Nodes in the non-cluster network send data to the sink node per duty cycle (every 5 seconds) via multi-hop routes. In the clustered network, member nodes send data to the cluster heads per duty cycle. Cluster heads aggregate and send the merged data to the sink node per duty cycle. The sink node is at the middle on the left side. We did the simulation in both bridge and matrix topologies with four dierent cluster sizes. This case helps us to nd the relationship with the saved energy and the network size, and the eect of dierent cluster sizes in such conditions. Figure 5.6 and Figure 5.7 shows the system energy consumptions in clustered networks on two dierent topologies in contrast to non-cluster networks. Gaps between curves of non-cluster networks and at cluster networks illustrate the gain of saved energy with dierent cluster sizes. we rst focus on the system energy consumption regarding to dierent cluster sizes for the clustered networks. We can nd that in the bridge topology with more than 20 nodes, the system energy consumption decreases with the increase of cluster size. For example, in Figure 5.6, it is obvious that the at cluster network with cluster size 4 consumes relatively more energy than the networks with other cluster sizes. Therefore, in relatively large bridge topologies, the at clustering with larger cluster size could save more energy. In Figure 5.7, It is also true that the larger the cluster size is, the more energy a clustered network could save. It is a case in point that the clustered matrix network with cluster size 10 consumes less energy than the ones with other cluster sizes. In both above two gures, the larger the cluster size, the more energy it could save. It is reasonable because with the increase of cluster size, a head could recruit more members and the number of heads in the network also decreases. As a result, there will be more one or two-hop packet transmissions between members and heads, and less long multi-hop packet transmissions between heads and the sink node, thus reducing the total energy consumption. However, Figure 5.6 and Figure 5.7 are not enough to show the improvement of the energy e ciency of our algorithm. If we would like to observe the energy e ciency considering the increase of nodes number, we could use Equation 5.1 to calculate the Saved System Energy Percentage (es %) for two
CHAPTER 5.
EVALUATION
50
80
Saved System Energy (%)
60
40
Bridge
20
Cluster Size 4 6 8
0
10
0
20
40
60
Total Number of Nodes
Figure 5.8: Saved system energy percentage in the bridge case
topologies, which represents the percentage of saved system energy in clustered networks compared with the system energy consumption of non-cluster networks. In the equation, e1 stands for the system energy consumption of clustered networks with dierent cluster sizes respectively. And e2 always stands for the system energy consumption of non-cluster networks. Moreover, es stands for saved energy between a non-cluster network and a cluster network with certain number of nodes and cluster size. And es % is the percentage of saved system energy compared with the system energy consumption of non-cluster networks.
es = e2 − e1 , es % = es /e2 = (e2 − e1 )/e2 ∗ 100%
(5.1)
Based on Equation 5.1, Figure 5.8 and Figure 5.9 show the results of es % regarding to nodes numbers with dierent cluster sizes in the bridge and matrix cases. The X axis represents nodes numbers and the Y axis stands for es %, saved system energy percentage. In Figure 5.8, we focus on the saved system energy percentage regarding to nodes number. With the increase of nodes number, the saved system energy percentage rises dramatically with less than 40 nodes and then reaches a plateau for about 70% when nodes are more than 40 in the bridge case.
CHAPTER 5.
EVALUATION
51
60
50
Saved System Energy (%)
40
30
Matrix
20
Cluster Size 4 6
10 0 20 40
Total Number of Nodes
8 10
60
Figure 5.9: Saved system energy percentage in the matrix case
Therefore, the curves imply that when nodes are less than 40, the nodes number actually aects the energy e ciency of our clustered networks. When nodes number is more than 40, the saved system energy percentage is about 70% regardless of nodes number. In Figure 5.9, it is also the case that the saved system energy percentage soars up when node are less then 40 nodes, and when nodes are more than 40, the percentage reaches a plateau of about 55%. Therefore, we can reach the following two conclusions. The larger cluster size could save more energy. And with bigger network scales, for our at clustering the saved system energy percentage tends to reach a stable value, 70% for the bridge case and 55% for the matrix case. Moreover, the bridge case has better energy e ciency by adopting our at clustering because in the bridge case, the average transmission distance in hops decreases a lot compared with non-cluster networks. In both cases, our cluster algorithm can save considerable energy.
• System energy consumption regarding to duty cycle in the 2 topologies with dierent cluster sizes
CHAPTER 5.
EVALUATION
52
3000
System Energy Consumption (J)
Bridge Non-Cluster
2500 2000 1500 1000 500 0 0
20 40 60 Flat Cluster 20 40 60
100
200
300
Duty Cycle
400
500
Figure 5.10: System energy consumption regarding to duty cycle in the bridge case
In this simulation case, we record the energy consumption over duty cycle with a xed cluster size ve on three dierent network sizes. The system running time equals the product of duty cycle number multiplying the interval, which is ve seconds in this case. The simulation tells us how much energy can be saved along with the increase of time in the network. Figure 5.10 and Figure 5.11 show the energy saving over time in terms of duty cycle in clustered networks on two dierent topologies in contrast to noncluster network. The gap between dash curves (non-cluster networks) and solid curves (clustered networks) illustrates the gain of energy e ciency under dierent network scales. The bigger network saves more energy in cluster topology, especially for bridge case. The energy saving increases dramatically over time. Since all curves are approximately straight, we can construct linear models to predict the energy saving under a given network topology and scale. Suppose the tted functions for cluster and non-cluster topology are given respectively by
y1 = ax + c, y2 = bx + d
(5.2)
where x is the number of duty cycle, y1 stands for non-cluster and y2 stands for at clustering. Therefore, the following equations could present the value
CHAPTER 5.
EVALUATION
53
3000 2800 2600 2400 2200 2000 1800 1600 1400 1200 1000 800 600 400 200 0 0
Matrix Non-Cluster 36 49 64 Flat Cluster 36 49 64
System Energy Consumption (J)
100
200
300
Duty Cycle
400
500
Figure 5.11: System energy consumption regarding to duty cycle in the matrix case of saved energy (∆y ) and the improvement ratio of energy e ciency
∆y = y1 − y2 = sx − i ∆y y1 − y2 bx + d = =1− y1 y1 ax + c
(5.3)
(5.4)
Because y1 stands for non-cluster and y2 stands for at clustering, the constants s and i has dierent meanings. s stands for the saved energy per duty cycle, which represents how much energy a at cluster network could save with each extra duty cycle compared with a non-cluster network. Furthermore, i represents the initial energy consumption for building a at cluster structure network. And with these equations, we can predict the energy saving and ratio of energy gain in a given time point. For example, when nodes number is 60 in bridge case, two functions for non-cluster and at cluster topology are:
y1 = 5.855x + 5.617, y2 = 1.816x + 19.487 ∆y = y1 − y2 = 4.039x − 13.87
(5.5) (5.6)
CHAPTER 5.
EVALUATION
54 (5.7)
∆y 1.816x + 19.487 =1− . y2 5.855x + 5.617
According to the above equations, the system energy gain is about 4.039 Joule per duty cycle. And when duty cycles are more than 4, the 60 nodes network with at cluster consumes less energy than the non-cluster one. We can also predict the energy gain and the ratio of energy for the 60 nodes bridge case. For instance, when the system runs for 600 duty cycles (i.e., x=600), the clustered topology saves about 2409.53 Joules energy, which saves about 68.5% energy compared with non-cluster topology. nodes 20 40 60 Bridge s 0.338 1.749 4.039 i 2.881 7.688 13.870 nodes 36 49 64 Matrix s 0.959 1.684 2.708 i 13.086 24.177 45.655
Table 5.2: Flat clustering results Moreover, we calculate and list the s and i value separately in Table 5.2. According to the gure, it is obvious that s increases with the nodes number in both the bridge and matrix cases, which illustrates the energy gain per duty cycle rises with the nodes number. In addition, i rises with the nodes number also. It is reasonable that the more the nodes are, the more energy the initial clustering process consumes. Hence in short, the gain of energy e ciency in our at clustering protocol is a signi cant advantage.
5.3.2 Delegation Protocol
The delegation protocol is the protocol that provides fault tolerance for CH failures and also is the basis for the multi-level clustering protocol. We did the following simulation to evaluate the performance of this protocol with dierent packet loss rates.
System recovery time regarding to packet loss rate in the 2 topologies
In this simulation, after the network has formed a cluster structure, we introduce a failure of random 10% of CHs simultaneously. We record the recovery
CHAPTER 5.
EVALUATION
55
55
50
Bridge Total Node Number
45
20 40 60
40
Recovery Time (sec)
35
30
25
20
15
10
5
0 0.0 0.1 0.2 0.3 0.4 0.5
Packet Loss Rate
Figure 5.12: Recovery time in the bridge case
time to test the performance of our delegation function. The recovery time starts from the time point when 10% CHs fail to the time point when the cluster structure becomes stable again. In this simulation, we also take the eect of packet loss rate on network connectivity into consideration. In the poor link quality environment, heartbeat signal or SUB / PUB / ACK messages loss will cause re-clustering and new node join. Recovery process may take several rounds to complete. We take packet loss rate as X axis and system recovery time as Y axis, and expect to nd how external environment condition aects the recovery time of the whole network. In Figure 5.12, we can nd that in the 20 nodes bridge networks, the system recovery time rises slightly all the time with the increase of packet loss rate. Furthermore, in the 40 and 60 nodes bridge networks, the system recovery time increases slightly with packet loss rate less than 0.35. However, when the packet loss rate is more than 0.35, the system recovery time soars up. The slight increase of the system recovery time may due to the fact that with the increase of the packet loss rate, the original members of the failed CHs may need to take extra rounds to join a cluster. Nevertheless, the latter situation that the recovery time soars up could be owing to the fact that the network itself cannot maintain the stable cluster structure due to the high packet loss rate. A BCH considers its CH has already failed due to excessive
CHAPTER 5.
EVALUATION
56
70
Matrix
60
Total Node Number 36
50
49 64
Recovery Time (sec)
40
30
20
10
0 0.0 0.1 0.2 0.3 0.4 0.5
Packet Loss Rate
Figure 5.13: Recovery time in the matrix case
loss of the heartbeat signals from CH while in fact the CH still works, thus triggering the taking over process. And later that CH discovers that it has no member and will try to join a cluster as a CM. This situation eventually cause the dramatically increase of the system recovery time. Therefore, we can reach the conclusion that with less than 0.35 packet loss rate, the system recovery time of our protocol in the bridge case is about 25 seconds. And 0.35 is the maximum tolerable packet loss rate for our protocols to maintain a cluster structure in the bridge case. In Figure 5.13, we can also nd the above mentioned situations. With the packet loss rate less than 0.35, system recovery time of all networks increases slightly and is also about 25 seconds. However, when the loss rate is more than 0.35, the system recovery time starts to soar up. Therefore, 0.35 could be a threshold for our clustering protocol to maintain a stable network. Consequently, our conclusion is that the system recovery time in both cases is about 25 seconds with less than 0.35 packet loss rate. And the maximum tolerable packet loss rate is 0.35. By the way, if the protocol needs to maintain the cluster structure with more than 0.35 packet loss rate, we should either increase the tolerance of the loss of heartbeats or try to realize reliable transmission in some sense.
CHAPTER 5.
EVALUATION
57
5.3.3
Hierarchical Clustering
Based on the at clustering and the delegation protocols, the multi-level clustering protocol could form networks into 3 or more level clustering structure. We also did several simulations to evaluate the performance as well as its energy e ciency. In order to achieve a better performance, according to our simulations, we optimize the following parameters based on the level (the lowest node has level 0). Currently, we de ne ∆T as 1 second and ∆TIMEOUT as 0.5 seconds based on our simulations.
T 1 = 2 + ∆T ∗ level T 2 = 4 + ∆T ∗ level T T L = 2 + level2 T IM EOU T = 1 + ∆T IM EOU T ∗ level
(5.8) (5.9) (5.10) (5.11)
Convergence time
For the hierarchical clustering protocol, the convergence time is also an important factor to evaluate the performance of the hierarchical clustering process. The shorter the time is, the faster a network could form a stable structure and start to send data. As a result, we did a simulation similar to the convergence time simulation of the at clustering protocol. We recorded the average cluster completion time regarding to the increase of total nodes number. The convergence time of one node is from the point that a node starts to the point that the node reaches the stable DONE phase. The average convergence time takes all nodes into account and calculates the mean value. We also tested four dierent cluster sizes (4, 6, 8 and 10) on the two network topologies. The following gures show the average convergence time of hierarchical clustering in the bridge and matrix topologies aiming at 3 and 4 level clustering structures. In both Figure 5.14 and Figure 5.15, in the bridge case with less than 20 nodes, the average convergence time increases dramatically with the increase of nodes. And when the nodes are more than 20, the average convergence time reaches a plateau. In addition, with more than 20 nodes, the average convergence time uctuates around 12.75 seconds for 3-level structure and 16 seconds for 4-level structure. These values are acceptable for the time overhead of forming a hierarchical clustering structure.
CHAPTER 5.
EVALUATION
58
14.5
14.0
Average Convergence Time (sec)
13.5
13.0
12.5
12.0
11.5
11.0
10.5
Bridge 3-level clustering
10.0
4 6 8
9.5
9.0
10
0 20 40 60
Total Number of Nodes
Figure 5.14: Convergence time in the 3-level clustering bridge case
18.0 17.5 17.0
Average Convergence Time (sec)
16.5 16.0 15.5 15.0 14.5 14.0 13.5 13.0 12.5 12.0 11.5 11.0 10.5 10.0 9.5 9.0 0 20 40
Bridge 4-level clustering 4 6 8 10
60
Total Number of Nodes
Figure 5.15: Convergence time in the 4-level clustering bridge case
CHAPTER 5.
EVALUATION
59
16 15
Average Convergence Time (sec)
14 13 12 11 10 9 8 7 0 20 40
Total Number of Nodes Matrix 3-level clustering 4 6 8 10
60
Figure 5.16: Convergence time in the 3-level clustering matrix case
20 19
Average Convergence Time (sec)
18 17 16 15 14 13 12 11 10 9 8 7 0 20 40
Total Number of Nodes Matrix 4-level clustering 4 6 8 10
60
Figure 5.17: Convergence time in the 4-level clustering matrix case
CHAPTER 5.
EVALUATION
60
For the matrix cases, in both Figure 5.16 and Figure 5.17, the curves for most cluster sizes increase dramatically from 4 nodes to 9 nodes but decrease from 9 nodes to 16 nodes and then increase again. The reason for such a tendency is that networks with less than 9 nodes usually cannot form a 3-level clustering structure every time because CHs are too few and they may not be able to hear each other. Therefore, these CHs may still try to nd each other for several rounds before they go to DONE phase and send data, thus increasing the average convergence time. However, in the cases with 16 or more nodes, the networks are more likely to form a 3-level or 4-level cluster structure with more CHs. Hence, CHs could quickly form another cluster and go to DONE phase instead of trying several rounds. Furthermore, with more than 20 nodes, the average convergence time also rises slightly with the increase of nodes. The maximum average convergence time for 3 and 4-level clustering is less than 20 seconds, which is still acceptable. In addition, there is obvious dierence of average convergence time among dierent cluster sizes. In both 3 and 4-level cases, the average convergence time of cluster size 4 is usually longer than those of other sizes and the one with cluster size 8 shows the shortest time. To explain this phenomenon, in the matrix cases usually a node can reach more than 4 neighbors within one-hop distance and central nodes usually have 8 neighbors. With cluster size of 4, one or more neighbor nodes are likely to perform the second round of clustering process to join another cluster, thus increasing the average convergence time. However, with the cluster size 8, a CH is likely to accept all its neighbors as its CMs. Therefore, a larger cluster size (8 according to the gures) is preferred for the matrix topologies.
Energy e ciency
For the hierarchical clustering protocol, we also did two simulations similar to the ones of the at clustering protocol and observed the tendency of system energy consumption regarding to nodes number and duty cycle respectively.
• System energy consumption regarding to nodes number in the 2 topologies with dierent cluster sizes
In this simulation case, we record the energy consumption in 1000 seconds of the 3-level clustered topology in comparison with the at topology regarding to the increase of the node number with dierent cluster sizes. In the hierarchical structure networks, member nodes send data to its SUB Head (SH) every 5 seconds (i.e., duty cycle interval). SHs again aggregate and send the
CHAPTER 5.
EVALUATION
61
400
Bridge
System Energy Consumption (J)
300
Flat Cluster 4 6 8
200
10 3-level Cluster 4
100
6 8 10
0 0 20 40 60
Total Number of Nodes
Figure 5.18: System energy consumption regarding to node numbers in the hierarchical bridge case
merged data to their SH or CH. Finally, CHs also aggregate and send data to the sink node. The sink node is in the middle on the left side. We did the simulation in both bridge and matrix topologies with four dierent cluster sizes. We expect to nd the dierence of the energy consumption among dierent cluster sizes with dierent node numbers. Figure 5.18 shows that with less than 20 nodes, the 3-level clustering networks consume a little bit more energy than the at ones within 1000 seconds. And when nodes are more than 20, the 3-level clustering networks saves more energy. Based on this nding, it is reasonable that the at clustering has better energy saving than the hierarchical one in the small-scale networks. Because with the 3-level clustering in small-scale networks, the level-2 CHs are few and it is possible that those level-2 CHs happen to be far away from the sink node and those level-1 SHs close to the sink node have to send packets to those CHs. Packets actually go a detour to a farther node, and the farther node aggregates and sends the packet to the sink node along another long multi-hop route, thus resulting in more system energy consumption compared with the at case. Figure 5.19 shows that regardless of cluster sizes, the 3-level clustering networks consumes more energy than the at clustering networks within 1000
CHAPTER 5.
EVALUATION
62
600 500 400 300 200 100 0 0 20 40
Total Number of Nodes Matrix Flat Clustering 4 6 8 10 3-level Clustering 4 6 8 10
System Energy Consumption (J)
60
Figure 5.19: System energy consumption regarding to node numbers in the hierarchical matrix case
seconds in the matrix case. There are two possible reasons that cause such a phenomenon. One is that a hierarchical clustering network actually consumes more energy than the at clustering ones. Another reason is that the initial process for a 3-level clustering may consumes more energy than the one for a at clustering and the running time is too short to show the gain of energy saving. We will discuss it and nd the reason in the next simulation. In both Figure 5.18 and Figure 5.19, we can nd the similar phenomenon to the at cluster that the larger the cluster size is, the more energy the network could save. The curve of the cluster size 4 with 3-level clustering is usually above other curves. For example, if we look at the point of 60 nodes in Figure 5.18, it shows that with the increase of cluster size, the energy consumption decreases. It is the same reason as we mentioned in Sec. 5.3.3. The more nodes a cluster could contain, the less SHs or CHs are in the network, thus reducing the long multi-hop transmission from SHs to CHs and CHs to the sink node and saving energy.
• System energy consumption regarding to duty cycle in the 2 topologies with dierent number of nodes
CHAPTER 5.
EVALUATION
63
1500 1400 1300
System Energy Consumption (J)
1200 1100 1000 900 800 700 600 500 400 300 200 100 0 0
Bridge Flat 20 40 60 3-level 20 40 60 4-level 20 40 60
100
200
300
400
500
600
700
800
Duty Cycle
Figure 5.20: System energy consumption regarding to duty cycle in the hierarchical bridge case
In this simulation case, we record the energy consumption over duty cycle with a xed cluster size ve on three dierent network sizes. The system running time equals the product of duty cycle number multiplying the interval, which is ve seconds in this case. And we compare the energy consumptions of at, 3-level and 4-level clustering networks to nd out the best levels for certain cases. In Figure 5.20, it is obvious that multi-level clustering networks (either 3 or 4level structure) consumes less energy than the at clustering for all number of nodes in the bridge case. And the longer the running time is, the more energy the multi-level clustering networks could save. In addition, if we focus on the 3-level and 4-level networks, except for the 20 nodes networks, the 4-level clustering networks save a little bit more energy than the 3-level ones, and the gain of energy saving also increases with the elapse of time. We can also use the Function 5.3 and calculate the s and y respectively. Here, y1 always represents the non-cluster network while y2 could be at, 3-level and 4-level cluster respectively. And we use Equation 5.12 to calculate simp . simp stands for the improvement percentage between two s values. s1 always stands for the at s while s2 could be 3-level and 4-level s respectively. Table 5.3 shows the results.
CHAPTER 5.
EVALUATION
64 3-level 4-level i(J) i(J) 4.139 5.143 11.241 14.779 20.655 25.885 s improvement
bridge at 3-level nodes s(J) s(J) 20 0.338 0.377 40 1.749 1.882 60 4.039 4.612 Note: simp column is the
3-level 4-level 4-level at simp s(J) simp i(J) 11.28% 0.344 1.56% 2.881 7.60% 1.916 9.56% 7.688 14.19% 4.645 15.00% 13.870 percentage of the 3-level or 4-level compared with the at s
Table 5.3: Hierarchical clustering results in the bridge case
∆s = s2 − s1 , simp = ∆s/s1 = (s2 − s1 )/s1 ∗ 100%
(5.12)
According to s and simp in Table 5.3, the gain of energy per duty cycle between 3-level and 4-level clustering is too trivial and far less than the gain between at and 3-level clustering. For the 20 nodes bridge topology, the 4level clustering even consumes more energy than the 3-level clustering while for the 40 and 60 nodes cases, the simp of 4-level only increases by less than 2% in the 40 nodes case and by less than 1% in the 60 nodes case compared with the simp of 3-level. In addition, the initial energy consumption for setting up the cluster structure also rises with levels. Therefore, considering convergence time, energy gain and the initial energy consumption, we can reach the conclusion that in the bridge case, the 3-level clustering structure is the best choice. For the matrix cases in Figure 5.21, it shows a situation dierent from Figure 5.20. Since several curves are quite close to each other, we also use the Function 5.3 and calculate the s and i respectively. Here, y1 always represents the non-cluster network while y2 could be at, 3-level and 4-level cluster respectively. And we also use Equation 5.12 to calculate the simp . simp stands for the improvement percentage between two s values. s1 always stands for the at s while s2 could be 3-level and 4-level s respectively. Table 5.4 shows the results. Firstly, we compare the conditions of at clustering with the ones of the 3level clustering. In the 36 nodes networks, the simp of the 3-level clustering is -0.26%, which means there is no gain of energy saving with the increase of time between the 3-level and at clustering in the 36 nodes matrix topology. However, in the 49 nodes networks, we can nd that the simp of the 3-level is 0.88%. So, there is a trivial increase of energy saving between the 3-level and the at clustering with the increase of time. But the improvement is too
CHAPTER 5.
EVALUATION
65
2200 2000
System Energy Consumption (J)
1800 1600 1400 1200 1000 800 600 400 200 0 0
Matrix Flat 36 49 64 3-level 36 49 64 4-level 36 49 64
100
200
300
400
500
600
700
800
Duty Cycle
Figure 5.21: System energy consumption regarding to duty cycle in the hierarchical matrix case
matrix at 3-level nodes s(J) s(J) 36 0.959 0.956 49 1.684 1.699 64 2.708 3.095 Note: Gain column is the
3-level 4-level 4-level at simp s(J) simp i(J) -0.26% 0.890 -7.13% 13.086 0.88% 1.605 -4.70% 24.177 14.32% 2.742 1.28% 45.655 percentage of the 3-level or 4-level compared with the at s
3-level 4-level i(J) i(J) 20.059 29.076 35.987 45.844 62.289 74.814 s improvement
Table 5.4: Hierarchical clustering results in the matrix case
CHAPTER 5.
EVALUATION
66
trivial. In the 64 nodes networks, the simp of the 3-level is 14.32%, which is a big improvement in the energy gain per duty cycle. Furthermore, if we take 4-level clustering networks into consideration, it is obvious that 4-level clustering consumes more energy than the 3-level clustering and there is no energy gain between 4-level and 3-level clustering in all conditions in the matrix topology. And if we compare the 4-level clustering with the at one, we can nd except for the 64 nodes matrix, the 4-level clustering even consumes more energy than the at one. As a result, the 4-level clustering is not worthy of consideration for energy e ciency in the matrix case. Therefore, we conclude that with less than 49 nodes in the matrix case, it is enough to form a at clustering structure for energy e ciency. When the nodes are more than 64, the 3-level clustering structure is a better option. Finally, we can also use the Equation 5.2, 5.3 and 5.4 to predict the energy gain and the ratio of energy gain, and take the 64 nodes matrix topology with the at and 3-level clustering as an example. The following equations are for 3-level and at clustering in the 64 nodes case:(y2 stands for at clustering and y3 stands for 3-level clustering)
y2 = 2.712x + 62.522, y3 = 2.325x + 79.157 ∆y = y2 − y3 = 0.387x − 16.635 ∆y 0.387x − 16.635 = . y2 2.325x + 79.157
(5.13) (5.14) (5.15)
According to the above equations, the system energy gain is about 0.387 Joule per duty cycle. And when duty cycles are more than 43, the 64 nodes network with 3-level clustering consumes less energy than the one with at clustering. With these equations, we can also predict the energy saving in a given time point. For instance, when the system runs for 3000 duty cycles (i.e., x=3000), the clustered topology saves about 1144.365 Joules and about 16.22% energy consumption compared with at cluster topology. The gain of energy e ciency between 3-level and at clustering in the long run in such a case is signi cant. Hence, we can reach the conclusion that in the bridge case, the 3-level clustering structure is the best choice for energy e ciency while in the matrix case, the at clustering structure is the best choice for the topologies with less than 64 nodes. In the 64 nodes matrix case, a 3-level clustering is the best choice for energy e ciency.
Chapter 6 Conclusion and Future Work
6.1 Conclusion
To sum up, in this thesis work, we rst review several related clustering algorithms and nd their aws. Then, we introduce our algorithm including 3 protocols, Flat Clustering protocol, Function Delegation protocol and Multi-Level Clustering protocol, and describe our improvements to the original design. These three protocols together could provide the following ve features, scalability, fault tolerance, load balancing, energy e ciency and multi-level clustering. Next, in order to evaluate our algorithm in a short time with low expense, we decide to use simulator and look into three popular ones, J-Sim, OMNeT++ and NS-2. NS-2 meets our requirements and serves as our evaluation tool. In addition, we explain the implementation of our algorithm and provide detailed data structures and state diagrams. Finally, we simulate three protocols respectively under dierent conditions and reach some conclusions. We validate our algorithm and nd it quite promising in performance and energy e ciency, especially in the bridge case. For instance, networks with our at clustering protocol could save considerable energy compared with non-cluster networks. And our 3-level clustering could save more energy than the at clustering in the bridge cases.
6.2 Future Work
We have simulated our algorithm on NS-2 simulator with several conditions. More test cases could be performed for further evaluating the algorithm, for instance, simulation of the whole network life span and tracking the energy 67
CHAPTER 6.
CONCLUSION AND FUTURE WORK
68
consumption on each node. And we could simulate more topologies, e.g., randomly deploying certain number of nodes in a xed area or even 3D topologies. In addition, it is a complex problem to provide fault tolerance for a multi-level clustering network. More studies and researches could focus on that problem. Moreover, the period of T1 and T2 time phase are key to the clustering algorithm and should be adjusted according to the network scale. So, more simulations are needed to nd relationship between T1, T2 phase and the network size. Finally, the algorithm of selecting a CH needs further improvement. Currently, our algorithm totally bases on the residue energy for the CH selection. The node with the highest residue energy among its neighbors could automatically become a CH. However, more conditions could be taken into consideration for selecting a CH, for example, locations of the nodes, received signal strength etc. If a node is near the sink node, which means it could reach the sink node with fewer hops, it could be more probable to be a CH than others. In this way, the node that is close to the sink node could become CH, thus reducing the hops of transmission between CHs and the sink node and saving more energy. What's more, when recruiting members, a CH could also have criteria and prefer those nodes with relatively low energy, strong signal strength and few hops to reach. In this way, a node with low energy and near to a CH could become its member, thus making a cluster more stable and energy e ciency.
Bibliography
[1] Castalia - user manual version 2.3. http://castalia.npc.nicta.com. au/pdfs/Castalia%20-%20User%20Manual.pdf/. [2] Castalia, a simulator for wsns. http://castalia.npc.nicta.com.au/. [3] Inet framework for omnet++ 4.0. http://inet.omnetpp.org. [4] Inetmanet. http://github.com/inetmanet/inetmanet. [5] Ismo - intelligent structural health monitoring system. http://mide. tkk.fi/en/ISMO. [6] J-sim. http://sites.google.com/site/jsimofficial/. [7] Mixim project. http://mixim.sourceforge.net/. [8] Mobility framework sourceforge.net. for omnet++.
http://mobility-fw.
[9] The network simulator - ns-2. http://www.isi.edu/nsnam/ns/. [10] Ns-2.29 all-in-one package. http://ftp.isi.edu/nsnam/dist/. [11] ns-3. http://www.nsnam.org/wiki/index.php/Main_Page. [12] Omnet++. http://www.omnetpp.org/. [13] WirelessHART.
http://www.hartcomm.org/protocol/wihart/ wireless_technology.html.
[14] IEEE 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Speci cations. Tech. rep., IEEE Computer Society, June 2007. [15] ZigBee Speci cation. Tech. rep., ZigBee Alliance, 2008. 69
BIBLIOGRAPHY
70
[16]
An Energy E cient Hierarchical Clustering Algorithm for Wireless Sensor Networks. In IEEE INFOCOM 2003 (2003). http://www.ieee-infocom.org/2003/papers/ 42_02.PDF.
Bandyopadhyay, S., and Coyle, E. J. Bandyopadhyay, S., and Coyle, E. J. An energy e cient hierarchical clustering algorithm for wireless sensor networks, 2003.
[17] [18]
Conference of the IEEE Computer and Communications Societies (INFOCOM¡¯ 01) (April 2001).
[19]
Chan, H., and Perrig, A.
A clustering scheme for hierarchical control in multi-hop wireless networks. In Proceedings of 20th Joint
Banerjee, S., and Khuller, S.
uniform cluster formation. In Proceedings of the First European Workshop on Sensor Networks (EWSN) (2004), pp. 154171.
Demirbas, M., Arora, A., and Mittal, V. Floc: A fast local clustering service for wireless sensor networks. In Workshop on De-
Ace: An emergent algorithm for highly
[20]
pendability Issues in Wireless Ad Hoc Networks and Sensor Networks (DIWANS/DSN (2004).
[21]
the IEEE International Conference on Distributed Computing in Sensor Systems(DCOSS¡¯05) (June 2005).
[22] [23] [24] [25]
Fall, K., and Varadhan, K.
Ding, P., Holliday, J., and Celik, A. Distributed energy e cient hierarchical clustering for wireless sensor networks. In Proceedings of
nsnam/ns/doc/ns_doc.pdf.
The ns Manual. http://www.isi.edu/
MiWi Wireless Networking Protocol Stack. Tech. rep., Microchip Technology Inc., 2007.
Flowers, D., and Yang, Y.
An algorithm for evaluation of nite trigonometric series. American Mathematical Monthly 65 (1958), 3435.
Goertzel, G.
Fault-tolerant clustering of wireless sensor networks. In Proceedings of the IEEE Wireless Communication and Networks Conference (WCNC 2003) (March 2003).
Gupta, G., and Younis, M.
[26]
Middleware: middleware challenges and approaches for wireless sensor networks. In IEEE Distributed Sys. Online, vol. 7, pp. 1¨C23 (2006).
Hadim, S., and Mohamed, N.
BIBLIOGRAPHY
71
[27]
Heinzelman, W. R., Chandrakasan, A., and Balakrishnan,
Energy-e cient Communication Protocols for Wireless Microsensor Networks. In Proc. Hawaaian Int'l Conf. on Systems Science (January 2000). http://wind.lcs.mit.edu/papers/leach-hicss.ps.
H.
[28]
ing for sensor networks. In Proceedings of the 3rd international symposium on Information processing in sensor networks (IPSN '04) (2004), ACM, pp. 205214. The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4. Tech. rep., IETF - Network Working Group, February 2007. http://tools.ietf.org/ html/rfc4728.
Johnson, D., Hu, Y., and Maltz, D.
Hohlt, B., Doherty, L., and Brewer, E.
Flexible power schedul-
[29]
[30] [31] [32]
Gpsr: Greedy perimeter stateless routing for wireless networks. pp. 243254.
Karp, B. Keshav, S.
Real 5.0 overview, 1997.
Adaptive data fusion for energy e¡Àcient routing in wireless sensor networks. In IEEE Transactions on Computers (2006). vol. 55, pp. 12861299,.
Luo, H., Luo, J., Liu, Y., and Das, S. Nadeem, T., and Agrawala, A.
[33]
Performance of IEEE 802.11 based Wireless Sensor Networks in Noisy Environments. Tech. rep., Department of Computer Science, University of Maryland, 2005. An algorithm for group formation in an amorphous computer. In Proceedings of the Tenth International Conference on Parallel and Distributed Systems (PDCS (1998).
Nagpal, R., and Coore, D.
[34]
[35]
Ad hoc On-Demand Distance Vector (AODV) Routing. RFC 3561, The Internet Engineering Task Force - Network Working Group, July 2003. http://tools.ietf. org/pdf/rfc3561.pdf.
Perkins, C., Belding-Royer, E., and Das, S.
[36]
Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers. http://www.cs.virginia.edu/~cl7v/cs851-papers/ dsdv-sigcomm94.pdf.
Perkins, C. E., and Bhagwat, P. Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and Schooler, E.
[37]
Std 802.15.4-2006. Tech. rep., IEEE Computer Society, 2006.
IEEE
BIBLIOGRAPHY
72
[38]
A Survey of Simulation in Sensor Networks. http://portal.acm.org/citation.cfm?id= 1578022.1578901.
Singh, C. P., Vyas, O. P., and Tiwari, M. K.
[39]
An adaptive energy-e cient mac protocol for wireless sensor networks. In Proceedings of the 1st
van Dam, T., and Langendoen, K.
international conference on Embedded networked sensor systems(SenSys 03) (2003), pp. 171180.
[40]
Xu, K., and Gerla, M.
A heterogeneous routing protocol based on a new stable clustering scheme. In Proceeding of IEEE Military Communications Conference (MILCOM 2002) (October 2002).
Ye, W., Heidemann, J., and Estrin, D.
[41]
protocol for wireless sensor networks. In Proceedings of the IEEE Infocom (New York, NY, USA, June 2002), USC/Information Sciences Institute, IEEE, pp. 15671576.
Ye,
An energy-e cient mac
[42]
In Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies(INFOCOM 2002). Vol.3 (2002), pp. 15671576. mac protocol for wireless sensor networks. Distributed clustering in ad-hoc sensor networks: A hybrid, energy-e cient approach. In in Proceedings of IEEE INFOCOM (2004), pp. 629640.
Younis, O., and Fahmy, S.
W.,
Heidemann,
J.,
and
Estrin,
D.
An energy-e cient
[43]
[44]
Heed: A hybrid, energy-e cient, distributed clustering approach for ad hoc sensor networks. IEEE Transactions on Mobile Computing 3 (2004), 366379.
Younis, O., and Fahmy, S.
[45]
Distributed formation of overlapping multi-hop clusters in wireless sensor networks. In Proceedings of the 49th Annual IEEE Global Communication Conference (Globecom 06)) (November 2006).
Youssef, A., Younis, M., Youssef, M., and Agrawala, A.
[46]
Gs3: Scalable self-con guration and selfhealing in wireless sensor networks. pp. 5867.
Zhang, H., and Arora, A.
Appendix A Implemenation of RockAgent Class
A.1 Class
Figure A.1 shows the detailed class collaboration, including all the parameters and functions. We describe the usage of these parameters and functions in Sec. A.2.
A.2 Parameters and Functions
This section includes the usage for the parameters and functions in the RockAgent Class.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
// show detailed process or not int i s s t a r t ; // check i f started int fwdbroadcast_ ; // forward broadcast ADV or not int c t r ; // for state_update , control packets sending in a time phase int BTTL; // Broadcast ADV TTL int BBTTL; // Broadcast ADV TTL base value double T1_DURATION; // T1 time
double T2_DURATION;
int v e r b o s e ;
73
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
74
Figure A.1: RockAgent Class Collaboration Diagram
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
75
16 17 double T1_T2_DELTA; 18 19 double adv_br_interval_ ; 20 21 double WAIT_PUB_DURATION; 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62
T2 time Delta value for adjusting T1 and T2 according to l e v e l p e r i o d i c a l l y broadcast adv i n t e r v a l timeout for waiting for PUB ( for HEAD in DONE phase , recved ADV, replied SUB and wait for PUB) double TIMEOUT_RESEND; // wait time for timeout int RETRY_LIMIT; // retry time li mi t of a node trying to join c l u s t e r s int MAX_LEVEL; // max l e v e l for the hierarchical cl uste ring double done_time_point ; // record the l a s t done time int sent_pkt_num ; // record the t o t a l send number of packets int sent_msg_num ; // record the t o t a l send number of messages double i n i t _ e n e r g y ; // i n i t energy double c u r r e n t _ e n e r g y ; // current energy , only update when sending ADV ofstream LogFile ; // LogFile ofstream int t o t a l n o d e s ; // records the t o t a l nodes in the simulation double PUB_INTERVAL; // Periodically sent PUB INTERVAL int n o _ c l u s t e r ; // sig for no_cluster network int test_energy_consumption ; // sig for t e s t i n g energy consumption int f i x _ c l u s t e r ; // true i f t e s t fix_cluster , f a l s e i f not int f a u l t _ t o l e r a n c e ; // true i f t e s t f a u l t tolerance double COMPUTING_CONS; //computing overhead energy consumption for HEAD node double ENERGY_LIMIT; // energy lower limit , i f head has energy l e s s than this , send NTF RETIRE double HEAD_INFO_TIMEOUT; // for purge timeout head info in sink node double down_head_rate ; // for f a u l t tolerance test , the percentage of head to be shutdown node_entry_t bch_record ; // for debugging and solving segmentation f a u l t
// // // //
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
76
63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
// my profile , store s e l f values node_table_t ngb_table ; // neighbor t abl e node_table_t ∗ ngb_lvl_table ; // for store one l e v e l lower ADV node info node_table_t sub_table ; // sub table , when received sub , put i t in . node_table_t pub_table ; //pub table , when received pub , put i t in . node_table_t backup_table ; // backup_table , to store backup information fwd_table_t fwd_table ; // for ADV forward // sink node store head info WirelessPhy ∗ n e t i f _ ; // pointer to the network interface object Mac802_11 ∗mymac ; // pointer to the MAC layer object AODV∗ aodvagent ; // pointer to the AODV object EnergyModel ∗ energy_model ; // pointer to the EnergyModel object
Rock_State_Timer rock_state_timer_ ; − Rock_PrBrADV_Timer rock_prbradv_timer_ ; r o c k _ h e a d i n f o sink_hhead ;
profile_t profile ;
98 Rock_Timeout_Timer rock_sub_timeout_timer_ ; 99 Rock_Timeout_Timer rock_inv_timeout_timer_ ; 100 Rock_Timeout_Timer rock_ntf_timeout_timer_ ;
// for T1 T2 time up event // for p e r i o d i c a l l y broadcast ADV Rock_KeepAlive_Timer rock_keepalive_timer_ ; // for keep a l i v e in Done phase Rock_HDADV_Timer rock_hdadv_timer_ ; // for HEAD in DONE phase dealing with ADV that is one l e v e l l e s s than HEAD' s 97 // the following timers are for timeout resend event
Here are the functions in the RockAgent Class.
1 2 RockAgent ( ) ; 3
4 v i r t u a l int command ( int argc , const char ∗ const ∗ argv ) ; 5 6 ∗ ∗
// construction function // start , stop , and set variables are done here . communication with t c l ; override command in Agent Class / I n i t i a l i z a t i o n functions /
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
77
7 void i n i t _ n o d e ( ) ; 8 9 int g e t _ l o w e r _ l a y e r ( ) ; 10 11 12 ∗ ∗ 13 ∗ 14 void s t a t e _ u p d a t e ( ) ; 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
void t1_handler ( ) ; void t2_handler ( ) ; void done_handler ( ) ; void t1_time_up ( ) ;
// i n i t i a t e the node i t s e l f // get pointers to the lower layer / Timer functions / / Handlers for time stat events ∗ / // state_update for time_driven event and handlers // The following are handlers for T1, T2 and Done time state events
/ ∗ Callback functions for timers dealing with time −up events ∗ / // T1 time up callback void t2_time_up ( ) ; // T2 time up callback void hd_adv_timer_callback ( ) ; // callback function for rock_hdadv_timer , dealing with one l e v e l l e s s ADV void k e e p _ a l i v e ( Rock_KeepAlive_Timer ∗ t i m e r ) ; //In Done phase , execute periodical tasks void t i m e o u t _ c a l l b a c k ( msg_type_t type ) ; // timeout resend callback function void c a n c e l _ a l l _ t i m e r s ( ) ; //Cancel a l l timers / ∗ Handlers for message events ∗ / v i r t u a l void r e c v ( Packet ∗ , Handler ∗ ) ; // callback function for receiving a Rock AGT packet ; override recv in Agent Class // handlers for d i f f e r e n t types of message
void void void void void void void
ADV_handler ( Packet ∗ SUB_handler ( Packet ∗ PUB_handler ( Packet ∗ INV_handler ( Packet ∗ NTF_handler ( Packet ∗ ACK_handler ( Packet ∗ DET_handler ( Packet ∗ pkt ) ; pkt ) ; pkt ) ; pkt ) ; pkt ) ; pkt ) ; pkt ) ;
void si n k _ r e c v _ h a n d l e r ( Packet ∗ pkt ) ;
// for handling PUB msg received by sink / ∗ Message sending functions ∗ / // general send functions for SUB, PUB INV, NTF etc .
void send_msg ( int type , node_entry_t ∗ entry , Packet ∗ pkt ) ;
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
78
53 54 55 56 57 58 59 60
void send_ADV ( ) ; void send_SUB ( node_entry_t ∗ e n t r y ) ; void s u b s c r i b e _ t a b l e ( node_table_t ∗ t a b l e ) ; void void void void
//send sub to a l l the entry in the ta bl e
; 61 void send_DET( uint16_t b c h i d ) ; 62 63 int forward_Broadcast_ADV ( Packet ∗ pkt ) ; 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93
send_PUB( node_entry_t ∗ e n t r y ) ; send_INV ( node_entry_t ∗ e n t r y ) ; send_NTF( uint16_t i d ) ; send_ACK( node_entry_t ∗ entry , uint16_t seq , msg_type_t type )
//send DET from head to BCH for l ink broken detection // forward broadcast ADV messages ; return 1 i f the packet needs forwarding ; return 0 i f not . / ∗ Table functions ∗ / int update_node_table ( node_table_t ∗ t a b l e , Packet ∗ pkt ) ; // return the update entry index in the node table , i f not updated , return −1 void c l e a r _ t a b l e ( node_table_t ∗ node_table ) ; // clear one ta bl e void c l e a r _ t a b l e s ( ) ; // clear a l l t a b l e s int d e l _ r e c o r d _ i n _ t a b l e ( node_table_t ∗ node_table , uint16_t i d ) ; // delete a record from a table , return 1 i f succeed in deleting , return 0 i f not int i s _ i n _ t a b l e ( node_table_t ∗ t a b l e , uint16_t i d ) ; // i f in table , return the index ; ; i f not , return −1 node_entry_t ∗ find_top_energy_record ( node_table_t ∗ t a b l e ) ; // return the pointer to the record with the l a r g e s t energy in the tab le ; return NULL i f ta bl e empty node_entry_t ∗ f i n d _ r e c o r d ( uint16_t id , node_table_t ∗ t a b l e ) ; // find a record based on id , return that record i f found ; return NULL i f not int t a b l e _ p u r g e ( node_table_t ∗ t a b l e ) ; // for maintain t ab le and delete outdated records / ∗ List Functions ∗ /
void i d _ i n s e r t ( uint16_t id , uint8_t l e v e l ) ; void id_remove ( uint16_t i d ) ; void id_purge ( ) ; int id_total_number ( ) ; void determine_ch ( ) ;
HeadInfo ∗ id_lookup ( uint16_t i d ) ;
94 b o o l select_BCH ( ) ;
/ ∗ Other functions ∗ / // c a l l ed when T1 times up , the nodes s e l f determines whether i t is Head
APPENDIX A.
IMPLEMENATION OF ROCKAGENT CLASS
79
95 96 void BCH_takeover ( ) ; 97 98 99 100 101
// s e l e c t BCH, return f a l s e i f failed , return true i f ok // get the pointers of the MAC and WirelessPhy layers , return TCL_OK or TCL_ERROR void count_pkt_msg ( int fwd ) ; // count the t o t a l sent msg and t o t a l sent pkt void shutdown ( ) ; //shutdown the node
Appendix B Usage of RockAgent
We list the RockAgent parameters and commands in TCL and explain their usage in this part.
1 2 3 set r o c k a g e n t [ new Agent /Rock ] 4 5 6 $ns attach − agent $node_ ( $count ) $ r o c k a g e n t 7
# the following is about our RockAgent Usage # set a new rock agent
The following code explains how to new a rock agent in a TCL script.
# attach i t to the node
The following part explains the usage of RockAgent parameters.
1 $ r o c k a g e n t set ADV_broadcast_interval_ 1 2
3 4 $ r o c k a g e n t set forward_broadcast_ADV_ t r u e 5 6 7 $ r o c k a g e n t set v e r b o s e t r u e 8
# set the i n t e r v a l of p e r i o d i c a l l y broadcast ADV in T1 phase, default value is 1 # set true i f a node forward others ADV, f a l s e not, default is false # set true i f you want to see a l l logs and outputs during run time, set f a l s e not # no longer used, set the p a c k e t s i z e , now could control by the class i t s e l f # set the base ADV TTL value, default is 2
80
9 10 $ r o c k a g e n t set p a c k e t S i z e _ 20 11 12 13 $ r o c k a g e n t set BTTL_ 2 14
APPENDIX B.
USAGE OF ROCKAGENT
81
15 16 $ r o c k a g e n t set T1_DURATION_ 2 17 18 19 $ r o c k a g e n t set T2_DURATION_ 4 20 21 22 $ r o c k a g e n t set T1_T2_DELTA 0 . 5 23
# set the T1 duration, default is 2 sec # set the T2 duration, default is 4 sec # set the delta value for increase of T1 and T2 per l e v e l up, default value is 0 .5 sec # set the time length for a CH to block ADV and wait for PUB. default value is 5 sec # set the timeout time, default value is 1 sec # set the retry li mi t for rounds, default is 5 # set the max l e v e l a node could reach, default is 1 , which means a f l a t c l u s t e r . ( node l e v e l s t a r t s from 0) # no longer used, the code can get the init_energy automatically # t e l l a node the t o t a l number of nodes in the simulation # set duty cycle l e n g t h , default is 5 # set the sink node address
$ r o c k a g e n t set s i n k $ v a l ( nn ) $ r o c k a g e n t set PUB_INTERVAL 5 $ r o c k a g e n t set t o t a l n o d e s $ v a l ( nn ) $ r o c k a g e n t set i n i t _ e n e r g y 100
24 25 $ r o c k a g e n t set WAIT_PUB_DURATION_ 5 26 27 28 $ r o c k a g e n t set TIMEOUT_RESEND 1 29 30 31 $ r o c k a g e n t set RETRY_LIMIT 2 32 33 34 $ r o c k a g e n t set MAX_LEVEL 1 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
51 52 $ r o c k a g e n t set f i x _ c l u s t e r f a l s e 53
# set true i f simulate non − cluster network, f a l s e i f not, default is f a l s e # set true i f simulate fix_cluster (no delegation, a CH w i l l shutdown i t s member i f the CH f a i l s ) , default is f a l s e # set true i f t e s t energy consumption
$ r o c k a g e n t set n o _ c l u s t e r f a l s e
54 55 $ r o c k a g e n t set test_energy_consumption f a l s e 56 57 ( t h e node w i l l p e r i o d i c a l l y send PUB t o CH and CH a l s o send t o t h e s i n k node ) , default i s f a l s e
APPENDIX B.
USAGE OF ROCKAGENT
82
58 59 $ r o c k a g e n t set f a u l t _ t o l e r a n c e f a l s e 60
61 62 $ r o c k a g e n t set Computing_Energy_Consumption 0 . 0 0 0 0 8 7 4 1 5 63 set t h e computing e n e r g y consumption for data a g g r e g a t i o n e v e r y duty c y c l e J o u l e . D e f a u l t i s 0 . 0 0 0 0 8 7 4 1 5 J o u l e 64 65 $ r o c k a g e n t set ENERGY_LIMIT 10 66 67 default v a l u e i s 10 J o u l e 68 69 $ r o c k a g e n t set down_head_rate 0 . 1 70
# set true i f need f a u l t tolerance ( Function Delegation ) support, default is f a l s e
# set the Energy Low l i m i t . I f a CH detects i t s energy l e s s than t h i s value, i t w i l l t r i g g e r BCH take over. # In f a u l t tolerance t e s t , the percentage of CHs in the network to be shut down. default is 0 .1 (10%)
The following part introduces the commands that could be called in a TCL script:
1 2 $rockagent s t a r t 3 4 5 $rockagent stop 6
# s t a r t the rock agent # stop the rock agent, actually just print out something, write log f i l e and do not actually stop # shutdown the rock agent, also shutdown the r e l a t i v e energy_model and the WirelessPhy o b j e c t . Usually ju st executed in the code, not d i r e c t l y in a t c l s c r i p t # No longer used. Re initiate a node. #Only excute when the rockagent is on the sink node. Shutdown certain percentage of Chs randomly at the c a l l i n g time. # d i r e c t l y change the energy value in the enery_model o b j e c t .
7 8 $ r o c k a g e n t shutdown 9
10 11 $ r o c k a g e n t r e s t a r t 12 − 13 14 $ r o c k a g e n t sink_shutdown_random_head 15 16 17 $ r o c k a g e n t s e t − e n e r g y $ v a l u e 18
