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

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 ?? 802.15.4 B-MAC S-MAC PAMAS Telos MicaZ Mica2 Dot Mica

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 802.15.4 S-MAC PAMAS Telos MicaZ Mica2 Dot Mica

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

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

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

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

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

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

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

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

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

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

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

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

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,000 (85%) packets Duty cycle 75% higher without optimization Leaf Nodes

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)

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

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

SP Design, Implementation and Evaluation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, 802.15.4, etc

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

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

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

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

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

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

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

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)

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

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

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

Results: mica2 Throughput

Results: mica2 Throughput

Results: mica2 Throughput

Results: mica2 Throughput

Results: mica2 Throughput

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

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

Results: Trickle

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%

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?

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?

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

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

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