T2: What the Second Generation Holds

1. T2: What the Second Generation Holds Philip LevisStanford University 17.i.2007

2. Moore’s Law EE380

3. Bell’s Law log(users/device) 1950 1960 1970 1980 1990 2000 2010 EE380

4. 33m: 111 32m: 110 30m: 109,108,107 20m: 106,105,104 Sustainable architecture: monitoring and conserving water/energy use. 10m: 103, 102, 101 Biology: redwood micro- climates and trends Law enforcement and military: pinpointing snipers in cities. Medicine: monitoring patients outside the office. Applications EE380

5. Many Tiny Low-Cost Devices • Weighing the costs • Cost of device • Cost of deployment • Cost of maintenance • Unseen and in uncontrolled environments • A tree, a body, a faucet, a river, a vineyard • Wireless is inherent to embedded sensor networks • Reduces cost of deployment and maintenance • Wires not feasible in many environments EE380

6. Sensornets Today Patch (tiny nodes) Transit Gateway (PC, cellphone,stargate) Backend (PC) EE380

7. The Hardware • Two platform classes: gateway and embedded wireless. Linux: MB of RAM Active power: W Sleep power: mW 3 orders of magnitude TinyOS: KB of RAM Active power: mW Sleep power: µW - Energy is defining metric: lifetime, form factor, resources AA Battery for a year: ~2.7 Ah / (365 days * 24 hours) = 300µA avg. draw EE380

8. Moore’s Law EE380

9. Moore’s Law with Energy EE380

10. Microcontrollers EE380

11. A Brand New World • Cost, scale, lifetime and environment require wireless • Wireless makes energy the limiting factor • Moore’s Law has not followed an energy curve • Need for long-lived deployments means that ultra low-power nodes must still spend 99% of their time asleep. • These extreme energy limitations, coupled with long lifetimes, large numbers, and embedment, completely change hardware design, software design, OS structure, network protocols, and application semantics. EE380

12. Outline • A Brave New World • Platforms and hardware considerations • Operating systems and software • Networking and network protocols • An open alliance EE380

13. 4-10kB RAM 40-250 kbps Sample Platforms EE380

14. Power Why So Little? EE380

15. Where the mica2 Energy Goes 2002 EE380

16. Where the Telos Energy Goes 2004 EE380

17. Lifetime • 2 AA batteries is ~2700mAh • To last a year, average draw must be 2-300µA • Radio is principal cost EE380

18. CPU Utilization(mica2) Application uses 0.01% - 0.4% of the CPU From “Simulating the Power Consumption of Large-Scale Sensor Network Applications,” Shnayder et al., SenSys 2004. EE380

19. Platform and Hardware Considerations • Three axes for optimization: sleep power, wakeup times, and active power • Radio increasingly dominates power profile • Low-power reception is critical to long-term deployments • Need fine-grained control of component power states • MCU power state depends on external components • Lowest power states depend on timers • Platforms are evolving quickly, and there is much variety • BTnode3, tinynode, etc. EE380

20. Outline • A Brave New World • Platforms and hardware considerations • Operating systems and software • Networking and network protocols • An open alliance EE380

21. In the Beginning(1999) • Wireless sensor networks are on the horizon… • … but what are they going to do? • What problems will be important? • What will communication look like? • What will hardware platforms look like? • An operating system would provide a common execution environment for building and researching systems… • … but how do you design one with these uncertainties? EE380

22. TinyOS Goals(2000) • Allow fine-grained concurrency • Require very few resources • Adapt to hardware evolution • Support a wide range of applications • Be robust • Support a diverse set of platforms EE380

23. TinyOS Basics(2000) • A program is a set of components • Components can be easily developed and reused • Components can be easily replaced • Components can be hardware or software • Allow hardware/software boundary to easily change • Hardware has internal concurrency • Software must have it as well • Hardware is non-blocking • Software must be so as well EE380

24. TinyOS Basics, Continued(2002) Data Link Protocol Data Link Protocol Component Interface Hardware Crypto Software Crypto Component Task EE380

25. TinyOS Composition Application Tree Routing Collection Single-hop packet Timer Routing Logging Storage Timers Logging Packet EE380

26. TinyOS Composition Application Tree Routing Collection Single-hop packet Timer Routing Logging Storage Timers Logging Packet EE380

27. TinyOS Goals, Revisited • Allow fine-grained concurrency: tasks • Require very few resources: no threads, components • Adapt to hardware evolution: components • Support a wide range of applications: flexible boundaries • Be robust: component encapsulation • Support a diverse set of platforms: replacing components EE380

28. TinyOS Timeline • 1999: First platform (30 nodes) • 2000: rene platform, 4-5 groups • 2002: mica platform, 35+ groups, TinyOS 1.0 released • 2003: mica2 platform, 100+ groups, TinyOS 1.1 released • 2004: Telos/micaZ, 200 downloads/day, 100K+ nodes • 2006: 500K+ nodes, TinyOS 2.0 EE380

29. TinyOS 2.x(2005-6) • Evolution of TinyOS to address recent developments • Need for better standardization • Growing community interest and contribution • Increasing platform diversity • Transition from research to commercially viable platform • Four basic developments • Scheduler: improve robustness and flexibility • Network types: platform interoperability • Platform definition: simplify porting • Power management: OS support for long-term deployments EE380

30. The Power of Counting • A TinyOS program is a complete component graph • Counting across a program is a very powerful primitive • How many packet senders are there? • How many timers are used? • How many tasks are there? • Only components used by an application are included • Assigning each element a unique counter • 3 senders: sender 0, sender 1, sender 2 • 6 timers: timer 0, timer 1, … timer 5 • 8 tasks: task 0, task 1, … task 7 EE380

31. Tasks and the Scheduler • Tasks represent internal software concurrency • A component posts a task, which the OS runs later • Counting provides compile-time guarantees, leads to simpler code, and can enforce fairness policies • 80 cycles (10µs) to post and run a task EE380

32. Network Types • Depending on the processor, there are different data alignment and layout restrictions • ARM vs. x86 vs. AVR vs. MSP430 • Network protocols often use “network ordering” • Big endian, byte aligned, OSes have conversion functions • TinyOS supports network types at the language level • Automatically pack/unpack as needed source dest MSP430 opt sNo struct data_packet_t { nx_am_addr_t source; nx_am_addr_t dest; nx_uint8_t; opt; nx_uint16_t sNo; nx_uint8_t index; }; index source dest x86 opt sNo index network type source dest EE380 opt sNo index

33. MCU Power States ATMega128 While waiting for packet reception or transmission to complete, the MCU can drop into power-save. While reading/writing packets to the radio, the MCU cannot drop below the idle state. EE380

34. Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

35. Application turns on radio Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

36. Application turns on radio Radio sets sleep state dirty Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

37. Application turns on radio Radio sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

38. Application turns on radio Radio sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Goes to power-down Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

39. Application turns on radio Radio sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Goes to power-down Packet wakes up TinyOS Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

40. Application turns on radio Radio sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Goes to power-down Packet wakes up TinyOS Stack starts reading in packet from bus Bus sets sleep state dirty Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

41. Application turns on radio Radio sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Goes to power-down Packet wakes up TinyOS Stack starts reading in packet from bus Bus sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

42. Application turns on radio Radio sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Goes to power-down Packet wakes up TinyOS Stack starts reading in packet from bus Bus sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Goes to idle Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State EE380

43. Putting It Together • Components are lightweight state machines • Encapsulated state • Respond to external events • TinyOS remains reactive with low-overhead tasks • 80 cycles to post and run • Allows components to interleave execution cooperatively • Language techniques to optimize call paths and provide some compile-time promises of system behavior • Fine-grained component control enables fine-grained power management EE380

44. The Big Picture • Clean-slate OS design • Not an RTOS, significant departures from prior embedded • Make as much of a program static as possible • Compile-time, not run-time promises • Component isolation through careful design • Language/OS co-design • Brand-new domain enables breaking out of the law of C • Hide complexity when possible, expose it when needed • As we better understand sensornets and their requirements, versions of TinyOS can provide more policy EE380

45. Outline • A Brave New World • Platforms and hardware considerations • Operating systems and software • Network protocols and a network architecture • An open alliance EE380

46. Networking and Network Protocols • United States National Research Council thesis: “embedded sensor networks are different.” • Embedment, energy limitations, data-centric operation • They’re not just a new set of IP devices • If not IP, what are they? • What are the critical services and mechanisms? • What does a sensornet protocol stack look like? • Maybe it is just IP… EE380

47. Testing the Hypothesis • We don’t know what these networks will look like, so we’ll build a framework so everyone can figure it out • TinyOS: component-based OS • Can easily switch components • Designed for and supports major requirements: low power, hardware diversity, robustness, etc. • A lot of people start using TinyOS, and 6 years later… EE380

48. Sensor Network Protocols Today Application Regions Hood TinyDB EnviroTrack FTSP Diffusion SPIN STRAW TTDD Trickle Deluge Transport Drip MMRP Arrive TORA Ascent MintRoute CGSR AODV GPSR DSR ARA GSR GRAD Network Drain DBF DSDV TBRPF Resynch SPAN GAF FPS ReORg PC Topology Yao SMAC WooMac PAMAS TMAC BMAC ZMAC WiseMAC Pico Link/MAC 802.15.4 Bluetooth eyes Phy RadioMetrix CC1000 nordic RFM TOSSIM EE380

49. Defining an Architecture • Protocol research, applications, and real deployments show sensornets to have a diverse set of requirements • Traditional layer boundaries do not fit well • Commonalities emerge from these diverse efforts • From these commonalities we can begin to understand and define a sensor network architecture • Provide a structure for protocols andapplications, separating concerns andpromoting interoperability EE380

50. Why a New Architecture? • Short answer: we haven’t seen IP take over • Long answer: the Internet assumes a usage model • Independent end-to-end flows • Host-centric communication • Edge networks with a shared infrastructure • Sensor networks do not follow this model • Collaborative protocols • Data-centric communication • Sensing removes distinction between edge and core EE380