Chapter05 Sensor Networks
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
8/30/2002
CS537S Sensor Networks
2
What are they?
• Smart sensor = Micro-sensors + on-board processing +
low-power wireless interfaces
– All feasible at very small scale
• Berkeley Smart Dust
8/30/2002
CS537S Sensor Networks
3
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
8/30/2002
CS537S Sensor Networks
4
Applications
Seismic Structure
response
Marine
Microorganisms
• 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
Contaminant
Transport
Ecosystems,
Biocomplexity
Modified from Deborah Estrin, SIGMETRICS keynote,
http://lecs.cs.ucla.edu/~estrin/talks/Sigmetrics-June02.ppt
8/30/2002
CS537S Sensor Networks
5
Acoustic Tracking
Modified from Lui Sha et. al.,,MURI presentation
Berkeley mote
8/30/2002
CS537S Sensor Networks
6
Large Scale
• Number of nodes
• Diameter of networks
• Density
> 10 nodes/R
Radio radius R  30 m
Surveillance over 9 km2 
8/30/2002
Diameter: 100*R
100K nodes
CS537S Sensor Networks
7
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!
8/30/2002
CS537S Sensor Networks
8
Unpredictability
• Wireless
–
–
–
–
Probability of receiving packets vs. distance
Environmental noises
Terrain
High fault rates
Unknown and changing
topologies
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
8/30/2002
CS537S Sensor Networks
9
Unpredictability
When/where/how-many targets
Mobile targets
Sensors leave/join/move
8/30/2002
CS537S Sensor Networks
Berkeley mote
10
Real-Time Requirements
Timing constraints:
locate/report targets
within 30 sec
8/30/2002
Berkeley mote
CS537S Sensor Networks
11
Security
• Physically exposed to potential hackers
• Wireless communication
• Resource-constrained
8/30/2002
CS537S Sensor Networks
12
Sensor network is the
“challenge of the century”!
8/30/2002
CS537S Sensor Networks
13
Aggregate performance >>> individual node
“Where are the targets in the south?”
vs.
“What is the sound reading of sensor
191.12.1.0?”
8/30/2002
CS537S Sensor Networks
Berkeley mote
14
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
8/30/2002
CS537S Sensor Networks
15
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
8/30/2002
CS537S Sensor Networks
16
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?”
8/30/2002
CS537S Sensor Networks
Berkeley mote
17
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!
8/30/2002
CS537S Sensor Networks
18
5.2 MAC
MAC
TDMA (bluetooth)
• Energy-efficient
CSMA
• Less energy efficient
– Less contention
– Allow nodes to sleep in
others’ slots
• Less efficient in dynamic,
multihop networks
– Centralized coordinator
– Schedule broadcasting
among nodes
8/30/2002
– More contention, esp. in
heavy load
• Robust in dynamic
networks
– Naturally decentralized
– Less synchronization
needed
CS537S Sensor Networks
20
Characteristics
Wireless LAN
• Packet size: 512 B
• Symmetric
• Power: not a concern
• Single hop: only
between base station
and nodes
• Random traffic
8/30/2002
Sensor Net
• Packet size: 30 B
• Asymmetric
• Power: dominant issue
• Multi-hop: “reversed
multi-cast” topology
• Synchronized periodic
traffic
CS537S Sensor Networks
21
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
8/30/2002
CS537S Sensor Networks
22
Goals
MACAW/802.11
• Single-hop fairness: even
distribution of bandwidth
• Maximize single-cell
throughput
8/30/2002
Berkeley MAC
• Multi-hop fairness: avoid
starving far-away sensors
• Maximize yield: multi-hop
throughput per energy
CS537S Sensor Networks
23
Approaches
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
8/30/2002
Berkeley MAC
• Multi-hop fairness
– Adaptive rate control on
originated and route-thru
traffic
– Give preference to routethru traffic
• Maximize Yield
– Based on CSMA/CA
– Remove overhead packets
– Desynchronize periodic
traffic via phase shifting
– Less overhearing: Sleep
during backoff
CS537S Sensor Networks
24
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
rand()A
Avoidance
8/30/2002
rand()[2kS]*
Contention
Exponential Backoff
CS537S Sensor Networks
Time
Transmission
25
Problems

Cannot handle synchrony

Repeat collision between synchronous traffic
 Slightly early stream captures channel

Active listening during backoff
8/30/2002
CS537S Sensor Networks
26
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
8/30/2002
CS537S Sensor Networks
27
802.11/DCF: RTS/CTS/DATA/ACK
RTS, !
CTS

OK to
send
A
RTS
RTS
B
C
CTS
A
A
A
B
B
B
C
DATA
ACK
D
CTS
CTS 
defer
send
D
C
D
C
D
• 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
8/30/2002
CS537S Sensor Networks
28
The Inherent Hidden Terminal

The “unsolvable” by MACAW is common
between a node (A) and its grandparent (C)
Don’t know about CD
A
8/30/2002
RTS
B
C
DATA
CS537S Sensor Networks
D
To Base Station
29
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) …
A
DATA
t-ProcTime
-TxTime
8/30/2002
B
DATA
t
C
DATA
t+ProcTime
+TxTime
CS537S Sensor Networks
D
To Base Station
30
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
A
8/30/2002
DATA
B
DATA
C
DATA
CS537S Sensor Networks
D
To Base Station
31
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
8/30/2002
CS537S Sensor Networks
32
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 …
8/30/2002
CS537S Sensor Networks
33
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 …
8/30/2002
CS537S Sensor Networks
34
Evaluation Setup
• Error-free simulation and
rene-mote
implementation
 Implementation: always
listening when not sending
• Single-cell and multi-hop
8/30/2002
CS537S Sensor Networks
35
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
8/30/2002
CS537S Sensor Networks
36
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
8/30/2002
CS537S Sensor Networks
37
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 multihop pipelining
 Collision avoidance bw. grandparents and grandsons
through overhearing
 Implicit ACK by overhearing parent
 Depends on overhearing
 Heavily depend on symmetric links
8/30/2002
CS537S Sensor Networks
38
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
8/30/2002
CS537S Sensor Networks
39
An Energy-Efficient MAC Protocol for
Wireless Sensor Networks
8/30/2002
CS537S Sensor Networks
40
Outline
•
•
•
•
•
•
•
What is S-MAC ?
Requirements (Specific to Sensor Networks)
Goals of S-MAC
Techniques & Implementation
Experiments
Limitations
Future Plans
8/30/2002
CS537S Sensor Networks
41
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 message passing for applications requiring data store &
forward
8/30/2002
CS537S Sensor Networks
42
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
8/30/2002
CS537S Sensor Networks
43
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
8/30/2002
CS537S Sensor Networks
44
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
8/30/2002
CS537S Sensor Networks
45
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)
Dominant in sensor nets
8/30/2002
CS537S Sensor Networks
46
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
8/30/2002
CS537S Sensor Networks
47
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
8/30/2002
Sleep
Listen
Sleep
CS537S Sensor Networks
48
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 Schedule
of their 1neighbours Schedule 2
A
8/30/2002
B
C
CS537S Sensor Networks
D
49
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 thesleep
schedules.
after t secs
sleep after (t - td)secs
8/30/2002
Sync
Sync
A
B
CS537S Sensor Networks
Node Sleep time Synchronization
C
50
Periodic Sleep and Listen - contd.
• Cases of bordering nodes between schedules
• Bordering nodes may follow multiple schedules
• Consume higher energy due to higher awake time
Schedule 1
Schedule 2
8/30/2002
CS537S Sensor Networks
Border nodes:
two schedules
broadcast twice
51
Periodic sleep and listen - contd.
Schedule Synchronization
• Remember neighbours’ schedules
• Each node broadcasts its schedule every few
periods of sleeping and listening
• Uses a SYNC packet which has the address and
the time of it’s next sleep
• Re-sync when receiving a schedule update
• Schedule packets also serve as beacons for new
nodes to join a neighborhood
8/30/2002
CS537S Sensor Networks
52
Periodic sleep and listen - contd.
• Listen period divided into two parts to receive SYNC and Data
packets
• Each slot further divided for CS
Listen
Receiver
For SYNC
For RTS
SYNC
Sleep
RTS
Sender
CS
8/30/2002
CS
Send Data if RTS is Received ..
CS537S Sensor Networks
53
Collision Avoidance
• Multiple senders want to talk
• Options - Contention vs. TDMA
• Solution: Similar to IEEE 802.11 ad hoc mode
– Virtual Carrier Sense : A node records the value of the
transmission period from each transmitted packet into a NAV
(Network Allocation Vector) and sets a timer for it. Every time
the timer fires, the NAV is decremented and data can be
transmitted only when NAV = 0
– Physical carrier sense : When the receiver starts listening,
the sender starts carrier sense and randomly selects a time
slot to finish carrier sense. If no transmission is detected in
that period, it gets the medium to start the transmission
8/30/2002
CS537S Sensor Networks
54
Collision Avoidance - contd.
– Randomized backoff time
– RTS/CTS for hidden terminal problem
Node A
RTS
Node B
CTS
Node C
CTS
– RTS/CTS/DATA/ACK sequence
8/30/2002
CS537S Sensor Networks
55
Overhearing Avoidance
• Overhearing - Receive packets destined to others
• Sleep when neighbors talk/transmit data
• All immediate neighbors of sender and receiver should
sleep
E
C
A
B
D
F
• The duration field in each packet informs other nodes
the sleep interval
8/30/2002
CS537S Sensor Networks
56
Message Passing
• Sensor net in-network processing requires entire
message
• One long message - higher cost ofor re-transmitting
on corruption
• Fragmented message - higher control overhead due
to RTS and CTS for each packet and longer delay
too
• S-MAC approach
8/30/2002
CS537S Sensor Networks
57
Message Passing
• Different messages are not interleaved
– Long message is fragmented & sent in burst
– RTS/CTS reserve medium for entire message
– Fragment-level error recovery — ACK
— extend Tx time and re-transmit immediately
— also meant to avoid the hidden terminal problem
• Other nodes sleep for whole message time
• Each data and ACK packet has duration field in it
• Stresses on application level fairness and lesser latency for entire
message
• No limit on extensions on failure - What if the node is dead ?
8/30/2002
CS537S Sensor Networks
58
Message Passing
• Medium Reservation
Message
Listens &
sleeps for the
reserved Time
F1 | F2 | F3 | …………..|Fn
My address
Reserved Time = t(f2+f3+…fn) + t_ack(f1+f2+…fn)+t_ack
Ack
F1
C
A
B
D
Wakes up,
gets the time
reservation and
goes back to sleep
8/30/2002
CS537S Sensor Networks
Hidden Terminal
59
S-MAC Vs 802.11 Fragmentation
S-MAC Fragmentation
– RTS and CTS reserve the
medium for entire msg
duration + Acks
– Neighbouring nodes’
transmission period
awareness extended to one
message transmission
period
– If ACK not received,
extends Tx time and retransmits
– Promotes per-message
fairness
8/30/2002
IEEE 802.11 Fragmentation
– RTS and CTS reserve the
medium only for one data
fragment and ACK
– Neighbouring nodes’
transmission period
awareness limited to one data
transmission period
– If ACK not received, needs to
re-contend for the medium
– Promotes per-node fairness
CS537S Sensor Networks
60
Implementation on Testbed Nodes
• Platform
• Motes (UC Berkeley)
• 8-bit CPU at 4MHz,
• 8KB flash, 512B RAM
• 916MHz radio
• TinyOS: event-driven
8/30/2002
CS537S Sensor Networks
61
Implementation on Testbed Nodes
• Compared MAC modules
• IEEE 802.11-like protocol w/o sleeping - radio is either
in listen/receive mode or transmit mode
• Message passing with overhearing avoidance - does
not include periodic listen and sleep mode
• S-MAC (2 + periodic listen/sleep)
8/30/2002
CS537S Sensor Networks
62
Experiments
•
•
•
•
Topology and measured energy consumption on source nodes
Each source node sends 10 messages each in 10 fragments
Messages sent at varying time-interval
Energy consumed
= Ttransmit* Powertransmit+ Treceive* Powerreceive+Tlisten* Powerlisten
A
Source 1
Source 2
B
8/30/2002
C
E
Sink 1
Sink 2
D
CS537S Sensor Networks
63
Experiments
Results for energy consumption
8/30/2002
CS537S Sensor Networks
64
Experiments
Average energy consumption in the source nodes
1800
802.11-like protocol
Overhearing avoidance
S-MAC
Energy consumption (mJ)
1600
1400
1200
1000
800
600
400
200
0
2
4
6
8
10
Message inter-arrival period (second)
8/30/2002
CS537S Sensor Networks
65
Experiments - contd.
Percentage Sleep Time
• Overhearing
avoidance sleep mode
time reduces as the inter
arrival period of the
messages increases
• S-MAC tries to
maintain the sleep mode
time
8/30/2002
CS537S Sensor Networks
66
Experiments - contd.
• In heavy traffic S-MAC
seems to consume more
power than 802.11 due to
overhead of SYNC
transmissions/receptions
• Also it introduces more
latency and uses more
time to pass the same
amount of data
Measured
8/30/2002
Energy consumption
in the
intermediate
CS537S
Sensor
Networks node
67
Conclusions
• S-MAC offers significant energy efficiency over alwayslistening MAC protocols
• The periodic sleep/listen scheme does not benefit for
heavy loads
• Reduced duty cycle
Fairness
Packet Level
Latency
8/30/2002
Energy
Msg-level latency
Energy
CS537S Sensor Networks
68
Future Plans
• Measurement of throughput and latency
• Experiments on large testbeds with differing
system complexity
• ~100 Motes, ~30 embedded PCs w/ MoteNIC
8/30/2002
CS537S Sensor Networks
69
URLs of Interest
• S-MAC: http://www.isi.edu/scadds/
• PAMAS http://citeseer.nj.nec.com/cache/papers/cs/23136/http:zS
zzSzpacman.usc.eduzSzpamas.pdf/pamas-poweraware-multi.pdf
8/30/2002
CS537S Sensor Networks
70
5.3 Location
5.3.1 Static Location
Services
What is location data?
• It can be divided into three basic
categories:
• Absolute Physical (20”N by 15”W) technically a special case of relative
physical (relative to the earth)
• Relative Physical (50m north of cupples II)
• (3D vs. 2D)
• Symbolic (in the basement)
8/30/2002
CS537S Sensor Networks
73
Which types are useful for sensor nets?
• Relative Physical is the most useful (all sensors
relative to a fixed point, or all sensor relative to
their neighbors), and is assumed by practically
all sensor-nets apps, and many protocols
• Symbolic can be useful for data-centric
communication, and context-dependent
behavior: e.g., “Give me acoustic reading for all
nodes in bird’s nests”
• Absolute Physical is useful as a special case of
Relative Physical, for the same purpose(s)
8/30/2002
CS537S Sensor Networks
74
Where does location data come
from in sensor nets?
• Any of the types can be hard-wired (e.g.,
Great Duck island)
• Specialized hardware (e.g., GPS) can provide
absolute/relative physical
• Interactions between nodes can provide
relative physical (e.g., “Organizing a Global
Coordinate System from Local Information on
an Amorphous Computer”) and symbolic
(who are neighbors?)
• Visual/Aural/etc.. sensor readings can provide
8/30/2002
Sensor Networks
relative physicalCS537S
and/or
symbolic (e.g., “I hear 75
Which are practical?
Hard-coding is impractical for most apps
Specialized hardware is too
expensive/big/power-hungry, or limited to rigid
architectures: super-motes/base stations can
solve this to some extent
Neighbor-based algorithms are feasible...
Vision/sound are computationally expensive
and inaccurate in most cases (although they
may be useful in application-specific contexts)
8/30/2002
CS537S Sensor Networks
76
Practical Localization for Sensor
Nets
• Nirupama Bulusu, John Heidemann, and Deborah Estrin. GPS-less
low cost outdoor localization for very small devices. IEEE
Personal Communications, 7(5):28-34, October 2000. Special Issue
on Smart Spaces and Environments.
• Lance Doherty, Kristofer S. J. Pister, and Laurent El Ghaoui.
Convex position estimation in wireless sensor networks. In
Proceedings of IEEE Infocom 2001, volume 3, pages 1655-1663.
IEEE, IEEE Computer Society Press, April 2001.
• Radihika Nagpal, Organizing a Global Coordinate System from
Local Information on an Amorphous Computer. MIT AI Memo
1666, August 1999.
8/30/2002
CS537S Sensor Networks
77
GPS-less low cost outdoor localization
for very small devices
• Putting a GPS on every mote is
impractical:
• Size
• Power
• Cost
• How can we get around this while still
taking advantage of GPS?
8/30/2002
CS537S Sensor Networks
78
The Algorithm
A regular grid of reference points sends out beacon signals
at fixed intervals. Nodes listen for beacons for a fixed
period of time, and then decide on location.
8/30/2002
CS537S Sensor Networks
79
Pros
Cons
Connectivity-based Designed using an
approach (i.e., only idealized radio model
local interaction)
with perfect spherical
radio propagation
Accuracy can be
Assumes a regular grid
fine-tuned for
of nodes with known
application needs
locations to serve as
by changing the
reference points,
density of the grid covering the entire
network
8/30/2002
CS537S Sensor Networks
80
Convex position estimation in wireless
sensor networks
• Unlike the previous paper, no fixed grid (e.g.,
motes may be dropped from an airplane)
• “[assume that] only a few nodes have known
positions (perhaps equipped with GPS or
placed deliberately)”
• Remaining node positions are computed from
knowledge about communication links.
8/30/2002
CS537S Sensor Networks
81
The Algorithm
All nodes beacon to find out neighbors
Neighbors, along with known node positions, define a
(possibly under-constrained) constraint-satisfaction problem,
which can be solved to obtain approximate node locations
8/30/2002
CS537S Sensor Networks
82
Pros
Only a few nodes
locations are
needed
Cons
Designed using an
idealized radio model
with perfect spherical
radio propagation
Those nodes whose Non-local computation!
locations are
Assumes the all
known can be
constraints are
randomly scattered forwarded to a central
PC, which computes all
node locations, and
forwards the information
backNetworks
to the nodes
8/30/2002
CS537S Sensor
83
Organizing a Global Coordinate System
from Local Information on an Amorphous
Computer
• A “biologically inspired” algorithm
• Uses the “amorphous computing” model,
which is similar to sensor nets, but with an
important difference:
a fixed communication radius r is assumed
for all nodes, and communication is
assumed to be 100% reliable
8/30/2002
CS537S Sensor Networks
84
Biologically Inspired Computation
Ant Colony System used to solve TSP
and other optimization problems
Localization algorithm
based on the way
embryos differentiate
8/30/2002
Artificial Neural
Nets can be
“trained” to play
games, drive,
recognize text,
etc...
CS537S Sensor Networks
85
The Algorithm
Three anchor processors are chosen, as far apart from each
other as possible.
Anchors send beacons are sent with count=0, which are
flooded through the network, incrementing count at each step.
The lowest valued beacon a node receives from a given
anchor is its distance from that anchor, and triangulation gives
location.
When computing the distance, accuracy can be improved by
“smoothing” (averaging with neighboring values):
8/30/2002
Why -0.5? Because neighbors are
on average r/2 further away from
the source
CS537S Sensor
Networks (in an idealized scenario)
86
8/30/2002
CS537S Sensor Networks
87
Pros
Cons
Only a few nodes
locations are
needed
Designed using an
idealized radio model
with perfect spherical
radio propagation
Those nodes whose
locations are
How critical will this be
known can be
in determining realrandomly scattered world performance?
Entirely localized
algorithm
8/30/2002
CS537S Sensor Networks
88
More on Radio Transmission
• It should be possible to eliminate long links
by using a MAC protocol
• Effects of non-circular radii will be
averaged out over long distances
• Voids present a problem...
8/30/2002
CS537S Sensor Networks
89
Anchor 1
Node
VOID
Voids are problematic, since
nodes on the other side will
receive inaccurately high counts.
No simple solution...
8/30/2002
CS537S Sensor Networks
Anchor 2
90
5.3.2 RAP
Outline
• I-EDF vs SPEED vs RAP
• RAP: Real-time locAtion-based Protocols
– Architecture and API’s
– Velocity Monotonic Scheduling
• Evaluation Results
8/30/2002
CS537S Sensor Networks
92
I-EDF vs. SPEED vs. RAP
•
Hard real-time
–
•
•
•
•
•
•
•
•
8/30/2002
•
•
•
•
•
•
CS537S Sensor Networks
•
•
No guarantees
Ad hoc deployment
Dynamic traffic
Homogeneous platform
–
Implemented on motes
Routing, MAC rate control
No prioritization
Soft real-time
–
No guarantees
Ad hoc deployment
Dynamic traffic
Homogeneous platform
–
Sophisticated router node
MAC scheduling
Prioritization (EDF/RR)
Soft real-time
–
Absolute guarantee
Engineered network
Static traffic
Heterogeneous platform
–
•
Possible on motes
MAC scheduling
Prioritization (VMS)
93
Design Requirements
• Real-time requirements
Minimize end-to-end deadline miss ratio
• Support distributed microsensing
High-level service API’s
• Large scale, high density
Scalability is key
• Extreme resource constraints: bandwidth, energy
Minimum protocol overhead
8/30/2002
CS537S Sensor Networks
94
Location-based Communication
ID-based
Location-based
• From ID to ID
• What is the reading of
sensor 125.111.1.5?
• Rely on (unreliable)
individual sensors
• From location to location
• What is the virus density in
south terminal of airport?
• Individual sensors NOT
important
• Local coordination:
Sensors in interested area
aggregate data
• Sensor-base comm.:
Send aggregated result to
base station
8/30/2002
CS537S Sensor Networks
95
RAP:
Real-time locAtion-based Protocols
Sensing/Control
Application
Query/Event Service APIs
Query/Event Service
Coordination Service
Location-Addressed Protocol
Geographic Routing
Velocity Monotonic Scheduling
Prioritized MAC
8/30/2002
CS537S Sensor Networks
96
Query/Event Service
Coordination
Service
Location-Addressed Protocol
Query/Event API
Geographic Forwarding
Velocity Monotonic Scheduling
Prioritized MAC
• High-level abstraction for programming
distributed microsensing applications
register_event {
virusFound(0,0,100,100),
query {
virus.count,
area=(x-1,y-1,x+1,y+1),
period=1.5, deadline=5,
base=(100,100)
}
}
8/30/2002
// area to post event
// query to be triggered
// attribute
// query area
// timing info
// base station location
CS537S Sensor Networks
97
Query/Event Service
Coordination
Service
Location-Addressed Protocol
Geographic Routing
Geographic Forwarding
Velocity Monotonic Scheduling
Closest
to C
A
E




Prioritized MAC
C
Local state  Scalability
Dense network  Efficient greedy forwarding works well
Dense network  #hop proportional to distance
Location-based comm.  No location directory service
8/30/2002
CS537S Sensor Networks
98
Query/Event Service
Velocity
Coordination Service
Location-Addressed Protocol
Geographic Forwarding
Velocity Monotonic Scheduling
Prioritized MAC
• Timing constraint: deadline
• Location constraint: distance to destination
• Requested Velocity
– Embody both constraints
– Reflect local urgency
Velocity Monotonic Scheduling (VMS):
Priority = Requested Velocity
8/30/2002
CS537S Sensor Networks
99
Example
D
dis = 90 m; D = 2 s
V = 45 m/s
HIGH Priority
A
C
B
dis = 60 m; D = 2 s
V = 30 m/s
LOW Priority
8/30/2002
CS537S Sensor Networks
100
Velocity Monotonic Scheduling
Static VMS
• Fixed velocity on each hop
• V = dis(x0,y0,xd,yd)/D
– Source location: (x0,y0)
– Destination location: (xd,yd)
– End-to-end deadline: D
Dynamic VMS
• Adapt velocity at intermediate node based on progress
• Vi = dis(xi,yi,xd,yd)/Si
– Velocity at node: Vi
– Location of node i: (xi,yi)
– Slack: Si = D – elapseTime
8/30/2002
CS537S Sensor Networks
101
Prioritized MAC
Query/Event Service
Coordination Service
Location-Addressed Protocol
Geographic Forwarding
Velocity Monotonic Scheduling
Prioritized MAC
•
•
•
Collision Avoidance (CA)
– Channel idle  wait for randDIFSPrio
Contention
– Collision (No CTS or No ACK)CW = CW*(2+(Prio-1)/MAX_Prio)
Similar to 802.11’s EDCF
Acquire
Channel
Idle
randDIFSPrio
Avoidance
8/30/2002
CW
Contention
Exponential Backoff
CS537S Sensor Networks
Time
Transmission
102
Simulation:
Biometric Sensing
• 100 nodes on 136X136 m2 (4.5X4.5 radius2)
• Periodic query count on 31 nodes; detail on 15 nodes
Base
Station
Hot Regions
(sources)
FAR
8/30/2002
CS537S Sensor Networks
103
Workload
• Network (roughly approximate MICA mote)
– Communication range: 30.5 m
– Packet size: 32B (count), 160 B (detail)
– Bandwidth: 200 kbps (> MICA)
• Protocols
– Routing: DSR (Dynamic Source Routing), GF
(Geographic Forwarding)
– Scheduling: FIFO, DS (Deadline-based), SVM, DVM
– MAC: 802.11, extended 802.11 w. prioritization
8/30/2002
CS537S Sensor Networks
104
Deadline Miss Ratio
Overall
8/30/2002GlomoSim
CS537S
Sensor Networks
simulation
(deadline:
detail: 5 s, count: 10 s)
105
Deadline Miss Ratio
FAR hot region
8/30/2002GlomoSim
CS537S
Sensor Networks
simulation
(deadline:
detail: 5 s, count: 10 s)
106
miss ratio
Distance Fairness
1.00
0.90
0.80
0.70
0.60
0.50
0.40
0.30
0.20
0.10
0.00
FIFO
SVM
DS
0
50
100
150
200
distance from base station (m)
• SVM provides “fairer” service to remote sensors
– Critical for scalability of sensor networks!
8/30/2002
CS537S Sensor Networks
107
Conclusion
• Velocity Monotonic Scheduling
Reduce end-to-end deadline miss ratio
Fair service to remote sensors
• Event/query service API’s
High-level abstraction for distributed
microsensing
• Location-based protocol stack
Scalable
Small protocol overhead
8/30/2002
CS537S Sensor Networks
108
Critique
• VMS
–
–
–
–
DVM
No schedulability analysis or admission control  No guarantee
Is velocity the right trade-off between distance and time?
Distance = #hop? in-doors, obstacles, void, long links
• No routing or congestion control to handle congestion:
RAP+SPEED+?
• Lack support for
– Coordination services
– Areamulticast
– Mobility
• It’s a whole (or three) PhD thesis ahead! 
8/30/2002
CS537S Sensor Networks
109
5.4 Berkeley Mote &
TinyOS
Class Issues
• Motes arrived 
–
–
–
–
–
5 programming board
25 mica CPU/radio boards
10 rene sensor boards: light, temperature
5 mica sensor board: light, temperature, acoustic
Did not get: accelerometer, magnetometer
• Slides finally online
• Sample project to appear later this week
(promise!)
• 24 days to proposal due date
• Free food: ACM BBQ @ 11-1p Friday Lopata Courtyard
8/30/2002
CS537S Sensor Networks
111
Hardware Constraints
• Severe constraints in power, size, and cost
translated to:
• Slow CPU
• Short-distance, low-bandwidth radio
• Small memory
• Limited hardware parallelisms
– CPU hit by many interrupts!
• Support sleep mode in hw components
8/30/2002
CS537S Sensor Networks
112
Mote
• CPU: 4 MHz, 8 bit
– NO kernel/user protection
– Raw peripherals  a lot work for CPU:
• Collect data from sensors
• Process every bit to/from radio
• Arbitrate bus
• Radio: 900 Hz
– Rene: 19.2 kbps
– Mica: 50 kbps (max), 200 feet (power adjustable)
– NO byte level processing
• Memory
– Rene: 512 B data; 8K code
– Mica: 4 KB data; 128 KB code
• Two AA battery
– 3 days of continuous active operation
• Sleep modes: idle/power-down/power-save
8/30/2002
CS537S Sensor Networks
113
Software Challenges
• Small memory footprint
• Efficient in power and computation
• Lack hardware parallelism  OS provides
concurrency-intensive operation
• Real-time
• Robust
• Diversity in applications and design 
– Efficient modularity
– Reconfigurable hardware
– Software & hardware codesign
8/30/2002
CS537S Sensor Networks
114
How about a traditional embedded OS?
• Multi-threaded architecture
– Large number of threads  large memory
– Context switch overhead
• I/O model
– Blocking I/O (stop and go): waste memory on blocked threads
– Polling (busy-wait): waste CPU cycles and power
• Protection between applications and kernel
– Overhead for crossing kernel/user boundary & interrupt handling
• Pros
– Clean & simple programming model
– Priority-based scheduling support
– Robust (protect kernel)
8/30/2002
CS537S Sensor Networks
115
Example: Existing embedded OS
1. Thread 1 (high prio) runs
–
–
read from socket 1
block
2. Thread 2 (medium prio) runs
–
–
3.
4.
5.
6.
read from socket 2
block
Thread 3 (low prio) runs
Thread 2 unblocked, preempt thread 3
Thread 1 unblocked, preempt thread 2
Threads 1,2,3 complete in order
3 TCB’s, 6 context switches, 7 kernel/user switch
8/30/2002
CS537S Sensor Networks
116
TinyOS Solutions
• Support concurrency: event-driven architecture
• Modularity: application = scheduler + graph of components
– Compiled into one executable
• Efficiency: Get done quickly and sleep
– Event = function calls
– Less context switch: FIFO/non-preemptable scheduling
– No kernel/application boundary
Main (includes Scheduler)
Application (User Components)
Actuating
Communication
Sensing
Communication
Hardware Abstractions
Modified from D. Culler et. Al., TinyOS boot camp presentation, Feb 2001
8/30/2002
CS537S Sensor Networks
117
TinyOS component model
• Component has:
Messaging Component
– Frame (memory)
– Tasks: thread (computation)
– Interface:
• Command
• Event
Internal Tasks
Commands
Internal State
Events
• Frame: static storage model – compile-time allocation
• Command and events = function calls
• Clean (hw-like) interface
– No shared memory or global variables
– Replace hw with sw and vice versa
8/30/2002
CS537S Sensor Networks
118
TOS Component
AM_SUB_TX_PACKET
AM_SUB_INIT
AM_SUB_POWER
Internal Tasks
Commands
8/30/2002
AM_MSG_REC
AM_MSG_SEND_DONE
AM_RX_PACKET
_DONE
Messaging Component
TOS_MODULE AM;
ACCEPTS{
char AM_SEND_MSG(char addr, char type,
char* data);
void AM_POWER(char mode);
char AM_INIT();
};
SIGNALS{
char AM_MSG_REC(char type,
char* data);
Internal State
char AM_MSG_SEND_DONE(char success);
};
HANDLES{
char AM_TX_PACKET_DONE(char success);
char AM_RX_PACKET_DONE(char* packet);
};
USES{
char AM_SUB_TX_PACKET(char* data);
void AM_SUB_POWER(char mode);
char AM_SUB_INIT();
};
CS537S Sensor Networks
119
AM_TX_PACKET
_DONE
AM_SEND_MSG
AM_POWER
AM_INIT
//AM.comp//
Events
A Complete Application
D. Culler et. Al., TinyOS boot camp presentation, Feb 2001
application
sensing application
Routing Layer
routing
messaging
Messaging Layer
Radio Packet
packet
byte
bit
8/30/2002
Radio byte (MAC)
RFM
photo
clocks
CS537S Sensor Networks
ADC
Temp
i2c
SW
HW
120
TinyOS Two-level Scheduling
• Tasks do computations
– Unpreemptable FIFO scheduling
– Bounded number of pending tasks
• Events handle interrupts
– Interrupts trigger lowest level events
– Events can signal events, call commands, or post tasks
• Two priorities
– Event/command
– Tasks
Tasks
Preempt
events
POST
FIFO
commands
commands
Interrupts
8/30/2002
Hardware
CS537S Sensor Networks
Time
121
How to handle multiple data flows?
• Data/interrupt are handled by
– Respond to it quickly: A sequence of non-blocking
event/command (function calls) through the component
graph
• e.g., get bit out of radio hw before it gets lost
– Post tasks for long computations
• e.g., encoding
– Assumption: long computation are not emergent
• Preempting tasks to handle new data
8/30/2002
CS537S Sensor Networks
122
Receiving a message
Timing diagram of event propagation
8/30/2002
CS537S Sensor Networks
123
How should network msg be handled?
• Socket/TCP/IP?
– Too much memory for buffering and threads
• Data are buffered in network stack until application threads read it
• Application threads blocked until data is available
– Transmit too many bits (sequence #, ack, re-transmission)
– Tied with multi-threaded architecture
• TinyOS solution: active messages
8/30/2002
CS537S Sensor Networks
124
Active Message
• Every message contains the name of an event handler
• Sender
– Declaring buffer storage in a frame
– Naming a handler
– Requesting Transmission; exit
– Done completion signal
• Receiver
– The event handler is fired automatically in a target node
 No blocked or waiting threads on sender or receiver
 Behaves like any other events
 Single buffering
8/30/2002
CS537S Sensor Networks
125
Send Message
char TOS_COMMAND(INT_TO_RFM_OUTPUT)(int val){
int_to_led_msg* message = (int_to_led_msg*)VAR(msg).data;
if (!VAR(pending)) {
message->val = val;
if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAST,
AM_MSG(INT_READING), &VAR(msg))) {
VAR(pending) = 1;
return 1;
access appln msg buffer
}
}
cast to defined format
return 0;
application specific ready check
}
build msg
request transmission
destination identifier
get handler identifier
msg buffer
8/30/2002
CS537S Sensor Networks
mark busy
126
Analysis and Evaluation
• Let’s take apart Space, Power and Time
8/30/2002
CS537S Sensor Networks
127
Space Breakdown…
Code size for ad hoc networking
application
3500
3000
Bytes
2500
2000
1500
1000
500
0
8/30/2002
Interrupts
Message Dispatch
Initilization
C-Runtime
Scheduler: 144 Bytes code
Light Sensor
Totals: 3430 Bytes code
Clock
226 Bytes data
Scheduler
Led Control
Messaging Layer
Packet Layer
Radio Interface
Routing Application
Radio Byte Encoder
D. Culler et. Al., TinyOS boot camp presentation, Feb 2001
CS537S Sensor Networks
128
Power Breakdown…
Active
Idle
Sleep
CPU
5 mA
2 mA
5 μA
Radio
7 mA (TX)
4.5 mA (RX)
5 μA
EE-Prom
3 mA
0
0
LED’s
4 mA
0
0
Photo Diode
200 μA
0
0
Temperature 200 μA
0
0
Panasonic
CR2354
560 mAh
– Lithium Battery runs for 35 hours at peak load and years at
minimum load!
• That’s three orders of magnitude difference!
– A one byte transmission uses the same energy as approx
11000 cycles of computation.
8/30/2002
CS537S Sensor Networks
129
Time Breakdown…
Components
AM
Packet
Ratio handler
Radio decode thread
RFM
Radio Reception
Idle
Total
Packet reception
work breakdown CPU Utilization
0.05%
1.12%
26.87%
5.48%
66.48%
100.00%
0.20%
0.51%
12.16%
2.48%
30.08%
54.75%
100.00%
Energy (nj/Bit)
0.33
7.58
182.38
37.2
451.17
1350
2028.66
• 50 cycle thread overhead (6 byte copies)
• 10 cycle event overhead (1.25 byte copes)
8/30/2002
CS537S Sensor Networks
130
Applications
•
•
•
•
•
Multi-hop routing
Active badge
Vehicle sensing
Air-to-ground communication
Habita monitoring @ Great Duck Island
8/30/2002
CS537S Sensor Networks
132
Routing
• Each node needs to determine it’s parent and its
depth in the tree
• Each node broadcasts out <identity, depth, data>
when parent is known
• At start, Base Station knows it is at depth 0
– It send out <Base ID, 0, **>
• Individuals listen for minimum depth parent
2
1
3
Base
8/30/2002
0
2
1
CS537S Sensor Networks
133
Active badge
• 16 motes deployed on 4th floor
Soda Hall
• 10 round motes as office
landmarks
• 2 base stations around
corners of the building
• 4 Rene motes as active
badges for location tracking
• AA batteries (3 weeks)
• Tracking precision +/- one
office
http://nighthawk.cs.berkeley.edu:8080/tracking
8/30/2002
CS537S Sensor Networks
134
Vehicle sensing
• Unmanned airplane dropped motes from an
unmanned airplane
• Motes automatically forms a network
• Motes detect passing vehicles through
magnetic sensors
• Unmanned airplane sends a query to motes
to get the passing time of the vehicle
8/30/2002
CS537S Sensor Networks
135
TinyOS: Pros
• Small memory footprint
– Non-preemptable FIFO task scheduling
• Power efficient
– Put microcontroller and radio to sleep
• Efficient modularity
– Clean function call (event, command) interface
between components
• Concurrency-intensive operations
– Event/command + tasks
– Efficient interrupts/events handling (function calls, no
user/kernel boundary)
8/30/2002
CS537S Sensor Networks
136
TinyOS: Cons
• Messy/difficult programming model
– Explicit negotiation for data/resource
– No “long-running” things in command/event handlers
– No kernel/user protection  NOT robust
• An infinite loop in application: all dead!
– Zero compatibility  implement everything from scratch
• No overload protection
– “Livelock”: interruptions/events consume all CPU cycles  NO
real-work get done
• No real-time support/analysis
– Non-preemptable FIFO task scheduling
– How do we know the performance?
• Over constraining the platform?
8/30/2002
CS537S Sensor Networks
137
TinyOS: Extensions
• Virtual machine: Mate
– Higher-level programming model
– Protection
– Code mobility
• A project:
– Preemptable, priority-based scheduling (RM, EDF,
proportional share)
– Timing analysis
– Avoid “live lock”
– Overload protection
8/30/2002
CS537S Sensor Networks
138
Pointers
• Brian: Virtual machine (Thursday)
• Xiaorui: TinyOS internals (Next Thursday)
– No critique required
• http://today.cs.berkeley.edu/tos/
• http://www.xbow.com/Products/Wireless_Sensor
_Networks.htm
8/30/2002
CS537S Sensor Networks
139