Part IV: Sensor Network Protocols

Deborah Estrin

IV-1

Wireless Sensor Network Protocols

• Primary theme: building long- User Queries, External Database

lived, massively-distributed,
physically-coupled systems:
In-network: Application processing,
Aggregation, Query processing
– Coordinating to minimize
duty cycle and Data dissemination, storage, caching
communication
• Adaptive MAC
Adaptive topology, Geo-Routing
• Adaptive Topology
• Routing
– In-network processing MAC, Time, Location
• Data centric routing
• Programming models Phy: comm, sensing, actuation, SP
IV-2
 Medium Access Control in Sensor Nets

• Important attributes of MAC protocols

1. Collision avoidance
2. Energy efficiency
3. Scalability in node density
4. Latency
5. Fairness
6. Throughput
7. Bandwidth utilization

IV-3

MAC Impact on Sensor Networks

(Intanago et al, 2000)

• Major sources of energy waste

• Idle listening when no sensing events, Collisions,
Control overhead, Overhearing
(Joules/Node/Received Event)

(Joules/Node/Received Event)

0.14 0.018
Average Dissipated Energy

Diffusion
Average Dissipated Energy

0.12 0.016 Flooding

Flooding Omniscient Multicast 0.014
0.1
0.012
0.08 0.01
0.06 0.008 Omniscient Multicast
0.006
0.04 Diffusion
0.004
0.02 0.002
00 50 100 150 200 250 300 00 50 100 150 200 250 300
Network Size Network Size
Over 802.11-like MAC Over energy-aware MAC

IV-4
 Identifying the Energy Consumers

Power consumption of node subsystems

20

15
Power (mW)

10

0
CPU TX RX IDLE SLEEP
SENSORS
RADIO
• E TX ≈ E RX ≈ E IDLE >> E SLEEP
• Need to shutdown the radio

From Tsiatis et al. 2002

IV-5

Energy Efficiency in MAC

• Major sources of energy waste

– Idle listening
• Long idle time when no sensing event happens
• Collisions
• Control overhead Common to all
• Overhearing wireless networks
• Try to reduce energy consumption from all above
sources
• TDMA requires slot allocation and time synchronization
• Combine benefits of TDMA + contention protocols

IV-6
 Sensor-MAC (S-MAC) Design
(Wei et al. 2002)

• Tradeoffs

Latency
Energy
Fairness

• Major components of S-MAC

• Periodic listen and sleep
• Collision avoidance
• Overhearing avoidance
• Message passing

IV-7

Periodic Listen and Sleep

• Problem: Idle listening consumes significant energy

– Nodes do not sleep in IEEE 802.11 ad hoc mode

listen sleep listen sleep

• Solution: Periodic listen and sleep

– Turn off radio when sleeping
– Reduce duty cycle to ~10% (200 ms on/2s off)
– Increased latency for reduced energy

IV-8
 Periodic Listen and Sleep

• Schedules can differ

Node 1 listen sleep listen sleep

Node 2 listen sleep listen sleep

• Preferable if neighboring nodes have same schedule

— easy broadcast & low control overhead

Schedule 1 Border nodes:

Schedule 2 two schedules
broadcast twice

IV-9

Periodic Listen and Sleep

• Schedule maintenance
– Remember neighbors’ schedules
— to know when to send to them
– Each node broadcasts its schedule every few periods
– Refresh on neighbor’s schedule when receiving an
update
– Schedule packets also serve as beacons for new
nodes to join a neighborhood

IV-10
 Collision Avoidance

• Problem: Multiple senders want to talk

• Options: Contention vs. TDMA
• Solution: Similar to IEEE 802.11 ad hoc mode (DCF)
– Physical and virtual carrier sense
– Randomized backoff time
– RTS/CTS for hidden terminal problem
– RTS/CTS/DATA/ACK sequence

IV-11

Overhearing Avoidance

• Problem: Receive packets destined to others

• Solution: Sleep when neighbors talk
– Basic idea from PAMAS (Singh 1998)
– But we only use in-channel signaling
• Who should sleep?

• All immediate neighbors of sender and receiver

• How long to sleep?
• The duration field in each packet informs other nodes the
sleep interval

IV-12
 Message Passing

• Problem: In-network processing requires

entire message
• Solution: Don’t interleave different messages
– Long message is fragmented & sent in burst
– RTS/CTS reserve medium for entire message
– Fragment-level error recovery
— extend Tx time and re-transmit immediately
• Other nodes sleep for whole message time

Fairness Energy
Msg-level latency
IV-13

Msg Passing vs. 802.11 fragmentation

Time reservation by duration field

• MP
RTS 21 Data 19 Data 17 ... Data 1
CTS 20 ACK 18 ACK 16 ... ACK 0

• 802.11
RTS 3 Data 3 Data 3 ... Data 1
CTS 2 ACK 2 ACK 2 ... ACK 0

ü If ACK is not received, give up Tx — fairness

ü No indication of entire time — other nodes keep listening
IV-14
 Implementation on Testbed Nodes

• Platform
• Motes (UC Berkeley) :
• 8-bit CPU at 4MHz,
• 8KB flash, 512B RAM
• TinyOS: event-driven
• Also used as NIC for 32-bit embedded
PCs

• Compared MAC modules

• IEEE 802.11-like protocol
• Message passing with overhearing
avoidance
• S-MAC (2 + periodic listen/sleep)
• URL: http://www.isi.edu/scadds/smac/

IV-15

S-MAC Experimental results

(implemented on UCB Mote over RFM radio)

• Topology and measured energy consumption on

source nodes Energy consumed
Average energy consumption in the source nodes
1800
Source 1 Sink 1 802.11-like protocol
1600 Overhearing avoidance
S-MAC
Energy consumption (mJ)

1400

Source 2 Sink 2 1200

1000
• Each source node sends 800
10 messages
600
— Each message has 10 400
fragments x 40B
200
• Measure total energy
— Data + control + idle
0 2 4 6 8 10
Message inter-arrival period (second)
Message Inter-arrival period

IV-16
 Adaptive Topology

• Can we do more than shut down radio in between

transmissions/receptions?
• Can we put nodes to sleep for longer periods of time?
• Goal:
– Exploit high density (over) deployment to extend
system lifetime
– Provide topology that adapts to the application needs
– Self-configuring system that adapts to environment
without manual configuration

IV-17

Adaptive Topology: Problem Description

• Simple Formulation (Geometric Disk Covering)

– Given a distribution of N nodes in a plane.
– Place a minimum number of disks of radius r (centered on
the nodes) to cover them.
– Disk represents the radio connectivity (simple circle model).
• The problem is NP-hard.

IV-18
 Connectivity Measurements*

Packet reception over distance has a heavy tail. There is a non-

zero probability of receiving packets at distances much greater
than the average cell range Can’t just
determine
connectivity
clusters thru
geographic
coordinates…

For the same

reason you can’t
determine
coordinates
w/connectivity
169 motes, 13x13 grid, 2 ft spacing, open area, RFM radio,
simple CSMA

*An Empirical Study of Epidemic Algorithms in Large Scale Multihop Wireless Networks
Ganesan, Krishnamachari, Woo, Culler, Estrin and Wicker, UCLA/CSD-TR 02-0013.
IV-19

Tradeoff
• How many nodes to activate?
– few active nodes:
• distance between neighboring nodes high -> increase packet loss and
higher transmit power and reduced spatial reuse;
• need to maintain sensing coverage (see earlier session on
coverage/exposure)

– too many active nodes:

• at best, expending unnecessary energy;
• at worst nodes may interfere with one another by congesting the
channel.

IV-20
 Adaptive Topology Schemes

• Mechanisms being explored:

– Empirical adaptation: Each node assesses its connectivity
and adapts participation in multi-hop topology based on the
measured operating region, ASCENT (Cerpa et al. 2002)
– Cluster-based, load sharing within clusters, CEC (Xu et al.
2002)
– Routing/Geographic topology based, eliminate redundant
links, SPAN (Chen et al. 2001), GAF (Xu et al. 2001)
– Data/traffic driven: Trigger nodes on demand using paging
channel, STEM (Tsiatsis et al. 2002)

IV-21

One example algorithm: ASCENT

• The nodes can be in active or passive state.
– Active nodes forward data packets (using routing
mechanism that runs over topology).
– Passive nodes do not forward any packets but may sleep or
collect network measurements.
• Each node joins network topology or sleeps according to
measured number of neighbors and packet loss, as
measured locally.

Help Neighbor
Messages Announcements Data
Data Message Messages Message

Source Sink Sink Source Sink

Source

Passive Neighbor Active Neighbor

(a) Communication Hole (b) Self-configuration transition (c) Final State

IV-22
 State Transitions

after Tt
Test Active

neighbors < NT
neighbors > NT (high ID for ties);
and
or
• loss > LT
loss > loss T0
• loss < LT & help
after Tp

Passive Sleep
after Ts
NT: neighbor threshold
LT: loss threshold
T?: state timer values (p: passive, s: sleep, t: test)
IV-23

Testbed Platforms
• Tiered architecture: heterogeneous set of platforms (no particular
set of compromises with a unique platform).
• PC-104/iPAQ enable running tasks that are more CPU/memory
intensive.

PC-104/RPC iPAQ UCB Mote

• Simulator:
– Discrete event-driven simulator.
– Multiple stackable modules perform different functionality.

IV-24
 Energy Savings Ratio

Energy Savings Ratio (normalized to the Active case, all nodes turn on) as a
function of density. ASCENT provides significant amount of energy savings,
with a factor of 5 for high density scenarios.
IV-25

Event Delivery Ratio

Event Delivery Ratio as a function of density. ASCENT reduces collisions experienced by

diffusion routing by limiting the maximum number of active nodes transmitting packets.

Open question: to what extent would SMAC or Geo-routing produce the same result?
IV-26
 Goal Routing Assumptions
(general: energy dependency
savings)

GAF preserve routing fidelity none geographic information for

grid placement
radio connectivity directly
correlated with geography

SPAN preserve capacity of the gets connectivity matrix and 802.11 MAC with Power
raw topology neighbors from routing Savings mode
requires modifications in the
routing lookup process

STEM tradeoff latency for needs routing info to direct the 2 radios/wake-up channel
energy savings wake-up wave connectivity conditions
remain constant in sleeping
periods

ASCENT adapt topology based on none radio supports promiscuous

application needs mode

IV-27

STEM: Data drive wakeup

(Tsiatsis et. al 2002)

Wake up the nodes along the path

HOW ???

Sensor-triggered node wakeup

user
event
Zzz Zzz
Zzz
Zzz

sensor network

Path nodes need to be woken up

IV-28
 STEM: Sparse Topology and Energy Management

• Need to separate Wakeup and Data Forwarding Planes

• Chosen two separate radios for the two planes

• Use separate radio for the paging channel to avoid interference

with regular data forwarding

• Trades off energy savings for path setup latency

Wakeup plane: f1

Data plane: f2

IV-29

Duty Cycled Wakeup Radio

Initiator node
f1

B1
B2
1. beacon received
Train of beacon packets
TRx
2. beacon acknowledge

T
f1

Target node
IV-30
 Performance Metrics

E
T S (sec) E0

T (sec) T (sec)

IV-31

Energy vs Latency

E
50%
E0

10%

1%
0. 1%

TS (sec)
IV-32
 STEM Design Decisions

• One radio with one frequency band would cause interference

between the wakeup and data planes
A B
Active mode
Interference Polling mode
C

D
Sleep mode

• One radio with two frequencies would have to change

frequency to listen for setup requests
• One radio with time multiplexed wake-up and data planes
would require time synchronization between the two nodes –
time sync in ad-hoc networks is an open problem by itself
• The additional radio cost is about 15% of the total cost of the
node (from private communication with Savvides)

IV-33

Design Issue: Collision Resolution

1 initiator node

• beacon received correctly

• only intended receiver turns on the data
radio and sends a beacon acknowledge
in the wakeup plane

more initiator nodes

• upon detection of collision, a node turns on its data radio

• after T, the initiator node assumes the target node is up
and contacts it on the data plane
• when an expected target node doesn’t receive data, it
times out and goes back to sleep

IV-34
 Exploiting Latency AND Density

• Existing approaches (ASCENT, GAF, SPAN, etc) exploit node

density
Zzz

Zzz

Active nodes

• Combine STEM and one of these schemes (chosen GAF)

Zzz
Zzz

STEM

IV-35

Performance of STEM+GAF

E
E0

STEM GAF
alone

STEM + GAF TS = 400 ms

TS = 675 ms
TS = 900 ms

avg # of neighbors
IV-36
 Conclusions

• STEM leverages data latency for energy savings

• Combining existing algorithms that leverage density

and STEM yields additional energy savings

• Provide with design time tools for extending the

lifetime of the network

IV-37

Adaptive Topology: Future Work

• Load Balancing.
• Larger scale experiments.
• Interaction with adaptive MAC and geographic
routing
• Application defined Adaptive Fidelity
– Expanding on STEM’s data driven characteristics to
achieve more than on/off behavior

IV-38
 Routing

• Given a topology, how to route data?

– MANET: Reactive[DSR], proactive[AODV], TORA,
GPSR[KarpKung00]
– Location-aided routing: Geocast[Navas97],Cartesian-LAR,
[KOVaidya98]

– Building on Geo Routing

• GRAB (Lu et al 2002)
• Routing on curve (Badri 2002)

IV-39

GRAB:
Field Based Minimum Cost Forwarding
(Lu et al 2002)

• Each node broadcasts only once

• Cost Function
– A measure of how expensive it is to get a message back to
the sink.
– Could be base:
• Energy needed in radio communication.
• Hop count.
• …
• Node Cost
– Each node keeps a best estimate on its minimum cost.
– Estimate updated upon receipt of every ADV message.
– ADV message forwarding deferred for time proportional to
nodes cost estimate.

IV-40
 ADV Dissemination Example

• Signal strength is used to

measure cost.
• B sees strong signal and
judges cost to be 1.
• C sees weak signal and
judges cost to be 3.

IV-41

ADV Dissemination Example contd.

• Because B has a smaller

cost, he defers for a shorter
time then C.
• C updates his cost to 2 and
restarts his deferral timer.
• Each node has optimal cost
with minimum broadcast.

IV-42
 Data Dissemination

• A node that decides it has interesting data. broadcasts two

things (besides data)
– Total budget to get back to sink.
– Amount of budget used in initial broadcast.

• A node receiving a data message will only forward a data

message if
Total Budget ≥ Budget Spent So Far + My Cost
– If the inequality holds then Budget Spent So Far is updated.
– Otherwise the message is dropped.

IV-43

Data Dissemination Example

• Assume hop count was used

as a cost metric.
• Node A is the sink.
• Node C is the source.

IV-44
 Data Dissemination Example contd.

• Node C sends a data

message which specifies
– Total Budget = 2
– Budget Spent = 1
• Node E drops message
– TB < BS + E’s Cost
• Node B forwards message.

IV-45

Routing on a Curve
(Nath et al 2002)

• Trajectories are a natural name space for embedded

networks
• By definition, network structure mimics physical
structure that is instrumented
– Stress along a column
– Flooding along a river
– Pollution along a road
• Trajectories come from the application domain

IV-46
 TBF (Trajectory based forwarding)

• Fundamental Idea
– Route packets along a specified trajectory
• Generalization of Source Based Routing and Cartesian
routing
• Trajectory specified in the packet

IV-47

Specifying trajectory

y = ax + b, y = sin x
• Function
• Equation axx+= by
t , y += c
at =
+ b1;, xx= + y 2t , +y 1= r cos t
2
r sin
• Parametric
– we use this choice

IV-48
 Features of TBF

• Basic Features
– Decouples pathname from the actual path
• Source based Routing (LSR, DSR etc) mixes
naming and route path
• Applications:
– Route around obstacles/changes/failures
– Trajectory forwarding need not have a “destination”
• Route along a line, pattern
• Applications:
– Flooding, discovery, group communication (pollination)

IV-49

Routing on a curve

IV-50
 Spoke flooding

IV-51

Flooding along spokes

100
90
80
70
60
Coverage
50
Packets
40
30
20
10
0
4 9
Number of Spokes

IV-52
 Related Work

• MANET
– Reactive[DSR], proactive[AODV], TORA,
GPSR[KarpKung00]
• Location-aided routing
– Geocast[Navas97],Cartesian-LAR, [KOVaidya98]
• Localization techniques
– GPS, Cricket[Priyantha00],RADAR[Bahl00],
– Ahlos[bulusu00,Savides01],TdoA technique, Visual cues

IV-53

Discussion

• Trajectory modifications
• No forward progress
– Retry from source
– Local reverse gear
– Apply detour patches
– Packets allowed to backtrack
• Specifying trajectories
– Accurate trajectories
– Use fourier components
– Tradeoff between number of components and
accuracy

IV-54
 In-Network Processing
The Key to Sensor Network scalability and Realization

• Gupta and Kumar pointed out fundamental limits of

large scale wireless networks (per node throughput
O(1/sqrtN)
• However, S. Servetto shows that result holds only for
independent nodes (Mobicom 2002)
– Densely deployed sensor network data will be
correlated and can be aggregated
• Scalability and lifetime will depend on techniques
for in-network processing of data
– Naming Data: Directed Diffusion
– Data base perspectives:TAG, Sylph
– Programming mechanisms: Sensorware, Mate

IV-55

Directed Diffusion: Data Centric Routing

• Basic idea
– name data (not nodes) with externally relevant attributes
• Data type, time, location of node, SNR, etc
– diffuse requests and responses across network using
application driven routing (e.g., geo sensitive or not)
– optimize path with gradient-based feedback
– support in-network aggregation and processing

• Data sources publish data, Data clients subscribe to data

– However, all nodes may play both roles
• A node that aggregates/combines/processes incoming sensor
node data becomes a source of new data
• A sensor node that only publishes when a combination of
conditions arise, is a client for the triggering event data
– True peer to peer system

• Implementation defines namespace and simple matching rules

with filters
– Linux (32 bit proc) and TinyOS (8 bit proc) implementations IV-56
 Diffusion as a construct for
in-network processing
• Nodes pull, push, and store named data (using tuple space) to create
efficient processing points in the network
– e.g. duplicate suppression, aggregation, correlation
• Nested queries reduce overhead relative to “edge processing”
• Complex queries support
collaborative signal
processing
– propagate function
describing desired
locations/nodes/data
(e.g. ellipse for tracking)
– Interesting analogs to emerging
peer-to-peer architectures
• Build on a data-centric architecture
for queries and storage

IV-57

Nested Query Evaluation

(example experiment w/sub-optimal hardware)
(Heidemann et al.)

• Nested queries greatly

events successfully received (%)

improve event delivery rate

• Specific results depend on 80 nested
experiment
– placement 60

– limited quality MAC 40

• General result: app-level flat
20
info needed in sensor nets;
diffusion is good platform 1 2 3 4
number of light sensors

IV-58
 A more general look at
Data Centric vs. Address Centric
approach
(Krishnamachari et al.)
• Address Centric
• Distinct paths from each source to sink.

• Data Centric
• Support aggregation in the network where paths/trees overlap
• Essential difference from traditional IP networking

• Building efficient trees for Data centric model

• Aggregation tree: On a general graph if k nodes are sources and one is a
sink, the aggregation tree that minimizes the number of transmissions is the
minimum Steiner tree. NP-complete….Approximations:
• Center at Nearest Source (CNSDC): All sources send through source
nearest to the sink.
• Shortest Path Tree (SPTDC): Merge paths.
• Greedy Incremental Tree (GITDC): Start with path from sink to nearest
source. Successively add next nearest source to the existing tree.

IV-59

Source placement: event-

event-radius model

IV-60
 Comparison of energy costs

Data centric has many fewer transmissions than

does Address Centric; independent on the tree
building algorithm.

Address Centric
Shortest path data centric
Greedy tree data centric
Nearest source data centric
Lower Bound

IV-61

Opportunism always pays;

Greed pays only when things get very crowded
(Intanagowiwat et al. ns-2 more detailed simulations)
 Programming Paradigm
• Move beyond simple query with in-network aggregation model

• How do we task a 1000+ node dynamic sensor network to

conduct complex, long-lived queries and tasks ??
– What constructs does the query language need to support?

• What sorts of mechanisms need to be “running in the

background” in order to make tasking efficient?
– Small databases scattered throughout the network, actively
collecting data of nearby nodes, as well as accepting
messages from further away nodes?
– Active messages traveling the network to both train the
network and identify anomalous conditions?

IV-63

Examples
• Map isotherms and other “contours”, gradients, regions
– Record images wherever acoustic signatures indicate significantly
above-average species activity, and return with data on soil and air
temperature and chemistry in vicinity of activity.
– Mobilize robotic sample collector to region where soil chemistry and
air chemistry have followed a particular temporal pattern and where
the region presents different data than neighboring regions.

• Raises requirements for some global context, e.g. “average” levels

– Emerging role for distributed storage architecture

• Pattern identification: how much can and should we do in a distributed

manner?
– Similar to some vision/image analysis problems but distributed
noisy inputs

IV-64
 Why databases?

• Sensor networks are capable of producing massive amounts of

data
– Sensor networks should be able to
• Accept queries for data
• Respond with results
– Users will need
• An abstraction that guarantees reliable results
• Largely autonomous, long lived network

• Efficient organization of nodes and data will extend network

lifetime
– Database techniques already exist for efficient data storage
and access

IV-65

Database-centric Approach
(Muntz et al.)

• Query processing
– Storage structures:
• Less choice here … traditionally, data organized on disk
• Here, data originates at the sensors’ location
– Time coherency across space
– “Stream” processing … one pass over data
• E.g., try to estimate a histogram on the fly.
– Quality of service:
• Latency vs. completeness
• Actuators: e.g., camera pan and zoom
– Tradeoffs in communication vs. computation and storage:
e.g., filter-refine: where to do what.

IV-66
 Differences between databases and sensor
networks

• Database • Sensor Network

– Static data – Streaming data
– Centralized – Large number of nodes
– Failure is not an option – Multi-hop network
– Plentiful resources – No global knowledge about
– Administrated the network
– Frequent node failure
– Energy is the scarce
– Resource, limited memory
– Autonomous

IV-67

Bridging the Gap

• What is needed to be able to treat a sensor network

like a database?
– How should sensors be modeled?
– How should queries be formulated?

IV-68
 Traditional Approach: Warehousing

• Data is extracted from sensors and stored on a front-end server

• Query processing takes place on the front-end.

Warehouse

Front-end

Sensor Nodes

IV-69

What We’d Like to Do:

Sensor Database System

• Sensor Database System supports distributed query processing

over a sensor network

Sensor Sensor
DB DB
Sensor
DB
Sensor Sensor
Front-end DB DB

Sensor
Sensor DB Sensor
DB DB

IV-70
Sensor Nodes
 Sensor Database System

• Characteristics of a Sensor • Can existing database

Network:
– Streams of data
– Uncertain data
– Large number of nodes
– Multi-hop network
– No global knowledge
about the network
– Node failure and
interference is common
– Energy is the scarce
resource
– Lmited memory
– No administration, …
techniques be reused?
What are the new problems and
solutions?
– Representing sensor data
– Representing sensor
queries
– Processing query fragments
on sensor nodes
– Distributing query fragments
– Adapting to changing
network conditions
– Dealing with site and
communication failures
– Deploying and Managing a
sensor database system

IV-71

Performance Metrics

• High accuracy
– Distance between ideal answer and actual answer?
– Ratio of sensors participating in answer?
• Low latency
– Time between data is generated on sensors and answer is
returned
• Limited resource usage
– Energy consumption

IV-72
 Representing Sensor Data and Sensor Queries

• Sensor Data:
– Output of signal processing functions
• Time Stamped values produced over a given duration
– Inherently distributed
• Sensor Queries
– Conditions on time and space
• Location dependent queries
• Constraints on time stamps or aggregates over time windows
– Event notification

IV-73

Early Work in Sensor Databases

• “Towards Sensor Database System”

“Querying the Physical World”
– Phillipe Bonnet, Johannes Gehrke, Praveen Seshdri

IV-74
 Fjording the Stream: An Architecture for Queries
over Streaming Sensor Data
(Hellerstein et al.)

• How can existing database querying methods be applied to

streaming data?
• How can we combine real-time sensor data with stored historical
data?
• What architecture is appropriate for supporting simultaneous
queries?
• How can we lower sensor power consumption, while still
supporting a wide range of query types?

IV-75

Traditional Database Operators

• Are implemented using “pull” mechanisms.

• Block on incoming data.
• Most require all the data to be read first. (i.e. sort,
average…)
• Optimized for classic IO.
• Usually implemented as separate threads.

IV-76
 Hardware Architecture

• Centralized data
processing.
• Sensor proxies read and
configure sensors.
• Query processor interacts
with proxies to request and
get sensor data.
• Sensor proxies support
multiple simultaneous
queries, multiplexing the
data.

IV-77

Operators

• Implemented as state machines.

• Support transition(state) method, which causes the operator to
optionally read from input queues, write to output queue, and
change state.
• Multiple operators per thread, called by a scheduler. (Round
robin in the experiments)
• Allows fine-grained tuning of processing time allocated to each
operator.

IV-78
 Sensor Sensitive Operators

• Certain operations are impossible to perform on continuous data

streams. (sum, average, sort…)
• Can be performed on partial data windows.
• Joins can be implemented by hashing tuples.
• Can provide aggregation based on current data, with continuous
updates to parent operators.??

IV-79

Sensor Proxy

• Responsible for configuring sensor that belong to it, setting

sensing frequency, aggregation policies, etc..
• To save power, each sensor only listens for commands from
proxy during short intervals.
• Handles incoming data from sensors, and pushes it into
appropriate queues.
• Stores a copy to disk for historical queries.
• Performs data filtering, which it can sometimes offload to the
sensors.

IV-80
 Building a Fjord

• For all sensor data sources, locate the proxy for the
sensor, and install a query on it to deliver tuples at a
certain rate to a push queue.
• For non-sensor data sources, set up a pull queue to
scan for data.
• Pipe the data through the operators specified by the
query.

IV-81

Query

• Find average car speeds during time window (w), for all
segments the user is interested in (knownSegments)
• More complicated queries are possible, with joins of streaming
sensor data and historical data stored in a normal database
fashion.

IV-82
 Dataflow for the Query

• Data is pushed from the sensors to the user, through the filter
operator set up by the query.
• Multiple similar queries can be added to an existing fjord,
instead of creating one per query.

IV-83

Conclusion

• Fjords allow sensors to be treated as database sources for

querying, with little change in the overall architecture.
• Proxies can optimize energy consumption of individual sensors
based on user queries, and multiplex data from sensors to
multiple queries.
• Processing is centralized, but can sometimes be offloaded to
the sensors, to lower energy consumed by radio transmissions.

IV-84
 The Sylph Middleware

• Database mechanisms packaged as middleware

services
• Modular, Layered Design
– Sensor module
– Service discovery module
– Proxy core
• Query Language
READ temperature EVERY 30 seconds FOR 1 hour
• Sensor Stream Processing

IV-85

IV-86
 Sensor Module

• Strong Abstraction Barrier

• Sensor Description
– Derived from IEEE 1451 Transducer Electronic Data Sheet
(TEDS)
– Metadata - name, manufacturer, etc.
– Attributes - device status, sampling interval, etc.
– Data – available data, return types
• Attribute-Value Interface
– SET SamplingPeriod = 1 second
– GET DeviceStatus

IV-87

Service Discovery Module

• Device Proxy
• Common Service Discovery Mechanisms (e.g., Jini)
• Soft-State Reliability

IV-88
 Proxy Core

• Device Manager
• Sensor Proxy
– Service discovery
– Layered functionality (e.g., buffering)
• Query Processor
– Query parsing
– Directed graph of stream operators
– Query optimization
• Query Distribution - Gateways

IV-89

Accommodating in-network Aggregation

• Fjords and Sylph did not explicitly address in-network

aggregation/processing

• “Supporting Aggregate Queries Over Ad-Hoc Wireless Sensor

Networks” (Madden et al. 2002)
• Explores aggregation techniques that are application
independent
• Count
• Min
• Max
• Sum
• Average

IV-90
 At A Glance …

• Trying to minimize the

number of messages sent
• All aggregation is done by
building a tree

IV-91

Tricks of the Trade …

• How do you ensure an aggregate is correct?

– Compute it multiple times.
• How do you reduce the message overhead of redistributing queries?
– Piggy back the query along with data messages.
• Is there anyway to further reduce the messaging overhead?
– Child nodes only report their aggregates if they’ve changed.
• Nodes can take advantage of multiple parents for redundancy reasons.

IV-92
 The Tiny Aggregation (TAG) Approach
(S. Madden, UCB)

• Push declarative queries into network

– Impose a hierarchical routing tree onto the network
• Divide time into epochs
• Every epoch, sensors evaluate query over local
sensor data and data from children
– Aggregate local and child data
– Each node transmits just once per epoch
– Pipelined approach increases throughput
• Depending on aggregate function, various
optimizations can be applied

IV-93

SQL Primer SELECT AVG(light)

(Madden) FROM sensors
WHERE sound < 100
GROUP BY roomNo
HAVING AVG(light) < 50
• SQL is an established declarative language; not wedded to it
– Some extensions clearly necessary, e.g. for sample rates
• We adopt a basic subset:

SELECT {aggn(attrn), attrs}

FROM sensors
WHERE {selPreds}
GROUP BY {attrs}
HAVING {havingPreds}
EPOCH DURATION s

• ‘sensors’ relation (table) has

– One column for each reading-type, or attribute
– One row for each externalized value
• May represent an aggregation of several individual readings

IV-94
 Aggregation Functions
(Madden)

• Standard SQL supports “the basic 5”:

– MIN, MAX, SUM, AVERAGE, and COUNT
• We support any function conforming to:

Aggn={fmerge, finit, fevaluate}

Fmerge{<a1>,<a2>} → <a12>
finit{a0} → <a0>
Partial Aggregate
Fevaluate{<a1>} → aggregate value
(Merge associative, commutative!)

Example: Average
AVGmerge {<S1, C1>, <S2, C2>} → < S1 + S2 , C1 + C2>
AVGinit{v} → <v,1>
AVGevaluate{<S1, C1>} → S1/C1
IV-95

Query Propagation
(Madden)

• TAG propagation agnostic

– Any algorithm that can:
• Deliver the query to all sensors Query
• Provide all sensors with one or
more duplicate free routes to some
root 1 P:0, L:1
• Paper describes simple flooding
approach
– Query introduced at a root; 2 P:1, L:2 3 P:1, L:2

rebroadcast by all sensors until it

reaches leaves
– Sensors pick parent and level when 4 P:2, L:3
they hear query
– Reselect parent after k silent epochs 6 P:3, L:3
5
P:4, L:4
IV-96
 TAG Discussion
(Madden)

• Result is a stream of values 1

– Ideal for monitoring scenarios
2 3
• One communication / node / epoch
– Symmetric power consumption, even at root 4
• New value on every epoch
– After d-1 epochs, complete aggregation
5
• Given a single loss, network will recover after at most d-1
epochs
• With time synchronization, nodes can sleep between epochs,
except during small communication window

IV-97

Simulation Result
(Madden, OSDI ‘02)

Simulation Results Total Bytes Xmitted vs. Aggregation Function

2500 Nodes
50x50 Grid 100000
Depth = ~10 90000

Some aggregates
Neighbors = ~20 80000
Total B y tes Xm itte d

70000
60000 require dramatically
50000 more state!
40000
30000
20000
10000
0
EXTERNAL MAX AVERAGE COUNT MEDIAN
Aggregation Function
IV-98
 Taxonomy of Aggregates
(Madden)

• TAG insight: classifying aggregates according to

various functional properties
– Yields a general set of optimizations that can
automatically be applied

Property Examples Affects

Partial State MEDIAN : unbounded, Effectiveness of TAG

MAX : 1 record
Duplicate Sensitivity MIN : dup. insensitive, Routing Redundancy
AVG : dup. sensitive
Exemplary vs. Summary MAX : exemplary Applicability of Sampling, Effect of
COUNT: summary Loss
Monotonic COUNT : monotonic Hypothesis Testing, Snooping
AVG : non-monotonic

IV-99

SensorWare: a Sensor Middleware for

Distributed Applications
(Srivastava et al 2002)

• Current approaches: sensor nodes viewed as tiny database servers

– a user query is answered by aggregating results
– forms of queries:
• Do you currently see X?
• Did you see X in the past timer T?
• Inform me when you see X.
• Tell me periodically what you see.

• Problem: remote user in the interactive loop

– leads to higher latency for tracking
– also, excessive traffic and therefore wasted energy

• Mobile scripts naturally result in an information-driven strategy

IV-100
 SensorWare

• Mobile scripts (agents) injected as queries & tasks for

application-defined processing at the nodes
– replicate and migrate according to application logic and the state of
the physical world
– executed in a sand-box at each node
• Suite of core services for sensing, processing, communication,
and actuation available at each node
• Features
– Scripts use application-specific dissemination strategies layered on
top of a thin and simple protocol stack
• no one routing hard coded
– Autonomous coordination in the sensor network
• Avoids the “user-in-the-loop” model inherent in the usual database
query-response model
– Task centric programming model
• Avoids thinking in terms of individual nodes

IV-101

SensorWare Architecture
External user can Message
inject agent script exchanging

Apps, Scripts Scripts Apps,

Services Services
Script
Middleware migration Middleware

OS OS

Node 1 HW abstraction HW abstraction Node 2

layer layer
Hardware Hardware
Middleware

Runtime environment APIs

interpreter Mobility Sensing Networking

Script State
keeping Resource handling tasks
Sensor Timers &
Energy-based Admission control Networking
& resource management Abstraction CPU control
IV-102
 Implementation on iPaq-based Sensor
Nodes & Sensoria WINS

Magnetic Sensor
WaveLan Card - uC Based with RS232
-IEEE 802.11b Compliant - Range of +/- 2Gausus
- 11 Mbit/s Data Rate -Adjustable Sampling Rate
- X, Y, Z output
- Device ID Management

Familiar v0.5 iPAQ 3670

- Linux Based OS for iPAQ H3600s -Intel StrongARM
- JFFS2, read/write iPAQ’s flush - Power Management (normal,
- Tcl ported idle & sleep mode)
- Programmable System Clock
- IR, USB, Serial (RS232)
Transmission

IV-103

System Operation Overview

User Node

Script Migration

Script Code injecting

Script Migration

Mobile Script
- Light weight
- Programmable
Script Migration - Code Mobility
- Tcl front end

IV-104
 Event-driven Model

• Agents express the event they are interested in

• Sensor event
– event -data <name> -sample_period <value>
{-buffer_size <value>}
{-wakeup_period <value>}
{-threshold <value>}
• Timer event
– event -timer <name><value>
• Network event
– event -net <name> <start> <reg exp>
– agent can generate network event
• Timer and data event generated by the system
• send <node.user.family.instance> <msg>
• wait {-net <events> ...} {-data <events> ...} {-timer <events> ...}

IV-105

Mobile Script Model

• spawn <node> [-s|<code>]

{<bind> ...}
• Binding variables
– Pass-by-name
– Encourage agent reusability
– Support agent modulation
• Embedded Agents
– Agents that are being carried by other ones
– Two methods
• Static
– Prone to errors
– Cannot reuse: Mission specific
– High memory usage: Carrier has to stay alive!
• Dynamic
– High modulation

IV-106
 Tracking: Mobile Script Flooding

User Node

“Tracking Script
Code” injecting

Sensor Node

Monitoring
Target

Video IV-107
Node

Tracking: Event Sensing

User Node
Event Sensing

Event Sensing

Event Sensing
Event Sensing

Event Sensing
Event Sensing
Sensor Node

Event Sensing

Event Sensing Monitoring

Target

Video IV-108
Node
 Tracking: Mobile Script Activation

User Node

Tracking Code
Activated

Tracking
Code
Activated
Target
Sensor Node

Video IV-109
Node

Tracking: Position Notification and Code

Migration

User Node

Tracking
Script Migration

Tracking
Target Position Information
Sensor Node
Script Migration

Monitoring

Position Information

Video IV-110
Node
 Tracking: Position Notification

User Node

Tracking

Tracking
Script Migration
Target

Sensor Node

Tracking Monitoring
Script Migration

Position Information

Video IV-111
Node

Making this work on much smaller nodes

• UCB Mate project (Levis et al

2002) Network Programming Rate

– Stack-based bytecode interpreter 100%

– Self-forwarding code 80%
Programmed
Percent

60%
– Rapid reprogramming 40%
– Message receive and send 20%
contexts 0%
0 20 40 60 80 100 120 140 160 180 200 220 240

– TinyOS component, 7286 bytes Tim e (seconds)

code, 603 bytes RAM, three

concurrent execution contexts,
Code broken into 24 instruction
capsules

IV-112
 Moving Forward:
Storage, Representation, Distributed processing
• Spatio-temporal Queries
– Index data for easy temporal and spatial
searching
K V K V • Interpretation of Spatially Distributed Data
K V – Provide ability to interpret data at different spatial
K V
K V and temporal extents. Per-node processing
K V K V
alone is not enough
K V
K V
• Pattern-Triggered Data Collection
K V
K V
– Should enable multi-resolution data storage and
retrieval for data collection.
• Data Centric Protocols and In network
Processing
– Network does in-network processing of data
based on distribution of data
– When data changes, portion of the network
updates understanding of the data
– When user queries, it travels to node that
maintains relevant summarized data
IV-113

How should nodes summarize data?

(Bien et al)
Number of Nodes with

• Histograms are a useful way to

Value

summarize data
• Queries for statistics
Sensor Value
• Show degree of data
variation in an area
• Queries for maps
• Geographically show data
variation
Sensor Value

• Provide approximation of
map
ion
cat
Lo
Y

X Location

IV-114
 DIMENSIONSTM: A Multi-Resolution Storage
Architectures for Sensor Networks (Ganesan et al)

n Per-Node Temporal Data Processing

n Progressive encoding : more lossy
storage of older data
increasing n Design Principle: System
spatial
guarantees lossless multi-resolution
resolution
data collection within time T of
event occurrence. Older data is
stored ONLY for long-term query
processing, which can tolerate
greater loss
n Spatial Data Processing
n Nodes in the network form a logical
spatial hiearchy.
increasing n At each step of the hierarchy,
temporal
Time

further summarization of the data

resolution
takes place.

IV-115

Spatial Data Processing

Get coefficients from Huffman

level l-1 cluster-heads Encoding
2D Wavelet Deltas
Transform on Local
Tile Storage
Send coefficients to Huffman
level l+1 cluster-heads Decoding

• For level=1 to N
– Cluster-Heads (i-1) send data to Cluster-Head (i)
– ClusterHead(i) aggregates data from 4 lower level clusterheads,
locally stores the deltas, and sends resulting coefficients to
ClusterHead(i+1)
• To a first order approximation, size of coefficients transmitted at each
level is constant.

IV-116
 Content Addressable Storage
…aka Data Centric Storage
(Ramiswamy et al)

• Queries for some

things (like local
maxima) are not
necessarily spatially
correlated.
• Sensor networks
require a storage
scheme that indexes
on semantics as well
as on the location of
data.

IV-117

The Semantic Hierarchy

(Greenstein et al)
1 < Temperature ≤ 8
• The wider the
4 < Temperature ≤ 8 geographical extent a
node indexes, the
more data there is to
index.
• Given that each node
has limited storage,
tighter semantic
constraints must be
used for nodes that
index wider areas.
7 < Temperature ≤ 8

8 < Temperature ≤ 8

IV-118
 Index Construction
Indexes contain histograms summarizing
1 < Temperature ≤ 8
events within their value and spatial ranges 4 < Temperature ≤ 8

Event
Attributes 7 < Temperature ≤ 8

Name = EventLongitude
Value = 120
8 < Temperature ≤ 8

Attributes Coordinates
(120, 171)
Name = EventLatitude (0111 1000, 1010 1011)
Value = 171

Hash String
Attribute
Name = Temperature “Temperature 1 8”
Hash Coordinates
(121, 169)
Value = 8
Min = 1
Level
Function (0111 1001, 1010 1001)

Max = 8
Distribution = Uniform 1 of 4

IV-119

4 < Temperature ≤ 8
1 < Temperature ≤ 8
Search
• Search most constrained index nodes
for region of interest
• Search travels from constrained
semantics to constrained geography
7 < Temperature ≤ 8
(location of an event)
8 < Temperature ≤ 8
• Distributions are generated as part of
the index construction
Node Histogram Node Histogram Node Histogram
< 8 -- 752 < 7 -- 700 < 5 -- 400
> 8 -- 0 > 8 -- 0 > 8 -- 0

Region 00
Region 00 Region 00 Region 00
7 52
80
82 5 -- 100 5 -- 30
6 -- 80 6 -- 20
Region 01 7 -- 26 7 -- 13
Region 01 8 -- 1 8 -- 1
7 12
80
80 etc.
Region 10
Region 10 Region 10
7 15 Region 10
82
80 5 -- 20 5 --15
6 -- 20 6 -- 15
Region 11 7 -- 9 7 -- 4
Region 11 8 -- 0 8 -- 1
70
80
80

Level 4 Level 3 Level 2

IV-120