Ann. Telecommun. (2010) 65:777–794DOI 10.1007/s12243-010-0173-3

A load-aware energy-efficient and throughput-maximizedasynchronous duty cycle MAC for wireless sensor networks

Muhammad Mostafa Monowar ·Muhammad Mahbub Alam · Md. Obaidur Rahman ·Choong Seon Hong · Sungwon Lee

Received: 25 December 2009 / Accepted: 12 April 2010 / Published online: 7 May 2010© Institut Télécom and Springer-Verlag 2010

Abstract Being a pivotal resource, conservation of en-ergy has been considered as the most striking issue inthe wireless sensor network research. Several workshave been performed in the last years to devise dutycycle based MAC protocols which optimize energyconservation emphasizing low traffic load scenario. Incontrast, considering the high traffic situation, anotherresearch trend has been continuing to optimize bothenergy efficiency and channel utilization employingrate and congestion control at the MAC layer. Inthis paper, we propose A Load-aware Energy-efficientand Throughput-maximized Asynchronous Duty CycleMAC (LET-MAC) protocol for wireless sensor net-works to provide an integrated solution at the MAClayer considering both the low-and high-traffic sce-nario. Through extensive simulation using ns-2, wehave evaluated the performance of LET-MAC. LET-MAC achieves significant energy conservation duringlow traffic load (i.e., no event), compared to the priorasynchronous protocol, RI-MAC, as well as attainsoptimal throughput through maximizing the channel

M. M. Monowar · M. M. Alam · Md. O. Rahman ·C. S. Hong (B) · S. LeeComputer Engineering Department, Kyung Hee University,Seoul, South Koreae-mail: cshong@khu.ac.kr

M. M. Monoware-mail: monowar@ieee.org, hemal.cu@gmail.com

M. M. Alame-mail: mahbub@networking.khu.ac.kr

Md. O. Rahmane-mail: mdobaidurrahman@gmail.com

S. Leee-mail: drsungwon@khu.ac.kr

utilization and maintains lower delay in regard to theCSMA/CA-like protocol during a high volume of traffic(i.e., when an event occurs).

Keywords Wireless sensor networks ·Energy conservation · MAC protocol

1 Introduction

The Prodigious proliferation of Micro-Electro-Mechanical Systems (MEMS), [1] as well as wide adop-tion of wireless networking technologies, has created agreat opportunity for wide spread utilization of variousinnovative sensor network applications in the foresee-able future. The growing demand of these applicationsalso necessitates designing effective communicationprotocols for Wireless Sensor Networks (WSNs).However, designing such protocols faces various chal-lenges due to the resource constraints of WSNs; moreimportantly, energy constraint and bandwidth con-straint. Therefore, along with higher energy efficiency,a protocol also needs to achieve higher throughput,utilizing the maximum channel capacity.

A broad range of remote sensing applications (struc-tural and habitat monitoring, fire detection, targetrecognition and tracking) necessitate WSNs to operatein a dormant state (i.e., absence of event) for a longperiod of time and in crisis state for short periods (i.e.,occurrence of event) [2]. During the dormant period,nodes generate data at a lower rate (i.e., heartbeatmessages), while, in crisis state, nodes report the eventat a higher rate.

Considering energy as the most crucial resource,several duty cycle-based MAC protocols have been

778 Ann. Telecommun. (2010) 65:777–794

proposed [3, 4], aiming to maximize the energy con-servation. These protocols focus on reducing the idlelistening (unnecessarily turning on the radio while notransmission/reception is going on) as much as possiblethrough keeping the nodes asleep periodically, duringthe long dormant period. However, these studies over-looked the consequences of the high rate event trafficwithin the limited channel capacity. In contrast, thereexist a number of works in the literature, which aim tohandle the high rate event traffic adopting both the rateand congestion control in the MAC layer [5–8]. Theseworks try to avoid the packet losses at high traffic, andoptimize both the energy consumption and channel uti-lization. As a result, most of the existing works addressthe design of the MAC layer for energy-conserving lowtraffic, and throughput maximizing high-traffic situa-tions separately. However, because a single applicationrequires support for both these traffic situations, atraffic-aware integrated solution is, therefore, requiredat the MAC layer, which to the best of our knowledge,remains un-addressed.

In this paper, we focus to design a MAC protocolthat, on one hand, maximizes the energy conservationat low traffic, and, on the other hand, maximizes thenetwork throughput at high traffic with minimum possi-ble energy consumption. The design of such a protocol,however, needs to handle two conflicting goals: i) max-imizing the sleeping time of a node to increase the dutycycle, which might keep the channel idle, and ii) max-imizing the channel utilization to increase the networkcapacity, and to support high data rates reducing thesleeping time. Furthermore, we aim to adapt the duty-cycling at high traffic along with avoiding the packetloss to achieve high-energy efficiency. Therefore, itis necessary to balance the energy conservation andnetwork throughput based on the observed networktraffic condition.

Existing duty-cycle based MAC protocols can becategorized as synchronous and asynchronous proto-cols based on their wake-up schedule for communi-cation. Synchronous protocols [9–12] incur high costfor synchronization and maintain fixed wake-up inter-vals for communications. Asynchronous protocols [13–15] usually avoid this cost by employing a preamble-based transmission approach. Because the synchronousprotocols allow the nodes to wake up simultaneously(and an increased collision rate at high traffic), andmost of the asynchronous protocols use a long pream-ble (and hence, unnecessarily keep the medium busy),they usually achieve a very low medium utilization.Therefore, these protocols are not suitable to handle ahigh traffic situation. However, a recent work proposesa receiver-initiated duty-cycle MAC to minimize the

control overhead on medium occupancy [16]. This workhas motivated us to extend the duty cycle-based MACfor gaining higher throughput. Moreover, fairness isone of the core problems that need to be handled at theMAC layer during a crisis state. More specifically, here,we focus on attaining fair throughput among the nodesduring a crisis state so that the sink can get unbiasedinformation about the monitored area.

This paper introduces LET-MAC, a novel MAC pro-tocol which integrates the objective of the duty-cycleMAC with MAC-based rate control protocols usinga unified mechanism. Handling both the situationsusing a single mechanism has paid exiguous attentionso far. We devise a receiver-driven medium accessmechanism which provides higher energy efficiency,high medium utilization, and reduces the control over-head. We introduce a novel bi-directional rate controlmechanism with the aim of achieving optimal perfor-mance considering the traffic situation, which, in onedirection, controls the beacon-sending rate of a nodebased on the upstream node’s request, and, in anotherdirection, controls this rate along with reporting rateof the sources based on the contention and congestionsituation observed around the node itself. Moreover,we perform extensive simulations using ns-2 to evaluatethe performance of LET-MAC.

The remainder of the paper is organized, as follows:Section 2 summarizes the related works. Some prelim-inaries and design goals of LET-MAC are stated inSection 3. The detailed design of LET-MAC is pre-sented in Section 4. Section 5 demonstrates the perfor-mance of our protocol, evaluated using ns2, and finally,in Section 6, we present our concluding remarks.

2 Related work

Energy-efficient duty cycle MAC protocols have beena very prominent research area in wireless sensor net-works. Among the asynchronous protocols, B-MAC[13], developed at University of California, Berkley,is a contention-based CSMA like-approach which ex-ploits Low Power Listening (LPL) and an extendedpreamble for energy-efficient communication. Nodesmaintain a fixed periodic wake-up schedule to checkfor channel activity. If any activity is detected duringchannel sampling, it powers up and receives the data.The sender, on the other hand, sends a long preamblewhich lasts longer than the receiver’s wake-up inter-val to ensure the reception of data by the receiver.B-MAC exhibits higher energy efficiency in low-trafficloads, since, after each wake-up, it performs very shortchannel activity checking. However, it suffers from an

Ann. Telecommun. (2010) 65:777–794 779

overhearing problem and shows higher latency due tothe long preamble transmission.

X-MAC [14], is the optimized version of B-MACthat overcomes the overhearing problem with the in-troduction of short-strobed preambles and inclusionof the target receiver address in the preamble. Thisfacilitates the reply of early acknowledgement to thesender, and, thereby conserves energy with reducedper-hop latency. Yet, at each wake-up, every node hasto perform long clear channel assessment (CCA) checkin LPL, (longer than the ACK waiting period), whichcauses energy wastage if no data is available at thesender. Moreover, X-MAC also occupies the channelfor a long time with preamble transmission.

BoostMAC [15] is another optimized version ofB-MAC that provides an adjustable interface toachieve ultra-low power operation. Considering Habi-tat monitoring as the motivating application, Boost-MAC adapts with the changing traffic load throughadjustment of two parameters, polling interval andpreamble length. The polling interval adjustment isbased on selecting some predetermined polling timevalues stored in an array using Additive increase Mul-tiplicative decrease (AIMD) techniques rather thancomputing the actual channel polling times. It exploitsmachine learning to dynamically adjust the preamblelength. Despite the efforts in adapting with the trafficload, BoostMAC fails to achieve high channel uti-lization due to employing preamble based approach.Moreover, it does not consider the consequences ofhigh traffic situation, and lacks the functionalities suchas rate control, congestion control, without which themaximum sustainable throughput cannot be achievedduring high traffic situation.

RI-MAC [16] handles the problems of long channeloccupancy by the senders observed in B-MAC andX-MAC, introducing receiver-initiated transmission inwhich data transmission is initiated through a beacontransmission by the receiver. RI-MAC achieves betterenergy efficiency, delivery ratio, and lower latency,compared to X-MAC. However, like the prior asyn-chronous protocols, RI-MAC also shows non-adaptivebehavior in maintaining the wake-up interval, and thechannel utilization of RI-MAC during extreme condi-tions is still unknown which we have addressed whiledesigning LET-MAC.

PTIP [17] and Koala [18] also use the receiver-initiated transmission for WSN; however, the formerone is designed for infrastructure-based wireless sensornetworks, and the latter one uses this concept usingthe gateway node to wake up the sensor nodes fordownloading bulk data instead of actual data transfer.Besides WSN, the receiver-initiated MAC concept was

proposed by Garcia-Luna-Aceves et al. [19] for generalwireless networks in which collision handling had beengiven foremost importance above energy efficiency.

Synchronous approaches, such as S-MAC [9], T-MAC [20], R-MAC [10], DW-MAC [12], and also hy-brid approaches, like SCP-MAC [21], maintain a fixedwake-up interval for communication, and require stricttime synchronization among the nodes to perform syn-chronous wake-up and sleep. Communication is per-formed during the short active period of an operationalcycle, reducing the idle listening problem. However, themaintenance of synchronization among the nodes is adrawback in terms of overhead and supporting networkscalability. Therefore, due to the simplicity and scalablefeature, asynchronous approaches are particularly at-tractive in the context of WSNs.

The current literature regarding the congestion/ratecontrol protocol for WSNs reduces the energy wastagecaused by packet drops by imposing a sustainablerate to the sources and utilizing the maximum chan-nel capacity. Due to the dependency of MAC layerinformation for congestion control, MAC-based dis-tributed congestion control protocols are developedsuch as CODA [6], FUSION [22], IFRC [5], CCF [8],and, PCCP [7] and are more effective in the wire-less sensor network environment. Nonetheless, theseprotocols are developed based on the CSMA/CA-like“Always on” MAC protocol. The effect of duty-cyclingon congestion/rate control in the crisis state has notbeen considered in those protocols, which could be aserious problem in detecting and handling congestiondue to the sleep schedule maintenance in that situation.Therefore, LET-MAC integrates this functionality forgaining higher network efficiency, along with providingduty-cycling.

3 Preliminaries and design goals

We have studied the channel utilization of duty cy-cle MAC, in comparison with full-active CSMA/CAthrough performing a simulation. The general simu-lation setup is explained in Section 5. Unless oth-erwise mentioned, we consider a multi-hop networkthroughout the paper where some nodes act as sources(which generate data), some act as forwarding nodes(forward other node’s data) and some play both roles,and the nodes forward data to the sink. Twenty nodesare chosen from the margin as sources, and per nodeaverage goodput is measured varying the data rate ofthe sources. The per node average goodput is definedas the average number of successful packet receptionper second by the sink from each source node. In this

780 Ann. Telecommun. (2010) 65:777–794

study, as a synchronous MAC, we choose S-MAC withadaptive listening, and X-MAC and RI-MAC are cho-sen as asynchronous protocols, where the former usesa preamble-based, and the latter employs a receiver-initiated mechanism. As the Fig. 1 shows, full-activeCSMA/CA achieved the maximum per node goodput,which is 2.2 pps. RI-MAC achieved the second-bestper node goodput (1 pps), which is around 54% lessthan CSMA/CA. X-MAC obtained the lowest averagegoodput (0.05 pps), whereas S-MAC achieved goodputin between RI-MAC and X-MAC (0.75 pps).

The study gives the following observations:

– Preamble based asynchronous approach saturatesthe network for a long duration of preamble trans-mission, which not only increases the mediumaccess delay but also increases collision loss andcongestion loss during a high traffic load.

– As the offered load increases, synchronous-basedapproaches suffer from huge contention andthereby collision losses due to synchronous wake-up by the nodes. The small active period formaintaining a higher duty cycle exacerbates thecontention situation during the high traffic rate,resulting in lower goodput.

– A receiver-initiated asynchronous approach showsbetter performance than the other two during hightraffic load due to the avoidance of unnecessarychannel occupancy and provision of back-to-backdata transmission; however, the achievable good-put is still far from full-active CSMA/CA. Thereason is that, during high traffic, a huge numberof beacon and data packet collisions occur, whichforces the receiver to go into the sleep state. More-over, the long sleep interval, irrespective of the

Fig. 1 Average goodput vs offered load

traffic situation, builds up the congestion at thesender side.

The observations direct us to reach the followingconclusion:

In comparison with the existing duty cycle MAC pro-tocols, the receiver-initiated asynchronous approachcould be the better choice to achieve higher through-put. However, the lower utilization of the channelcapacity of this approach, as compared to full-activeCSMA/CA in a crisis state necessitates a mechanismwhich will reduce the collision, avoid the congestion, aswell as perform adaptive rate control along with dutycycle adjustment to achieve near optimal throughputwhile keeping the nodes in sleep as much as possible.

Nonetheless, adopting any existing rate control pro-tocol on the top of RI-MAC also will not work; sincethese protocols are designed based on the full-activeCSMA/CA-like protocols and could detect false con-gestion and perform unnecessary rate control, keepingthe channel capacity underutilized due to the sleepschedule maintenance by the receiver, while data isavailable to the sender.

Furthermore, the existing duty cycle protocols (syn-chronous or asynchronous) do not maintain their dutycycle based on the availability of traffic, which causeunnecessary wake up and energy wastage. Hence, theoverall design goals of LET-MAC are:

1. Energy Ef f iciency. Our primary goal is to achievesignificant improvement in energy savings duringvery low traffic load, compared to the current dutycycle protocols, as well as to reduce the energydissipation, avoiding packet drops at high trafficload.

2. Application Fidelity Enhancement. Our second goalis to boost the application fidelity while it is re-quired at the time of event occurrence and nodesgenerate data at a high rate. This situation demandsto attain a certain delivery ratio, higher throughput,and lower latency.

3. Network Ef f iciency. Another major goal of LET-MAC is to run the network at an efficient operatingpoint. More specifically, we intend to avoid thecongestion collapse, as well as reduce the collisionlosses, keeping the rate as high as possible duringthe crisis state through efficient rate control.

4. Robustness. We further wish LET MAC to be ro-bust to routing dynamics and nodes joining andleaving the network. Thus, in addition to eventoccurrence, traffic load also could vary due to theroute change as well as node location change. Ourproposed protocol aims to adapt these changesdynamically.

Ann. Telecommun. (2010) 65:777–794 781

4 Design of LET- MAC

To achieve the design goals, we devise several mech-anisms of LET-MAC as discussed in the subsequentsections.

4.1 Receiver-driven medium access

We adopt the receiver-driven mechanism for mediumaccess, as proposed in RI-MAC. However, the pro-posed medium access mechanism differs, in particular,in terms of packet reception, apposite sleeping time de-termination, number of control packets disseminated,as well as in back-off strategy. To efficiently portraythe mechanism we describe it according to the role thenodes play either as a receiver or a sender. The mediumaccess mechanism is portrayed in Fig. 2.

Receiver’s Operation Each node periodically wakesup according to its own wake-up interval to receivepackets from the upstream nodes. After turning onthe radio, a node broadcasts a beacon (referred asa primary beacon), after performing a short backoff(BOb ), followed by a CCA check, to avoid the collisionfrom simultaneous beacon packet transmissions by theneighboring nodes. It then waits to receive packetsfrom any of its upstream senders until a time-out (TO)occurs. The receiver goes to sleep if it detects the chan-nel busy during beacon transmission or detects collisionduring waiting for packets or no packets arrived afterTO occurs. If a node finds the channel busy for aconsecutive number of times, it might shift its wake-uptime to avoid the ongoing transmission, which coincideswith the wake-up time of that node.

We opt for multiple-packet reception at each recep-tion round (which starts after transmitting the beacon)for high-medium utilization. The number of allowablepackets received for a reception round is denoted asNr. The receiver embeds this value into the beaconpacket. The successful reception of the packets froma particular sender is acknowledged through anotherbeacon, denoted as ACK-Beacon, which acts as a blockacknowledgement. However, if the receiver receivesfewer number of packets than the specified value,then it updates the remaining number of packets tobe received in the ACK-Beacon packet, which invitesother potential senders having data to send packets toutilize that reception round. Thus, the ACK-Beaconserves two purposes; first, it acts as an acknowledge-ment (block-ack), and second, it solicits data packetsto utilize the reception round. A receiver goes to sleepafter full utilization of the reception round.

Sender 1

Receiver

Sender 2

LPLSleep

Sleep

Sleep

LPL

Beacon

Data ArrivesWake Up to

send

Beacon

Beacon

Data

Data Data Data

SIFS

SIFS

SIFS

SIFS

SIFS

Beacon

Beacon

Wake Up toreceive

DH

tg

tg

SIFS

TX RX LPL

TO

DH Data Packet Header

Data Backoff Beacon Backoff

Sleep

Sleep

Sleep

Data Data

(a) The value of Nr is set as 3 as for example. Sender 2 wins the channel and utilizes the reception round of the receiver fully. Sender 1 goes to sleep after overhearing the first packet header of Sender 2.

Sender 1

Receiver

Sender 2

LPLSleep

Sleep

Sleep

LPL

Beacon

Data ArrivesWake Up to

send

Beacon

Beacon

Data

Data

Data

Data

Data

Data

SIFS

SIFS

SIFS

SIFS

SIFS

Beacon

Beacon

Wake Up toreceive

tg

tg

Sleep

Beacon

Beacon

SIFS

Beacon

tg

DH

TO TO

Sleep

Sleep

Sleep

(b) The value of Nr is set as 3 as for example. Sender 2 is the wining node but having only 2 packets in the queue. Sender 1 goes to sleep after overhearing the first packet header and again wakes up with a guard time. It sends the remaining number of packet in that reception round and goes to sleep again. Besides, sender 2 goes to sleep just after finishing its transmission.

Fig. 2 Medium access mechanism

Sender’s Operation A node having data in the queuefunctions as a sender. Every sender is aware of itsreceiver’s wake-up schedule. After waking up at thattime, a sender waits in LPL for a receiver’s beacon.Upon detecting the beacon preamble it powers up andreceives the entire beacon packet.

A receiver i appends the remaining duration untilits next wake-up, ti

r, in the primary beacon or ACK-Beacon to inform the upstream senders its wake-upschedule. It is calculated as- ti

r = diw − (

tib − ti

w

); where,

diw is the wake-up interval of node i, ti

b is the time whenthe primary beacon or ACK-Beacon has been sent, andtiw is the wake-up time of the node i, and ti

b − tiw denotes

an interval. Using the value, tir, a sender, j, determines

its wake-up schedule for sending data, t jw(send) as-

t jw(send) = t j

curr + (tir − tg

)(1)

782 Ann. Telecommun. (2010) 65:777–794

where, t jcurr is the current time at sender j, tg is the guard

time for clock drift and is measured as- tg = 2 × Rdrif t ×tir and, Rdrif t is the maximum clock drift rate.

Notably, if a sender misses the sending operationin its pre-scheduled sending time due to the receiver’sbeacon failure or collision or if it is a joining node,it continues waiting in LPL for the receiver’s beaconinstead of sleeping.

Upon beacon reception, the senders start their ran-dom back-off (BOd) within a fixed contention win-dow. Based on the current queue size, qcurr, and theith receiver’s requisition, Ni

r, a wining node, j in thecontention sends N j

s number of packets with a gapof Short Interframe Space (SIFS) between successivepackets according to-

N js =

⎧⎨

⎩

qcurr, i fqcurr ≤ Nir

Nir, otherwise.

The wining node goes to sleep immediately after receiv-ing the ACK-Beacon. In contrast, the losing nodes willbe in the sleep state if they find N j

s = Nir through over-

hearing the first data packet header (which containsN j

s ). However, for the case, N js < Ni

r, the losing nodesremain awake instead of sleeping if N j

s < threshold,to reduce the energy cost caused by frequent turningon/off the radio. We set the threshold as 2. If N j

s ≥threshold, then the losing nodes go to sleep. They wakeup again just before the ACK-Beacon reception time(intended for the wining sender), with a guard time tg,and wait for it in LPL. The nodes can easily estimate thesleeping duration before ACK-Beacon comes through,overhearing the value, N j

s , from the packet header.In every case, whenever a node looses the channel, itfreezes its backoff to gain higher priority in accessingthe channel for the next contention, which addressesthe fair access of the medium.

4.2 Bi-directional rate control

The major challenges of LET-MAC is to obtain themaximal energy savings during the idle period of thesensors and achieve the near optimal throughput duringcrisis state with minimum energy wastage. We addressthese challenges through introducing a novel rate con-trol mechanism, referred to as bi-directional rate con-trol (BRC), which is a combination of the following twomechanisms;

– Forward Rate Control(FRC). The beacon sendingrate of the downstream node is controlled accord-ing to the request by the upstream nodes.

– Backward Rate Enforcement(BRE). The down-stream node enforces reduction in the forwardingrate of the upstream nodes, as well as creates back-pressure for source rate reduction.

Since, in our proposed receiver driven medium accessmechanism, a node broadcasts its primary beacon af-ter wake up at a particular interval, hence controllingthe wake-up interval is analogous to the control of itsbeacon interval (or beacon rate), and vice-versa. There-fore, throughout the paper, the term wake-up intervaland beacon interval have been used interchangeably.

4.2.1 Forward rate control

With receiver-driven transmission technique, the for-warding rate of the upstream nodes depends on thebeacon sending rate of the downstream receiver. Aswe employ multiple-packet reception at each receptionround, thus, this number also affects the forwardingrate. In this mechanism, both of these factors are con-trolled according to the request performed by the up-stream nodes, based on the prevailing traffic situation.This mechanism includes the following operations:

A. Adaptive Multiple Packet Reception A receiverreceives multiple packets in succession according tothe load observed at its upstream nodes. During lowtraffic load, a receiver might receive all of the queuedpackets at its upstream senders. As the traffic load atthe upstream sender increases, it demands excessivepacket reception, which, however, might increase themedium access delay and, thereby, collision. Hence, amaximum limit should be provided, addressing thosefactors denoted as Nmax

r . Therefore, as long as theload at the upstream senders persists within this limit,a receiver could receive all of the packets for highermedium utilization.

Algorithm 1 exhibits the adjustment of multiple-packet reception for the ith node (Ni

r) in a particularreception round. The initial value of the Ni

r field is setas Nmax

r to force the upstream senders transmitting allthe queued packets in order to get an idea of the currentload (Line 1 in Algorithm 1). The senders include theircorresponding current load in terms of packet rate,Lcurr in the packet header, which is calculated as-

Lcurr = PacketReceptionRate+PacketGenerationRate

= Nr

dw

+ 1

Td(2)

where dw is the wake-up interval of a node and Td

is the data generation interval. A receiver i then esti-

Ann. Telecommun. (2010) 65:777–794 783

mates the observed load per wake up at its upstreamsenders as-

OLi =⎧⎨

⎩

∑

j∈S(i)

L jcurr

⎫⎬

⎭× di

w (3)

where, S(i) is the set of upstream senders of node i anddi

w is the wake up interval of node i. Node i sets the

Algorithm 1 Nir Value Adjustment

1. Set, Ninitr = Nmax

r2. Set OLi according to Eq. 33. if (OLi ≥ Nmax

r ) then4. Ni

r = Nmaxr

5. else6. Ni

r = OLi

7. end if

value of Nir as Nmax

r , when the observed load exceedsor is even with Nmax

r , otherwise, the current observedload is selected as Ni

r.

B. Traf f ic Rate Aware Wake-up Scheduling TheTraffic Rate Aware Wake-up Scheduling (TWS) de-termines the wake-up/beacon interval of downstreamnodes based on the upstream node’s request. The fixed[9, 13, 14] or random wakeup interval [16], observed inthe literature failed to reflect the current traffic loadwhich achieved neither higher energy efficiency duringvery low traffic nor obtained the higher throughput dur-ing the high traffic situation. Hence, we introduce TWSwhich selects the wake-up interval of a node i, di

w as-

diw = min

(d j

w

); j ∈ S(i) (4)

For this operation, upstream senders append thedata generation interval (if it is source node only) orwake-up interval (if it is forwarding node only) orminimum of the packet generation interval and wake-up interval (if it acts both as source and forwardingnode) in the interval field of the data packet headerwhile sending packets to the receiver. We assume thatthe MAC layer knows the data generation interval.Thus, the wake-up interval is selected according to theminimum wake-up interval or data generation intervalof the upstream senders, according to Eq. 4. However,initially, each node in the network could choose theirwake-up interval according to the maximum data gen-eration interval (decided by the application) or any ran-dom value and eventually update it according to TWS.

TWS achieves the maximum energy efficiency dur-ing low traffic load because nodes remain in the sleep

state for a long period of time during the dormant stateand expect to receive a packet from any of its upstreamsenders at each wake-up, thus avoiding unnecessarywake-up. On the other hand, during the crisis state,nodes wake up at a high rate, which also increasesthe beacon sending rate to achieve higher throughput.Furthermore, this reduces the per-hop latency, and,for multi-hop network, TWS affirms the non-increasingwake-up interval selection by the downstream nodes tomaintain lower end-to-end delay.

C. Towards Maximal Throughput Avoiding QueueBuild Up During high traffic situation, TWS effec-tively adjusts the wake-up interval of a node to achievehigher throughput. It also prevents queue build-upat the upstream nodes while the observed load is ina tolerable situation (OLi ≤ Nmax

r ). However, whenOLi > Nmax

r , to inhibit in building up the queue at theupstream senders, the wake-up interval needs to beadjusted for achieving maximum throughput. Hence, inthat situation, to accommodate the extra traffic prevail-ing at its upstream senders, node i estimates requiredbeacon sending rate Ri

BS(req) as

RiBS(req) = Ri

BS(curr) × OLi

Nmaxr

(5)

In Eq. 5, RiBS(curr) is the current beacon sending rate of

node i, and OLi is the current observed load obtainedfrom the algorithm 1. Based on Eq. 5, a node sets itsnew beacon sending rate, Ri

BS(new) as-

RiBS(new) = Ri

BS(curr) + α(Ri

BS(req) − RiBS(curr)

)

(6)

Here, α is the stabilizing parameter. If α = 0, then itnullifies the effect of the required rate. Again, if α = 1,then Ri

BS(new) = RiBS(req), which could result a sharp

increase of the beacon sending rate instantaneously,perhaps creating an oscillating situation. Therefore, thevalue should be, 0 < α < 1, and based on the simula-tion, we set the value as 0.35.

While the new rate approaches the required rateeventually, the beacon sending rate of a node increaseswith the aim of gaining highest possible throughput dur-ing crisis state. This situation also allows the nodes tosleep, although for short duration. However, to provideenergy efficiency, a node might remain awake insteadof a sleep if Edw

l ≤ Eonof f holds true; where, Edw

l isthe energy consumption for listening up to the wake-upinterval, and Eonof f denotes the energy consumptionfor turning the radio on and off.

784 Ann. Telecommun. (2010) 65:777–794

4.2.2 Backward rate enforcement

Unlike the forward rate control, where the downstreamnode’s packet reception rate is adjusted based on thetraffic situation at upstream nodes, the backward rateenforcement mechanism enforces the reduction of theforwarding rate of the upstream nodes and the re-duction of source rate through creating back-pressureconsidering the current network status observed at thedownstream node. The related operations of this mech-anism include:

A. Rate Enforcement at High Contention The forwardrate control mechanism might fail to utilize the mea-sured beacon rate due to experiencing collision. Hence,this is not the optimal wake-up/beacon interval consid-ering the contention scenario. Therefore, a node adjustsits beacon interval during high contention, as shown inAlgorithm 2. In this mechanism, every node maintains a

Algorithm 2 Beacon Rate Adjustment in HighContention

1. Initialize CRC2. while (CRC ≥ 0) do3. if Ri

BS(current)changes then4. go to 15. end if6. if Experience Collision then7. N f + +8. CRC − −9. end if

10. end while11. if (N f ≥ threshold) then12. Ri

BS(new) = RiBS(curr) − γ

13. RiBS(curr) = Ri

BS(new)

14. diw(curr) = 1

RiBS(curr)

15. j = 016. end if17. if (N f < threshold and j ≤ m) then18. j + +19. if (j==m) then20. call FRC()21. end if22. end if

contention resolution counter (CRC) and observes thenumber of failed transmissions, N f , within this countervalue (line 1–9 of Algorithm 2). A failed transmission isdefined as each time a node wakes up but immediatelygoes to sleep as it experienced collision after sendingthe beacon. A node reinitializes its CRC value if itscurrent beacon interval changes. If the value of N f

becomes greater than a threshold, μ (80% of CRC),then it immediately performs an additive decrease ofthe beacon sending rate (line 11–12 in Algorithm 2).Additive decrease is used to avoid the aggressive ratereduction which could be caused by multiplicative de-crease mechanism.

In contrast, while the value of N f is less than μ andprolong for m consecutive times (line 17–20 of Algo-rithm 2), a node updates its beacon interval accordingto forward rate control mechanisms.

B. Source Rate Control at Congestion The boundedpacket reception rate due to high contention and lim-ited capacity of the wireless network could cause queuebuild up at a node which, in turn, causes packet loss dueto overflow. Thus, source rates need to be decreasedwhich, in turn, increases the beacon/wake-up intervalof the nodes along the path to the sources.

We measure the instantaneous average queue lengthof a node to detect the level of congestion following theusual trend of congestion control mechanisms. [5, 6, 22].The average is taken using the exponentially weightedmoving average (EWMA) formula as

Avgiq = (1 − ε) × Avgi

q + ε × instq (7)

Where, Avgiq is the average queue length of node i, insti

qis the instantaneous queue length of that node, and ε

is the tuning parameter. The average queue length isupdated after each reception round of node i.

Whenever the value of Avgiq exceeds a certain

threshold, λ, a node sets the ECN bit in the primarybeacon and ACK-Beacon packet. Subsequently, all thenodes along the path set ECN bit in the beacon pack-ets to notify the source nodes regarding congestion,thus creating back-pressure. A node resets the ECNbit upon relinquish of congestion. Sources employ thecommonly followed Additive Increase MultiplicativeDecrease (AIMD) approach for rate control. Since allthe sources along the path to the congested node reducethe data generation rate and increases at the same rateafterwards; fairness is maintained among the sources[23].

The detection of the congestion level and therebyperforming source rate control might not avoid thepacket drops for the nodes which are far away from thesources. As we employ a receiver-initiated mechanism,to fully avoid the packet drops, a receiver, i, could stopsending beacon if it detects that the queue is full. Itresumes sending the beacon again when its queue hasspace to receive at least one packet. In this case, it setsthe value, Nr, as the remaining space of its queue.

Ann. Telecommun. (2010) 65:777–794 785

4.3 Analysis

This section presents an energy and latency model forthe basic LET-MAC protocol.

A. Energy Analysis. Our energy analysis is basedon the work presented at [21]. In this analysis, weassume a network of n nodes, where all nodes are inthe transmission range of each other. For simplicity, weconsider only TWS operation for duty cycle adjustment.We assume that every node generates data at a fixedinterval, denoted as Td. Thus, dw = Td. Here, we intendto perform the analysis of radio energy consumption asit is the most dominant source of energy consumptionfor WSNs. [3, 4]. Typically, a radio has four differentstates: listen, transmit, receive, and sleep; the powerconsumption of each can be denoted as Pl ,Pt, Pr,and Ps. Since channel polling is different from typicallistening [21], we present the energy consumption forpolling, Pp, separately. We can measure the energyconsumption of a radio device by determining the timeit stays in each state, denoted as Tl, Tt, Tr, Tp, and Ts.Thus, the expected energy consumption per node forLET-MAC can be modeled as

E = El + Et + Er + Ep + Es

= PlTl + PtTt + PrTr + PpTp + PsTs (8)

In this analysis, we use the power and time valuesof CC2420 radio [24] for actual representation of themodel, as shown in Table 1. The value of the beaconand data packet length, along with the corresponding

Table 1 Typical power and time values used in 802.15.4 radio(CC2420)

Symbol Meaning Value

Pl Power in listening 56.4 mWPt Power in transmitting 52.2 mWPr Power in receiving 56.4 mWPl Power in polling 12.3 mWPl Power in sleeping 3μ WTg Average guard time 3 μsTw Average waiting time after 5.11 ms

sending beaconTb Time to transmit or receive a byte 32 μsTd Data generation interval varyingdw Wakeup/Beacon interval varyingTbb Average beacon backoff time 1.3 msTdb Average backoff time for 5.1 ms

data packetLd Data packet length 32 bytesLb Beacon packet length 14 bytes

back-off periods, are taken from the simulation para-meters, as to be discussed in Section 5.

Tl = Tbb + Tw

dw

+ Tdb

dw

= 1

dw

(Tbb + Tdb + Tw

)(9)

Tp = Tg + Tbb

dw

(10)

Tt = LdTb

dw

+ 2

(Lb Tb

dw

)

= 1

dw

(LdTb + 2(Lb Tb )) (11)

Tr = (n − 1)LdTb

dw

+ 2

(Lb Tb

dw

)(12)

Ts = 1 − Tl − Tp − Tt − Tr (13)

Equation 9–13 delineates the expected staying timeof a node in different states. Expected listen time,Tl, incorporates the carrier sensing performed by thereceiving node for the Tbb period before sending abeacon packet at each wake-up interval, along Tw,the waiting time for data packet arrival after sendinga beacon. It also includes the listening time for thesending node, which lasts up to Tdb period after everybeacon reception. Tp in Eq. 10 is for only the sendersas each sending node wakes up to send according tothe receiver’s wake-up schedule and to poll the channelfor beacon reception. The expected transmission timein Eq. 11 is derived for the sending nodes which sendsdata after each beacon reception, as well as for thereceiver, which transmits the primary beacon and Ack-Beacon at each reception round. Equation 12 signifiesthe multiple-packet reception in which, at each beaconinterval, a node receives data packets from its (n − 1)

neighbor nodes. It also includes the primary and Ackbeacon reception by the sending node. Here, we as-sume, Nr = (n − 1). Finally, the expected sleeping timecan be formulated by measuring the inactive time of anode, as in Eq. 13.

Substituting Eq. 9–13 into Eq. 8, we get the expectedenergy consumption per node for our proposed LET-MAC. Notably, the energy consumption largely de-pends on the primary beacon interval or wake-up in-terval of a node. In particular, the energy consumptionis inversely proportional to the beacon interval. Again,since, this parameter is determined based on the datageneration interval of a node, a similar relationshipexists between energy consumption and the traffic loadoffered in the network.

786 Ann. Telecommun. (2010) 65:777–794

B. Delay Analysis. The per-hop latency can be for-mulated as

Latperhop = dw

2+ Tbb + Tdb + Lb Tb + LdTb (14)

Assuming the data packet length and beacon lengthto be fixed, per hop latency also depends on the bea-con interval of the receiver. Since, with the increaseof the data rate the beacon interval decreases, duringhigh traffic situation the per-hop latency also decreases.Moreover, for the multi-hop case, the value dw showsa non-increasing feature due to the TWS mechanism,which also exhibits lower end-to-end latency in themulti-hop scenario.

Figure 3 illustrates the relation of the wake-up in-terval with energy consumption and latency, based onour energy and latency model. In particular, it showsthe lower energy consumption sacrificing the delay inlight traffic load, while higher energy consumption withlower delay in the case of heavy traffic loads. However,considering energy as a pioneer resource for wirelesssensor network, an optimal beacon interval can beobtained satisfying d

ddw(E) = 0 in case of higher traffic

load to prolong the battery lifetime, while the energyconsumption exceeds a certain limit with the sacrificeof latency, which can be used as minimum limit in thebeacon interval.

4.4 Parameter selection

This section discusses the determination of the value ofdifferent parameters we used in designing our protocol.

The value of Nmaxr is a system parameter and com-

pletely depends on the topology and application re-quirement. We consider the channel busy probability toselect this value, which also reflects the medium access

Fig. 3 Analytical results of energy and latency model varyingwake-up interval

delay and collision. We derive the maximum value ofNmax

r based on the analysis performed in [25] and [26]for the IEEE 802.15.4 CSMA/CA mechanism. Fromtheir results, we formulate the channel busy probability,denoted as β, due to the transmission from neighboringnodes, as

β = n × Tavgt

dw − Tavgt

(15)

Where, Tavgt is the average transmission time required

to transmit Nr packets, which can be obtained as

Tavgt = Nr × LdTb + (Nr − 1) × SIFS + 2Lb Tb (16)

We use the parameter values for Ld, SIFS, Lb , and Tb ,as used in simulation discussed in Section 5. Assuming200ms1 as dw, keeping the channel busy probability as75%, and putting the average number of backloggedneighbors as 5 (depends on the topology), and solvingthe Eq. 15 using Eq. 16, we obtain, Nmax

r = 3 and usethat value in the simulation.

We intend to keep the value of congestion detectionthreshold, λ (as discussed in Section 4.2.2 B), lower todetect an early congestion and initiate the source ratecontrol immediately for congestion avoidance. How-ever, a very low threshold could result in lower networkutilization and a very high value also could cause delayin detecting congestion. From the simulation, we obtainthat 60–70% of the maximum queue size gives a betterresult for early handling of congestion, which leads tosetting the value of λ as 9. Hence, when the averagequeue length reaches 9, the source rate control mecha-nism is initiated.

The determination of the value of ε used in Eq. 7should reflect both the transient congestion situationand actual queue size. If it is too large, it could overes-timate the congestion situation, and a very lower valuealso might not reflect the actual queue size. The rela-tionship between congestion detection threshold andthe tuning parameter has been explored in [27]. Basedon their analysis, and through extensive simulation, weset the value of ε as 0.1. This value detects congestionwhen the actual queue size reaches 63% of maximumqueue length (40 as set in the simulation). Moreover,we intuitively set the value of CRC and m in thesimulation, which justifies the selection.

1The value could be taken from the maximum allowable datageneration rate or minimum allowable data generation intervaldecided by the application.

Ann. Telecommun. (2010) 65:777–794 787

5 Performance evaluations

This section discusses the performance evaluation ofthe LET-MAC protocol. The results show that LET-MAC clearly outperforms others in achieving its designgoals.

5.1 Simulation environment

We perform extensive simulation of our protocol usingthe ns-2 network simulator. We used version 2.33 ofthe ns-2 simulator using the Two Ray Ground propa-gation model in the air and a single Omni-directionalantenna commonly used with ns-2. A network of area100m x 100m is used with 100 nodes deployment inuniform random distribution. We evaluated our proto-col using two models with this network environment:a correlated event traffic model and a periodic trafficload model. In this study, we compare LET-MAC withRI-MAC and a fully active CSMA/CA protocol. Full-active CSMA/CA has been chosen, as it achieves thehighest possible throughput since packet transmissionis initiated as soon as it arrives to the queue, and noduty cycle is maintained. We further omit preamble-based asynchronous protocols, as RI-MAC showed itssupremacy upon those protocols in their simulation. Weexclude routing traffic to simplify our evaluation andassume that a routing functionality exists which selectsthe shortest path between any two nodes. Table 2represents different parameters, and their correspond-ing values we used in our simulation. Some of theparameters (SIFS, Slot time, Data Rate, CCA Checkdelay) are from the data sheet of CC2420 radio [24].The beacon size varies from minimum 96 to maximum113 bits, depending on the Block-Ack size, along withthe presence/absence of congestion control informa-tion. On the contrary, the beacon size of RI-MAC is48–72 bits. The data packet of LET-MAC also includes4 bytes additional data in the MAC header. This over-head, however, facilitates in performing both rate andcongestion control, integrated with duty cycling with-out incorporating as additional component for those

purposes. The sleep interval of RI-MAC is set to arandom value between 0.5 to 1.5 second. We used thepower consumption values of sensor nodes in differentstates according to Table 1. Each simulation has beenperformed for 60 seconds, and we averaged the valuesobtained for 30 random runs.

5.2 Performance metrics

In this study, we measure the effectiveness of LET-MAC, compared to the other relevant protocols usingthe following metrics:

Energy Consumption. The total energy consump-tion, E, is calculated as

E =n∑

i=1

PlTil + PtTi

t + PrTir + PpTi

p + PsTis (17)

Where n is the number of deployed nodes. The averagevalue of E is taken after 30 simulation runs.

Average Duty Cycle. The duty cycle is the ratio ofa node’s active time and the summation of active andsleeping time.

End-to-End Latency. End-to-End latency of a packetis measured as the time difference between the packetgeneration time and the time when it is received bythe sink. Delays experienced by distinct data packetsare averaged over the total number of distinct packetsreceived by the sink.

Delivery Ratio. It is the ratio of the total numberof packets received by the sink to the total number ofpackets generated by the source nodes.

Average Goodput. We measure the average goodputof a source node as the average number of successfulpacket receptions per second by the sink from eachsource node.

Buf fer Drop Rate. It is the ratio of dropped packetsdue to buffer overflow to the number of transmittedpackets, expressed as a percentage.

Collision Drop Rate. It is the ratio of the droppedpackets due to collision to the number of transmittedpackets, expressed as a percentage.

Table 2 Parameters and theirvalues used in the simulation

Parameter Value Parameter Value Parameter Value

Data rate 250 kbps Beacon length 96–113 bits Nmaxr 3 packets

SIFS 192μs MAC header length 14bytes λ 9 packetsSlot time 320μs Payload length 32bytes ε 0.1Tx range 30 m BOb 8 CRC 5Carrier sensing range 67 m BOd 32 μ 4CCA check delay 128μs Queue size 40packets m 3PHY header 6 bytes Retry limit 5 γ 1

788 Ann. Telecommun. (2010) 65:777–794

Fig. 4 Average energy consumption for different numbers ofsources

5.3 Simulation results

This section presents the results obtained through eval-uating LET-MAC with others using the metrics statedabove. The results are shown in two different trafficmodels.

5.3.1 Correlated event traf f ic model

The correlated event traffic model grabs the effect ofspatially correlated events in a sensor network. Theremote sensing applications generate a high volumeof traffic when an event occurs, and the number ofsources along with the traffic generation rate signifiesthe traffic load situation. To reflect this scenario, thismodel picks a random location for the generation ofan event. The event radius is varied from 6 m to 36m and, thereby, got the number of sources2 from 1 to40. Moreover, we assume that an event occurred afterthe 10 seconds from the beginning of the simulation,and this crisis situation lasts for 20 seconds. During thecrisis state, the data generation interval for the sourcesis set as 0.05 seconds, whereas, in the dormant state,it is set as 10 seconds (assuming the maximum datageneration interval). In this study, we vary the trafficload by varying the number of sources.

Figure 4 shows the total energy consumption amongthe sensor nodes as the traffic load increases. Typically,full-active CSMA/CA shows the highest energy con-sumption, as no duty cycle mechanism is employed, and

2No of sources= ρπ R2s where, ρ = 100

100×100 , π = 3.14, Rs =sensing range

most of the energy is consumed for idle listening. LET-MAC and RI-MAC both exhibit significantly lower en-ergy consumption, compared to full-active CSMA/CAdue to the duty cycling mechanism; however, LET-MAC conserves energy far better than RI-MAC, be-cause of its load-aware duty cycle maintenance usingbi-directional rate control. Hence, during the dormantperiod, nodes in LET-MAC stay in the sleeping statemuch longer than RI-MAC. Moreover, during hightraffic load, although the wake-up interval of LET-MAC decreases with the increase of the packet sendingrate, unlike RI-MAC, the receivers still perform a sleepoperation after receiving Nmax

r packets (a receiver inRI-MAC continues receiving packets as long as it getspackets from its upstream senders), and senders arealso tuned to the receiver’s wake-up time, thus avoidingidle listening, which, still exists for the senders of RI-MAC. For the same reasons, as shown in Fig. 5, LET-MAC shows lower duty cycle than RI-MAC as thetraffic load increases. In contrast, due to a lack of anysleep mechanism, full-active CSMA/CA has a 100%duty cycle irrespective of the traffic load. Figure 6illustrates the energy consumption of the sensor nodesat different periods of the simulation. The result isshown for 40 source nodes. During 10 to 30 seconds ofthe simulation time, while the event occurs, a dramaticincrease in energy consumption is observed for all theprotocols. However, during the dormant state, whiledata generation interval is very low (10 seconds), LET-MAC shows significantly lower energy consumptionthan the other protocols. At this period, RI-MAC alsooutperforms the full-active CSMA/CA due to the dutycycle maintenance.

We evaluate the average end-to-end latency perpacket during crisis state with increasing traffic load

Fig. 5 Average duty cycle for different numbers of sources

Ann. Telecommun. (2010) 65:777–794 789

Fig. 6 Average energy consumption versus simulation time

as the number of sources increase, shown in Fig. 7.Full-active CSMA/CA shows the best performance forlatency since it is exempted from any sleep delay or bea-con waiting delay for data transmission. However, withthe increase of the traffic load, the end-to-end latencyincreases due to the retransmission increases caused bycollisions. A similar trend is observed for all the casesshown in this figure. LET-MAC delineates the closestperformance with full-active CSMA/CA. The reasonis that, although it incurs some sleep delay due to themaintenance of duty cycle, the beacon rate adjustmenttechnique during high traffic load decreases the wake-up interval considerably, and the backward rate en-forcement mechanisms reduce the retransmission ofdata packets caused by both high contention and con-gestion. RI-MAC exhibits the worst delay performance

Fig. 7 Average end-to-end latency for different number ofsources

due to the absence of load aware duty cycle main-tenance and suffers from huge collision and therebyretransmission during a crisis state. For example, in anextremely high traffic situation when the number ofsources is 40 the end-to-end latency is improved by 66%for LET-MAC as compared to RI-MAC.

Figure 8 demonstrates the average goodput achievedper node with different numbers of sources. In thisstudy, we implement a MAC-based distributed ratecontrol mechanism (IFRC) with full-active CSMA/CAto know the behavior using a rate control mechanism.The error bars indicate the maximum variation in nodegoodput. As the Fig. 8 shows, the average goodputper node decreases as the number of sources increasesfor all of the protocols since the traffic load exceedsthe network capacity. Although full-active CSMA/CAachieves higher goodput per node, the variation innode goodput is also higher which exhibits unfair be-havior among the nodes (Fig. 8a). With the use ofIFRC, full-active CSMA/CA shows fairness, althoughthe average goodput decreases slightly because of ag-gressive congestion avoidance by IFRC (Fig. 8b). Incontrast, for the lack of rate control along with non-adaptive duty cycle maintenance RI-MAC shows theworst performance both in achievable goodput andfairness (Fig. 8c). Due to the bi-directional rate con-trol mechanisms LET-MAC performs closer to full-active CSMA/CA in achieving higher goodput with theadditional benefit of fairness among the source nodes(Fig. 8d).

Considering the delivery ratio, both LET-MAC andfull-active CSMA/CA with IFRC achieves an almost100% delivery ratio due to the rate control techniquesas shown in Fig. 9. However, the absence of rate con-trol mechanism prevents a higher delivery ratio forboth full-active CSMA/CA without rate control andRI-MAC. Comparatively, RI-MAC shows the worstperformance due to a huge number of collision andcongestion loss for maintaining non-adaptive duty cyclein a crisis state.

5.3.2 Periodic traf f ic load model

The periodic traffic load model represents the periodicapplication (i.e. monitoring application), in which sen-sors generate data at a fixed interval. In this model,each sensor sources traffic at a particular offered load,as well as forward other nodes traffic through multi-hopmanner. Here, we randomize the initial data genera-tion of the sensors to avoid the synchronized periodicreports of the sensors. In this study, the traffic load isvaried by changing the data generation interval of thenodes.

790 Ann. Telecommun. (2010) 65:777–794

(a) Average Goodput for full-active CSMA/CA

(b) Average Goodput for full-active CSMA/CA with IFRC

(c) Average Goodput for RI-MAC

(d) Average Goodput for LET-MAC

Fig. 8 Average goodput achieved varying number of sources

Fig. 9 Delivery ratio varying number of sources

The energy usage varying data generation interval isillustrated in Fig. 10. As the figure shows, for a highrate periodic application, the energy depletion is sig-nificantly higher than the applications which generatepackets at moderate intervals for all of the protocols.During the high traffic rate, the energy consumptionfor transmission and reception is dominating ratherthan idle listening. Hence, after a certain data gen-eration interval, the energy consumption falls for allof the protocols at which idle listening dominates theenergy consumption. Through handling idle listening,the asynchronous duty cycle protocols, RI-MAC andLET-MAC show considerable energy conservationcompared to full-active CSMA/CA. Comparatively,LET-MAC shows better performance in both situ-ations, especially with low traffic scenario, since it

Fig. 10 Energy consumption versus data generation interval

Ann. Telecommun. (2010) 65:777–794 791

reduces the idle listening and unnecessary wake-upsignificantly with the increase of the data generationinterval along with avoidance of energy wastage dueto packet drops through a bi-directional rate controlmechanism.

As far as the average duty cycle is concerned, LET-MAC shows considerable improvement in maintainingvery low duty cycle as the wake-up interval increaseswith the reduction of data generation rate, as illustratedin Fig. 11. On the other hand, after a certain interval,the duty cycle for RI-MAC shows steady behaviorsince, although sender’s active time is reduced at lowtraffic load, receivers maintain their duty cycle in afixed manner. As usual, full-active CSMA/CA pos-sesses 100% duty cycle irrespective of the traffic load.

Figure 12 delineates the effect of the data genera-tion interval on average end-to-end latency per packet.While high offered load is given to the source nodes,LET-MAC performs well with full-active CSMA/CAhaving lower latency. Due to the huge collision andretransmission occurred, as well as the long sleep in-terval during that period, RI-MAC exhibits higher la-tency per packet. However, as the data generationinterval increases, the end-to-end latency of LET-MAC also increases due to the long sleep delay. Thisreflects the design objective of LET-MAC, in partic-ular, achieving lower latency during the high trafficload offered, which shows similar performance to full-active CSMA/CA, while for lower traffic load gain-ing high energy efficiency. Hence, concerning latency,LET-MAC is suitable for the periodic applications thatgenerate data at a high rate, which is quite common inpractice for WSNs. (i.e. Structural monitoring, HabitatMonitoring).

Fig. 11 Average duty cycle versus data generation interval

Fig. 12 Average end-to-end latency versus data generationinterval

The impact of offered traffic load over delivery ratiohas been illustrated in Fig. 13. This study also includesIFRC with full-active CSMA/CA. During high trafficrate, both RI-MAC and full-active CSMA/CA achievea quite lower delivery ratio (below 50%) because of theabsence of any rate control algorithm causing high con-tention and congestion loss. However, a sharp increasein delivery ratio is observed as the traffic rate decreasesfor both of the protocols. On the other hand, LET-MAC and full-active CSMA/CA with IFRC achievesa higher delivery ratio (near 100 %) at almost all ofthe traffic load offered to the sources, except in a veryextreme condition while it is reduced to 90% becauseof the collision. This finding signifies that, for high rateperiodic applications, LET-MAC surpasses both full-active CSMA/CA (when no rate control mechanism is

Fig. 13 Delivery ratio versus data generation interval

792 Ann. Telecommun. (2010) 65:777–794

Fig. 14 Collision drop rate versus source data rate

used), as well as asynchronous MAC protocols like RI-MAC, in terms of achieving higher delivery ratio.

The sources of packet drops at different data gen-eration interval is portrayed in Figs. 14 and 15, re-spectively, while the former shows the collision droprate and the latter exhibits the packet drop rate due tobuffer overflow. As the figures show, more of the dropsare caused due to the number of collisions than bufferoverflow as the source data rate increases. With thepresence of contention and congestion handling mecha-nisms, LET-MAC excels for full-active CSMA/CA andRI-MAC by far in terms of collision drop rate, as shownin Fig. 14. However, with the use of IFRC, full-activeCSMA/CA also shows lower collision drop rate. For thecongestion avoidance technique, no buffer drops oc-curred for either LET-MAC or full-active CSMA/CAwith IFRC, as shown in Fig. 15. However, congestion

Fig. 15 Buffer drop rate versus source data rate

(a) Average Goodput for full-active CSMA/CA

(b) Average Goodput for full-active CSMA/CAwith IFRC

(c) Average Goodput for RI-MAC

(d) Average Goodput for LET-MAC

Fig. 16 Average goodput achieved varying the Source data rate

Ann. Telecommun. (2010) 65:777–794 793

drops are noticed in the case of RI-MAC and in that offull-active CSMA/CA without rate control.

Figure 16 plots the average goodput achieved overall nodes at different offered loads for full-activeCSMA/CA Fig. 16a, full-active CSMA/CA with IFRCFig. 16b, RI-MAC Fig. 16c, and LET-MAC Fig. 16d.For each case, the diagonal line represents the achiev-able rate with infinite capacity. The error bars par-allel to the y-axis indicates the maximum variationin node goodput at each offered load. As Fig. 16ashows, the maximum achievable fair rate for full-active CSMA/CA with no rate control mechanism is0.42 pps, after which, although the average goodputincreases, the variability in goodput also increases. Thehigh variation in error bars indicates the low fairnessachieved among the nodes. In particular, nodes closerto the sink achieve higher goodput than the nodeswhich are far the away. While IFRC is used, full-activeCSMA/CA shows fair per node goodput, althoughthe maximum achievable goodput decreases (0.3 pps).LET-MAC also demonstrates fair goodput per node.However the maximum achievable goodput for LET-MAC (0.38 pps) is better than full-active CSMA/CAwith IFRC because of bi-directional rate control mech-anisms, which controls the rate less aggressively thanIFRC does, considering both contention and conges-tion. In contrast, the maximum sustainable fair rate forRI-MAC is only 0.15 pps, as it lacks non-adaptive dutycycle maintenance with no rate control functionalities.

6 Concluding remarks

This paper proposes LET-MAC, a novel rate con-trol integrated asynchronous duty cycle MAC protocolfor WSNs. With the proposed bi-directional rate con-trol mechanisms exploiting the receiver initiated trans-mission, LET-MAC achieves optimal performance indifferent traffic load. In particular, during low traffic sit-uation, it achieves higher energy efficiency, while in thecrisis state, it obtains maximum sustainable throughput.

We measured the performance of LET-MAC usingns-2 which revealed that, compared to RI-MAC, LET-MAC improves about 71.5% in energy conservation,while the traffic rate is low (0.25 pps), considering a100 node network, with all acting as sources. More-over, while fair achievable goodput and end-to-endlatency is concerned in the crisis state, LET-MACachieves fair goodput and lower end-to-end latencynear the full-active CSMA/CA protocol and far out-performs RI-MAC in fairness, achievable goodput, andlatency.

Acknowledgement This research was supported by Basic Sci-ence Research Program through the National Research Founda-tion of Korea (NRF) funded by MEST (No. 2009-0083838).

References

1. Warneke B, Pister K (2002) Mems for distributed wirelesssensor networks. In: 9th international conference on electron-ics, circuits and systems, 2002, vol 1, pp 291–294

2. Kang J, Zhang Y, Nath B (2007) Tara: topology-aware re-source adaptation to alleviate congestion in sensor networks.IEEE Trans Parallel Distrib Syst 18(7):919–931

3. Anastasi G, Conti M, Di Francesco M, Passarella A (2009)Energy conservation in wireless sensor networks: a survey.Ad Hoc Netw 7(3):537–568

4. Halkes GP,van Dam T, Langendoen KG (2005) Comparingenergy-saving mac protocols for wireless sensor networks.Mob Netw Appl 10(5):783–791

5. Rangwala S, Gummadi R, Govindan R, Psounis K (2006)Interference-aware fair rate control in wireless sensor net-works. SIGCOMM Comput Commun Rev 36(4):63–74

6. Wan C-Y, Eisenman SB, Campbell AT (2003) Coda: con-gestion detection and avoidance in sensor networks. In Sen-Sys ’03: proceedings of the 1st international conference onembedded networked sensor systems. ACM, New York,pp 266–279

7. Wang C, Li B, Sohraby K, Daneshmand M, Hu Y (2007)Upstream congestion control in wireless sensor networksthrough cross-layer optimization. IEEE J Sel Areas Commun25(4):786–795

8. Ee CT, Bajcsy R (2004) Congestion control and fairness formany-to-one routing in sensor networks. In SenSys ’04: pro-ceedings of the 2nd international conference on Embeddednetworked sensor systems. ACM, New York, pp 148–161

9. Ye W, Heidemann J, Estrin D (2004) Medium access controlwith coordinated adaptive sleeping for wireless sensor net-works. IEEE/ACM Trans Netw 12(3):493–506

10. Du S, Saha A, Johnson D (2007) Rmac: a routing-enhancedduty-cycle mac protocol for wireless sensor networks. In:INFOCOM 2007. 26th IEEE international conference oncomputer communications. IEEE, Piscataway, pp 1478–1486

11. Lu G, Krishnamachari B, Raghavendra CS (2007) An adap-tive energy-efficient and low-latency mac for tree-based datagathering in sensor networks: research articles. Wirel Com-mun Mob Comput 7(7):863–875

12. Sun Y, Du S, Gurewitz O, Johnson DB (2008) Dw-mac: alow latency, energy efficient demand-wakeup mac protocolfor wireless sensor networks. In MobiHoc ’08: proceedingsof the 9th ACM international symposium on Mobile ad hocnetworking and computing. ACM, New York, pp 53–62

13. Polastre J, Hill J, Culler D (2004) Versatile low power me-dia access for wireless sensor networks. In SenSys ’04: pro-ceedings of the 2nd international conference on Embeddednetworked sensor systems. ACM, New York, , pp 95–107

14. Buettner M, Yee GV, Anderson E, Han R (2006) X-mac: ashort preamble mac protocol for duty-cycled wireless sensornetworks. In SenSys ’06: Proceedings of the 4th internationalconference on embedded networked sensor systems. ACM,New York, pp 307–320

15. Stone K, Colagrosso M (2007) Efficient duty cycling throughprediction and sampling in wireless sensor networks. WirelCommun Mob Comput 7(9):1087–1102

794 Ann. Telecommun. (2010) 65:777–794

16. Sun Y, Gurewitz O, Johnson DB (2008) Ri-mac: a receiver-initiated asynchronous duty cycle mac protocol for dynamictraffic loads in wireless sensor networks. In SenSys ’08: pro-ceedings of the 6th ACM conference on Embedded networksensor systems. ACM, New York, pp 1–14

17. El-Hoiydi A, Decotignie J-D (2005) Low power downlinkmac protocols for infrastructure wireless sensor networks.Mob Netw Appl 10(5):675–690

18. Musaloiu-E R, Liang C-J, Terzis A (2008) Koala: ultra-lowpower data retrieval in wireless sensor networks. In: IPSN’08. International conference on information processing insensor networks, 2008, pp 421–432

19. Garcia-Luna-Aceves JJ, Tzamaloukas A (1999) Reversingthe collision-avoidance handshake in wireless networks. InMobiCom ’99: proceedings of the 5th annual ACM/IEEE in-ternational conference on mobile computing and networking.ACM, New York, pp 120–131

20. van Dam T, Langendoen K (2003) An adaptive energy-efficient mac protocol for wireless sensor networks. InSenSys ’03: proceedings of the 1st international conferenceon embedded networked sensor systems. ACM, New York,pp 171–180

21. Ye W, Silva F, Heidemann J (2006) Ultra-low duty cycle macwith scheduled channel polling. In SenSys ’06: proceedingsof the 4th international conference on embedded networkedsensor systems. ACM, New York, pp 321–334

22. Hull B, Jamieson K, Balakrishnan H (2004) Mitigating con-gestion in wireless sensor networks. In SenSys ’04: pro-ceedings of the 2nd international conference on Embeddednetworked sensor systems. ACM, New York, pp 134–147

23. Jian Y, Chen S (2008) Can csma/ca networks be made fair?In MobiCom ’08: proceedings of the 14th ACM internationalconference on Mobile computing and networking. ACM,New York, pp 235–246

24. Chipcon inc. CC2420 datasheet. http://www.chipcon.com25. Kim TO, Park JS, Chong HJ, Kim KJ, Choi BD (2008) Per-

formance analysis of ieee 802.15.4 non-beacon mode with theunslotted csma/ca. IEEE Commun Lett 12(4):238–240

26. Na J, Lim S, Kim C-K (2008) Dual wake-up low power listen-ing for duty cycled wireless sensor networks. EURASIP Jour-nal on Wireless Communications and Networking 2008(11)

27. Floyd S, Jacobson V (1993) Random early detection gate-ways for congestion avoidance. IEEE/ACM Trans Netw 1(4):397–413