Chapter05 Sensor Networks

1. Chapter05 Sensor Networks

2. 5.1 Introduction • What are sensor networks? • “Challenge of the century” • New paradigm for distributed computing! • Class • Student responsibilities • Vote for times: make-up; final presentation CS537S Sensor Networks

3. What are they? • Smart sensor = Micro-sensors + on-board processing + low-power wireless interfaces • All feasible at very small scale • Berkeley Smart Dust CS537S Sensor Networks

4. Mica Mote • Two Board Sandwich • CPU/Radio board • Sensor Board • Size • Mote: 11 in • Pocket PC: 5.23.1 in • CPU • Mote: 4 MHz, 8 bit • Pocket PC: 133 MHz, 32 bit • Memory • Mote: 4KB SRAM • Pocket PC: 32 MB RAM • Radio • Mote: 50 kbps • Bluetooth: 433.8 kbps; Wireless LAN: 10 Mbps CS537S Sensor Networks

5. Applications • Smart sensors massively distributed in environments for sensing and control • Enable spatially and temporally dense environmental monitoring • Embedded Networked Sensing will reveal previously unobservable phenomena Seismic Structure response Contaminant Transport Ecosystems, Biocomplexity Marine Microorganisms Modified from Deborah Estrin, SIGMETRICS keynote, http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt CS537S Sensor Networks

6. Acoustic Tracking Modified from Lui Sha et. al.,,MURI presentation Berkeley mote CS537S Sensor Networks

7. > 10 nodes/R Diameter: 100*R 100K nodes Large Scale • Number of nodes • Diameter of networks • Density Radio radius R  30 m Surveillance over 9 km2 CS537S Sensor Networks

8. Severe Resource Constraints • Bandwidth, CPU, memory, and storage • Energy • Batteries, solar cells • Long life time • Bird habitat monitoring: 9 months • Bridges: years • Need power management! CS537S Sensor Networks

9. Unpredictability • Wireless • Environmental noises • Terrain • High fault rates • Unknown and changing topologies Probability of receiving packets vs. distance 169 motes, 13x13 grid, 2 ft spacing, open area, RFM radio, simple CSMA Deborah Estrin, SIGMETRICS keynote, http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt CS537S Sensor Networks

10. Unpredictability When/where/how-many targets Mobile targets Sensors leave/join/move Berkeley mote CS537S Sensor Networks

11. Real-Time Requirements Timing constraints: locate/report targets within 30 sec Berkeley mote CS537S Sensor Networks

12. Security • Physically exposed to potential hackers • Wireless communication • Resource-constrained CS537S Sensor Networks

13. Sensor network is the “challenge of the century”! CS537S Sensor Networks

14. Aggregate performance >>> individual node • “Where are the targets in the south?” vs. • “What is the sound reading of sensor 191.12.1.0?” Berkeley mote CS537S Sensor Networks

15. New Computing Paradigms • Aggregate performance >>> individual node • Location-based queries • Nodes w/o global ID • Group coordination … … • Goal: reliable aggregate services on top of thousands of unreliable nodes CS537S Sensor Networks

16. Data-Centric Communication • Maximize information about physical events • NOT raw data throughput (as in traditional networks) • High redundancy in raw data • In-network data aggregation instead of sending everything to base stations CS537S Sensor Networks

17. Acoustic Tracking In-network aggregation send positions (not individual sound) • “Where are the targets in the south?” vs. • “What is the sound reading of sensor 191.12.1.0?” Berkeley mote CS537S Sensor Networks

18. Decentralized Control • Self-adaptation to handle unpredictabilities • Routing: avoid hot spots • Power management: optimal topology and lifetime • data caching/placement • Fault-tolerance • Scalability: cannot depend on global information • Decentralized control • Only depend on neighborhood information • Need to guarantee aggregate stability! CS537S Sensor Networks

19. 5.2 MAC

20. TDMA (bluetooth) Energy-efficient Less contention Allow nodes to sleep in others’ slots Less efficient in dynamic, multihop networks Centralized coordinator Schedule broadcasting among nodes CSMA Less energy efficient More contention, esp. in heavy load Robust in dynamic networks Naturally decentralized Less synchronization needed MAC CS537S Sensor Networks

21. Wireless LAN Packet size: 512 B Symmetric Power: not a concern Single hop: only between base station and nodes Random traffic Sensor Net Packet size: 30 B Asymmetric Power: dominant issue Multi-hop: “reversed multi-cast” topology Synchronized periodic traffic Characteristics CS537S Sensor Networks

22. More Assumptions • All traffic from nodes to base stations • No inter-sensor communication (aggregation) • All streams are equally important • No QoS (latency, rate) requirement • Rate can be regulated arbitrarily • Symmetric links CS537S Sensor Networks

23. MACAW/802.11 Single-hop fairness: even distribution of bandwidth Maximize single-cell throughput Berkeley MAC Multi-hop fairness: avoid starving far-away sensors Maximizeyield: multi-hop throughput per energy Goals CS537S Sensor Networks

24. MACAW/802.11 Single-hop fairness Separate backoff counter per receiver Overhearing: Copy backoff counters through overhearing Maximize throughput Based on CSMA/CA Sync packet transmission by adding overhead packets Berkeley MAC Multi-hop fairness Adaptive rate control on originated and route-thru traffic Give preference to route-thru traffic Maximize Yield Based on CSMA/CA Remove overhead packets Desynchronize periodic traffic via phase shifting Less overhearing: Sleep during backoff Approaches CS537S Sensor Networks

25. 802.11: CSMA/CA • Collision detection • Virtual collision • Hardware-sensed collision • Collision Avoidance (CA) • Channel idle  wait for rand()A • Contention • Collision (No CTS or No ACK) backoff-time = rand()2kS Acquire Channel Idle Time rand()A rand()[2kS]* Avoidance Contention Exponential Backoff Transmission CS537S Sensor Networks

26. Problems • Cannot handle synchrony • Repeat collision between synchronous traffic • Slightly early stream captures channel • Active listening during backoff CS537S Sensor Networks

27. Break Synchrony • Repeat collision between synchronous traffic • Slightly early stream captures channel Break the synchrony: • Random delay before listening: similar to CA • Phase shift at source sensor • The phase of sensor’s sampling interval is shifted by a random amount in response to transmission failure • Lead to “aperiodic” sensing CS537S Sensor Networks

28. 802.11/DCF: RTS/CTS/DATA/ACK RTS RTS CTS  defer send A B C D RTS, !CTS  OK to send • Problem: Cost of overhead packets when data are small • Control packet: 3 B, data packet: 30 B  30% overhead • Every control packet needs CSMA/CA CTS CTS A B C D DATA A B C D ACK A B C D CS537S Sensor Networks

29. The Inherent Hidden Terminal • The “unsolvable” by MACAW is common between a node (A) and its grandparent (C) Don’t know about CD To Base Station RTS DATA A B C D CS537S Sensor Networks

30. Remove RTS/CTS/ACK (1) • Take advantage of multi-hop pipeline overhead-free collision avoidance bw. grandparents and grandsons  • A overhears B transmit at t  C will transmit at t+ProcTime • A avoids transmitting until t+ProcTime+TxTime • But, A is overhearing (possibly in backoff) … To Base Station DATA DATA DATA A B C D t t+ProcTime +TxTime t-ProcTime -TxTime CS537S Sensor Networks

31. Remove RTS/CTS/ACK (2) • Remove ACK • Overhear parent relay your packet  implicit ACK  • But, depend on symmetry • But, A is overhearing (possibly in backoff) … • Collision reduced by • Phase offset • Random delay before listen • Adaptive Rate Control To Base Station DATA DATA DATA A B C D CS537S Sensor Networks

32. Adaptive Rate Control • Goals • Achieve multi-hop fairness: sensor net cannot scale if no remote sensors can report data to base station! • Avoid overload link toward base station • Rationale • Rate should be throttled when transmission fails to avoid overloading link and excessive collisions • Separate rate control applies to the packets originated from sensor itself and route-thru packets • Route-thru traffic should be given preference because they already consumed more bandwidth CS537S Sensor Networks

33. Adaptive Rate Control (ARC) • Given demanded rate S, the actual transmission rate is S*p (0 < p < 1) • Linear increase, multiplicative decrease • Successful transmission  p = p +  • Failed transmission  p = p*β (0 < β < 1) • : reward for successful transmission • β: penalty for failure • Tuning , β always a headache … CS537S Sensor Networks

34. Balance Originated and Route-thru traffic • Route-thru traffic given preference because • dropping them lead to more wasted bandwidth • traffic from far-away more vulnerable to dropping • Hence, • Route-thru has less penalty: βroute = 1.5βorigin • Route-thru increase faster: route = (n+1)origin where n is the number of children sending traffic • n really should be the number of sending descendants • More tuning to do … CS537S Sensor Networks

35. Evaluation Setup • Error-free simulation and rene-mote implementation • Implementation: always listening when not sending • Single-cell and multi-hop CS537S Sensor Networks

36. Key Evaluation Results: Single Hop • CSMA • Random delay before listening key to robustness • Backoff mechanism is irrelevant  random backoff is sufficient • Sleep during backoff key to energy saving • Single-hop fairness • 802.11: slightly early sender capture whole channel • Application-level phase shifting significantly improve single-hop fairness CS537S Sensor Networks

37. Key Evaluation Results: Multi Hop • Multi-hop fairness: data delivered to base station • CSMA: • remote sensors starve • sensors close to base station dominate • ARC • remote sensors not starved • fairer, but not entirely • improved yield for remote sensors, but still not as high as close sensors CS537S Sensor Networks

38. Critiques • Break synchrony among traffic • Random delay before listening: similar to CA • Phase shift at source sensor • Remove RTS/CTS/ACK by taking advantage of multi-hop pipelining • Collision avoidance bw. grandparents and grandsons through overhearing • Implicit ACK by overhearing parent • Depends on overhearing • Heavily depend on symmetric links CS537S Sensor Networks

39. More Critiques • Adaptive Rate Control • Rate throttled when transmission fails to avoid overloading link • Separate rate control applies to the packets originated from sensor itself and route-thru packets • Route-thru traffic given preference to improve fairness • Localized algorithm • Difficult tuning • Assume No inter-sensor communication (aggregation) • All streams are equally important • No QoS (latency, rate) requirement • Rate can be regulated arbitrarily CS537S Sensor Networks

40. An Energy-Efficient MAC Protocol for Wireless Sensor Networks CS537S Sensor Networks

41. Outline • What is S-MAC ? • Requirements (Specific to Sensor Networks) • Goals of S-MAC • Techniques & Implementation • Experiments • Limitations • Future Plans CS537S Sensor Networks

42. S-MAC • A MAC (Medium Access Control) protocol for wireless sensor networks • Different from traditional wireless MACs (e.g. IEEE 802.11) • Energy conservation and self configuration of primary importance • Inspired by PAMAS (based on MACA but uses a separate signalling channel), but uses in-channel signalling • Applies messagepassing for applications requiring data store & forward CS537S Sensor Networks

43. Requirements • Energy Efficiency - reduced power consumption for prolonged life of the nodes (Battery-powered nodes energy efficiency ) • Scalability - to easily accommodate network changes ( changes in network size, node density and topology) self-organization) • Collision Avoidance • Throughput • Bandwidth utilization • Latency • Fairness CS537S Sensor Networks

44. Assumptions • Most of the communication between peers and not with the base station • Requirement for self configuration • Sensor networks are dedicated to a single application or a few collaborative applications • Applications have long idle periods and can tolerate some latency • Requirement for in-network data processing CS537S Sensor Networks

45. S-MAC Goals • Primary - Achieve energy efficiency • Bonus - capable of good scalability and collision avoidance • Secondary - Throughput and bandwidth utilization • Cost - may lead to reduced per-hop fairness and latency CS537S Sensor Networks

46. Dominant in sensornets Sources of Energy Waste • Collision - due to follow-on transmissions on collisions • Overhearing - node picks up packets meant for another destination • Control Packet Overhead • Idle listening - listening to receive possible traffic that is not sent (consumes 50%- 100% of energy spent for receiving) CS537S Sensor Networks

47. Minimize Energy Waste -Ways and Means • Avoid collisions - uses CSMA/CA (basic 802.11) • Avoid overhearing - puts a node to sleep when the neighbouring nodes are transmitting • Control overhead - Applies message passing • Avoid idle listening - periodic listen and sleep CS537S Sensor Networks

48. Periodic Sleep and Listen • Every node sleeps periodically (radio switch-off) • Sets a timer to awake itself after the designated sleep time • Sleep time can be application specific • Periodic sleep time same for all the nodes • Latency increased - latency requirement places a limit on the sleep time of the nodes Listen Sleep Listen Sleep CS537S Sensor Networks

49. Schedule 1 Schedule 2 B C D A Periodic Sleep and Listen • Nodes free to choose listen/sleep schedules • Neighbouring nodes preferred to have same schedules • Nodes exchange their schedules by broadcasting them to their immediate neighbours • Nodes maintain a schedule table to store the schedules of their neighbours CS537S Sensor Networks

50. Sync Sync A B C Periodic Sleep and Listen - contd. • Choosing Schedules • Node listens for a certain amount of time. If it does not receive any other schedule, randomly chooses a sleep time, broadcasts it in a SYNC message - synchronizer • If a node receives a schedule, it sets it schedule to be the same and broadcasts that in a SYNC message - follower • If a node receives a schedule after it has broadcasted its schedule, it adopts this second schedule too and wakes up at both the schedules. sleep after t secs sleep after (t - td)secs CS537S Sensor Networks Node Sleep time Synchronization