TinyOS: An Open Platform for Wireless Sensor Networks. Philip Levis Stanford University 8.v v.2006

Transcription

1 TinyOS: An Open Platform for Wireless Sensor Networks Philip Levis Stanford University 8.v v.2006

2 The EmNets Vision Information technology (IT) is on the verge of another revolution The use of EmNets [embedded networks] throughout society could well dwarf previous milestones. 1 The motes [EmNet nodes] preview a future pervaded by networks of wireless batterypowered sensors that monitor our environment, our machines, and even us. 2 1 National Research Council. Embedded, Everywhere, MIT Technology Review. 10 Technologies That Will Change the World, v.2006 MDM

3 Moore!s Law 8.v.2006 MDM

4 Bell!s Law log(users/device) v.2006 MDM

5 Applications 33m: m: m: 109,108,107 20m: 106,105,104 10m: 103, 102, 101 Sustainable architecture: monitoring and conserving water#energy use! Biology: redwood micro" climates and trends Law enforcement and military: pinpointing snipers in cities! Medicine: monitoring patients outside the o$ce! 8.v.2006 MDM

6 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 8.v.2006 MDM

7 Sensornets Today Patch (tiny nodes) Transit Gateway (PC, cellphone, stargate) Backend (PC) 8.v.2006 MDM

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

9 Moore!s Law 8.v.2006 MDM

10 Moore!s Law with Energy 8.v.2006 MDM

11 Microcontrollers 8.v.2006 MDM

12 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. 8.v.2006 MDM

13 Outline A Brave New World Platforms and hardware considerations Operating systems and software Networking and network protocols An open alliance 8.v.2006 MDM

14 Calculating Lifetime Power (W) is current draw (A) x voltage (V) Energy (J) is power (W) x time (s) Power can be misleading Regulating voltage can be expensive Energy can be misleading too Batteries capacity depends on draw levels (non-uniform) In practice, what matters is the current draw profile: how much current a node draws and for how long. 8.v.2006 MDM

15 Sample Platforms 4-10kB RAM kbps 8.v.2006 MDM

16 Why So Little? Power 8.v.2006 MDM

17 Where the mica2 Energy Goes Active Idle Idle, radio off Power-down 20-25mA 13-18mA 3mA 110µA v.2006 MDM

18 Where the Telos Energy Goes Active Idle Idle, radio off Power-down 18-21mA 17-20mA 50µA 10µA v.2006 MDM

19 Lifetime 2 AA batteries is ~2700mAh To last a year, average draw must be 2-300µA Radio is principal cost Platform Mica2 active Mica2 idle Mica2 power-down Telos active Telos idle Telos power-down Draw 20 ma 13 ma 110 µa 18 ma 17 ma 10 µa Lifetime 5.5 days 8 days ~3 years 6 days 6 days ~30 years 8.v.2006 MDM

20 Workload: Monitoring Low rate, periodic sampling (minutes/sample) Ad-hoc collection tree Last months-year 8.v.2006 MDM

21 Three Steps to Long Life (courtesy of Joe Polastre) Sleep: low duty cycle, wake up rarely Maximize time in power-down Wakeup: when you do wake up, do so quickly Minimize transition times Awake: minimize idle time Do what you have to quickly 8.v.2006 MDM

22 Sleeping Nodes must spend almost all of their time asleep To last 1 year: Difference between 10!A and 100!A Platform Duty Cycle Awake Sleep Active Mica2 1% 15 min/day 35% 65% Telos 1.6% 22 min/day 3% 97% To last 2 years: Platform Duty Cycle Awake Sleep Active Mica2 0.2% 3 min/day 87% 13% Telos 0.8% 11 min/day 6% 94% 8.v.2006 MDM

23 Sleeping, continued Minimize sleep current by turning off non-essential circuits Essential is usually a single low-speed oscillator Drive peripherals through a low-power oscillator Turn off core when possible Interrupt sources Radio Radio Power wakeup Sensor MCU Sensor MCU sleep Flash Flash Time 8.v.2006 MDM

24 Waking Up To Communicate Wake up latencies are wasted energy Powering components, but no useful work is being done A constant overhead on every wakeup (amortization useful) First step: wake up MCU Mica2 (atmega128): 180!s Telos (MSP430): 6!s Second step: wake up radio Mica2 (CC1000): 2ms Telos (CC2420): 600!s 8.v.2006 MDM

25 Low Power Reception Idle listening can be a tremendous waste of energy Scheduled communication I know when someone will send to me, I ll wake up then TDMA, network scheduling, etc. Low power listening (LPL) I don t know when someone will send to me I ll wake up periodically and check Wakeup constants become important How often to wake up? Power wakeup sleep Time 8.v.2006 MDM

26 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 v.2006 MDM

27 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. 8.v.2006 MDM

28 Outline A Brave New World Platforms and hardware considerations Operating systems and software Networking and network protocols An open alliance 8.v.2006 MDM

29 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? 8.v.2006 MDM

30 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 8.v.2006 MDM

31 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 8.v.2006 MDM

32 TinyOS Basics, Continued (2002) Component Data Link Protocol Data Link Protocol Interface Component Hardware Crypto Software Crypto Task 8.v.2006 MDM

33 TinyOS Composition Application Collection Routing Tree Routing Single-hop packet Timer Logging Storage Packet Timers Logging 8.v.2006 MDM

34 TinyOS Composition Application Collection Routing Tree Routing Single-hop packet Timer Logging Storage Packet Timers Logging 8.v.2006 MDM

35 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 8.v.2006 MDM

36 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 v.2006 MDM

37 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 8.v.2006 MDM

38 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 8.v.2006 MDM

39 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 8.v.2006 MDM

40 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 MSP430 source opt index struct data_packet_t { nx_am_addr_t source; nx_am_addr_t dest; source dest nx_uint8_t; opt; x86 opt sno nx_uint16_t sno; index nx_uint8_t index; }; source dest 8.v.2006 MDM network 2006 type 40 opt sno dest sno index

41 Platform Definition Diverse platforms, with some commonality: Platform MCU Radio Storage Mica2 ATMega128 CC1000 at45db mica ATMega128 CC2420 at45db imote2 pxa27x CC2420 Telos MSP430 CC2420 at45db stm25p eyes MSP430 TDA5250 at45db tinynode MSP430 XE1205 stm25p TinyOS 2.0 approach: a platform is a collection of chips Platform-specific code stitches chip code together 8.v.2006 MDM

42 Example: micaz AppM TimerMilliC ActiveMessageC Atmega128 Timer Stack CC2420 Radio Stack Application Component MicaZ Component Chip Component 32kHz Timer Millisecond Timer Communication CC2420AlarmC 8.v.2006 MDM

43 Power Management Peripheral power control Every active OS component can be turned on/off Power state of radio, flash chip, sensors Policy dependent on subsystem stack (e.g., LPL vs. TDMA) At OS level, control is explicit Microcontroller power control Enter lowest power state that supports ongoing operations Microcontroller-specific At OS level, control is implicit 8.v.2006 MDM

44 Peripheral Power Control Dedicated peripherals Examples: radio, hardware clock, UART Explicit control from subsystem Virtualized peripherals Examples: sending packets, sensors Implicit control from virtualization component Shared peripherals Examples: bus, flash chip Resource access arbiter has power management policy 8.v.2006 MDM

45 Peripherals, Continued Timer PWR MCU SFD SPI Bus MCU is in deep sleep SPI Bus CC2420 Radio 8.v.2006 MDM

46 Peripherals, Continued Timer PWR MCU SFD SPI Bus MCU is in deep sleep Timer wakes the MCU SPI Bus CC2420 Radio 8.v.2006 MDM

47 Peripherals, Continued MCU is in deep sleep Timer PWR MCU SFD SPI Bus Timer wakes the MCU TinyOS powers up the radio, enables receive interrupt SPI Bus CC2420 Radio 8.v.2006 MDM

48 Peripherals, Continued MCU is in deep sleep Timer PWR MCU SFD SPI Bus Timer wakes the MCU TinyOS powers up the radio, enables receive interrupt TinyOS returns MCU to sleep SPI Bus CC2420 Radio 8.v.2006 MDM

49 Peripherals, Continued MCU is in deep sleep Timer PWR MCU SFD SPI Bus Timer wakes the MCU TinyOS powers up the radio, enables receive interrupt TinyOS returns MCU to sleep SPI Bus Packet arrives and wakes MCU CC2420 Radio 8.v.2006 MDM

50 Peripherals, Continued MCU is in deep sleep Timer PWR MCU SFD SPI Bus Timer wakes the MCU TinyOS powers up the radio, enables receive interrupt TinyOS returns MCU to sleep CC2420 Radio SPI Bus Packet arrives and wakes MCU TinyOS powers up bus, reads in received packet 8.v.2006 MDM

51 Peripherals, Continued MCU is in deep sleep Timer PWR MCU SFD SPI Bus Timer wakes the MCU TinyOS powers up the radio, enables receive interrupt TinyOS returns MCU to sleep CC2420 Radio SPI Bus Packet arrives and wakes MCU TinyOS powers up bus, reads in received packet TinyOS turns off radio, processes packet 8.v.2006 MDM

52 MCU Power States ATMega128 State Idle Ext. Standby Standby Power-save Power-down External Interrupts External Clock Main Clock While waiting for packet reception or transmission to complete, the MCU can drop into power-save. Timer0 EEPROM ADC, I/O While reading/writing packets to the radio, the MCU cannot drop below the idle state. 8.v.2006 MDM

53 Computing a Power State Application CC2420 SPI Bus Scheduler McuSleep Hardware State 8.v.2006 MDM

54 Computing a Power State Application turns on radio Application CC2420 SPI Bus Scheduler McuSleep Hardware State 8.v.2006 MDM

55 Computing a Power State Application CC2420 SPI Bus Application turns on radio Radio sets sleep state dirty Scheduler McuSleep Hardware State 8.v.2006 MDM

56 Computing a Power State Application CC2420 SPI Bus Application turns on radio Radio sets sleep state dirty Scheduler completes Sees sleep state is dirty, recalculates sleep state Scheduler McuSleep Hardware State 8.v.2006 MDM

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

58 Computing a Power State Application Scheduler CC2420 SPI Bus McuSleep 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 Hardware State 8.v.2006 MDM

59 Computing a Power State Application Scheduler CC2420 SPI Bus McuSleep 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 Hardware State 8.v.2006 MDM

60 Computing a Power State Application Scheduler CC2420 SPI Bus McuSleep Hardware State 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 8.v.2006 MDM

61 Computing a Power State Application Scheduler CC2420 SPI Bus McuSleep 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 Hardware State Scheduler completes Sees sleep state is dirty, recalculates sleep state Goes to idle 8.v.2006 MDM

62 Power State Override Sometimes, hardware state is not sufficient to calculate the best low-power state Application-level requirements Highly customized applications Example: IntelMote2 pxa27x low power states Some states can take many milliseconds to wake up Can disrupt protocol or application timing McuSleep component has an optional override interface, where components can set a minimum low-power state 8.v.2006 MDM

63 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 8.v.2006 MDM

64 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 8.v.2006 MDM

65 Outline A Brave New World Platforms and hardware considerations Operating systems and software Network protocols and a network architecture An open alliance 8.v.2006 MDM

66 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 8.v.2006 MDM

67 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 8.v.2006 MDM

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

69 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 and applications, separating concerns and promoting interoperability 8.v.2006 MDM

70 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 8.v.2006 MDM

71 The Two Major Protocols Most simple sensornets start with two protocols Protocol 0: Dissemination Reliably deliver data to every node in a network Reconfiguration, programs, queries Basic mechanism for network control Protocol 1: Collection Deliver data from every node to one or more sinks Basic mechanism for gathering data 8.v.2006 MDM

72 Dissemination Use local broadcasts and packet suppression Scale to a wide range of densities Control transmissions over space 100% eventual reliability Disconnection, repopulation, etc. Continuous process Maintenance: exchange metadata (e.g., version numbers, hashes) at a low rate to ensure network is up to date Propagation: when a node detects an inconsistency, the network quickly broadcasts the new data 8.v.2006 MDM

73 Some Networking Challenges Loss over space Loss over time Asymmetry Energy Bandwidth 8.v.2006 MDM

74 Trickle Polite gossip: Every once in a while, broadcast what data you have, unless you!ve heard some other nodes broadcast the same thing recently. Energy efficient, fast, and scalable Maintenance: a few sends per hour Propagation: across large multihop networks in seconds Scalability: thousand-fold changes in density 8.v.2006 MDM

75 Trickle Algorithm Time interval of length! Redundancy constant k (e.g., 1, 2) Maintain a counter c Pick a time t from [0,!!] At time t, transmit metadata if c < k Increment c when you hear identical metadata to your own Transmit updates when you hear older metadata At end of!, pick a new t 8.v.2006 MDM

76 Example Trickle Execution A c ' k%& B ' C time '! transmission suppressed transmission reception 8.v.2006 MDM

77 Example Trickle Execution A c ' t A1 k%& B & C time '! transmission suppressed transmission reception 8.v.2006 MDM

78 Example Trickle Execution c k%& A ' t A1 B ( C time '! t C1 transmission suppressed transmission reception 8.v.2006 MDM

79 Example Trickle Execution c k%& A ' t A1 B ( t B1 C time '! t C1 transmission suppressed transmission reception 8.v.2006 MDM

80 Example Trickle Execution c k%& A ' t A1 B ' t B1 C time '! t C1 transmission suppressed transmission reception 8.v.2006 MDM

81 Example Trickle Execution c k%& A & t A1 B ' t B1 t B2 C time &! t C1 transmission suppressed transmission reception 8.v.2006 MDM

82 Example Trickle Execution c k%& A & t A1 B ' t B1 t B2 C time &! t C1 t C2 transmission suppressed transmission reception 8.v.2006 MDM

83 Example Trickle Execution c k%& A & t A1 t A2 B ' t B1 t B2 C time &! t C1 t C2 transmission suppressed transmission reception 8.v.2006 MDM

84 Example Trickle Execution c k%& A ' t A1 t A2 B ' t B1 t B2 C time '! t C1 t C2 transmission suppressed transmission reception 8.v.2006 MDM

85 Short Listen Effect A B C D Lack of synchronization leads to the short listen effect For example, B transmits three times:! Time 8.v.2006 MDM

86 Simulated Propagation New data (20 bytes) at lower left corner 16 hop network Time To Reprogram, Tau, 10 Foot Spacing (seconds) Time to reception in seconds Set! l = 1 sec Set! h = 1 min 20s for 16 hops Wave of activity Time 8.v.2006 MDM

87 Trickle Overview Trickle scales logarithmically with density Can obtain rapid propagation with low maintenance In example deployment, maintenance of a few sends/hour, propagation of 30 seconds Controls a transmission rate over space Coupling between network and the physical world Trickle is a nameless protocol Uses wireless connectivity as an implicit naming scheme No name management, neighbor lists Stateless operation (well, eleven bytes) 8.v.2006 MDM

88 The Internet Narrow Waist The Internet narrow waist is at the network layer: IP Separate many transport and application protocols from underlying data-link technologies But sensornets have many different network protocols (collection, dissemination, etc.) Local coordination and communication pushes the narrow waist downwards 8.v.2006 MDM

89 Sensor Network Narrow Waist Hypothesis: in sensor networks, the narrow waist of is at layer 2 (single hop) But there are many L2 packet formats and protocols International spectrum allocation Media access Work at the network layer and above can provide guidance on what the narrow waist needs to provide 8.v.2006 MDM

90 Sensor Network Architecture Sensor-Net Application In-Network Storage Security System Management Power Management Time Coordination Discovery Address-Free Protocols Data Link Custody Transfer Sensor-Net Protocol Triggers Name-Based Protocols Suppression Predicates Caching Estimation Graphs Naming Media Access Timestamping Coding Assembly ACK Physical Architecture Sensing Energy Storage Carrier Sense Transmit Receive 8.v.2006 MDM

91 Single Hop Architecture (Polastre et al., SenSys 2005) Network Service Manager Network Protocol 1 Network Protocol 2 Network Protocol 3 Neighbors Send Receive SP Neighbor Table Msg Pool SP Adaptor A Data Link A Link Estimator SP Adaptor B Data Link B Link Estimator PHY A PHY B 8.v.2006 MDM

92 Futures and Pooling Send Pool Entry dest count B 4 msg Node A sleep TX sleep Node B sleep sleep sleep RX sleep 8.v.2006 MDM

93 Futures and Pooling Send Pool Entry dest count B 4 msg Node A sleep TX sleep Node B sleep sleep sleep RX sleep 8.v.2006 MDM

94 Futures and Pooling Send Pool Entry dest count B 4 msg Node A sleep TX sleep Node B sleep sleep sleep RX sleep 8.v.2006 MDM

95 Futures and Pooling Send Pool Entry dest count B 4 msg Node A sleep TX sleep Node B sleep sleep sleep RX sleep 8.v.2006 MDM

96 Futures and Pooling Send Pool Entry dest count B 4 msg Node A sleep TX sleep Node B sleep sleep sleep RX sleep 8.v.2006 MDM

97 The Sensor Cloud Network protocols within the patch are often address-free Collection, dissemination, diffusion, synopsis diffusion Application requirements are data-centric Addresses are critical for management Need to identify individual nodes Queries, etc. Need to address nodes from outside the network Current approaches are application-level IP-level support would enable traditional tools Huge numbers of devices 8.v.2006 MDM

98 IETF 6lowpan WG Question: how do you connect a low-power embedded wireless network to the larger Internet with IPv6? Wide range of issues: IP adaptation/packet Formats and interoperability Addressing schemes and address management Network management Routing in dynamically adaptive topologies Security, including set-up and maintenance Application programming interface Discovery (of devices, of services, etc) Implementation considerations 8.v.2006 MDM

99 Sensor Network Architecture Edge devices within the larger Internet cloud Not transit networks Data-centric within Collaborative operation Snooping, address-free Complex single-hop requirements Traditional layers do not apply Addressable from without Management, configuration, etc. 8.v.2006 MDM

100 Outline A Brave New World Platforms and hardware considerations Operating systems and software Network protocols and a network architecture An open alliance 8.v.2006 MDM

101 Changing the World 33m: m: m: 109,108,107 20m: 106,105,104 10m: 103, 102, v.2006 MDM

102 TinyOS Alliance Low-power wireless embedded networks need a close collaboration between academia and industry Many unsolved problems Revisiting old assumptions Remaining grounded in practical concerns The TinyOS Alliance mission Provide a forum to facilitate the development and maintenance of a stable,technically-sound base of TinyOS technology and surrounding tools through the creation of standard interfaces and protocols, vetted extensions, open reference implementations, technical documents,testing and verification suites, and educational materials 8.v.2006 MDM

103 TinyOS Alliance Structure (tentative) Grassroots: it!s about the contributors and their work Follow an IETF model Steering Committee Members, corporate members, contributing members Working groups WG WG WG Members Steering committee 8.v.2006 MDM

104 Working Groups T2 core WG TinyOS 2.x, core abstractions talked about today: platforms, maintenance, compiler efforts Full release planned for this summer Net2 WG Multihop protocols, single hop abstractions, network arch. Becoming major area of activity Network architecture talked about today Alliance WG Administrative formation (structure, contributions, etc.) Will eventually retire on full formation of alliance 8.v.2006 MDM

105 Learn, Participate, and Use 8.v.2006 MDM

106 Questions 8.v.2006 MDM