position-basedaggregatornodeelectionin …buttyan/publications/buttyans10ijdsn.pdf · wireless...

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2010, Article ID 679205, 15 pagesdoi:10.1155/2010/679205

Research Article

Position-Based Aggregator Node Election inWireless Sensor Networks

Levente Buttyan1 and Peter Schaffer2

1 Laboratory of Cryptography and Systems Security (CrySyS), Budapest University of Technology and Economics (BME),1117 Budapest, Hungary

2 Interdisciplinary Centre for Security, Reliability and Trust (SnT), University of Luxembourg (UL), 1359 Kirchberg, Luxembourg

Correspondence should be addressed to Peter Schaffer, [email protected]

Received 25 September 2008; Accepted 13 August 2009

Copyright © 2010 L. Buttyan and P. Schaffer. This is an open access article distributed under the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properlycited.

We introduce PANEL a position-based aggregator node election protocol for wireless sensor networks. The novelty of PANEL withrespect to other aggregator node election protocols is that it supports asynchronous sensor network applications where the sensorreadings are fetched by the base stations after some delay. In particular, the motivation for the design of PANEL was to supportreliable and persistent data storage applications, such as TinyPEDS; see the study by Girao et al. (2007). PANEL ensures loadbalancing, and it supports intra and intercluster routing allowing sensor-to-aggregator, aggregator-to-aggregator, base station-to-aggregator, and aggregator to-base station communications. We also compare PANEL with HEED; see the study by Younis andFahmy (2004) in the simulation environment provided by TOSSIM, and show that, on one hand, PANEL creates more cohesiveclusters than HEED, and, on the other hand, that PANEL is more energy efficient than HEED.

1. Introduction

Wireless sensor networks consist of a multitude of tinysensor nodes capable for wireless communications and a fewpowerful base stations. The sensor nodes usually performsome monitoring task (e.g., measure various environmentalparameters). The base stations collect sensor readings andforward them for further processing to a service center.

Based on how the sensor readings reach the base stations,we can distinguish synchronous and asynchronous sensornetworks. In the synchronous case, the sensor readingsare sent to the base stations in realtime using multihopwireless communications, where the sensor nodes coopera-tively forward data packets on behalf of other sensor nodestowards the base stations. In the asynchronous case, thesensor readings are fetched by the base stations after somedelay (e.g., once every day or week). In this case, the basestations are often mobile, and they physically approach thesensors in order to fetch their data through a single wirelesshop. Examples of synchronous sensor network applicationsinclude forest fire alarm systems and building automationsystems where realtime operation is indispensable. Examplesof asynchronous applications include habitat monitoring

systems and agricultural applications such as vineyardmonitoring where realtime operation is not an issue.

As sensor nodes are often severely resource constrained,various techniques have been proposed to ensure the efficientoperation of sensor networks. One of these techniques iscalled aggregation or in-network processing. The idea is that,instead of forwarding (in case of synchronous applications)or storing (in case of asynchronous applications) rawsensor readings, data can be first processed, combined,and compressed by some distinguished sensor nodes, calledaggregators.

While aggregation increases the overall efficiency of thesensor network, the aggregator nodes themselves use moreresources than the regular sensor nodes. For this reason, it isdesirable to change the aggregators from time to time, andthereby, to better balance the load on the sensor nodes. Forthis purpose, aggregator node election protocols can be usedin the sensor network that allow dynamic reassignment of theaggregator role.

In this paper, which is an enhanced version of ourpreviously published conference paper in [1], we introducePANEL: a position-based aggregator node election protocolfor wireless sensor networks. As its name indicates, PANEL

2 International Journal of Distributed Sensor Networks

uses the geographical position information of the nodesto determine which of them should be the aggregators.Like other aggregator node election protocols, PANEL alsoensures load balancing in the sense that each node is anelected aggregator nearly equally frequently. The salientfeature of PANEL that makes it novel and different fromother aggregator node election protocols is that besides syn-chronous applications, PANEL also supports asynchronousapplications.

In particular, the motivation for the design of PANELwas to support TinyPEDS (Tiny Persistent Encrypted DataStorage) [2], and other similar asynchronous sensor networkapplications. In TinyPEDS, aggregator nodes collect andaggregate sensor readings from the clusters that they areresponsible for, and then persistently store the aggregatedvalues (in an encrypted form). In addition, in order toincrease reliability, the aggregators replicate their storeddata at the aggregators of some selected backup clusters.These backup aggregators (i.e., the aggregators in the backupclusters) must be chosen in such a way that they are fartheraway from the primary aggregator than a certain distancecalled the disaster radius. The rationale is that if there isa disaster in which the primary aggregator is destroyed,its data is still available at and can be retrieved from thebackup aggregators. Being a position-based protocol, PANELsupports TinyPEDS and applications alike by providingassurances regarding the distance between the elected aggre-gator nodes.

The organization of the paper is the following. InSection 2, we report on the related work. In Section 3, weintroduce the general assumptions that we based the designof PANEL upon. In Section 4, we describe the operationof PANEL. In Section 5, we present our simulation-basedcomparison of the performance of PANEL with that ofHEED [3]: an aggregator node election protocol well knownfrom the literature. In Section 6, we discuss some possibleextensions of PANEL. And finally, in Section 7, we concludethe paper.

2. Related Work

Dividing the sensor network into clusters and using in-network aggregation is an effective way to treat the enormousamount of information produced by the sensor nodes.Several papers have been published in this research area forsensor networks; we list the related ones below.

There are some papers that give an overview of in-network aggregation and cluster formation solutions. One ofthese papers is that in [4], which discusses the main issues ofclustering in sensor networks and concludes that clusteringis a useful tool for topology management and for in-networkdata aggregation. In [5], the authors detail the different dataaggregation techniques and highlight the tradeoffs betweenenergy efficiency, data accuracy, and latency. In [6], one canread about a comparison of homogeneous (i.e., all of thenodes have same hardware capability) and heterogeneous(i.e., nodes have different hardware capabilities) sensornetworks from clustering point of view, while in [7], the

authors investigate the schemes of single-hop and multihopcommunications and their impact on clustering.

The papers that propose solutions for clustering canbe classified based on their primary aim (however, mostof these papers have multiple aims). The largest groupaccording to this classification consists of papers that aimat lifetime maximization of the sensor network. This groupof papers can be further divided based on the method thatthey use for the clustering: it can be either probabilistic ordeterministic. In case of probabilistic solutions, the clusterheads are elected based on some randomness, while incase of deterministic solutions, some iterative or centralizedstrategies are deployed.

The most known probabilistic cluster formation algo-rithm is the LEACH protocol [8, 9]. In LEACH, the clusteringgoes as follows: in every round, each sensor node picks arandom number, and if this random number is smaller thana threshold, the node becomes a cluster head. Next, it adver-tises itself with constant energy via radio communicationand waits for cluster members. The cluster members are thenoncluster head nodes, and each of them joins that clusterhead’s cluster whose advertisement was received with thehighest energy (in general, this is the nearest cluster head’scluster). The properties of LEACH are that it flatly balancesthe energy consumption of the network; however, it uses onlyone-hop communication; the remaining energy of the nodesis not a parameter by the election (but it should be becauseof the increased energy needs of a cluster head node); andthe protocol requires every node to be able to reach the basestation in one hop, which is not generally true in sensornetworks.

Other related probabilistic cluster formation solutionscan be found in [10–15]. In [10, 11], one can read about adata gathering scheme, called PEGASIS, that forms a chain ofnodes and elects a leader node for energy-efficient collectionof the sensors’ measurements. In [12], the authors propose atechnique to build k-hop clusters, that is, where the clustermembers are at most k-hops away from the cluster head. In[13], a LEACH-like idea is exploited considering the residualenergy of the nodes as well. In [14, 15], the problem ofunequal-energy dissipation is considered in case of equallysized clusters. Therefore, in these latter papers, the authorspropose to form unequal size clusters: smaller ones closeto the base station and larger ones further from it, as thecluster heads of closer-lying clusters have more load due tothe message forwarding task for further-lying clusters.

The most important probabilistic solution for ourpurposes is HEED [3], which can also be considered asthe generalization of [8] and [13]. In HEED, the clusterformation algorithm is more sophisticated; it elects thecluster heads based on their remaining energy and on asecondary parameter that can control the cluster density,the load balancing, and the amount of intracluster commu-nication. The HEED protocol seems to be a good tradeoffbetween termination speed and cluster head distribution byallowing some communication between neighboring nodes.The simulation results of HEED show that it outperformsLEACH in terms of network lifetime and in ratio of energydissipated for clustering.

International Journal of Distributed Sensor Networks 3

The list of papers that aim at network lifetime maximiza-tion using a deterministic aggregator node election method isquite extensive as well. In [16–18], one can find solutions forthe mentioned problem assuming that the sensor networkis heterogeneous; that is, there are less-energy-constrainedgateway nodes among the usual constrained sensor nodesthat can help in cluster formation and in the routing ofsensor messages. The authors of [19, 20] approach theclustering problem from data gathering point of view, andpropose a centralized solution for near-optimal schedulingof the message sending. In [21], the problem of lifetimemaximization is handled by balancing the load of clusterheads and by minimizing the total distance between sensornodes and cluster heads. The study in [22] tackles the sameproblem using fuzzy logic with the variables of energy, nodeconcentration, and node centrality with respect to the entirecluster.

There are some papers that do not primarily aim at net-work lifetime prolongation, but at quick cluster formation.In [23], the authors consider event-driven sensor networkswith high degree of spatial-temporal correlation. The mainfocus of the paper is on cross-layered design of localizedalgorithms for performing quick data aggregation and quickhierarchy formation allowing prompt response to queries. In[24], one can read about a fast clustering algorithm suitablefor large-scale sensor networks by its property of locality,scalability, and self-healing in case of node failures and newlydeployed nodes.

The following group of papers collects those works thataim at enhanced network management. For example, theobjective of [25] is to show that one can efficiently computean asymptotically optimal clustering, even when collisionresistant packet forwarding is not ensured. The authors of[26] propose a hierarchical clustering approach, where thecluster heads are clustered again at the higher layer of thehierarchy. Here, the clustering problem is defined in a graphtheoretic framework, and a distributed solution is presentedthat results in size-bounded clusters. The ACE algorithm [27]aims at forming minimally overlapping clusters with the helpof cluster migration. The algorithm ends in constant timeregardless of the size of the network and uses only localcommunications between nodes.

Security is rarely considered in the cluster formationor aggregator node election problem. An exception is thestudy in [28], where the authors deal with the issue ofnonmanipulable aggregator node election. When an attackernode is able to manipulate the aggregator election process, itis able to influence the operation of the network, for example,by electing itself as aggregator and maliciously filtering thesensors’ measurements. Three independent countermeasuresare proposed against such an attacker in [28], with all of thembased on distributed random number generation. Anotherexception is the paper in [29], where the author proposed atechnique for resilient cluster formation, which consists of aneighbor validation module based on wormhole detection,a priority-based selection of the cluster head nodes, and acentralized detection module that aims at detecting the nodesthat have an abnormally large number of neighbors (as theseare most likely compromised).

The papers listed above are all related to the aggregatornode election problem assuming clustering. However, noneof the above methods are able to guarantee a minimumdistance between certain aggregators. However, in ourmotivating application area (i.e., reliable and persistentdistributed data storage), backup aggregators must be cho-sen in such a way that they reside farther away fromthe primary aggregator than a certain disaster range. In[30], the authors detail an approach for aggregator nodeelection that is able to guarantee this minimum distance;however, the proposed solution is centralized, and thus,its applicability is limited. On the contrary, PANEL canguarantee a minimum distance between aggregators in adistributed manner, because in PANEL the aggregator nodesreside within fixed-size clusters and are elected locallywithout the need of a central controller. For instance, theminimum distance between two aggregators belonging tononneighboring clusters is dx, where x is the number ofclusters between the two aggregators and d is the physical sizeof the cluster.

3. General Assumptions

One of the main assumptions that PANEL relies on is thatthe sensor nodes are static and they are aware of theirgeographical position. This is obtained either by means ofGPS or by using any of the numerous node positioningalgorithms proposed for wireless sensor networks in theliterature (see, e.g., [31, 32]). We note, however, that PANELdoes not need precise position information (see Section 6.3for the related discussion); therefore, the inaccuracy of thepositioning mechanism does not limit the applications ofPANEL. Unlike the sensor nodes, the base stations maynot necessarily be static, but they can be mobile and theirpresence can be sporadic.

We further assume that the sensor network consists ofhomogeneous sensors (in terms of resources). The sensornodes are deployed in a bounded area, and this area ispartitioned into geographical clusters. We aim at electinga single aggregator per cluster. The density of the networkis large enough so that the nodes within each cluster areconnected when they use maximum power for transmission.In other words, there exists a route between any pair ofsensors of a given cluster that contains only sensors from thatcluster. This assumption on the connectivity within a clusteris crucial to the correct operation of PANEL, and it can besatisfied by appropriately choosing the cluster size (given thedeployment density of the network and the maximum powerrange of the nodes).

Finally, we assume that time is divided into epochs,and the nodes are synchronized such that each of themknows when a new epoch begins. If the nodes are equippedwith GPS, then time synchronization is provided for free.Otherwise, additional mechanisms for time synchronization(see, e.g., [33, 34]) need to be implemented in the network inorder to support PANEL.


Reference pointSensor nodeElected aggregator

Figure 1: Illustration of the geographical clustering in PANEL.

4. Operation of PANEL

In this section, we give a detailed description of the operationof PANEL. We start with a brief overview in order tointroduce the components of PANEL, and then we presentthese components in detail in the subsequent subsections.

4.1. Overview. PANEL assumes that the sensor nodes aredeployed in a bounded area, and this area is partitionedinto geographical clusters. For simplicity, in this paper, weassume that the deployment area is a rectangle and that theclusters are equal-sized squares, as illustrated in Figure 1.We emphasize, however, that the ideas behind PANEL aregeneral, and that PANEL could also be used for areas andcluster forms with more complex shapes.

The clustering is determined before the deployment ofthe network, and each sensor node is preloaded with thegeographical information of the cluster which it belongs to.In our simplified case, each sensor node is preloaded withthe coordinates of the lower-left corner of its cluster, as wellas with the size d of the cluster. In addition, as we mentionedbefore, each node i is aware of its own geographical position−→P i.

At the beginning of each epoch, a reference point−→R j is

computed in each cluster j by every node in a completelydistributed manner. In fact, the computation of the referencepoint depends only on the epoch number, and it can beexecuted by every node independently and locally. Once thereference point is computed, the nodes in the cluster elect thenode that is the closest to the reference point as the aggregatorfor the given epoch (see Figure 1 for illustration).

The aggregator node election procedure needs commu-nications within the cluster. PANEL takes advantage of thesecommunications and uses them to establish routing tablesfor intra-cluster routing. In particular, at the end of theaggregator node election procedure, the nodes also learnthe next hop towards the aggregator elected for the currentepoch.

PANEL also includes a position-based routing protocolthat is used in intercluster communications. As the nodesare aware of their geographical position, this seems tobe a natural choice that does not result in additionaloverhead. The position-based routing protocol is used forrouting messages from a distant base station or from adistant aggregator towards the reference point of a givencluster. Once the message enters the cluster, it is routedfurther towards the aggregator using the intra-cluster routingprotocol based on the routing tables established duringthe aggregator node election procedure. Any position-basedrouting protocol can be integrated with PANEL; currently,we are using the Greedy Perimeter Stateless Routing (GPSR)protocol [35].

PANEL can also support reliable persistent data stor-age applications such as TinyPEDS [2]. Reliability can beachieved by replicating the data aggregated by the aggregatornodes at other aggregator nodes. For this purpose, theaggregator nodes need to be able to communicate witheach other. The routing protocols of PANEL can supportthis by routing the messages containing the replicated datausing PANEL’s position-based intercluster routing protocoltowards the reference point of the selected backup cluster,and then switching to the intra-cluster routing protocol ofPANEL to deliver the data to the aggregator of that cluster.

Finally, we want to point out that in PANEL, the referencepoints of the clusters are recomputed and the aggregatorelection procedure is reexecuted in each epoch. This ensuresload balancing in the sense that each node of the cluster canbecome aggregator with nearly equal probability. In addition,the nodes can accumulate information that they receive inthe different epochs and use that for routing and intrusiondetection purposes (see Section 6.1 for more details).

4.2. Reference Point Computation. In PANEL, the aggregatorelection begins with the computation of a reference point−→R j in each cluster j. The input of this computation is thecurrent epoch number e, which is assumed to be knownby every sensor. The computation itself consists in calling apseudorandom function H that maps e to a relative position−→Q inside the cluster. Formally, H(e) = −→

Q , where−→Q ∈

(−δd,d + δd) × (−δd,d + δd), d is the size of the cluster,and δ < 0.5 is a parameter which we will explain below. The

reference point of cluster j is determined as−→R j =

−→O j +

−→Q ,

where−→O j is the position of the lower-left corner of cluster j.

The pseudorandom function H can easily be imple-mented with a cryptographic hash function. Moreover, thepseudorandomness ofH means that the outputs produced byH for the consecutive epoch numbers look as a sequence ofrandom positions. This ensures the load balancing propertyof PANEL.

Note that the above computation can be executed byevery sensor independently and locally. In addition, thereference points of every past (and future) epoch can alsobe computed easily by anybody. This property is useful inapplications where the sensor network provides persistentstorage services by requiring the aggregator nodes of thedifferent epochs to store the aggregated values that they


Figure 2: The Voronoi cells of the nodes in a cluster.

compute. In these applications, when looking for some dataof a past epoch in a given cluster, one needs to send aquery to the aggregator of that epoch. This requires therecomputation of the reference point of the given cluster inthe given epoch.

Let us now explain why parameter δ is needed in thereference point computation, and how its value can bedetermined. Recall that in PANEL, the node that is theclosest to the reference point of a given cluster is elected asaggregator for that cluster for the given epoch. Assumingthat the nodes are deployed uniformly at random, and thatthe position of the reference point in each epoch is alsoselected uniformly at random, the probability that a givennode becomes aggregator is determined by the size of theVoronoi cell of the node, and the size of the area within whichthe reference point is selected. For load balancing purposes,we would like that each node becomes aggregator with nearlythe same probability, thus, we would like that the Voronoicells of the nodes have approximately the same size.

Let us consider Figure 2 for illustration of the Voronoicells of the nodes in a cluster. We can observe a “bordereffect” in this figure, namely, the size of the Voronoi cellsof the nodes close to the edge of the cluster is larger thanthat of the nodes in the middle. One way to cancel thisborder effect out is to deploy the sensor nodes not at random,but following a given structure. This structure has to ensurethat the sizes of the Voronoi cells of the different nodes areequal. For example, the ideal deployment position for nodei(i ≤ n) in one dimension in [0, t] is at ((2i − 1) · t)/2n,where n is the number of nodes. However, deploying thenodes by hand is often impossible (e.g., in many militaryapplications); therefore, we set aside this solution. Even if weassume that the node deployment is fixed, we can effectivelymitigate this border effect by adjusting the size of the areawithin which the reference point is selected, as with this, wecan adjust the size of the Voronoi cells of the nodes on theedge of the cluster. Parameter δ expresses the magnitude ofthis adjusting operation in percent of the original cluster sized. For example, δ = −0.1 means that on each side of thecluster the bounds are contracted by 10%.

It is not easy to determine an appropriate value for δanalytically due to the complexity of the computation of the

−0.2 −0.15 −0.1 −0.05 0 0.05 0.1

δ (%)

250150

50

Side len

gth

of cluste

r (m)0

0.4

0.8

1.2

1.6

2

S 1/S

2

Figure 3: Determining the value of parameter δ by simulations.

size of the Voronoi cells. Therefore, we propose to determineits value by simulations. In Figure 3, on the z axis, we havethe ratio between the average size S1 of the bounded Voronoicells (i.e., the cells close to the center of the cluster) and theaverage size S2 of the unbounded Voronoi cells (i.e., the cellson the edge of the cluster) as a function of parameter δ andthe cluster size given by the side length. The plane at z = 1corresponds to the optimum, where the average sizes of thecells of the two types are equal. The intersection of this planeand the surface obtained by simulations is projected to thez = 0 plane. This projected curve gives the optimal value ofparameter δ for different cluster sizes assuming that there are10 nodes in the cluster. As one can see, the optimal value isusually between −0.12 and −0.07.

4.3. Aggregator Election Procedure. Once the reference pointsare computed, the nodes start the aggregator node electionprocedure. Each node i sets a timer, the expiration time of

which is proportional to the distance D(−→P i,−→R j) between

the node’s position−→P i and the reference point

−→R j of

its cluster. When this timer expires, the node broadcastsa message with maximum power in which it announcesitself as the aggregator unless the node heard such anannouncement from another node before its timer expired.The announcement message has the following format:

[type | epoch | id | pos

](1)

where “type” is announcement, “epoch” is the current epochnumber, and “id” and “pos” are the identifier and theposition of the originator of the announcement, respectively.

When a node hears an announcement, it verifies whetherthe originator of the announcement is closer to the referencepoint than the node known to be the closest so far (whichcan be the node itself if it has not heard any announcementsyet). If so, then the node records the originator of theannouncement as the candidate aggregator, and rebroadcaststhe announcement. Moreover, if the node still has its timeractive, then it cancels it. Otherwise, the node silently discardsthe announcement. Announcements that belong to otherclusters are also discarded in order to limit the propagationof an announcement within the cluster that it is concernedwith.


Input:

identifier idself and position−→P self of the node executing the algorithm

parameters−→O self and d of the cluster of the node executing the algorithm

current reference point−→R self of the cluster and epoch number enow

running time T of the algorithmOutput:

identifier idaggr and position−→P aggr of the elected aggregator node

set idaggr = idself;

set−→P aggr =

−→P self;

set timer t0 = T ;

set timer t1 = f (D(−→P self,

−→R self));

while timer t0 is still active dowait until timer t1 fires or an announcement m is received;case timer t1 fired:

broadcast [announcement | enow | idself |−→P self] with max power;

case an announcement m = [announcement | e | id | −→P ] is received:if the pair (e, id) has been seen before then drop m;

else if e /= enowor−→P /∈ square (

−→O self,d)then drop m;

else if D(−→P ,−→R self) > D(

−→P aggr,

−→R self)then drop m;

elseset idaggr = id;

set−→P aggr =

−→P ;

if timer t1 is still active then cancel timer t1;rebroadcast m with max power;

end while

output idaggr,−→P aggr

Algorithm 1: The pseudocode of the aggregator election procedure of PANEL.

As the node that is the closest to the reference point sendsits announcement first, there is a high chance that this will bethe single announcement that is flooded inside the cluster.This means that in most cases, each node rebroadcasts asingle message during the aggregator election procedure.In some cases, however, depending on the topology of thenetwork, it may happen that more than one nodes sendtheir announcements. In those cases, only the announcementoriginated by the node that is the closest to the referencepoint will “survive”, meaning that only that announcementwill be received and recorded by every node in the cluster.

After some predefined time T , the aggregator node elec-tion phase is closed, and each node considers the recordedcandidate aggregator as the aggregator for the current epoch.The value of T depends on the time needed for a floodedmessage to cover the largest possible distance within thecluster. This ensures that at the end of the aggregator electionphase, each node must have received the announcement ofthe future aggregator.

The pseudocode of the aggregator election algorithm isgiven in Algorithm 1.

4.4. Routing. Strictly speaking, routing is not an integralpart of aggregator node election protocols. Nevertheless, inPANEL, we make recommendations for the routing protocols

that fit best PANEL’s design assumptions and operatingprinciples. In particular, in PANEL, we envision two kinds ofrouting components: an intra-cluster routing protocol andan intercluster routing protocol.

The intra-cluster routing protocol is used to route amessage to the aggregator of a given cluster if that messageis already inside the cluster. This concerns, on one hand, themessages that contain the measurements of the sensors in thecluster. On the other hand, the intra-cluster routing protocolis also used to route messages from a distant source to thecurrent aggregator or to any of the past aggregators of thecluster once those messages have reached the cluster. Thesemessages include queries originating from a distant basestation and backup messages originating from aggregators ofdistant clusters.

The intra-cluster routing protocol has a stronger con-nection to the operational details of PANEL, therefore, wespecify it explicitly. However, we note that this specificationserves as an example only; other kinds of routing protocolscan also be integrated with PANEL.

The intra-cluster routing protocol of PANEL can takeadvantage of the fact that the nodes within the clustercommunicate during the aggregator election procedure. Inparticular, announcement messages containing the identifierand the position information of their sources are flooded inthe cluster. This can be used to set up backward pointers


towards the sources of the announcement messages in therouting tables of the nodes. More specifically, in PANEL,every node that hears an announcement records the identi-fier and the position of the originator of the announcementas destination, it records the identifier of the node fromwhich it received the first copy of the announcement as thenext hop towards the recorded destination, and it computesand records the power level needed to transmit to this nexthop node. The identifier of the next hop is obtained from thelower-layer (e.g., MAC) header of the message encapsulatingthe announcement. The computation of the required powerlevel relies on the fact that the nodes transmit announcementmessages with maximum power, and the receiving nodescan measure the power level with which they receive thosemessages.

Given the above information in the routing tables, andthe identifier of the destination in the messages that arerouted with the intra-cluster routing protocol, routing isquite straightforward. Each node in the cluster that receivessuch a message forwards it to the next hop associated to themessage’s destination in the routing table of the forwardingnode with the corresponding power level. If no matchingentry is found in the routing table, then the message isdropped. The positions of the destinations stored in therouting table are not used by the intra-cluster routingprotocol; they are recorded to support the interoperation ofthe intercluster and the intra-cluster routing protocol, as wewill explain later.

An important observation is that the aggregator elec-tion procedure described in Section 4.3 ensures that theannouncement message of the future aggregator node of thecurrent epoch is flooded in the entire cluster, and thus, everynode in the cluster creates a routing entry (or updates anexisting one) with the future aggregator as the destination.This means that later in the current epoch, every node inthe cluster can forward messages towards this aggregator.Moreover, routing table entries are kept beyond the durationof the epoch in order to support the routing of queries thatare destined to aggregators of past epochs.

The intercluster routing protocol is used to route mes-sages to and from a distant cluster. These messages can bequeries from and responses to a distant base station, aswell as backup messages destined to distant aggregators thatcontain replicated data. We recommend to use a position-based routing protocol as the intercluster routing protocolfor the following two reasons. First, PANEL already makesthe assumption that the nodes are aware of their positions,and therefore, this position information can naturally bereused for routing purposes. Second, intercluster routingis concerned with messages that need to be routed (i) tothe aggregator of a distant cluster or (ii) to a distant basestation. Regarding case (i), in PANEL, the identifier of theaggregator node is not known explicitly outside the cluster,but, instead, one knows only the reference point to whichthe aggregator happens to be the closest node. Regardingcase (ii), the query messages can contain the geographicalposition of the base station to which the responses shouldbe sent back. Thus, in all cases, messages need to be routedtowards a geographical position, and hence, position-based

routing seems to fit best for intercluster routing in PANEL.Apart from being a position-based routing protocol, we donot restrict the choice for intercluster routing in PANEL.

The intercluster routing protocol is used together withthe intra-cluster routing protocol in the following way. Firstof all note that messages from distant sources are alwaysdestined either to the current aggregator of a cluster or toone of the aggregators in the past. In particular, backupmessages containing replicated data of another cluster aredestined to the current aggregator of the backup cluster,whereas queries from the base station are usually destinedto an aggregator in the past. Note also that, as we mentionedabove, every node has routing table entries for the currentand the past aggregators of its cluster. The interworking ofthe intercluster and intra-cluster routing protocols is basedon these important observations.

Messages from distant sources do not contain theidentifier of the targeted aggregator, but instead they containthe reference point to which the targeted aggregator is theclosest node. When such a message reaches the target cluster,the first node that receives it looks into its routing table,and determines the identifier of the targeted aggregator bysearching for the entry whose destination position is theclosest to the reference point specified in the message. Oncethe identifier of the destination is determined, the intra-cluster routing protocol can be used to deliver the message.Once again, the correctness of this approach is based on thefact that every node in the cluster has an entry in its routingtable for the current and all past aggregators of the cluster,and messages from distant sources are always destined to oneof these aggregators.

5. Simulation Results

In this section, we study the aggregator node electionand cluster formation capabilities of PANEL by means ofsimulations. Moreover, we compare the energy consumptionof a network using PANEL as the aggregator node electionprotocol to the energy consumption of the same networkwhen the aggregator election protocol is HEED [3]. Wehave chosen HEED as the algorithm to compare PANEL toas HEED is a probabilistic approach as well; moreover, itaims at energy efficiency too and it considers intra-clusterrouting already, not just aggregator node election. HEEDoutperforms LEACH [8, 9] in terms of network lifetime andin ratio of energy dissipated for clustering, therefore, it is abetter benchmark than LEACH. Finally, HEED is a widelyknown and well-understood aggregator election approachthat is frequently referenced in the corresponding literature.

For the simulations, we have implemented both PANELand HEED in NesC for TinyOS 2 [36] (i.e., the implemen-tations are ready to run on real sensor nodes), and thesimulations are made with the help of TOSSIM [37], thede-facto TinyOS simulator. The simulations focus on theaggregator node election phase of PANEL, as it is the mainpart of the protocol. As for the energy measurements, webased our solution on PowerTOSSIM 2. PowerTOSSIM 2 isthe power measurement extension for TinyOS 2; however,


it is still experimental and can be downloaded only fromthe official TinyOS 2 contrib repository [38]. As HEEDneeds energy information in runtime for the aggregatornode election, we extracted the corresponding equationsfrom the code of PowerTOSSIM 2 and integrated theminto the code of HEED (and PANEL as well, to maintainequivalence in testing setup). In this way, each sensor nodemeasures its own energy consumption. Note that this smallcomputation consumes very limited energy and hence itdoes not influence the results significantly. We note thatPowerTOSSIM 2 supports only mica2 nodes [39] whichuse the Chipcon CC1000 [40] radio transceiver and theATmega128L [41] microcontroller.

The simulation settings are the following. We assumethat time is divided into epochs, and each epoch consists inan aggregator node election phase and five measuring/datatransmission phases, called rounds. In the aggregator nodeelection phase, the nodes select the cluster head in eachcluster, while in the rounds, the cluster member nodes sendmeasurement information to the cluster head. Both theaggregator node election phase and the rounds have at most10 seconds to finish. We ran the simulations for 100 epochs(i.e., for 6000 seconds). The tested topologies are the same forPANEL and HEED. We considered 40 uniformly randomlyplaced nodes in a square-shaped field consisting in 4 equalshaped clusters, where the node density is controlled throughthe size of the field: the highest density is realized in thesmallest field of 50× 50 m2, while the smallest density isrealized in the largest field of 500 × 500 m2. We simulated20 different topologies for each of the different densities. Incase of HEED, the value of parameter pmin is set to 5 · 10−4,and the cost model is AMRP (see [3]) with the modificationthat it does not depend on the total number of nodes in thecluster, but only on the number of nodes that are in reachabledistance with radio communication. In case of PANEL, δ isset to 0, as this choice corresponds to the worst case (i.e., noborder effect mitigation).

The first question we analyze is the consistence ofaggregator node election in case of PANEL and HEED. Wecall the aggregator election consistent if only one clusterhead (i.e., aggregator node) is elected in each cluster. Thisconsistence is the optimal case; however, due to messagelosses, interferences and possible lack of connectivity, thisideal case rarely happens (see the related discussion inSection 6.2). Nevertheless, the closer the number of clusterheads is to the number of clusters, the more consistent isthe aggregator election. In Figure 4, one can see the averagenumber of cluster heads as a function of the field size (i.e.,node density). The horizontal axis corresponds to the sidelength of the field (as the field is assumed to be square shaped,both sides of the field are of the same length), while thevertical axis corresponds to the average number of clusterheads. The solid curve corresponds to PANEL, while thedashed curve corresponds to HEED. The measurements aremade only on the indicated field sizes (see the ticks on thehorizontal axis), the lines connecting the points are only toemphasize the characteristics of the changes when headingto lower node densities. The presented measurements areaverages of 20 different topologies for each field size, and

Optimum

50045040035030025020015010050

Side length of field (m)

PANELHEED

0

1

2

3

4

5

6

7

8

9

10

Ave

rage

nu

mbe

rof

clu

ster

hea

ds

Figure 4: Average number of cluster heads as a function of the fieldsize.

100 epochs are simulated on each topology. (This way ofvisualization will be the same in the upcoming figures aswell.)

As one can see, PANEL ensures a more consistentaggregator node election than HEED. The line correspondingto the optimum is at y = 4 (as we have 4 clusters), andPANEL approaches it quite well, while in case of HEED, theaverage number of cluster heads goes over 7 for lower nodedensities. We note that for very high node densities (i.e., fieldsizes of 50 × 50 m2 and 100 × 100 m2 ) HEED performsslightly better than PANEL, but for average and low nodedensities, the results of PANEL are much better than theresults of HEED. The reason for this outcome lies in the verynature of the algorithms: PANEL can better propagate thecluster head advertisements since these messages always getrebroadcast as a node receives and accepts them. However, incase of HEED, the advertisements are not rebroadcast (i.e.,only one broadcast is sent by the advertiser node that all theother nodes have to receive), so there is a higher chance fora node to miss such a message and declare itself as a clusterhead, thus raising the average number of cluster heads.

The time spent for electing the cluster head is anotherimportant question. The less time an algorithm needs forcluster head election, the more time it has for other purposes.We define the cluster head election time as the length of thetime interval beginning with the new epoch start, and endingwhen all the nodes have a finalized view about which node isthe cluster head (and which node is the next hop towardsthis cluster head). In Figure 5, one can see the average clusterhead election time (vertical axis) as a function of the fieldsize (horizontal axis). The solid curve corresponds to PANEL,while the dashed curve corresponds to HEED.

The results of Figure 5 are not surprising. Both PANELand HEED have 10 seconds according to the simulation setupfor cluster head election in each epoch, and in HEED, thistime is consumed as the finalization of the links is only


50045040035030025020015010050


PANELHEED

0

2

4

6

8

10

12

14

Com

plet

ion

tim

eof

aggr

egat

orn

ode

elec

tion

(s)

Figure 5: Average cluster head election time as a function of thefield size.

performed after some number of advertisement iterations isalready performed. The required number of such iterationsin HEED is controlled by pmin, however, we have chosenpmin for five times higher than in the examples in [3] inorder to lower the number of required iterations (i.e., from15 to 12). Further lowering the number of iterations couldpossibly distort the cluster head election process in HEEDas its correct operation—especially its energy balancingproperty—relies on the fact that higher remaining energynodes have less (approx. 6) iterations to perform than lowerremaining energy nodes, and thus, the latter nodes are ablejoin to the clusters established by the former nodes. However,in PANEL, the 10 seconds time window for cluster headelection is not fully consumed: PANEL needs less than 6seconds for electing the cluster head (and for establishingthe multi-hop route for each node towards this cluster head).The reason for this is that, in the optimal case, all the nodeshave to send one broadcast message and extract the requiredinformation from the received messages, thus, the clusterhead election can end without further iterations.

Having seen that the number of cluster heads is usuallynot optimal on average (see Figure 4), it is very importantto detail the impact of this result on the number of nodesin the partitioned clusters (i.e., subclusters). As we have40 nodes deployed on the field and 4 clusters, the optimalnumber of nodes in a cluster is 10. However, as the nodesare randomly deployed, it often happens that there are fewerthan 10 nodes in some clusters (and more than 10 in theothers), but this does not influence our average expectation.In Figure 6, one can see the histogram of the number ofnodes in the subclusters as a function of the field size. Thex-axes corresponds to the field size, the y-axes correspondsto the number of nodes in the subcluster, while the z-axescorresponds to the number of occurrences.

Figure 6 clearly shows that while HEED produces asignificant amount of clusters with few nodes (i.e., therearmost bars are high), PANEL usually produces clustersof near optimal number of nodes (i.e., the bars near to the

y = 10 axis are relatively high). This again emphasizes agood feature of PANEL: even if the number of cluster headsgets above the optimal value, the number of nodes in asubcluster remains high. On the opposite, HEED produces ahigh amount of clusters with very few nodes, thus subdividesthe network into small parts that are hard to maintain. Forthe sake of better comparison, we show three sections ofFigure 6 in Figure 7.

In Figure 7, the horizontal axes correspond to thenumber of nodes in the subclusters, while the vertical axescorrespond to the number of occurrences. The solid curvecorresponds to PANEL, while the dashed curve correspondsto HEED, and the three subfigures correspond to differentfield sizes, namely 50 × 50 m2, 250 × 250 m2 and 500 ×500 m2, respectively. The tendency of the behaviour of thetwo algorithms is clear: while HEED behaves very wellin terms of distribution of the number of nodes in thesubclusters for high node densities, it produces many clusterswith few nodes as the node density goes lower. On thecontrary, PANEL behaves quite well in the same comparisoneven for small node densities. The reason for this differencestems from the fact that in HEED, the cost model can retainnodes from joining to a common cluster head when thenode density is small, as further lying cluster heads havehigher costs than closer-lying ones. Another componentof the problem is the high average number of clusterheads (see Figure 4): HEED elects more cluster heads onaverage, which also leads to network partitioning. As theconnectivity becomes weaker (i.e., for lower node densities,larger fields), this behaviour becomes more emphasized,however, in PANEL, the number of clusters with few nodesstays low even for low node densities.

All the same, cluster head election makes no sensewithout an application that employs the newly elected clusterheads. This justifies our simulation scenarios that comprisenot just cluster head election, but data message sendingas well. Instead of measuring just the energy spent forcluster head election, in Figure 8(a), we show the totalaverage energy consumed by PANEL and HEED. Here again,the horizontal axis corresponds to the field size, while thevertical axis corresponds to the average energy consumption.The solid curve corresponds to PANEL, while the dashedcurve corresponds to HEED. The whiskers show the 95%confidence interval of the corresponding values.

As one can see, PANEL consumes less energy in total thanHEED, independently from the node density. Moreover, thewhiskers in Figure 8(a) show that the energy consumptionof PANEL can be forecasted more precisely than the energyconsumption of HEED, as the 95% confidence intervals ofthe energy consumption of PANEL are more narrow thanthat of HEED. This property is confirmed by Figure 8(b),which shows that the standard deviation of the averageenergy consumption is much higher in case of HEED thanin case of PANEL. (The whiskers in Figure 8(b) correspondto the 95% confidence interval of the standard deviation ofthe energy consumption.) We emphasize that the numberof rounds (i.e., the amount of data message sending) highlyinfluences our results: the rounds are where PANEL is moreenergy efficient than HEED, thus, increasing the number of


PANEL

1715

1311

97

53

1

Number of nodes in the subcluster450350

250150

50


0

1000

2000

3000

Nu

mbe

rof

occu

rren

ces

(a)

HEED

1715

1311

97

53

1

Number of nodes in the subcluster450350

250150

50


0

1000

2000

3000

Nu

mbe

rof

occu

rren

ces

(b)

Figure 6: Histogram of the number of nodes in the subclusters.

50 × 50 m2 field

1715131197531

Number of nodes in the subcluster

PANELHEED

0

500

1000

1500

2000

2500

3000

Nu

mbe

rof

occu

rren

ces

(a)

250 × 250 m2 field

1715131197531


PANELHEED

0

500

1000

1500

2000

2500

3000

Nu

mbe

rof

occu

rren

ces

(b)

500 × 500 m2 field

1715131197531


PANELHEED

0

500

1000

1500

2000

2500

3000

Nu

mbe

rof

occu

rren

ces

(c)

Figure 7: Histogram of the number of nodes in the subclusters for field sizes of 50 × 50 m2, 250 × 250 m2 and 500 × 500 m2.

rounds beyond 5 would result in even better performanceof PANEL with respect to HEED. The number of roundsdepends on the actual application, however, we believe thathaving 10, 20, 50 or more rounds can be the general case. Inthese energy simulations we tried to show how PANEL andHEED works in worst case situations, and we conclude thatPANEL is more energy efficient that HEED in our scenarios,independently from the node density.

6. Extensions of PANEL

We complete the description of PANEL in this section bydiscussing three possible extensions related to its operation:the security of PANEL, the problem of disconnected clusters,and the required accuracy of the node’s position information.

6.1. Security. There are several ways how an adversarycan spoil the operation of PANEL. In the following, wedetail these attacks and propose countermeasures againstthem. We assume that the attacker is able to capture and

reverse-engineer one or more nodes, thus, the attacker isable to control these nodes and has knowledge about allthe information stored in these nodes (e.g., secret keys,measurement data, etc.).

The most straightforward type of attack aims at dis-torting the aggregate at the cluster head. To achieve this,an attacker can either (i) modify the environment of theattacked sensor node, or (ii) capture the sensor node andalter the measured values as desired. Altering the measuredparameter of the environment in the first attack means, forexample, lighting a match near to a temperature sensor orflashing with a flashlight near to a photometer sensor; theseoutsider attacks can totally falsify the measurement result ofthe sensor node. Capturing a sensor node in the second caserequires more knowledge from the adversary, but he can gainfull control over the sensor node. Both of these attacks can becircumvented using a statistical sample filtering approach atthe cluster head (like, e.g., [42]). (We note that cryptographycannot help here as these attacks cannot be detected withcryptographic tools.)


50045040035030025020015010050


PANELHEED

20

25

30

35

40

45A

vera

geen

ergy

con

sum

ptio

n(J

)

(a) Total average energy consumption as a function of the field size

50045040035030025020015010050


PANELHEED

0

5

10

15

20

25

Stan

dard

devi

atio

nof

the

ener

gyco

nsu

mpt

ion

(J)

(b) Standard deviation of the total average energy consumption as afunction of the field size

Figure 8: Total energy consumption comparison of PANEL and HEED.

In order to achieve his goal (i.e., to distort the aggregate),the adversary can also (iii) force the captured node to alterthe data field of a forwarded message that comes fromanother node, or (iv) send false measurement data in thename of other nodes to the cluster head. In case of (iii),the captured node must be on the routing path that one ormore of the nodes use to send their measurements to thecluster head. As these messages are not protected, a capturednode that is a forwarder can modify the content of thesemessages. In case of (iv), the captured node tries to confusethe cluster head by sending messages in the name of othernodes; when the cluster head later receives the valid messagesfrom the well-behaving nodes it cannot determine whichof the received messages are valid. While both of the latterattacks can be handled more or less with the previouslymentioned technique, a more appropriate tool against theseattacks is cryptographic integrity protection (in case of (iii)),or authentication (in case of (iv)). For these, the nodes need,for example, a public-private key pair and they have to signtheir messages using the private key, moreover, they have toattach their public key to the message after it was signed.(We note that assuming public-key cryptography in sensornetworks is not far fetched according to [43].) This, on onehand, prevents a captured node to alter the measurementdata in the messages as the captured node cannot regeneratethe signature on the message after the modification. On theother hand, a captured node cannot send messages in thename of other nodes as, again, the captured node cannotgenerate a valid signature, because it does not know theprivate key of other nodes. However, it could be possible thatan attacker invents public-private key pairs and generatescryptographically sound messages. We anticipate that thisattack is handled by using the extensions proposed later inthis section (i.e., identifier signing by the base station).

Signing and thus authenticating the messages also helpsin the case when the attacker aims at interfering with thecluster head election process. In this attack, the attacker triesto send an advertisement message in the name of a node thatwould not become aggregator based on the position of thereference point. The nodes that hear this fake advertisementmessage would rebroadcast it until a node detects that itsown position is closer to the reference point than the positionin the advertisement. After this, the latter node wouldrebroadcast its own advertisement and the whole clusterwould know which node is the real cluster head. However,the numerous message broadcasts consumes a high amountof energy, and thus, this attack should not be underestimated.Signing not just the data messages but the advertisementmessages as well protects against this attack as, in this case,an attacker cannot send a valid advertisement message in thename of other nodes as it does not know the other nodes’private key. A node that receives an advertisement messagethat is not correctly signed can easily drop it and further waitfor a valid advertisement.

A typical attack against aggregator node election pro-tocols is to manipulate the execution in such a way thatthe nodes controlled by the adversary become aggregatorsmore frequently than they should. In this way, the adversarycan collect information from the network easier, as nodessend their sensor readings to the aggregators. In PANEL,such an attack can be perpetrated using fake information inthe announcement message in the aggregator node electionphase by a captured node that uses (i) its correct identifier,but fake position information, or (ii) a fake identifier alongwith fake position information. Moreover, (iii) the adversarycan deploy new nodes at desired positions. In the firstcase, the captured node only alters its position informationand reports its correct identifier very close to the current


reference point in each epoch. In the second case, thecaptured node invents a new identifier along with a positionvery close to the current reference point and reports this pairin the announcement. In the third case, however, the attackerdoes not have to capture a node, he only has to deploy anew one close to the reference point (the attacker can dothis as he can calculate the position of the reference pointin advance).

PANEL can be easily extended with security measures toprevent even these misdeeds. First of all, the base station canuse public-key cryptography and sign the nodes’ identifierwith its private key, and load the corresponding public key onthe sensors before deployment. Using this signed identifier,a node that receives an announcement message can checkwhether it contains a valid identifier or not using the publickey of the base station, but no one except the base stationis able to generate new identifiers. With this technique,one can detect the cases (ii) and (iii), therefore, the onlyremaining way to attack the aggregator node election phaseis case (i). One can thwart attack (i) by allowing the nodesto keep in their routing tables the position information ofthe other nodes from which they have already heard anannouncement. This information can be kept in the routingtables even beyond the duration of an epoch. Therefore, thenodes can detect if a captured or corrupted node tries toreport itself at different positions in different epochs. If theabove attack is detected, the detector node can flood an alarmmessage in the cluster including the cheating node’s identifierand the proof for the cheating, that is, the two advertisementmessages with the same identifier and different positioninformation, both signed by the cheating node. In case ofreception of such an alarm message the nodes can checkthe proof of the cheating and exclude the related identifierfrom further cooperation. We note that it is important thatall the nodes exclude the cheating node in order to maintaina consistent view of the cluster. Without this requirement,some nodes could elect the cheating node later as aggregator,while some nodes could not, and this could result in clusterfractioning.

Another straightforward attack against the data collec-tion part of PANEL is the selective message dropping attack.A captured forwarder node can selectively drop the messagesthat it receives instead of forwarding them. With this attack,however, the attacker can only slightly mislead the aggregate.For example, if the aggregator function is the average, themedian, or the min/max, then the gain of the attacker is thatthe final aggregate is based on fewer measurements than inthe unattacked case, which usually does not influence theresult significantly (assuming that the number of droppedmessages is not high). Moreover, each dropped measurementalters the aggregation result, but in case of the average andthe median, the attacker does not know in advance whethera dropped measurement results in increasing or in decreasingthe aggregate, and therefore, the strength of this kind ofattack is limited as well. We believe that the very natureof sensor networks, namely that they are distributed andcomprise of a high number of nodes, is enough to mitigatethis type of attack.

In summary, to enhance the security of PANEL, wepropose to use (i) node identifiers that are signed by thebase station in order to prevent the acceptance of forgedidentifiers, (ii) digital signatures in order to authenticatethe senders and protect the integrity of the messages, (iii)the technique of remembering the nodes’ identifier andposition in order to prevent the captured nodes fromvirtually changing their position, and (iv) a sample filteringtechniques like those in [42] in order to mitigate attacksaiming at injecting false measurements.

6.2. Disconnected Clusters. A crucial assumption of PANEL isthat the nodes within a cluster form a connected subnetwork.If this assumption is not satisfied, and the subnetwork withina cluster is partitioned, then some nodes will not hear theannouncement of the node closest to the reference point, andthey will elect another node as aggregator. More specifically,in this case, as many aggregators are elected in the cluster asmany partitions the subnetwork has.

Connectivity within every cluster can be ensured byappropriately choosing the cluster size given the node densityof the network. The smaller the clusters are, the more likelyis that the subnetworks of the clusters will be connectedgiven a particular node cardinality. We observe, however, thatthe node density may decrease during the lifetime of thenetwork because some nodes may exhaust their batteries anddie. One solution would be to introduce new nodes in thenetwork in order to keep the node density constant. Anothersolution is to extend the area in which an announcementis flooded beyond the borders of the corresponding cluster.For instance, the announcement can also be flooded in theneighboring clusters. This would increase the probabilitythat each node in the corresponding cluster receives theannouncement even if the subnetwork within that clusteris partitioned, because those partitions may be connectedthrough the neighboring clusters. The downside of thisapproach is the increased energy consumption of the nodes.

This latter approach is acceptable, if the nodes inthe neighboring clusters are ready to route even the datamessages of the disconnected clusters towards the affectedcluster head. However, assuming that the queries from thebase station are usually interested in aggregates of the past,the following solution can be more energy efficient. Duringthe aggregator node election phase, we do extend the areain which an announcement is flooded, and we tolerate thatmultiple cluster heads are elected. These cluster heads collectthe measurements of the sensors, and send the aggregatedmeasurements to a backup cluster head as usual, alsoincluding their position information into the message. Thebackup cluster head can detect that multiple cluster headswere elected in a cluster when it receives multiple backupsoriginated from the same cluster. This, on the one hand, canbe reported to the base station by the backup cluster head,and, on the other hand, the subaggregates can be aggregatedin one message by the backup cluster head again, and sentback to the originator cluster heads using solely position-based routing in order to recover the consistency inside thecluster.


This latter solution is efficient in terms of communi-cation overhead, but sometimes it is not applicable. Forexample, in case of the average, it works fine, as the average ofthe averages of two subsamples is equal to the average of thesample consisting in the two subsamples. However, in case ofthe median, it does not work. Therefore, for such aggregationfunctions that need the whole sample to produce the correctoutput, we propose to use the following method. At first, weagain require the aggregator nodes to include their positioninformation in the backup messages. Then, as the backupcluster head detects the malfunctioning as already detailed,it chooses a “final aggregator” (i.e., a node among the clusterheads of the partitioned cluster that will finally perform theaggregation), and it informs the originator nodes about thedisconnectivity and about the identity of the final aggregator.The packet sent to the originator nodes has to contain theidentifier and position information of the final aggregator,while the packet sent to the final aggregator has to containthe identifier and position information of all the originators.All of these packages have to be sent using solely position-based routing. When the originator nodes receive such apacket, they send all of the collected measurements (i.e., notjust the aggregates, but all of the measurements of all of thenodes in the subcluster in the epoch) to the final aggregatorusing position-based routing, which can then produce aproper aggregate based on the received sample. Finally, thefinal aggregator sends back the produced aggregate to theoriginator nodes using solely position-based routing. Atthe reception of this latter packet, the originators replacetheir previous aggregate with the received one. With thistechnique, even the partitioned subnetworks will have aconsistent picture of their cluster, independently from theapplied aggregator function. Moreover, queries will receivecorrect answers independently from the queried cluster head.

6.3. Virtual Coordinates. The operation of PANEL relies onthe assumption that the nodes are aware of their geographicpositions. This means that some positioning mechanismneeds to be implemented in the network in order tosupport PANEL. Note, however, that the aggregator nodeelection procedure itself does not require accurate positioninformation; indeed, the same procedure would work alongwith the intra-cluster routing with virtual positions inventedby the nodes themselves once and forever at the beginning ofthe operation of the network.

After all, interpreting the output of the pseudorandomfunction H as the position of a reference point is also anarbitrary choice; it could also be mapped to the identifierspace, and the protocol could elect the node whose identifieris the closest to the “reference identifier” as the aggregator forthe current epoch.

Besides the aggregator node election procedure, anothercomponent of PANEL, the intercluster routing protocol alsouses the position information of the nodes. Therefore, therequired accuracy of the position information is determinedby the position-based intercluster routing protocol used inPANEL. Note, however, that one may consider replacingthe position-based intercluster routing protocol with a

nonposition-based protocol in order to further decrease thedependency of PANEL on the accuracy of the positioningmechanism.

7. Conclusion

We described PANEL: a position-based aggregator nodeelection protocol for wireless sensor networks. The noveltyof PANEL with respect to other aggregator node electionprotocols is that it supports asynchronous sensor networkapplications where the sensor readings are fetched by the basestations after some delay. In particular, the motivation for thedesign of PANEL was to support reliable and persistent datastorage applications, such as TinyPEDS.

PANEL uses the position information of the nodes todetermine which of them should become aggregator. PANELensures load balancing, meaning that each node has nearlythe same chance to become aggregator, and it supportsintra and intercluster routing allowing sensor-to-aggregator,aggregator-to-aggregator, base station-to-aggregator, andaggregator-to-base station communications.

Besides describing the operation of PANEL, we also eval-uated its efficiency by means of simulations. In particular, wecompared the cluster formation capabilities and the energyconsumption of PANEL to those of HEED: an aggregatornode election protocol well-known from the literature. Ourresults show that PANEL behaves better than HEED in bothcomparisons.

Acknowledgments

The work described in this paper is based on results of the ISTFP6 STREP UbiSec&Sens (http://www.ist-ubisecsens.org/).UbiSec&Sens receives research funding from the EuropeanCommunity’s Sixth Framework Programme. Apart fromthis, the European Commission has no responsibility for thecontent of this paper. The information in this document isprovided as is and no guarantee or warranty is given thatthe information is fit for any particular purpose. The userthereof uses the information at its sole risk and liability.The presented work has also been partially supported bythe Hungarian Scientific Research Fund (contract numberT046664). The first author has been partially supportedby the Hungarian Academy of Sciences through the BolyaiResearch Fellowship. The second author has been partiallysupported by Ericsson through the HSN Lab. Last, but notleast, the authors are thankful for Gergely Acs and AttilaFaddi for their help and support on this work. This work wasdone while the second author was with BME.

References

[1] L. Buttyan and P. Schaffer, “PANEL: position-based aggregatornode election in wireless sensor networks,” in Proceedings ofthe 4th IEEE Internatonal Conference on Mobile Adhoc andSensor Systems (MASS ’07), pp. 1–9, Pisa, Italy, October 2007.


[2] J. Girao, D. Westhoff, E. Mykletun, and T. Araki, “TinyPEDS:tiny persistent encrypted data storage in asynchronous wire-less sensor networks,” Ad Hoc Networks, vol. 5, no. 7, pp. 1073–1089, 2007.

[3] O. Younis and S. Fahmy, “Distributed clustering in ad-hocsensor networks: a hybrid, energy-efficient approach,” inProceedings of the 23rd Annual Joint Conference of the IEEEComputer and Communications Societies (INFOCOM ’04), pp.629–640, Hong Kong, March 2004.

[4] O. Younis, M. Krunz, and S. Ramasubramanian, “Nodeclustering in wireless sensor networks: recent developmentsand deployment challenges,” IEEE Network, vol. 20, no. 3, pp.20–25, 2006.

[5] R. Rajagopalan and P. K. Varshney, “Data-aggregation tech-niques in sensor networks: a survey,” IEEE CommunicationsSurveys & Tutorials, vol. 8, no. 4, pp. 48–63, 2006.

[6] V. Mhatre and C. Rosenberg, “Homogeneous vs heteroge-neous clustered sensor networks: a comparative study,” in Pro-ceedings of IEEE International Conference on Communications(ICC ’04), pp. 3646–3651, Paris, France, June 2004.

[7] V. Mhatre and C. Rosenberg, “Design guidelines for wirelesssensor networks: communication, clustering and aggrega-tion,” Ad Hoc Networks, vol. 2, no. 1, pp. 45–63, 2004.

[8] W. R. Heinzelman, A. Chandrakasan, and H. Balakrish-nan, “Energy-efficient communication protocol for wirelessmicrosensor networks,” in Proceedings of the 33rd AnnualHawaii International Conference on System Siences (HICSS’00), January 2000.

[9] W. B. Heinzelman, A. P. Chandrakasan, and H. Balakrishnan,“An application-specific protocol architecture for wirelessmicrosensor networks,” IEEE Transactions on Wireless Com-munications, vol. 1, no. 4, pp. 660–670, 2002.

[10] S. Lindsey and C. S. Raghavendra, “PEGASIS: power-efficientgathering in sensor information systems,” in Proceedings of theIEEE Aerospace Conference, vol. 3, pp. 1125–1130, 2002.

[11] S. Lindsey, C. Raghavendra, and K. M. Sivalingam, “Data gath-ering algorithms in sensor networks using energy metrics,”IEEE Transactions on Parallel and Distributed Systems, vol. 13,no. 9, pp. 924–935, 2002.

[12] S. Bandyopadhyay and E. J. Coyle, “An energy efficient hier-archical clustering algorithm for wireless sensor networks,” inProceedings of the 22nd Annual Joint Conference on the IEEEComputer and Communications Societies (INFOCOM ’03), pp.1713–1723, San Francisco, Calif, USA, April 2003.

[13] M. Ye, C. F. Li, G. H. Chen, and J. Wu, “EECS: an energyefficient clustering scheme in wireless sensor networks,”in Proceedings of the 24th IEEE International PerformanceComputing and Communications Conference (IPCCC ’05), pp.535–540, Phoenix, Ariz, USA, April 2005.

[14] S. Soro and W. B. Heinzelman, “Prolonging the lifetime ofwireless sensor networks via unequal clustering,” in Proceed-ings of the 19th IEEE International Parallel and DistributedProcessing Symposium (IPDPS ’05), pp. 1–8, Denver, Colo,USA, April 2005.

[15] C. Li, M. Ye, G. Chen, and J. Wu, “An energy-efficientunequal clustering mechanism for wireless sensor networks,”in Proceedings of the 2nd IEEE International Conference onMobile Ad-Hoc and Sensor Systems (MASS ’05), pp. 597–604,Washington, DC, USA, November 2005.

[16] G. Gupta, “Load-balanced clustering of wireless sensornetworks,” in Proceedings of IEEE International Conferenceon Communications (ICC ’03), pp. 1848–1852, Anchorage,Alaska, USA, May 2003.

[17] G. Gupta and M. Younis, “Performance evaluation of load-balanced clustering in wireless sensor networks,” in Proceed-ings of the 10th International Conference on Telecommunica-tions (ICT ’03), 2003.

[18] M. Younis, M. Youssef, and K. Arisha, “Energy-aware manage-ment for cluster-based sensor networks,” Computer Networks,vol. 43, no. 5, pp. 649–668, 2003.

[19] K. Dasgupta, K. Kalpakis, and P. Namjoshi, “An efficientclustering-based heuristic for data gathering and aggregationin sensor networks,” in Proceedings of the IEEE WirelessCommunications and Networking Conference (WCNC ’03), vol.3, pp. 1525–3511, New Orleans, La, USA, March 2003.

[20] K. Kalpakis, K. Dasgupta, and P. Namjosh, “Efficient algo-rithms for maximum lifetime data gathering and aggregationin wireless sensor networks,” Computer Networks, vol. 42, no.6, pp. 697–716, 2003.

[21] S. Ghiasi, A. Srivastava, X. Yang, and M. Sarrafzadeh, “Optimalenergy aware clustering in sensor networks,” Sensors, vol. 2, no.7, pp. 258–269, 2002.

[22] I. Gupta, D. Riordan, and S. Sampalli, “Cluster-head electionusing fuzzy logic for wireless sensor networks,” in Proceedingsof the 3rd Annual Communication Networks and ServicesResearch Conference, pp. 255–260, Halifa, Canada, May 2005.

[23] P. Popovski, F. H. P. Fitzek, H. Yomo, T. K. Madsen, and R.Prasad, “MAC-layer approach for cluster-based aggregation insensor networks,” in Proceedings of the International Workshopon Wireless Ad-Hoc Networks (IWWAN ’04), pp. 89–93, Oulu,Finland, June 2004.

[24] M. Demirbas, A. Arora, and V. Mittal, “FLOC: a fast localclustering service for wireless sensor networks,” in Proceedingsof Workshop on Dependability Issues in Wireless Ad HocNetworks and Sensor Networks (DIWANS ’04), 2004.

[25] F. Kuhn, T. Moscibroda, and R. Wattenhofer, “Initializingnewly deployed ad hoc and sensor networks,” in Proceedingsof the Annual International Conference on Mobile Computingand Networking (MOBICOM ’04), pp. 260–274, Philadelphia,Pa, USA, 2004.

[26] S. Banerjee and S. Khuller, “A clustering scheme for hierar-chical conrol in multi-hop wireless networks,” in Proceedingsof the 20th Annual Joint Conference of the IEEE Computerand Communications Societies (INFOCOM ’01), Anchorage,Alaska, USA, April 2001.

[27] H. Chan and A. Perrig, “ACE: an emergent algorithm forhighly uniform cluster formation,” in Proceedings of the 1stEuropean Workshop on Sensor Networks, pp. 154–171, Berlin,Germany, January 2004.

[28] M. Sirivianos, D. Westhoff, F. Armknecht, and J. Girao, “Non-manipulable aggregator node election protocols for wirelesssensor networks,” in Proceedings of the 5th InternationalSymposium on Modeling and Optimization in Mobile, AdHoc, and Wireless Networks (WiOpt ’07), pp. 1–10, Limassol,Cyprus, April 2007.

[29] D. Liu, “Resilient cluster formation for sensor networks,” inProceedings of the 27th International Conference on DistributedComputing Systems (ICDCS ’07), p. 40, Toronto, Canada, June2007.

[30] J. N. Al-Karaki, R. Ul-Mustafa, and A. E. Kamal, “Dataaggregation in wireless sensor networks—exact and approx-imate algorithms,” in Proceedings of the Workshop on HighPerfomance Switching and Routing (HPSR ’04), pp. 241–245,Phoenix, Ariz, USA, April 2004.

[31] M. Maroti, B. Kusy, G. Balogh, et al., “Radio interferometricgeolocation,” in Proceedings of the ACM Workshop on Security


of Ad Hoc and Sensor Networks (SENSYS ’05), pp. 1–12, SanDiego, Calif, USA, November 2005.

[32] S. Capkun, M. Hamdi, and J.-P. Hubaux, “GPS-free position-ing in mobile ad hoc networks,” Cluster Computing, vol. 5, no.2, pp. 157–167, 2002.

[33] S. Ganeriwal, S. Capkun, C.-C. Han, and M. B. Srivastava,“Secure time synchronization service for sensor networks,” inProceedings of the ACM Workshop on Wireless Security (WiSe’05), pp. 97–106, Cologne, Germany, September 2005.

[34] K. Sun, P. Ning, C. Wang, A. Liu, and Y. Zhou, “TinySeRSync:secure and resilient time synchronization in wireless sensornetworks,” in Proceedings of the 13th ACM Conference onComputer and Communications Security (CCS ’06), pp. 264–277, Alexandria, Va, USA, November 2006.

[35] B. Karp and H. T. Kung, “GPSR: greedy perimeter statelessrouting for wireless networks,” in Proceedings of the 6th AnnualInternational Conference on Mobile Computing and Networking(MOBICOM ’00), pp. 243–254, New York, NY, USA, 2000.

[36] “TinyOS 2,” http://www.tinyos.net/tinyos-2.x/doc/.[37] P. Levis, N. Lee, M. Welsh, and D. Culler, “TOSSIM: accurate

and scalable simulation of entire TinyOS applications,” inProceedings of the 1st International Conference on EmbeddedNetworked Sensor Systems (SenSys ’03), pp. 126–137, LosAngeles, Calif, USA, November 2003.

[38] TinyOS Alliance, “PowerTOSSIM for TinyOS 2.x,” http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x-contrib/cedt/

[39] XBow Corporation, “Mica2 Datasheet,”https://www.eol.ucar.edu/rtf/facilities/isa/internal/CrossBow/DataSheets/mica2.pdf.

[40] Chipcon Corporation, “CC1000 Datasheet,”http://www.chipcon.com/files/CC1000 Data Sheet 2 2.pdf.

[41] ATMEL Corporation, “ATmega128L Datasheet,”http://www.datasheetcatalog.com/datasheets pdf/A/T/M/E/ATMEGA128L.shtml.

[42] L. Buttyan, P. Schaffer, and I. Vajda, “RANBAR: RANSAC-based resilient aggregation in sensor networks,” in Proceedingsof the 4th ACM Workshop on Security of Ad Hoc andSensor Networks (SASN ’06), pp. 83–90, Alexandria, Va, USA,October 2006.

[43] K. Piotrowski, P. Langendoerfer, and S. Peter, “How publickey cryptography influences wireless sensor node lifetime,” inProceedings of the 4th ACM Workshop on Security of Ad Hocand Sensor Networks (SASN ’06), pp. 169–176, Alexandria, Va,USA, October 2006.

position-basedaggregatornodeelectionin …buttyan/publications/buttyans10ijdsn.pdf · wireless...

Documents