mobicom tutorial 4 de

8/14/2019 Mobicom Tutorial 4 De

1/60

IV-1

Part IV: Sensor Network Protocols

Deborah Estrin

IV-2

Wireless Sensor Network Protocols

Primary theme: building long-

lived, massively-distributed,

physically-coupled systems:

Coordinating to minimize

duty cycle and

communication

Adaptive MAC

Adaptive Topology

Routing

In-network processing

Data centric routing

Programming models

In-network: Application processing,Aggregation, Query processing

Adaptive topology, Geo-Routing

MAC, Time, Location

Phy: comm, sensing, actuation, SP

User Queries, External Database

Data dissemination, storage, caching


2/60

IV-3

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. Throughput7. Bandwidth utilization

IV-4

Major sources of energy waste

Idle listening when no sensing events, Collisions,Control overhead, Overhearing

MAC Impact on Sensor Networks(Intanago et al, 2000)

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0 50 100 150 200 250 300

AverageDissipatedE

nergy

(Joules/Node/Receive

dEvent)

Network Size

DiffusionDiffusion

Omniscient MulticastOmniscient MulticastFloodingFlooding

0

0.002

0.004

0.006

0.008

0.01

0.0120.014

0.016

0.018

0 50 100 150 200 250 300

AverageDissipated

Energy

(Joules/Node/Receive

dEvent)

Network Size

DiffusionDiffusion

Omniscient MulticastOmniscient Multicast

FloodingFlooding

Over 802.11-like MAC Over energy-aware MAC


3/60

IV-5

Identifying the Energy Consumers

Need to shutdown the radio

From Tsiatis et al. 2002

SENSORS

Power consumption of node subsystems

0

5

10

15

20

Power(mW)

CPU TX RX IDLE SLEEP

RADIO

SLEEPIDLERXTX EEEE >>

IV-6

Major sources of energy waste

Idle listening

Long idle time when no sensing event happens

Collisions

Control overhead

Overhearing Try to reduce energy consumption from all above

sources

TDMA requires slot allocation and time synchronization

Combine benefits of TDMA + contention protocols

Energy Efficiency in MAC

Common to all

wireless networks


4/60

IV-7

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

Tradeoffs

Major components of S-MAC

Periodic listen and sleep

Collision avoidance

Overhearing avoidance

Message passing

Latency

FairnessEnergy

IV-8

Periodic Listen and Sleep

Problem: Idle listening consumes significant energy

Nodes do not sleep in IEEE 802.11 ad hoc mode

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

sleeplisten listen sleep


5/60

IV-9


Schedules can differ

Preferable ifneighboring nodes have same schedule

easy broadcast & low control overhead

Border nodes:two schedulesbroadcast twice

Node 1

Node 2



Schedule 2

Schedule 1

IV-10


Schedule maintenance

Remember neighbors schedules

to know when to send to them

Each node broadcasts its schedule every few periods

Refresh on neighbors schedule when receiving anupdate

Schedule packets also serve as beacons for newnodes to join a neighborhood


6/60

IV-11

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-12

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 thesleep interval


7/60

IV-13

Message Passing

Problem: In-network processing requiresentiremessage

Solution: Dont 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

FairnessEnergyMsg-level latency

IV-14

Msg Passing vs. 802.11 fragmentation

Time reservation by durationfield

If ACK is not received, give up Tx fairness

No indication of entire time other nodes keep listening

RTS 21 ...

...

Data 19

ACK 18CTS 20

Data 17

ACK 16

Data 1

ACK 0

MP

RTS 3 ...

...

Data 3

ACK 2CTS 2

Data 3

ACK 2

Data 1

ACK 0

802.11


8/60

IV-15

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 embeddedPCs

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-16

S-MAC Experimental results(implemented on UCB Mote over RFM radio)

Topology and measured energy consumption onsource nodes

Source 1

Source 2

Sink 1

Sink 2

Each source node sends10 messages

Each message has 10fragments x 40B

Measure total energy

Data + control + idle0 2 4 6 8 10

200

400

600

800

1000

1200

1400

1600

1800Average energy consumption in the source nodes

Message inter-arrival period (second)

Energyconsu

mption(mJ)

802.11-like protocolOverhearing avoidanceS-MAC

Message Inter-arrival period

Energy consumed


9/60

IV-17

Adaptive Topology

Can we do more than shut down radio in betweentransmissions/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 environmentwithout manual configuration

IV-18

Adaptive Topology: Problem Description

Simple Formulation (Geometric Disk Covering)

Given a distribution of Nnodes in a plane. Place a minimumnumber of disks of radius r(centered on

the nodes) to cover them.

Disk represents the radio connectivity (simplecircle model). The problem is NP-hard.


10/60

IV-19

Connectivity Measurements*

Packet reception over distance has a heavy tail. There is a non-zeroprobability of receiving packets at distances much greaterthan the average cell range

169 motes, 13x13 grid, 2 ft spacing, open area, RFM radio,simple CSMA

Cant just

determine

connectivity

clusters thru

geographic

coordinates

For the same

reason you cant

determine

coordinatesw/connectivity

*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-20

Tradeoff How many nodes to activate?

fewactive nodes:

distance between neighboring nodes high -> increase packet lossandhigher transmit power and reduced spatial reuse;

need to maintain sensing coverage (see earlier session oncoverage/exposure)

too manyactive nodes: at best, expending unnecessary energy; at worst nodes may interferewith one another by congestingthe

channel.


11/60

IV-21

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 redundantlinks, SPAN (Chen et al. 2001), GAF (Xu et al. 2001)

Data/traffic driven: Trigger nodes on demand using pagingchannel, STEM (Tsiatsis et al. 2002)

IV-22

One example algorithm: ASCENT

The nodes can be in activeor passivestate.

Active nodes forward data packets (using routingmechanism that runs over topology).

Passive nodes do notforward any packets but may sleep orcollect network measurements.

Each nodejoinsnetwork topology or sleepsaccording tomeasured number of neighbors and packet loss, asmeasured locally.

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

Help

MessagesData Message

SinkSource SinkSource

Neighbor

Announcements

MessagesData

Message

SinkSource

Active NeighborPassive Neighbor


12/60

IV-23

State Transitions

Test

Passive Sleep

Active

after Tt

after Tp

after Ts

neighbors < NT

and

loss > LT

loss < LT & help

neighbors > NT (high ID for ties);

or

loss > loss T0

NT: neighbor threshold

LT: loss threshold

T?: state timer values (p: passive, s: sleep, t: test)

IV-24

Testbed Platforms

Tiered architecture: heterogeneous set of platforms (no particularset of compromises with a unique platform).

PC-104/iPAQ enable running tasks that are more CPU/memoryintensive.

iPAQ UCB Mote

Simulator:

Discrete event-driven simulator.

Multiple stackable modules perform different functionality.

PC-104/RPC


13/60

IV-25

Energy Savings Ratio

Energy Savings Ratio (normalized to the Active case, all nodes turn on) as a

function of density. ASCENTprovides significant amount ofenergy savings,

with afactor of 5 for high density scenarios.

IV-26

Event Delivery Ratio

Event Delivery Ratio as a function of density. ASCENT reducescollisions experienced bydiffusion 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?


14/60

IV-27

radio supports promiscuousmode

noneadapt topology based onapplication needs

ASCENT

2 radios/wake-up channel

connectivity conditions

remain constant in sleeping

periods

needs routing info to direct thewake-up wave

tradeoff latency forenergy savings

STEM

802.11 MAC with Power

Savings mode

gets connectivity matrix and

neighbors from routing

requires modifications in the

routing lookup process

preserve capacity of the

raw topologySPAN

geographic information forgrid placement

radio connectivity directly

correlated with geography

nonepreserve routing fidelityGAF

AssumptionsRouting

dependency

Goal

(general: energysavings)

IV-28

STEM: Data drive wakeup(Tsiatsis et. al 2002)

Sensor-triggered node wakeup

Wake up the nodes along the path

HOW ???

event

sensor network

user

Zzz

Path nodes need to be woken up

Zzz ZzzZzz


15/60

IV-29

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 interferencewith regular data forwarding

Trades off energy savings for path setup latency

Wakeup plane: f1

Data plane: f2

STEM: Sparse Topology and Energy Management

IV-30

Duty Cycled Wakeup Radio

f1

f1

Target node

Initiator node

Train of beacon packets

TRx

B1B2 1. beacon received

2. beacon acknowledge

T


16/60

IV-31

Performance Metrics

(sec)ST

(sec)T (sec)T

0

EE

IV-32

Energy vs Latency

%50

%10

%1

%1.0

0E

E

(sec)ST


17/60

IV-33

STEM Design Decisions

One radio with onefrequency band would cause interferencebetween the wakeup and data planes

One radio with twofrequencies would have to changefrequency to listen for setup requests

One radio with time multiplexed wake-up and data planeswould 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 thenode (from private communication with Savvides)

Active mode

Polling mode

Sleep mode

Interference

A B

C

D

IV-34

Design Issue: Collision Resolution

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 doesnt receive data, it

times out and goes back to sleep

1 initiator node

beacon received correctly

only intended receiver turns on the data

radio and sends a beacon acknowledge

in the wakeup plane


18/60

IV-35

Exploiting Latency AND Density

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

density

Combine STEM and one of these schemes (chosen GAF)

Zzz

Active nodes

Zzz

Zzz

Zzz

STEM

IV-36

Performance of STEM+GAF

GAF

STEM + GAF

STEM

alone

avg # of neighbors

0E

E

msTS 900=

msTS 675=

msTS 400=


19/60

IV-37

Conclusions

STEM leverages data latency for energy savings

Combining existing algorithms that leverage densityand STEM yields additional energy savings

Provide with design time tools for extending thelifetime of the network

IV-38

Adaptive Topology: Future Work

Load Balancing.

Larger scale experiments.

Interaction with adaptive MAC and geographicrouting

Application defined Adaptive Fidelity

Expanding on STEMs data driven characteristics to

achieve more than on/off behavior


20/60


21/60

IV-41

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-42

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.


22/60

IV-43

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-44

Data Dissemination Example

Assume hop count was used

as a cost metric.

Node A is the sink.

Node C is the source.


23/60

IV-45

Data Dissemination Example contd.

Node C sends a data

message which specifies

Total Budget = 2

Budget Spent = 1

Node E drops message

TB < BS + Es Cost

Node B forwards message.

IV-46

Routing on a Curve(Nath et al 2002)

Trajectories are a natural name space for embeddednetworks

By definition, network structure mimics physicalstructure that is instrumented

Stress along a column

Flooding along a river

Pollution along a road

Trajectories come from the application domain


24/60

IV-47

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-48

Specifying trajectory

Function

Equation

Parametric

we use this choice

xybaxy sin, =+=

1,1 22 ++=++ yxcbyax trytrxbatytx cos,sin;, ==+==


25/60

IV-49

Features of TBF

Basic Features

Decouples pathname from the actual path

Source based Routing (LSR, DSR etc) mixesnaming 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-50

Routing on a curve


26/60

IV-51

Spoke flooding

IV-52

Flooding along spokes

01020

304050

60708090

100

4 9

Number of Spokes

Coverage

Packets


27/60

IV-53

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-54

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 andaccuracy


28/60


29/60

IV-57

Diffusion as a construct forin-network processing

Nodes pull, push, and store named data (using tuple space) to createefficient processing points in the network

e.g. duplicate suppression, aggregation, correlation

Nested queries reduce overhead relative to edge processing

Complex queries supportcollaborative signalprocessing

propagate functiondescribing desiredlocations/nodes/data(e.g. ellipse for tracking)

Interesting analogs to emergingpeer-to-peer architectures

Build on a data-centric architecturefor queries and storage

IV-58

Nested Query Evaluation

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

Nested queries greatlyimprove event delivery rate

Specific results depend onexperiment

placement

limited quality MAC General result: app-level

info needed in sensor nets;diffusion is good platform ev

entssuccessfullyreceived(%)

number of light sensors

flat

nested

60

1 2 3 4

80

40

20


30/60

IV-59

A more general look atA more general look at

Data Centric vs. Address CentricData Centric vs. Address Centric

approachapproach((KrishnamachariKrishnamachari et al.)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 generalgraph if k nodes are sources and one is asink, the aggregation tree that minimizes the number of transmissions is theminimum Steiner tree. NP-complete.Approximations:

Center at Nearest Source (CNSDC): All sources send through sourcenearest to the sink. Shortest Path Tree (SPTDC): Merge paths. Greedy Incremental Tree (GITDC): Start with path from sink to nearestsource. Successively add next nearest source to the existing tree.

IV-60

Source placement: eventSource placement: event--radius modelradius model


31/60

IV-61

Comparison of energy costsComparison of energy costs

Address CentricShortest path data centricGreedy tree data centricNearest source data centricLower Bound

Data centric has many fewer transmissions thandoes Address Centric; independent on the treebuilding algorithm.

Opportunism always pays;Greed pays only when things get very crowded

(Intanagowiwat et al. ns-2 more detailed simulations)


32/60

IV-63

Programming Paradigm

Move beyond simple query with in-network aggregation model

How do we task a 1000+ node dynamic sensor network toconduct complex, long-lived queries and tasks ??

What constructs does the query language need to support?

What sorts of mechanisms need to be running in thebackground in order to make tasking efficient?

Small databases scattered throughout the network, activelycollecting data of nearby nodes, as well as acceptingmessages from further away nodes?

Active messages traveling the network to both train thenetwork and identify anomalous conditions?

IV-64

Examples Map isotherms and other contours, gradients, regions

Record images wherever acoustic signatures indicate significantlyabove-average species activity, and return with data on soil and airtemperature and chemistry in vicinity of activity.

Mobilize robotic sample collector to region where soil chemistry andair chemistry have followed a particular temporal pattern and wherethe 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 distributedmanner?

Similar to some vision/image analysis problems but distributednoisy inputs


33/60

IV-65

Why databases?

Sensor networks are capable of producing massive amounts ofdata

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-66

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.

Database-centric Approach(Muntz et al.)


34/60

IV-67

Differences between databases and sensornetworks

Database

Static data

Centralized

Failure is not an option

Plentiful resources

Administrated

Sensor Network

Streaming data

Large number of nodes

Multi-hop network

No global knowledge aboutthe network

Frequent node failure

Energy is the scarce

Resource, limited memory

Autonomous

IV-68

Bridging the Gap

What is needed to be able to treat a sensor networklike a database?

How should sensors be modeled?

How should queries be formulated?


35/60

IV-69

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-70

What Wed Like to Do:

Sensor Database System

Sensor Database System supports distributed query processing

over a sensor network

Sensor

DB

Sensor

DB

Sensor

DB

Sensor

DB Sensor

DB

Sensor

DB

Sensor

DB

Sensor

DB

Front-end

Sensor Nodes


36/60

IV-71

Sensor Database System

Characteristics of a SensorNetwork:

Streams of data

Uncertain data

Large number of nodes

Multi-hop network

No global knowledgeabout the network

Node failure andinterference is common

Energy is the scarceresource

Lmited memory

No administration,

Can existing databasetechniques be reused?

What are the new problems andsolutions?

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-72

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 isreturned

Limited resource usage

Energy consumption


37/60

IV-73

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-74

Early Work in Sensor Databases

Towards Sensor Database System

Querying the Physical World

Phillipe Bonnet, Johannes Gehrke, Praveen Seshdri


38/60

IV-75

Fjording the Stream: An Architecture for Queriesover 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-76

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.


39/60

IV-77

Hardware Architecture

Centralized dataprocessing.

Sensor proxies read andconfigure sensors.

Query processor interactswith proxies to request andget sensor data.

Sensor proxies supportmultiple simultaneousqueries, multiplexing thedata.

IV-78

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.


40/60

IV-79

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-80

Sensor Proxy

Responsible for configuring sensor that belong to it, settingsensing frequency, aggregation policies, etc..

To save power, each sensor only listens for commands fromproxy during short intervals.

Handles incoming data from sensors, and pushes it intoappropriate queues.

Stores a copy to disk for historical queries. Performs data filtering, which it can sometimes offload to the

sensors.


41/60

IV-81

Building a Fjord

For all sensor data sources, locate the proxy for thesensor, and install a query on it to deliver tuples at acertain rate to a push queue.

For non-sensor data sources, set up a pull queue toscan for data.

Pipe the data through the operators specified by thequery.

IV-82

Query

Find average car speeds during time window (w), for allsegments the user is interested in (knownSegments)

More complicated queries are possible, with joins of streamingsensor data and historical data stored in a normal databasefashion.


42/60


43/60

IV-85

The Sylph Middleware

Database mechanisms packaged as middlewareservices

Modular, Layered Design

Sensor module

Service discovery module

Proxy core

Query LanguageREAD temperature EVERY 30 seconds FOR 1 hour

Sensor Stream Processing

IV-86


44/60

IV-87

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-88

Service Discovery Module

Device Proxy

Common Service Discovery Mechanisms (e.g., Jini)

Soft-State Reliability


45/60

IV-89

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-90

Accommodating in-network Aggregation

Fjords and Sylph did not explicitly address in-networkaggregation/processing

Supporting Aggregate Queries Over Ad-Hoc Wireless SensorNetworks (Madden et al. 2002)

Explores aggregation techniques that are application

independent Count

Min

Max

Sum

Average


46/60

IV-91

At A Glance

Trying to minimize the

number of messages sent

All aggregation is done by

building a tree

IV-92

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 theyve changed.

Nodes can take advantage of multiple parents for redundancy reasons.


47/60

IV-93

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

Aggregatelocal and child data

Each node transmits just once per epoch

Pipelined approach increases throughput

Depending on aggregate function, various

optimizations can be applied

IV-94

SQL Primer

(Madden)

SQL is an established declarative language; not wedded to it

Some extensions clearly necessary, e.g. for sample rates

We adopt a basic subset:

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

SELECT {aggn(a t t r n) , a t t rs}

FROM sensors

WHERE {selPreds}

GROUP BY {att rs}HAVING {havingPreds}EPOCH DURAT ION s

SELECT AVG(light)FROM sensorsWHERE sound < 1 00GROUP BY roomNoHAVING AVG(light) < 50


48/60

IV-95

Aggregation Functions(Madden)

Standard SQL supports the basic 5:

MIN, MAX, SUM, AVERAGE, and COUNT

We support any function conforming to:

Aggn={fmerge, fin i t , fevaluate}

Fmerge{< a1>,}

fin i t{a 0}

Fevaluate{< a1>} aggregate value

(Merge assoc ia t i ve , com mut a t i ve !)

Example: Average

AVGmerge {< S1, C1>, } < S1 + S2 , C1 + C2>

AVG in i t{v }

AVGevaluate{< S1, C1>} S1/C1

Partial Aggregate

IV-96

Query Propagation

(Madden)

TAG propagation agnostic

Any algorithm that can:

Deliver the query to all sensors

Provide all sensors with one ormore duplicate free routes to someroot

Paper describes simple flooding

approach Query introduced at a root;

rebroadcast by all sensors until itreaches leaves

Sensors pick parent and level whenthey hear query

Reselect parent after k silent epochs

Query

P:0, L:1

2

1

5

3

4

6

P:1, L:2 P:1, L:2

P:3, L:3

P:2, L:3

P:4, L:4


49/60

IV-97

TAG Discussion(Madden)

Result is a stream of values

Ideal for monitoring scenarios

One communication / node / epoch

Symmetric power consumption, even at root

New value on every epoch

After d-1 epochs, complete aggregation

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

1

2 3

4

5

IV-98

Simulation Result

(Madden, OSDI 02)

To ta l By tes Xmi t ted vs . Aggrega t ion Func t i on

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

EXTERNAL MAX AVERAGE COUNT MEDIAN

Aggregation Function

TotalBytesXm

itted

Simulation Results

2500 Nodes

50x50 Grid

Depth = ~10

Neighbors = ~20Some aggregates

require dramaticallymore state!


50/60

IV-99

Taxonomy of Aggregates(Madden)

TAG insight: classifying aggregates according tovarious functional properties

Yields a general set of optimizations that canautomatically be applied

Hypothesis Testing, SnoopingCOUNT : monotonicAVG : non-monotonic

Monotonic

Applicability of Sampling, Effect ofLoss

MAX : exemplary

COUNT: summary

Exemplary vs. Summary

Routing RedundancyMIN : dup. insensitive,

AVG : dup. sensitive

Duplicate Sensitivity

Effectiveness of TAGMEDIAN : unbounded,MAX : 1 record

Partial State

AffectsExamplesProperty

IV-100

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


51/60

IV-101

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 ofthe 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 databasequery-response model

Task centric programming model

Avoids thinking in terms of individual nodes

IV-102

SensorWare Architecture

Middleware

OS

Hardware

HW abstraction

layer

Scripts Apps,

Services

Script

migration

Node 2

Middleware

OS

Hardware

HW abstraction

layer

ScriptsApps,

Services

Message

exchangingExternal user can

inject agent script

Node 1

Middleware

APIsRuntime environment

Mobility NetworkingSensinginterpreter

Script State

keeping

Energy-based Admission control

& resource managementNetworking

Sensor

Abstraction

Timers &

CPU control

Resource handling tasks


52/60


53/60


54/60

IV-107

Tracking: Mobile Script Flooding

Sensor Node

User Node

Video Node

MonitoringTarget

Tracking ScriptCode injecting

IV-108

Tracking: Event Sensing

Sensor Node

User Node

Video Node

MonitoringTarget

Event Sensing

Event Sensing

Event Sensing

Event Sensing

Event Sensing

Event Sensing

Event Sensing

Event Sensing


55/60

IV-109

Tracking: Mobile Script Activation

Tracking CodeActivated

Sensor Node

User Node

Video Node

Target

TrackingCodeActivated

IV-110

Tracking: Position Notification and Code

Migration

Position InformationTracking

Sensor Node

User Node

Video Node

Target

Position Information

TrackingScript Migration

Script Migration

Monitoring


56/60

IV-111

Tracking: Position Notification

Tracking

Sensor Node

User Node

Video Node

Target

Position Information

TrackingScript Migration

Script MigrationMonitoring

Tracking

IV-112

Making this work on much smaller nodes

UCB Mate project (Levis et al2002)

Stack-based bytecode interpreter

Self-forwarding code

Rapid reprogramming

Message receive and send

contexts

TinyOS component, 7286 bytescode, 603 bytes RAM, three

concurrent execution contexts,

Code broken into 24 instruction

capsules

Network Programming Rate

0%

20%

40%

60%

80%

100%

0 2 0 4 0 6 0 8 0 1 00 12 0 14 0 1 60 18 0 2 00 2 2 0 2 40

Time (seconds)

Percent

Programmed


57/60

IV-113

Moving Forward:Storage, Representation, Distributed processing

Spatio-temporal Queries

Index data for easy temporal and spatial

searching

Interpretation of Spatially Distributed Data

Provide ability to interpret data at different spatial

and temporal extents. Per-node processing

alone is not enough

Pattern-Triggered Data Collection

Should enable multi-resolution data storage and

retrieval for data collection.

Data Centric Protocols and In networkProcessing

Network does in-network processing of databased on distribution of data

When data changes, portion of the networkupdates understanding of the data

When user queries, it travels to node thatmaintains relevant summarized data

K V

K V

K V

K V

K V

K V

K VK V

K V

K V

K V

IV-114

How should nodes summarize data?(Bien et al)

Histograms are a useful way tosummarize data

Queries for statistics

Show degreeof datavariation in an area

Queries for maps Geographicallyshow data

variation

Provide approximation ofmap

Sensor ValueNumberofNodeswith

Value

YLocatio

n

XLocation

SensorValue


58/60

IV-115

DIMENSIONSTM: A Multi-Resolution StorageArchitectures for Sensor Networks (Ganesan et al)

increasingspatial

resolution

increasingtemporalresolutionT

ime

n Per-Node Temporal Data Processing

n Progressive encoding : more lossystorage of older data

n Design Principle: Systemguarantees lossless multi-resolutiondata collection within time T ofevent occurrence. Older data isstored ONLY for long-term queryprocessing, which can tolerategreater loss

n Spatial Data Processing

n Nodes in the network form a logical

spatial hiearchy.n At each step of the hierarchy,

further summarization of the datatakes place.

IV-116

Spatial Data Processing

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 toClusterHead(i+1)

To a first order approximation, size of coefficients transmitted at eachlevel is constant.

LocalStorage

2D WaveletTransform on

Tile

HuffmanEncoding

HuffmanDecoding

Deltas

Send coefficients tolevel l+1 cluster-heads

Get coefficients fromlevel l-1 cluster-heads


59/60

IV-117

Content Addressable Storageaka Data Centric Storage

(Ramiswamy et al)

Queries for some

things (like local

maxima) are notnecessarily spatially

correlated.

Sensor networks

require a storage

scheme that indexes

on semantics as wellas on the location of

data.

IV-118

The Semantic Hierarchy(Greenstein et al)

8 < Temperature 8

7 < Temperature 8

1 < Temperature 8

4 < Temperature 8

The wider thegeographical extent anode indexes, themore data there is toindex.

Given that each nodehas limited storage,tighter semantic

constraints must beused for nodes that

index wider areas.


60/60

IV-119

Event

Index Construction

AttributeName = TemperatureValue = 8

Min = 1

Max = 8

Distribution = Uniform

AttributesName = EventLatitude

Value = 171

HashFunction

AttributesName = EventLongitude

Value = 120

(120, 171)(0111 1000, 1010 1011)

Level

1 of 4

Coordinates

Temperature 1 8

Hash String(121, 169)

(0111 1001, 1010 1001)

Coordinates

Indexes contain histograms summarizing

events within their value and spatial ranges

8 < Temperature 8

7 < Temperature 8

1 < Temperature 8

4 < Temperature 8

Search

8 < Temperature 8

7 < Temperature 8

1 < Temperature 8

4 < Temperature 8

etc.

Search most constrained index nodesfor region of interest

Search travels from constrainedsemantics to constrained geography(location of an event)

Distributions are generated as part ofthe index construction

Node Histogram

Region 008 0

Region 018 0

< 8 --752

> 8 -- 0

Node Histogram

Region 007 52

8 2

Region 017 12

8 0

Region 10

< 7 --700

> 8 -- 0

Node Histogram

Region 005 --100

6 --80

7 --26

8 --1

Region 005 --30

6 --20

7 --13

8 --1

< 5 --400

> 8 -- 0

mobicom tutorial 4 de

Documents