Sensor Networks: Directed Diffusion and other proposals

1. Sensor Networks: Directed Diffusion and other proposals ECE 256

2. Sensor Networking – Why ?? • Data Collection – A basic need • Will the volcano erupt? Need temperature/gas signatures • Are poles melting due to GW? Need ocean current data • How many enemy tanks crossed through the jungle? • Did anyone enter my house while I was away? • Human monitoring possible/feasible ? • Not always • Why not a sensor + RF? Why need processor? • Too much data • In-networkdata distillation necessary

3. Sensor Networking -- Vision

4. San Fransisco’s Moscone Center equipped with sensor network

5. Sensor Hardware (Glimpse)

6. Sensor Nodes • Motivating factors for emergence • Applications • Moore’s Law in chips, MEMS • Advances in wireless technology • Challenges • Battery technology lagging • Canonical Sensor Node contains • Sensor(s) to convert a energy form to an electrical impulse • e.g., to measure temperature • Microprocessor • Communications link e.g., wireless • Power source e.g., battery

7. Laser diode III-V process Passive CCR comm. MEMS/polysilicon Analog I/O, DSP, Control COTS CMOS Sensor MEMS/bulk, surface, ... Power capacitor Multi-layer ceramic Solar cell CMOS or III-V Thick film battery Sol/gel V2O5 1-2 mm Example: Berkeley “Motes” or “Smart Dust”

8. Example Hardware • Size • Golem Dust: 11.7 cu. mm • MICA motes: Few inches • Everything on one chip: micro-everything • processor, transceiver, battery, sensors, memory, bus • MICA: 4 MHz, 40 Kbps, 4 KB SRAM / 512 KB Serial Flash, lasts 7 days at full blast on 2 x AA batteries

9. Examples • Spec, 3/03 • 4 KB RAM • 4 MHz clock • 19.2 Kbps, 40 feet • Supposedly $0.30 MICA: More recent (from xbow) Similar i-motes by Intel

10. Types of Sensors • Micro-sensors (MEMS, Materials, Circuits) • acceleration, vibration, gyroscope, tilt, magnetic, heat, motion, pressure, temp, light, moisture, humidity, barometric, sound • Chemical • CO, CO2, radon • Biological • pathogen detectors • Actuators too (mirrors, motors, smart surfaces, micro-robots)

11. Berkeley Family of Motes

12. Sensor Software (TinyOS Glimpse)

13. Programming TinyOS • Use a variant of C called NesC • NesC defines components • A component is either • A module • A module can be a Clock or LED … • Or an user-defined software module • Or a configuration • set of other components wired together • Specifying the unimplemented methods invocation mappings • Complete NesC application - one top level configuration

14. Steps in writing/installing your NesC app (applies to MICA Mote) • On your PC • Write NesC program • Compile to an executable for the mote • Plug the mote into the parallel port through a connector board • Install the program • On the mote • Turn the mote on, and it’s already running your application

15. Internal State Internal Tasks Commands Events TinyOS component model • Component specifies: • Component invocation is event driven • arising from hardware events • Static allocation avoids run-time overhead • Scheduling: dynamic • Explicit interfaces accommodate different applications

16. A Complete TinyOS Application sensing application application Routing Layer routing Messaging Layer messaging Radio Packet packet Radio byte Temp byte photo SW HW RFM ADC i2c bit clocks

17. Energy – a critical resource

18. Sensor-node Operating System • Size of code and run-time memory footprint • Embedded System OS’s inapplicable • Need hundreds of KB ROM • Workload characteristics • Continuous ? Bursty ? • Application diversity - Need toreuse sensor nodes • Energy consumption - Primary concern • Computation, Communication must be energy-aware

19. TinyOS: Summary Matches both • Hardware requirements • power conservation, size • Application requirements • diversity (through modularity), event-driven, real time

20. AdHoc and Sensors … • Ad Hoc network lacking killer applications • Difficult to force co-operation among HUMAN users • Mobility/connectivity unreliable for a business model • Difficult to bootstrap – critical mass required • Sensor networks more realizable • More defined applications • Single owner/administration – easier to implement • Sensing already an established process – just add networking to it.

21. However … • Ad Hoc and Sensor Networks are both multi-hop wireless architectures • Thereby shares several technical issues and challenges • Solutions in one domain often applicable to others. • However, key differences exist • Energy constraint in sensor networks • Traffic models and characteristics • Other issues like coverage, fault-tolerance, etc.

22. This Talk … • Directed Diffusion • Focusing on the shift from the ad hoc paradigm • The attention to energy conservation • Other routing proposals • SPIN, LEACH, Rumor Routing, etc. • SMAC • Energy-Aware Medium Access Control

23. Directed Diffusion

24. A region requires event-monitoring (harmful gas, vehicle motion, seismic vibration, temperature, etc.) Deploy sensors forming a distributed network On event, sensed and/or processed information delivered to the inquiring destination Directed Diffusion The Problem A sensor field Event Sensor sources Sensor sink

25. The Proposal • Proposes an application-aware paradigm to facilitate efficient aggregation, and delivery of sensed data to inquiring destination • Challenges: • Scalability • Energy efficiency • Robustness / Fault tolerance in outdoor areas • Efficient routing (multiple source destination pairs)

26. IP or not to IP • IP is the pivot of wired/wireless networks • All networking protocol over and below IP • Should we stick to this model? Comments ?

27. Directed Diffusion • Typical IP based networks • Requires unique host ID addressing • Application is end-to-end, routers unaware • Directed diffusion – uses publish/subscribe • Inquirer expresses an interest, I, using attribute values • Sensor sources that can service I, reply with data

28. Type = Wheeled vehicle // detect vehicle location Interval = 20 ms // send events every 20ms Duration = 10 s // Send for next 10 s Field = [x1, y1, x2, y2] // from sensors in this area Data Naming • Expressing an Interest • Using attribute-value pairs • E.g., • Other interest-expressing schemes possible • E.g., hierarchical (different problem)

29. Gradient Set Up • Inquirer (sink) broadcasts exploratory interest, i1 • Intended to discover routes between source and sink • Neighbors update interest-cache and forwards i1 • Gradient for i1set up to upstream neighbor • No source routes • Gradient – a weighted reverse link • Low gradient  Few packets per unit time needed

30. Low Low Low Exploratory Gradient Exploratory Request Gradient Event Bidirectional gradients established on all links through flooding

31. Event-data propagation • Event e1 occurs, matches i1 in sensor cache • e1 identified based on waveform pattern matching • Interest reply diffused down gradient (unicast) • Diffusion initially exploratory (low packet-rate) • Cache filters suppress previously seen data • Problem of bidirectional gradient avoided

32. Reinforced gradient Reinforced gradient Reinforcement • From exploratory gradients, reinforce optimal path for high-rate data download  Unicast • Byrequesting higher-rate-i1 on the optimal path • Exploratory gradients still exist – useful for faults Event A sensor field Sink

33. Path Failure / Recovery • Link failure detected by reduced rate, data loss • Choose next best link (i.e., compare links based on infrequent exploratory downloads) • Negatively reinforce lossy link • Either send i1 with base (exploratory) data rate • Or, allow neighbor’s cache to expire over time Link A-M lossy A reinforces B B reinforces C … D need not A (–) reinforces M M (–) reinforces D Event D M Src A C B Sink

34. Loop Elimination • M gets same data from both D and P, but P always delivers late due to looping • M negatively-reinforces (nr) P, P nr Q, Q nr M • Loop {M  Q  P} eliminated • Conservative nr useful for fault resilience P Q D M A

35. Simulation Setup & Metrics • ns2, 50 nodes in 160x160 sqm., range 40m • Node density maintained, 802.11 MAC • Random 5 sources in 70x70, random 5 sinks • Average Dissipated Energy • Per node energy dissipation / # events seen by sinks • Average Delay • Latency of event transmission to reception at sink • Distinct event delivery ratio • Ratio of # events sent to # events received by sink

36. Average Dissipated Energy In-network aggregation reduces DD redundancy • Flooding poor because of multiple paths from source to sink flooding Multicast Diffusion

37. Delay DD finds least delay paths, as OM – encouraging • Flooding incurs latency due to high MAC contention, collision flooding Diffusion Multicast

38. Event Delivery Ratio under node failures Delivery ratio degrades with higher % node failures • Graceful degradation indicates efficient negative reinforcement 0 % 10% 20%

39. Conclusion • Directed diffusion, a paradigm proposed for event monitoring sensor networks • Energy efficiency achievable • Diffusion mechanism resilient to fault tolerance • Conservative negative reinforcements proves useful • A careful MAC protocol, designed for such specifics, can yield further performance gains

40. Questions?

41. An Energy-Efficient MAC Protocol for Wireless Sensor Networks (S-MAC) Wei Ye, John Heidemann, Deborah Estrin

42. Major source of energy waste • Collision • Overhearing • Control Overhead • Idle Listening • Listening to possible traffic that is not sent • 50%-100% energy drain compared with receiving

43. Avenues to Reduce Energy Consumption (1) Periodic listen and sleep (2) Collision avoidance (3) Overhearing avoidance (4) Message passing

44. (1) Periodic Listen and Sleep • The main idea • Put nodes to sleep periodically • Called “Duty Cycles” • However, ensure that sleep/wake-up is synchronous

45. B Listen/Sleep Schedule Assignment Choosing Schedule (1) • Synchronizer • Listen for a mount of time • If hear no SYNC, select its own SYNC • Broadcasts its SYNC immediately Listen A Sleep Go to sleep after time t Listen for SYNC Broadcasts • Follower • Listen for a mount of time • Hear SYNC from A, follow A’s SYNC • Rebroadcasts SYNC after random delay td Listen Go to sleep after time t- td Sleep td Broadcasts

46. A Listen/Sleep Schedule Assignment Choosing Schedule (2) • B receives A’s schedule and rebroadcast it. • 2. Hear different SYNC from C • 3. Adapt both schedules Listen Sleep Go to sleep after time t1 Listen for SYNC Broadcasts Listen B Sleep td Broadcasts Only need to broadcast once Nodes only rarely adopt multiple schedules Listen C Sleep Go to sleep after time t2 Listen for SYNC

47. Keeping Clocks in SYNC • SYNC packets must not collide • Reserve separate time window for SYNC transmission

48. (2) Collision Avoidance • Identical to 802.11 • RTS/CTS • Virtual carrier sense (NAV) • Physical carrier sense

49. (3) Overhearing Avoidance Neighbors go to sleepon overhearing RTS/CTS • A is talking to B • D receives CTS from B -> sleep • D’s transmission will collide B’s • C receives RTS from A -> sleep • C cannot receive CTS/DATA from E • All immediate neighbours of transmitting node sleep • How long should they sleep? • C and D update their NAV • Keeping sleeping until NAV count down to zero

50. (4) Message Passing • How to transmit long message? • Transmitting one long message is inefficient • Many small packets with RTS/CTS/ACK for each • S-MAC: Divide into fragments, transmit in burst • RTS/CTS reserve medium for the entire sequence • Fragment-errors recovery with ACK • no control packets for fragments