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-network data distillation necessary

3
Sensor Networking -- Vision
4
San Fransiscos Moscone Center equipped with
sensor network
5

• Sensor Hardware
• (Glimpse)

6
Sensor Nodes

• Motivating factors for emergence
• Applications
• Moores 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
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 its already running your
  application

15
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
i2c
ADC
bit
clocks
17
Energy a critical resource
18
Sensor-node Operating System

• Size of code and run-time memory footprint
• Embedded System OSs inapplicable
• Need hundreds of KB ROM
• Workload characteristics
• Continuous ? Bursty ?
• Application diversity - Need to reuse 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
The Problem

• 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

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
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 i1 set up to upstream neighbor
• No source routes
• Gradient a weighted reverse link
• Low gradient ? Few packets per unit time needed

30
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
Reinforcement

• From exploratory gradients, reinforce optimal
  path for high-rate data download ? Unicast
• By requesting 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 neighbors 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
Sink
B
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

Q
P
A
D
M
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
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 As SYNC
• Rebroadcasts SYNC after random delay td

Listen
Sleep
Go to sleep after time t- td
td
Broadcasts
46
Listen/Sleep Schedule Assignment

• Choosing Schedule (2)

• B receives As 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 -gt sleep
• Ds transmission will collide Bs
• C receives RTS from A -gt 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

51
Acknowledgment to Pro. Jun Yang
Neighbors can sleep for whole message
52
Message Passing

• Advantages
• Energy saving
• Neighbors go to sleep when sense transmissions
• Reduces control overhead by sending multiple ACK
• Disadvantage
• Node-to-node fairness reduces
• However, message-level latency reduces

53
Experiment
Listen time 300ms Sleeping time 1s SYNC every
13s (10 listen/sleep period) A, B, C use the same
schedule
54
Energy save due to periodic sleep
802.11
Energy save due to avoiding overhearing by using
message passing
OA
SMAC
Heavy Traffic
Light Traffic
55
OA In light traffic status, nodes keep listening
for quite a long time
56
SYNC overhead
Overhearing avoidance still benefit
Heavy Traffic
Light Traffic
57

• Questions?

58

• Energy Efficient Routing in Ad Hoc Disaster
  Recovery Networks
• An Application Perspective

59
Motivation

• Disaster recovery emerging application for
  adhoc/sensor networks
• During Sep 11 attacks survivors were detected
  through mobile phone signals
• People often buried below earthquake disaster
• New RFID or smart badge technologies
• Each person wears a badge that is a transceiver
• Sends out very low rate signals about human
  location
• Information collected at peripheral central
  stations

60
Problem

• Given some pkt generation rate at each badge
• Design routing strategy that maximizes network
  lifetime
• Problem formulated as a LPP
• Maximize minimum lifetime
• subject to the flow constraints on each node
• Subject to the capacity constraints of the links

61
Approach

• Existing simplex techniques can be used to solve
  the problem
• Computation intensive due to several iterations
  for convergence
• Paper proposes binary search on network lifetime
• In plain words, a network lifetime (T) is chosen
  and applied to see if there exists a feasible
  flow assignment
• If not, (T/2) is tried, else (2T) until
  convergence

62
Summary

• Complexity of O(n3logT)
• n3 for finding a feasible assignment of flows
• Log T for the binary search
• However, distributed version of this protocol
• Only available for a single origin node
• For multiple badges ? future work

63
Other Research Challenges in Sensors

• Coverage
• Union of all sensing ranges need to cover entire
  region
• Time synchronization
• Data Aggregation
• Calculating functions over a spatial distribution
  of sensors
• Data Dissemination
• Rumour routing, Ant colonies, swarm intelligence
• Motion tracking, object guiding
• Sensors Actuators ? mobile robots !!!

64

• Questions?

65
Message Complexity
Grid topology N 25 n 5 Sources m 3
sinks Nodes talk with Adj. or diagonal nodes
Flooding Unrestricted broadcast Each interest
broadcast by each node ? nN messages A msg
received twice over a link ? total receptions
2n ( of links) Total msg. cost nN 4n(?N
1)(2?N 1) O( nN )
66
Message Complexity II
Omniscient Multicast Multicast trees rooted at
each source (Cost of tree establishment not
counted.) Overhead of 2 receptions on each link
of tree, Tj Total msg. cost 2 distinct links
l l ? Uj 1 to n (Tj) Expressing all trees in
terms of a common tree, T1, we get Message
Complexity O(n?N), asymptotically, and m ?N
Directed Diffusion Similar approach using rooted
trees Message Complexity O(n?N),
asymptotically, and m ?N But, cost lower than
OM, cause DD can perform duplicate suppression on
common link. More gain when more sources
67
TinyOS design point

• Bursty dataflow-driven computations
• Multiple data streams gt concurrency-intensive
• Real-time computations (hard and soft)
• Power conservation
• TinyOS
• Event-driven execution (reactive mote)
• Size
• Accommodate diverse set of applications (plug n
  play)