an address light integrated mac and routing protocol for sensor networks n.
Skip this Video
Loading SlideShow in 5 Seconds..
An Address-light, Integrated MAC and Routing Protocol for Sensor Networks PowerPoint Presentation
Download Presentation
An Address-light, Integrated MAC and Routing Protocol for Sensor Networks

Loading in 2 Seconds...

play fullscreen
1 / 31
Download Presentation

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

Download Presentation

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
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