Traffic-Differentiation-Based Modular QoS Localized Routing for Wireless Sensor Networks

13
Traffic-Differentiation-Based Modular QoS Localized Routing for Wireless Sensor Networks Djamel Djenouri and Ilangko Balasingham Abstract—A new localized quality of service (QoS) routing protocol for wireless sensor networks (WSN) is proposed in this paper. The proposed protocol targets WSN’s applications having different types of data traffic. It is based on differentiating QoS requirements according to the data type, which enables to provide several and customized QoS metrics for each traffic category. With each packet, the protocol attempts to fulfill the required data-related QoS metric(s) while considering power efficiency. It is modular and uses geographical information, which eliminates the need of propagating routing information. For link quality estimation, the protocol employs distributed, memory and computation efficient mechanisms. It uses a multisink single-path approach to increase reliability. To our knowledge, this protocol is the first that makes use of the diversity in data traffic while considering latency, reliability, residual energy in sensor nodes, and transmission power between nodes to cast QoS metrics as a multiobjective problem. The proposed protocol can operate with any medium access control (MAC) protocol, provided that it employs an acknowledgment (ACK) mechanism. Extensive simulation study with scenarios of 900 nodes shows the proposed protocol outperforms all comparable state-of-the-art QoS and localized routing protocols. Moreover, the protocol has been implemented on sensor motes and tested in a sensor network testbed. Index Terms—Wireless sensor networks, quality of service, geographical routing, distributed protocols. Ç 1 INTRODUCTION M ANY applications of wireless sensor networks (WSN), such as vehicular and biomedical, have diverse data traffic with different quality of service (QoS) requirements. This paper focuses on these applications, for which it proposes a localized QoS routing protocol. Traffic differ- entiation, while simultaneously considering latency, relia- bility, residual energy, and transmission power in a localized way represents the key features of our contribution. We consider a general scenario typical for many of the targeted WSN applications, where sensors collect different kinds of data and transmit them toward fixed sinks via other sensors in a multihop, ad hoc paradigm. We define two kinds of sinks; primary sink and secondary sink, to which a separate copy of each message that requires high reliability is sent. A typical example of such a scenario is patient monitoring in a hospital room, where different health parameters are to be captured and forwarded to health care servers accessible by the medical staff. Traffic is diverse and may have different QoS requirements, depend- ing on the monitored parameter and its value, the patient health situation, the patient context, e.g., regular monitoring versus monitoring in operating room, etc. Duplication toward a secondary sink may be useful if high reliability is required. Three different classes of QoS requirements are used in the proposed protocol: 1) energy efficiency (including both residual energy and the required transmis- sion power), 2) reliability, and 3) latency. The first requirement is traffic unrelated, contrary to the other ones. It can be viewed as application-related QoS metric that must be taken into account for all types of traffic, since ensuring a long network lifetime is essential for all applications. With these requirements, data traffic may be split into: 1. regular traffic that has no specific data-related QoS need, 2. reliability-sensitive traffic, which should be deliv- ered without loss but can tolerate reasonable delay, e.g., file transfer for long term data, 3. delay-sensitive traffic, which should be delivered within a deadline but may tolerate reasonable packet loss, e.g., video streaming, and finally 4. critical traffic of high importance and requiring both high reliability and short delay (delivery within a deadline), e.g., safety alarms in vehicular applica- tions, physiological parameters of a patient during a surgery, etc. Following this classification, the proposed protocol is designed using a modular approach, aiming to ensure exactly the required QoS for each packet. A module is devoted to each QoS requirement, in addition to the queuing module and neighbor manager. The queuing module is responsible for implementing a priority multiqueuing strategy that gives more priority, and it consequently ensures shorter latency, to critical and delay-sensitive packets. The neighbor manager runs the HELLO protocol that enables exchanging information between neighboring nodes and implements the link reliability and latency estimators. It uses IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011 797 . D. Djenouri is with the Computer Engineering Department, CERIST Research Center, Rue des Trois Freres Aissou, Ben-Aknoun, Algiers 16030, Algeria. E-mail: [email protected]. . I. Balasingham is with the Interventional Center, Oslo University Hospital, University of Oslo, Intervensjonssenteret Rikshospitalet, 0027 Oslo, Norway. E-mail: [email protected]. Manuscript received 9 Oct. 2009; revised 11 Mar. 2010; accepted 12 Aug. 2010; published online 28 Oct. 2010. For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number TMC-2009-10-0415. Digital Object Identifier no. 10.1109/TMC.2010.212. 1536-1233/11/$26.00 ß 2011 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS

Transcript of Traffic-Differentiation-Based Modular QoS Localized Routing for Wireless Sensor Networks

Traffic-Differentiation-BasedModular QoS Localized Routingfor Wireless Sensor Networks

Djamel Djenouri and Ilangko Balasingham

Abstract—A new localized quality of service (QoS) routing protocol for wireless sensor networks (WSN) is proposed in this paper. The

proposed protocol targets WSN’s applications having different types of data traffic. It is based on differentiating QoS requirements

according to the data type, which enables to provide several and customized QoS metrics for each traffic category. With each packet,

the protocol attempts to fulfill the required data-related QoS metric(s) while considering power efficiency. It is modular and uses

geographical information, which eliminates the need of propagating routing information. For link quality estimation, the protocol employs

distributed, memory and computation efficient mechanisms. It uses a multisink single-path approach to increase reliability. To our

knowledge, this protocol is the first that makes use of the diversity in data traffic while considering latency, reliability, residual energy in

sensor nodes, and transmission power between nodes to cast QoS metrics as a multiobjective problem. The proposed protocol can

operate with any medium access control (MAC) protocol, provided that it employs an acknowledgment (ACK) mechanism. Extensive

simulation study with scenarios of 900 nodes shows the proposed protocol outperforms all comparable state-of-the-art QoS and

localized routing protocols. Moreover, the protocol has been implemented on sensor motes and tested in a sensor network testbed.

Index Terms—Wireless sensor networks, quality of service, geographical routing, distributed protocols.

Ç

1 INTRODUCTION

MANY applications of wireless sensor networks (WSN),such as vehicular and biomedical, have diverse data

traffic with different quality of service (QoS) requirements.This paper focuses on these applications, for which itproposes a localized QoS routing protocol. Traffic differ-entiation, while simultaneously considering latency, relia-bility, residual energy, and transmission power in a localizedway represents the key features of our contribution.

We consider a general scenario typical for many of thetargeted WSN applications, where sensors collect differentkinds of data and transmit them toward fixed sinks viaother sensors in a multihop, ad hoc paradigm. We definetwo kinds of sinks; primary sink and secondary sink, towhich a separate copy of each message that requires highreliability is sent. A typical example of such a scenario ispatient monitoring in a hospital room, where differenthealth parameters are to be captured and forwarded tohealth care servers accessible by the medical staff. Traffic isdiverse and may have different QoS requirements, depend-ing on the monitored parameter and its value, the patienthealth situation, the patient context, e.g., regular monitoringversus monitoring in operating room, etc. Duplicationtoward a secondary sink may be useful if high reliability

is required. Three different classes of QoS requirements areused in the proposed protocol: 1) energy efficiency(including both residual energy and the required transmis-sion power), 2) reliability, and 3) latency. The firstrequirement is traffic unrelated, contrary to the other ones.It can be viewed as application-related QoS metric that mustbe taken into account for all types of traffic, since ensuring along network lifetime is essential for all applications.

With these requirements, data traffic may be split into:

1. regular traffic that has no specific data-related QoSneed,

2. reliability-sensitive traffic, which should be deliv-ered without loss but can tolerate reasonable delay,e.g., file transfer for long term data,

3. delay-sensitive traffic, which should be deliveredwithin a deadline but may tolerate reasonable packetloss, e.g., video streaming, and finally

4. critical traffic of high importance and requiring bothhigh reliability and short delay (delivery within adeadline), e.g., safety alarms in vehicular applica-tions, physiological parameters of a patient during asurgery, etc.

Following this classification, the proposed protocol isdesigned using a modular approach, aiming to ensureexactly the required QoS for each packet. A module isdevoted to each QoS requirement, in addition to the queuingmodule and neighbor manager. The queuing module isresponsible for implementing a priority multiqueuingstrategy that gives more priority, and it consequently ensuresshorter latency, to critical and delay-sensitive packets. Theneighbor manager runs the HELLO protocol that enablesexchanging information between neighboring nodes andimplements the link reliability and latency estimators. It uses

IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011 797

. D. Djenouri is with the Computer Engineering Department, CERISTResearch Center, Rue des Trois Freres Aissou, Ben-Aknoun, Algiers 16030,Algeria. E-mail: [email protected].

. I. Balasingham is with the Interventional Center, Oslo UniversityHospital, University of Oslo, Intervensjonssenteret Rikshospitalet, 0027Oslo, Norway. E-mail: [email protected].

Manuscript received 9 Oct. 2009; revised 11 Mar. 2010; accepted 12 Aug.2010; published online 28 Oct. 2010.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TMC-2009-10-0415.Digital Object Identifier no. 10.1109/TMC.2010.212.

1536-1233/11/$26.00 � 2011 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS

lightweight estimators based on Exponential WeightedMoving Average (EWMA), which have small memoryfootprint and are suitable for WSN. These estimators enablethe other modules to locally select the most appropriateneighboring node among the available candidates offeringpositive advance toward the destination. Fig. 1 shows thesolution framework.

The rest of the paper is structured around the followingsections: Section 2 discusses the related work. Section 3 givesthe network model, notations, and assumptions. The solu-tion and its different modules are presented in Section 4.Section 5 presents a mathematical analysis of the solution,while Section 6 is devoted to performance evaluationthrough a comparative simulation study. Section 7 describesthe implementation on sensor motes and shows some resultsof the tests. Finally, Section 8 draws the conclusion.

2 RELATED WORK

Geographic or localized routing is a promising approach forWSN. It has the advantage of being scalable and efficientcompared to global information routing (reactive andproactive), notably in networks where nodes are stationaryor with low mobility. A common feature of all localizedrouting protocols is the use of localization information, toselect the next router among neighboring nodes that aregeographically closer to the destination. However, theselection strategy differs from one protocol to anotherdepending on the constraints to consider. In this paper, routeselection is based on QoS objectives. Many research effortshave been devoted to multiobjective QoS routing in WSNusing localization information, resulting in several routingprotocols. SPEED [1] attempts to route packets throughroutes that ensure a given fixed speed, and uses ExponentialWeighted Moving Average for link latency estimation. Theaim of this protocol is basically to reduce delay, but itprobabilistically chooses the node among the ones supposedto fulfill the required speed, which is energy efficient andbalances the network load. However, SPEED does notconsider reliability. The protocol proposed in this paper isdifferent from SPEED in many aspects. It considers reliabilityand uses dynamic speed that can be adjusted for each packetaccording to the required deadline for reception. It addressesenergy using a deterministic approach and balances the load

only among nodes estimated to offer the required QoS.MMSPEED [2] attempts to improve SPEED and definesmultispeed routing, where several routing layers—eachensuring a given speed—are used. Packets are associatedwith appropriate layers according to their required speed,and reliability is ensured through probabilistic multipathtoward a single sink, which may result in congestion at nodesnear the sink. To prevent such congestion, our protocol uses adifferent approach to address reliability, namely, single-pathmultiple sink, which will be described later. Moreover, linkreliability is considered in the routing metrics.

DARA [3] considers reliability, delay, and residual energyin the routing metric, and defines two kinds of packets:critical and noncritical packets. The same weighted metric isused for both types of packets, where the only difference isthat a set of candidates reached with a higher transmissionpower is considered to route critical packets. For delayestimation, the authors use queuing theory and suggest amethod that, in practice, needs huge amount of samplestorages. The proposed protocol differs from DARA withrespect to many aspects. First, in addition to residual energy,the transmission energy is also considered. The protocol alsomakes a more comprehensive traffic differentiation anddefines several categories according to the QoS requirementinstead of using only two classes. Furthermore, it uses amodular approach with different metrics for each categoryinstead of a single weighted metric. This enables customizedand dynamic QoS provision according to the packet type.Finally, it uses the memory-efficient EWMA for link anddelay estimation and considers both queuing time and trans-mission delay, whereas DARA only considers queuing time.

Residual energy, reliability, and geographic advance areused in [4]. However, the authors consider the use ofharvesting energy for estimating residual energy of neigh-boring nodes, assuming environmentally powered sensors.We do not consider such kind of power and assume that theonly available power is through batteries. Chipara et al. [5]did not consider residual energy and reliability, but they tookinto account delay and required transmission power in theirlocalized QoS routing. For delay estimation, they usedJacobson’s algorithm that has the advantage of consideringboth average and variation of samples, but like [3], it requirespast observations that are stored [6]. Mahapatra et al. [7] useonly last observations to estimate latency in their QoS routingprotocol that combines delay and residual energy in aweighted routing metric. Some other localized routingprotocols such as [8], [9], [10], [11], [12], [13] deal only withenergy efficiency, and most of them combine residual energyand transmission power in a weighted routing metric.

All the protocols proposed thus far do not make a cleardifferentiation in route selection between traffic with respectto QoS requirements. They define either the same combinedmetric (of all the considered QoS metrics), or several servicesbut with respect to only one metric. Our main contribution isthe design of a routing protocol enabling to provide differentQoS services regarding latency, reliability, and energy alltogether according to the traffic type. The proposed protocolis the first that makes such differentiation and considers allthe above mentioned QoS metrics.

3 NETWORK MODEL AND ASSUMPTIONS

We assume that nodes are aware of their positions, eitherthrough an internal global positioning system (GPS) device

798 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011

Fig. 1. Solution framework.

or a separate distributed localization service [14]. Each nodevi is supposed to be aware of its current battery state Bvi

(also termed residual energy). This can be obtained at anytime from the current voltage and the discharge curve thatfeatures the battery [4]. We assume that nodes have thesame transmission power range, Prange, and that each nodecan control its transmission power. The set of nodes in vi’svicinity denoted by, Nvi , consists of vi’s neighboring nodes,defined by Nvi ¼ fvj : distvi;vj � Prangeg, where distvi;vj is theeuclidean distance between nodes, vi and vj. In additionto Nvi ;N

advcvi;vd

is defined as the set of neighboring nodesproviding positive advance for node, vi, toward finaldestination, vd. It consists of neighboring nodes that arecloser to the destination than vi. That is, Nadvc

vi;vd¼ fvj 2 Nvi :

distvj;vd � distvi;vdg. Like all geographic routing protocols,each node needs to know its neighboring nodes and theircurrent parameters, e.g., position, battery state, etc. This canbe ensured via the execution of a HELLO protocol such asin [1], [2], [4], [7], [8], [15].

For localized routing to be effective, nodes are supposed tobe either stationary or having low mobility. Otherwise,positions will change very frequently, and a high frequencyof HELLO packets exchange will be needed to keep the nodeup-to-date about the neighboring nodes, which is resourceconsuming. The proposed protocol does not deal with voidsituation. We say there is a void situation between two non-neighboring nodes in the particular case where there is nonode in the network closer to one of them than the other.Node density is supposed to be high enough to prevent suchsituation. The target WSN application where the protocolmay be used should gather different traffic with different QoSrequirements. The proposed solution would not be effectivein WSN of homogeneous traffic such as automatic irrigationin agriculture. Without loss of generality, two sinks acting asprimary and secondary sinks are supposed to be used andlocated at geographically divergent positions. It is possible toextend the model to use multiple sinks and associate eachsensor node with two geographically divergent sinks.

To transmit one bit from a source to a destination over adistance, d, the total consumed energy (by both nodes) isgiven as [9]

E ¼ 2Eelec þ �d�; ð1Þ

where Eelec is the energy utilized by transceiver electronic,which is independent of the distance. �d� accounts for theradiated power necessary to transmit over distance d, where� is the path loss (2 � � � 5) and � is a constant given inJoule=ðbits�m�Þ. Equation (1) is for unicast packets. Forbroadcasting messages from a given node, vi, the energycan be written as

E ¼ ðkNðviÞk þ 1ÞEelec þ �d�; ð2Þ

where kNðviÞk denotes the number of vi’s neighboringnodes, and d is the distance traversed by the packet (usuallyset to the power rang for broadcast packets).

4 PROTOCOL OVERVIEW

4.1 Neighbor Manager

This module is the first that receives packets from the higherand the lower layers. It is responsible for executing the

HELLO protocol, managing neighbor table, implementingestimation methods, running the other modules, and provid-ing them with the required information according to thepacket type. It uses a neighbor table that assigns an entry foreach neighboring node, which includes all the informationrelated to the node such as its position, residual energy,estimated waiting time for each queue, estimated transmis-sion delay, required transmission energy toward it, andestimated packet delivery ratio. The three latter parametersare estimated by the neighbor manager, while the others areestimated by the neighboring nodes themselves using theirown neighbor managers. They are updated upon eachreception of a HELLO packet. Periodically, or upon observingsignificant change in some parameters, each node broadcastsa HELLO packet including its current position, residualenergy, and its estimation of the other local parameters.Obviously, high frequency (short period) of HELLO packetsexchange provides relevant and up-to-date information, but itwould become resource consuming. This means it is requiredthat this period should be carefully selected to maintainproper balance between information freshness and cost.

Neighboring nodes use HELLO packets to updateexisting entries, add new entries when new nodes movewithin the node’s vicinity, and delete entries when neighbor-ing nodes move away or break down, which can be detectedin case of not receiving HELLO packets after a definedperiod of time (timeout). The HELLO protocol implementedby this module is not much different from state-of-the artlocalized routing, such as [2], [7], [4], [8], [15], [1]. It just addssome more estimation information to the exchanged packet,as mentioned above. In the following, the estimatorsimplemented by the neighbor manager are described.

4.1.1 Reliability Estimation

Exponential Weighted Moving Average [6] estimation ismore suitable for WSN compared to the other estimationmethods such as flip-flop estimator, Kalman filter, andlinear regression. These methods use statistically meaningfulmedian upon previous estimates’ variation, which is var-iance-calculation-based and requires important storageresources. EWMA has the advantage of being simple andless resource demanding compared to other methods [4],[15]. Still, it can react quickly to significant changes, whilebeing stable and less influenced by sporadic, large deviatedmeasurements. Window Mean Exponential Weighted Mov-ing Average (WMEWMA) is very similar to EWMA butupdates the estimated parameter in regular time intervalsinstead of doing it for every packet, which is appropriate forestimating link latency.

Algorithm 1 describes the WMEWMA-based link relia-bility estimation of the proposed protocol. prrvi;vj denotesthe packet reception ratio (PRR) of the link relaying node vito node vj. It indicates the probability of successful deliveryover the link (estimated link reliability). This parameter isupdated by vj at each time window, w, and inserted into theHELLO packet for usage by node, vi, in the next window.Therefore, the given algorithm is run by node, vj, and not,vi, contrary to the other algorithms given later. The timewindow is expressed in terms of number of packetstransmitted by node, vi. Upon receiving each packet, thenode updates the current window, cw, the number ofpackets received, r, as well as the number of known missedpackets, f , where packet:sc is the sequence number of the

DJENOURI AND BALASINGHAM: TRAFFIC-DIFFERENTIATION-BASED MODULAR QOS LOCALIZED ROUTING FOR WIRELESS SENSOR... 799

current received packet, and sp is the one of the lastreceived packet. At the end of time window, prrvi;vj isupdated as indicated in instruction 8, and parameters arereinitialized. a is a tunable parameter of the movingaverage. Appropriate values for a and w for a stableWMEWMA are w ¼ 30 and a ¼ 0:6 [6].

4.1.2 Latency Estimation

Algorithm 2 illustrates the estimation of parameters used bythe delay-sensitive module. As in [2], the EWMA approachis employed, but it is used for both transmission delay andqueuing delay. Each node, vi, estimates transmission delay,dtrvj , of outgoing link for each neighbor, vj, as well as itsqueuing delay, wvi , and broadcasts the latter in the HELLOpackets. Therefore, for vi, every wvj is obtained from vj. Itneeds to estimate wvi and dtrvj . We will show later thatseveral queues are used, i.e., critical packets and delay-sensitive packets are inserted in different queues. Therefore,each packets’ type has a separate estimation of wvi for thequeuing delay, say wvi ½packet:type�. This delay representsthe time between packet insertion into the queuing systemand when it becomes at the position of transmission.Instruction 6 of Algorithm 2 shows the EWMA update,where ! is the exact waiting time of the packet that can becalculated through a local time stamp. It represents asample for wvi estimation. The same approach is adapted forestimating dtrvj , (instructions 7 to 11 of Algorithm 2), wheret0 the time the packet is ready for transmission and becomesthe head of transmission queue, tACK the time of thereception of acknowledgment (ACK) packet, bw the band-width, and sizeðACKÞ the size of the ACK packet. This way,dtrvj includes estimation of the time interval from the packetthat becomes head of v0is transmission queue until itsreception at node, vj. This takes into account all delays dueto contention, such as channel sensing, channel reservation(RTS/CTS) if any (depending on the used medium accesscontrol (MAC) protocol), time slots, etc. Note that for agiven packet, computation complexity of both estimators isconstant (Oð1Þ).

4.2 Energy Module

This module is responsible for routing regular packets aswell as the other packets, when more than one candidatesatisfy the required QoS criteria. Both power transmissioncost and residual energy of routers should be considered toachieve power efficiency. A nonaggregated min-max ap-proach is used for this trade-off [16]. The problem is to selectat node, vi, the most power-efficient node for destination, vd,from the set of neighboring nodes offering positive advance,Nadvcvi;vd

. Considering (1), the cost that can be managed whenrouting is only the radiated power for transmission. That is,for every candidate node, vj, the required energy related torouting is given by �ðdistvi;vjÞ

�—called hereafter the trans-mission power. The other criterion is the battery state,Bvj , ofevery candidate node, vj.

Algorithm 3 describes the min-max approach of theenergy module. vT denotes the node that has the minimumtransmission power cost, which represents the optimumwith respect to the first criterion, while the secondcriterion’s optimum, denoted by vB, is the node havingthe highest amount of energy in its battery. For everycandidate, vj, its relative deviation for each metric’soptimum is calculated (instructions 1 to 3). Note thatbattery states, Bvj ; BvB , are always positive, contrary totransmission powers that may be less than 0, whichexplains the removal of max function from instruction 3(also note that Bvj < BvB8j). After that, the set, S0, of nodesminimizing the maximum deviation with respect to the twocriteria, is calculated as shown in instruction 4. If jS0jcontains merely one element, then obviously it is theselected optimum. Otherwise, instruction 8 indicates thecase where the metric, k, for which fZkðvjÞg in instruction 4reaches the maximum is not unique for all elements of S0,i.e., some nodes have maximum deviation in ZT and othersin ZB. Note that M½maxðÞ� stands for the metric for whichthe maximum is obtained. In this case, the node offering thebest advance from S0 will be selected. Otherwise, the finalsolution is the set of nodes from S0 that minimizes thedeviation for the metric other than l, where l represents themetric for which fZkðvjÞg reaches the maximum. Note thatthe computation complexity of this algorithm is linear. It isOðNadvc

vi;vdÞ, which is � OðNviÞ.

800 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011

4.3 Reliability Module

The reliability module is presented by Algorithm 4. First,reliability is addressed by sending a copy to both primaryand secondary sinks, respectively, denoted by PS and SS.This multisink single-path approach is selected instead ofthe single-sink multipath approach used in [2], whichresults in data packets convergence near or at the sink, andthus increases traffic contention and collisions [3]. For eachcopy, candidate offering the highest reliability, prr, isselected (instruction 3). prrvj is estimated by the neighbormanager as shown in Section 4.1.1. If several nodes have themaximum reliability, then the most energy efficient isselected using the energy module. Note that the computa-tion complexity of this algorithm is OðNviÞ.

4.4 Latency Module

Packet velocity approach given in [5] is used by thismodule. It has the advantage of not requiring anysynchronization between nodes as it uses relative times.The main difference between our approach and [5] is thatthe former uses a simple but memory and time-efficientestimation method instead of Jacobson’s algorithm. More-over, it considers queuing time at both the current and thenext hop, together with link latency. We suppose everydelay-sensitive packet has a delivery deadline, dd, specifiedby the upper layers. It indicates the time the packet shouldbe delivered to the final recipient.

We define two velocities (speeds); required velocity, sreq,and velocity offered by node, vj, denoted by, svj . Therequired velocity is proportional to the distance and thetime remaining to the deadline, rt. At each hop and prior toeach transmission at the MAC layer, the transmitter updatesthis parameter and puts it in the header as

rt ¼ rtrec � ðttr � trec þ size=bwÞ; ð3Þ

where trec represents the reception time, ttr the transmissiontime, bw the bandwidth, size the packet size, and rtrec theprevious value of rt (at time of reception). ttr � trec þsize=bw gives the whole delay from reception of the packetuntil transmission of the last bit. It includes both queuingdelay ðtrec � ttrÞ and data transfer delay ðsize=bwÞ. Uponreception of the packet, node vi uses the rt value updated atthe previous hop to calculate the required velocity, sreq, asillustrated in Algorithm 5. After that, it estimates thevelocity offered by neighboring nodes that provide positiveadvance, by taking into account waiting time at the queue ofnode vi, say wvi , transmission time, dtrvj , and waiting timeat the queue of the next hop, wvj . Remember that thewaiting time estimations depend on the packet type, andthere will be different wvj for each packet type ðpacket:typeÞ.After computing velocities of all candidate nodes, the delay-sensitive module calculates the set of nodes supposed to

meet the required deadline, Sdel, and calls the energymodule, or reliability module in case of critical packets. Thecalled module selects the most appropriate router from theset, Sdel, if it includes several nodes. Computation complex-ity of this algorithm is OðNviÞ.

4.5 Queuing Manager

To obtain low latency when routing critical and delay-sensitive packets, higher priority should be given to thesepackets in channel contention than the delay-insensitivepackets (regular and reliability-sensitive packets). Also,critical packets need higher priority than delay-sensitivepackets. This can be achieved through a multiqueue prioritypolicy, which is implemented by the queuing managermodule as described in Algorithm 6. We propose to use threequeues and send packets from the highest priority queue tothe lowest one. The highest priority queue, CQ, is used bycritical packets, the second highest priority queue, DSQ, isused by delay-sensitive packets, and the least priority queue,RQ, is used by regular and reliability-sensitive packets. Thenumber of critical and delay-sensitive packets is usually low,and there would be periods where their respective queuesare empty. Otherwise, lower priority traffic may beindefinitely blocked by higher priority traffic. In this case, atimeout policy for each packet is used to remove it to thehighest priority queue. This multiqueuing defines conten-tion priority locally, i.e., between packets from the samenode. It is possible to define priority for all traffic betweenneighboring nodes by modifying the MAC protocol slots andbackoff time [2]. Nevertheless, such a mechanism requiresimportant modifications in the MAC layer and may increasepacket collision in dense networks. Computation complexityof this algorithm is constant, i.e., Oð1Þ.

DJENOURI AND BALASINGHAM: TRAFFIC-DIFFERENTIATION-BASED MODULAR QOS LOCALIZED ROUTING FOR WIRELESS SENSOR... 801

5 ANALYSIS

5.1 Queuing Time

In this section, an analysis using queuing theory of waiting

time for the multiqueuing system presented in Section 4.5

is given. This waiting time will be used to draw upper and

lower bounds, respectively, of end-to-end packet delivery

probabilities and end-to-end delays. A general analysis

with n queues is provided, where n ¼ 3 in the proposed

solution. It would be straightforward to extend the solution

to define more priorities, even between packets of the same

category. The following analysis is general and directly

applies to any extension.At node l, assume packets arrival to each queue of

priority i, say Qli, follows a Poisson process of rate, �li. The

service time, which represents the packet transmission

delay, is unknown but can follow any general distribution.

It is, however, independent of the queue and thus

represented by a unique random variable for all queues,

say � . Also suppose that queues’ sizes are high enough to

hold all the arriving packets. The model is, thus, a queuing

system of type M=G=11 [17]. The waiting time of queue,

Qli, is denoted by, Wl

i , and the number of packets at each

queue, Qli, by NQl

i. Priority is decreasing with the queue

number, i.e., Ql1 has the highest priority and Ql

n the lowest

one. The following will be used in the analysis [17]:

. Littles’s formula.

E�NQl

i

�¼ �liE

�Wl

i

�: ð4Þ

. Server Utilization. The server utilization for packetsof priority i, say �li, is

�li ¼ �liE½� �: ð5Þ

To make sure that all packets will be served within a finite

delay it is assumed that,Pn

i¼1 �li < 1.

For a packet P arriving to the kth queue, the expected

waiting time,E½Wlk�, is the sum of: 1) the expected remaining

time of the current packet in service,E½R�, 2) the service time

of all packets in queues having a higher or the same priority,

i.e., packets in Qli; i � k, and 3) the service time of packets in

higher priority queues arriving during P ’s waiting time, i.e.,

after P but prior to its service. Formally speaking

E�Wl

k

�¼ E½R� þ

Xki¼1

E½NQli�E½� � þ

Xk�1

i¼1

E�Ml

i

�E½� �; ð6Þ

where Mli is the number of arriving packets to queue, Ql

i,

during the waiting time of P , given by

E½Mli � ¼ �liE½Wl

k�. Using the latter expression along with

(4) and (5), (6) becomes

E�Wl

k

�¼E½R� þ

Pk�1i¼1 �

liE�Wl

i

1�Pk

i¼1 �li

: ð7Þ

Lemma 1.

8k 2 f1; ::::; ng; 1þXki¼1

�li�1�

Pi�1j¼1 �

lj

��1�

Pij¼1 �

lj

¼ 1

1�Pk

j¼1 �lj

:

Proof. By recurrence on k, see the Appendix. tuLemma 2.

8k 2 f1; . . . ; ngE�Wl

k

�¼ E½R��

1�Pk�1

j¼1 �lj

��1�

Pkj¼1 �

lj

� :

Proof. By recurrence on k and using Lemma 1, see theAppendix. tuAccording to Leon-Garcia [17], E½R� can be expressed as

E½R� ¼ 1

2

Xni¼1

�liE½�2�; ð8Þ

where E½�2� in our case is the second moment of the servicetime of all packets given by

E½�2� ¼ V ar½� � þ E½� �2:

Finally, using (8) in Lemma 2, we derive the final

expression of E½Wlk� as

E�Wl

k

�¼ E½�2�

Pni¼1 �

li

2 1�Pk�1

j¼1 �lj

� �1�

Pkj¼1 �

lj

� � : ð9Þ

5.2 End-to-End Delay Upper Bound

Assume that the longest loop-free geographical2 route

separating a source and a sink is h hops. The end-to-end

delay is the sum of waiting times in queues and transmis-

sion times for all the hops from the source to the

destination. For a packet of priority k, the upper bound,

delayk, of the end-to-end delay can be given by

E½delayk� ¼Xhl¼1

�E½Wl

k� þ E½� ��:

Using (9), we obtain

E½delayk� ¼Xhl¼1

E½�2�Pn

i¼1 �li

2 1�Pk�1

j¼1 �lj

� �1�

Pkj¼1 �

lj

� �þ hE½� �:

If we note �i the maximum packet arrival rate for queue

of priority i, and �i the corresponding server utilization,

E½delayk� can be bounded by

E½delayk� �hE½�2�

Pni¼1 �i

2 1�Pk�1

j¼1 �j

� �1�

Pkj¼1 �j

� �þ hE½� �: ð10Þ

802 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011

1. Poisson arrival, general service, one server, no specification for thequeue size (1).

2. By a geographical route, we refer to a route constructed usinggeographical routing, in which the euclidian distance toward the destina-tion keeps decreasing from hop to hop.

Note that E½� � (the transmission time’s expected value)

greatly depends on the MAC protocol to be used. The

proposed protocol and techniques are general and inde-

pendent of the MAC protocol. Therefore, analyzing this

parameter is beyond the scope of this work. An example of

such analysis for CSMA/CA can be found in [18].

5.3 Reliability-Sensitive Packet Delivery LowerBound

The probability of successful delivery by the system is the

probability of successful delivery of at least one copy. Let us

denote each of the two events, successful delivery of each

copy, by e1 and e2, respectively, and the system successful

delivery by e. We have P ½e� ¼ P ½e1� þ P ½e2� � P ½e1je2�P ½e2�.Since e1 and e2 are independent events, P ½e1je2� ¼ P ½e1�,

thus

P ½e� ¼ P ½e1� þ P ½e2� � P ½e1�P ½e2�: ð11Þ

Both P ½e1� and P ½e2�, the lower bounds of, respectively,

P ½e1� and P ½e2�, or the probability of delivery when selecting

longest routes, can be given by

P ½e1� ¼ P ½e2� ¼Yhi¼1

E½prr� ¼ E½prr�h;

where E½prr� is the expectation of the packet delivery ratio,

or the probability of successful delivery, over a link. Using

this, (11) becomes

P ½e� ¼ 2P ½e1� � P ½e1�2 ¼ 2E½prr�h � E½prr�2h; ð12Þ

which is the lower bound of P ½e�. Note that for reliability-

unsensitive packets (regular and delay-sensitive packets),

the bound is trivially E½prr�h.

5.4 Computation and Communication Complexity

We have seen that the communication complexity for each

routing module of node vi is linear with Nvi . Moreover, if

we note Nvmax the maximum network density, i.e., the

maximum number of neighboring nodes in the network,

then the worst case complexity of each module becomes

�ðNvmaxÞ. Routing a packet is simply the sequential execution

of one or two modules, and therefore the overall complexity

is additive, which is still linear �ðNvmaxÞ. Like all localized

routing, the only communication overhead of the proposed

protocol is limited to the HELLO packet exchange, which

consists in periodic transmission by each node to its

neighbors. Its complexity is �ðnÞ transmission and

�ðnNvmaxÞ reception. This computation and communication

complexity is typical for localized protocols.

6 PERFORMANCE EVALUATION

6.1 Comparative Study

To evaluate the performance of the proposed protocol, wecarried out a simulation study using GloMoSim [19]. In thisstudy, the proposed protocol—called hereafter LOCalizedMultiobjectives Routing (LOCALMOR)—is compared withstate-of-the-art localized routing, namely, DARA [3], SPEED[1], MMSPEED [2], EAGFS [10], and a simple geographicalgreedy forwarding (GFW) [20]. The last protocol is not QoSprotocol. It was chosen as a benchmark representing basicgeographic routing, which indicates the improvementprovided by the other QoS protocols. Inevitably, energyefficiency of QoS protocols will be affected when data-related QoS requirement increases. A QoS protocol isenergy efficient if it is less affected and effectively respondsto the requirements by balancing data-related QoS andenergy efficiency. EAGFS considers only power efficiency.It is expected to achieve the maximum performance interms of energy balancing, and thus serves as a benchmarkof energy efficiency. All the other protocols are QoSprotocols. Protocols like in [4] have completely differentassumptions, e.g., environmental powered sensors, andtherefore are out of scope. Table 1 provides a qualitativecomparison among the QoS protocols involved in thesimulation study, where ETx and Eres, respectively, standsfor transmission and residual energy.

The simulation configuration consists of 900 nodeslocated in a 1;800 m2 area, and 1,000 s of simulation time.This high number of nodes permits to investigate scalabilityof the protocols. The nodes were uniformally distributed ina grid topology, with approximatively 100 m of powerrange, resulting in an average density of 8 (each node hasseven neighboring nodes, on average). Two sinks located atthe corners of the grid, i.e., (0,0) and (1,800, 1,800), wereused as the primary and secondary sinks, respectively.Traffic was generated from a node located in the center ofthe simulation area, which makes routes long and equaldistance toward both sinks. Constant bit rate (CBR) trafficwas used to generate traffic, with 1 kB/s in all scenarios.Some amendments have been made to CBR to includepacket type generation with stochastic distribution, follow-ing tunable rates for each type. Critical packets and regularpackets were used in the simulation. These two classesallow to test all the modules since both delay-sensitive andreliability-sensitive modules are employed to route criticalpackets. Moreover, it does not make sense to compare theprotocols in diverse QoS requirement scenarios. None of theadversaries makes a comprehensive traffic differentiationlike LOCALMOR, which would obviously outperform allthe protocols in this case. The next section separatelyinvestigates the performance of the protocol with each

DJENOURI AND BALASINGHAM: TRAFFIC-DIFFERENTIATION-BASED MODULAR QOS LOCALIZED ROUTING FOR WIRELESS SENSOR... 803

TABLE 1Qualitative Comparison

packet class. Critical packet rate was varied from 0.1 to 1,

where the performance metrics were measured. Note that

for each setting, the remaining rate to 1 represents regular

packet rate, and the overall traffic load was constant and

fixed to 1 kB/s in all scenarios. Table 2 summarizes the

simulation parameters. The performance metrics used are

the packet reception ratio (prr) of all packets and criticalpackets, the end-to-end delay (of all packets and criticalpacket), the ratio of packets arriving within the deadline,the standard deviation of the power consumption, and thenetwork lifetime. The deadline was fixed in this simulationto 0:3 s for all critical packets. The simulation resultspresented in this section were obtained after nine days ofruntime on two laptops. Each point of the plots is theaverage of nine measurements with a 95 percent ofconfidence interval.

Figs. 2a, 2b, 3a, 3b, and 4a show that LOCALMOR clearlyoutperforms all protocols with respect to the correspondingmetrics. In the second position, DARA shows goodperformance compared to other protocols. LOCALMORand DARA linearly increase their performance as a functionof critical packet rate, while all other protocols’ perfor-mances are relatively stable. For high critical packet rates,LOCALMOR halves the delay compared to the majority ofprotocols and provides 25 percent better performancecompared to DARA. It increases the packet reception ratioup to 13 percent compared to MMSPEED and to 20 percentcompared to SPEED. For high critical packet rates, DARA’spacket reception ratio is closer to that of LOCALMOR but it

804 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011

TABLE 2Simulation Parameters

Fig. 2. Packet reception ratio.

Fig. 3. End-to-end delay.

is still inferior. The difference becomes more important forlow rates and achieves 7 percent. The high reliability ofLOCALMOR and DARA is due to the use of efficientduplication toward different sinks, contrary to MMSPEEDthat uses a multipath single-sink strategy. This kind ofduplication results in packet congestion either at the finalsink or intermediate nodes. The other protocols do notconsider reliability as QoS metric. The linear increase of thepacket reception ratio for LOCALMOR and DARA with theincreasing critical packet rate can be explained by thesubsequent increase of duplications (applied only to criticalpackets). This means, the larger the number of criticalpackets we have, the more the packets are duplicated,which subsequently increases their reception ratio. On theother hand, low delays in both protocols are due to theconsideration of queuing waiting time. In addition to this,LOCALMOR considers transmission delay, which justifiesits superiority versus DARA. MMSPEED also considersqueuing and transmission delays, but on the other hand, theuse of multipath single-sink transmissions causes conges-tion and thus results in several retransmission of packetsbefore successful reception, which explains the relativelyhigher delay for MMSPEED. The linear decrease of the end-to-end delay for LOCALMOR and DARA (Fig. 3a) is due tothe same reason as of the packet reception ratio, i.e., packetsare routed through more delay-efficient link as the criticalpacket rate increases.

In Fig. 3b—depicting the end-to-end delay of criticalpackets versus critical packet rate—we notice a stable end-to-end delay for all protocols, which reflects the stability of theroutes selected for critical packets that are obviously notaffected by the critical packets rise. EAGFS balances thetraffic and shows the lowest battery deviation, as depicted inFig. 4b. This protocol considers only energy consumption,which explains its power efficiency but also low efficiencywith respect to the data-related QoS metrics (Figs. 2 and 3).SPEED also has low battery deviation, as it always selects thenext router randomly among the available candidates. Thisenables balancing the power consumption well. However, itdoes not make any distinction among packets and does not

consider reliability. This resulted in low performance withrespect to the other metrics.

LOCALMOR ensures a trade-off between traffic relatedQoS metrics and energy. For low and average rates ofcritical packets, it has the lowest battery deviation likeEAGFS (Fig. 4b). Then, its energy deviation smoothlyincreases as rates become higher, but it is still better thanthe majority of QoS protocols. This gradual rise is due to thedecrease of possible choices. LOCALMOR balances the loadonly among nodes estimated to ensure delivery within thedeadline and having the highest reliability. SPEED on theother hand uses a fixed traffic-unrelated speed and ignoresreliability. Therefore, as the number of critical packetsincreases, LOCALMOR inevitably balances packet amongfewer nodes than SPEED. Unlike the other metrics, DARAperforms poorly in terms of energy, as it does neither useany traffic balancing technique nor any probabilisticselection. This traffic balancing intuitively affects the net-work lifetime, defined as the time until the first node runsout of its battery.

The impact of traffic balancing on network lifetime isshown in Fig. 5, where protocols having low deviationsensure long lifetime and vice versa. In other words, protocols

DJENOURI AND BALASINGHAM: TRAFFIC-DIFFERENTIATION-BASED MODULAR QOS LOCALIZED ROUTING FOR WIRELESS SENSOR... 805

Fig. 4. (a) Delivery within deadline. (b) Power consumption standard deviation.

Fig. 5. Network lifetime (time to first battery drain).

ensuring stable traffic balancing (EAGFS, SPEED, etc.) havethe highest network lifetime and are unaffected by theincrease of critical packets. LOCALMOR has the highestlifetime along with EAGFS until 50 percent critical packetrate. After that, its lifetime smoothly decays but remainshigher than 600 s, which is higher than the majority of thecompared protocols. This decrease is due to the number ofnodes used to balance the traffic, which inevitably decreaseswith critical packet rate (that yields more QoS requirements).Note that LOCALMOR uses only nodes estimated to ensurethe required QoS, contrary to traffic-unrelated energy-efficient protocols (SPEED and EAGFS). In conclusion,LOCALMOR’s strategy was clearly demonstrated to beeffective in ensuring low latency and high reliability, whilealways considering the energy and balancing the load amongnodes providing the required QoS.

6.2 Traffic Differentiation Analysis

Traffic differentiation is the main feature that distinguishesthe proposed protocol. In the previous section, only criticaland regular packets were used, as none of the comparedprotocols considers the other classes (delay-sensitive andreliability-sensitive traffic). This section analyzes the trafficdifferentiation of the protocol. We use the same configura-tion as described previously. Nonetheless, this part of thestudy focuses on LOCALMOR and uses all types of traffic.

QoS traffic, including delay-sensitive, reliability-sensi-tive, and critical packets were varied in the same way ascritical packets were varied in the previous section, i.e., eachQoS traffic varies from 0.1 to 1 and the remaining rate is setto regular packets. Fig. 6 depicts the obtained results, wherethe x-axis represents the rate of QoS traffic (delay-sensitive,reliability-sensitive, and critical for each plot, respectively).The difference regarding the end-to-end delay (Fig. 6a)between the traffic sensitive to this metric (critical anddelay-sensitive packet) and the traffic unsensitive to it(regular-sensitive packets) is clear and becomes moreimportant as the QoS traffic rate increases.

The difference increases linearly until the end-to-enddelay of delay-sensitive and critical traffic almost becomeshalved compared to reliability-sensitive traffic. This increase

was expected due to large delay-sensitive and critical traffic,where packets are routed through more delay-efficientlinks, while with reliability-sensitive traffic, the protocolconsiders only link reliability. This explains the constantand relatively high end-to-delay for the reliability-sensitivetraffic. But it also justifies its superiority versus delay-sensitive traffic with respect to packet reception ratio asshown in Fig. 6b, since link reliability is not considered fordelay-sensitive traffic.

PRR of the traffic sensitive to the reliability (critical andreliability-sensitive classes) increases linearly with its rate,from 86 (87 percent for critical packets) to 98 percent,whereas it is stable for delay-sensitive packets at theinterval of 80 to 83 percent. This can be explained by thesame reasons as with the delay, i.e., more critical andreliability-sensitive traffic results in giving more considera-tion to link reliability, which is not considered for delay-sensitive traffic. Critical traffic is sensitive to both metrics,which explains the obtained high performance for thisclass. The small difference between critical traffic anddelay-sensitive traffic with regard to end-to-end delay(Fig. 6a) is due to the queuing priority that is higher forthe former. The difference is, however, little and does notexceed 19 ms. The difference of PRR between critical andreliability-sensitive traffic (Fig. 6b) is flipping but insignif-icant since it never exceeds 2 percent. This is because thereis no priority between the two classes with respect to thismetric. However, for the delay metric, the critical packetsare more prioritized.

7 IMPLEMENTATION ON SENSOR MOTES AND

EXPERIMENTATION

The proposed protocol was implemented and tested usingreal sensor motes. TelosB3 motes were used, along withContiki operating system [21]. TelosB (TPR2420) enablesUSB programming and data collection, and it includes anIEEE 802.15.4 radio (CC2420) with integrated antenna. It haslow power consumption and uses two AA batteries. The

806 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011

3. http://www.xbow.com.

Fig. 6. (a) End-to-end delay. (b) Packet reception ratio.

radio is a ZigBee compliant RF transceiver that operates inthe Industrial scientific and medical (ISM) band, at 2.4 to2.4834 GHz. TellosB’s microcontroller is an 8 MHz TIMSP430, with a 10 KB RAM and 1 MB of external flashmemory. All these features make TelosB an appropriateresearch platform suitable for our experiments. Contiki isthe first sensor and embedded systems platform thatsupports TCP/IP, which is important for real life deploy-ment in many applications. It facilitates the integration ofsensor networks with other existing network such asInternet. Contiki is written in C programming language,and uses the protothread programming paradigm that ismore natural and makes the coding of the protocol easiercompared to pure event-based systems [22]. It also includesa lightweight communication stack called RIME, providinga useful programming interface for communication proto-col implementation. The interface is composed of manymodules such as the multihop module used in thisimplementation. The size of the binary code of theimplementation was 24 KB. This includes code for routingprotocol, traffic generation module, the operating systemkernel, and libraries, all uploaded as a single file. Theprotocol code is a simplified implementation of all themodules except the queuing manager. Embedded systemslike Contiki implement packet transmission calls as non-blocking procedure, which prevents any queuing manage-ment implementation. Due to physical limitations of sensormotes and the difficulties in real deployment, it is extremelydifficult to perform as extensive evaluation as done in thesimulation study. The aim of this experiment is topractically investigate the feasibility of the protocol. Themotivation is neither to evaluate the scalability of theprotocol nor to compare it with other protocols, which wasalready carried out in the previous section.

An experimental network of 15 nodes was deployedwith one source and two sinks, where one acts as primaryand the other as secondary. Every sink was connected to alaptop computer through a USB port. To control thetopology on a small surface, we used the power controlmechanism provided by the CC2420 driver that enables31 discrete values (from 1 to 31). We fixed the maximumtransmission power to 2, resulting in a power range offew tens of centimeters (less than 1 m). As shown in Fig.7, the resulting network topology offers an acceptable

connectivity and has several multihop routes separatingthe source and the sinks, which is needed to test a routingprotocol. At the MAC layer, null-MAC was used toeliminate the effects of duty-cycling-related delay. Thesource node generated a 20 bytes packet each second andtransmitted it to the primary sink and possibly also to thesecondary sink. This depends on the packet type, decidedupon each transmission. 40 percent of the packets wereregular, 20 percent were delay-sensitive, 20 percent werereliability-sensitive, and 20 percent were critical. Serialport was used by each sink to construct log files, whichwere used for collecting the results.

The results are very encouraging and show that morethan 96 percent of packets were correctly delivered withreasonable delay. More importantly, they show that theprotocol’s traffic differentiation strategy provides differentQoS for the different packet types as depicted in Fig. 8.Fig. 8a shows the packet reception ratio of critical versusregular packets, while Fig. 8b shows the end-to-end delay ofdelay-sensitive versus regular packets. It becomes clear thatthe protocol ensures higher reliability and lower latency topackets requiring such performances than regular packets.In more complex scenarios, e.g., with more nodes, routes,etc., the route selection strategy (routing protocol) wouldhave a much more important impact on the performancemetrics, as shown in Section 6.

8 CONCLUSION

We have proposed a new localized routing protocol forwireless sensor networks. The proposed protocol takes intoaccount the traffic diversity, which is typical for manyapplications, and it provides a differentiation routing usingdifferent quality of service metrics. Data traffic has beenclassified into several categories according to the requiredQoS, where different routing metrics and techniques areused for each category. The protocol is built up around amodular design following the traffic classification. For eachpacket, it tends to ensure exactly the required QoS metricsin a power-aware way. It employs memory and computa-tion efficient estimators, and it uses a multisink single-pathapproach to increase the reliability. Energy has beenconsidered for all packets and achieved by selecting always

DJENOURI AND BALASINGHAM: TRAFFIC-DIFFERENTIATION-BASED MODULAR QOS LOCALIZED ROUTING FOR WIRELESS SENSOR... 807

Fig. 7. Experimental network topology.

the most power-efficient candidate among those offeringthe required data-related QoS (delay and/or reliability).The consideration and differentiation of both delay andreliability requirements distinguish the proposed protocolfrom the state-of-the-art protocols. The protocol usesmultiqueuing with priority, giving more priority and hencelower latency to critical and delay-sensitive packets. Thismultiqueuing may be implemented at the network layerwithout any modification at the lower layers, and overallthe protocol does not depend on a specific MAC protocoland requires only minor modifications at the MAC layer forcalculating estimates. It can operate with any protocol aslong as it employs an acknowledgment mechanism.Simulation results show that the proposed protocol outper-forms all compared state-of-the-art routing protocols byoffering the best QoS while considering energy. Moreover,it has been implemented and tested in a sensor networktestbed. The obtained results are very encouraging andshow that the protocol ensures good QoS and makes trafficdifferentiation based on QoS requirements. This makes theprotocol suitable for WSN with heterogeneous traffic, suchas medical and vehicular applications.

APPENDIX

Proof of Lemma 1. By recurrence on k:

1. for k ¼ 1: the equality can be checked by replace-ment in the two expressions.

2. Assume that the equality holds for k� 1, and tryto prove it for k.

1þXki¼1

�li

1�Pi�1

j¼1 �lj

� �1�

Pij¼1 �

lj

� �

¼ 1þXk�1

i¼1

�li

1�Pi�1

j¼1 �lj

� �1�

Pij¼1 �

lj

� �

þ �lk

1�Pk�1

j¼1 �lj

� �1�

Pkj¼1 �

lj

� �:

Using the recurrence hypothesis, we get

1þXki¼1

�li

1�Pi�1

j¼1 �lj

� �1�

Pij¼1 �

lj

� �

¼ 1

1�Pk�1

j¼1 �lj

þ �lk

1�Pk�1

j¼1 �lj

� �1�

Pkj¼1 �

lj

� �

¼1�

Pkj¼1 �

lj þ �lk

1�Pk�1

j¼1 �lj

� �1�

Pkj¼1 �

lj

� �

¼1�

Pk�1j¼1 �

lj

1�Pk�1

j¼1 �lj

� �1�

Pkj¼1 �

lj

� � ¼ 1

1�Pk

j¼1 �lj

:

ut

Proof of Lemma 2. By recurrence on k:

1. for k ¼ 1: by replacing in (7) and Lemma 2, wecan check that they produce the same expression.

2. Assume that the equality holds for k� 1, and tryto prove it for k.

Using the recurrence hypothesis, (7) gives

E½Wk� ¼E½R�

1�Pk�1

j¼1 �lj

1þXki¼1

�li

1�Pi�1

j¼1 �lj

� �1�

Pij¼1 �

lj

� �0@

1A:

Using Lemma 1, we get

E�Wl

k

�¼ E½R�

1�Pk�1

j¼1 �lj

� �1�

Pkj¼1 �

lj

� � :

ut

ACKNOWLEDGMENTS

This work was carried out at the Norwegian University of

Science and Technology (NTNU) as a part of the MELODY

808 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 10, NO. 6, JUNE 2011

Fig. 8. (a) Packet reception ratio. (b) End-to-end delay.

project funded by the Research Council of Norway, duringthe tenure of a postdoctoral fellowship from the EuropeanResearch Consortium for Informatics and Mathematics(ERCIM). The authors would like to thank the anonymousreviewers, as well as their colleague Raul Chavez-Santiago,for their valuable comments and suggestions, whichsignificantly helped to improve the quality of the manu-script. Djamel Djenouri thanks the CERIST research center,which is supported by the Algerian Ministry of HigherEducation and Scientific Research, for the facilities duringthe final steps of the work.

REFERENCES

[1] T. He, J.A. Stankovic, C. Lu, and T.F. Abdelzaher, “A Spatiotem-poral Communication Protocol for Wireless Sensor Networks,”IEEE Trans. Parallel and Distributed Systems, vol. 16, no. 10, pp. 995-1006, Oct. 2005.

[2] E. Felemban, C.-G. Lee, and E. Ekici, “MMSPEED: MultipathMulti-Speed Protocol for QoS Guarantee of Reliability andTimeliness in Wireless Sensor Networks,” IEEE Trans. MobileComputing, vol. 5, no. 6, pp. 738-754, June 2006.

[3] M.M. Or-Rashid, Md.A. Razzaque, M.M. Alam, and C.S.Hong, “Multi-Constrained QoS Geographic Routing for Het-erogeneous Traffic in Sensor Networks,” Inst. of Electronics,Information and Comm. Engineers Trans. Comm., vol. 91B, no. 8,pp. 2589-2601, 2010.

[4] K. Zeng, K. Ren, W. Lou, and P.J. Moran, “Energy Aware EfficientGeographic Routing in Lossy Wireless Sensor Networks withEnvironmental Energy Supply,” Wireless Networks, vol. 15, no. 1,pp. 39-51, 2009.

[5] O. Chipara, Z. He, G. Xing, Q. Chen, X. Wang, C. Lu, J. Stankovic,and T. Abdelzaher, “Real-Time Power-Aware Routing in SensorNetworks,” Proc. IEEE Int’l Workshop Quality of Service, 2006.

[6] A. Woo and D. Culler, “Evaluation of Efficient Link ReliabilityEstimators for Low-Power Wireless Networks,” technical report,Univ. of California, 2003.

[7] A. Mahapatra, K. Anand, and D.P. Agrawal, “QoS and EnergyAware Routing for Real-Time Traffic in Wireless Sensor Net-works,” Computer Comm., vol. 29, no. 4, pp. 437-445, 2006.

[8] X. Wu, B.J. d’Auriol, J. Cho, and S. Lee, “Optimal Routing inSensor Networks for In-Home Health Monitoring with Multi-Factor Considerations,” Proc. Sixth Ann. IEEE Int’l Conf. PervasiveComputing and Comm. (PERCOM ’08), pp. 720-725, 2008.

[9] T. Melodia, D. Pompili, and I.F. Akyildiz, “On the Interdepen-dence of Distributed Topology Control and Geographical Routingin Ad Hoc and Sensor Networks,” IEEE J. Selected Areas in Comm.,vol. 23, no. 3, pp. 520-532, Mar. 2005.

[10] T.L. Lim and M. Gurusamy, “Energy Aware GeographicalRouting and Topology Control to Improve Network Lifetime inWireless Sensor Networks,” Proc. IEEE Int’l Conf. BroadbandNetworks (BROADNETS ’05), pp. 829-831, 2005.

[11] S. Wu and K.S. Candan, “Power-Aware Single- and MultipathGeographic Routing in Sensor Networks,” Ad Hoc Networks, vol. 5,no. 7, pp. 974-997, 2007.

[12] J.-H. Chang and L. Tassiulas, “Maximum Lifetime Routing inWireless Sensor Networks,” IEEE/ACM Trans. Networking, vol. 12,no. 4, pp. 609-619, Aug. 2004.

[13] C.-p. Li, W.-j. Hsu, B. Krishnamachari, and A. Helmy, “A LocalMetric for Geographic Routing with Power Control in WirelessNetworks,” Proc. Second Ann. IEEE Conf. Sensor and Ad Hoc Comm.and Networks (SECON), pp. 229-239, Sept. 2005.

[14] T. He, C. Huang, B.M. Blum, J.A. Stankovic, and T.F. Abdelzaher,“Range-Free Localization and Its Impact on Large Scale SensorNetworks,” ACM Trans. Embedded Computer Systems, vol. 4, no. 4,pp. 877-906, 2005.

[15] T. Roosta, M. Menzo, and S. Sastry, “Probabilistic GeographicalRouting Protocol for Ad-Hoc and Sensor Networks,” Proc. Int’lWorkshop Wireless Ad-Hoc Networks (IWWAN), 2005.

[16] C.A. Coello, “An Updated Survey of GA-Based MultiobjectiveOptimization Techniques,” ACM Computing Surveys, vol. 32, no. 2,pp. 109-143, 2000.

[17] A. Leon-Garcia, Probability and Random Processes for ElectricalEngineering, second ed. Wesley, 1994.

[18] A.M.D. Athanasios Gkelias, V. Friderikos, and A.H. Aghvami,“Average Packet Delay of CSMA/CA with Finite User Popula-tion,” IEEE Comm. Letters, vol. 9, no. 3, pp. 273-275, Mar. 2005.

[19] X. Zeng, R. Bagrodia, and M. Gerla, “GloMoSim: A Library for theParallel Simulation of Large-Scale Wireless Networks,” Proc. 12thWorkshop Parallel and Distributed Simulation (PADS ’98), pp. 154-161, May 1998.

[20] B. Karp and H.T. Kung, “GPSR: Greedy Perimeter StatelessRouting for Wireless Networks,” Proc. ACM MobiCom, pp. 243-254, 2000.

[21] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki - A Lightweightand Flexible Operating System for Tiny Networked Sensors,”Proc. 29th Ann. IEEE Int’l Conf. Local Computer Networks (LCN ’04),pp. 455-462, 2004.

[22] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali, “Protothreads:Simplifying Event-Driven Programming of Memory-ConstrainedEmbedded Systems,” Proc. Fourth Int’l Conf. Embedded NetworkedSensor Systems (SenSys ’06), pp. 29-42, 2006.

Djamel Djenouri received the engineer, mas-ter’s, and PhD degrees in computer sciencefrom the University of Science and Technology(USTHB), Algiers, Algeria, in 2001, 2003, and2007, respectively. During his PhD studies, hevisited John Moors University in Liverpool,United Kingdom, where he carried out colla-borative work with researchers of the DistributedMultimedia Systems and security group. From2008 to 2009, he was granted a postdoctoral

fellowship from the European Research Consortium on Informatics andMathematics (ERCIM), and he worked at the Norwegian University ofScience and Technology (NTNU), in Trondheim, Norway, where heparticipated in the MELODY project supported by the NorwegianResearch Council. Currently, he is a permanent full-time researcher atthe CERIST research center in Algiers. His research focuses on ad hocand sensor networking, especially on the following topics: quality ofservice, security, power management, routing protocols, MAC protocols,fault tolerance, sensor and actuator networks, and vehicular applica-tions. He has participated in many international conferences andpublished more than 30 papers in international peer-reviewed journalsand conference proceedings. He is a member of the ACM and served asa TPC member and the chair of many international conferences andworkshops. He also served as a reviewer for many internationaljournals. In 2008, he was granted the Best Publication Award fromANDRU, supported by the Algerian government.

Ilangko Balasingham received the MSc andPhD degrees from the Department of Telecom-munications, the Norwegian University ofScience and Technology (NTNU), Trondheim,Norway, in 1993 and 1998, respectively, both insignal processing. He performed his master’sdegree thesis in the Department of Electrical andComputer Engineering, the University of Cali-fornia, Santa Barbara. From 1998 to 2002, heworked as a research scientist developing image

and video streaming solutions for mobile handheld devices at FastSearch & Transfer ASA, Oslo, Norway, which is now part of Microsoft,Inc. Since 2002, he has been with the Interventional Centre, OsloUniversity Hospital, Norway, as a research scientist, where he heads theWireless Sensor Network Research Group. He was appointed as anadjunct professor in signal processing in medical applications at NTNUin 2006. His research interests include super robust short rangecommunications for both in-body and on-body sensors, body areasensor networks, microwave short range sensing (noninvasive, remote,and continuous estimation of blood pressure), and short rangelocalization and tracking sensors, catheters, and micro robots.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.

DJENOURI AND BALASINGHAM: TRAFFIC-DIFFERENTIATION-BASED MODULAR QOS LOCALIZED ROUTING FOR WIRELESS SENSOR... 809