Elsevier Editorial System(tm) for Ad Hoc Networks Manuscript Draft Manuscript Number: ADHOC-D-11-205R2 Title: On Combining Duty-Cycling with Network Coding in Flood-based Sensor Networks Article Type: Regular Paper Keywords: wireless sensor networks, energy efficiency, duty cycling, network coding Corresponding Author: Dr. Radu Stoleru, Ph.D. Corresponding Author's Institution: Texas A&M University First Author: Roja Chandanala, MS Order of Authors: Roja Chandanala, MS; Wei Zhang, M.S.; Radu Stoleru, Ph.D.; Myounggyu Won Abstract: Network coding and duty-cycling are two major techniques for saving energy in wireless sensor networks. To the best of our knowledge, the idea to combine these two techniques for even more aggressive energy savings, has not been explored. This is not unusual, since these two techniques achieve energy efficiency through conflicting means, e.g., network coding saves energy by exploiting overhearing (i.e., nodes are awake), whereas duty-cycling saves energy by reducing idle listening (i.e., nodes sleep). In this article, we thoroughly investigate if network coding and duty cycling can be used together for more aggressive energy savings in flood-based wireless sensor networks. Our main idea is to exploit the redundancy sometimes present in flooding applications that use network coding, and put a node to sleep (i.e., duty cycle) when a redundant transmission takes place (i.e., the node has already received and successfully decoded a sequence of network-coded packets). We propose a scheme, called DutyCode, in which a multiple access control (MAC) protocol implements packet streaming and allows the network coding-aware application to decide when a node can sleep. We also present an algorithm for deciding the optimal coding scheme for a node to further reduce energy consumption by minimizing redundant packet transmissions. Finally, we propose an adaptive switching technique between DutyCode and an existing duty-cycling MAC protocol. We investigate our proposed solutions analytically and implement them on mote hardware. Our performance evaluation results, obtained from a 42-node indoor testbed, show that our scheme saves 30-46% more energy than network coding-based solutions.

On Combining Network Coding with Duty-Cycling in Flood-based WirelessSensor Networks

Roja Chandanalaa, Wei Zhanga, Radu Stolerua,∗, Myounggyu Wona

aDepartment of Computer Science and Engineering, Texas A&M University

Abstract

Network coding and duty-cycling are two major techniques for saving energy in wireless sensor networks. To the bestof our knowledge, the idea to combine these two techniques for even more aggressive energy savings, has not beenexplored. This is not unusual, since these two techniques achieve energy efficiency through conflicting means, e.g.,network coding saves energy by exploiting overhearing (i.e., nodes are awake), whereas duty-cycling saves energy byreducing idle listening (i.e., nodes sleep). In this article, we thoroughly investigate if network coding and duty cyclingcan be used together for more aggressive energy savings in flood-based wireless sensor networks.

Our main idea is to exploit the redundancy sometimes presentin flooding applications that use network coding, andput a node to sleep (i.e., duty cycle) when a redundant transmission takes place (i.e., the node has already receivedand successfully decoded a sequence of network-coded packets). We propose a scheme, called DutyCode, in which amultiple access control (MAC) protocol implements packet streaming and allows the network coding-aware applica-tion to decide when a node can sleep. We also present an algorithm for deciding the optimal coding scheme for a nodeto further reduce energy consumption by minimizing redundant packet transmissions. Finally, we propose an adaptiveswitching technique between DutyCode and an existing duty-cycling MAC protocol. We investigate our proposedsolutions analytically and implement them on mote hardware. Our performance evaluation results, obtained from a42-node indoor testbed, show that our scheme saves 30-46% more energy than network coding-based solutions.

Keywords: wireless sensor networks, energy efficiency, duty cycling, network coding

1. Introduction

Energy is a scarce resource in wireless sensor net-works (WSN) and its conservation has been the subjectof extensive research. While a variety of solutions havebeen proposed for saving energy in WSN, duty cyclingand network coding have proven to be two of the mostsuccessful techniques.

Network coding is a technique that increases energyefficiency and reduces network congestion by combin-ing packets destined for distinct users. Since the ini-tial proposal by Ahlswede [2], many applications haveincorporated this technique. Network coding is particu-larly well-suited for WSN due to the broadcast nature of

∗Corresponding author∗∗A preliminary version of this article was presented at the IEEE

International Conference on Networked Sensing Systems (INSS),2010 [1].

Email addresses:roja@cse.tamu.edu (Roja Chandanala),wzhang@cse.tamu.edu (Wei Zhang),stoleru@cse.tamu.edu(Radu Stoleru ),mgwon@cse.tamu.edu (Myounggyu Won)

their communications. Overhearing is effortless, prop-agation is usually symmetric, and energy efficiency isa priority. Network coding can also be found in appli-cations including multi-cast, content distribution, delaytolerant networks, underwater sensing suites, code dis-semination, storage, and security. As diverse as theseapplications are, they all share a common assumption:nodes in a network are always awake.

Duty cycling is a technique that increases energy ef-ficiency by allowinga node to turn off part or all ofits systemsfor periods of time. Encompassing a rangeof techniques from peripheral device management to al-most complete system shutdown, duty cycling extendsnode lifetime and reduces maintenance. It has beenshown that duty cycling can extend battery life by an or-der of magnitude or more. In WSN duty cycling is per-vasive, and almost all deployed systems use it. Giventhe importance of duty cycling to WSN, the assump-tion that nodes will be awake cannot be made.Sincenodes will be asleep at least part of the time, i.e., the

Preprint submitted to Elsevier AdHoc Networks July 16, 2012

*Manuscript

time available for overhearing is reduced, network cod-ing becomes more difficult.

In this article, we address the challenge faced whenaggressive energy savings (i.e., both duty-cycling andnetwork coding) are needed in flooding-based WSNapplications. To the best of our knowledge, this isthe first work that considers the simultaneous use ofduty cycling and network coding. We particularly tar-get code/program dissemination (i.e., distributing a newprogram/executable image to all sensor nodes), a flood-based application that needs a non-negligible amount oftime for execution, e.g., tens to hundreds of minutes forlarge scale WSN.

Our main idea is derived from the intuition that, dueto redundancy in network coding for flooding applica-tions, there areperiods of timewhen a node does notbenefit from overhearing packets. We seek to preciselydetermine these periods of time and let nodes that donot benefit from overhearing, to be put to sleep, i.e., toduty-cycle.

Our solution to the aforementioned challenge isDu-tyCode, a cross layer scheme in which Random LowPower Listening (RLPL) – a new MAC protocol – facil-itates streaming, elastic random sleeping and transmis-sion arbitration, while the Network Coding-aware Ap-plication determines the time to sleep and the sleep du-ration. We also propose anEnhanced Coding Scheme(ECS) algorithm, which eliminates redundant packettransmissions by selecting appropriate network codingschemes for nodes. Finally, a novel technique, calledLPL/RLPL Mode Transition, ensures the smooth transi-tion between our RLPL protocol and Low Power Listen-ing (LPL), a typical duty-cycling MAC protocol whichis more energy efficient for non-flooding WSN applica-tions. The contributions of this article are as follows:

• DutyCode – a cross layer scheme that supportspacket streaming and a mechanism for randomiz-ing sleep cycles using elastic intervals. These al-low nodes to intelligently select sleep periods.

• ECS – an algorithm for deciding an efficient cod-ing scheme in static networks. ECS assigns codingschemes to minimize the number of transmissions,thus allowing for more energy savings.

• LPL/RLPL Mode Transition - a completely adap-tive solution allowing the application to smoothlyswitch between LPL and RLPL, without packetloss.

• Theoretical analysis of our proposed DutyCodeand ECS schemes and extensive simulations

S

r1 r2

d1 d2

x1,x2x1,x2

x1,x2x1,x2

x1,x2x1,x2

(a)

S

r1 r2

d1 d2

x1+x2

x1+x2 x1+2x2

x1+2x2

x1,x2x1,x2

(b)

Figure 1: A flood-based application in which nodes floodspacketsx1 andx2 in the entire network: a) transmissions whennetwork coding is not used (a total of 6 packet transmissions);b) transmissions when network coding is used (4 packet trans-missions).

demonstrating their energy efficiency and highthroughput.

• An implementation of our schemes on mote hard-ware, and performance evaluation in a 42-nodetestbed where actual energy consumption is mea-sured.

This article is organized as follows. Section 2 pro-vides background on network coding and duty cycling,and the motivation for our work. Sections 3, 4 and 5present the design of our DutyCode protocol, ECS algo-rithm and LPL/RLPL transition technique, respectively.Section 6 presents theoretical analysis of DutyCode andECS algorithm. Section 7 describes the implementationof our solutions, and Section 8 presents performanceevaluation results. We review the state of art in Sec-tion 9 and conclude in Section 10.

2. Background and Motivation

Network coding enhances energy efficiency by re-ducing the number of packet transmissions. The basicconcept of network coding, as applied to a flood-basedapplication, can be explained using a simple scenarioshown in Figure 1. Senderswants to flood two packetsx1 andx2. As shown in Figure 1(a), when network cod-ing is not used, six packet transmissions are requiredto deliver the two packets to all nodes in the network,i.e., r1, r2, d1, d2. As shown in Figure 1(b), however,when network coding is used, only 4 transmissions areneeded. This is because each of the two relays transmitsonly one coded packet. For network coding to work, re-ceiversd1, d2 must be able to receive both coded pack-ets, i.e. (x1+ x2) and (x1+ 2x2). Otherwise, they will beunable to decode the other packet received.

2

n 1 2 3 4

IP

NACK

4

BOi,c BOi,c BOi,c

BT BT BTTRBT

1 2

ReNACK

NT

BT

Figure 2: The AdapCode protocol: Ci are coded packets, N isa NACK packet, due to missing packet C4, R4 is the reply tothe NACK packet, sent when a ReNACK timer fires, IP is theInter-Page Interval, BOi,c is the backoff interval - initial andcongestion, NACK is a timer.

It is important to note that, unlike normal broad-cast/flooding packets, one missing coded packet canrender a sequence of coded packets “useless” (i.e., theydo not convey any information). Consider a scenariowhere a node receives the independent coded packets(a1x1+ a2x2+ a3x3+ a4x4), (b1x1+ b2x2+ b3x3+ b4x4),and (c1x1+c2x2+c3x3+c4x4). For decoding these pack-ets, it becomes critical to receive another coded packet,say (d1x1 + d2x2 + d3x3 + d4x4). Otherwise all 3 re-ceived packets are useless. As the coding scheme in-creases (i.e.,coding scheme is defined as the number ofdifferent packets coded into a single packet) the penaltyfor losing a single packet increases linearly.

2.1. AdapCode DesignIn this subsection we present AdapCode [3], a flood-

ing application which uses network coding and employsCSMA as its MAC protocol. Figure 2 describes theprotocol. In this figure, a sender nodes transmits asequence of packets (i.e., labeledC1, ..., C4, andR4),which are received by noder. Noder transmits packetN. The transmission and reception of packets are indi-cated by vertical gray arrows.As will become apparentlater, we depict both the transmission and reception ofa packet because these are the time instances when anode needs to be awake.

We are now ready to describe the AdapCode protocolin detail. When a source node, e.g., a base station, wantsto flood a set of packets to all nodes in the network, itbroadcasts the data as pages. Each page consists of anumber of packets. The arrival of a transmission requestat the MAC layer is depicted in Figure 2 as the verti-cal arrow “TR” (i.e., transmission request). In Figure 2,the TR only for the coded packetC1 is shown to keepthe figure simple. After transmitting a page, the sourcenode waits for a short period of time, called “Inter-PageInterval” and labeled IP in Figure 2, for code propaga-tion, and then transmits the next page. After receiving

s

r2

time

r1

x1 + x2P

x1 + 2x2P

x1P x2P

x1

x1

x2

x2

d1

d2

x1 + 2x2x1 + x2

x1 + x2 x1 + 2x2

Figure 3: Network coding integrated Low Power Listeningbased on long preambles (P represents a Preamble), for theexample shown in Figure 1(b). Source nodessends two pack-etsx1 andx2. Receiver nodesr1 andr2 sends a coded packet.Destination nodesd1 andd2 are able to decode the coded pack-ets, to retrieve the original packetsx1 andx2.

packets, a node adaptively chooses a “coding scheme”(i.e. coding scheme is defined above), based on thenumber of neighbors. If a node does not receive anypackets for a fixed period of time (called “NACK” delayin Figure 2), it broadcasts a NACK packet (labeledN inFigure 2), which indicates the packets it missed. Uponreceiving a NACK, all nodes having the page that con-tains the requested packets, set a random backoff timer(called “ReNACK” delay). The node with the smallestReNACK delay interval wins and transmits all the re-quested packets (packet R4 in Figure 2). As with exist-ing CSMA protocols, AdapCode uses a “BackoffTimer”(labeled BT in Figure 2) for accessing the medium be-fore transmitting any packet. This backoff timer has twovalues: an initial value, and a congestion value, selectedrandomly from BOi and BOc, respectively.

2.2. Motivation

Most existing duty-cycling protocols achieve energysavings through Low Power Listening (LPL) [4]. How-ever, simply integrating LPL with network coding isnot energy efficient since overhearing, the fundamentalbuilding block of network coding, is difficult to achievewhen nodes aim to sleep as much as possible. Fig-ure 3 shows how network coding and LPL can be em-ployed together in the network topology depicted in Fig-ure 1(b). As shown, because LPL uses long preamblesbefore sending the actual packets, the total transmissiontime and energy consumption (required for preambletransmission and reception) are expected to increase.

To validate this, we performed experiments in an in-door testbed of 42 Epic motes. We integrated AdapCodewith LPL [4], a frequently used duty cycling MAC pro-tocol. In our experiments we varied the LPL Sleep In-terval. The Sleep Interval is the time interval that a nodeis asleep between two consecutive wake-ups - in LPL,

3

0

2000

4000

6000

8000

10000

12000

14000

0 40 80 120 160 200 0

70

140

210

280

350

420

Energ

y [m

J]

Tim

e [sec]

Sleep Interval [msec]

AdapCode EnergyAdapCode Time

Figure 4: Impact of LPL sleep interval on energy consumptionand total execution time (i.e., for flooding a new executableimage to all nodes in the network) of AdapCode, an applica-tion which uses network coding. Results are obtained from a42 mote testbed.

nodes wake up briefly, to identify if a preamble is trans-mitted. If a preamble is detected, the node stays awaketo receive the packet transmitted immediately followingthe preamble. If no preamble is detected, a node goesimmediately to sleep. As an example, if a node needs tobe awake for 2ms to detect a preamble (this value is de-pendent on hardware), then a sleep intervalS I of 200msis equivalent to a duty cycle of 1% for the node.

The results of our experiments are depicted in Fig-ure 4. As shown, even very short sleep intervals (i.e.,80msec) nearly doubled the delay and energy consump-tion. This is in contradiction to the general belief that,for LPL, longer sleep intervals result in higher energyefficiency. From these results, it was clear that: i) anode should select sleep intervals intelligently at non-static intervals (in contrast with LPL which has fixedsleep intervals); and ii) long preamble-based MAC so-lutions are not suitable for network coding applications.

During our experiments, a significant number of re-dundant packet transmissions was detected. This re-dundancy in AdapCode is attributed to its simplified as-sumption that the network is uniform, where the num-ber of neighbors is assumed to be the same for all nodes.This assumption, however, is not practical and results ininefficient coding scheme assignments. Network topol-ogy, e.g., the number of parents or children, should becarefully taken into account when coding schemes aredetermined to avoid unnecessary packet transmissions.Those considerations motivated us to devise a new tech-nique to assign efficient coding schemes for any net-work topology such that all nodes can decode all packetswith the minimum number of packet transmissions.

It is important to remark that LPL is more energy

efficient than DutyCode for non-flooding applications(i.e., when the network traffic is low, there are more op-portunities for nodes to sleep). In Section 5 we willpresent a technique that ensures an adaptive transitionbetween LPL and RLPL, based on network traffic. Suchtechnique also needs to avoid packet loss during theLPL/RLPL transitions.

3. DutyCode Protocol Design

Combining duty-cycling with network coding inflood-based applications is inefficient because nodes uselong preambles for communicating with neighbors, andstay awake whenever there is a transmission (i.e., evenif the node has received the transmitted packet). Oursolution tackles this problem by providing a frameworkin which nodes are informed of future packet transmis-sions, without using control packets. This frameworkallows sensor nodes that run network coded applicationsto employ timely, smart duty-cycling.

3.1. Main IdeasSimilar to AdapCode, our proposed solution Duty-

Code groups packets in pages and transmits all packetsin a page as a stream using CSMA. The stream sent bya node isusefulfor neighboring nodes lacking the datacontained in the page, anduselessfor neighboring nodesthat have already received the data in the page. Uponreceiving the first packet of a page, a node decides if itshould stay awake and receive the remaining packets inthe page, or it should sleep while the remaining pack-ets in the page are streamed. The computation of thetime to be asleep is based on a control field present ineach packet, which indicates the number of remainingpackets of the stream.

DutyCode integrates Random Low Power Listen-ing (RLPL), a novel MAC protocol, with the NetworkCoded Application (NC App). RLPL facilitatesstream-ing, elastic random sleepingand transmission arbitra-tion, while the NC App determines when a node cansleep and for how long (i.e., sleep duration). When re-quested by the NC App, RLPL turns off the radio forthe requested duration if there is no pending transmis-sion. The NC App specifies the sleep duration when itrequests the node to sleep. Importantly, RLPL does notput the node to sleep periodically. Unlike other duty-cycling protocols RLPL does not perform Clear Chan-nel Assessment (CCA) before turning off the radio. Thisis because the CCA would not have any meaning, sincerequests for sleep come from the NC App when there is,typically, ongoing radio communication (e.g., streamingof useless packets).

4

n 1 2 3

IP

BO1i,1c

BOri,rc

BT BT BTTRBT

1 2 3

8

BT

8

BO2i,2c

Figure 5: DutyCode streaming: after the backoff intervalsBO1i,1c, coded packetsC2, through C8 are streamed, withbackoff intervals BOri ,rc. BT indicates when a Backoff Timerfired, TR indicates when a Transmit Request has been receivedby RLPL, and IP represents Inter-Page time Interval. Verticalgray arrows depict the direction of packet transmission.

In the remaining part of this section we describe themain components of RLPL and illustrate DutyCode’sexecution with an example.

3.2. Packet Streaming

The streaming operation of RLPL is depicted in Fig-ure 5. The meaning of “Page”, “IP”, “BT” and “Ci”is the same as for AdapCode, shown in Figure 2. Asshown, nodes receives a request for transmission (i.e.,an arrow pointing down, and labeled TR, in Figure 5)and transmits a page (i.e., coded packetsC1 throughC8)to receiver noder. Following the notation used for de-scribing AdapCode, the sender and receiver of a packettransmission can be identified by the gray arrow point-ing down and by the BT timer. As shown, the BT timerfires only for nodes, the sender of the packets.

When streaming coded packets, the penalty for col-lision is high. To reduce collisions, in DutyCode, thefirst two packets of a stream are sent with large ran-dom backoff intervals (i.e., BO1i,1c and BO2i,2c). Therest of the stream is sent with very small backoff intervalBOri ,rc. The subscripts “i” and “c” stand for the “initial”and “congestion” backoff, respectively. Thus, BO1i andBOri are initial backoff intervals, and BO1c and BOrc arecongestion backoff intervals. It is important to mentionagain that the first packet in a page contains the page ID,and that each packet contains a counter indicating howmany packets in the stream remain to be sent.

3.3. Elastic Random Sleeping

In this subsection we describeYielding, the main fea-ture of RLPL that enables the elastic random sleepingof nodes, andtransmission defer. We use Figure 6 toexplain these important concepts in RLPL.

Upon receiving the first packet of a stream, a nodeyields. As shown in Figure 6(a) upon receiving the first

1 2 3

BTTR

1

8

1 2 3 8

YL

TR

TR

1

2

HP

HP

YL

BO1i,1c BO2i,2c

(a)

1 2 3

1

BTTR

1

8

1 2 3 8

TR

TR

YL

YL

BT

BT

2

HD

HD

BO1i,1c BO2i,2c

(b)

Figure 6: (a) Yielding and Transmission Defer in DutyCode.(a) The packet transmit requests TR arrive at nodesr1 andr2

after they yield. This is handled by nodesr1 andr2 as a pend-ing request, labeled HP - Handle Pending, after the streamfrom nodes finishes. Since noder1 has the data in the page,it sleeps; (b) The packet transmit requests TR arrive at nodesr1 andr2 beforethey yield. This is handled by nodesr1 andr2

as a packet defer, labeled HD - Handle Defer. Similarly with(a) noder1 sleeps, because it has the data, while noder2 staysawake to receive the page.

packet of a stream from nodes, nodesr1 andr2 decide toyield (i.e., the vertical double arrow labeled YL). Whileyielding, nodesr1 andr2 do not process any transmit re-quests from the NC App, for the duration of the streamfrom s. Since noder1 has the page being transmitted bys, it sleeps for the duration of the stream. This is theelastic random sleeping. In Figure 6(a), the NC App atnoder1 intends to send a packet (i.e., the vertical arrowlabeled TR) while the node’s radio is turned off (i.e., itsleeps). Afterr1 wakes up, it tries to transmit pendingpackets (i.e., dotted vertical arrow labeled HP - HandlePending). Because noder2 does not have the page be-ing transmitted, it stays awake and receives all streamedpackets. Similar to noder1, noder2 yields (i.e., the ver-tical double arrow labeled YL in Figure 6(a)). Noder2

5

1 2 3

BTTR

1 2 3

8

8

1

2

BTTRYL

BT

HD

BO1i,1c BO2i,2c

(a)

1 2

BTTR

1 2 2 3

8

8

1

2

BTTRYL

BT

3

HD

BOrcBO2i,2c

BT

BO1i,1c

(b)

Figure 7: Transmission arbitration: ID(s1) > ID(s2) and (a)s2 learns about the stream froms1 and successfully defers itstransmission (i.e., vertical double arrow labeled YL). (b)s2

learns about the stream froms1 and fails to defer its transmis-sion (i.e., vertical double arrow labeled YL).

handles its packet transmission request (the receipt ofthe request is marked as a vertical TR arrow pointingdown) after it receives the last stream packet from nodes (i.e., vertical dotted arrow labeled HP in Figure 6(a)).

A transmission deferis a decision made by RLPL topostpone a scheduled packet transmission for a futuretime. As shown in Figure 6(b), nodesr1 and r2 yield(i.e., the vertical double arrow labeled YL) because ofthe stream initiated by nodes. When they yield, they al-ready have transmission requests from the NC App (tobe noted, this scenario is different then the one shown inFigure 6(a) when the transmit request TR reaches RLPLafter yielding). The backoff timers for these transmis-sion requests fire (i.e., depicted by vertical dotted ar-rows labeled BT) after the yield operation. When theBT timer fires, the nodes decide to defer their transmis-sions, until after the stream from nodes finishes (i.e.,the vertical dotted arrow labeled HD - Handle Defer).Similar with Figure 6(a), noder1 decides to sleep afteryielding (because it has the data in the page), and noder2 decides to stay awake, to receive the page.

3.4. Transmission Arbitration

Transmission arbitration occurs when two nodestransmit their packets almost simultaneously. Morespecifically, let’s assume that nodes1 receives one

S

r1

r2

r3

r5r4

r6

r7

r9r8

r11r10

r13r12

r14

r15

r17r16

r18

d

Figure 8: Network topology example to illustrate the opera-tion of DutyCode.

packet from nodes2, and thats1 is awaiting its trans-mission backoff timer to fire (becauses1 also has pack-ets to send). Whens1 receives the packet froms2, basedon the contents of the packet (e.g., sender ID),s1 candecide whether it can defer its transmission or not. Inour scheme, nodes with smaller node IDs will yield tonodes with higher node IDs.

Figure 7 illustrates two transmission arbitration sce-narios where nodess1 ands2 (ID(s1) > ID(s2)) competefor a channel. In Figure 7(a), the transmissions of pack-etsC1 andD1 are simultaneous, and will result in a col-lision (represented as the grey double arrow). Becausethe backoff timers are random, in Figure 7(a) nodes2

learns about the stream from nodes1 first, i.e., packetC2 is transmitted well before the packetD2 is attemptedto be transmitted by nodes2 (as represented by the dot-ted vertical arrow labeled BT for nodes2). Since ID(s1)> ID(s2), nodes2 decides to yield to nodes1. In thiscase, the transmission timer of nodes2 (as mentioned,the dotted vertical arrow labeled BT) fires after it makesthe defer decision. Therefore it successfully defers itstransmission.

Figure 7(b) presents a scenario where the transmis-sion timer of nodes2 fires before it makes the defer de-cision. As in Figure 7(a) packetsC1 and D1 collide,but packetD2 is sent very shortly after packetC2 isreceived, without enough time to yield. Consequently,nodes2 cannot prevent packetD2 from being sent. AfterD2, however, nodes2 defers the transmission of its fol-lowing packets. This scenario shows that nodes2 trans-mits almost immediately after receiving the packetC2

from nodes1, which implies that nodes1 has likely re-ceived packetD2 from nodes2. Consequently, nodes1

will need to decide if it should defer its transmission ornot. Now, nodes1 will obviously not decide to defer itstransmission because ID(s1) > ID(s2). Consequently,the remaining packetsC3 throughC8 will be sent suc-cessfully.

6

3.5. DutyCode ExampleIn this subsection we explain how DutyCode works

through an example, depicted in Figure 8. As shown,there is a source nodes that floods packets in a 5 hopWSN. We assume that each page consists of 8 packets.For ease of explanation, we assume that 2 nodes are 1hop away froms, 4 nodes are 2 hops away froms, 8nodes are 3 hops away froms and lastly, 4 nodes are 4hops away froms. Using the AdapCode algorithm todecide the coding scheme (which is based on the num-ber of neighbors), nodesr1 and r2 havecs = 2. Thismeans that the number of packets each node sends ispp/cs = 4, if the number of packets per pagepp is8. Similarly, for nodes 2 hops away froms the codingschemecs is 4 (i.e., each node will send 8/4 = 2 codedpackets), and for nodes 3 hops away froms the codingschemecs is 8 (i.e., each node sends 8/8 = 1 codedpacket). After the nodes decide their coding schemes(again, the technique we use here is the same as ofAdapCode’s, based on the number of neighbors), theflooding operation can start.

The senderssends the packets in a page continuously(i.e., as a stream). When senders finishes streaming, itwaits for a period of time for potential NACK packets(which indicate that receivers missed some packet(s)).In response to a NACK packet, senders resends themissing packets. After nodesr1 and r2 receive all 8packets in the page, using their coding scheme, theycode and send 4 packets each. Assuming the backoff

timer of noder1 fires first, the streaming of the 4 pack-ets from it will start. After receiving the first packet(of the 4), noder2 realizes that it has already seen thepage, and it will decide to sleep for the remaining timeof the stream (in this example 3 packets). Similarly,when noder2 streams its 4 coded packets, noder1 willsleep. When nodesr1 andr2 finish sending their codedpackets, they will wait for NACK packets. NACK pack-ets might be sent by nodesr3 throughr6 if they missed acoded packet, and could not decode all packets received.If a NACK packet is received, eitherr1 or r2 resends themissing packet. If nodesr3 throughr6 are able to de-code the 8 packets received, then they have the entirepage. Based on their coding scheme (which iscs= 4),each node will send 2 coded packets. Whenever one ofnodes streams its packets (let’s assumer3), the nodesthat have received already the page (i.e., nodesr1, r2,r4, r5 andr6) decide to sleep.

4. An Enhanced Coding Scheme (ECS)

While our proposed solution, presented in the pre-vious section, saves a considerable amount of energy

p1 p5p4p3p2 p8p7p6

c3c2c1 c4

Figure 9: An example of a network topology that causes re-dundant packet transmissions.

there is still an opportunity to save more energy byreducing the number of unnecessary packet transmis-sions. This is primarily because, thus far, we used thesame algorithm as AdapCode, for deciding the codingscheme each node uses. The simple algorithm usedby AdapCode uses the number of neighbors. The al-gorithm, at high node densities, increases the codingscheme. Hence, each node sends fewer coded packets.This scheme, however, does not identify unnecessarypacket transmissions, which is the purpose of our En-hanced Coding Scheme (ECS) algorithm.

In order to analyze the unnecessary transmissions,we define thePreferred Coding Scheme (PCS)for eachnode. PCS is defined as the maximum coding schemethat a node’s parents can use such that all parent’s chil-dren can successfully decode all encoded packets.

Consider Figure 9 which shows a hypothetical net-work with four leaf nodes (c1 − c4) and their parents(p1 − p8), wherec1 and c4 receive packets from fourparents whereasc2 andc3 receive packets from only twoparents. In our example, consider the PCS forc1. Sincec1 receives 4 coded packets (i.e., each from parentp1

through p4) at most 4 packets can be encoded into asingle packet, yielding a PCS of 4 forc1. Similarly, thePCS forc2, c3, andc4 are 2, 2, and 4, respectively. Sincethe PCS forc2 andc3 is 2, the coding scheme ofp3− p6

must be 2. Consequently, all childrenc1 − c4 can de-code all packets from the transmissions fromp3 − p6.The result, and this is how ECS removes unnecessarytransmissions, is that transmissions fromp1, p2, p7, andp8 are all useless.

In order to avoid such extraneous transmissions andsave energy, we propose an Enhanced Coding Scheme(ECS) Algorithm, which decides the optimal codingscheme of each node. Our algorithm is centralized anduses information about the network topology. We repre-sent the network as a directed graphG = (N,E), whereN is the set of all nodesni , andE is the set of edges(ni, n j) such thatni is the one-hop parent ofn j . Eachedge has a Link Quality (LQ) scalar value, which rep-resents the link’s successful packet delivery ratio. Onlyedges with LQ greater than a pre-defined Link QualityThreshold (LQT) are considered. Different LQTs re-

7

Algorithm 1 Enhanced Coding Scheme (ECS)

1: for eachni ∈ N do2: nPCS

i, j ← |Pi |, ∀n j ∈ Pi .3: end for4: for eachni ∈ N do5: nCS

i ← min{nPCSi, j | n j ∈ Ci}

6: end for7: for eachni ∈ N do8: nEQNS

i ← 09: for eachn j ∈ Pi (in an ascending order ofnCS

j )do

10: if nEQNSi ≤ pagesizethen

11: nEQNSi ← nEQNS

i +pagesize

nCSj

12: else13: nPCS

i, j ← null codingscheme14: end if15: end for16: end for17: for eachni ∈ N do18: if ∀n j ∈ Ci , nPCS

j,i = null codingschemethen19: nCS

i ← null codingscheme20: else21: nCS

i ← min{nPCSj,i | n j ∈ Ci}

22: end if23: end for

sult in different network topologies, thereby affectingthe performance of ECS. LetPi = {n j | (n j, ni) ∈ E}be the set of all one-hop parents of nodeni andCi =

{n j | (ni, n j) ∈ E} be the set of all one-hop children ofnodeni . We denote bynPCS

i, j the PCS ofni for its parent

n j ∈ Pi , and bynCSi the coding scheme ofni .

The pseudocode for the proposed ECS algorithm isshown in Algorithm 1. ECS runs in 2 phases. In thefirst phase, the algorithm computes the PCS valuenPCS

i, jfor all n j ∈ Pi . (Line 1-3).

Then, the initial coding scheme for each nodeni is de-cided as themin{nPCS

j,i : n j ∈ Ci}, i.e., the minimum PCSvalue among all PCS values of its children (Line 4-6).If |Ci | = 0, then the “null coding scheme” is chosen forni (in a “null coding scheme” no coded packets are for-warded), preventing a leaf node from sending unneces-sary packets. In the second phase, the algorithm checksfor possible redundant transmissions for each nodeni ,by examining the initial coding schemes of its parents.If for nodeni there is a redundant transmission from oneof its parentn j , the algorithm updates the PCS value forthe parent,nPCS

i, j to the null coding scheme (Line 7-16).In the last step, the algorithm checks the PCS value for

the children of each node. If all children suggest a nullcoding scheme, then the algorithm sets the null codingscheme as the final one for the parent; otherwise thecoding scheme assigned to the parent is the minimumPCS value among its children (Line 17-23).

Although ECS is a centralized algorithm where cod-ing schemes are decided at a central entity, it can bemodified to run in a distributed manner through addi-tional message exchanges between nodes. We leave thedevelopment of a distributed ECS algorithm as futurework.

5. LPL/RPLP MAC Transitioning

Aggressive energy saving can be achieved by Duty-Code in flood-based WSN (i.e., high network traffic).For low network traffic, however, LPL is more energyefficient. Thus, there is a need for an efficient techniqueto switch between RLPL and LPL. Such switching tech-nique needs to be carefully designed to ensure a smoothand timely transition with no packet loss.

In our solution, each node starts executing LPL.When a node receives the first packet of the flood, itattempts to switch to RLPL. To minimize packet lossduring the transition from LPL to RLPL, we use a tran-sient mode, called NoSleepLPL. In NoSleepLPL, afterreceiving the first packet of the flood, a node does notsleep. This is because the node tries to avoid missingpackets. The received packets are relayed utilizing longpreambles (as LPL does), to ensure that node’s children,in turn, do not miss any packets. Similarly, the chil-dren nodes transition to NoSleepRLPL successfully. Ata fixed time interval after receiving the first packet ofthe flood, a node switches from NoSleepLPL to RLPL.The node switches back from RLPL to LPL mode whenit has received all packets in the flood. Switching backfrom RLPL to LPL is relatively easier due to low traffic,thus not incurring packet loss.

6. DutyCode Protocol and ECS Algorithm Analysis

In this section we derive performance bounds for theDutyCode protocol and ECS algorithm. The aim of ouranalysis is to:

• Show that DutyCode does not have any overhead,when compared with AdapCode. The two metricswe investigate arethe total number of packets perpagetransmitted (Section 6.1), andthe total execu-tion timeof flooding (Section 6.2).

8

• Show that the coding schemes assigned by ECS areoptimal (Section 6.3).

• Compute an upper bound on the energy savings ofDutyCode (Section 6.4).

For our analysis we use the following notations:ppis number of packets per page;cs is the coding scheme;cp is the collision probability in AdapCode;cp1 andcp2

are the collision probabilities associated withBO1 andBO2 backoff intervals in DutyCode, respectively;BOc

is the CSMA congestion backoff interval (as it will benoted belowBOi is not of interest for AdapCode); andttr is the transmission time per packet.

We assume that the sleep interval per pageS I is cho-sen such that there is no time overhead due to sleeping(i.e., stream duration is much longer than the sleep in-terval):

S I ≤ (BO1i/2+ pp/cs· ttr ) (1)

For the analysis in this section it is paramount to ob-serve the following: i) because AdapCode is messageintense, there is always a node waiting to transmit apacket. Consequently, the congestion backoff intervalfor AdapCode will be chosen randomly between 0 andBOc. Because the backoff is uniformly distributed, theaverage backoff interval isBOc/2 and the average col-lision probability iscp; ii) in DutyCode the first packetof a stream is always transmitted with a backoff intervalrandomly chosen between 0 andBO1i. Hence, the aver-age backoff interval for the first packet isBO1i/2. Sincethe average collision probability for the first packet ofthe stream iscp1, the collision probability for the sec-ond packet of the stream iscp1 · cp2 (i.e., a collisionwill occur during the transmission of second packet ifand only if there was a collision during the first packettransmission).

6.1. Total Number of Packets per Page Transmitted

In this section we investigate the relationship betweenPd

p andPap, the total number of packets per pagetrans-

mitted by DutyCode and AdapCode, respectively (wenote here thatPd

p andPap are different thanpp, which is

a constant describing how large a page is). Our result isexpressed by the following theorem.

Theorem 6.1. If BO1i ≥ BOc then Pdp ≤ Pa

p .

Proof. In both DutyCode and AdapCode, three typesof packets contribute to the total number of packets perpage: a) coded packets; b) NACK packets; and c) Re-NACK packets. We now derive the number of packetsof each type.

6.1.1. Coded PacketsCoded packets are packets transmitted by a node as a

result of network coding. The number of coded packetsper page isCp = pp/cs. Assuming the coding schemeis identical for DutyCode and AdapCode (i.e., we do notconsider here the Enhanced Coding Scheme (ECS)), wehave:

Cap = Cd

p (2)

whereCap andCd

p are the number of coded packets forAdapCode and DutyCode, respectively.

6.1.2. NACK PacketsA node sends a NACK packet when it is unable to

decode a page. This can happen because of two factors:i) the node does not receive enough independent codedpackets needed for decoding a page; and ii) collisionscause loss of coded packets.

Since DutyCode uses the same coding scheme asAdapCode, the first factor, i.e., not enough independentcoded packets received, has no impact on the total num-ber of packets. Hence, we do not consider it.

We now analyze how collisions impact the number ofNACK packets in AdapCode and DutyCode.

In AdapCode, the maximum number of NACKs perpacket is (cp+ 2cp2 + ...). This is because with colli-sion probabilitycp a coded packet will be lost, hence 1NACK will need to be sent. Additionally, if the trans-mission of the NACK packet causes a collision with aregular packet (this will occur with probabilitycp2) thentwo NACK packets will need to be sent. Consequently,the total number of NACKs per page for AdapCode is:

Nap = (pp/cs)(cp+ 2cp2 + ...). (3)

For DutyCode, NACK packets can be sent as a resultof: i) collision of the first packet transmission, whichoccurs with probability (cp1); ii) collision of the sec-ond packet transmission, which occurs with probability(cp1 · cp2). Thus, the total number of packets per pagefor DutyCode is:

Ndp = (cp1 + cp1 · cp2) + 2cp1 · (cp1 +

cp1 · cp2) + 3cp21(cp1 + cp1 · cp2) + ...

= (1+ cp2) · (cp1 + 2cp21 + ...). (4)

One can remark that collision probabilities are in-versely proportional with backoff intervals. Thus, wecan expresscp = k/BOc andcp1 = k/BO1i, wherek is

9

a proportionality constant (assumed the same for Duty-Code and AdapCode). Consequently, the ratio of colli-sion probabilitiescpandcp1 is:

cp1

cp=

BOc

BO1i.

Consequently, if backoff intervals are chosen suchthatBO1i ≥ BOc, then:

cp1 ≤ cp. (5)

Considering Equation 5, ifpp/cs ≥ (1 + cp2) thenthe relation betweenNd

p and Nap (given by Equation 3

and Equation 4) is:

Ndp ≤ Na

p. (6)

It is important to reemphasize the required conditionpp/cs ≥ (1 + cp2). This condition basically says thatpp needs to be different thancs. If this condition is nottrue, i.e.,pp = cs, then there is only one packet in thestream, and there is no opportunity for sleeping.

6.1.3. ReNACK PacketsReNACK packets are uncoded packets, sent in re-

sponse to NACK requests. We now analyze the numberof ReNACK packets for AdapCode and DutyCode.

In AdapCode, if there is a collision while transmit-ting a coded packet (i.e., with probability of collisioncp) all packets in the page need to be resent, withoutbeing coded. Consequently, for each coded packet (andthere arepp/cs coded packets in each page), the nodeneeds to retransmitcs packets. Similar to scenario de-scribed for NACKs, the node needs to transmit thesepackets twice with probabilitycp2. Hence, the numberof ReNACKs per page for AdapCode is:

Rap = cs· pp/cs· (cp+ 2cp2 + ....). (7)

For DutyCode, a collision during a stream transmis-sion can occur: i) during the transmission of the firstpacket (with probabilitycp1). In this scenariocspack-ets will be retransmitted; and ii) during the transmissionof the second packet (with probabilitycp1 · cp2). In thisscenario the entire page will be retransmitted. Conse-quently, the number of ReNACK packets sent by Duty-Code isRd

p = cs · cp1 + cp2 · cp1 · pp. Assuming theworst case, in whichpp packets need to be retransmit-ted in case of collision during the transmission of firstpacket, the total number of ReNACKs per page per nodeis:

Rdp = cp1 · pp+ 2cp2

1 · pp+ ...

= pp · (cp1 + 2cp21 + ...). (8)

From Equations 7, 8 and 5 the relation between thenumber of ReNACK packets sent by AdapCode and Du-tyCode is:

Rdp ≤ Ra

p. (9)

From Equations 2, 6 and 9, thenPdp ≤ Pa

p, wherePa

p = Cap + Na

p + Rap is the total number of packets per

page of AdapCode, andPdp = Cd

p + Ndp + Rd

p is the totalnumber of packets per page of DutyCode.

If we denote bys the total number of streams in thenetwork, the total number of packets per node for Adap-Code can be written, in terms ofs, as:

Pa = s · pp/cs+ Nap (10)

whereNap is the number of NACK packets for Adap-

Code.In DutyCode, coded packets and ReNACKs (note:

not NACK packets) are transmitted as streams. Con-sequently, the total number of packets transmitted pernode is:

Pd = s · pp/cs+ Ndp (11)

where the first term represents the number of coded andReNACK packets a node transmits, andNd

p is the num-ber of NACK packets for DutyCode.

6.2. Total Execution Time

In this subsection we investigate the relation betweenTd

n and Tan, the total execution time of flooding, per

node, for DutyCode and AdapCode, respectively. Ouranalysis omits the delay that a packet defer causes. Ourresult is expressed by the following theorem.

Theorem 6.2. If pp/cs· BOc ≥ BO1i and BOc = BO1c,then Td

n ≤ Tan.

Proof. As mentioned earlier, the average backoff timeper packet in AdapCode isBOc/2. Hence, the total exe-cution time, per node, for the flooding operation is:

Tan = Pa(BOc/2+ ttr )

which, after the substitution ofPa with Equation 10, be-comes:

10

S

thth th

Figure 10: A multihop network topology for a flood-basedWSN application. Large dotted circles represent communica-tion range. Groups of nodes are (i −1), i and (i +1) hops awayfrom s.

Tan = s · pp/cs· BOc/2+ Na

p · BOc/2+ Pa · ttr (12)

For DutyCode, the average backoff interval for astream isBO1i/2 except for the stream which is trans-mitted after a NACK packet (for a NACK packet, yield-ing is not done because it is not a stream). Hence, thewait time of the stream transmitted right after the NACKis BO1c/2. In DutyCode, based on Equation 1, the totaltime for flooding is the total time required for all packettransmissions. Consequently the total time per node is:

Tdn = (s− Nd

p) · BO1i/2+ Ndp · BO1c/2+

+Ndp · BO1i/2+ Pd · ttr

= s · BO1i/2+ Ndp · BOc/2+ Pd · ttr

sinceBO1c = BOc.From Equation 6 and Theorem 6.1, whenpp/cs ·

BOc ≥ BO1i, then:

Tdn ≤ Ta

n .

6.3. Total Energy Saving

This section presents an analytical upper bound onthe total energy saving of a node in DutyCode. Toprove the upper bound, we consider a particular networktopology depicted in Figure 10, where nodes inith hopare within the interference range of nodes in (i+1)th hopand (i −1)th hop. We assume that the Inter-Page interval(IP) is minimal, i.e., the source node sends one page af-ter the previous page has been successfully flooded bythe nodes that are 3 hops away from it, thus preventing

the hidden terminal problem. We denote bySi the setof nodes that arei hops away from the source. The totalenergy saving for a node is defined as follows:

Esave= Tsleep/Ttotal (13)

whereTtotal is the total flooding time, andTsleep is thetotal time that a node is in sleep mode.

Since flooding is a pipelined process, given the mini-mal IP interval,Ttotal can be estimated as the total timetaken for any node inSi−1, Si , orSi+1 to finish the flood.Consider a nodeni ∈ Si . In this topology,ni can-not transmit a packet if any node inSi−1 (parents),Si

(peers), orSi+1 (children) transmits. Thus, the expectedtotal flooding timeE(Ttotal) is given by:

E(Ttotal) =

(

|Si−1| + |Si − 1| + |Si+1|

2

)

· Tpage · P

=3n2· Tpage· P (14)

whereTpage is the time taken for one page, i.e.,Tpage=

(BO1i/2+pp/cs· ttr), andP is the total number of pages.The first term is divided by 2, to account for senders andreceivers. Essentially, at most|Si−1|+|Si−1|+|Si+1|

2 transmis-sions take place.

If we assume a coding scheme with no redundanttransmissions, only packets transmitted by the nodes inSi−1 are useful. Consequently,ni can sleep while thenodes inSi andSi+1 are transmitting their packets. Theexpected total sleep timeE(Tsleep) is thus:

E(Tsleep) =

(

|Si − 1| + |Si+1|

2

)

· T′page · P

= n · T′page· P (15)

whereT′page is the sleep time per page, i.e.,T′page= S I.Considering Equations 1, 14 and 15, the expected to-

tal saving in energy is:

E(Esave) = E

(

Tsleep

Ttotal

)

=n · S I

3n2 (BO1i/2+ pp/cs· ttr )

≤23. (16)

6.4. Enhanced Coding Scheme AnalysisIn this section we prove the optimality of the coding

scheme assigned by our proposed ECS algorithm.

Theorem 6.3. ECS produces the optimal codingschemes for all nodes, such that all packets can be de-coded successfully.

11

Algorithm 2 Streaming a Packet Received

1: if (# of remaining pkts> 0) then2: if (any yield cond. is true)then3: if (# pkts awaiting transmit> 0) then4: attempt to DEFER pkt transmission5: RLPL saves DEFER result6: end if7: RLPL startsNoSendtimer8: end if9: else

10: RLPL stopsNoSendtimer and handles packet11: end if

Proof. Assume by contradiction that there exists a bet-ter coding schemeBCS. This implies that inBCS, thereexists a node that transmits fewer packets than ECS. Letthis node beni . Note that, in ECS, each parent choosesthe minimum coding scheme among those proposed byits children (as explained in Algorithm 1 (Line 21)).Thus, if ni transmits fewer packets, then at least onechild would not be able to decode all packets success-fully, which is a contradiction. Consequently,BCSdoesnot exist.

7. Implementation

We implemented DutyCode and LPL/RLPL Tran-sition in nesC for TinyOS 2.1. We modified sev-eral existing TinyOS modules: CC2420ReceiveC,CC2420TransmitC and CC2420CsmaC - from now on,we will refer to these modules asReceive, TransmitandCsma, respectively. We also added DutyCode spe-cific modules: RandomLPL and RPowerCycleC. TheECS algorithm was implemented in Java, on a centralserver. It uses network topology information collectedfrom the nodes to decide the coding scheme for eachnode.

7.1. Packet Streaming

We modified theTransmit and Receive modulesand implemented theRandomLPL module for packetstreaming. When streaming is achieved, an applicationsends packets one after another, without any significantdelay (i.e., as soon assendDone() event is signaled).Each packet header contains the number of remainingpackets in the stream, computed based on the codingscheme used.

The Receive module notifies theTransmit mod-ule when the node receives a stream packet from an-other node. Upon receiving a signal fromReceive,

Transmit runs Algorithm 2. First,Transmit checksif it has pending packets or the end of the stream hasbeen reached (Line 1). If there are remaining packetsin the stream,Transmit checks if the stream satisfiesthe yielding conditions discussed in Section 3 (Line 2).If the stream does not satisfy the yielding conditions,no action is taken. Otherwise, if it is in the middle oftransmission, the node tries to defer the packet trans-mission and it informs theRandomLPL module abouttwo things: i) details of the stream transmission; andii) the defer status, if there was a need for packet defer(Line 4-5). TheRandomLPLmodule then sets a NoSendtimer (Line 7) and keeps future transmit requests pend-ing until the stream duration is over or it is informedby Transmit that the stream it is yielding to, has com-pleted.Transmit informsRandomLPL about the com-pletion of stream upon receiving a signal fromReceiveabout the last packet of the stream (Line 10). We imple-mented the packet defer in theTransmit module be-cause it is the only module that maintains the transmis-sion internal state.

Upon receiving a transmit request from the applica-tion with the result of clear channel assessment (CCA),theTransmit module copies the message to the radiochip and waits for the backoff interval corresponding tothe CCA result.Transmit can defer a packet transmis-sion until the actual transmission has been started. Theapplication would not be aware about this packet deferand RLPL handles the deferred packet as soon as possi-ble.

7.2. Elastic and Random SleepingWe implemented/modified the RandomLPL and

RPowerCycleC modules so that sleep requests are nolonger handled periodically, as done for LPL. Instead,the requests to put the radio in low power mode (i.e.,requests to sleep) are treated as one time requests. TheRPowerCycleCmodule is also modified not to performclear channel assessment (CCA) before turning off theradio. This is because the network coding applicationdecides to put a node to sleep, based on the knowl-edge it has about the currently transmitted stream. Thisstream is useless to the node. Hence, performing CCAis unnecessary - we know that a transmission is ongo-ing, but it is useless. We also modified theCsma moduleto turn off the radio only ifTransmit decides to deferthe transmission.

7.3. The ECS AlgorithmWe implemented the ECS algorithm in JAVA. We ex-

ecute the algorithm on a central server, after we col-lect connectivity information from the entire network.

12

We leave the development of a distributed ECS algo-rithm as future work. When the algorithm starts, thenetwork topology is constructed by receiving neighbortables from the motes, via serial ports. Based on thenetwork topology, ECS computes the optimal codingscheme for each node as described in Section 4. Thenew coding schemes are transmitted back to the nodesvia serial ports. When the flooding starts, each nodeuses the new coding scheme.

7.4. LPL to RLPL Mode Transition

In order to achieve a smooth transition between LPLand RLPL (as described in Section 5), we built two in-dependent modules, one containing the LPL protocol,and the other RLPL. We also created a wrapper modulethat provides a common interface both MAC protocols.The wrapper handles the LPL to RLPL mode transitionsmoothly: if the current MAC protocol is in the middleof transmission, the transition happens after receivingthesendDone() event. Switching is accomplished bystopping the current MAC protocol and then starting theother MAC protocol. Especially for the transition fromLPL to RLPL, the transient state noSleepLPL is intro-duced to minimize the packet loss, as explained in Sec-tion 5. The noSleepLPL is implemented such that theDefaultLPL andRPowerCycleC modules do not turnoff the radio when requested by an application throughthe wrapper module.

8. Performance Evaluation

We evaluated the performance of DutyCode, ECS al-gorithm and LPL/RLPL mode transition in a testbedconsisting of 42 Epic motes [5] deployed in an indoorenvironment of approximately 500ft2. Among the 42nodes, 14 are instrumented for power consumption mea-surements. The map of our testbed is shown in Fig-ure 11. The testbed has a diameter of at most 5 hops.We varied the network density (and implicitly the diam-eter of the network) by changing the radio TX Power(i.e., the TXCTRL.PALEVEL register of the CC2420transceiver [6]). The TX Power can be varied from 2 to31, the lowest and the highest transmit power levels, re-spectively. Each experimental point represents the meanof 5 executions of the protocol. Standard deviation isdepicted in all performance evaluation results.

As state of art for our performance evaluation wechose AdapCode [3], a flooding protocol that uses net-work coding. The metrics we used for performanceevaluation are theper node energy consumptionand

Figure 11: The map of our testbed. For each node, (x, y) rep-resents its relative coordinate with respect to the origin (0,0),in the lower left corner. The origin is where the source node,initiating the flood operation, was located. The network is atmost 5 hops (when the radio transmit power is the lowest). Thecentral server is where measurements for power consumption,neighborhood are collected.

total flooding time. While we are interested in en-ergy consumption, we also aim not to increase the to-tal flooding time. The parameters that we vary arethe sleep interval (S I), node density (ND), the size ofpacket (S P), the number of packets (NP), the length ofthe NACK timer, i.e., NACK delay (NACKD), and theInter-Page Interval (II ). From Theorems 6.1 and 6.2,the BO1i should satisfy the condition:pp/cs · BOc ≥

BO1i ≥ BOc. In order to decrease the collision proba-bility of DutyCode and reduce the penalty for retrans-mission, the greater bound for BO1i is used for theexperiments. In our experiments, the default back-off intervals were chosen as follows: BO1i and BO2i

are chosen randomly in the interval [0.3msec, 8msec],BO1c and BO2c are chosen randomly in the inter-val [0.3msec, 2msec], BOri=(2+nodeid)/32msec, andBOrc=(5+ nodeid)/32msec.

The default values for the parameters are:S I =17msec,ND = 4, S P= 28bytes,NP = 256, NACKD= 640msec,II = 300msec. The effects of these param-eters on the performance of DutyCode are investigatedin the remaining part of this section.

8.1. Preliminary Evaluation

We verified the correct operation of DutyCode proto-col using three regular nodes and a source node, forminga single hop network. An oscilloscope was used to mea-sure the actual power consumption and sleep intervals.Figure 12 depicts the oscilloscope view of coded packet

13

Figure 12: Packet streaming captured on oscilloscope showsthe current consumption during sleeping and during packettransmission. The current consumptions increases from topto bottom. The sleeping interval is indicated by a solid arrowand the packet streaming is denoted by a dotted arrow (i.e.,sleeping interval is low current consumption, packet stream-ing requires high current consumption).

0

1400

2800

4200

5600

7000

8400

0 15 30 45 40

60

80

100

120

140

160

Energ

y [m

J]

Tim

e [sec]

Sleep Interval [msec]

AdapCode EnergyAdapCode Time

DutyCode EnergyDutyCode Time

MAX Energy Saving

Figure 13: The effect of the sleep intervalS I on energy con-sumption and execution time of flooding. The bound on theenergy efficiency of DutyCode is also plotted.

transmissions of the 3 nodes after receiving a page fromthe source. As shown, two small spikes under the dottedarrow indicate a packet transmission. A cluster of suchspikes represents a “stream”. In our experiment, a pageconsisted of 4 packets, hence the 4 sets of spikes. Thesolid arrow indicates the sleep duration of a node. Asthe figure shows, during a stream transmission, othernodes are in the sleep state. As soon as the transmis-sion is finished, one of the remaining nodes starts itsstream transmission, while the remaining nodes sleep(since they already have the page).

8.2. Sleep Interval

In this experiment we investigate how sleep inter-val S I affects energy consumption and total floodingtime. It is important to remark that AdapCode and Du-

tyCode should consume the same amount of energy ifS I is 0msec. This is because both AdapCode and Du-tyCode use the same network coding scheme, and atS I = 0msec, neither scheme allows nodes to sleep.

Before presenting the experimental results, we wouldlike to build the intuition that although energy savings inDutyCode are expected to increase with higher sleep in-terval, this can only occur until a certain point/threshold(i.e., a certain sleep interval). Below this threshold,nodes sleep very little, and are still awake while uselesspacket transmissions are taking place. Longer sleep in-tervals (i.e., duty-cycling) will allow them to save moreenergy. After the threshold point, however, nodes loseopportunities for network coding, i.e., there are pack-ets being transmitted, but because nodes sleep, they donot receive the packets. Consequently, nodes will notbe able to decode coded packets, and more NACKs andReNACKs will be transmitted. At this point the en-ergy efficiency of duty-cycling is much less than the en-ergy lost because of retransmissions caused by sleepingwhen network coding is taking place.

We measured energy consumption and total flood-ing time by varyingS I in the [4msec, 60msec] range,while keeping other parameters constant. Figure 13 de-picts our results, which confirm our intuition. AsS Iincreased, the energy consumption of DutyCode gradu-ally decreased untilS I was 45ms, after which it startedto increase. Following our analysis in Section 6, themaximum energy saving is achieved when the sleep du-ration matches the stream duration. The explanation forthe 45ms optimal sleep interval is as follows. In theseset of experiments, we do not employ ECS - we sim-ply use the default coding scheme that AdapCode uses(i.e., based on neighbor density). In our testbed, due toa relatively uniform deployment, all nodes have a cod-ing scheme of 2. This means that the 8 packet page iscoded in 4 packets. Since a stream has 4 packets, theopportunity for sleeping is only for the last 3 packets inthe page. Transmitting a single packet in TinyOS takesabout 8ms. Hence transmitting 3 packets, coupled withthe additional small backoffs between streaming packets(i.e., BOr) will total around 45ms.

The experimental results follow the analytical result,as the maximum energy saving for our testbed wasachieved whenS I = 45msec. The theoretical upperbound of energy saving is also shown in the figure forcomparison. The maximum energy savings achievedfor our testbed was 42%, while the theoretical boundis 66%.

We also compare the energy consumption of Duty-Code with that of NoCode, a modified version of Adap-Code which does not use network coding, but uses duty

14

0

1500

3000

4500

6000

7500

0 15 30 45

Energ

y [m

J]

Sleep Interval [msec]

AdapCode EnergyDutyCode Energy

NoCode Energy

Figure 14: Energy consumption of DutyCode, AdapCode andNoCode.

1000

1500

2000

2500

3000

3500

4000

3 4 5 6 7

40

60

80

100

120

140

160

Energ

y [m

J]

Tim

e [sec]

Tx Power

EnergyTime

Figure 15: The effect of node density on energy consumptionand total flooding time for DutyCode.

cycling. The results are presented in Figure 14. Asshown, DutyCode consumes less energy than NoCode.Interestingly, NoCode consumes less energy than Adap-Code, revealing that, for our scenario, duty-cycling canbe more energy efficient than network coding. Nev-ertheless, by combining network coding with duty cy-cling, DutyCode can achieve more aggressive energysavings.

8.3. Node Density

In this experiment we explore the impact of nodedensity on energy efficiency and total time for flood-ing in DutyCode. We are interested in the effects ofnode density because a higher node density causes morecollisions, thus increasing energy consumption and totaltime for flooding. At the same time, however, a highernode density might also decrease network diameter, as-suming that the network size is fixed, like our testbed.This decrease in the network diameter would result inlower energy consumption and shorter time for flood

0

2000

4000

6000

8000

10000

12000

60 160 260 360 460 10

70

130

190

250

310

370

Energ

y [m

J]

Tim

e [sec]

# Packets

AdapCode EnergyAdapCode Time

DutyCode EnergyDutyCode Time

Figure 16: The effect of total number of packets on energyconsumption and total flooding time.

propagation.In our experiments we varied the TX Power from 3

to 7. For TX Power levels above 7, the network be-comes a single hop network. We keep all other param-eters constant. Our experimental results are shown inFigure 15. The aforementioned effects can be observedfrom Figure 15. As TX Power increased from 3 to 4and from 5 to 6, the energy consumption and time forflooding decreased, due to a reduced network diame-ter (i.e., fewer hopes were needed to reach all nodes inthe network from the source), despite the higher num-ber of collisions. However, for increases of TX Powerfrom 4 to 5 and from 6 to 7, the network diameter re-mained constant. Consequently, only the higher num-ber of collisions influenced the performance, increasingenergy consumption and time for flooding to complete.

8.4. Total Number of Packets

In this experiment we evaluate the impact the totalnumber of packets has on energy efficiency and flood-ing time. We expect that flooding more packets in thenetwork will result in higher energy consumption andlonger time for flooding.

Our performance evaluation results are depicted inFigure 16. We can observe that, as the total num-ber of packets increased, both energy consumption andflooding time increased. This is because more packetsbeing transmitted increase total transmission time andalso the probability of collisions. Interestingly, as thenumber of packets increased from 64 to 512 (700%),power consumption increased by 600%. This incre-ment is not strictly linear because, as the number ofpackets increases, nodes find more appropriate cod-ing schemes, thus decreasing the likelihood of redun-dant/useless transmissions. As a reminder, we note here

15

1000

1250

1500

1750

2000

2250

2500

2750

20 40 60 80 100 25

35

45

55

65

75E

nerg

y [m

J]

Tim

e [sec]

Packet Size [bytes]

EnergyTime

Figure 17: The effect of packet size on energy consumptionand total time for flooding.

that in these sets of experiments we employ the same al-gorithm for deciding the coding scheme, as AdapCode.We investigate the performance of our ECS algorithm inSection 8.8.

It is also interesting to note that in this experiment, al-though energy savings increase from 866mJ to 5,021mJ,when compared to AdapCode, our solution’s savings re-duced from 55% to 48%. We attribute this reduction inpower savings to reduced redundant/useless transmis-sions.

8.5. Packet Size

In this experiment we investigate the effect of packetsize on energy efficiency and total time for flooding.We obtained performance results for packet sizes in therange [28bytes, 108bytes]. We keep all other parame-ters constant.

The results are depicted in Figure 17. As shown, asthe packet size increased, both energy consumption andtotal time for flooding decreased. One can observe thatwhen the packet size increases 3-fold, the energy con-sumption decreases by 33%. This emphasizes that ina packet transmission, the backoff intervals are signifi-cantly longer than the time taken for actual packet trans-mission. From our experiments, it appears that more en-ergy can be saved by sending a few large packets insteadof many small ones. A possible explanation is the goodlink quality in our testbed.

8.6. NACK Interval

In this experiment we investigate the effect NACK in-terval has on energy efficiency and total time of flood-ing. As mentioned before, a node waits for “NACK In-terval” to receive a useful packet without transmitting aNACK). An increase in NACK Interval time is expected

0

1200

2400

3600

4800

6000

7200

300 400 500 600 700

45

60

75

90

105

120

135

Energ

y [m

J]

Tim

e [sec]

NACK Interval [msec]

Adapcode EnergyAdapcode Time

DutyCode EnergyDutyCode Time

Figure 18: The effect of NACK interval on energy consump-tion and total time for flooding.

0

2000

4000

6000

8000

10000

180 280 380 480 580 680 15

35

55

75

95

Energ

y [m

Wh]

Tim

e [sec]

Inter-Page Interval [msec]

AdapCode EnergyAdapCode Time

DutyCode EnergyDutyCode Time

Figure 19: The effect of Inter-Page Interval on energy con-sumption and total time for flooding.

to generate additional delays and potential energy ineffi-ciencies. The NACK intervals we chose are in the range[340msec, 740msec].

The results are depicted in Figure 18. As shown, theincrease in the NACK Interval results in an increasedenergy consumption and total time for flooding, for bothDutyCode and AdapCode. One can also observe thatDutyCode is slightly less affected by longer NACK In-tervals, i.e. the slopes of curves depicting DutyCodeenergy consumption and total time for download aresmaller than for AdapCode.

8.7. Inter-Page Interval

In AdapCode and DutyCode, the source node main-tains a time gap, called Inter-Page Interval, betweensubsequent page transmissions. In this section we in-vestigate the effect this interval has on the energy con-sumption and total time for flooding. For this evalua-tion, we use Inter-Page Intervals in the range [180msec,700msec] while keeping all other parameters constant.

16

0

600

1200

1800

2400

3000

3600

4200

0 10 20 30 40 50 40

60

80

100

120

140

160

Energ

y [m

J]

Tim

e [sec]

Sleep Interval [msec]

DutyCode w/o ECS EnergyDutyCode w/o ECS Time

DutyCode w/ ECS EnergyDutyCode w/ ECS Time

Figure 20: The effect of sleep interval in DutyCode with andwithout ECS.

The results of our evaluation are depicted in Fig-ure 19. We observe that the Inter-Page Interval, overthe rage we considered, does not have a noticeable in-fluence on the energy consumption or the total time forflooding of DutyCode and AdapCode. Consequently,we infer that as long as the increase in Inter-Page Inter-val does not increase the idle time of nodes (i.e., timewhen nodes do not have anything to transmit) in thenetwork, the Inter-Page Interval does not significantlyaffect energy efficiency and total time for flooding ofDutyCode and AdapCode.

8.8. DutyCode with ECS

.In this section, we investigate the performance gain

from integrating ECS with DutyCode. We also examinethe impact of Link Quality Threshold (LQT) on ECS.As presented in Section 4, LQT is a design parameterof ECS. Different LQT values result in different topolo-gies, thereby affecting the performance of ECS.

We measured energy consumption and total floodingtime for both DutyCode with ECS and DutyCode with-out ECS by varying sleep interval. For these experi-ments, LQT= 0.95. We chose this high value (i.e., in-dicating we only used highly symmetric links) to ob-tain accurate coding schemes (i.e., children and parentnodes can communicate symmetrically) and ensure suf-ficient redundancy for packet decoding. The results aredepicted in Figure 20. The patterns for energy consump-tion and flooding time of DutyCode with ECS was sim-ilar to that of DutyCode. The graph also shows that Du-tyCode with ECS outperforms DutyCode without ECS,by approximately 10%.

We also measured the total number of packet trans-missions for both DutyCode with ECS and DutyCodewithout ECS, by varying LQT. The results are shown

0

1500

3000

4500

6000

7500

9000

0.8 0.9 0.95

Nu

mb

er

of

Pa

cke

ts

Link Quality Threshold (LQT)

DutyCode w/ ECSDutyCode w/o ECS

Figure 21: The effect of LQT on the total number of packetstransmitted in the network.

0

1500

3000

4500

6000

7500

9000

LPL RLPL LPL/RLPL

Energ

y [m

J]

Mode

Figure 22: The effect of MAC protocol on the energy con-sumption of DutyCode.

in Figure 21. As expected, DutyCode with ECS out-performs DutyCode without ECS, in terms of the to-tal packet transmissions, regardless of LQT. As LQTincreases from 0.8 to 0.9, the total number of packettransmissions for DutyCode with ECS decreased. Thisis because at higher LQT (i.e., higher symmetry in com-munication), the coding schemes derived are more ac-curate. Interestingly, the increase of LQT from 0.9 to0.95 actually increased the total number of transmis-sions. This is because the total number of valid links(i.e., links above the threshold) tends to decrease withextremely high LQT, thereby allowing only very few re-dundant transmissions.

8.9. LPL/RLPL Mode Transition

To assess the effects of LPL/RLPL Mode Transition,we evaluate DutyCode is LPL mode, in RLPL modeand in the LPL/RLPL “protocol transition” mode. TheSleep Interval value we chose is 45msec for these ex-periments. This is because DutyCode in RLPL modeachieves higher energy savings, when compared to Du-tyCode in LPL mode, at this value for the Sleep Inter-

17

val. We measure the energy consumption over a timeperiod of 150sec. To be noted is the fact that the execu-tion of the flooding application is less than 150sec. Thelonger time interval allows us to illustrate inefficienciesin RLPL, when network flooding is not present.

The results are shown in Figure 22. As expected, theenergy consumption of RLPL mode is high as the nodesare awake most of the time, even when the flooding ap-plication does not execute. As shown, the LPL/RLPL“protocol transition” mode is 20% more energy efficientthan the LPL mode.

9. Related Work

In the area of duty cycling, research has often ex-amined low power listening (LPL) and scheduling. B-MAC [4] is a simple LPL protocol with periodic listen-ing that requires no synchronization. However, in hightraffic networks, throughput is impacted. X-MAC [7]improves B-MAC by using ACKs, but suffers similar in-efficiencies in networks using broadcast. Wise-MAC [8]enhances efficiency by creating opportunities for syn-chronization, but is designed for low traffic networks.In SPAN [9], average sleep time is lengthened but com-mon network configurations cause power exhaustion innodes on high traffic routes. S-MAC [10] uses adaptive,periodic sleep, and clustering. Although it is efficientat low bandwidth, performance degrades at higher net-work loads. T-MAC [11] enhances S-MAC by reducingthe awake period even more. However, nodes frequentlymiss useful packets while asleep. SCP [12] saves powerby scheduling coordinated transmission and listen pe-riods. However, high network loads reduce sleep op-portunities. DW-MAC [13] is another scheduling pro-tocol that allows nodes to wake up on demand. AS-MAC [14] achieves scheduling through periodic hellopackets but fails to optimize efficiency because the hellopacket has to be transmitted at the wake up intervalsof each neighbor. RI-MAC [15] is a receiver initiatedMAC protocol with an aim to reduce the idle-listening.But, scheduling algorithms do not apply for broadcastapplications. The sleep and awake durations (i.e., dutycycle) for each node are computed as an optimizationproblem for unicast transmissions [16]. Opportunisticflooding [17] and Schm-Dist [18] save energy in a lowduty-cycling networks by treating broadcast transmis-sions as unicasts. ADB [19] achieves efficient broadcastin asynchronous duty-cycling networks, through collab-oration among nodes achieved by additional informa-tion in the packet footer. These technique may not scaleto large scale and message intense networks because

each transmission is handled as a transmission to eachneighbor individually.

A variety of network coding approaches have alsobeen proposed. With COPR [20], Cui, et.al. maximizethroughput by combining several unicast packets intoa single broadcast packet. BEND, Zhang, et.al. [21]improves packet delivery rates, reducing retransmis-sions, but negates much of the energy savings by for-warding multiple copies of the same packet. Energy-efficiency at intermediate nodes was examined in [22]where Markov chains were used to determine bounds onenergy consumption. Inspired by Reed-Solomon codes,network coding based on raptor codes is proposed forvideo streaming on lossy packet networks in [23]. De-creased errors contribute to higher throughput and re-duced power consumption in [24]. Multimedia through-put and energy-efficiency in wireless networks is exam-ined in [25]. However, existing coding schemes did nottake duty cycling into consideration. CODEB [26] usesReed-Solomon based coding algorithm for achievingoptimal coding. Cluster based network coding schemeis proposed in [27], to minimize the redundancy in mes-sages transmitted. But these schemes are done for uni-cast message patterns. Similarly, TEEM [28], Max-MAC [29] and BEAM [30] are traffic aware MAC pro-tocols that deal with unicast messages. P-MAC [31]may not scale to a large, message-intense network, asit requires periodic traffic pattern update to achieve traf-fic aware duty-cycling.

In [1], we investigated the integration of network cod-ing with duty-cycling in flood-based WSN. This articleimproves the energy efficiency of [1] by proposing ECS,a coding decision algorithm that minimizes the redun-dant packet transmissions, thereby saving more energy.Furthermore, an adaptive transition technique accom-plishes a smooth and timely transition between LPL andRLPL without packet loss.

10. Conclusions

Network coding and duty-cycling are two populartechniques for saving energy in wireless sensor net-works. In this article, we demonstrate that although theyachieve energy efficiency by conflicting means, theycan be combined for more aggressive energy savingsin flood-based sensor network applications. To achieveaggressive energy savings we propose DutyCode, a net-work coding friendly MAC protocol which implementspacket streaming and allows the application to decidewhen a node can sleep. Through analysis and realsystem implementation we demonstrate that DutyCode

18

does not incur higher overhead than state of art solu-tions, and that it achieves up to 46% more energy sav-ings when compared with network coding-based solu-tions that do not use duty-cycling. The proposed schemerequires minimal changes to existing network codingapplications. We also present ECS, a technique that op-timizes the network coding scheme of each node. Wedevelop an integrated network coding with duty cyclingsolution, which allows smooth MAC protocol transitionbetween LPL (i.e., more energy efficient when floodingis not taking place) and RLPL, which is more energy ef-ficient when network flooding occurs. We demonstratethe effectiveness and practically of our proposed solu-tions analytically and through real system implementa-tion and evaluations.

Acknowledgements

The authors would like to thank Manish KumarSingh, who participated in the initial discussions of theproject. This work was supported in part by NSF grants#0923203, #1127449, #1145858.

References

[1] R. Chandanala, R. Stoleru, Network coding in duty cycledsen-sor networks, in: International Conference on Networked Sens-ing Systems (INSS), 2010.

[2] R. Ahlswede, N. Cai, S.-Y. R. Li, R. W. Yeung, Network infor-mation flow, IEEE Trans. Inf. Theory 46 (2000) 1204–1216.

[3] I.-H. Hou, Y.-E. Tsai, T. F. Abdelzaher, I. Gupta, AdapCode:Adaptive network coding for code updates in wireless sensornetworks, in: Proceedings of INFOCOM, 2008.

[4] J. Polastre, J. Hill, D. Culler, Versatile low power media accessfor wireless sensor networks, in: Proceedings of SenSys, 2004.

[5] P. Dutta, J. Taneja, J. Jeong, X. Jiang, D. Culler, A buildingblock approach to sensornet systems, in: Proceedings of SenSys,2008.

[6] Texas Instruments Inc., CC2420 Data Sheet.[7] M. Buettner, G. V. Yee, E. Anderson, R. Han, X-MAC: a short

preamble MAC protocol for duty-cycled wireless sensor net-works, in: Proceedings of SenSys, 2006.

[8] A. El-Hoiydi, J.-D. Decotignie, WiseMAC: An ultra low powerMAC protocol for the downlink of infrastructure wireless sensornetworks, in: Proceedings of ISCC, 2004.

[9] B. Chen, K. Jamieson, H. Balakrishnan, R. Morris, SPAN:an energy-efficient coordination algorithm for topology main-tenance in ad hoc wireless networks, Wirel. Netw. 8 (5) (2002)481–494.

[10] W. Ye, J. Heidemann, D. Estrin, An energy-efficient MAC proto-col for wireless sensor networks, in: Proceedings of INFOCOM,2002.

[11] T. V. Dam, K. Langendoen, An adaptive energy-efficient MACprotocol for wireless sensor networks, in: Proceedings of Sen-Sys, 2003.

[12] W. Ye, F. Silva, J. Heidemann, Ultra-low duty cycle MAC withscheduled channel polling, in: Proceedings of SenSys, 2006.

[13] Y. Sun, S. Du, O. Gurewitz, D. B. Johnson, DW-MAC: a low la-tency, energy efficient demand-wakeup MAC protocol for wire-less sensor networks, in: Proceedings of MobiHoc, 2008.

[14] B. Jang, J. B. Lim, M. Sichitiu, AS-MAC: An asynchronousscheduled MAC protocol for wireless sensor networks, in: Pro-ceedings of MASS, 2008.

[15] Y. Sun, O. Gurewitz, D. B. Johnson, RI-MAC: a receiver-initiated asynchronous duty cycle MAC protocol for dynamictraffic loads in wireless sensor networks, in: Proceedings of Sen-Sys, 2008.

[16] S. C. Ergen, C. Fischione, D. Marandin, A. L. Sangiovanni-Vincentelli, Duty-cycle optimization in unslotted 802.15.4 wire-less sensor networks, in: Proceedings of GLOBECOM, 2008.

[17] S. Guo, Y. Gu, B. Jiang, T. He, Opportunistic flooding in low-duty-cycle wireless sensor networks with unreliable links, in:Proceedings of Mobicom, 2009.

[18] J. Hong, J. Cao, W. Li, S. Lu, D. Chen, Sleeping schedule-aware minimum latency broadcast in wireless ad hoc networks,in: Proceedings of IEEE International Conference on Commu-nications (ICC), 2009.

[19] Y. Sun, O. Gurewitz, S. Du, L. Tang, D. B. Johnson, ADB:an efficient multihop broadcast protocol based on asynchronousduty-cycling in wireless sensor networks, in: ProceedingsofSenSys, 2009.

[20] T. Cui, L. Chen, T. Ho, Energy efficient opportunistic networkcoding for wireless networks, in: Proceedings of INFOCOM,2008.

[21] J. Zhang, Y. Chen, I. Marsic, Network coding via opportunis-tic forwarding in wireless mesh networks, in: Proceedings ofWCNC, 2008.

[22] J. Goseling, R. Boucherie, J.-K. van Ommeren, Energy con-sumption in coded queues for wireless information exchange,in: Proceedings of Network Coding, Theory, and Applications,2009.

[23] N. Thomos, P. Frossard, Raptor network video coding, in: MV’07: Proceedings of the international workshop on Workshoponmobile video, 2007.

[24] Y. Xiao, L. Ma, K. Khorasani, A. Ikuta, A new robust narrow-band active noise control system in the presence of frequencymismatch, IEEE Transactions on Audio, Speech & LanguageProcessing 14 (6) (2006) 2189–2200.

[25] X. Tao, C. Zhang, J. Lu, Network coding for energy efficientwireless multimedia transmission in ad hoc network, in: Pro-ceedings of International Conference on Communication Tech-nology (ICCT), 2006.

[26] L. Li, R. Ramjee, M. Buddhikot, S. Miller, Network coding-based broadcast in mobile ad hoc networks (2007).

[27] T.-G. Li, C.-C. Hsu, C.-F. Chou, On reliable transmission byadaptive network coding in wireless sensor networks, in: Pro-ceedings of ICC, 2009.

[28] H. Gong, J. Cao, M. Liu, L. Chen, L. Xie, A traffic aware, energyefficient MAC protocol for wireless sensor networks, Int. J. AdHoc Ubiquitous Comput. 4 (3/4) (2009) 148–156.

[29] P. Hurni, T. Braun, MaxMAC: A maximally traffic-adaptiveMAC protocol for wireless sensor networks, in: ProceedingsofEWSN, 2010.

[30] M. Anwander, G. Wagenknecht, T. Braun, K. Dolfus, Beam:Aburst-aware energy-efficient adaptive mac protocol for wirelesssensor networks, in: International Conference on NetworkedSensing Systems (INSS), 2010.

[31] T. Zheng, S. Radhakrishnan, V. Sarangan, PMAC: An adaptiveenergy-efficient MAC protocol for wireless sensor networks, in:Proceedings of IPDPS, 2005.

19