1. 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

2. Outline Problem Statement The case for flexible link control SP
Design
Implementation
Evaluation
Implications and Conclusions

3. Wireless Sensor Networks Today
Tracking
Application
Sensing
Application
Pt-Pt
Routing
1-1
Neighborhood
Sharing
1-k / k-1
Aggregation
N --- 1
Data
Collection
N-1
Robust
Dissemination
1-N ??
B-MAC
S-MAC
PAMAS
Telos
MicaZ
Mica2
Dot
Mica

4. A Unifying Abstraction is Needed
Tracking
Application
Sensing
Application
Pt-Pt
Routing
1-1
Neighborhood
Sharing
1-k / k-1
Aggregation
N --- 1
Data
Collection
N-1
Robust
Dissemination
1-N
Link Abstraction
B-MAC
S-MAC
PAMAS
Telos
MicaZ
Mica2
Dot
Mica

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 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
WSNs different… like to deal with them at an abstract layer
What do we expect a traditional link layer abstraction to do?
Have abstractions for a long time, don’t stretch much. We propose a new one that can stretch… for wsns
Some abstractions from the specific link protocol yet address factors pertaining to wsns
Addresses new set of issues of wsns
Indpenedent of link technology
Cases to make:
Possible to get an efficient abstraction
Abstract
Different
** fatter, what are the knobs for reconfiguration
** turn knobs for different tradeoffs
** metric for deciding settings, abstracting the effect of the knobs from the underlying link
Can you do it in a way that is
- reasonable to use
- works with multiple links

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
Network
Protocol
For Link A
Network
Protocol SP
Network
Protocol
For Link B
Link Abstraction
Link
Protocol A
Link
Protocol A
Link
Protocol B
Link
Protocol B

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

10. Flexible Link Control

11. Application & Services
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
Application & Services
Scheduling
Fragmentation
Routing
Organization
Link protocol
Color of link protocol
Radio hardware

12. Link/Network Protocols
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
Link/Network Protocols
Data
Control
B-MAC
PHY

13. 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
Packet part?
wakeup
wakeup
wakeup
TX [preamble]
sleep
packet
sleep
sleep
Node 1
time
wakeup
wakeup
wakeup
wakeup
wakeup
wakeup RX
Node 2
sleep
packet
sleep
sleep
time

14. 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
Radio
Independent
Radio
Dependent

15. B-MAC: Uses of a flexible MAC protocol
S-MAC/T-MAC
Start radio
Radio started, CSMA enabled
SYNC packet received
… 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
S-MAC
off
LPL
CCA
ACK
off on
off on 1 2 3 4 5 6 7 8 9 10
B-MAC
Radio

16. Factored vs Layered Protocols
topology
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
Factored link layer never worse than the 1 size fits all, often much better
Crude control, same thing that was there in 802.2
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

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

18. Forwarded <10,000 packets
Surge Application Network 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
Forwarded <10,000 packets
1 hop from
base station
Forwarded ~35, (85%) packets
Duty cycle 75% higher
without optimization
Leaf Nodes

19. Tradeoffs: Latency vs Reliability Surge Application
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)

20. Tradeoffs: Latency for Energy Factored 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

21. 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 (January 7, 2004)
Default MAC protocol in use for 10 months

22. SP Design, Implementation and Evaluation

23. SP Design SP Goals B-MAC showed SP must Generality Efficiency
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

24. Traditional Opaque Layering
Message Transmission
Message Reception SP
Data
Data
Message Transmission
Message Reception

25. Translucent Layering in SP
Link Abstracted Parameters
Message Transmission
Message Reception
Link Abstracted Feedback SP
Control
Data
Data
Feedback
Link Specific Parameters
Message Transmission
Message Reception
Link Specific
Feedback

26. 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

27. Message Reception Message arrives from link SP dispatches
Receive SP
Message arrives from link
SP dispatches
Network protocols establish
naming/addressing
filtering

28. Message Transmission Messages placed in shared message pool
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

29. Neighbor Management SP provides a shared neighbor table
Neighbors
Send
Receive
Neighbor Table
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

30. SP Architecture SP Data Link A Data Link B SP Adaptor A SP Adaptor B
Network
Protocol 1
PHY A
PHY B
Protocol 2
Protocol 3
Service
Manager
Estimator
Link
Neighbor Table
Msg Pool
Neighbors
Send
Receive

31. 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

32. Design Space for SP Expressive Simplified 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:
Difficult, Complex
AIDA (message batching & processing)
CFIC (wireless QoS with 1 bit)
Zhao/Woo (difficult networking environment)
SP approach:
Define the minimal set of abstraction primitives

33. SP Design: Collaborative Interface for Message Transmissions
Control
Reliability Best effort to transmit the msg
Urgency Priority mechanism
Feedback
Congestion Was the channel busy?
Should I slow down?
Phase Was there a better time to send?
Decouple app sampling from communication

34. SP Message Futures Submit an SP Message for Transmission
Network Protocol
SP Message
packets
Submit an SP Message for Transmission
Message added to message pool
SP requests the link transmit the 1st packet
Link tells SP the transmission completed
SP asks protocol for next packet
Protocol updates packet entry in message pool
1st packet
(1)
Next Packet Handler
(5)
(6)
Send
Msg Pool
(2)
Message
Dispatch SP
msg*
transmit
completed
inspect
(3)
(4)
Motivating Example:
AIDA
50% less energy used
80% less end-to-end delay
Link Protocol

35. sp_message_t Neighbor Table Message Pool destination message quantity
Required
Link
Network
sp_message_t 1
destination message
quantity
urgent
reliability
phase
congestion
address_t
1st TOSMsg to send # of pkts to send
on or off
D adjustment
true or false 2
control
address time on
time off
listen
quality
address_t
local time node wakes
local time node sleeps
true or false
estimated link quality
feedback
Network Protocol
Network Protocol
Network Protocol
Neighbor Table
Msg Pool SP
Link Protocol

36. 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

37. Link Protocols Sampled Slotted 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, , etc

38. 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

39. 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

40. Using SP with B-MAC SP CC1000 Neighbors Send Receive PER RSSI
Neighbor Table
Msg Pool SP
Transmit
Transmit Done
Update
Receive
Link Estimate
+Control
+Feedback
Neighbors
Request
B-MAC SP Adaptor
Re-
Transmit
Urgent
Reliable
Preamble Length
Process RX
Update Schedule
Link
Quality
TX Actions
RX Actions
PER
RSSI
Control
Transmit
Receive
B-MAC TX RX
LPL
Wakeup
CCA
CC1000

41. Slotted Protocols: 15.4 Beacons
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
CSMA Contention Period
Beacon
Data
Ack
Data
Beacon
sleep
Superframe Duration
Beacon Frame Duration

42. Using SP with 802.15.4 Coordinator Neighbors wake for beacon period
beacon TX
send
done
packet
received SP
send
Coordinator
15.4
start radio
send beacon
stop radio
superframe complete
Beacon
Data
Data
Ack
RF Channel
If yes, wake up
beacon RX
TX first
packet
Ack
received
15.4
Neighbors
are messages pending?
Update
schedule
TX done
send done reliability set
Stop radio
packet RX SP

43. Network Protocols Collection Routing (MintRoute)
Dissemination (Trickle)
Aggregation (Synopsis Diffusion)

44. MintRoute MintRoute SP Send Receive Intercept MultiHop Neighbors
SP Message
forwarding queue
Choose Parent
Send Route
Beacons
Update Neighbor
ETX
MultiHop Neighbors
1st packet
MultiHop Engine
MintRoute
Next Packet Handler
Send
Receive
Neighbors
Send
Receive SP
Neighbor Table
Msg Pool
Neighbor
Functions
Message
Dispatch
Link
Estimator
Link Protocol

45. 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)
(5)
(2)
(4)
(3)

46. Synopsis Diffusion Sends “synopses” towards a collection point
Needs a gradient to know which way to aggregate
Simple Implementation
Synopsis Diffusion
Node Address
Gradient Manager
Neighbors
Send
Receive SP
Neighbor Table
Msg Pool
Neighbor
Functions
Message
Dispatch
Link
Estimator
Link Protocol

47. Synopsis Diffusion Requires a gradient to the collection point
Collaborative Implementation
MintRoute
Maintaining Hop Count
Synopsis Diffusion
Gradient Manager
Neighbors
Send
Receive SP
Neighbor Table
Msg Pool
Neighbor
Functions
Message
Dispatch
Link
Estimator
Link Protocol

48. Benchmarks Minimal performance reduction in single hop
Compare to B-MAC paper
Compare to IEEE
Simpler multihop/network protocol code
Power consumption
Network protocol co-existence

49. Results: mica2 Throughput

50. Results: mica2 Throughput

51. Results: mica2 Throughput

52. Results: mica2 Throughput

53. Results: mica2 Throughput

54. Results: Single Hop Benchmarks (802.15.4)
1.5% maximum duty cycle
12.5% maximum duty cycle

55. Results: MintRoute Code Size: mica2: 28% smaller Telos: 23% smaller
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
.057
.059
.095
Parent Changes 1
1.58 5
Parent Evictions
Code Size:
mica2: 28% smaller
Telos: 23% smaller
Comparable size when including SP code size

56. Results: Trickle

57. 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%

58. Implications and Conclusions

59. 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?

60. 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?

61. Open Issues No explicit security mechanism Naming
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

62. Open Issues Time Synchronization Frequency Hopping
Pass post-arbitration time stamping
Data correlation
Protocol synchronization
Frequency Hopping
Requires Time Synchronization
Link or Network mechanism?
May be part of reliability bit

63. 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 &