AppSleep

1. AppSleep Nithya Ramanathan Mark Yarvis Lakshman Krishnamurthy Deborah Estrin

2. Outline • Contributions / Background • AppSleep / Time Synchronization • Evaluation • Adaptive AppSleep / Evaluation • Summary of Results

3. Contributions • AppSleep: An transport protocol for low duty-cycle networks with significant energy savings over BMAC/SMAC • Bulk data transfer; energy efficient by only keeping active route awake • Low overhead time synchronization that is robust to packet loss • Adaptive AppSleep: An adaptive addition that maximizes energy savings while handling time varying latency requirements • Intuition that sleep/wake control does not only belong in the MAC for a certain class of applications

4. Definition of Terms • Synchronous Data – Pre-scheduled sample delivery • Frequency : 1 / (sampling period) • Asynchronous – Unscheduled data, i.e. detected events/ queries • Latencies • Synchronous Data – Time to return pre-scheduled data once it has been obtained • Asynchronous Data – Time to return an event once it has been detected, or receive a query

5. Informal Application Taxonomy

6. Sources of Energy Dissipation • Radio (20mA Tx / 16mA Rx / Idle) • Idle Listening • Overhearing • Control Packet overhead • Collisions (not addressed by AppSleep) • Processor (5.5mA active / 1.6mA idle/ <1uA sleep)

7. SMAC • Goals • Energy efficiency, self-organization • Geared towards • Medium latency (seconds), frequent, non-deterministic traffic; • Link statistics kept up to date i.e. Frequent monitoring • Not suitable for low-traffic, extremely low latency apps • Energy Conservation • Overhearing: Overhearing avoidance, relatively short preambles • Packet Overhead: High packet overhead for scheduling/SYNC • Idle Listening: Frequent when there is a very light traffic load • Multi-hop not always achieved during one wake-period

8. BMAC • Goals • Simple operation, Scalability, and Tolerance to changing network conds • Geared towards • Low latency (msec), non-deterministic traffic i.e. Casual/Emergency event detection, target tracking • Not suitable for deterministic / high-traffic apps • Energy Conservation • Overhearingsignificant unicast preambles • Packet Overhead: Preamble Length dependent on sleep time • Idle Listening: Frequent with minimal traffic • Collisions: Hidden terminal is an issue without RTS/CTS addition of BMAC • While its flexible, optimal parameter setting still depends on network characteristics (E.g. Network density => Check period)

9. BMAC Overhead • Long preambles impact receive and transmit energies for BMAC AppSleep & SMAC linear regardless of sleep duration

10. Energy Efficient Approaches • Different energy efficient approaches apply to different classes of applications • Nothing directly applies to “Infrequent Monitoring” where applications are willing to do nothing for extended periods of time

11. Outline • Contributions / Background • AppSleep Protocol / Time Synchronization • Evaluation • Adaptive AppSleep / Evaluation • Summary of Results

12. Application Driven Sleep • Pros • Extended sleep periods enables idle mode for processor and minimized radio/processor switching • Minimal application specific knowledge • Cons of Extended Sleep Periods • Requires synchronized wake-up so that neighbors hear each other • Dropped packets have higher impact • Multi-hop during single wakeup is crucial

13. AppSleep • Cluster wakes/sleeps at the same time • Cluster head sends periodic SYNCH packet with a relative sleep time (Tpkt-sleep) to synchronize network • Control Packet Transfer: node waits until cluster wakes up • Bulk Data Transfer: node first unicasts a control packet along the route it will use • Extensive wake-up intervals, so receiver on time is long

14. Cluster Head broadcasts SYNCH • Nodes start out awake. • When a new node joins the network, it remains awake until it hears a SYNCH packet CH

15. Trelative-sleep seconds later… • Nodes goto sleep Trelative-sleep seconds later, specified in the SYNCH packet CH

16. Synchronous wakeup = Sleep = Awake • Nodes all wakeup together after Tsleep seconds, specified in SYNCH packet • Nodes stay awake long enough to communicate across the network diameter CH

17. Nodes stay awake for Tawake • Node can transmit a control packet during wake-period across network diameter • For bulk data transfer, control packet commands nodes on route to remain awake CH

18. Remaining nodes go to sleep • Nodes on active route remain awake until bulk data transfer completes CH

19. Network goes back to sleep • And then go to sleep again CH

20. 3 State Protocol Cluster Awake Ctrl packets tx/rx across network Wakeup timer fires Node initiates bulk transfer Sleep timer fires Node terminates bulk transfer Cluster Sleep Proc idle/sleeps Bulk Data Transfer Note: Sleep period determined by latency needs of application

21. Global sleep-wake • Entire cluster sleeps/wakes on the same schedule = Sleep = Awake Cluster Awake Bulk Data Transfer Cluster Sleeps

22. Time Synchronization • Trades-off accuracy for minimal overhead • Tight / pair-wise synchronization not needed: reduces overhead by ½ => O(1). • Lower overhead than other protocols (RBS1, DTMS2, LTS3) • Addresses SYNCH packet loss 1 J. Elson, L. Girod, D. Estrin, “Fine-Grained Network Time Synchronizatino using Reference Broadcasts”. OSDI, 2002. 2 S. Ping, “Delay Measurement Time Synchronization for WSN”. Intel-Research, Berkeley. 3 J. Greunen, J. Rabaey, “Lightweight Time Synchronization for Sensor Networks”

23. Impacts on Time Synchronization • Packet Delay / Loss • Clock drift • Theoretical clock drift for mica2 is 20 ppm Cdrift = +/- 72 msec/hour • Dependent on time elapsed since the last SYNCH packet (Tlast_ts)

24. Accounting for packet delaysTPkt_Delay = TSend-delay + TReceive_Delay Packet Transmission Send Delay Receive Delay P r e a m b l e D a t a Preamble Data Sender application stamps packet, and adjusts relative sleep time Receiver MAC stamps same byte in packet Receiver application receives packet, sets its sleep timers, and forwards the packet Sender MAC stamps packet Send-delay Includes channel access, and processing Transmission Delay Included in Send and Receive Delay Propogation Delay Assume it is 0 Receive-delay Time elapsed while processing a received packet 1 1 Ping, Su Delay Measurement Time Synchronization for Wireless Sensor Networks. IRB-TR-03-013. June, 2003.

25. AppSleep’s Time Synchronization • Compensating for Packet Delay • Receiving nodes calculate their relative sleep time (Tsleep) TPkt_Delay = TSend-delay + TReceive_Delay Ttime-sleep = Tpkt-sleep - TPkt_Delay (1) • Compensating for Clock Drift • Initial node delays packet transmission by Tinit_dly Tclk_drift = (2 * |Cdrift | ) * (Tlast_ts + 1) Tinit_dly = Tclk_drift (2) • Nodes should stay awake for Tawake (recaluclated 1 / hour) Thop_dly = (Nhops * 50ms) Tawake = Tinit_dly + Tclk_drift + Thop_dly (3)

26. Initial GuardbandTinit_dly = (2 * Tclk_drift ) * (Tlast_ts + 1) If it has been < 1 hour since the SYNCH packet, nodes could wakeup anytime from 72 msec before to 72 msec after they are supposed to… - 72 msec 72 msec 0 After Tinit_dly all nodes along the path are guaranteed to be awake Tinit_dly = 144msec Node 2 receives preamble Node 1 starts sending Node 1 wakes up Node 2 wakes up

27. AppSleep’s Time Synchronization • Compensating for Packet Delay • Receiving nodes calculate their relative sleep time (Tsleep) TPkt_Delay = TSend-delay + TReceive_Delay Tsleep = Tpkt-sleep - TPkt_Delay (1) • Compensating for Clock Drift • Initial node delays packet transmission by Tinit_dly Tclk_drift = (2 * |Cdrift | ) * (Tlast_ts + 1) Tinit_dly = Tclk_drift (2) • Nodes should stay awake for Tawake (recaluclated 1 / hour) Thop_dly = (Nhops * 50ms) Tawake = Tinit_dly + Tclk_drift + Thop_dly (3)

28. Time Nodes Stay AwakeTawake = Thop_dly + Tclk_drift + Tinit_dly Assuming SYNCH packet has been sent in the last hour, and the network diameter is n hops: Tclk_drift = Tinit_dly = (2 * 72ms) * (0 + 1) = 144ms Tawake = 144 + 144 + n * 50ms A worst-case scenario 0 Tclk_drift= 144ms Thop_dly = Nhops * 50ms Tinit_dly = 144msec Node 1 starts sending Node n wakes up Node 1 wakes up Node n receives

29. AppSleep’s Time Synchronization • Compensating for Packet Delay • Receiving nodes calculate their relative sleep time (Tsleep) TPkt_Delay = TSend-delay + TReceive_Delay Tsleep = Tpkt-sleep - TPkt_Delay (1) • Compensating for Clock Drift • Initial node delays packet transmission by Tinit_dly Tclk_drift = (2 * |Cdrift | ) * (Tlast_ts + 1) Tinit_dly = Tclk_drift (2) • Nodes should stay awake for Tawake (recaluclated 1 / hour) Thop_dly = (Nhops * 50ms) NOTE: N = Maximum network diameter Tawake = Tinit_dly + Tclk_drift + Thop_dly (3)

30. Application Specific Knowledge • Network diameter • To calculate Tawake • Potentially obtain from routing layer • Minimum latency requirements • To calculate Tsleep • Obtain from Application

31. Optimal Time Synchronization Period • Increased SYNCH packet overhead is offset by decreased time nodes stay awake during each wake-up • Optimal SYNCH period decreases with the sleep period

32. What if a SYNCH packet is dropped? • Each SYNCH packet informs nodes when to expect the next SYNCH packet • If a node does not get a SYNCH packet when expected, it broadcasts a SYNCH-REQ message to request an updated sleep time

33. Time Synchronization timeline • Nodes send up to 4 SYNCH-REQ messages, exponentially decay timeout • If they still do not hear a SYNCH packet – remain on Twait = Tawake – Tbuffer Ttimeout = 200msec Ttimeout = 400msec … Node wakes up Neighboring nodes hear SYNCH-REQ; send updated SYNCH messages Node broadcasts SYNCH-REQ message

34. Time Synchronization Time = Tts • Cluster Head floods SYNCH packets • Nodes update the SYNCH packet and forward the first one • Some nodes do not hear them CH X X

35. Time = Tts + 200msec • Nodes that did not receive a SYNCH packet send SYNCH-REQ packets after Twait secs CH X X X

36. Forwarding SYNCH-REQ responses • Nodes that receive updated SYNCH packets will forward those on CH

37. Time = Tts + 200msec + 400msec… • Nodes that again did not receive SYNCH packets will send up to 3 more SYNCH-REQ messages - after decaying wait periods CH X

38. Outline • Contributions / Background • AppSleep / Time Synchronization • Evaluation • Adaptive AppSleep / Evaluation • Summary of Results

39. Evaluation • Theoretical Results using energy model • Actual Measurements • BMAC snapshot as of 9/20 (tinyos-1.x/contrib/ucb/tos/CC1000Pulse) • AppSleep snapshot as of 9/20 (tinyos-1.x/tos/platform/mica2/CC1000*) • All are 7-hop networks

40. Energy Model Assumptions • General • 7-hop network diameter • Nodes receive/forward data from average of 3 children • Nodes have 7 neighbors • Routing traffic overhead included – commensurate with sample traffic (2 packets) • Radio: Erx = Eidle to conservatively estimate overhearing • SMAC • Node sends SYNCH packet every: 1 / (SYNC_PERIOD * NUM_NEIGHBORS) seconds; Because if a node hears a SYNC packet, it doesn’t need to send one out • Maximum sleep = 12 seconds • BMAC • Uses application control • Based on code (tinyos-1.x/contrib/ucb/tos/CC1000Pulse) as of 9/20/2004 • Maximum sleep = 1.6 seconds • Radio Awake = Time Awake – (1.5 * num-radio-switches)

41. Average Latency • B-MAC is the best • SMAC does not include adaptive listening • B-MAC/S-MAC latency scales with number of hops, AppSleep is constant AppSleep = Tcheck/2 + Tlisten S-MAC = (Tcheck/2 + Tlisten) + (Nhops – 1) * (Tcheck + Tlisten) B-MAC = (1.5 * Tcheck + Tlisten) + (Nhops – 1) * (Tcheck + Tlisten)

42. Energy to Maintain Network (No traffic) • BMAC has the lowest overhead when no traffic is sent

43. Total Lifetime • AppSleep attempts communication across network diameter, so for equivalent sleeping duration, SMAC outperforms it AppSleep avg latency = 375 sec 3x difference bet BMAC & AppSleep for 22min sampling period AppSleep avg latency = 46 sec

44. Impact of Neighborhood Size for 22-minute sampling • Demonstrates 2nd key result: despite increased transmission overhead, SMAC exceeds BMAC due to BMAC’s preamble over-hearing • SMAC & AppSleep not impacted by neighbor density AppSleep shows 9X longer lifetime over BMAC for 20 neighbors AppSleep avg latency = 46 sec AppSleep avg latency = 5.9 sec

45. AppSleep Lifetime as Impacted by Network Diameter: Scalability

46. Actual Average Energy Consumption • Measured: • Time radio on • Time tx/rx • Number of times radio switches • Test: • Sample 1/10 minutes • SYNCH packet 1 / (2 hours) for AppSleep • 2 Runs for each test BMAC estimate < actual measurements AppSleep’s model closely matches measurement

47. Actual Average Time Radio is Awake • BMAC is awake 4x longer than AppSleep

48. Packet Loss • Test • 4 runs each • 6-20 hours • 7-hops • BMAC = 3-6% • AppSleep => 1-3%

49. Varying Latency Usage Model • Samples are sent in a pre-scheduled fashion • Dynamic querying ability required, however • Low latency query response required for a period of time after a sample has been returned (~1 minute response time) • After that, the query response latency bounds increase substantially (~10 minute response time)

50. Adaptive AppSleep State Diagram • Within each state, AppSleep protocol is running • Control packets from the cluster head moves the network between states • Difference between states is length of sleep Synchronous Data Return Minimum Power Asynchronous Data Query Ready 1 Asynchronous Data Query Ready n Asynchronous Data ...