PA

JU

a

ARRAA

KWQPP

1

nwfmtof

sadnrsaaataa

t

0h

The Journal of Systems and Software 86 (2013) 1650– 1662

Contents lists available at SciVerse ScienceDirect

The Journal of Systems and Software

j ourna l ho me page: www.elsev ier .com/ locate / j ss

S-QUASAR: A publish/subscribe QoS aware middleware for Wireless Sensor andctor Networks

aime Chen ∗, Manuel Díaz, Bartolomé Rubio, José M. Troyaniversity of Málaga, Dpto. Lenguajes y ciencias de la Computación, Calle de Bulevard Louis Pasteur, s/n, 29071 Málaga, Spain

r t i c l e i n f o

rticle history:eceived 8 October 2012eceived in revised form 13 February 2013ccepted 13 February 2013vailable online 26 February 2013

eywords:

a b s t r a c t

It has been more than 30 years since the first research into Wireless Sensor and Actor Networks appeared.However, WSANs are still not a ubiquitous technology due to several factors which include a lack of Qual-ity of Service (QoS) support or the absence of high level programming models. New applications withheterogeneous QoS requirements where WSANs can be successfully applied, such as Critical Infrastruc-ture Protection (CIP), have been recognized.

PS-QUASAR, a middleware for WSANs that deals with these two issues, offers a high level simple

ireless Sensor and Actor NetworksoS-aware middlewareublish/subscriberogramming Abstraction

programming model based on the publish/subscribe paradigm. In this model all nodes in the networkare potential publishers of each of the topics. PS-QUASAR also handles QoS (reliability, deadline, priority)and supports a many-to-many exchange of messages between nodes in a fully distributed way by meansof multicasting techniques. Performance evaluation via simulation using the Contiki operating systemshows that the protocol can handle multiple publishers and subscribers at the same time whilst dealing

with QoS requirements.

. Introduction

Wireless Sensor and Actor Networks (WSANs) have been recog-ized as one of the most promising technologies to date and onehich will have an impact on how we interact and get information

rom the environment. WSANs are composed of small devices withultiple on-board sensors which can communicate with each other

hrough wireless links (Akyildiz et al., 2002). By taking advantagef the large number of nodes which a WSAN is composed of, a highault tolerance can be achieved.

There are a great number of applications where wireless sen-or networks have been successfully applied (Gaura et al., 2010)nd their advantages have been long acknowledged. However andespite the intense research carried out in this area, WSANs haveot yet become a pervasive technology as predicted. The main bar-iers, researchers and industry have encountered are the lack of QoSupport (mainly reliability), the lack of widely used programmingbstractions that simplify the task of programming applicationsnd also the lack of standards. Regarding the first issue, andlthough there are actually protocols that allow information to be

ransmitted in a reliable way to a neighbor, more elaborate depend-ble routing protocols are needed so that the network dynamicallydapts to changing environments and possible failures. Regarding

∗ Corresponding author. Tel.: +34 952 13 2865; fax: +34 952 13 1397.E-mail addresses: hfc@lcc.uma.es (J. Chen), tolo@lcc.uma.es (B. Rubio),

roya@lcc.uma.es (J.M. Troya).

164-1212/$ – see front matter © 2013 Elsevier Inc. All rights reserved.ttp://dx.doi.org/10.1016/j.jss.2013.02.028

© 2013 Elsevier Inc. All rights reserved.

the second one, a huge number of different high level abstractionshave been proposed. However, most of the applications are still pro-grammed at a low level of abstraction and tailored for each specificapplication. Finally there are currently widely used standards forWSANs, mainly at the data link layer such as IEEE 802.15.4. How-ever, there is still no agreement on what standard to use in upperlayers.

WSANs are usually deployed in changing and adverse environ-ments and therefore routing protocols should be able to handlenew node additions or node failures. This means that the commu-nication scheme should not only rely on nodes’ physical addresses,because available nodes’ addresses can change overtime if newnodes are added or existing ones fail.

The publish/subscribe model (Eugster et al., 2003) is a widelyknown communication paradigm for asynchronous communica-tion between nodes in a distributed system. Two main entities existin this approach: (1) publishers that produce data on a certain topicand (2) subscribers that consume data of a specific topic. The goalof the publish/subscribe system is to transparently send the datafrom publishers to subscribers that have declared their interest inthe same topic. In this paradigm publishers and subscribers do notknow each other. The system is in charge of automatically deliver-ing data produced by publishers to the corresponding subscribers.

On the one hand, we believe that the publish/subscribe model

is a feasible programming abstraction for wireless sensor networksand one that matches the reporting paradigm that a WSAN usu-ally has, that is, a large number of nodes report their readings toa small number of data consumers. For the developers, it greatly

ms an

sapeetr

tprnSaitafiimSdp

adWTtiPrat

ptpmgaf

rtmec

2

dpobaa

bpptot

J. Chen et al. / The Journal of Syste

implifies the task of programming since they do not have to worrybout low level communication primitives and can focus on therogram logic rather than on how to distribute the data it gen-rates. On the other hand we acknowledge that QoS support isssential for most modern applications, in particular for reliability,herefore the routing protocol must be able to handle different QoSequirements.

Let us take as an application scenario a wireless sensor networko monitor an electrical substation. The sensors are attached toower transformers and power lines to measure temperature, cur-ent and component status. Readings outside of normal range areotified as warnings and alarms and need to be reliably sent to aCADA with high priority. In addition, several movement detectorsre deployed in the electrical substation to detect unauthorizedntrusions. Finally, a couple of cameras and luminous and acous-ic alarms have been deployed in the scenario. These cameras andlarms will be activated when an alarm notification, warning noti-cation or intrusion are detected. The wireless sensor network

n this scenario needs to cope with sensors and actors, priorityessages, reliable transmission and multiple subscribers (alarms,

CADA and cameras). This application scenario is based on a realemonstrator presented in the WSAN4CIP project in which wearticipated.

Taking these two requirements and the application scenarios the motivation, this paper proposes a publish/subscribe mid-leware based on a simple publish/subscribe model suitable forSANs called PS-QUASAR that is able to provide QoS support.

he routing protocol that comes with PS-QUASAR (referred to ashe PS-QUASAR routing protocol in the remainder of the paper)s fully distributed and does not assume any reporting pattern.S-QUASAR uses a publish/subscribe directed acyclic graph basedouting protocol that supports a many-to-many communicationnd can handle priority, deadline and reliability requirements inhe communication between nodes.

There are publish/subscribe protocols which have already beenroposed in the context of WSANs and these are covered in Sec-ion 2 illustrating their differences with the one presented in thisaper. The main contributions of the article are as follows: (1) aiddleware that supports QoS and which provides a simple pro-

ramming model based on the publish/subscribe paradigm and (2) routing protocol supporting a publish/subscribe paradigm in aully distributed way, based on directed acyclic graphs.

The rest of the paper is structured as follows. Section 2 presentselated work. Section 3 describes the problem formulation andhe scenario assumptions. The PS-QUASAR middleware and imple-

entation notes are described in Section 4. The performance andvaluation tests are presented and analyzed in Section 5. Finallyonclusions are presented in Section 6.

. Related work

Routing protocols for WSANs need to be light-weight andecentralized. That means that, ideally, they should only routeackets based on the information about their neighbors and notn the whole network. Besides, as broadcast communications inig networks introduce high latency, on-demand routing protocolsre not usually suitable for WSANs, particularly in delay-sensitivepplications.

A large number of routing protocols for WSANs have alreadyeing presented and many routing protocols have covered the mainroposals. However, routing protocols for WSANs supporting a

ublish/subscribe paradigm have not been extensively studied. Ashe routing protocol that the PS-QUASAR middleware has is onef them, the related work focuses on already existing routing pro-ocols and middlewares that allow a publish/subscribe paradigm

d Software 86 (2013) 1650– 1662 1651

to run on top of them. Surveys covering other kinds of protocolscan be found in Jiang and Manivannan (2004), García Villalba et al.(2009), Al-karaki and Kamal (2004), and Akkaya and Younis (2005).The main difference between publish/subscribe routing protocolsand other routing protocols is that they have to somehow emu-late the global data space that holds the information exchangedbetween nodes following a many-to-many pattern. Furthermore,QoS in WSANs is covered in Chen et al. (2011), Xia (2008), and Chenand Varshney (2004).

A generic overview of publish/subscribe protocols is presentedin Eugster et al. (2003) where the different publish/subscribe varia-tions are classified and discussed. Tran and Truong (2011) deal withthe use of the publish/subscribe in sensor networks. The existingchallenges and possible techniques to overcome them are pre-sented. In Albano and Chessa (2009) the different techniques thatcan be used to implement a publish/subscribe protocol in sensornetworks are studied together with the possible primitives in thesekinds of systems.

Single-subscriber and multiple-subscriber protocols are cov-ered in Sections 2.1 and 2.2 respectively. A summary of allpresented protocols and middlewares, with the one presented inthis paper is shown in Table 1. The main features of each of the pro-posals covered in the related work are summarized in this table. Thefeatures of the proposed middleware, PS-QUASAR, are also shownin this table.

2.1. Single-subscriber routing protocols

2.1.1. Proposals for WSNsMires (Souto et al., 2005) is a middleware for WSANs that uses

a publish/subscribe paradigm. Communication between publish-ers and subscribers takes the following steps. First, all nodes inthe network must send the information to advertize their availabletopics. Once this information has been received by the subscribernode, it then selects the topics it wants to subscribe to by sending amessage to the corresponding nodes. Finally, sensor nodes receiv-ing this message can start sending information about the selectedtopics. The multihop routing protocol used to exchange messagesis not covered in the paper. Also, Mires does not directly supportQoS. In PS-QUASAR the implementation of the paradigm is substan-tially different. All nodes in the network have access to the existingsubscribers and can send information to them without a two-stepprotocol.

A simple publish/subscribe system is presented in Wireless sen-sor networks based on publish/subscribe messaging paradigms(Cam et al., 2011). The protocol only allows many-to-one communi-cation which means that there is only a subscriber (the sink node).The protocol is initiated by the subscriber which broadcasts thetopics it is interested in. Nodes receiving the packet will publishinformation back to the sink. This means that communication isalways initiated by the subscriber node and requires two commu-nication phases (one in each direction) to work. This protocol doesnot handle QoS and does not cope with fault tolerance.

In Boukerche et al. (2006) two routing protocols based on thepublish/subscribe paradigm are presented. The first one uses theBellman–Ford algorithm to locate the sink node which is the onlysubscriber. Once a routing tree is formed subscriptions are sentusing flooding. Information is sent to the subscriber using the short-est paths to the root of the tree. A recovery protocol that selects anew path to the subscriber if a failure in a node in the current path isselected is also presented. This protocol relies on ACKs to detect thefailures. Finally, a clustering mechanism is proposed where nodes

with the highest remaining energy aggregate information from theneighbors and relay it to the subscriber. This protocol always usesACKs to send information from the node to the subscriber whichcan be energy consuming.

1652 J. Chen et al. / The Journal of Systems and Software 86 (2013) 1650– 1662

Table 1Publish/subscribe routing protocol summary.

Name Multiple subscribers Support actors Scheme QoS Fully distributed

Mires No No Topic-based No YesWireless sensor networks based on

publish/subscribe messaging paradigmsNo No Unknown No Yes

Fault-tolerant wsn routing protocol for thesupervision of context-aware physicalenvironments

No No Unknown Reliability Yes

MQTT-S No (only outside the wsan) Yes Content-based Priority, deadline, reliability YesQuad-PubSub Yes No Unknown No UnknownTinyMQ Yes No Content-based No YesA Publish–Subscribe Middleware for Real-Time

Wireless Sensor NetworksYes No Unknown Priority Yes

TinyDDS Yes No Content-based Priority, deadline, reliability YesYes

YesYes

2

ontebdatbc

2

2

QtosElcea

lubwiboh

nueuttncfw

i

Clustered Publish/Subscribe in WSANs Yes

A policy-based publish/subscribe middleware YesPS-QUASAR Yes

.1.2. Proposals for WSANsMQTT-S (Hunkeler et al., 2008) adapts the MQTT protocol (based

n the publish/subscribe paradigm) to sensor networks. Sensorodes are publishers whereas the external applications receivinghe data are subscribers. The protocols need the assistance of anxternal broker which controls how to match the data generatedy the network with the corresponding applications. MQTT definesifferent levels of QoS that provide different reliability schemes andlso supports the use of actors. MQTT does not specify any routingechniques; it assumes a TCP/IP like protocol. The main differenceetween MQTT and PS-QUASAR is the use of an external broker thatontrols publisher/subscriber matching.

.2. Multiple-subscriber routing protocols

.2.1. Proposals for WSNsA publish/subscribe protocol for location-aware WSANs called

uad-PubSub is presented in Taherian and Bacon (2007). The pro-ocol assumes that all nodes are aware of their position and thatf their neighbors. The network area is divided into geographicalcopes controlled by special nodes called “Event brokers” (EBs).ach event broker offers access to information generated by pub-ishers in its area. After that, subscribers are linked to those EBs thatan serve them with their set of interests. The paper does not how-ver clarify how to implement the different steps of the protocol in

real device. This protocol does not handle QoS.TinyMQ (Shi and Deng, 2011) presents a content-based pub-

ish/subscribe middleware for wireless sensor networks. TinyMQses an overlay network together with a naming scheme based oninary strings to connect publishers with subscribers. First the net-ork is partitioned into several tree-based clusters and each node

s given a binary address by means of a maintenance protocol. Thisinary address is such that it allows routing to be carried out basedn the addresses and distances to root nodes. TinyMQ does notandle QoS.

A publish/subscribe middleware for real-time wireless sensoretworks is presented in Sharifi et al. (2006). The protocol makesse of broadcast communications to notify of the different inter-sts and also to deliver the information. QoS support is achieved bysing two packet queues: one for information requiring QoS andhe other one for normal packets. Packets are processed accordingo their priority value. The protocol has been tested in a 40-nodeetwork with 2 subscribers and 4 publishers. The paper neitherlarifies how paths to relay the information are obtained nor how

ailures are dealt with. PS-QUASAR uses a similar approach to copeith QoS requirements.

DDS or Data distribution service for real-time systems is a spec-fication developed by the OMG consortium of a middleware for

Unknown No YesTopic-based Reliability YesTopic-based Priority, deadline, reliability Yes

distributed systems based on the publish/subscribe paradigm. DDSallows users to specify Quality of Service (QoS) parameters thatwill apply to the communications between nodes such as reliabil-ity, deadline, durability or transport priority. QoS expected/offeredon the publisher/subscriber side respectively needs to be compati-ble in order for the communication to take place. TinyDDS (Boonmaand Suzuki, 2010) presents an implementation of the DDS standardfor WSANs located in the transport layer that can work on top ofdifferent network layer implementations. TinyDDS, does not focuson a specific routing protocol to be used but rather offers a layerdesign pattern that allows flexible use of different protocols. Tiny-DDS offers a complete solution to communicate not only nodes inthe same network but also different TinyDDS networks by meansof a set of gateways. Although the DDS standard is a rather simplestandard, we believe that some parts can be optimized to cope withthe WSAN limitations. PS-QUASAR offers a simpler programmingmodel.

2.2.2. Proposals for WSANsA clustered approach to support a publish/subscribe program-

ming abstraction over WSANs is followed in Schönherr et al. (2008).Clusters are automatically formed in the WSAN by means of theinformation periodically exchanged between nodes and the use ofa cost function. Each of the clusters has a cluster head that receivesthe information sent by the nodes by means of a spanning tree.Inter-cluster communication is also possible. Subscriptions are dis-seminated within each cluster by flooding it with messages. Theperiodical beaconing of this proposal is similar to the one used inPS-QUASAR. Also, this proposal supports the use of actors.

A policy-based publish/subscribe middleware for sense-and-react applications is presented in Russello et al. (2011). Applicationsare specified using a customized high level language called ESCAPEwhich is later translated to platform-specific code automatically.The prototype implementation of the middleware offers two rout-ing protocols, both based on the flooding protocol. The middlewarehandles authentication and reliability by means of retransmissionsand also supports the use of actors. The programming model pre-sented in the paper is more complex and sophisticated than that ofPS-QUASAR but involves more steps in the development process.

Finally, the PS-QUASAR routing protocol can be classified as arouting protocol supporting multiple subscribers and the use ofactors. It also copes with QoS requirements.

3. Problem formulation, assumptions

The network is assumed to be composed of an homogeneousset of nodes with equal transmission range. Nodes can interferewith the communications of other nodes if communication is

ms and Software 86 (2013) 1650– 1662 1653

s(aNaips

antaibgs

4

boccwpt

mMgmnrtopdspttip

J. Chen et al. / The Journal of Syste

imultaneous. The following entities are possible in the network:1) publishers (data producers) and/or subscriber (data consumers)nd (2) relay nodes which are neither publisher nor subscribers.odes are not aware of their position or the network topologynd the reporting pattern is unknown, i.e., nodes can freely sendnformation when they want. The goal is to route information fromublishers to subscribers that have declared their interest in theame topic and by taking into account the QoS requirements.

Let the network graph be G = (V, E) where V is the set of nodesnd E the set of edges. The cardinality of each set is specified as

= |V| and m = |E| respectively. Let si be node i in V and eij the edgehat goes from si to sj where 0 ≤ i, j ≤ n. Let Ni be the set of neighborsdjacent to si and ti = |Ni|. We consider that two nodes are adjacentf they can directly communicate with each other. Let Pubt and Subt

e all the publishers and subscribers of topic t respectively. D(si, s)ives the minimum known distance at a given time between nodei and subscriber s measured in number of hops.

. PS-QUASAR middleware

PS-QUASAR is a lightweight middleware that provides a topic-ased publish/subscribe scheme with an event/listener abstractionver the traditional message passing abstraction provided by allurrent WSAN platforms. The PS-QUASAR routing protocol is espe-ially tailored to the publish/subscribe requirements. In otherords, it connects multiple publishers to subscribers in a trans-arent way for the programmer and at the same time ensures thathe QoS requirements are met.

The PS-QUASAR middleware is composed of three differentodules: PS-QUASAR Maintenance Protocol, PS-QUASAR Routingodule and the API. Fig. 1 shows the PS-QUASAR module dia-

ram and how the different modules connect to each other. Theaintenance protocol is in charge of creating the links between

eighbor nodes and discovering subscribers and publishers. Theouting module carries out the actual routing process based onhe information collected by the former protocol. The API, on thether hand, provides a set of methods for developers to make use ofublish/subscribe programming model offered by PS-QUASAR. Theetails on these three components are presented in the followingections. Section 4.1 presents an overview of the publish/subscriberogramming model provided by PS-QUASAR. Section 4.2 presentshe maintenance protocol and unsubscription mechanisms used by

he PS-QUASAR routing module. The routing protocol is explainedn Section 4.3. Finally, the QoS support mechanisms used in thisaper are detailed in Section 4.4.

Fig. 1. PS-QUASAR module diagram.

Fig. 2. PS-QUASAR programming model API.

4.1. Publish/subscribe programming model

PS-QUASAR provides a lightweight topic-based pub-lish/subscribe model suitable for wireless sensor devices, whichare constrained devices in terms of size, cost, memory and band-width. Topic-based publish/subscribe means that the matchingprocess between publishers and subscribers is entirely done on thebasis of a topic name. A topic is simply a keyword that identifiesthe subject of the information generated by a publisher or thesubject of the information that a subscriber wants to receive.In PS-QUASAR the topic name is encoded in a 16-bit integer forreasons of efficiency. Each piece of information generated by pub-lishers is associated with a 16-bit integer (chosen by the developerand specified in the ps publish primitive). This information willbe automatically delivered to nodes which have declared theirinterest in the same 16-bit integer (by means of the ps subscribeprimitive). The publish/subscribe programming model providedby PS-QUASAR is really simple and easy to use. The simplicityof the model helps developers to implement WSAN applicationswithout worrying about common low-level issues such as datapacket encoding/decoding, message handling, etc.

The publish/subscribe programming model API is shown inFig. 2. The primitives are classified depending on whether theyare called from the publisher or the subscriber side. The proposedpublish/subscribe programming model is based on two differentmechanisms: publish/subscriber primitives and listeners. The pub-lish/subscribe primitives allow information to be transparentlysent from publishers to subscribers. These two entities can belocated in different nodes or in the same one. By doing this we use anhomogeneous publish/subscribe approach that is used for all com-munications that are carried out in the network, either in a localor remote way. In the proposed publish/subscribe model, the QoSrequirements are only specified on the publisher’s side. This simpli-fies the task of delivering information and avoids time-consumingQoS-matching algorithms. In DDS, for example, QoS is specified onboth sides and only when the QoS policies are compatible does thecommunication take place. This however requires an additionalmatching algorithm or must rely on a central server that carriesout this task. The QoS parameters offered are deadline, reliabil-ity and priority. Deadline is expressed in ms, reliability in numberof node-to-node retransmissions. Priority is expressed as a num-

ber, the higher it is the more priority is given to the packet. Moredetails about how these QoS parameters are handled can be foundin Section 4.4. Listeners are functions that are executed whenevera message is received by a subscriber. Only subscribers can make

1654 J. Chen et al. / The Journal of Systems and Software 86 (2013) 1650– 1662

gram

uapdotmn

pinepltcasi

4

pnr(wwiEdt

t

Fig. 3. PS-QUASAR pro

se of listeners to process received data. Listeners are specifieds a parameter in the ps subscribe method. Listeners receive twoarameters: the ID of the node sending the information and theata itself. In addition, the developer needs to specify the behaviorf the main function. This function is called once, upon initializa-ion. From it, subscriptions are chosen (ps subscribe) and publish

ethods can also be called. For example if periodical reporting iseeded, periodical timers are set in the main function.

To sum up, the PS-QUASAR programming model is composed ofublish/subscribe primitives and listeners. Publish/subscribe prim-

tives are used to communicate nodes and functions in the sameode or in remote nodes whereas listeners take action when-ver information is received at a node. Fig. 3 illustrates this entirerocess by means of a simple example. In the example, node 1 pub-

ishes a temperature warning notification (topic TW). Because onlyhe local node is subscribed to the TW topic no communication isarried out with remote nodes. A local listener processes the datand depending on its value publishes the reading to all nodes sub-cribed to the temperature alarm topic (TA topic), which is node 2n the example.

.2. Maintenance protocol

Tree-based routing protocols usually require a maintenancerotocol that allows each node to find its neighbors and coordi-ate them to form a tree. One of the classic algorithms to form aouting tree in a distributed manner is the Bellman–Ford algorithmTanenbaum, 2010). The algorithm maintains a table at each nodeith the best known distance to each destination (subscriber) andhere it has to relay the information to get there. This distance is

teratively updated by exchanging information with its neighbors.ventually, each node in the network is able to find the shortest

istance to the destination. The distance is typically measured ashe number of hops toward the destination.

One identified issue in the Bellman–Ford algorithm is the count-o-infinity problem shown in Fig. 4 and explained in Tanenbaum

Fig. 4. Node failure issue in common tree-based maintenance.

ming model example.

(2010). Let us imagine we have a network of 4 nodes. The root issupposed to be node A. After the maintenance protocol is carriedout all nodes know how to relay the information to A. At a certainpoint node B fails and because of the timestamps, node C is awarethat no path is available to node A. Before node D is aware of thisnew situation it sends a maintenance packet stating that node Ais at distance 3. Node C will receive this maintenance packet andit will believe that there is a new path toward A if information isrelayed through D. If there are more nodes in the network this errorwill cascade through them and the network will become unusable.

Section 4.2.1 covers the PS-QUASAR maintenance protocolbased on the Bellman–Ford algorithm and Section 4.2.2 theunsubscription/failure recovery mechanism that also deals withcount-to-infinity problem. The PS-QUASAR maintenance andunsubscription protocol described in both sections is depicted inAlgorithm 1.

Algorithm 1 (PS-QUASAR Maintenance protocol. Node si).loop

for all active unsubscription of subscriber a from neighbor n doif phase(n, a) = =1 then

Add to notify packet: a is no longer accessible from si

5: end ifend forfor all subscriber b accessible from node si do

Calculate D(si„ b) from the information stored in the neighbortable (nodes in Ni)

Add to notify packet: subscriber b is at distance D(si , b) fromnode si

10: end forAdd to notify packet: information about si such as E(si), . . .Broadcast notify packetwait MAINTENANCE PERIOD

end loop15: upon reception of notify packet p from node sj do

for all unsub./failure of subscriber a accessible from neighbor sj

in p doif subscriber a is only accessible from sj with min. distance

thendelete from neighbor table: a is accessiblephase(sj , a) = 1

20: start timer to set phase(sj , a) = 2 after time t1

start timer to end unsub. protocol for subscriber a andneighbor sj after time t1 + t2

end ifend forfor all subscriber b notified in p do

25: if phase(sj , b) = 1||phase(sj , b) = 2 thenignore notification (the subscriber is unsubscribing)

elseupdate distance to b as D(sj , b)+1 if it is nearer the one

already stored in the local tablesend if

30: end forupdate information about the neighbor sj: E(sj), . . .

update sj timestampend upon

J. Chen et al. / The Journal of Systems an

4

rTBpem

itnttnmrrhtwaate

tntfptQbee(

4

mtiuis

lnwcto

Fig. 5. Maintenance packet fields.

.2.1. PS-QUASAR maintenanceThe PS-QUASAR routing protocol is based on a tree-based

outing protocol and as such requires a maintenance protocol.he proposed maintenance protocol is a modified version ofellman–Ford algorithm. The maintenance protocol is based oneriodical beaconing to exchange node information (e.g. remainingnergy) and subscriber information. Node information is used toeet QoS requirements.All nodes periodically broadcast a maintenance packet with

nformation about themselves and also with information abouthe subscribers that are accessible from the current node. In everyode, information about the subscribers found so far and informa-ion about the neighbors are kept in a local table. This table keepsrack of all the subscribers discovered so far and all the possibleeighbors through which the node can relay the information toake the packet reach the subscriber. Because of this, PS-QUASAR

outing protocol is not strictly a tree-based routing protocol butather a directed acyclic graph based protocol. All possible next-op that are part of minimum distance paths are stored and areaken into account during the routing process. If one of the pathsith minimum distance toward the destination fails the others

re still available and the routing protocol will continue to oper-te normally. Only when all paths with minimum distance fail willhe unsubscription/failure protocol presented in Section 4.2.2 bexecuted.

Two facts can be deduced from the proposed maintenance pro-ocol. The first is that all nodes in the network are aware of theumber of subscribers and how to reach them and the second ishat multiple paths toward each subscriber are identified. The firstact means that in PS-QUASAR all nodes in the network can act asublishers without having to notify of this fact in advance (unlikeraditional publish/subscribe systems). The second means that PS-UASAR can select the most suitable path toward a subscriberased on the state of the network. Fig. 5 shows the informationxchange by the maintenance protocol. It includes the distance toach of the subscribers, information about each of the neighborssuch as remaining energy) and unsubscription information.

.2.2. Unsubscription and fault toleranceThe unsubscription algorithm uses the periodical maintenance

echanism to carry out unsubscription and node failure notifica-ion. The same maintenance packet used in the protocol explainedn Section 4.2 is also used to notify of unsubscriptions and node fail-res. If any unsubscription is issued then the maintenance packet

s also used for a number of periods to notify neighbors that aubscriber is no longer available.

In addition, the proposed algorithm has identified and tack-ed the count-to-infinity problem. This behavior is caused becauseodes update their tables with information, that is not up-to-date

hich can cause an incoherent state that prevents routing being

arried out properly. Whenever an unsubscription or a node failureakes place the neighbors will be aware of the situation becausef the timestamp mechanism. Each neighbor will detect the

d Software 86 (2013) 1650– 1662 1655

subscriptions involved in the unsubscription/node failure. Then atwo phase unsubscription process will start for that particular sub-scription. One phase runs after the other and each of the phaseslasts for a predefined length of time that is measured using timers.Different unsubscriptions can be executed at the same time in anode and each of them can be in a different phase.

When an unsubscription of subscriber u starts at node n:

1. During the first phase node n will periodically broadcast that u isunsubscribing. Information received at node n about subscriberu is discarded during this phase. In other words, phase one indi-cates that a subscriber is currently unsubscribing and thereforethe information it sends may not be up-to-date. Packets receiv-ing the unsubscription of subscriber u from node n will start theunsubscription protocol for that particular subscriber. This waythe unsubscription information propagates across the network.

2. This phase is similar to phase 1 but no broadcast messages aresent informing about the unsubscriptions/node failures. Phase 2gives time for neighbors of node n to delete the correspondingentries about subscriber u from the tables before trusting in thecontent of the corresponding maintenance packet sent by noden. This way the count-to-infinity problem is mitigated. For thisto be done, the duration of phase two must be equal to or higherthan the time defined in the timestamp to delete old informationabout nodes.

Phases are symbolically marked as phase(si, a) in Algorithm 1.Finally, we note that the maintenance mechanism is used to carryout unsubscription so no additional messages are needed to addthe modifications proposed.

Fig. 6 shows an example of the same situation shown in Fig. 4with our proposal. This time the maintenance packet that nodeC receives from node D is ignored because node C is running theunsubscription protocol for that particular topic and subscriber.

4.3. Routing protocol

The routing protocol is covered in this section. First the conceptof weight function is introduced in Section 4.3.1. Then, the multicastmechanism and the PS-QUASAR routing algorithm is explained inSection 4.3.2.

4.3.1. PS-QUASAR weight functionThe PS-QUASAR routing protocol uses a weight function to eval-

uate each of the neighbor nodes to which it can relay data packets.The PS-QUASAR weight function that evaluates node si to calculatethe importance of link eij is defined as

Wi(sj) = ff (neighbor status) ∗ fw(neighbor status) (1)

where fw is a function that evaluates the importance of the pathtoward a subscriber based on the information it has about the net-work and about the neighbor. By defining function fw so that ittakes into account different parameters such as LQI (link qualityindicator), remaining energy, traffic, etc., routing decisions can becustomized to tailor the protocol behavior to the need of the users.Finally, the weight function is controlled by an additional functionff. This allows the protocol to discard certain nodes which do notwant to be considered as relay nodes. Basically when a node wantsto be discarded as a relay node, ff must be equal to 0. Since theweight function expresses the probability of a node to be chosenas the next relay node, a value of 0 indicates that the node is nevergoing to be chosen in the routing process. The weight function is the

mathematical tool that shapes the behavior of the routing module.

For example let us consider that we want the routing algorithmto give priority to paths with a high remaining energy and with ahigh LQI. One possible solution is to define the weight function as

1656 J. Chen et al. / The Journal of Systems and Software 86 (2013) 1650– 1662

maintenance example.

iett

ap

4

arctaatahc

iacttost

ttdbhdpnr

ptrc

Fig. 6. PS-QUASAR

n formula (2). Em and Lm are the normalized value of the remainingnergy of a node and the LQI value of the communication link withhat node respectively. c1 and c2 values are used to further controlhe importance of the energy and LQI parameters.

Additionally, only nodes whose energy and LQI are higher than predefined threshold will be taken into account in the routingrocess.

ff (sj) ={

0 if E(sj) < THRESHOLD1∨

L(sj) < THRESHOLD2

1 otherwisefw(neighbor status) = c1 ∗ Em(sj, neighbor status) + c2 ∗ Lm(sj, neighbor status)

Wi(sj) = ff (sj) ∗ fw(neighbor status)

(2)

.3.2. PS-QUASAR routingPS-QUASAR does not cache information. The information is sent

s soon as it is produced by means of a directed acyclic graph basedouting protocol. The PS-QUASAR routing protocol extends the con-ept of a simple routing tree to make use not only of one pathoward each subscriber but to use as many paths as possible. Tochieve this, nodes establish links with each other to form a directedcyclic graph for each of the publishers in the network. Althoughhis implies that more memory is necessary to keep the informationbout all adjacent nodes, the number of neighbors a sensor nodeas, even in dense networks, is relatively small. This extra memoryan be perfectly handled by current sensor nodes.

The PS-QUASAR routing protocol dynamically adapts its behav-or to the neighbor status to route the packets using different pathsnd allows the information to be transmitted with certain QoS poli-ies. The use of multiple paths toward the subscriber node improveshe energy efficiency of the algorithm. As explained in Section 4.2,he maintenance protocol identifies the possible paths toward eachf the subscribers. The routing protocol uses this information toend data packet associated with a topic to all subscribers of thatopic in the network.

PS-QUASAR proposes a publish/subscribe programming modelhat allows multiple subscribers to declare their interest in the sameopic. Because of that, data associated with a topic may need to beelivered to more than one node in the network. One option woulde to send a packet for each of the subscribers in the network. Thisowever, generates unnecessary traffic as the same information isuplicated. To optimize this type of communication PS-QUASARroposes a multicast mechanism. In general terms, packets areot duplicated whenever possible unless the network topologyequires it.

The routing module takes the information that the maintenance

rotocol collects and reuses paths whenever possible when morehan one subscriber of a topic is detected. If subscribers cannot beeached by relaying to the same direction then packets are dupli-ated. In order to control duplicate packets a packet field called

Fig. 7. Data packet fields.

“Already notified” (Fig. 7) is used to tell the nodes the list of sub-scribers that do not need to be notified. This field contains a list ofall subscriber ids that are being notified by other packet duplicateor that have already being notified. The use of that packet field andthe algorithm itself is explained by means of an example in Fig. 8.

In the example we have four subscribers (nodes A, B, E, H) andone publisher (node G). In Fig. 8(b) publisher G publishes data tosubscribers A, B, E and H. For each of the messages sent, the contentof the “Already notified” field of each packet is shown. The decisionof which path to use is entirely based on the information collectedby the maintenance protocol. More specifically, distances are usedto detect paths that take us one hop closer to the maximum numberof subscribers possible. The algorithm is repeated in each of therelay nodes until all corresponding subscribers are attended by thesmallest number of packets. In the example node G detects that byrelaying through node E it is possible to reach nodes E, A, B. Anotherpacket is sent to node H to reach the remaining subscriber. The“Already notified” field of the packet sent from G to E specifies thatthis packet does not need to reach H because there is another packetthat is in charge of doing so. In this way, the field is updated everytime a packet needs to be duplicated or a subscriber is notified.This field is necessary for packets to keep control of the multicastprocess.

The pseudocode behavior of the PS-QUASAR routing protocol isdetailed in Algorithm 2.

Algorithm 2 (PS-QUASAR routing module pseudocode. Node si).upon reception of data packet p of topic t do

calculate a set of nodes H ⊆ Ni so that1. by relaying a packet through every node sh ∈ H all subscribers

not attended yet in Subt can be reached with minimum distance2. |H| is minimum

5: 3. |H∩ L| = ∅ where L are the nodes specified in the alreadynotified section of packet p

4. If there is more than one possible option to reach a subscriberthen the path whose weight function is bigger is chosen

update deadline packet field and end if it has expiredfor all sh ∈ H do

10: update status of “Already notified” field of packet pif reliability is enabled then

relay data packet p to node sh in a reliable wayelse

relay data packet p to node sh

15: end ifend for

end upon

J. Chen et al. / The Journal of Systems and Software 86 (2013) 1650– 1662 1657

(a) Exampl e sce nario. Node G is thepublisher and nodes A, B, E and H arethe sub scribers

(b) Packet duplication is not done unless re-qui red by the network topolog y

F sher ar

ocnsptts

4

tpp

wpenchaa

pimPpai

d

d

ntaundolIr

The test scenario is composed of a network of 110 nodesarranged in a grid as shown in Fig. 9. To test the routing algorithm,a set of nodes will periodically report a series of messages.

0

1

2

3

4

5

6

7

8

9

10

11

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

ig. 8. PS-QUASAR multicast mechanism. (a) Example scenario. Node G is the publiequired by the network topology.

Every time a data packet is received the “Already notified” fieldf the packet is compared to the subscriber tables in the node toheck whether there are still any subscribers that have not beenotified. If there are any then the corresponding paths are cho-en so that all remaining subscribers are covered, the number ofacket duplicates is minimum and also whose weight function ishe biggest. For each of the copies of the packet that are relayed,he “Already notified” field needs to be updated to include all sub-cribers covered by other packet duplicates.

.4. QoS

This section summarizes the mechanisms used to deal withhe QoS requirements specified by means of the publish/subscriberogramming model detailed in Section 4.1. These are: reliability,riority and deadline.

In our protocol, reliability deals with increasing the probabilityith which packets are transmitted whereas priority finds shortaths toward the destination based on the importance of the pack-ts. Reliability is achieved using node-to-node retransmission. Theumber of retransmissions that are made on a node-to-node basisan be specified in the publish primitive shown in Fig. 2. Priority isandled by means of queues where incoming and outgoing packetsre ordered according to their importance. Priority is specified asn integer number that is stored inside each packet.

Finally, PS-QUASAR provides a deadline mechanism that allowsackets to be discarded if their deadline has expired before reach-

ng destination. The user can specify a deadline that expresses theaximum time allowed for the packet to reach the destination. In

S-QUASAR, the deadline, if specified, is stored in a field in each dataacket and updated everytime it is relayed using formula (3). Also,n estimation of the time it takes a packet si to reach a subscriber ss calculated as depicted in formula (4).

eadline′i = deadlinei − (tp + ts) (3)

elayi = ts ∗ D(si, s) (4)

tp expresses the time a packet is being processed at a node,amely from the moment it is received to the moment it is relayed.

s refers to the average time that it takes to send a data packet to neighbor node. Because ts time cannot be measured in real-timenless the two nodes involved in the communication have synchro-ized their clocks, a constant ts value has been used. Whenever aeadline field of a packet is updated and the resulting value is less

r equal to 0 the packet is discarded. Also if the delayi value calcu-ated is higher than the remaining deadline the packet is discarded.n addition packets with the same priority are queued, ordered byemaining deadline. This way, the smaller the deadline is the sooner

nd nodes A, B, E and H are the subscribers. (b) Packet duplication is not done unless

they are handled compared with other packets in the same prioritylevel.

5. Evaluation

In order to test the protocols described in this paper, severaldifferent tests have been carried out. The tests are depicted in thissection, with the analysis of the results obtained.

5.1. Environment set-up

The prototype of the algorithm has been implemented in Cprogramming language for the TelosB motes running the Contikioperating system (Dunkels et al., 2004). The resulting code has beensimulated using the Cooja simulator (Österlind et al., 2006). TheCooja simulator emulates TelosB motes at machine code instruc-tion set level. The communication model takes into account packetloss when nodes are transmitting at the same time.

5.2. Energy consumption, reliability and packet delay

0 2 4 6 8 10 12

Fig. 9. Evaluation scenario: 110 sensor nodes arranged in a grid. Square: HM topic.Diamond: TM topic. Triangle: LD topic. Circle: neither subscriber nor publisher. Star:all three topics. Filled/non-filled figures indicate subscribers/publishers.

1 ms and Software 86 (2013) 1650– 1662

ehatNacnanpe2bao(moa

u

wircp

utewotmt

F(

658 J. Chen et al. / The Journal of Syste

The test scenario has a total of 5 subscribers and 9 publish-rs dealing with data from 3 different topics: temperature (TM),umidity (HM), linear displacement (LD). Publishers/subscribersre marked with square/diamond/triangle symbols indicating thathey produce/receive data from TM/HM/LD topics respectively.ode 51, represented as a star, is subscribed to all three topicsnd will therefore receive information from all 9 publishers. Theommunication in this scenario follows a many-to-many commu-ication pattern that allows the features of our algorithm to benalyzed. Each node except for the ones in the boundaries has 8eighbors at 1 hop distance. The test is made up of a series of dataackets published at the same time from each of the publishersvery 10 s. The total number of packets sent by each publisher is01. For example, information generated by nodes 26, 28, 30 wille received by subscribers 2, 21 and 51. Node 60 is configured to use

3-retransmission reliability scheme. The rest of the nodes operaten a best effort basis. This scenario is used to study the reliabilitydelivery ratio), energy consumption (expressed in millijoules) and

ean packet (expressed in ms) delay of each node. Before carryingut the test, the network has been initialized to let each node findll its neighbors.

To test the algorithm the following weight function has beensed

ff (sj) ={

0 if E(sj) < THRESHOLD

1 otherwisefw(neighbor status) = Em(sj, neighbor status)

Wi(sj) = ff (sj) ∗ fw(neighbor status)

(5)

here neighbor status contains all the information about the nodesn Pi. This weight function gives preference to neighbors with highemaining energy and will therefore help to balance the energyonsumption between the possible relay nodes in the path betweenublishers and subscribers.

Figs. 10 and 11 show the energy consumption for the testsing/without using the PS-QUASAR multicast mechanism respec-ively. A series of colored dots have been used to represent thenergy consumption. Each dot represents a sensor node in the net-ork. The color of each dot represents the energy relative to the

ther nodes in the network, i.e. the darkest color corresponds tohe node with the highest remaining energy after the test. When

ulticast is not used then a packet duplicate must be created every-ime a message is sent even if multiple subscribers are in the same

ig. 10. Energy consumption of the test scenario using PS-QUASAR multicastenergy is expressed in millijoules).

Fig. 11. Energy consumption of the test scenario without using PS-QUASAR multi-cast (energy is expressed in millijoules).

direction. Because each of these packets can take a different pathtoward the subscriber the energy consumption is less balanced asshown in Fig. 11. On the other hand using the PS-QUASAR multicastmechanism optimal paths are detected in a fully distributed wayand they are used to transmit less packets which translates to animprovement in energy consumption and reliability. This has beenmarked as a set of lines in Fig. 10. Using this path all correspondingsubscribers can be reached at minimum distance whilst avoidingduplicating packets. The mean energy consumption of the mainte-nance protocol without taking into account the data packets sentis of 369.32 mJ.

Comparing Figs. 10 and 11 it can be seen that the energy con-sumption in Fig. 11 affects a higher number nodes and is lessbalanced in the sense that nodes with a higher energy consump-tion are disperse across the whole network. On the other hand, inFig. 10 only nodes within optimal paths show a relatively higherenergy consumption. Optimal paths, in this context, refer to thepaths at minimum distance that can be used by publishers to sendthe information to multiple subscribers at the same time.

The mean energy consumption during the test is 2474/2567 mJfor the scenario with/without multicast respectively. The resultindicates that the mean energy consumption is lower in the sce-nario that uses multicast. In order to better illustrate the energyconsumption in both scenarios Fig. 12 shows the time it takes 50%of the nodes (55 nodes) in the network to spend a predefined valueof 10,000 mJ. Initially, the multicast scenario seems to spend theenergy more quickly but after the first 10 nodes (which corre-spond to nodes near the subscribers) the nodes in the non-multicastscenario start spending the energy at a higher rate. The 3 graphspreviously presented, however, do not explain the higher energyconsumption in nodes near the subscribers that the multicast sce-nario has. In order to understand that, reliability ratios need to betaken into account.

Figs. 13 and 14 show the delivery ratio in hundreds per cent forboth cases. It is clear that all packets sent from node 60 (which isconfigured to send data in a reliable way) have been received bynode 51 in both tests. Also, a much higher delivery ratio is achievedusing multicast. For example, without using multicast more thanhalf of the packets between nodes 90 and 51 are lost. If a packet islost it does not reach the subscriber and therefore does not generatean energy consumption in nodes near the subscriber. This is one of

the reasons the energy consumption in nodes near the subscriberis higher in the case where multicast is used. In the test a totalnumber of 4221 packets should be received if a 100% reliability is

J. Chen et al. / The Journal of Systems an

5 10 15 20 25 30 35 40 45 50 555000

5500

6000

6500

7000

7500

8000

8500

9000

Number of nodes

Tim

e re

quire

d to

spe

nd 1

0000

mJ

(sec

onds

) x − no multicasto − multicast

Fig. 12. Time it takes a certain number of nodes of the network to spend 10,000 mJo

abtti

smotrmdn

both scenarios it can be seen that the network traffic is the main

f energy.

ssumed. For the case where multicast has been used, 4095 haveeen received. However, for the case where multicast is disabled aotal of 3559 packets have been received. Even taking into accounthis difference in the delivery ratio, the mean energy consumptions lower in the multicast test.

The difference in the delivery ratio is produced by the colli-ions when transmitting at the same time. Because the multicastechanism reduces the network traffic it lowers the probability

f collisions which affects the delivery ratio. The results show thathe multicast mechanism reduces the network traffic, improves theeliability and helps to save energy although the energy spent is

ore localized. The higher the number of subscribers in the same

irection from the publisher, the greater the effect it has on theumber of packets generated.

Fig. 13. Delivery ratio of packets using

Fig. 14. Delivery ratio of packets without us

d Software 86 (2013) 1650– 1662 1659

Finally, Figs. 15 and 16 show the main delay packet with andwithout using multicast respectively. In addition Fig. 17 shows thedifference in delay between both cases. A negative value indicatesthat delay using multicast is lower. It can be seen that the multicastcan deliver the packets with a lower delay. There are some caseswhere delay is actually higher than the test without using multicastbut as explained before, this is due to the low delivery ratio obtainedwhen multicast is not used.

5.3. QoS

In this section the QoS mechanisms provided by PS-QUASARare studied. More specifically, the reliability, deadline and prioritysupport of the middleware is analyzed by means of several tests.

5.3.1. ReliabilityReliability is achieved in our middleware by means of retrans-

missions. This has a direct effect on energy consumption, that is, themore reliable a retransmission is the more energy consumption itwill produce in the network. We have seen that the multicast mech-anism helps to save energy consumption by not duplicating packetsunless necessary. In this test we have sent 51 messages every 20 swith the same publisher/subscriber configuration as Section 5.2 butthis time configuring all publishers with a 3-retransmission reli-ability scheme.

The delivery ratio of both scenarios is shown in Figs. 18 and 19.As expected the delivery ratio in this scenario is much higher thanthe one obtained in the previous test (Figs. 15 and 16). In the exam-ple where multicast is used the delivery ratio obtained is muchbetter, reaching almost 100% in all subscribers. However, evenusing a 3-retransmission scheme the delivery ratio of the scenariowhere no multicast is used is significantly affected by the distancebetween publisher and subscriber. From the results obtained in

reason for the network performance. In the second scenario, theoverhead produced by not using multicast has generated muchmore traffic that favors packet collisions and therefore has a direct

multicast (in hundreds per cent).

ing multicast (in hundreds per cent).

1660 J. Chen et al. / The Journal of Systems and Software 86 (2013) 1650– 1662

Fig. 15. Mean delay of packets using multicast.

Fig. 16. Mean delay of packets without using multicast.

of pa

eniTmam

Fig. 17. Difference between mean delay

ffect on the delivery ratio. The mean energy consumption of theodes in the scenario that uses multicast is of 1222.30 mJ where as

n the scenario without multicast the consumption is of 1351.93 mJ.hat supposes around 10% in energy savings by using the multicast

echanism. Because in the multicast scenario, packets generated

re not duplicated unless necessary they do not produce retrans-issions that directly influence the energy consumption.

Fig. 18. Delivery ratio using a 3-retransmis

ckets with and without using multicast.

5.3.2. Deadline and priorityIn this test the deadline and priority mechanisms explained in

Section 4.4 are tested. Fig. 20 shows the test scenario. Nodes 7, 25,43 and 61 periodically publish information at the same time that

will be received by node 1. This test simulates the burst of messagesthat is produced by a sensor network when an abnormal situationis detected in the environment. At that moment the network starts

sion reliability scheme and multicast.

J. Chen et al. / The Journal of Systems and Software 86 (2013) 1650– 1662 1661

Fig. 19. Delivery ratio using a 3-retransmission rel

0 2 4 6 8 10 120

1

2

3

4

5

6

7

8

9

10

11

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

Fig. 20. Test scenario for the deadline/priority test. Filled/non-filled figures indicatesubscribers/publishers.

Table 2Node QoS policy for the priority/deadline test.

Node Priority Deadline (ms)

61 6 900043 6 10,00025 5 9000

7 5 10,000

61 43 25 70

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

Mea

n de

lay

pack

et (

ms)

Node id

Fig. 21. Mean packet delay in a scenario with nodes with different deadline andpriority configurations (see Table 2).

iability scheme and without using multicast.

generating a high number of packets and they are all relayed at thesame time to the subscribers. To simulate this scenario, one packetis published at the same time by each of the four publishers every250 ms. The total number of packets published by each node is 400.The QoS policy of each of these nodes is shown in Table 2.

Fig. 21 shows the mean delay of the packets from the momentthey are sent to the moment they are received in the subscriber.It can be seen that the packets with smaller delay are the oneswith highest priority as expected. Also, packets with the lowestdeadlines have a lower delay within the same priority value.

6. Conclusions

PS-QUASAR, a lightweight middleware that provides a topic-based publish/subscribe scheme for WSANs has been presented.PS-QUASAR allows multiple subscribers and publishers to exist inthe same network. It also provides a set of mechanisms that allowsdeadline, reliability and priority to be handled by means of a simplepublish/subscribe programming model. It has been observed thatthe network traffic significantly degrades the node performanceby causing packet collisions. A multicast mechanism has been pre-sented that improves the energy consumption and network trafficby not duplicating packets unless the network topology requires it.The results obtained show that PS-QUASAR successfully identifiessuitable paths toward each of the subscribers and can effectivelyhandle QoS.

Acknowledgement

This work was supported by the Spanish Project TIN2011-23795WiCMaS:Wireless based Critical Information Management Sys-tems.

References

Akkaya, K., Younis, M., 2005. A survey on routing protocols for wireless sensornetworks. Ad Hoc Networks 3 (3), 325–349, http://dx.doi.org/10.1016/j.adhoc.2003.09.010.

Akyildiz, I.F., Su, W., Sankarasubramaniam, Y., Cayirci, E., 2002. Wireless sensornetworks: a survey. Computer Networks 38, 393–422.

Albano, M., Chessa, S., 2009. Publish/subscribe in wireless sensor networks basedon data centric storage. In: Proceedings of the 1st International Workshop onContext-Aware Middleware and Services: Affiliated with the 4th InternationalConference on Communication System Software and Middleware (COMSWARE2009), CAMS’09, ACM, New York, NY, USA, pp. 37–42, http://dx.doi.org/10.1145/1554233.1554243.

Al-karaki, J.N., Kamal, A.E., 2004. Routing techniques in wireless sensor networks: asurvey. IEEE Wireless Communications 11, 6–28.

Boonma, P., Suzuki, J., 2010. tinydds: an interoperable and configurable pub-lish/subscribe middleware for wireless sensor networks. In: Principles andApplications of Distributed Event-Based Systems, IGI Global, pp. 206–231.

Boukerche, A., Pazzi, R.W.N., Araujo, R.B., 2006. Fault-tolerant wireless sensor

network routing protocols for the supervision of context-aware physical envi-ronments. Journal of Parallel and Distributed Computing 66 (4), 586–599,http://dx.doi.org/10.1016/j.jpdc.2005.12.007.

Cam, H., Sahingoz, O.K., Sonmez, A.C.,2011. Wireless sensor networks basedon publish/subscribe messaging paradigms. In: Proceedings of the 6th

1 ms an

C

C

D

E

G

G

H

J

O

Ö

R

S

S

S

S

662 J. Chen et al. / The Journal of Syste

International Conference on Advances in Grid and Pervasive Computing, GPC’11.Springer-Verlag, Berlin, Heidelberg, pp. 233–242 http://dl.acm.org/citation.cfm?id=2008928.2008960

hen, D., Varshney, P.K., 2004. Qos support in wireless sensor networks: a survey. In:Proc. of the 2004 International Conference on Wireless Networks (ICWN 2004),Las Vegas, NV, USA.

hen, J., Díaz, M., Llopis, L., Rubio, B., Troya, J.M., 2011. A survey on quality of servicesupport in wireless sensor and actor networks: Requirements and challengesin the context of critical infrastructure protection. Advanced Topics in CloudComputing. Journal of Network and Computer Applications 34 (4), 1225–1239,http://dx.doi.org/10.1016/j.jnca.2011.01.008.

unkels, A., Grönvall, B., Voigt, T., 2004. Contiki – a lightweight and flexible operatingsystem for tiny networked sensors. In: Proceedings of the First IEEE Workshopon Embedded Networked Sensors (Emnets-I), Tampa, FL, USA.

ugster, P.T., Felber, P.A., Guerraoui, R., Kermarrec, A.-M., 2003. The manyfaces of publish/subscribe. ACM Computing Surveys 35 (2), 114–131,http://dx.doi.org/10.1145/857076.857078.

arcía Villalba, L.J., Sandoval Orozco, A.L., Trivino Cabrera, A., Barenco Abbas,C.J., 2009. Routing protocols in wireless sensor networks. Sensors 9(11), 8399–8421, http://dx.doi.org/10.3390/s91108399 http://www.mdpi.com/1424-8220/9/11/8399/

aura, E., Girod, L., Brusey, J., Allen, M., Challen, G., 2010. Wireless Sensor Networks,Deployments and Design Frameworks. Springer, New York.

unkeler, U., Truong, H.L., Stanford-Clark, A., 2008. Mqtt-s – a publish/subscribeprotocol for wireless sensor networks. In: 3rd International Conference on Com-munication Systems Software and Middleware and Workshops COMSWARE 08(January), pp. 791–798.

iang, Q., Manivannan, D., 2004. Routing protocols for sensor networks. In:Proceedings of the 1st IEEE Consumer Communications and Networking Con-ference (CCNC’04), Las Vegas, NV, USA, pp. 93–98.

OMG consortium, DDS: Data Distribution System. http://www.omg.org/technology/documents/dds spec catalog.htm

sterlind, F., Dunkels, A., Eriksson, J., Finne, N., Voigt, T., 2006. Cross-level sensornetwork simulation with cooja. In: Proceedings of the First IEEE Interna-tional Workshop on Practical Issues in Building Sensor Network Applications(SenseApp 2006), Tampa, FL, USA.

ussello, G., Mostarda, L., Dulay, N., 2011. A policy-based publish/subscribe mid-dleware for sense-and-react applications. The Ninth International Conferenceon Quality Software. Journal of Systems and Software 84 (4), 638–654,http://dx.doi.org/10.1016/j.jss.2010.10.023.

chönherr, J.H., Parzyjegla, H., Mühl, G., 2008. Clustered publish/subscribe in wire-less actuator and sensor networks. In: Proceedings of the 6th InternationalWorkshop on Middleware for Pervasive and ad hoc Computing, MPAC ’08, ACM,New York, NY, USA, pp. 60–65, http://dx.doi.org/10.1145/1462789.1462800.

harifi, M., Taleghan, M., Taherkordi, A., 2006. A publish–subscribe middle-ware for real-time wireless sensor networks. In: Alexandrov, V., van Albada,G., Sloot, P., Dongarra, J. (Eds.), Computational Science – ICCS 2006. Lec-ture Notes in Computer Science, vol. 3991. Springer, Berlin/Heidelberg,

pp. 981–984.

hi, K., Deng, Z., 2011. Tinymq A content-based publish/subscribe middleware forwireless sensor networks. Science and Technology C, 12–17.

outo, E., Guimarães, G., Vasconcelos, G., Vieira, M., Rosa, N., Ferraz, C., Kel-ner, J., 2005. Mires: a publish/subscribe middleware for sensor networks.

d Software 86 (2013) 1650– 1662

Personal and Ubiquitous Computing 10 (1), 37–44, http://dx.doi.org/10.1007/s00779-005-0038-3.

Taherian, S., Bacon, J., 2007. A publish/subscribe protocol for resource-awarenessin wireless sensor networks. In: Aspnes, J., Scheideler, C., Arora, A., Madden,S. (Eds.), Proceedings of the International Workshop on Localized Algorithmsand Protocols for Wireless Sensor Networks (LOCALGOS 2007). Lecture Notes inComputer Science (LNCS), vol. 4549. IEEE Computer Society, Springer, Santa Fe,NM, USA, pp. 27–38.

Tanenbaum, A., 2010. Computer Networks, 5th ed. Prentice Hall Professional Tech-nical Reference.

Tran, D.A., Truong, L.H., 2011. Enabling publish/subscribe services in sensornetworks. In: Publishers, R. (Ed.), Advances in Next Generation Services andService Architectures.

WSAN4CIP. Wireless Sensor and Actuator Networks for the Protection of CriticalInfrastructures. EU FP7. http://www.wsan4cip.eu

Xia, F., 2008. Qos challenges and opportunities in wireless sensor/actuator networks.Sensors 8 (2), 1099–1110, http://dx.doi.org/10.3390/s8021099 http://www.mdpi.com/1424-8220/8/2/1099/

Jaime Chen earned his BS and MS degree in Computer Engineering at University ofMálaga in 2008. He received his M.S. degree in “Artificial Intelligence and SoftwareEngineering” at University of Málaga in 2009. He is currently a PhD student therewhere he investigates in the field of the Wireless Sensor and Actor Networks and itsapplications. He is specially involved in the area of middlewares for WSANs and QoSsupport. He has been a member of the Software Engineering group of the Universityof Málaga (GISUM) since 2009.

Manuel Diaz received his MS and PhD degree in Computer Science from the Uni-versity of Málaga in 1990 and 1995, respectively. From 1990 to 1995 he was anAssistant Professor at the Department “Lenguajes y Ciencias de la Computación” ofthe University of Málaga. Since 1995 he has been an Associate Professor in the samedepartment. He has worked in the areas of distributed and parallel programmingand in real-time systems, especially in the areas of software engineering for thesekinds of systems. He has been a member of the Software Engineering group of theUniversity of Málaga (GISUM)since its foundation.

Bartolomé Rubio received his MS and PhD degree in Computer Engineering fromthe University of Málaga in 1990 and 1998, respectively. From 1991 to 2000 he wasan Assistant Professor at the Department “Lenguajes y Ciencias de la Computación”of the University of Málaga. Since 2001 he has been an Associate Professor in thesame department. He is working in the areas of distributed and parallel program-ming and coordination models and languages. Currently, he is specially involved inthe research field of wireless sensor and actor networks. He has been a memberof the Software Engineering group of the University of Málaga (GISUM) since itsfoundation.

José M. Troya received his MS and PhD degrees from the University Complutense ofMadrid in 1975 and 1980 respectively. From 1980 to 1988 he was an AssociateProfessor in that University, and since 1988 he has been a Full Professor in the

Department of Languages and Computing Science of the University of Málaga. He hasworked on parallel algorithms for optimization problems and on parallel program-ming and software engineering for distributed real-time systems. He has supervisedtwenty PhD thesis and published more than fifty papers in international refereedjournals.