Exploring Energy-Efficient MAC Protocols for Wireless Sensor Networks and Mesh Networks
This lecture discusses various MAC protocols tailored for wireless sensor networks, focusing on energy efficiency and fairness. Key papers examined include "An Energy-Efficient MAC Protocol for Wireless Sensor Networks" and "The Case for Heterogeneous Wireless MACs." The talk covers the design and evaluation of new MAC protocols for long-distance 802.11 mesh networks, explores the unique requirements for sensor networks, and outlines solutions for prevalent issues like collisions and overhead reduction. The session includes a Q&A segment addressing students' inquiries.
Exploring Energy-Efficient MAC Protocols for Wireless Sensor Networks and Mesh Networks
E N D
Presentation Transcript
CS 15-849E: Wireless Networks (Spring 2006)MAC LayerDiscussion Leads:Abhijit Deshmukh Sai VinayakInstructor: Srinivasan Seshan
Papers “An Energy-Efficient MAC Protocol for Wireless Sensor Networks” Wei Ye, John Heidemann, Deborah Estrin “The Case for Heterogenous Wireless MACs” Chung-cheng Chen, Haiyun Luo “Design and Evaluation of a new MAC Protocol for Long-Distance 802.11 Mesh Networks” Wei Ye, John Heidemann, Deborah Estrin
Outline • Motivation • MAC – Wireless Sensor Networks • Heterogenous Wireless MACs • MAC for Mesh Networks • Take Aways • Similarities and Differences • Q & A
Motivation • Last Lecture • MACAW, Carrier Sense, Idle Sense • Basic Terms, Algorithms • Major Focus on Fairness • Very Generic • Special Requirements for • Sensor Networks • Heterogeneous • Mesh Networks
MAC for Sensor Networks • Sensor Networks • Sensors, Embedded processor, Radio, Battery • Ad hoc fashion • Proximity, short-range multi-hop communication • Committed to One or few applications • MAC Protocol • Energy Efficiency • Scalability • Accommodate network changes • Fairness, Latency, Throughput and Bandwidth
Sensor Networks • Sources of Energy Waste ? • Collision • Overhearing • Control packet overhead • Idle Listening • Tradeoff of fixing these • Reduction in per-hop fairness and latency. How? • Message Passing, Fragment long message • Why not a big concern in Sensor Networks? • Application-level performance
Related Work • PAMAS • Avoid overhearing among neighbors • Two independent radio channels • Suffers from idle listening • TDMA • Natural Savings • Scheduling • Static • Piconet • Periodic Sleep
Sensor-MAC Protocol Design • Periodic Listen and Sleep • Message Passing • Collision and Overhearing Avoidance
Periodic Listen and Sleep • Basic Scheme • Turn off Radio, set timer to wake up, sleep • Clock Drift • Sync using relative timestamps • Long listen period • Reduce Control Overhead • Sync with neighbors, exchange schedules • Advantage over TDMA ? • Looser Synchronization • Disadvantage? • Latency due to switching, RTS/CTS
Periodic Listen and Sleep • Choosing and Maintaining Schedules • Schedule Table • Synchronizer • Follower Rebroadcast SYNC Listen Wait (random) Wait (random)
Periodic Listen and Sleep • Maintaining Synchronization • SYNC packet • Listen Interval • SYNC + RTS
Collision & Overhearing Avoidance • Collision Avoidance • NAV • Virtual vs. Physical Carrier Sense • Overhearing Avoidance • Listening to all transmissions • Who all should sleep? • All neighbors of sender and receiver x x E C A B D F
Message Passing • Long vs. Short Message Length • Stream of Fragments, single RTS-CTS • Problem? • No Fairness • 802.11 Methodology? • Why send ACK after each fragment? • Prevent hidden terminal problem
Implementation • Rene Motes + Tiny OS • Simplified IEEE 802.11 • Message Passing (overhearing avoidance) • S-MAC (Message Passing + Periodic Sleep) • Topology used
Results • Low performance for high loads? • Synchronization overhead (SYNC packets) • Latency
Heterogeneous Wireless MACs • Basic Service Set (BSS) • Careful Channel Assignment • Wireless interference • Limited orthogonal channels
Motivation • Exposed Receiver – Hidden Sender CTS / RTS ? data data x Blocked S1 R1 ? ACK
4-way Handshake? • Hidden Receiver • Exposed Sender
Incomplete vs. Inconsistent • Channel status at sender • Incomplete estimate of receiver • Inconsistent at multiple competing senders • Incomplete channel status == high packet loss • Inconsistent channel status == unfair channel sharing
Intra-BSS Interference Mitigation • When to use 4-way handshake? • Client detecting data transmission vs. Client’s data transmission being detected • Access point to initiate channel access? • BSS in center • Less chance of interference from other BSS
Inter-BSS Interference Mitigation • RTR (Request to receive) • RTR-DATA vs. RTS-CTS-DATA • ACK in form of next RTR • Stateless Approach • Alternating between MAC protocols • Simple Design and Implementation • Low Channel Utilization
Fairness • Why is flow 23 getting unfair treatment? • Client 3 is exposed receiver • Receiver 1 is not interfered by 23 • How to solve it ? • Switch to receiver initiated protocol • Increase power levels of CTS/RTS
MAC for Long Dist. 802.11 Mesh • Motivation • Extend 802.11 for long haul • Challenges • Use off-the shelf hardware • Low cost
Overview • Basic Principle • SynRx & SynTx
Design and Implementation • Design decisions driven by • Low cost considerations • Usage of off-the-shelf 802.11 hardware • Achieving SynOp • Get rid of immediate ACKs • Get rid of carrier sense backoffs
Design and Implementation (contd.) Immediate Acks • Use IBSS mode of operation • Convert IP unicast to MAC broadcast • No ACKs for broadcast packets in IBSS mode • Broadcast = Unicast since link is 1-1 • ACKs can be implemented at the driver level Carrier Sensed Backoffs • Make use of feature provided by Intersil Prism chipsets
2P Operation on Single Link • Marker acts as a token • Loose Synchrony
2P Operation on Single Link (contd.) • Need to handle 2 scenarios • Temporary loss of synchrony (loss of marker) • Link recovery after failure • 2P handles both using timeouts • Advantages • Link-resync process is quick • CRC errors do not cause timeout (other than marker) …. Why ?
2P Operation on Single Link (contd.) • Two ends of a link get out of synchrony at the same time and timeout together …. So? • They would not hear each others marker packets since both SynTx coincides … So? • Repeated Timeouts … !!! Solution …? • Staggered timeouts Bumping
Topology Formation • What are the topologies in which 2P? • Bipartite ? • A tree is trivially bipartite • Bad in terms of fault tolerance • Add redundancy but turn on only one tree at a time (Morphing) • 3 Heuristics • Reduce length of links used • Avoid short angles between links • Reduce hop-count
Evaluation • Goal is threefold • Measure impact of step by step link establishment • Study effect of 2P in a large topology • Study performance of TCP over 2P • Link Establishment • 12.9 ms for first case (delay due to bumping) • 4.9 afterwards
Similarities and Differences Similarities • MAC protocol implementations • Extend 802.11 for a specific environment • Others? Differences • Deployment scenarios • Energy Saving, Long haul, Heterogeneity • Writing Style • Others?