Transcript SP: A Unifying Link Abstraction

A Unifying Abstraction
for Wireless Sensor Networks
Joseph Polastre
October 20, 2005
Collaborators: David Culler, Jonathan Hui, Philip
Levis, Scott Shenker, Ion Stoica, and Jerry Zhao
Outline
Problem Statement
 The case for flexible link control
 SP

 Design
 Implementation
 Evaluation

Implications and Conclusions
2
Wireless Sensor Networks Today
Tracking
Application
Pt-Pt
Routing
1-1
Neighborhood
Sharing
1-k / k-1
Sensing
Application
Aggregation
N --- 1
Data
Collection
N-1
Robust
Dissemination
1-N
??
802.15.4
Telos
B-MAC
MicaZ
S-MAC
Mica2
PAMAS
Dot
Mica
3
A Unifying Abstraction is Needed
Tracking
Application
Pt-Pt
Routing
1-1
Neighborhood
Sharing
1-k / k-1
Sensing
Application
Aggregation
N --- 1
Data
Collection
N-1
Robust
Dissemination
1-N
Link Abstraction
802.15.4
Telos
B-MAC
MicaZ
S-MAC
Mica2
PAMAS
Dot
Mica
4
A New Abstraction?

Why not IP? Why not Ethernet? IEEE 802.2?

Problem:
IP/Ethernet don’t account for it
 In network processing (not end-to-end)
 Power!

Local per-link decisions
 Fuzzy sensor network boundaries
 Link protocols know link quality
 Network protocols may exchange sleeping schedule
 Coordination occurs across layer boundaries
5
Proposal for SP:
“Sensornet Protocol”

Solution: A data link layer abstraction to
enable efficient communication in wireless
sensor networks
 Exposing
control is critical for long lived
operation
 Enable link protocol interchangeability
underneath optimized network protocols
(routing, aggregation, organization, etc)
 Smallest, most powerful primitives to execute
higher level protocols efficiently
6
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
7
Evaluation of efficiency
Network
Protocol
For Link B
Network
Protocol
SP
Network
Protocol
For Link A
Link Abstraction
Link
Protocol
A
Link
Protocol
A
Link
Protocol
B
Link
Protocol
B
8
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
9
Flexible Link Control
Challenge

Create a factored system



Interchangeable protocols,
cross-layer communication
Retain efficiency of layered
protocols
Application & Services
Scheduling
Fragmentation
Routing
Organization
Proposal


Factored link protocol of
primitives with control
interface
Flexibility to meet network
protocol needs

Link protocol
Radio hardware
Think ILP
12
B-MAC: Principles



Reconfigurable MAC protocol
Flexible control
Hooks for sub-primitives




Feedback to higher protocols




Backoff/Timeouts
Duty Cycle
Acknowledgements
Model of operation
Project costs upward
Minimal implementation
Minimal state
Link/Network Protocols
Data
Control
B-MAC
PHY
13
B-MAC Primitives:
Low Power Listening (LPL)

Synchronization-free primitive



Periodically


Energy Cost = RX + TX + Listen
Goal: minimize idle listening
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
packet
wakeup
sleep
sleep
wakeup
RX
sleep
wakeup
sleep
TX [preamble]
packet
Node 2
sleep
wakeup
Node 1
wakeup
Duty cycle depends on number of
neighbors and cell traffic
wakeup

wakeup

time
sleep
time
14
B-MAC Primitives:
Interfaces

Interface StdControl







Interface RadioCoordinator

Control MAC CSMA Primitives
Initial Backoff Length
Congestion Backoff Length
Signal a packet to higher layers


Control MAC Primitives
Enable/Disable CCA
Enable/Disable ACK
Halt Transmission
Interface MacBackoff



Submit a packet for transmission
Interface ReceiveMessage

Interface MacControl




Power control of radio
Init – Init Done
Start – Start Done
Stop – Stop Done
Interface SendMessage


Provide time synchronization info
Interface LowPowerListening






Control Preamble Sampling
Get/Set Mode
Get/Set Listening Mode
Get/Set Transmit Mode
Get/Set Preamble Length
Get/Set Check Interval
Radio
Independent
Radio
Dependent
15
B-MAC:
Uses of a flexible MAC protocol

S-MAC/T-MAC
off LPL
S-MAC
off
on CCA
on
off ACK 1 2 3 4 5 6 7 8 9 10
B-MAC
Radio
1) Start radio
2) Radio started, CSMA enabled
3) SYNC packet received

4)
5)
6)
7)
8)
9)
10)
… wait for RTS-CTS period
Send RTS with CSMA enabled
CTS received
Disable CSMA, Enable ACK
Send DATA
Receive ACK
After timeout, Stop radio
Radio stopped
16
Factored vs Layered Protocols
1
Experimental Setup:



n nodes send as
quickly as possible to
saturate the channel
4
5
7
14000
12000
Pay for what you use
6
B-MAC
B-MAC w/ ACK
B-MAC w/ RTS-CTS
S-MAC unicast
S-MAC broadcast
Channel Capacity
16000
1
0.9
0.8
0.7
10000
Simple B-MAC design

0
8
Factored link layer never
worse than traditional
approach

3
9
Throughput (bps)

2
10
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
0.6
8000
0.5
6000
0.4
0.3
4000
0.2
2000
0
Percentage of Channel Capacity
topology
0.1
0
5
10
15
0
20
Number of nodes
17
Data Set Node Locations:
6
Surge 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

4
13
Run B-MAC in a real world application

5
11
2
10
12
7
8
85 feet
9
Simple routing protocol optimization

Turn off long preambles when sending
to the base station (one hop away)
 Base station always on
20
Surge Application
Network power consumption of a factored link protocol

Duty cycle dependant on
position in network

2.35% worst case node duty cycle
Effect of node depth on duty cycle

Duty Cycle (%)
3
2.5
Duty Cycle (%)
2
Duty Cycle (%)
Leaf nodes
3
Duty Cycle
Effect of number of transmissions onAverage
duty cycle
 Middle nodes forwarding
3
 1 hop from base station
2.5
benefit from reconfiguration 2.5 Forwarded <10,000
Effect of node depth on duty cycle
Average Duty Cycle
packets
2
2
1.5
1 hop from
base station
1.5
• Forwarded ~35,000
(85%) packets
• Duty cycle 75% higher
without optimization
1
1.5
1
Leaf Nodes
1
0.5
0.5
0.5
0
0
0
00
1
2
3
Number of hops
4
5
0
1
0.5
1
2
3
2
Number of hops
1.5
4
2.5
Number of packets forwarded or sent
5
3
3.5
214
x 10
Tradeoffs: Latency vs Reliability
Surge Application
Latency of B-MAC in a monitoring application
1100

Reliability
1000

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)
900
800
700
Latency (ms)

B-MAC Average Latency Std Dev
B-MAC Average Latency
B-MAC Minimum Expected Latency
600
500
400
300
200
100
0
0
1
2
3
4
Number of hops
5
6
22
Tradeoffs: Latency for Energy
Factored vs Traditional Protocol
Effect of latency on mean energy consumption
550
500
11
10
9
3
2
1
B-MAC
S-MAC
Always On

450
400

350
Energy (mJ)
Assume a multihop
packet is generated
every 10 sec
300
250

200
Delay the packet

S-MAC Default Configuration
150
100

50
0
0
2000
4000
6000
Latency (ms)
8000
10000
No queuing delay
allowed
S-MAC sleeps longer
between listen period
B-MAC increases the
check interval and
preamble length
B-MAC Default Configuration
23
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



Flexible control allows network protocols to be built efficiently for
varying workloads
Media Access Reconfiguration is essential for efficient
deployment of wireless sensor networks


organization, synchronization, routing, fragmentation
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
24
SP
Design, Implementation and Evaluation
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
26
Traditional Opaque Layering
Message
Transmission
Message
Reception
Data
Data
SP
Message
Transmission
Message
Reception
27
Translucent Layering in SP
Link Abstracted
Parameters
Message
Transmission
Message
Reception
Link Abstracted
Feedback
Data
Message
Transmission
Message
Reception
Feedback
Link Specific
Parameters
Data
Control
SP
Link Specific
Feedback
28
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
29
Message Reception
Receive
SP
Message arrives from link
 SP dispatches
 Network protocols establish

 naming/addressing
 filtering
30
Message Transmission
Send
Receive
Msg Pool
SP

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
31
Neighbor Management
Neighbors
Neighbor Table
Send
Receive
Msg Pool
SP

SP provides a shared neighbor table
 Cooperatively
managed
 SP mediates interaction using table
No policy on admission/eviction by SP
 Link Power Scheduling information

32
SP Architecture
Network
Service
Manager
Network
Protocol 1
Neighbors
Network
Protocol 3
Receive
Msg Pool
SP Adaptor B
Data Link B
Link
Estimator
PHY A
Link
Estimator
Data Link A
Send
Neighbor Table
SP
SP Adaptor A
Network
Protocol 2
PHY B
33
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
34
Design Space for SP

Expressive
 Multiple
priority levels
 Explicit reliability
 Exact latency times
Real Time Systems & Networking
Difficult, Complex

Simplified
 Single
bit priority
 Reliability on or off
 Urgent or not
Motivating Wireless Examples:
AIDA (message batching & processing)
CFIC (wireless QoS with 1 bit)
Zhao/Woo (difficult networking environment)
SP approach:
Define the minimal set of abstraction primitives
35
SP Design:
Collaborative Interface for Message Transmissions

Control
 Reliability
 Urgency

Best effort to transmit the msg
Priority mechanism
Feedback
 Congestion

Should I slow down?
 Phase

Was the channel busy?
Was there a better time to send?
Decouple app sampling from communication
36
SP Message Futures
Network Protocol
SP Message
packets
1st packet
(1)
(5)
Next Packet
Handler
(6)
Send
Msg Pool
SP
(2)
Message
Dispatch
(3)
msg*
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
(4)
Link Protocol
Motivating Example:
AIDA
50% less energy used
80% less end-to-end delay
37
Neighbor Table
Neighbor
Required
Link
Message Pool
sp_message_t
Network
address
time on
time off
listen
quality
address_t
local time node wakes
local time node sleeps
true or false
estimated link quality
Network Protocol
control
2
destination
message
quantity
urgent
reliability
feedback
1
phase
D adjustment
congestion true or false
Network Protocol
Neighbor Table
address_t
1st TOSMsg to send
# of pkts to send
on or off
on or off
Network Protocol
Msg Pool
SP
Link Protocol
38
TinyOS Implementation of SP
Network
Service
Manager
Network
Protocol 1
Neighbors

Neighbor table


Insert, Remove
Adjust
Find Neighbors
 Events



Admit
Evicted
Expired
Data Link A
Network
Protocol 3
Receive
Msg Pool
SP Adaptor B
Data Link B
PHY A

Link
Estimator

SP Adaptor A
Link
Estimator
(max, get, etc)
 Commands
Send
Neighbor Table
SP
 Iterator
Network
Protocol 2
PHY B
Message Pool
 SP
message pointers
stored
 nextPacket() event
 Control and feedback
stored in message
structure
39
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
40
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
41
SP Adaptor for B-MAC

B-MAC periodically samples the channel for activity


Receivers can synchronize to senders



Messages are sent at local wakeup times
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
42
Using SP with B-MAC
Neighbors
Send
Neighbor Table
SP
Transmit
+Control
Receive
Transmit Done
+Feedback
Msg Pool
Update
Receive
Neighbors
Link Estimate
Request
B-MAC SP Adaptor
ReTransmit
Urgent Preamble Process
Reliable Length
RX
B-MAC
TX
Transmit
RX
Receive
LPL
Wakeup
CC1000
RSSI
Control
RX Actions
Link
Quality
PER
TX Actions
Update
Schedule
CCA
43
Slotted Protocols: 15.4 Beacons


SP


sleep
Beacon
Each node beacons on its
own schedule
Other nodes “scan” for 15.4
beacons, synchronize
Data

CSMA Contention Period
Data
Ack
15.4 Protocol
Beacon

Superframe Duration
Beacon Frame Duration
Neighbor information
inserted by 15.4
Instructs 15.4 to wake
during other beacon
periods
44
Using SP with 802.15.4
send
send
done
stop radio
superframe complete
beacon
RX
Update
schedule
packet
RX
Ack
Data
TX first
packet
RF Channel
Ack
received
TX
done
15.4
send done
reliability set
15.4
Stop
radio
Neighbors
are messages
pending?
Data
Beacon
start radio
send beacon
If yes,
wake up
SP
packet
received
Coordinator
wake for beacon
TX
beacon period
SP
45
Network Protocols
Collection Routing (MintRoute)
 Dissemination (Trickle)
 Aggregation (Synopsis Diffusion)

46
MintRoute
Receive
1st packet
Next Packet
Handler
Send
Receive
Send
Neighbors
Neighbor Table
Neighbor
Functions
forwarding queue
MintRoute
SP Message
Intercept
MultiHop Engine
SP
Update
Neighbor
ETX
MultiHop Neighbors
Choose
Parent
Send
Route
Beacons
Send
Receive
Msg Pool
Message
Dispatch
Link
Estimator
Link Protocol
47
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
(5)
(1)
(2)
(4)
(3)
48
Synopsis Diffusion

Sends “synopses” towards a collection point
 Needs
a gradient to know which way to aggregate
Simple Implementation
Node
Address
SP
Synopsis Diffusion
Gradient
Manager
Send
Neighbors
Neighbor Table
Neighbor
Functions
Receive
Msg Pool
Message
Dispatch
Link
Estimator
Link Protocol
49
Synopsis Diffusion

Requires a gradient to the collection point
Collaborative Implementation
MintRoute
Maintaining Hop Count
SP
Synopsis Diffusion
Gradient
Manager
Send
Neighbors
Neighbor Table
Neighbor
Functions
Receive
Msg Pool
Message
Dispatch
Link
Estimator
Link Protocol
50
Benchmarks

Minimal performance reduction in single
hop
 Compare
to B-MAC paper
 Compare to IEEE 802.15.4
Simpler multihop/network protocol code
 Power consumption
 Network protocol co-existence

51
Results: mica2 Throughput
16000
14000
0.9
12000
0.8
0.7
10000
0.6
8000
0.5
6000
0.4
4000
2000
0
0
0.3
B-MAC
SP
SP + CC
SP + LPL + CC
SP + LPL + CC + Phase
Channel Capacity
5
10
Nodes (n)
Percentage of Channel Capacity
Throughput (kbps)
1
0.2
0.1
15
0
20
52
Results: mica2 Throughput
16000
14000
0.9
12000
0.8
0.7
10000
0.6
8000
0.5
6000
0.4
4000
2000
0
0
0.3
B-MAC
SP
SP + CC
SP + LPL + CC
SP + LPL + CC + Phase
Channel Capacity
5
10
Nodes (n)
Percentage of Channel Capacity
Throughput (kbps)
1
0.2
0.1
15
0
20
53
Results: mica2 Throughput
16000
14000
0.9
12000
0.8
0.7
10000
0.6
8000
0.5
6000
0.4
4000
2000
0
0
0.3
B-MAC
SP
SP + CC
SP + LPL + CC
SP + LPL + CC + Phase
Channel Capacity
5
10
Nodes (n)
Percentage of Channel Capacity
Throughput (kbps)
1
0.2
0.1
15
0
20
54
Results: mica2 Throughput
16000
14000
0.9
12000
0.8
0.7
10000
0.6
8000
0.5
6000
0.4
4000
2000
0
0
0.3
B-MAC
SP
SP + CC
SP + LPL + CC
SP + LPL + CC + Phase
Channel Capacity
5
10
Nodes (n)
Percentage of Channel Capacity
Throughput (kbps)
1
0.2
0.1
15
0
20
55
Results: mica2 Throughput
16000
14000
0.9
12000
0.8
0.7
10000
0.6
8000
0.5
6000
0.4
4000
2000
0
0
0.3
B-MAC
SP
SP + CC
SP + LPL + CC
SP + LPL + CC + Phase
Channel Capacity
5
10
Nodes (n)
Percentage of Channel Capacity
Throughput (kbps)
1
0.2
0.1
15
0
20
56
Results:
Single Hop Benchmarks (802.15.4)
1.5% maximum duty cycle
12.5% maximum duty cycle
57
Results:
MintRoute
Telos Results
Min
Med Avg
Max
Duty Cycle (%)
3.1
4.5
4.9
Delivery
94.1 96.6 97.4 100
Retx/pkt
0
4.4
.057 .059 .095
Parent Changes 0
1
1.58 5
Parent Evictions 0
0
0

0
Code Size:



mica2: 28% smaller
Telos: 23% smaller
Comparable size when
including SP code size
58
Results:
Trickle
59
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%
60
Implications
and
Conclusions
SP:
Abstraction, Service, or Protocol?
Goal: Define a unifying abstraction.
 What exactly is SP?

 Certainly
an abstraction
 Acts as a service between link and network
protocols
 Is SP itself a protocol?
62
SP:
Abstraction, Service, or Protocol?

SP does not dictate any header fields



Our SP implementation relies on abstract data types



Messages are opaque to SP
Relies on SP adaptor to emulate or add missing fields needed
for correct operation
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?
63
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
64
Open Issues

Time Synchronization
 Pass
post-arbitration time stamping
 Data correlation
 Protocol synchronization

Frequency Hopping
 Requires
Time Synchronization
 Link or Network mechanism?
 May be part of reliability bit
65
Conclusions

Effective link abstraction, SP, allows network
protocols to run efficiently on varying power
management schemes
 Power savings
 Smaller, simpler

Multiple network protocols benefit from
coexistence
 Coordination


code
and cooperation
Effective separation of mechanism and policy
Building block for a sensor network architecture
 May
even apply to the Internet Architecture & 802.11
66