A Unifying Abstraction for Wireless Sensor Networks

1
A Unifying Abstractionfor 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
Aggregation N --- 1
Data Collection N-1
Robust Dissemination 1-N
Pt-Pt Routing 1-1
Neighborhood Sharing 1-k / k-1
??
B-MAC
802.15.4
S-MAC
PAMAS
Telos
MicaZ
Mica2
Dot
Mica
4
A Unifying Abstraction is Needed
Tracking Application
Sensing Application
Aggregation N --- 1
Data Collection N-1
Robust Dissemination 1-N
Pt-Pt Routing 1-1
Neighborhood Sharing 1-k / k-1
Link Abstraction
5
A New Abstraction?

• Why not IP? Why not Ethernet? IEEE 802.2?
• Problem
• Power! IP/Ethernet dont 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 SPSensornet 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

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

• Explain briefly what it is
• How B-MAC uses translucent layering
• How it enables more efficient WSNs
• Why protocols need it
• Why it doesnt solve SP
• 10 slides max

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

Application Services
Scheduling
Fragmentation
Routing
Organization
Link protocol
Radio hardware
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

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

TX preamble
sleep
sleep
sleep
packet
Node 1
time
RX
sleep
sleep
sleep
Node 2
packet
time
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

Radio Independent
Radio Dependent
16
B-MACUses 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
LPL CCA ACK
off
off
on
off
on
1
2
3
4
5
6
7
8
9
10
B-MAC
Radio
17
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

18
B-MACUses of a flexible MAC protocol

• Low Power Bulk Transfer
• Send n packets in a burst

• Set LPL mode ON
• Radio started, CSMA enabled
• Send first packet
• Include number of remaining packets in data
  payload
• Disable CSMA, LPL
• Enable ACK
• Send n-1 packets
• Enable CSMA, LPL
• Disable ACK

Bulk Transfer
LPL CCA ACK
off
on
off
on
off
on
1
2
3
4
5
6
7
B-MAC
Radio
19
Fragmentation SupportFactored vs Layered Protocol

• S-MAC
• RTS-CTS Fragmentation Support
• B-MAC
• Network protocol sends initial data packet with
  number of fragments pending
• Disable backoff LPL for rest of fragments

• Measure energy consumption at C(bottleneck node)
• Minimizing power relieson controlling link layer
  primitives

Sometimes the black boxis worse than the naïve
approach
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 checksleep ratio 1100
• 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

Forwarded lt10,000 packets
1 hop from base station

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

Leaf Nodes
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)

23
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
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

25
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 Layering
MessageTransmission
MessageReception
SP
Data
Data
MessageTransmission
MessageReception
28
Translucent Layering in SP
MessageTransmission
MessageReception
Link AbstractedParameters
Link AbstractedFeedback
SP
Data
Control
Data
Feedback
Link SpecificParameters
MessageTransmission
MessageReception
Link Specific Feedback
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
Receive
SP

• Message arrives from link
• SP dispatches
• Network protocols establish
• naming/addressing
• filtering

31
Message Transmission
Send
Receive
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

32
Neighbor Management
Neighbors
Send
Receive
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

33
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
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
36
SP DesignCollaborative 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

37
SP Message Futures
Network Protocol
packets
SP Message

• 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 PacketHandler
(5)
(6)
Send
(2)
Message Dispatch
msg
SP
transmit
completed
inspect
(3)
(4)
Motivating Example AIDA 50 less energy used 80
less end-to-end delay
Link Protocol
38
Neighbor Table
Message Pool
sp_message_t
Network
Link
Required
Neighbor
1
destinationmessage quantity urgent reliability p
hase congestion
address_t 1st TOSMsg to send of pkts to send on
or off on or off D adjustment true or false
2
control
addresstime 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
SP
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

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 doesnt 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
Neighbors
Send
Receive
SP
Receive
Transmit
Transmit Done
Link Estimate
Update
Control
Feedback
Request
Neighbors
B-MAC SP Adaptor
ProcessRX
UpdateSchedule
Link Quality
PreambleLength
Urgent Reliable
Re- Transmit
RX Actions
TX Actions
RSSI
PER
Control
Transmit
Receive
B-MAC
TX
RX
LPL
Wakeup
CCA
CC1000
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

CSMA Contention Period
Beacon
Beacon
Data
Data
Ack
sleep
Superframe Duration
Beacon Frame Duration
45
Using SP with 802.15.4
send done
SP
wake forbeacon period
beaconTX
packet received
send
Coordinator
15.4
stop radio superframe complete
start radio send beacon
Beacon
Data
Data
Ack
RF Channel
If yes,wake up
beacon RX
TX first packet
Ack received
15.4
Neighbors
are messagespending?
send donereliability set
Update schedule
TXdone
Stopradio
packet RX
SP
46
Network Protocols

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

47
MintRoute
Send
Receive
Intercept
forwarding queue
SP Message
SendRoute Beacons
UpdateNeighbor ETX
ChooseParent
MintRoute
1st packet
MultiHop Engine
MultiHop Neighbors
Next PacketHandler
Send
Receive
Send
Receive
Neighbors
SP
Message Dispatch
Neighbor Functions
Link Estimator
Link Protocol
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)
(5)
(2)
(4)
(3)
49
Synopsis Diffusion

• Sends synopses towards a collection point
• Needs a gradient to know which way to aggregate

Synopsis Diffusion
Simple Implementation
Gradient Manager
Node Address
Send
Receive
Neighbors
SP
Message Dispatch
Neighbor Functions
Link Estimator
Link Protocol
50
Synopsis Diffusion

• Requires a gradient to the collection point

Collaborative Implementation
Synopsis Diffusion
MintRoute Maintaining Hop Count
Gradient Manager
Send
Receive
Neighbors
SP
Message Dispatch
Neighbor Functions
Link Estimator
Link Protocol
51
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

52
Results mica2 Throughput
53
Results mica2 Throughput
54
Results mica2 Throughput
55
Results mica2 Throughput
56
Results mica2 Throughput
57
ResultsSingle Hop Benchmarks (802.15.4)
1.5 maximum duty cycle
12.5 maximum duty cycle
58
ResultsMintRoute

• Code Size
• mica2 28 smaller
• Telos 23 smaller
• Comparable size whenincluding SP code size

59
Results Trickle
60
Results Combining Network Protocols (mica2)

• Neither MR nor SD know about each other
• SPs message pool allows batching and power
  savings
• Overall power savings of 35extends node
  lifetime by over 54

61
Implications andConclusions
62
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?

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

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