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
• A Brave New World
• Platforms and hardware considerations
• Operating systems and software
• Networking and network protocols
• An open alliance
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
Peripherals, Continued
CC2420
Radio
MCU
SFDPWR
SPI Bus
• MCU is in deep sleep
• Timer wakes the MCU
SPI Bus
Timer
8.v.2006 MDM 2006 47
Peripherals, Continued
CC2420
Radio
MCU
SFDPWR
SPI Bus
• MCU is in deep sleep
• Timer wakes the MCU
• TinyOS powers up the radio,
enables receive interruptSPI Bus
Timer
8.v.2006 MDM 2006 48
Peripherals, Continued
CC2420
Radio
MCU
SFDPWR
SPI Bus
• MCU is in deep sleep
• Timer wakes the MCU
• TinyOS powers up the radio,
enables receive interrupt
• TinyOS returns MCU to sleep
SPI Bus
Timer
8.v.2006 MDM 2006 49
Peripherals, Continued
CC2420
Radio
MCU
SFDPWR
SPI Bus
• MCU is in deep sleep
• Timer wakes the MCU
• TinyOS powers up the radio,
enables receive interrupt
• TinyOS returns MCU to sleep
• Packet arrives and wakes MCU
SPI Bus
Timer
8.v.2006 MDM 2006 50
Peripherals, Continued
CC2420
Radio
MCU
SFDPWR
SPI Bus
• MCU is in deep sleep
• Timer wakes the MCU
• TinyOS powers up the radio,
enables receive interrupt
• TinyOS returns MCU to sleep
• Packet arrives and wakes MCU
• TinyOS powers up bus, reads
in received packet
SPI Bus
Timer
8.v.2006 MDM 2006 51
Peripherals, Continued
CC2420
Radio
MCU
SFDPWR
SPI Bus
• MCU is in deep sleep
• Timer wakes the MCU
• TinyOS powers up the radio,
enables receive interrupt
• TinyOS returns MCU to sleep
• Packet arrives and wakes MCU
• 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
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
Hardware State
• Application turns on radio
8.v.2006 MDM 2006 55
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
Hardware State
• Application turns on radio
– Radio sets sleep state dirty
8.v.2006 MDM 2006 56
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
Hardware State
• Application turns on radio
– Radio sets sleep state dirty
• Scheduler completes
– Sees sleep state is dirty,recalculates sleep state
8.v.2006 MDM 2006 57
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
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
8.v.2006 MDM 2006 58
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
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
8.v.2006 MDM 2006 59
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
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 inpacket from bus
– Bus sets sleep state dirty
8.v.2006 MDM 2006 60
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
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 inpacket from bus
– Bus sets sleep state dirty
• Scheduler completes
– Sees sleep state is dirty,recalculates sleep state
8.v.2006 MDM 2006 61
Computing a Power State
Scheduler McuSleep
CC2420
SPI Bus
Application
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 inpacket from bus
– Bus sets sleep state dirty
• Scheduler completes
– Sees sleep state is dirty,recalculates sleep 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
• 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 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
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
A
k%&c
'
&
'
tA1
8.v.2006 MDM 2006 78
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
A
k%&c
'
(
'
tA1
tC1
8.v.2006 MDM 2006 79
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
A
k%&c
'
(
'
tA1
tB1
tC1
8.v.2006 MDM 2006 80
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
A
k%&c
'
'
'
tA1
tB1
tC1
8.v.2006 MDM 2006 81
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
A
k%&c
&
'
&
tA1
tB1
tC1
tB2
8.v.2006 MDM 2006 82
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
A
k%&c
&
'
&
tA1
tB1
tC1
tB2
tC2
8.v.2006 MDM 2006 83
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
A
k%&c
&
'
&
tA1
tB1
tC1
tA2
tB2
tC2
8.v.2006 MDM 2006 84
Example Trickle Execution
time
!
B
C
transmission suppressed transmission reception
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
• 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 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