* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download SP: A Unifying Link Abstraction
Survey
Document related concepts
Backpressure routing wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Deep packet inspection wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Computer network wikipedia , lookup
Zero-configuration networking wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Network tap wikipedia , lookup
Serial digital interface wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Airborne Networking wikipedia , lookup
Internet protocol suite wikipedia , lookup
Communication protocol wikipedia , lookup
Transcript
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