Network Coding in Duty-Cycled Sensor Networks

Transcription

1 1 Network Coding in Duty-Cycled Senor Network Roja Chandanala, Radu Stoleru, Member, IEEE Abtract Network coding and duty-cycling are two popular technique for aving energy in wirele adhoc and enor network. To the bet of our knowledge, the idea to combine thee two technique, for more aggreive energy aving, ha not been explored. One explanation i that thee technique achieve energy efficiency through conflicting mean, e.g., network coding ave energy by exploiting overhearing, wherea duty-cycling ave energy by cutting idle litening and, thu, overhearing. In thi paper, we evaluate the ue of network coding in duty-cycled enor network. We propoe a cheme, called DutyCode, in which a MAC protocol implement packet treaming and allow the application to decide when a node can leep. We invetigate our cheme analytically and implement it on mote hardware. We evaluate our olution in a 42-node indoor tetbed. Performance evaluation reult how that our cheme ave 2-3% more energy than olution that ue network coding, but do not ue duty-cycling. I. INTRODUCTION Energy i a carce reource in wirele enor network (WSN) and conervation of energy ha been the ubject of extenive reearch. While a variety of olution have been propoed, duty cycling and network coding have proven to be two of the mot ucceful technique in thi field. Network coding i a technique that increae energy efficiency and reduce network congetion by combining packet detined for ditinct uer. Since the initial propoal by Ahlwede [1], many application have incorporated thi idea. Network coding i particularly well-uited for WSN due to the broadcat nature of their communication. Overhearing i effortle, propagation i uually ymmetric, and energy efficiency i a priority. Network coding can be found in application including multi-cat, content ditribution, delay tolerant network (DTN), underwater ening uite, code diemination, torage, and ecurity. A divere a thee application are, they all hare a common aumption: node in the network are alway awake. Duty cycling i a technique that increae energy efficiency by allowing a node to turn off part or all of it ytem for period of. Encompaing a range of technique from peripheral management to almot complete ytem hutdown, duty cycling extend node life and reduce maintenance. When done properly, duty cycling can extend battery life by an order of magnitude or more. In WSN, duty cycling i pervaive and almot all deployed ytem integrate ome level of it. Given the importance of duty cycling to WSN, the aumption that node will be awake cannot be made. Since node will be aleep at leat part of the, network coding become more difficult becaue the available for overhearing i reduced. Sleep cycle uing a fixed interval a hort a 3m Roja Chandanala and Radu Stoleru are with the Department of Computer Science and Engineering, Texa A&M Univerity, College Station, TX 7784 USA ( {rojac, toleru}@ce.tamu.edu) reult in increaed energy conumption and delay intead of hrinkage. In thi paper we addre the challenge faced when aggreive (i.e., both duty-cycling and network coding are employed) energy aving are mandated in flooding-baed WSN application. We particularly target application uch a code diemination that require a non-negligible amount of, poibly ten of minute in large cale enor network. Since network coding mandate node to be awake to make the maximum ue of coding/decoding opportunitie, it may eem inefficient to allow node to leep. Our main idea i derived from the intuition that, due to the redundancy of coding, there are period of when a node doe not benefit from overhearing coded packet being tranmitted. We eek to preciely determine thee period of, and let node that do not benefit from thee uele packet, to leep. Our olution i a cro layer approach, where the MAC layer facilitate treaming, random leeping and ynchronization, and the network coding-aware application layer determine, baed on the tream being tranmitted, the to leep and the leep duration. The prerequiite of our olution i that network coding be applied individually to a equence of packet, called page. The packet that are to be coded within a page i random, however. The contribution of our paper include: A media acce control (MAC) protocol that upport treaming. Thi allow node to ue tream to predict packet arrival. A mechanim for randomizing leep cycle uing elatic interval. Thi allow node to intelligently elect leep period. Energy and delay model and imulation demontrating the energy efficiency and throughput of thi olution. An implementation on mote hardware and performance evaluation in 42-node tetbed where actual energy conumption i meaured. Thi paper i organized a follow. Section II motivate our work and provide background on network coding. Section III and IV preent our cheme for network coding in duty-cycled environment, and it analyi, repectively. Section V and VI decribe the implementation and performance evaluation of our cheme. We review the tate of art in Section VII and conclude in Section VIII. II. MOTIVATION AND BACKGROUND Network coding enhance energy efficiency by reducing the number of tranmiion. The baic concept of network coding can be explained uing a imple cenario [2]. Sender 1 want to end a packet to t 1 and ender 2 want to end another packet x 2 to t 2, a hown in Figure 1(a) and 1(b). At total of /1/$ IEEE

2 2 1 t2 r1 x 2 r2 x 2 x2 (a) 2 t1 1 t2 1 x r1 r2 2 x + 1 x x1+x2 Fig. 1. a) Without network coding 6 tranmiion are required for ending packet and x 2 from 1 and 2 to t 1 and t 2, repectively; b) with network coding, only 4 tranmiion are ufficient. (b) x2 2 t1 x AdapCode Energy 7 AdapCode Time Sleep Interval [mec] Fig. 3. Execution of X-MAC-enabled AdapCode on a 42 epic mote tetbed. Energy per node and total execution a function of the Sleep Interval parameter of X-MAC r 2 t 2 +x 2 (a) 1 r 2 t 2 Preamble (b) Preamble +x 2 +x 2 Fig. 2. Network coding integrated with (a) tatic leeping chedule (b) Low Power Litening baed on long preamble. ix tranmiion are required to deliver the two packet when network coding i not ued (Figure 1(a)). However, Figure 1(b) how that, when network coding i ued, only 4 tranmiion are needed becaue the two relay can tranmit only one coded packet ( +x 2 ) intead. For network coding to work, receiver t 1, t 2 mut be able to overhear packet and x 2 from 1 and 2, repectively. Otherwie, they will be unable to decipher anything from the coded packet received. It i important to note that, unlike normal broadcat packet, one miing coded packet can render a equence of coded packet uele (i.e., they do not convey any information). Conider a cenario where a node receive the following independent coded packet: a 1 + a 2 x 2 + a 3 x 3 + a 4 x 4 b 1 + b 2 x 2 + b 3 x 3 + b 4 x 4 c 1 + c 2 x 2 + c 3 x 3 + c 4 x 4 Receiving another coded packet: d 1 +d 2 x 2 +d 3 x 3 +d 4 x 4, i critical for thi node in order to decode all the packet. Otherwie all 3 received packet are uele. A the coding cheme (i.e the number of different packet coded into a ingle packet) increae, the penalty for looing a ingle packet increae linearly. A previouly noted, mot exiting duty-cycling protocol achieve energy aving through tatic leeping or cheduling. However, for network coding, cheduling i not a feaible olution becaue overhearing i required. If ender were aware of the detination of each packet, it might be poible to only tranmit when the appropriate receiver were awake. However, ender are typically unaware of the identity of every receiver. Alo, the coordination required to enure that all intended receiver were awake at the ame could be prohibitively cotly. Static leeping i imilarly unuited due to the high likelihood of miing a ueful packet while aleep. Conider the example in Figure 1(b) when network coding i ued with duty-cycling, and two olution, (illutrated in Figure 2(a) and Figure 2(b)): a rigid, tatic duty cycle, or Low Power Litening [3]. A hown in Figure 2(a) if node t 2 doe not receive the coded packet, it will not be able to obtain the packet detined for it, namely x 2. If LPL i ued, a depicted in Figure 2(b) the total for execution i increaed, cauing coniderable energy expenditure becaue of the overhead caued by preamble tranmiion. And thi overhead increae with the increae in LPL interval. To validate our obervation we performed experiment on a tetbed of 42 epic mote and 256 packet of data to be tranmitted to all the mote from a ource. We integrated AdapCode [4], a code diemination application that ue network coding, with X-MAC [5], a frequently ued MAC protocol that allow duty cycling. The reult of our experiment, in which we varied the LPL leep interval parameter (indicative of the duty-cycle deired), are depicted in Figure 3. Although ome degradation due to mied tranmiion wa expected, epecially at longer leep interval, energy conumption wa generally expected to decreae. Intead, even uing very hort tatic leep interval nearly doubled the execution and energy conumption. From thee reult, it wa clear that: i) a node hould elect leep interval intelligently at nontatic interval; and ii) long preamble baed MAC olution are not uitable for network coding application. The problem formulation that emerged wa for each node to predict the likelihood of receiving packet and decide to leep if the packet are likely to be uele. III. NETWORK CODING IN DUTY-CYCLED WSN The core problem of combining duty-cycling and network coding i non-intelligent duty-cycling. Our olution tackle thi problem by providing a framework to keep a node informed of the future packet without any ue of control packet. Thi knowledge make a node capable of employing mart dutycycling. The fundamental principle of our olution i that each node tream all the packet of a logical entity (i.e., page) in a row. Thi tream i ueful for node lacking the data being tranmitted, otherwie it i uele. Upon receiving the firt packet a node tay awake and receive all packet if they are ueful, otherwie the node leep for the duration of the tream. A node can compute the duration of tream a the tranmiion per packet the remaining packet of tream.

3 3... C n IP C 1 C 2 C 3 C 4 N R 4 C1 C2 C3 C4 r C 1 C 2 BO i,c BO i,c C 3 BO i,c NACK N R 4 r 1 C1 leep Fig. 4. The NetCode protocol: C i are coded packet, N i a NACK packet, due to miing packet C 4, R 4 i the ReNACK packet - the non coded packet miing, IP i the Inter- Interval, BO i,c i the backoff interval - initial and congetion (NOTE: the backoff i between any two packet), NACK i a r. Duty Cycle NC App RLPL (a) r... C n IP BO 1i,1c C 1 C 2 C 3 C 4 C 1 (b) BO 2i,2c C 2 C 3 C 4 Fig. 5. (a) DutyCode architecture; (b) Streaming in DutyCode: after the backoff interval, BO 1 and BO 2 packet in a page are treamed. A. Preliminarie In thi ubection we introduce a typical application, called NetCode, that ue network coding for energy efficiency. We decribe it operation in detail becaue we aim to analytically demontrate, in the ection that follow, that the introduction of our mart duty-cycle doe not come with any major overhead. The operation of NetCode i depicted in Figure 4. In NetCode, when a ource node, e.g., a bae tation, want to dieminate a new program image in the network, broadcat the data a page. Each page conit of a number of packet. After tranmitting a page, the ource wait for a hort period of for the code propagation, and ubequently end the next page. The interval that eparate two page i called Inter- Interval (IP in Figure 4). NetCode typically ue CSMA a a MAC protocol. All node, after receiving packet, adaptively chooe an appropriate coding cheme (i.e. the number of packet to be coded in a ingle packet) or have a predefined one. The appropriate coding cheme i choen baed on the number of neighbor. If a node doe not receive any packet for a random period of (called NACK delay in Figure 4), it broadcat a NACK packet (labeled N in Figure 4), indicating the exact packet that it mie. Upon receiving a NACK, all node having the page that contain the requeted packet, et a random backoff r (called ReNACK delay ). The node with the mallet ReNACK delay interval win and tranmit all the requeted packet (packet R 4 in Figure 4). A with exiting CSMA protocol, NetCode ue a Backoff r for acceing the medium before tranmitting any packet. Thi backoff r ha, typically, two value: an initial value, and a congetion value, elected randomly a depicted in Figure 4 from BO i and BO c range, repectively. B. Propoed Solution Our olution, called DutyCode and hown in Figure 5(a), i an integrated cheme (i.e., MAC - NetworkCoding applica- r 2 C1 C2 C3 C4 awake Fig. 6. Streaming when no packet are awaiting tranmiion at r 1 and r 2 tion ) in which the MAC layer facilitate treaming, random leeping and ynchronization. The application determine the to leep and the leep duration baed on it knowledge about the tream being tranmitted. The prerequiite of our olution are: i) packet are grouped into logical entitie, called page; and ii) network coding i limited to the packet from ame logical entity. The propoed MAC protocol, Random Low-Power- Litening (RLPL), allow: i) packet treaming; ii) tranmiion defer; and iii) tranmiion arbitration. When requeted by network coding (NC) application, RLPL turn off the radio for the requeted duration if there i no pending tranmiion. The NC application pecifie the leep duration when it requet the node to leep. RLPL doe not put the node to leep periodically. When requeted, and if feaible, RLPL hut down the radio for the requeted period. Unlike other duty-cycling protocol (e.g., DefaultLPL in TinyOS 2.1) it doe not perform Clear Channel Aement (CCA) before turning off the radio. The reaon for thi i that the CCA would not have any meaning, ince requet for leep come from the NC application when there i, typically, ongoing radio communication (e.g., treaming of uele packet). We define uele packet a the packet pertaining to a page which wa already decoded by the receiving node. We define SI, Sleep Interval a the duration per packet, for which a node leep upon receiving a packet from a uele tream. C. Packet Streaming For treaming, RLPL et different initial and congetion backoff interval for packet tranmiion. The operation of DutyCode i depicted in Figure 5(b). The firt two packet of the tream are tranmitted normally with random backoff interval choen from different range and the ret of the tream i ent without any backoff. In treaming, the penalty for tranmiion colliion i high. To reduce colliion, the firt two packet of the tream are ent with large random backoff interval. A hown, backoff interval for the firt packet and econd packet are elected from BO 1 and BO 2 repectively (each ha one initial, and one congetion value: BO 1i, BO 1c and BO 2i, BO 2c ). Application can et thee value according to the reliability of the network. Upon receiving a tream packet, a node yield if it ha no packet awaiting tranmiion. A hown in Figure 6, upon receiving a tream from node, node r 1 and r 2 do not proce any tranmit requet coming from their NC application, for the duration of the tream from. A hown, becaue r 1 ha the page being tranmitted by, it leep for the duration

4 4 C1 C2 C3 C4 r1 r2 C1 leep C1 C2 C3 C4 awake r 1 X C2 C3 C4 X (a) C2 C3 C4 r 1 X C2 C3 D2 D3 D4 X (b) C2 D2 D3 D4 Fig. 7. Streaming with tranmiion defer (vertical dotted arrow) at node r 1 and r 2. Fig. 8. Tranmit arbitration (on packet X colliion) baed on node ID: a) when r 1 > ; and b) node r 1. Vertical dotted arrow repreent packet tranmiion deferred. of the tream. After r 1 wake up, it trie to tranmit any pending packet. Similarly, node r 2 tay awake and receive all treamed packet. Node r 2 handle it packet tranmiion requet, either after it receive the lat packet of the tream from node or after the expected tream duration i over, whichever happen firt. D. Tranmiion Defer In Figure 7, node r 1 and r 2 yield to node. Thi i imilar to the cae of regular treaming (Figure 6, except that node r 1 and r 2 defer packet tranmiion. At any the application can only have one pending tranmiion. Hence, r 1 and r 2 handle the deferred packet tranmiion when they realize that the tream tranmiion by node i over. Deferred packet i handled a a new tranmiion requet i.e., the node back off for the duration elected randomly from initial backoff interval. A tranmiion defer i imilar to tranmiion cancelation except that it i completely handled in MAC. RLPL handle the deferred and pending packet after the leep interval i over and radio i turned on. E. Tranmiion Arbitration Upon receiving a packet of a tream from node, node r 1 yield to if r 1 >, where and r 1 are unique node ID. In Figure 8(a), r 1 yield to becaue there hould only be one active tream tranmiion. When a node yield to another node, it defer it tranmiion, if feaible. A node doe not tranmit any packet until it receive the lat packet of the tream it i yielding to, or the expected duration of the tream i over, whichever happen firt. Similarly, a hown in Figure 8(b), node yield to node r 1 becaue r 1 <. It i important to oberve that, becaue of thi arbitration, a node which decide to leep becaue it detect a tream by node, may mi ueful packet being tranmitted by r 1, if node yield to r 1. We choe to allow thi cenario becaue, intead of under-utilizing the channel by not tranmitting any tream, we prefer to allow ome node tranmit it tream. IV. DUTYCODE PROTOCOL ANALYSIS In thi ection we analyze the operation of the propoed DutyCode cheme. The aim of our analyi are i) To how that the propoed duty-cycling enabled network coding doe not have any overhead, when compared with exiting network coding application, uch a NetCode. ii) To analyze the effect of backoff interval on the execution. The two metric we invetigate are the total number of packet per page, and the total execution of our cheme. We denote by pp the number of packet per page, c the coding cheme, cp the colliion probability in NetCode, and cp 1 and cp 2 the colliion probabilitie aociated with BO 1 and BO 2 in DutyCode (a decribed in the previou ection), BO c the CSMA congetion backoff interval and t tr the actual tranmiion per packet. We aume that the leep interval per packet, SI i choen uch that there i no overhead due to leeping (i.e., tream duration i much longer than leep interval): SI pp/c (BO 2i /2 + pp/c t tr ). Becaue, NetCode i meage intene there i alway a node waiting to tranmit a packet with congetion backoff interval choen randomly between and BO c. Becaue the backoff i uniformly ditributed, the average backoff interval i BO c /2 and the average colliion probability i cp. Similarly, in DutyCode, the average backoff for the firt packet of tream i BO 1i /2. The reaon for thi i that in DutyCode, becaue of packet defer, the firt packet of a tream i alway tranmitted with a backoff interval choen from to BO 1i. Hence, the average backoff interval for the firt packet i BO 1i /2 and the average colliion probability for the firt packet of the tream i cp 1. The colliion probability for the econd packet of the tream i cp 1 cp 2, becaue there could be colliion during the tranmiion of econd packet if and only if there wa colliion during the firt packet tranmiion. A. Total Number of Packet Tranmitted Theorem 1. If BO 1i BO c then Pp d Pp a, where Pp d and Pp a are the total number of packet for DutyCode and NetCode, repectively. Proof 1. In both DutyCode and NetCode, three type of packet can contribute to the total number of packet: ) coded packet; b) NACK packet; and c) ReNACK packet. Coded Packet: Coded packet are the packet tranmitted by a node, obtained after coding (i.e., baed on a coding cheme). Hence, the number of coded packet per page C p i given by: C p = pp/c. Since the coding cheme i the ame in DutyCode and NetCode: C a p = C d p (1) where C a p and C d p are the number of coded packet for NetCode and DutyCode, repectively. NACK Packet: A node end a NACK when it i unable to decode a page. There are two reaon for NACK: i) unable to receive enough independent packet needed for decoding a page; and ii) colliion;

5 5 i) independent packet: Becaue DutyCode ue the ame coding cheme a NetCode, thi factor ha no impact on the total number of packet. Hence, we do not conider it. ii) colliion: In NetCode, the maximum the number of NACK per packet i N = cp+2cp , i.e., with probability cp, the node need to end 1 NACK. If a colliion occur during the NACK tranmiion, the node may have to tranmit 2 NACK packet with cp 2 probability. The total number of NACK per page i: N a p = (pp/c)(cp + 2cp ) For DutyCode, the NACK can be ent a a reult of two cenario: i) colliion during firt packet tranmiion (cp 1 ); ii) colliion during econd packet tranmiion (cp 1 cp 2 ). Thu, the total number of packet per page i: N d p = (cp 1 + cp 1 cp 2 ) + 2cp 1 (cp 1 + cp 1 cp 2 ) + 3cp 2 1(cp 1 + cp 1 cp 2 ) +.. = (1 + cp 2 ) (cp 1 + 2cp ) Since the colliion probability of a tranmiion, cp, i inverely proportional to the backoff interval range BO, i.e., cp 1/BO, then cp = k 1 /BO and cp 1 = k 2 /BO 1i when DutyCode and NetCode are run in the ame network with imilar parameter k 1 = k 2. cp 1 cp = BO c BO 1i (2) If backoff interval are choen uch that BO 1i BO c, then, from Equation 2: cp 1 cp (3) From Equation 3, when pp/c (1 + cp 2 ) and BO 1i BO c then: N d p N a p (4) For DutyCode, it i neceary to enure pp/c (1 + cp 2 ) otherwie there would only be 1 packet in the tream, and there would not be any opportunity for leeping. It would be very eay to increae packet per page with an increae in coding cheme. One might argue that a node may mi ome ueful packet while aleep. A node goe to leep, however, only after receiving a ueful packet tream. If there i only one tream then the node would not mi any ueful packet. Only becaue of colliion there could be multiple tream at a. Hence, the NACK due to colliion cover thi part. ReNACK Packet: ReNACK are the regular packet with no coding. In NetCode, if there i a colliion while tranmitting a coded packet, it may need to end all the packet coded into that meage which i the coding cheme. So, for each coded packet which i pp/c per page, the node need to retranmit c with probability cp. Similar to NACK it need to tranmit thee packet twice with probability cp 2. Hence, the number of ReNACK per page i: R a p = c pp/c (cp + 2cp ). For DutyCode, a colliion during a tream tranmiion can be attributed to one of the following: i) a colliion during the tranmiion of firt packet (probability cp 1 ), require that c packet be retranmitted; and ii) a colliion during the tranmiion of the econd packet (probability cp 1 cp 2 ), require that an entire page be retranmitted: c cp 1 + cp 2 cp 1 pp. Auming the wort cae, in which pp packet need to be retranmitted in cae of colliion during the tranmiion of firt packet, the total number of ReNACK per page per node i: R d p = pp (cp 1 + 2cp ) From Equation 3, when BO 1i BO c then: R d p R a p (5) From Equation 1, 4 and 5, and ince Pp a/d + Rp a/d, then Pp d Pp a. N a/d p B. Total Execution Time = C a/d p + Theorem 2. If the backoff interval atify pp/c BO c = BO 1i and BO c = BO 1c, then the total for DutyCode i le than or equal to that of NetCode. Proof 2. In DutyCode, except for NACK all other packet (i.e., coded packet and ReNACK) can be tranmitted a tream. If i the total number of tream in DutyCode then the number of packet to be tranmitted per node i: P d = pp/c + N d (6) In NetCode, the total number of packet can be written, in term of a: P a = pp/c + N a (7) A explained, the average backoff per packet in NetCode i BO c /2. Hence, the total per node i: T a n = P a (BO c /2 + D a t + t tr ) where Dt a i the average delay in NetCode (becaue NetCode packet are not treamed, a mall delay i maintained between ucceive tranmiion). After ubtituting Equation 7, we obtain: T a n = pp/c BO c /2+N a BO c /2+P a D a t +P a t tr (8) For DutyCode, for each tream the average backoff interval i BO 1i /2 except for the tream which i tranmitted after a NACK packet (for a NACK packet, yielding i not done becaue it i not a tream).hence, the wait of tream which i tranmitted right after the NACK i BO 1c /2. Conequently the total per node i: T d n = ( N d ) BO 1i /2 + N d BO 1c /2 + N d BO 1i /2 + P d t tr = BO 1i /2 + N d BO c /2 + P d t tr ince BO 1c = BO c. Thi may give a fale impreion that, by decreaing the backoff interval, the total execution can be decreaed. However, with a decreae in backoff interval, the colliion probability increae, which reult in an increae in the number of NACK and ReNACK. Given that N a N d, P a P d, pp/c BO c = BO 1i. T d n T a n (9)

6 6 Algorithm 1 Streaming Packet Received 1: if (# of remaining pkt > ) then 2: if (any yield cond. i true) then 3: if (# pkt awaiting tranmit > ) then 4: attempt to DEFER pkt tranmiion 5: RLPL ave DEFER reult 6: end if 7: RLPL tart NoSend r 8: end if 9: ele 1: RLPL top NoSend r and handle packet 11: end if Actually pp/c BO c BO 1i BO c i ufficient for proving 9. But, maller BO 1i may reult in increaed colliion probability. In order to avoid thi, we choe the maximum bound for BO 1i, pp/c BO c = BO 1i. Another reaon for thi i that the increae in pp/c increae the penalty for colliion while tranmitting the firt packet of the tream. In order to minimize thi penalty, BO 1i hould alo be increaed ufficiently. When the backoff interval are elected uch that they atify the condition above, the total for DutyCode i equal to that of NetCode. VI. PERFORMANCE EVALUATION We evaluate the performance of DutyCode in an indoor tetbed coniting of 42 epic mote [6] deployed in an approximately 5ft 2 area. Out of the 42 node, 14 are intrumented for power conumption meaurement. The experiment are performed in a 5 hop network, obtained by a TX power etting of 4 for the enor node. Each experimental point repreent the mean of 3 execution of the protocol. Standard deviation i depicted in all our performance evaluation reult. For comparion with tate of art we choe AdapCode [4], a flooding protocol that ue network coding and i repreentative of our NetCode model. The metric we ue for performance evaluation are the per node energy conumption and the total required for the code update. While we are intereted in the energy conumption, we alo aim to not increae the total download. The parameter that we vary are the leep interval (SI), the node denity (ND), the ize of the packet (SP ), the number of packet (NP ), the NACK delay (N ACKD), and the interpage and backoff interval (II and BI, repectively). For thee we ue the following default value: SI=17, ND=4, SP =28, NP =256, NACKD=64, II=3, BI=32. The effect of thee parameter i invetigated and decribed in the remaining part of thi ection. V. IMPLEMENTATION We implemented the DutyCode protocol in nec for TinyOS The implementation wa done in the CC242ReceiveC (Receive) and CC242TranmitC (Tranmit) module. A new module RandomLPL (RLPL) wa created, which differ from the exiting DefaultLPL, a preented in Section III. Due to pace contraint, and the complexity of the deign being concentrated in the Tranmit module we decribe only it implementation in detail. Specifically, we decribe the cenario in which a node receive a tream packet. When treaming i achieved, the application end packet one after the other without any ignificant delay. (i.e., enddone() i ignaled). Each packet header contain the number of remaining packet in the tream, computed baed on the coding cheme ued. Upon receiving a tream packet from neighbor, the Receive module inform the Tranmit. The module interaction i explained in Algorithm 1. After receiving a tream ignal from Receive, Tranmit check if it ha pending packet or the end of the tream ha been reached (line 1). If there are remaining packet in the tream, tranmit check (line 2) if the tream atifie the yielding condition dicued in Section III. If not, no action i taken. Otherwie, if it i in the middle of tranmiion the node trie to defer the packet tranmiion (line 4) and inform RLPL about: i) the detail of the tream tranmiion; and ii) the defer tatu, if there wa a need for packet defer. RLPL then et a NoSend r (line 7) and keep future tranmit requet pending until the tream duration i over or informed by tranmit about completion of tream it i yielding to. Tranmit inform RLPL about the completion of tream upon receiving the ignal from receive for the lat packet of the tream (line 1). A. Sleep Interval In thi experiment we invetigate how leep interval SI affect the energy conumption and total diemination. SI i a critical parameter for DutyCode. We varied the leep interval in the [4mec, 45mec] range, while keeping other parameter contant. The reult are preented in Figure 9. Our initial intuition i that the energy aving hould be incurred with non-zero leep interval, i.e., when a node ha the opportunity to leep. Furthermore, the energy conumption hould decreae further with an increae in leep interval, up to a certain point, after which, the energy conumption would tart to increae again. Experimental reult confirm our intuition. Confirming our analyi in Section IV, energy aving reach maximum when leep interval i 35-44mec where the leep duration matche tream duration. A hown, energy aving of 3% are achieved. B. Node Denity In thi experiment we varied the network denity by changing the radio TX power. The number of packet NP ued wa 64. The reult are depicted in Figure 1 where the tranmiion power i varied from 4 to 31 and the all other parameter are kept contant. The expectation wa that at higher node denitie, the opportunitie for network coding and leeping increae. However, the colliion probability cp increae a well. A expected, energy aving increaed with higher node denity (from 4 to 22) and then deteriorated with increaed denity. A the node denity increae pp, packet per page hould be increaed o that tream per page hould at leat contain more than one coded packet.

7 AdapCode Energy 1 AdapCode Time DutyCode Time Sleep Interval [mec] Fig. 9. The effect leep interval ha on energy conumption and Energy Time Packet Size [byte] Fig. 12. Effect total number of packet ha on energy conumption and total Energy Time Tx Power Fig. 1. The effect node denity ha on energy conumption and total Adapcode Energy 8 Adapcode Time DutyCode Time NACK Interval [mec] Fig. 13. Effect of NACK interval on energy conumption and total AdapCode Energy AdapCode Time DutyCode Time # Packet Fig. 11. Effect total number of packet ha on energy conumption and total. Energy [mwh] AdapCode Energy AdapCode Time DutyCode Time Inter Interval [mec] Fig. 14. Effect page interval ha on energy conumption and total C. Number of Packet We evaluated how the ize of the data to be dieminated (i.e., number of packet) affect the energy aving. The reult are depicted in Figure 11. A the total number of packet to be tranmitted increae, the increae in the chance of packet colliion and the total for tranmiion reult in increaed power conumption. In our experiment, a the number of packet increaed from 64 to 512, power conumption increaed by 5%. Thi increment i not linear becaue, a the number of packet increae, node find the mot appropriate coding cheme and uele tranmiion are decreaed. Although energy aving increae from 45mJ to 165mJ, when compared to AdapCode, our olution aving reduced from 3% to 2%. Thi reduction in power aving can be attributed to reduced redundant tranmiion. D. Packet Size In thi experiment we invetigated the effect of packet ize on energy efficiency and total. The reult are depicted in Figure 12, where equally paced packet ize value are elected in the range [28-18]. A the packet ize increae, the computation required alo increae and the node need a gap between ucceive packet reception. Hence, the minimal backoff interval for the tream packet i increaed by 2mec for packet ize 88 and 18 to minimize the penalty for loing ueful packet. From our experiment, we oberved that the energy conumption i not increaed proportionally with the packet ize.thi i becaue with large packet wated on backoff and computation i le compared to that of mall packet. E. NACK Interval In thi experiment we invetigated the effect NACK interval ha on energy efficiency and total of DutyCode (a explained before, in NetCode a node wait for NACK Interval to receive a ueful packet without tranmitting a NACK). The reult are depicted in Figure 13. The NACK interval are choen from the range [34-74]. An increae in the NACK i expected to generate additional delay. A the NACK interval increae from 34 to 74, the energy aving of our olution decreae from 3% to 25%, a reult of the additional delay and le opportunity for leeping. F. Inter- Interval In typical flooding-baed application that ue network coding, the ource node maintain a gap between ubequent page tranmiion. Thi i a deign parameter of AdapCode. For thi evaluation, we teted NetCode with different interpage interval ranging from 3-7 while keeping all other parameter contant, including N ACKD. The reult of our evaluation of inter-page interval are depicted in Figure 14. A long a the increae in inter-page interval doe not increae the idle in the network (i.e., increae the where node do not have anything to tranmit), the interpage interval doe not affect the total taken and power conumption of both AdapCode and DutyCode. G. Backoff Interval Backoff interval i a deign parameter of DutyCode. Experiment were run with different backoff interval elected from the range [8, 48] to evaluate the effect of backoff interval on power conumption of each node and the total delay.

8 8 Fig DutyCode Time Backoff Interval [mec] Effect backoff interval ha on energy conumption and total. A explained in Section IV, decreaing the backoff interval beyond an optimal value, doe not decreae the total taken. Our experimental reult are depicted in Figure 15. A hown, a backoff interval increae from 8 to 16, total and energy conumption decreae. However, a further increae in backoff interval reulted in an increaed total taken for the download and, thu, increaed energy conumption. Hence, the optimal value of the backoff interval BO 1i i 16. For the ret of the performance evaluation experiment, the BO 1i i et to 32mec o that there i no increae in the total and colliion probability. It can be oberved that the taken by DutyCode i le than or equal to that of AdapCode in all performance evaluation figure except for few outlier. VII. RELATED WORK In the area of duty cycling, reearch ha often examined low power litening (LPL) and cheduling. B-MAC [3] i a imple LPL protocol with periodic litening that require no ynchronization. However, in high traffic network, either throughput or leep i impacted. X-MAC [5] improve B-MAC but uffer imilar inefficiencie in network uing broadcat. Wie-MAC [7] enhance efficiency but i deigned for low traffic network. In SPAN [8], average leep i lengthened but common network configuration caue power exhaution in node on high traffic route. S-MAC [9] ue adaptive, periodic leep, and clutering. Efficient at low bandwidth, performance degrade at higher network load. T-MAC [1] enhance S- MAC by reducing the awake period even more. However, node frequently mi ueful packet while aleep. SCP [11] ave power by cheduling coordinated tranmiion and liten period. However, high network load reduce leep opportunitie. Packet treaming increae throughput but limitation on treaming tart can caue delay. A variety of network coding approache have alo been propoed. With COPR [12], Cui, et.al. maximize throughput by combining everal unicat packet into a ingle broadcat packet. BEND, Zhang, et.al. [13] improve packet delivery rate, reducing retranmiion, but negate much of the energy aving by forwarding multiple copie of the ame packet. Energy-efficiency at intermediate node wa examined in [14] where Markov chain were ued to determine bound on energy conumption VIII. CONCLUSIONS Network coding and duty-cycling are two popular technique for aving energy in wirele adhoc and enor network. In thi paper we demontrate that although they achieve energy efficiency by conflicting mean, they can be combined for more aggreive energy aving. To achieve thee energy aving we propoe DutyCode, a network coding friendly MAC protocol which implement packet treaming and allow the application to decide when a node can leep. Through analyi and real ytem implementation we demontrate that DutyCode doe not incur higher overhead, and that it achieve 2-3% more energy aving when compared with network coding-baed olution that do no ue duty-cycling. The propoed cheme require minimal change to exiting network coding application. We leave for future work an extenion of our olution in which the length of the tream can be learned. Acknowledgement Thi work wa funded, in part, by NSF grant CNS REFERENCES [1] R. Ahlwede, N. Cai, S.-Y. R. Li, and R. W. Yeung, Network information flow, IEEE Tran. Inf. Theory, 2. [2] C. chun Wang, Beyond the butterfly a graph-theoretic characterization of the feaibility of network coding with two imple unicat eion. [3] J. Polatre, J. Hill, and D. Culler, Veratile low power media acce for wirele enor network, in Proceeding of SenSy, 24. [4] I.-H. Hou, Y.-E. Tai, T. F. Abdelzaher, and I. Gupta, Adapcode: Adaptive network coding for code update in wirele enor network, in Proceeding of INFOCOM, 28. [5] M. Buettner, G. V. Yee, E. Anderon, and R. Han, X-mac: a hort preamble mac protocol for duty-cycled wirele enor network, in Proceeding of SenSy, 26. [6] P. Dutta, J. Taneja, J. Jeong, X. Jiang, and D. Culler, A building block approach to enornet ytem, in Proceeding of SenSy, 28. [7] A. El-Hoiydi and J.-D. Decotignie, Wiemac: An ultra low power mac protocol for the downlink of infratructure wirele enor network, in Proceeding of ISCC, 24. [8] B. Chen, K. Jamieon, H. Balakrihnan, and R. Morri, Span: an energy-efficient coordination algorithm for topology maintenance in ad hoc wirele network, Wirel. Netw., vol. 8, no. 5, pp , 22. [9] W. Ye, J. Heidemann, and D. Etrin, An energy-efficient mac protocol for wirele enor network, in Proceeding of INFOCOM, 22. [1] T. van Dam and K. Langendoen, An adaptive energy-efficient mac protocol for wirele enor network, in Proceeding of SenSy, 23. [11] W. Ye, F. Silva, and J. Heidemann, Ultra-low duty cycle mac with cheduled channel polling, in Proceeding of SenSy, 26. [12] T. Cui, L. Chen, and T. Ho, Energy efficient opportunitic network coding for wirele network, in Proceeding of INFOCOM, 28. [13] J. Zhang, Y. Chen, and I. Maric, Network coding via opportunitic forwarding in wirele meh network, in Proceeding of WCNC, 28. [14] J. Goeling, R. Boucherie, and J.-K. van Ommeren, Energy conumption in coded queue for wirele information exchange, in Proceeding of Network Coding, Theory, and Application, 29.