A Flexible Framework for Hierarchical Clustering on Wireless Sensor Networks

A Flexible Framework for Hierarchical Clustering on Wireless Sensor

Networks

Yi Gong

June 30, 2010

Master of Science Thesis Stockholm, Sweden 2010 TRITA-ICT-EX-2010:199

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

Degree Programme of Security and Mobile Computing

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 eciently 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 eciency, 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 pro- vides the fault tolerance and load balancing features. Multi-Level Clus- tering 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 eciency of our algorithm are promising, especially in the bridge topologies.

Keywords: Wireless Sensor Network, Hierarchical Clustering Algorithm, Simulation, NS-2

Language: English

ii

iii   

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:

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

ACA Autonomous Component Architecture

AODV Ad hoc On-Demand Distance Vector Routing

BCH Backup Cluster Head

CH Cluster Head

CM Cluster Member

DSDV Destination-Sequenced Distance-Vector Routing

DSR Dynamic Source Routing

GPSR Greedy Perimeter Stateless Routing

IC Integrated Circuit

ISMO Intelligent Structural Health Monitoring System LR-WPAN Low-Rate Wireless Personal Area Network

OOP Object Oriented Programming

SH Cluster Sub-Head

WSN Wireless Sensor Network

v

Abbreviations and Acronyms v

1 Introduction 1

1.1 Related Work . . . 1

1.2 Problem Statement . . . 3

1.3 Objectives and Scopes . . . 4

1.4 Methods . . . 5

1.5 Structure of the Thesis . . . 6

2 Clustering Algorithm 7 2.1 Architecture . . . 8

2.2 Denitions . . . 8

2.3 Flat Clustering Protocol . . . 10

2.4 Function Delegation Protocol . . . 13

2.5 Multi-Level Clustering Protocol . . . 16

3 Current State of Simulator 18 3.1 J-Sim . . . 18

3.2 OMNeT++ . . . 20

3.3 NS-2 . . . 20

3.4 Comparison . . . 21

4 Implementation 23 4.1 Protocol Stack and Platform . . . 23

vi

4.4 Flat Clustering . . . 32

4.5 Function Delegation . . . 34

4.6 Multi-Level Clustering . . . 36

5 Evaluation 39 5.1 Simulated Environment . . . 39

5.2 Test Criteria . . . 41

5.3 Simulation Analysis . . . 43

5.3.1 Flat Clustering . . . 43

5.3.2 Delegation Protocol . . . 54

5.3.3 Hierarchical Clustering . . . 57

6 Conclusion and Future Work 67 6.1 Conclusion . . . 67

6.2 Future Work . . . 67

A Implemenation of RockAgent Class 73 A.1 Class . . . 73

A.2 Parameters and Functions . . . 73

B Usage of RockAgent 80

vii

3.1 Comparison of dierent simulators . . . 21

5.1 ns2 Energy Model . . . 41

5.2 Flat clustering results . . . 54

5.3 Hierarchical clustering results in the bridge case . . . 64

5.4 Hierarchical clustering results in the matrix case . . . 65

viii

2.1 Network architecture . . . 8

2.2 Flat clustering protocol . . . 11

2.3 Node joins an existing cluster . . . 12

2.4 Delegation protocol . . . 14

2.5 SUB lost during the process of delegation . . . 15

2.6 Hierarchical clustering protocol . . . 16

3.1 Comparison of dierent simulator packages . . . 21

4.1 General protocol stack of a node . . . 24

4.2 Modied schematic of a node under the CMU monarch wireless extensions to ns [22] . . . 25

4.3 Simple RockAgent class collaboration diagram . . . 26

4.4 General packet structure . . . 29

4.5 Message driven handlers . . . 31

4.6 Time driven handlers . . . 31

4.7 Timers . . . 32

4.8 Flat clustering state diagram . . . 33

4.9 Delegation state diagram . . . 35

4.10 Hierarchical clustering state diagram . . . 37

5.1 Bridge and matrix topologies with diagonal connection . . . . 40

5.2 Isolated nodes number in the bridge case . . . 44

5.3 Isolated nodes number in the matrix case . . . 44

ix

5.6 System energy consumption regarding to nodes number in the

bridge case . . . 48

5.7 System energy consumption regarding to nodes number in the matrix case . . . 48

5.8 Saved system energy percentage in the bridge case . . . 50

5.9 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

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 applica- tions, sensor nodes have the capability of detecting surrounding conditions, such as vibration, temperature and illumination. And these sensors are usu- ally 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 predened 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 eciency and

1

so on. IEEE 802.15.4 [37] has become a popular standard which species the physical layer and media access control for low-rate wireless personal area networks (LR-WPANs). Based on the IEEE 802.15.4, specications attempt to oer complete solutions to WSN with upper layer supports, such as ZigBee [15], WirelessHART [13] and MiWi [23]. In addition, recently several modications [33, 41] of IEEE 802.11 [14] are also available for WSN considering energy eciency.

Several ad-hoc routing protocols have been applied in WSN to provide multi- hop routing, such as Ad hoc On-Demand Distance Vector (AODV) rout- ing [35], Destination-Sequenced Distance-Vector (DSDV) routing [36] and Dynamic Source Routing (DSR) [29]. Finally, a number of clustering algo- rithms 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 eciency 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

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 scalabil- ity, load balancing, fault tolerance, energy eciency and multi-level cluster- ing together into consideration. Furthermore, the above mentioned solutions are usually tightly coupled with lower layers or specic to certain application so that it is dicult 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 eciently organize a large scale WSN with numerous nodes, especially in the condition that each node sends data to the sink node simultaneously

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 re- dundant 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 miss- ing other features. Few of them could take scalability, load balancing, fault tolerance, energy eciency and multi-level clustering structure all into consideration.

2. Existing solutions are usually tightly coupled with lower layers or spe- cic to certain application so that it is dicult for application layer development as well as lower layer modications.

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

on middleware layer based on Publish / Subscribe paradigm. The algorithm takes scalability, load balancing, fault tolerance, energy eciency and multi- level 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 de- velopment. 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 sup- port great network scalability as well as provides topology exibility. And our algorithm includes three protocols, namely Flat Clustering protocol, Func- tion Delegation protocol and Hierarchical Clustering protocol aiming at constructing a multi-level cluster structure in a WSN from the bottom up.

In order to validate the design of this new algorithm and evaluate its perfor- mance in a relatively short period with low expense, we decide to simulate this algorithm on a simulator. There are several popular simulators includ- ing 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 ex- tensibility 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 simula- tion framework for this algorithm on the NS-2 simulator and gain several results considering protocol performance and energy eciency. Based on our simulation, we optimize key parameters for our algorithm and nd that the performance and the energy eciency 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

Literature review builds up a sound foundations for this thesis work. In ad- dition, simulator survey provides the understandings of advantages as well as disadvantages of dierent simulators and helps us select the suitable sim- ulator 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 NS- 2. 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.

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 fulll 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 eciency in some cases according to our simulation in Sec.5.

7

SH(1)

CM(0)

CH(2)

Node CH(1)

CM(0) CM(0) CM(0) CM(0) CM(0) CM(0) SH(1)

Sink Node

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 Denitions

Before the introduction of the three protocols, we need to dene four roles of a node, six message types and three time phases.

Firstly, a node in our clustered network could have 4 roles, Node, CM (Cluster Member), CH (Cluster Head) and SH (Sub Cluster Head).

Node stands for a node which just starts and does not join a cluster. CM always stands for a level-0 node which has already joined a cluster and sends data to its CH periodically. CH 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, SH 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.

In addition, our algorithm denes 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 immedi- ately 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

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, T1, T2 and DONE.

In T1 time phase, a node usually broadcasts ADVs which contain the energy value of the sending nodes and stores the information of received ADVs. In T2 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 conrm 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 conrmation for its participation and becomes a CM. DONE 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.

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 en- ergy 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 en- ergy 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

Node Node Node

Periodically Broadcast ADV Periodically Broadcast ADV

T2

SUB

SUB

ACK

PUB PUB

ACK

CH

CM

T1

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

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 conrms 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.

T1

Node CH

Broadcast ADV SUB PUB

ACK DONE

CM

T2

Figure 2.3: Node joins an existing cluster

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 inuence 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 - Function Delegation 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.

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

CM

CH CM CM

INV ACK

NTF(RETIRE) ACK(BCH_START)

SUB

SUB PUB

PUB

INV ACK ACK

ACK

DONE DONE

T1 T2

DONE DONE

T2

T2

DONE T2

Node

Node CH

Node BCH

CM

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

CM

CH BCH CM

NTF(RETIRE) ACK(BCH_START)

SUB

SUB PUB

PUB

INV ACK ACK

ACK

DONE DONE

T1 T2

DONE DONE

T2

T2

DONE T2

Node

Node CH

Node CM

CM

BCH

SUB (Resend)

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 modication, 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 modication 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.

CH(L) CH(L) CH(L)

Periodically Broadcast ADV Periodically Broadcast ADV

SUB SUB

ACK

PUB PUB

ACK

CH(L+1)

T1

SH(L)

SH(L)

T2

INV ACK

BCH (L)

DONE

Local Delegation

Figure 2.6: Hierarchical clustering protocol

2.5 Multi-Level Clustering Protocol

In WSNs, a 2-level clustering structure has its benets, 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 benets.

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 trac 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 trac 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 eciency.

Therefore, based on the above two protocols, we design the third protocol - Multi-Level Clustering 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 multi- level 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.

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.

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 specic to applications and ser- vices. 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, develop- ers 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, OM- NeT++ 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

which is similar to software integrated circuit (IC) design architecture. Be- cause 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 species how an initia- tor (caller) and a reactor (callee) fulll 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 con- tract, 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 im- plements "Script" to organize all the components and dene 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.

3.2 OMNeT++

OMNeT++ is a relatively new simulator, which "is an extensible, modular, component-based C++ simulation library and framework, with an Eclipse- based 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], IN- ETMANET [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 im- plementations, such IEEE 802.15.4 CSMA/CA, T-MAC [39], S-MAC [42]

and so on. However, Castalia only provides simpleTreeRouting and mul- tipathRingsRouting [1], which is not enough for our simulation. For the INETMANET framework, it provides both 802.11 and 802.15.4 MAC imple- mentations, 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 frame- work 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 imple- mentation 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

could also be a good option for our simulation.

3.4 Comparison

Now we have looked into three simulators and known about their advan- tages 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 J-Sim OMNeT++ NS2

Development Closed Ongoing Ongoing

Community Few Some Some

Docs & Extension Some Some Many

Tools Some Some Many

Scale Medium Large Medium

Performance Slow Fast Fast

Dev. Diculty Easy Medium 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

provides all the necessary packages and meets our three criteria. And it has abundant documentations and extension packages. However, it is more dicult 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.

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 pro- tocols 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 ecient 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

WirelessPhy Clustering Protocol

Wireless Channel Routing protocols

802.15.4/802.11 IP Layer

Node

Figure 4.1: General protocol stack of a node

TCL scripts serves as "glue" to "mix up" these classes and also species 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 reection 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.

RTagent (AODV) Rock_Agent

LL ARP

IFq

MAC

NetIF Radio

Propagation Model

channel_

uptarget_

Channel

uptarget_

downtarget_ uptarget_

downtarget_

downtarget_

mac_

propagation_

arptable_

uptarget_

IP address

defaulttarget_

255

entry_

addr demux

port demux

energy_model SELF_ENERGY

Wireless Node

energy_model_

Figure 4.2: Modied schematic of a node under the CMU monarch wireless extensions to ns [22]





5RFN$JHQW





5RFNB6WDWHB7LPHU





5RFNB3U%U$'9B7LPHU





5RFNB+'$'9B7LPHU





5RFNB7LPHRXWB7LPHU





5RFNB.HHS$OLYHB7LPHU

VWUXFW!!

URFNBKHDGLQIR

VWUXFW!!

IZGBWDEOHBW

VWUXFW!!

IZGBHQWU\BW

VWUXFW!!

QRGHBWDEOHBW

VWUXFW!!

SURILOHBW

VWUXFW!!

QRGHBHQWU\BW





































 











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

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 func- tions 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 mes- sages 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

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.

prole 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 in- formation 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 respon- sible for forwarding broadcast ADVs. And rock headinfo is responsible for the storage of head information on the sink node.

Finally, we dene 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,

General Packet Structure

ADV Packet

Energy Capability

SUB Packet

Interests[]

Interest_nu m

Length Location

Level Seq

Id PUB

PUB Packet

Results[]

Result_nu m ADV Payload

SUB Payload

PUB Payload

Quality Value

Type

Results Item Structure

Length Location

Level Seq

Id INV

INV Packet

Backup table[]

Number

Seq Location Capability

Energy Level

Addr Id

Backup Table Structure

INV Payload

NTF Packet

Length Location

Level Seq

Id NTF

NTF Payload

Ntf payload Ntf_option

Length Location

Level Seq

Id ACK

ACK Packet

Length Location

Level Seq

Id SUB

Payload Length

Location Level

Seq Id

Type

Length Location

Level Seq

Id ADV

ACK_Type ACK_Seq

ACK Payload

Figure 4.4: General packet structure

there are six types of packets as we dene 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 identication 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-congured 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 dene 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 rep- resenting 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 deal- ing 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.

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 in- cludes 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 re- spectively. And we have explained the main usages for these timers in the descriptions of the main classes in Sec. 4.2.

Rock_State_Timer::expire

RockAgent::T1_time_up RockAgent::T2_time_up

Rock_PrBrADV_Timer::expire

RockAgent::Send_ADV

Rock_HDADV_Timer::expire

RockAgent::hd_adv_timer_callback

Rock_KeepAlive_Timer::expire

RockAgent::keep_alive

Rock_Timeout_Timer::expire

RockAgent::timeout_callback

Figure 4.7: Timers

4.4 Flat Clustering

We design the 3 protocols respectively and this section includes the imple- mentation 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 (T1, Node) 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 (T2, Head) 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 (T2, Node) 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 (DONE, Head) state while CMs that have joined a cluster will clean their ngb table and go to (Done, Member) state. When a CH is at (DONE, Head) phase, it also listens for ADVs and recruits members. Finally, nodes in these two

T1, Node

T2, Head

Send/Recv ADV

T1 time up

T2, Node

CH

Not CH

Send SUB

T2 time up

Done, Head

Recv SUB, Reply PUB

Has member No member

Recv PUB, Reply ACK

T2, Member

Recv ACK

Done, Member

T2 time up Determine

CH T2 time

up, still Node, not

reach Retry Limit

T2 time up, still Node, reach Retry Limit

Recv ADV, Reply SUB

Recv PUB, Reply ACK Recv SUB,

Reply PUB

T2 time up, no member, reach Retry Limit

Done, Node

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 prob- ability of successful clustering, when a node at (T1, Node) state receives a SUB message, it immediately goes to (T2, Node) and replies with a SUB message. Moreover, it is possible that after T2 times up, a node at (T2, Node) state does not receive SUB or ACK, and a node at (T2, Head) state is not able to recruit any member. In these conditions, nodes roll back to (T1, Node) state and try another round to join a cluster. Furthermore, the Retry Limit 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 (Done, Node) state and send data directly to a sink node periodically. We dene such a kind of nodes as Isolated Nodes.

In our simulations in Chapter 5, we control the percentage of such a kind of nodes to be less than 5%.

Therefore, after the at clustering process, a node nally goes to the following