Procrastination Might Lead to a Longer and More Useful Life

1. Procrastination Might Lead to a Longer and More Useful Life Prabal Dutta, David Culler, and Scott Shenker University of California, Berkeley

2. In sensor networks, energy is the defining constraint • Battery-operated 2 “AA” batteries • 10 mA active current • 10 uA sleep current • 1% duty cycle • CPU 10 MIPS • RAM 4 KB to 10 KB • ROM 32 KB to 128 KB • Flash 512 KB to 1 MB • Radio 40 kbps to 250 kbps 2000 mA-Hr

3. SELECT * FROM sensors SAMPLE PERIOD 5 min SELECT time, epoch, id, parent, voltage, depth, hum, temp, toplight, botlight FROM sensors SAMPLE PERIOD 5 min Many scientific data collection applicationsstream sensor data from sensor nodes to sinks “Great Duck Island” [Szewczyk04] “Redwoods” [Tolle05]

4. Necessity as the mother of invention:Sensornets run at a few percent duty cycle Year Deployment MAC DC Period (s) 2003 GDI Polled 2.2% 0.54-1.085 2004 Redwoods Sched 1.3% 300 2005 FireWxNet Sched 6.7% 900 2006 WiSe Sched 1.6% 60

5. Scheduled Communications DC = tguard/Tpkt + tpkt/Tpkt G D G D G D RX G D G D G D TX tguard tpkt Tpkt

6. Polled Communications Tpoll tpoll P P P D P P D RX D D D D D D D D D TX tpkt Tpoll + tpoll Tpkt

7. Even at 1-2% duty cycles, idle listening dominates power budget* Low-Power Listening (idle listening) * See paper for detailed derivations R. Szewczyk, A. Mainwaring, J. Polastre, D. Culler, “An Analysis of a Large Scale Habitat Monitoring Application”, ACM SenSys’ 04, November, 2004, Baltimore, MD

8. SELECT nodeid, timestamp, temperature, humidity, pressure, totalrad, photorad FROM sensors SAMPLE PERIOD 5 min REPORT PERIOD 1 day Procrastinate by decouplingsensing and sending periods

9. Procrastination:Opportunities and challenges across the network stack

10. Application Transport Network Link

11. Network layer protocols are chatty • Frequent routing beacons ensure availability • But topology maintenance is expensive • Why maintain the topology if it goes unused? • Delay topology (tree) formation until needed • However, interactive use could justify more frequent communications

12. Network layer challenges: Establishing the topology • How would you quickly establish a gradient? • Would you pick aggressive (long) links? • Would you cache old state (perhaps a day old)? • Would you try to use old state first? • Would you prefer to build a new topology?

13. Quickly flooding the routing beacon with Ripple • Start with a basic flooding protocol • Modify the retransmission timer • Delay proportional to RSSI, which “schedules” network approximately • Related work • Trickle [Levis04] • SRM [Floyd97]

14. Application Transport Network Link

15. Transport layer opportunities • Improve reliability by using “good” links quickly • Send data hop-by-hop and may achieve higher throughput since RTT is smaller • Avoid intra-path interference due to multi-hop wireless flows • Avoid expensive end-to-end retransmissions

16. Add cheap NAND flash to nodes 1GB spot price ~ $7 > 40% annual price decline 68% decline in last year Energy-efficient 100x less costly to write a byte than send a byte over radio Can write entire contents with just a few percent of energy in AA batteries But how to buffer route-throughbundles with a limited storage? Source: DRAM Exchange

17. Procrastination: opportunities and challenges across the network stack Application Transport Network Link

18. At the application layer, compresssensor readings before transmission • Temperature • Light Source: [Tolle05]

19. Lots of CPU cycles for compressing prior to storage or communications • Prior to transmission • O(100K) instructions for O(1 byte) transmitted • Massive asymmetry in computation and communication • Unlikely to change: Moore’s Law vs Maxwell’s Law • Prior to storage • O(10K to 1M) instruction for O(1 byte) written • Massive asymmetry in computation and storage • Unlikely to change: [Super-]Moore’s Law vs Moore’s Law • But raises some new questions • What compression algorithms should be used? • What logical and physical data structures should be used?

20. Application Transport Network Link

21. Picking good links quicklymight not be too difficult

22. Caveat: Channel access costs stilldominate infrequent communications α 1 β αt α > 1 > β Node Local Time ON TX ON RX t’ βt Min(RXon) = 2 x MaxDrift + Startup + Jitter • Research on: • Minimizing clock skew • Speeding up radio startup • Providing bus arbitration • Lowering RSSI detection cost t Global “Real” Time *CSMA-LPL costs don’t scale with time, but have high fixed costs for transmission

23. Conclusion • Delay offers many optimization opportunities • Link • Network • Transport • Application • But standby power dominates budget • 90% of node power • 25% of laptop power • 8% of the UK electricity in 2004

24. Discussion

25. The total load on a 1-hop nodein an n-hop network is: 2(n2-1)+1 1-hop 2-hop Area n2-1 3-hop n-hop • N2(n2-1)+1 • 1 • 7 • 17 • 31 • 49 • 71 Area  1 1-hop area must: (a) route-through (RX & TX) 2-hop to n-hop traffic: 2(n2-1) (b) originate (TX) 1-hop traffic: 1

26. [Kusy06, Sallai06] Achieved 2.7 us average error 26 us max error Over 11 hop network 45 nodes In 4 seconds With two-phase flood Using fixed neighbors But how to flood without fixed neighbors? Rapid time synchronization

27. What could storage enable?Delay expensive operations to reduce overhead • Many operations have high startup costs • Sending packets • Writing to flash or disk • Acquiring sensor data • Often better to postpone expensive operations • But what to do with all the flowing data? Store it • Related work • Nagle’s algorithm • Cache coherence • Disk buffering • The FedEx Truck

28. What else could storage enable?Break synchrony between subsystems • Many subsystems are synchronous • Sensor and signal conditioning • Signal conditioning and A/D conversion • Packet arrival and processing • Asynchrony allows each element to operate optimally. Storage is the glue between elements • Related work • Elastic pipelines [Sutherland89] • Bulk synchronous-parallel [Valiant89] • Queue element in Click [Morris99] • Fjords in streaming [Madden02] • Asynchronous computer architectures

29. Radio Capacity Node Data Rate 880 bits /sec 0.8 bits / sec = = 1,100 Digging deeper into overhead Typical • Data generation rate (raw): 20 bytes / 5 min • Data generation rate (raw): 0.53 bits / sec • Packet overhead (headers): 50% (17B hdr/36B data) • Data generation rate (w/ overhead): 0.80 bits / sec • Radio data rate (raw, CC1000): 40 kbps • Radio data rate (duty cycled at 2.2%) 880 bits / sec • Over-provisioning factor (1-hop) 1,100 times • Over-provisioning factor (2-hop) 157 times • Over-provisioning factor (3-hop) 64 times • Over-provisioning factor (4-hop) 35 times • Over-provisioning factor (5-hop) 22 times • … • Optimally provisioned for 23-hop, uniformly distributed network

30. Radio On-Time Radio Active Time 19 minutes 40kbps/10KB = = 1,100 Bottom line:Streaming is not efficient A typical 1% duty cycle translates to over 14 minutes of daily on time. Streaming delivers a trickle through a fire hose

31. Streaming every sensor sample is inefficient • TCP doesn’t send single-byte packets (exception: TCP_NODELAY); bytes are coalesced into larger packets • Operating systems don’t write to disk; they cache multiple writes and flush • College students don’t do their laundry daily; they wait until their underwear runs out

32. Related work: Delay-Tolerant Networking • Others [Fall03] have suggested DTN used by necessity when: • No contemporaneous path from source to sink is available • End-to-end round-trip times exceed a few seconds • Nodes exhibit mobility over short time scales • Links exhibit high loss rates over short periods of time • Others [Mathur06] have suggested NAND flash be used because of energy-efficiency. This proposal explores how • This proposal suggests DTN be used by choice when: • Delay is tolerable • Energy-efficiency is important • The network is otherwise over-provisioned • No characterization of the energy-efficiency of DTN in the literature over streaming data transfer