1 / 63

A Unifying Abstraction for Wireless Sensor Networks

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

mareo
Download Presentation

A Unifying Abstraction for Wireless Sensor Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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

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

  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. 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 Challenge Application & Services Scheduling Fragmentation Routing Organization Linkprotocol Radio hardware

  12. 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. 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 wakeup wakeup wakeup wakeup wakeup wakeup wakeup wakeup wakeup B-MAC Primitives:Low Power Listening (LPL) TX [preamble] sleep sleep sleep packet Node 1 time RX sleep sleep sleep Node 2 packet time

  14. 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 B-MAC Primitives: Interfaces Radio Independent Radio Dependent

  15. 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 B-MAC:Uses of a flexible MAC protocol S-MAC off LPL CCA ACK off on on off 2 3 5 8 10 1 4 6 7 9 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

  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. 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 Surge ApplicationNetwork power consumption of a factored link protocol Forwarded <10,000 packets 1 hop from base station • Forwarded ~35,000 (85%) packets • Duty cycle 75% higher • without optimization Leaf Nodes

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

  20. 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 Tradeoffs: Latency for EnergyFactored vs Traditional Protocol 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 1.1.3 (January 7, 2004) • Default MAC protocol in use for 10 months

  22. SPDesign, Implementation and Evaluation

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

  24. Traditional Opaque Layering MessageReception MessageTransmission SP Data Data MessageReception MessageTransmission

  25. Translucent Layering in SP Link AbstractedParameters MessageReception MessageTransmission Link AbstractedFeedback SP Data Control Data Feedback Link SpecificParameters Link Specific Feedback MessageReception MessageTransmission

  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 Receive • Message arrives from link • SP dispatches • Network protocols establish • naming/addressing • filtering SP

  28. Msg Pool Message Transmission Send Receive • 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

  29. Neighbor Table Msg Pool Neighbor Management Neighbors Send Receive • 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

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

  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. Expressive Multiple priority levels Explicit reliability Exact latency times Simplified Single bit priority Reliability on or off Urgent or not Design Space for SP 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. 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 Msg Pool SP Message Futures Network Protocol SP Message packets 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

  35. Msg Pool Neighbor Table Neighbor Table Message Pool sp_message_t Neighbor Required Link Network 1 destinationmessage quantity urgent reliability phase 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

  36. 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 TinyOS Implementation of SP

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

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

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

  42. Using SP with 802.15.4 send done beaconTX packet received wake forbeacon period SP 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? Update schedule send donereliability set TXdone Stopradio packet RX SP

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

  44. Msg Pool Neighbor Table MintRoute Send Receive Intercept SP Message forwarding queue ChooseParent SendRoute Beacons UpdateNeighbor ETX MintRoute 1st packet MultiHop Neighbors MultiHop Engine Next PacketHandler Send Receive Send Neighbors Receive SP 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. Msg Pool Neighbor Table Synopsis Diffusion • Sends “synopses” towards a collection point • Needs a gradient to know which way to aggregate Synopsis Diffusion Simple Implementation Node Address Gradient Manager Send Neighbors Receive SP Neighbor Functions Message Dispatch Link Estimator Link Protocol

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

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

  49. Results: mica2 Throughput

  50. Results: mica2 Throughput

More Related