1 / 31

An Address-light, Integrated MAC and Routing Protocol for Sensor Networks

An Address-light, Integrated MAC and Routing Protocol for Sensor Networks. Catherine Rosenberg Purdue University. In collaboration with Sunil Kulkarni and Aravind Iyer. A Brief Overview of Sensor Networks. What? Application Specific Networks of wireless nodes Why?

Télécharger la présentation

An Address-light, Integrated MAC and Routing Protocol for 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.


Presentation Transcript

  1. An Address-light, Integrated MAC and Routing Protocol for Sensor Networks Catherine Rosenberg Purdue University In collaboration with Sunil Kulkarni and Aravind Iyer

  2. A Brief Overview of Sensor Networks • What? • Application Specific Networks of wireless nodes • Why? • Sense/monitor certain phenomena of interest and report to a “base station” (continuous monitoring versus event-triggered monitoring) • Where? • Military: Surveillance of sensitive areas, personnel monitoring, target detection, intrusion detection etc. • Civilian: Forest fire detection, habitat monitoring smart homes etc.

  3. A Brief Overview of Sensor Networks (contd.) Characteristics: Application-driven  no generic sensor networks • In general (but not always!) fairly inexpensive nodes with limited battery life and little computational capacity • A sensor network has an objective or a task. Nodes collaborate to achieve the objective • Sensing coverage • Communication capability: single hop versus multi-hop communication (trade-off between energy, H/W and S/W complexity) • Aggregation capability: very application specific • Node deployment versus node placement • Dense networks of nodes • Nodes are prone to failures

  4. Wireless node Base-station Salient Features • Usually very dense network • Possibly random deployment due to inaccessible terrain need of self-organizing capabilities • Mobility is typically low, but topology could be dynamic A Sensor Network (base-station at center) A Sensor Network (remote base-station)

  5. Wireless node Base-station Salient Features • Finite battery life: energy-efficiency is the prime issue • Many-to-one communication rather than many-to-many • Need to ensure sensing coverage of the area of interest, connectivity, and satisfy tolerance limits on latency Many-to-many data flow (Ad-hoc Network) Many-to-one data flow (Sensor Network)

  6. Design challenges • Energy efficient protocols for MAC, routing, and transport • Data fusion and clustering tradeoffs • Lifetime of a sensor network; For “how long” does the sensor network serve its purpose? • Dense networks  scalability of protocols is an important issue • No single BEST solution due to the application specific nature of the network

  7. Application Taxonomy • Broad spectrum of sensor network applications • Unique requirements for each application class • Application classes include • Event detection • Continuous monitoring • Sink-initiated data gathering • Object tracking • Hybrid of the above • Classification enables a focused design to cater to a particular application class

  8. Event Detection • Examples of applications • Intruder detection, Breach of security, Fire detection, etc. • Model of application class • Network inactive unless event detected • Events are rare (with some apriori frequency 1/T) • Only one node detects an event • Event reports are latency-constrained (delay < t) • Should contain some location information about event (beyond our scope)

  9. Goals, Results and Roadmap • Goal: To design MAC and routing protocols for sensor networks deployed for event detection • Results: • AIMRP: An integrated MAC and routing protocol • Optimized for event detection applications • Light-weight addressing; Power-efficient • Roadmap: • Related work • Contributions • How it works! • Issues • Power-saving mode • Performance

  10. Related Work • No previous work on MAC and routing specifically for event detection • S-MAC [1] based on IEEE 802.11 • TDMA, CDMA, FDMA or schedule-based MACs • More suited for data-gathering • Unsuitable for event-detection • Routing protocols • Adaptations of ad-hoc protocols (AODV, DSR) • Do not take into account many-to-one paradigm [1] W. Ye, J. Heidemann and D. Estrin, “An Energy-efficient MAC Protocol for Wireless Sensor Networks”, Proc. IEEE Infocom 2002.

  11. Contributions of AIMRP • First and only attempt at an integrated MAC and routing protocol for event detection using sensor networks • Addressing overhead is very minimal • order of few bits • Routing integrated with MAC (adapted from 802.11) • using any-cast querying • Power-saving mechanism • requires no coordination between nodes • consumes only ~25% of the power consumed by S-MAC

  12. Data plane Control Plane Forwarding Routing MAC Layer Unicast MAC Layer Broadcast Design Principles • Application-specific design • Energy efficiency • Many-to-one paradigm • Cross-layer interaction • Interaction between MAC and Routing layers • Integration of data plane and control plane Traditional layering in ad-hoc networks Routing and Forwarding MAC Layer Anycast Cross-layer interaction

  13. AIMRP: Overview • AIMRP – stands for Address-light, Integrated MAC and Routing Protocol • Two phases: • Configuration Phase – organize the network into tiers centered at the base-station • Active Phase – forward event reports across tiers towards the base-station, using hop-by-hop routing • Note: We will explain the working of AIMRP without the power-saving mode

  14. Message Type Source MAC-Id Source Tier-Id Optional Fields Message Type Source MAC-Id Source Tier-Id Destn MAC-Id Optional Fields AIMRP: Configuration Phase AIMRP: How it works! AIMRP: Active Phase RTR: anycastmsg R A CTR: unicast msg R L S aR 2aR DATAmsg ACKmsg

  15. AIMRP: Features • Addressing • Random ids per transmission attempt for MAC • Tier-ids for the purpose of routing • MAC mechanism • Based on IEEE 802.11 • RTR is an anycast message (like a “route request”) • CTR after backoff to avoid collision • Routing mechanism • Forwarding in the direction of decreasing tier rank • Hop-by-hop routing using anycast querying

  16. AIMRP: Features (contd.) • Deadlock resolution • Mechanisms borrowed from IEEE 802.11 • Guard time for carrier sense (DIFS) • RTR backoff • CTR, DATA, ACK timeouts • CTR backoff to reduce CTR collisions • Receiver node not predetermined • Due to routing being integrated with MAC • Random ids chosen afresh for each transmission • Reduce systematic collisions of nodes choosing same id

  17. AIMRP: Dimensioning parameters • Two parameters crucial • a: • Governs the width of each tier in AIMRP • Affects (along with l) number of available next-hop nodes • Tuning of a discussed later • l: • Average density of nodes in the network • Assume nodes are randomly and uniformly distributed • l has to guarantee connectivity under AIMRP [2] [2] S. Kulkarni, A. Iyer and C. Rosenberg, “Routing Dependent Node Density Requirements for Connectivity in Multi-hop Wireless Networks”, March 2004, Submitted for publication.

  18. AIMRP: Power-saving Mode • Need: To reduce energy wastage due to contention-based MAC • Principle: Nodes shut off their radio modules from time to time, when not communicating, in an uncoordinated fashion • Constraint: Nodes use multi-hop relaying to communicate to sink; so need to satisfy end-to-end latency constraint (t) • Note: Power-saving mode should not affect the operation of the protocol

  19. AIMRP: Power-saving Mode (contd.) • Working: • Each node goes to sleep from time to time for a random exponential time ts with mean s-1 • If a node sending an RTR does not get a reply, then it retries after a timeout • On expiry of sleep schedule, the node listens for time ton and sleep again unless it senses an event or receives data to be relayed • The value of s is chosen to satisfy the latency constraint (t) • Completely uncorrelated schedules, so no information exchange necessary

  20. AIMRP: Power-saving Mode (contd.) • How to dimension s: • t(k)sleep:the delay encountered in hop k (out of HA) due to next-hop nodes being asleep • It is assumed to be much larger than all the other delay components (packet transmission, back-offs, etc) • t: end-to-end tolerated delay; F: tolerance

  21. AIMRP: Power-saving Mode (contd.) • t(k)sleep: Exponentially distributed with mean 1/slA(a) where l is node density, A(a) is area of next-hop nodes, a is the tier parameter • Using t and F, s can be calculated from previous equation

  22. AIMRP: Energy Consumption Model • Model borrowed from [3]; representative of MIT mamps sensor nodes • Eup = Pontup – energy to bring radio transceiver up from sleep • Edw = Pontdw – energy to put radio to sleep • Pon – power consumed when radio is on • Ptr – additional power when radio is transmitting [3] Eugene Shih et. al., “Physical Layer Driven Algorithm and Protocol Design for Energy-efficient Sensor Networks”, Proceedings of MOBICOM 2001, Rome, Italy, 2001.

  23. AIMRP: Notation

  24. AIMRP: Performance • Average Power Consumption • Energy per event report • Energy per hop • Average number of hops

  25. AIMRP: Performance (contd.) • Table of values used for comparison (with a = 0.5) • Results • AIMRP: • S-MAC:

  26. AIMRP: Performance (contd.) • Is there an optimum value for a? • Pavg is a complicated function of a • Minimum (numerically calculated) around 0.4-0.5

  27. AIMRP: Performance (contd.) • Average power consumption versus various parameters: l, T and t • Independent of l; decreases with T and t

  28. Conclusions and Extensions • Simple model for event detection • Events equally likely in region of interest • Some apriori frequency • Protocol based on some assumptions • Only one node detects each event • Energy calculations based on assumption • Events are rare • No bursts of many events • Protocol would survive with perhaps a degraded performance

  29. Acknowledgements • This work was supported by a DARPA grant (contract no. MDA 972-02-1-0032) and an NSF grant (contract no. 0087266) • Thanks for listening!

  30. S-MAC: Salient features • Medium access mechanism based on 802.11 • Periodic sleep-wake cycles using virtual clusters • Signaling to form and maintain virtual clusters • Requires synchronization and contributes to overhead • Overhearing avoidance using in-channel signaling • Message passing to improve application-perceived latency of long data packets

  31. S-MAC: Performance • Similar analysis for S-MAC • Average Power Consumption • Energy per hop • Energy per event report

More Related