T2: What the Second Generation Holds

Philip LevisStanford University

17.i.2007

T2: What the Second Generation Holds

17.i.2007 EE380 2

Moore’s Law

17.i.2007 EE380 3

Bell’s Law

1950 1960 1970 1980 1990 2000 2010

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

log(u

sers/de

vice)

17.i.2007 EE380 4Law 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: monitoringand conserving water/energy use.



Medicine: monitoring patientsoutside the office.

17.i.2007 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

17.i.2007 EE380 6

Sensornets Today

Patch(tiny nodes)

Transit Gateway(PC, cellphone,

stargate)

Backend(PC)

17.i.2007 EE380 7

The Hardware

• Two platform classes: gateway and embedded wireless.

Linux: MB of RAMActive power: WSleep power: mW

TinyOS: KB of RAMActive power: mWSleep 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

17.i.2007 EE380 8

Moore’s Law

17.i.2007 EE380 9

Moore’s Law with Energy

17.i.2007 EE380 10

Microcontrollers

17.i.2007 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.

17.i.2007 EE380 12

Outline

• A Brave New World

• Platforms and hardware considerations

• Operating systems and software

• Networking and network protocols

• An open alliance

17.i.2007 EE380 13

Sample Platforms

4-10kB RAM

40-250 kbps

17.i.2007 EE380 14

Why So Little?

Power

17.i.2007 EE380 15

Where the mica2 Energy Goes

0

5

10

15

20

MCU radio rx radio tx storageread

storagewrite

Active Power Draw (mA) 0

5

10

15

20

25

mica2

Active Power Draw (mA)

MCURadio

Active 20-25mA

Idle 13-18mA

Idle, radio off 3mA

Power-down 110µA 2002

17.i.2007 EE380 16

Where the Telos Energy Goes

0

5

10

15

20

MCU radio rx radio tx storageread

storagewrite

Active Power Draw (mA) 0

5

10

15

20

25

Telos revB

Active Power Draw (mA)

MCURadio

Active 18-21mA

Idle 17-20mA

Idle, radio off 50µA

Power-down 10µA 2004

17.i.2007 EE380 17

Lifetime

• 2 AA batteries is ~2700mAh

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

• Radio is principal cost

Platform Draw Lifetime

Mica2 active 20 mA 5.5 days

Mica2 idle 13 mA 8 days

Mica2 power-down 110 µA ~3 years

Telos active 18 mA 6 days

Telos idle 17 mA 6 days

Telos power-down 10 µA ~30 years

17.i.2007 EE380 18

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.

17.i.2007 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.

17.i.2007 EE380 20

Outline




• Networking and network protocols


17.i.2007 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?

17.i.2007 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

17.i.2007 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

17.i.2007 EE380 24

TinyOS Basics, Continued(2002)

Data LinkProtocol

Data LinkProtocol

HardwareCrypto

SoftwareCrypto

Component

Component

Interface

Task

17.i.2007 EE380 25

TinyOS Composition

PacketTimers Logging

Application

Tree Routing

Single-hop packet

Timer

Logging StorageRouting

Collection

17.i.2007 EE380 26

TinyOS Composition

PacketTimers Logging

Application

Tree Routing

Single-hop packet

Timer

Logging StorageRouting

Collection

17.i.2007 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

17.i.2007 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

17.i.2007 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

17.i.2007 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

17.i.2007 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

17.i.2007 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

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

17.i.2007 EE380 33

MCU Power States

State ExternalInterrupts

ExternalClock

MainClock

Timer0 EEPROM ADC,I/O

Idle

Ext. Standby

Standby

Power-save

Power-down

ATMega128

While reading/writing packets tothe radio, the MCU cannot dropbelow the idle state.

While waiting for packet receptionor transmission to complete, theMCU can drop into power-save.

17.i.2007 EE380 34

Computing a Power State

Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State

17.i.2007 EE380 35


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State

• Application turns on radio

17.i.2007 EE380 36


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State

• Application turns on radio– Radio sets sleep state dirty

17.i.2007 EE380 37


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State


• Scheduler completes– Sees sleep state is dirty,

recalculates sleep state

17.i.2007 EE380 38


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State




– Goes to power-down

17.i.2007 EE380 39


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State





• Packet wakes up TinyOS

17.i.2007 EE380 40


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State


• Scheduler completes – Sees sleep state is dirty,



• Packet wakes up TinyOS– Stack starts reading in

packet from bus

– Bus sets sleep state dirty

17.i.2007 EE380 41


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State






packet from bus




17.i.2007 EE380 42


Scheduler McuSleep

CC2420

SPI Bus

Application

Hardware State






packet from bus




– Goes to idle

17.i.2007 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

17.i.2007 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

17.i.2007 EE380 45

Outline




• Network protocols and a network architecture


17.i.2007 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…

17.i.2007 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…

17.i.2007 EE380 48

Sensor Network Protocols Today

Phy

Link/MAC

Topology

Network

Transport

Application

RadioMetrixRFM

CC1000Bluetooth 802.15.4

eyesnordic

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

FTSPSTRAW

ZMAC

TOSSIM

Drain

17.i.2007 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 and

applications, separating concerns andpromoting interoperability

17.i.2007 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

17.i.2007 EE380 51

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

17.i.2007 EE380 52

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

17.i.2007 EE380 53

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

17.i.2007 EE380 54

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

17.i.2007 EE380 55

Example Trickle Execution

time

B

C

transmission suppressed transmission reception

A

k=1c

0

0

0

17.i.2007 EE380 56


time

B

C


A

k=1c

0

1

0

tA1

17.i.2007 EE380 57


time

B

C


A

k=1c

0

2

0

tA1

tC1

17.i.2007 EE380 58


time

B

C


A

k=1c

0

2

0

tA1

tB1

tC1

17.i.2007 EE380 59


time

B

C


A

k=1c

0

0

0

tA1

tB1

tC1

17.i.2007 EE380 60


time

B

C


A

k=1c

1

0

1

tA1

tB1

tC1

tB2

17.i.2007 EE380 61


time

B

C


A

k=1c

1

0

1

tA1

tB1

tC1

tB2

tC2

17.i.2007 EE380 62


time

B

C


A

k=1c

1

0

1

tA1

tB1

tC1

tA2

tB2

tC2

17.i.2007 EE380 63


time

B

C


A

k=1c

0

0

0

tA1

tB1

tC1

tA2

tB2

tC2

17.i.2007 EE380 64

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

• Simulated 400 node 16 hop network

• Time to reception in seconds

• Set l = 1 sec, h = 1 min

• 20s for 16 hops• Wave of activity

• Real 71 node 8 hop network• Time to reception in seconds

• Set l = 1 sec, h = 1 min

• Time to “catch,” long tail

17.i.2007 EE380 65

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)

17.i.2007 EE380 66

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…

17.i.2007 EE380 67

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

17.i.2007 EE380 68

Narrow Waist Proposal: FWP

XSINK

X

A B C

• Fair Waiting Protocol– A multihop protocol receives a fair share of local bandwidth

– Also provides protocol isolation

• Basic mechanism: grant-to-send– Every transmission has an optimal time value t

– Only the recipient may transmit during this time t

• Current area of active work

17.i.2007 EE380 69

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.

17.i.2007 EE380 70

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

• Definition without evaluation is dangerous…– Per-hop vs. end-to-end fragmentation and assembly

– Cost: prr-(f+h) vs. fh x prr-1

17.i.2007 EE380 71

Outline




• Network protocols and a network architecture


17.i.2007 EE380 72

Changing the World

33m: 111

32m: 110

30m: 109,108,107

20m: 106,105,104

10m: 103, 102, 101





17.i.2007 EE380 73

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…”

17.i.2007 EE380 74

TinyOS Alliance Structure(tentative)

• Grassroots: it’s about the contributors and their work– Follow an IETF model

• Members, corporate members, contributing members

• Working groups

• Steering committee

Steering Committee

WG WGWG

Members

17.i.2007 EE380 75

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

17.i.2007 EE380 76

Questions

T2: What the Second Generation Holds

Documents

Transcript of T2: What the Second Generation Holds