A Unifying Abstraction for Wireless Sensor Networks

A Unifying Abstractionfor Wireless Sensor Networks

Joseph PolastreOctober 20, 2005

Collaborators: David Culler, Jonathan Hui, Philip Levis, Scott Shenker, Ion Stoica, and Jerry Zhao

2

Outline

Problem Statement The case for flexible link control SP

Design ImplementationEvaluation

Implications and Conclusions

3

SensingApplication

TrackingApplication

AggregationN --- 1

DataCollection

N-1

RobustDissemination

1-N

Pt-PtRouting

1-1

NeighborhoodSharing1-k / k-1

B-MAC802.15.4 S-MAC PAMAS

Telos MicaZ Mica2 Dot Mica

Wireless Sensor Networks Today

??

4

SensingApplication

TrackingApplication

AggregationN --- 1

DataCollection

N-1

RobustDissemination

1-N

Pt-PtRouting

1-1

NeighborhoodSharing1-k / k-1

B-MAC802.15.4 S-MAC PAMAS

Telos MicaZ Mica2 Dot Mica

A Unifying Abstraction is Needed

Link Abstraction

5

A New Abstraction?

Why not IP? Why not Ethernet? IEEE 802.2?

Problem: Power! IP/Ethernet don’t account for it In network processing (not end-to-end)

Local per-link decisions Fuzzy sensor network boundaries

Link protocols know link quality Network protocols may exchange sleeping schedule Coordination occurs across layer boundaries

6

Proposal for SP:“Sensornet Protocol” Solution: A data link layer abstraction to

enable efficient communication in wireless sensor networksExposing control is critical for long lived

operationEnable link protocol interchangeability

underneath optimized network protocols (routing, aggregation, organization, etc)

Smallest, most powerful primitives to execute higher level protocols efficiently

7

Goals of our abstraction

Generality Provide the necessary primitives so the abstraction is not

circumvented These primitives allow cooperative decision making between link

and network protocols Reconfiguration of the link protocol (acknowledgements, power

management, etc) Choose tradeoffs (reliability, latency, power consumption, etc) Support scheduling of radio active periods (power scheduling)

Efficiency Not hinder protocol performance or power consumption Co-existence of cooperative network protocols

8

Evaluation of efficiency

NetworkProtocol

For Link A

NetworkProtocol

SP

NetworkProtocol

For Link B

LinkProtocol

A

LinkProtocol

A

LinkProtocol

B

LinkProtocol

B

Link Abstraction

9

An abstraction enables…(and this talk will show)

Network protocols above operate efficiently Work equally well with both single-hop and multi-hop

protocols Co-existence of multiple link/network protocols Network Protocol evolution independent of

underlying link technology as IP provides for transport protocols

Separation of concerns Network protocols perform network functionality Link protocols perform single hop link functionality

Flexible Link Control

12

Challenge

Create a factored system Interchangeable protocols,

cross-layer communication Retain efficiency of layered

protocols Proposal

Factored link protocol of primitives with control interface

Flexibility to meet network protocol needs

Think ILP

Radio hardware

Link protocol

Routing Organization

Scheduling Fragmentation

Application & Services

13

B-MAC: Principles

Reconfigurable MAC protocol Flexible control Hooks for sub-primitives

Backoff/Timeouts Duty Cycle Acknowledgements

Feedback to higher protocols Model of operation Project costs upward

Minimal implementation Minimal state

PHY

B-MAC

Link/Network Protocols

Data Control

14

B-MAC Primitives:

Low Power Listening (LPL) Synchronization-free primitive

Energy Cost = RX + TX + Listen Goal: minimize idle listening

Periodically wake up, sample channel, sleep

Properties Wakeup time fixed (graph) “Check Time” between wakeups

variable Preamble length matches wakeup

interval Overhear all data packets in cell

Duty cycle depends on number of neighbors and cell traffic

RX

wak

eu

p

wak

eu

pw

ake

up

wak

eu

p

wak

eu

p

wak

eu

p

wak

eu

p

wak

eu

p

wak

eu

p

TX [preamble]

sleep sleep sleep

sleepsleepsleep

Node 2

Node 1time

time

pack

etpa

cket

15

B-MAC Primitives:

Interfaces Interface StdControl

Power control of radio Init – Init Done Start – Start Done Stop – Stop Done

Interface SendMessage Submit a packet for transmission

Interface ReceiveMessage Signal a packet to higher layers

Interface RadioCoordinator Provide time synchronization info

Interface MacControl Control MAC Primitives Enable/Disable CCA Enable/Disable ACK Halt Transmission

Interface MacBackoff Control MAC CSMA Primitives Initial Backoff Length Congestion Backoff Length

Interface LowPowerListening Control Preamble Sampling Get/Set Mode Get/Set Listening Mode Get/Set Transmit Mode Get/Set Preamble Length Get/Set Check Interval

RadioIndependent

RadioDependent

16

B-MAC:Uses of a flexible MAC protocol S-MAC/T-MAC 1) Start radio

2) Radio started, CSMA enabled3) SYNC packet received

… wait for RTS-CTS period4) Send RTS with CSMA enabled5) CTS received6) Disable CSMA, Enable ACK7) Send DATA8) Receive ACK9) After timeout, Stop radio10) Radio stopped

Radio

1 2 3 4 5 6 7 8 9 10

B-MAC

S-MACLPLCCAACK

offoffoffonon

17

Factored vs Layered Protocols Experimental Setup:

n nodes send as quickly as possible to saturate the channel

Factored link layer never worse than traditional approach Pay for what you use

Simple B-MAC design Optimize basic ops

Protocol ROM RAM

S-MAC 6274 516

B-MAC w/ DC/ACK/RTS-CTS 4616 277

B-MAC w/ DC & ACK 4386 172

B-MAC w/ Duty Cycling 4092 170

B-MAC w/ ACK 3340 168

B-MAC 3046 166

7

8

9

10

1

6

5

4

3

2

0

7

8

9

10

1

6

5

4

3

2

0

topology

0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

0 5 10 15 200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty

B-MAC B-MAC w/ ACK B-MAC w/ RTS-CTSS-MAC unicast S-MAC broadcast Channel Capacity

Th

rou

gh

pu

t (b

ps)

0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

0 5 10 15 200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


Th

rou

gh

pu

t (b

ps)

0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

0 5 10 15 200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


Th

rou

gh

pu

t (b

ps)

0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

0 5 10 15 200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


Th

rou

gh

pu

t (b

ps)

0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

0 5 10 15 200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Number of nodes

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


Th

rou

gh

pu

t (b

ps)

20

Surge Application Run B-MAC in a real world application

8 days/40000 data readings in deployment

Surge Multihop Data Collection includes: Data reporting every 3 minutes B-MAC check:sleep ratio: 1:100 ReliableRoute – B-MAC reconfiguration Power metering in the link protocol

Simple routing protocol optimization Turn off long preambles when sending

to the base station (one hop away) Base station always on

21

Surge ApplicationNetwork power consumption of a factored link protocol Duty cycle dependant on

position in network Leaf nodes Middle nodes forwarding 1 hop from base station

benefit from reconfiguration

2.35% worst case node duty cycle

0 0.5 1 1.5 2 2.5 3 3.5

x 104

0

0.5

1

1.5

2

2.5

3

Number of packets forwarded or sent

Du

ty C

yc

le (

%)

Effect of number of transmissions on duty cycle

0 1 2 3 4 50

0.5

1

1.5

2

2.5

3Effect of node depth on duty cycle

Number of hops

Du

ty C

ycle

(%

)

Average Duty Cycle

Leaf Nodes

1 hop frombase station

• Forwarded ~35,000 (85%) packets• Duty cycle 75% higher without optimization

Forwarded <10,000 packets

0 1 2 3 4 50

0.5

1

1.5

2

2.5

3Effect of node depth on duty cycle

Number of hops

Du

ty C

ycle

(%

)

Average Duty Cycle

22

Tradeoffs: Latency vs ReliabilitySurge Application

Reliability 98.5% of all packets delivered Some nodes achieved an

astounding 100% delivery …but communication links are

volatile Retransmissions required After 5 retries, give up and

pick a new parent Actual latency

Retransmission delay Contention delay (infrequent)

0 1 2 3 4 5 60

100

200

300

400

500

600

700

800

900

1000

1100

Number of hops

Lat

ency

(m

s)

Latency of B-MAC in a monitoring application

B-MAC Average Latency Std DevB-MAC Average LatencyB-MAC Minimum Expected Latency

23

0 2000 4000 6000 8000 100000

50

100

150

200

250

300

350

400

450

500

550

Latency (ms)

En

erg

y (m

J)

Effect of latency on mean energy consumption

B-MACS-MACAlways On

Tradeoffs: Latency for EnergyFactored vs Traditional Protocol

Assume a multihop packet is generated every 10 sec No queuing delay

allowed

Delay the packet S-MAC sleeps longer

between listen period B-MAC increases the

check interval and preamble length

S-MAC Default Configuration

B-MAC Default Configuration

11 10 9 3 2 111 10 9 3 2 1

24

Impact of Flexible Link Control Designed and implemented a flexible, low power media

access protocol Provides useful primitives for network services with minimal state Removes network services from the MAC protocol

organization, synchronization, routing, fragmentation Flexible control allows network protocols to be built efficiently for

varying workloads Media Access Reconfiguration is essential for efficient

deployment of wireless sensor networks Low Power Listening, with protocol knowledge, can perform

better than synchronized protocols Included in TinyOS 1.1.3 (January 7, 2004)

Default MAC protocol in use for 10 months

SPDesign, Implementation and Evaluation

26

SP Design

SP Goals Generality Efficiency

B-MAC showed Cooperation needed for efficient, composible system

SP must Abstract the link (Generality)

Support a wide variety of link and network protocols Prevent a significant loss of efficiency

Discourage circumventing the abstraction

27

Traditional Opaque LayeringMessageTransmission

MessageReception

MessageTransmission

MessageReception

SP

Dat

a Data

28

Translucent Layering in SPMessageTransmission

MessageReception

MessageTransmission

MessageReception

Link AbstractedParameters

Link SpecificParameters

SP

Link AbstractedFeedback

Dat

a

Con

trol D

ata

Feedback

Link SpecificFeedback

29

Properties of SP

SP provides mechanisms for network protocols to operate efficiently Network protocols may introduce policy

Three key elements of SP: Data Reception Data Transmission Neighbor Management

30

Message Reception

Message arrives from link SP dispatches Network protocols establish

naming/addressing filtering

SP

Receive

31

Message Transmission

Messages placed in shared message pool All entries are a promise to send a

packet in the future

Messages include Abstracted link control parameters Abstracted link feedback data References to packets associated with this message

SP

Msg Pool

Send Receive

32

Neighbor Management

SP provides a shared neighbor tableCooperatively managedSP mediates interaction using table

No policy on admission/eviction by SP Link Power Scheduling information

SP

Neighbor Table Msg Pool

Neighbors Send Receive

33

SP

Data Link A Data Link B

SP Adaptor A SP Adaptor B

NetworkProtocol 1

PHY A PHY B

NetworkProtocol 2

NetworkProtocol 3

NetworkService

Manager

LinkE

stimator

LinkE

stimator



SP Architecture

34

Proposed functionality for SP

What are the most commonly used link mechanisms? Commonly implemented network policies? Reliable Delivery

Acknowledgements/ARQ RTS/CTS

Priority Congestion control Fragmentation Link quality estimation

35

Design Space for SP

Expressive Multiple priority levels Explicit reliability Exact latency times

Simplified Single bit priority Reliability on or off Urgent or not

Real Time Systems & Networking Motivating Wireless Examples:

AIDA (message batching & processing)CFIC (wireless QoS with 1 bit)Zhao/Woo (difficult networking environment)

Difficult, Complex

SP approach:Define the minimal set of abstraction primitives

36

SP Design:Collaborative Interface for Message Transmissions

ControlReliability Best effort to transmit the msgUrgency Priority mechanism

FeedbackCongestionWas the channel busy?

Should I slow down?Phase Was there a better time to

send? Decouple app sampling from communication

37

SP

Msg Pool

Network Protocol

msg*

Next PacketHandler

packetsSP Message

MessageDispatch

transmit

completed

(1)

(2)

(3) (4)

(5)

(6)

1st packet

Send

insp

ect

Link Protocol

SP Message Futures

1) Submit an SP Message for Transmission

2) Message added to message pool

3) SP requests the link transmit the 1st packet

4) Link tells SP the transmission completed

5) SP asks protocol for next packet

6) Protocol updates packet entry in message pool

Motivating Example:AIDA50% less energy used80% less end-to-end delay

38

SP

Network Protocol Network Protocol Network Protocol


Message Pool

sp_message_t

destinationmessagequantityurgentreliability

phasecongestion

address_t1st TOSMsg to send# of pkts to sendon or offon or off

adjustmenttrue or false

con

tro

lfe

edb

ack

Neighbor Table

2

1

NetworkLinkRequiredNeighbor

addresstime ontime offlistenquality

address_tlocal time node wakeslocal time node sleepstrue or falseestimated link quality

Link Protocol

39

TinyOS Implementation of SP

Neighbor table Iterator (max, get, etc) Commands

Insert, Remove Adjust Find Neighbors

Events Admit Evicted Expired

Message Pool SP message pointers

stored nextPacket() event Control and feedback

stored in message structure

SP



NetworkProtocol 1

PHY A PHY B

NetworkProtocol 2

NetworkProtocol 3

NetworkService

Manager

LinkE

stimator

LinkE

stimator



SP



NetworkProtocol 1

PHY A PHY B

NetworkProtocol 2

NetworkProtocol 3

NetworkService

Manager

LinkE

stimator

LinkE

stimator

Neighbor TableNeighbor Table Msg PoolMsg Pool


40

Link Protocols

Sampled Communication is unsynchronized Data transfer wakes up receiver B-MAC, Aloha with Preamble Sampling, Mica1 LPL,

CC2500, Reactive Radio

Slotted Communication is synchronized Data transfers occur in “slots” S-MAC, T-MAC, TRAMA, 802.15.4, etc

41

Sampling Protocols: B-MAC LPL

Create an “SP adaptor” for B-MAC Emulates functionality that doesn’t exist in B-MAC Controls the length of the preamble Controls backoffs based on message type

Counts backoffs for congestion feedback Controls clear channel assessment

B-MAC Returns schedule information about wakeups Provides phase feedback hints

42

SP Adaptor for B-MAC

B-MAC periodically samples the channel for activity Messages are sent at local wakeup times

Receivers can synchronize to senders Receiving a message provides implicit time synchronization

information SP Adaptor updates node schedules in neighbor table

Subsequent messages “piggybacked” on long messages Mitigate the overall cost of long messages Use the SP message pool

43

Using SP with B-MAC

RX Actions

Receive

ProcessRX

Transmit

UpdateSchedule

SP

CC1000


Neighbors Send ReceiveR

SS

I

B-MAC SP Adaptor

LinkQuality

PE

R

ReceiveControl

PreambleLength

UrgentReliable

Re-Transmit

B-MAC TX RX LPL Wakeup CCA

Transmit+Control

Transmit Done+Feedback

Link EstimateRequest

TX Actions

UpdateNeighbors

44

Slotted Protocols: 15.4 Beacons

15.4 Protocol Each node beacons on its

own schedule Other nodes “scan” for 15.4

beacons, synchronize

SP Neighbor information

inserted by 15.4 Instructs 15.4 to wake

during other beacon periods

Bea

con

Bea

con

Superframe Duration

Beacon Frame Duration

sleep

Dat

a

Dat

a

Ack

CSMA Contention Period

45

Using SP with 802.15.4

RF Channel

15.4

SPwake forbeacon period

start radiosend beacon

Be

aco

n

beaconTX

are messagespending?

If yes,wake up

send

Da

ta

beaconRX

senddone

TX firstpacket

packetRX

Da

ta

Ack

TXdone

Ackreceived

send donereliability set

packetreceived

stop radiosuperframe complete

Stopradio

SP

15.4

Coordinator

Neighbors

Updateschedule

46

Network Protocols

Collection Routing (MintRoute) Dissemination (Trickle) Aggregation (Synopsis Diffusion)

47

SP

Msg Pool

Min

tRo

ute

Next PacketHandler

forwarding queueSP Message

MessageDispatch

1st packet

Send Receive

Neighbor Table

Neighbors

Mu

ltiHo

p E

ng

ine

Mu

ltiHo

p N

eigh

bo

rs

Send

SendRoute

Beacons

UpdateNeighbor

ETX

ChooseParent

Receive Intercept

NeighborFunctions

Link Protocol

LinkEstimator

MintRoute

Send Receive

48

Trickle Suppression mechanism assumes message broadcasts

are immediate and atomic Cancel command is required due to:

Transmission delays from SP, collision avoidance, TDMA slots Slotted protocols require broadcast emulation.

Sampling Protocol Slotted Protocol

(1)

(2)

(3)(4)

(5)

49

Synopsis Diffusion Sends “synopses” towards a collection point

Needs a gradient to know which way to aggregate

Link Protocol

LinkEstimator

Synopsis DiffusionGradient Manager

Node Address

Simple Implementation

SP

Msg PoolMessageDispatch

Send Receive

Neighbor Table

Neighbors

NeighborFunctions

50

Synopsis Diffusion Requires a gradient to the collection point

Link Protocol

LinkEstimator

Synopsis DiffusionGradient Manager

MintRouteMaintaining Hop Count

Collaborative Implementation

SP

Msg PoolMessageDispatch

Send Receive

Neighbor Table

Neighbors

NeighborFunctions

51

Benchmarks

Minimal performance reduction in single hopCompare to B-MAC paperCompare to IEEE 802.15.4

Simpler multihop/network protocol code Power consumption Network protocol co-existence

52

Results: mica2 Throughput

0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

Th

rou

gh

pu

t (kb

ps)

Nodes (n)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty

B-MACSPSP + CCSP + LPL + CCSP + LPL + CC + PhaseChannel Capacity

53


0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

Th

rou

gh

pu

t (kb

ps)

Nodes (n)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


54


0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

Th

rou

gh

pu

t (kb

ps)

Nodes (n)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


55


0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

Th

rou

gh

pu

t (kb

ps)

Nodes (n)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


56


0 5 10 15 200

2000

4000

6000

8000

10000

12000

14000

16000

Th

rou

gh

pu

t (kb

ps)

Nodes (n)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Pe

rce

nta

ge

of C

ha

nn

el C

ap

aci

ty


57

Results:Single Hop Benchmarks (802.15.4)

1.5% maximum duty cycle 12.5% maximum duty cycle

58

Results:MintRoute

Code Size: mica2: 28% smaller Telos: 23% smaller Comparable size when

including SP code size

Telos Results Min Med Avg Max

Duty Cycle (%) 3.1 4.5 4.4 4.9

Delivery 94.1 96.6 97.4 100

Retx/pkt 0 .057 .059 .095

Parent Changes 0 1 1.58 5

Parent Evictions 0 0 0 0

59

Results: Trickle

60

Results: Combining Network Protocols (mica2)

Neither MR nor SD know about each other SP’s message pool allows batching and power savings Overall power savings of 35%

extends node lifetime by over 54%

Implicationsand

Conclusions

62

SP: Abstraction, Service, or Protocol? Goal: Define a unifying abstraction. What exactly is SP?

Certainly an abstractionActs as a service between link and network

protocols Is SP itself a protocol?

63

SP: Abstraction, Service, or Protocol? SP does not dictate any header fields

Messages are opaque to SP Relies on SP adaptor to emulate or add missing fields needed

for correct operation Our SP implementation relies on abstract data types

Can query for address, length, etc Implicit “header fields” may not actually be in the message

Challenge: Is there a set of header fields that are necessary in WSNs for interoperability across nodes?

64

Open Issues

No explicit security mechanism Message content opaque to SP Link, Network, and App security can be built transparently to SP

Naming SP takes no position on naming, based on link Network protocols need mechanism

Establish mapping between names

Grouping and Multicast Providing group addressing can simply link and network

protocols similar to neighbor table

65

Open Issues

Time SynchronizationPass post-arbitration time stampingData correlationProtocol synchronization

Frequency HoppingRequires Time SynchronizationLink or Network mechanism?May be part of reliability bit

66

Conclusions

Effective link abstraction, SP, allows network protocols to run efficiently on varying power management schemes Power savings Smaller, simpler code

Multiple network protocols benefit from coexistence Coordination and cooperation

Effective separation of mechanism and policy Building block for a sensor network architecture

May even apply to the Internet Architecture & 802.11

A Unifying Abstraction for Wireless Sensor Networks

Documents

link qualitynetwork

link protocol acknowledgements

data link layer abstraction

cooperative network

flexible link controlexplain

shownetwork protocols

efficient wsnswhy protocols

higher level protocols