tinyos: an open platform for wireless sensor networks

Philip Levis

Stanford University

8.v.2006

9.v.2006

TinyOS: An Open Platform forWireless Sensor Networks

8.v.2006 MDM 2006 2

The EmNets Vision

• “Information technology (IT) is on the vergeof another revolution… The use of EmNets[embedded networks] throughout societycould well dwarf previous milestones.” 1

• “The motes [EmNet nodes] preview a futurepervaded by networks of wireless battery-powered sensors that monitor ourenvironment, our machines, and even us.” 2

1 National Research Council. Embedded, Everywhere, 2001.2 MIT Technology Review. 10 Technologies That Will Change the World, 2003.

8.v.2006 MDM 2006 3

Moore!s Law

8.v.2006 MDM 2006 4

Bell!s Law

1950 1960 1970 1980 1990 2000 2010

log

(use

rs/d

evic

e)

8.v.2006 MDM 2006 5Law enforcement and military:

pinpointing snipers in cities!

Applications

33m: 111

32m: 110

30m: 109,108,107

20m: 106,105,104

10m: 103, 102, 101

Biology: redwood micro"

climates and trends

Sustainable architecture: monitoring

and conserving water#energy use!

Medicine: monitoring patients

outside the o$ce!

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

Sensornets Today

Patch(tiny nodes)

Transit Gateway(PC, cellphone,

stargate)

Backend(PC)

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

AA Battery for a year: ~2.7 Ah / (365 days * 24 hours) = 300!A avg. draw

- Energy is defining metric: lifetime, form factor, resources

8.v.2006 MDM 2006 9

Moore!s Law

8.v.2006 MDM 2006 10

Moore!s Law with Energy

8.v.2006 MDM 2006 11

Microcontrollers

8.v.2006 MDM 2006 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-powernodes must still spend 99% of their time asleep.

• These extreme energy limitations, coupled with longlifetimes, large numbers, and embedment, completelychange hardware design, software design, OS structure,network protocols, and application semantics.

8.v.2006 MDM 2006 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 2006 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: howmuch current a node draws and for how long.

8.v.2006 MDM 2006 15

Sample Platforms

4-10kB RAM

40-250 kbps

8.v.2006 MDM 2006 16

Why So Little?

Power

8.v.2006 MDM 2006 17

Where the mica2 Energy Goes

110µAPower-down

3mAIdle, radio off

13-18mAIdle

20-25mAActive

2002

8.v.2006 MDM 2006 18

Where the Telos Energy Goes

10µAPower-down

50µAIdle, radio off

17-20mAIdle

18-21mAActive

2004

8.v.2006 MDM 2006 19

Lifetime

• 2 AA batteries is ~2700mAh

• To last a year, average draw must be 2-300µA

• Radio is principal cost

~30 years10 µATelos power-down

6 days17 mATelos idle

6 days18 mATelos active

~3 years110 µAMica2 power-down

8 days13 mAMica2 idle

5.5 days20 mAMica2 active

LifetimeDrawPlatform

8.v.2006 MDM 2006 20

Workload: Monitoring

• Low rate, periodic sampling (minutes/sample)

• Ad-hoc collection tree

• Last months-year

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

Sleeping

• Nodes must spend almost all of their time asleep

• To last 1 year:

• To last 2 years:

Telos

Mica2

Platform

1.6%

1%

Duty Cycle

22 min/day

15 min/day

Awake

3%

35%

Sleep

97%

65%

Active

Telos

Mica2

Platform

0.8%

0.2%

Duty Cycle

11 min/day

3 min/day

Awake

6%

87%

Sleep

94%

13%

Active

Difference between 10!A and 100!A

8.v.2006 MDM 2006 23

Sleeping, continued

• Minimize sleep current by turning off non-essential circuits

– Essential is usually a single low-speed oscillator

• Drive peripherals through alow-power oscillator

– Turn off core when possible

– Interrupt sources

sleep

wakeup

Power

Time

MCU

Radio

Flash

Sensor MCU

Radio

Flash

Sensor

8.v.2006 MDM 2006 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 2006 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 someonewill send to me

– I’ll wake up periodically and check

• Wakeup constants become important

• How often to wake up? sleep

wakeup

Power

Time

8.v.2006 MDM 2006 26

CPU Utilization(mica2)

Application uses 0.01% -

0.4% of the CPU

From “Simulating the Power Consumption of Large-Scale SensorNetwork Applications,” Shnayder et al., SenSys 2004.

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

Outline




• Networking and network protocols


8.v.2006 MDM 2006 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 executionenvironment for building and researching systems…

• … but how do you design one with these uncertainties?

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

TinyOS Basics, Continued(2002)

Data Link

Protocol

Data Link

Protocol

Hardware

Crypto

Software

Crypto

Component

Component

Interface

Task

8.v.2006 MDM 2006 33

TinyOS Composition

PacketTimers Logging

Application

Tree Routing

Single-hop packet

Timer

Logging StorageRouting

Collection

8.v.2006 MDM 2006 34

TinyOS Composition

PacketTimers Logging

Application

Tree Routing

Single-hop packet

Timer

Logging StorageRouting

Collection

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

8.v.2006 MDM 2006 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 2006 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 2006 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 simplercode, and can enforce fairness policies

• 80 cycles (10µs) to post and run a task

8.v.2006 MDM 2006 40

Network Types

• Depending on the processor, there are different dataalignment 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

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;

};

optsource

indexdest

sNo

optsource

index

destsNo

optsource

index

destsNo

MSP430

x86

network type

8.v.2006 MDM 2006 41

Platform Definition

• Diverse platforms, with some commonality:

• TinyOS 2.0 approach: a platform is a collection of chips

• Platform-specific code stitches chip code together

at45dbTDA5250MSP430eyes

stm25pXE1205MSP430tinynode

at45db stm25pCC2420MSP430Telos

CC2420pxa27xiMote2

at45dbCC2420ATMega128mica

at45dbCC1000ATMega128Mica2

StorageRadioMCUPlatform

8.v.2006 MDM 2006 42

Example: micaz

AppM

CC2420Radio Stack

TimerMilliC

MicaZ Component

Chip Component

ActiveMessageC

Atmega128Timer Stack

Application Component

CC2420AlarmC

32kHz Timer

Millisecond Timer

Communication

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

Peripherals, Continued

CC2420

Radio

MCU

SFDPWR

SPI Bus

• MCU is in deep sleep

SPI Bus

Timer

8.v.2006 MDM 2006 46


CC2420

Radio

MCU

SFDPWR

SPI Bus


• Timer wakes the MCU

SPI Bus

Timer

8.v.2006 MDM 2006 47


CC2420

Radio

MCU

SFDPWR

SPI Bus



• TinyOS powers up the radio,

enables receive interruptSPI Bus

Timer

8.v.2006 MDM 2006 48


CC2420

Radio

MCU

SFDPWR

SPI Bus




enables receive interrupt

• TinyOS returns MCU to sleep

SPI Bus

Timer

8.v.2006 MDM 2006 49


CC2420

Radio

MCU

SFDPWR

SPI Bus






• Packet arrives and wakes MCU

SPI Bus

Timer

8.v.2006 MDM 2006 50


CC2420

Radio

MCU

SFDPWR

SPI Bus







• TinyOS powers up bus, reads

in received packet

SPI Bus

Timer

8.v.2006 MDM 2006 51


CC2420

Radio

MCU

SFDPWR

SPI Bus







• TinyOS powers up bus, reads

in received packet

• TinyOS turns off radio,

processes packet

SPI Bus

Timer

8.v.2006 MDM 2006 52

MCU Power States

Power-save

Power-down

Standby

Ext. Standby

Idle

ADC,I/O

EEPROMTimer0MainClock

ExternalClock

ExternalInterrupts

State

ATMega128

While reading/writing packets to

the radio, the MCU cannot drop

below the idle state.

While waiting for packet reception

or transmission to complete, the

MCU can drop into power-save.

8.v.2006 MDM 2006 53

Computing a Power State

Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State

8.v.2006 MDM 2006 54


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State

• Application turns on radio

8.v.2006 MDM 2006 55


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State


– Radio sets sleep state dirty

8.v.2006 MDM 2006 56


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State



• Scheduler completes

– Sees sleep state is dirty,recalculates sleep state

8.v.2006 MDM 2006 57


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State





– Goes to power-down

8.v.2006 MDM 2006 58


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State






• Packet wakes up TinyOS

8.v.2006 MDM 2006 59


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State







– Stack starts reading inpacket from bus

– Bus sets sleep state dirty

8.v.2006 MDM 2006 60


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State











8.v.2006 MDM 2006 61


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State











– Goes to idle

8.v.2006 MDM 2006 62

Power State Override

• Sometimes, hardware state is not sufficient to calculatethe 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 2006 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 providesome compile-time promises of system behavior

• Fine-grained component control enables fine-grainedpower management

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

Outline




• Network protocols and a network architecture


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

Testing the Hypothesis

• We don!t know what these networks will look like, so we!llbuild 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 2006 68

Sensor Network Protocols Today

Phy

Link/MAC

Topology

Network

Transport

Application

RadioMetrixRFM

CC1000

Bluetooth 802.15.4eyes

nordic

WooMacSMACTMAC

WiseMAC

FPS

MintRoute

ReORg

PAMAS

CGSR

DBF

MMRP

TBRPF

BMAC

DSDV

ARADSR

TORA

GSR GPSR GRAD

Ascent

SPIN

SPAN

Arrive

AODV

GAFResynch

Yao

Diffusion

Deluge Trickle Drip

RegionsHood EnviroTrack TinyDB

PC

TTDD

Pico

FTSP

STRAW

ZMAC

TOSSIM

Drain

8.v.2006 MDM 2006 69

Defining an Architecture

• Protocol research, applications, and real deploymentsshow 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 understandand define a sensor network architecture

– Provide a structure for protocols andapplications, separating concerns andpromoting interoperability

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

The Two Major Protocols

• Most simple sensornets start with twoprotocols

• Protocol 0: Dissemination

– Reliably deliver data to every node in anetwork

– Reconfiguration, programs, queries

– Basic mechanism for network control

• Protocol 1: Collection

– Deliver data from every node to one ormore sinks

– Basic mechanism for gathering data

8.v.2006 MDM 2006 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, thenetwork quickly broadcasts the new data

8.v.2006 MDM 2006 73

Some Networking Challenges

• Loss over space

• Loss over time

• Asymmetry

• Energy

• Bandwidth

8.v.2006 MDM 2006 74

Trickle

• Polite gossip: “Every once in a while, broadcast what datayou have, unless you!ve heard some other nodesbroadcast 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 2006 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 2006 76

Example Trickle Execution

time

!

B

C

transmission suppressed transmission reception

A

k%&c

'

'

'

8.v.2006 MDM 2006 77


time

!

B

C


A

k%&c

'

&

'

tA1

8.v.2006 MDM 2006 78


time

!

B

C


A

k%&c

'

(

'

tA1

tC1

8.v.2006 MDM 2006 79


time

!

B

C


A

k%&c

'

(

'

tA1

tB1

tC1

8.v.2006 MDM 2006 80


time

!

B

C


A

k%&c

'

'

'

tA1

tB1

tC1

8.v.2006 MDM 2006 81


time

!

B

C


A

k%&c

&

'

&

tA1

tB1

tC1

tB2

8.v.2006 MDM 2006 82


time

!

B

C


A

k%&c

&

'

&

tA1

tB1

tC1

tB2

tC2

8.v.2006 MDM 2006 83


time

!

B

C


A

k%&c

&

'

&

tA1

tB1

tC1

tA2

tB2

tC2

8.v.2006 MDM 2006 84


time

!

B

C


A

k%&c

'

'

'

tA1

tB1

tC1

tA2

tB2

tC2

8.v.2006 MDM 2006 85

Short Listen Effect

• Lack of synchronization leads to the “short listen effect”

• For example, B transmits three times:

A

B

C

D

Time

!

8.v.2006 MDM 2006 86

Simulated Propagation

Time

Time To Reprogram, Tau, 10 Foot Spacing

(seconds)

18-20

16-18

14-16

12-14

10-12

8-10

6-8

4-6

2-4

0-2

• New data (20 bytes)

at lower left corner

• 16 hop network

• Time to reception in

seconds

• Set !l = 1 sec

• Set !h = 1 min

• 20s for 16 hops

• Wave of activity

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

Sensor Network Narrow Waist

• Hypothesis: in sensor networks, the narrow waist of is atlayer 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 provideguidance on what the narrow waist needs to provide

8.v.2006 MDM 2006 90

Sensor Network Architecture

Pow

er

Managem

ent

Syste

m M

anagem

ent

Tim

e C

oord

ination

Sensor-Net Protocol

Security

Dis

covery

Carrier SensePhysical Architecture

Transmit Receive

Data LinkMedia Access Timestamping Coding ACKAssembly

Sensor-Net Application

Address-Free Protocols Name-Based Protocols

PredicatesSuppression Estimation NamingGraphs

In-Network Storage

Caching

Custody Transfer Triggers

Energy StorageSensing

8.v.2006 MDM 2006 91

Single Hop Architecture(Polastre et al., SenSys 2005)

SP

Data Link A Data Link B

SP Adaptor A SP Adaptor B

Network

Protocol 1

PHY A PHY B

Network

Protocol 2

Network

Protocol 3

Network

Service

Manager

Lin

kE

stim

ato

r

Neighbor Table Msg Pool

Neighbors Send Receive

Lin

kE

stim

ato

r

8.v.2006 MDM 2006 92

Futures and Pooling

Node A

Node B

sleep

sleep sleep

TX

RX

sleep

sleep sleep

dest count

B 4

msgSend Pool Entry

8.v.2006 MDM 2006 93

Futures and Pooling

Node A

Node B

sleep

sleep sleep

TX

RX

sleep

sleep sleep

dest count

B 4

msgSend Pool Entry

8.v.2006 MDM 2006 94

Futures and Pooling

Node A

Node B

sleep

sleep sleep

TX

RX

sleep

sleep sleep

dest count

B 4

msgSend Pool Entry

8.v.2006 MDM 2006 95

Futures and Pooling

Node A

Node B

sleep

sleep sleep

TX

RX

sleep

sleep sleep

dest count

B 4

msgSend Pool Entry

8.v.2006 MDM 2006 96

Futures and Pooling

Node A

Node B

sleep

sleep sleep

TX

RX

sleep

sleep sleep

dest count

B 4

msgSend Pool Entry

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

IETF 6lowpan WG

• Question: how do you connect a low-power embeddedwireless 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 2006 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 2006 100

Outline




• Network protocols and a network architecture


8.v.2006 MDM 2006 101

Changing the World

33m: 111

32m: 110

30m: 109,108,107

20m: 106,105,104

10m: 103, 102, 101

8.v.2006 MDM 2006 102

TinyOS Alliance

• Low-power wireless embedded networks need a closecollaboration 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 andmaintenance of a stable,technically-sound base of TinyOStechnology and surrounding tools through the creation ofstandard interfaces and protocols, vetted extensions, openreference implementations, technical documents,testing andverification suites, and educational materials…”

8.v.2006 MDM 2006 103

TinyOS Alliance Structure(tentative)

• Grassroots: it!s about thecontributors and theirwork

– Follow an IETF model

• Members, corporatemembers, contributingmembers

• Working groups

• Steering committee

Steering

Committee

WG WGWG

Members

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

Learn, Participate, and Usehttp://www.tinyos.net/

8.v.2006 MDM 2006 106

Questions

tinyos: an open platform for wireless sensor networks

Documents