Agenda for Networking SessionChairs: S. Shyne & M. Srivastava

D. Estrin (USC) : Scalable Directed Diffusion Methods L. Zhang (UCLA): Gradient Broadcast for Sensor Nets D. J. Van Hook (MIT/LL): Publish/Subscribe Methods W. Kaiser (Sensor.com): WINS NG Networking Break M. Srivastava (UCLA): Sensor Networking Issues C. Chien (RSC): Latency, and Security Trade-offs in

Wireless Communications D. Carman (NAI Labs): Security Architecture & Techniques Discussion

Some Issues for Discussion Relationship between diffusion, gradient, and publish-

subscribe routing models Above vs. “traditional” multihop routing with spatial and power

awareness is one sufficient, or are both needed? how do they compare

Interaction of routing with distributed signal processing algorithms

Interaction of routing with sensor task distribution and scheduling

Interaction of networking with mobile code / scripting Management of sensor network – centralized, distributed Trade-offs: latency, power, survivability, accuracy

Mani SrivastavaUCLA - EE Departmentmbs@ee.ucla.edu

Sensor Networking IssuesDSN (ISI) & SensorWare (RSC) Projects at UCLA

Power Issues in Sensor Networking

Problems: routing is power unaware: focus on topology changes

• metrics such as shortest hop, shortest delay, link quality etc.• power loss in quiescent state signaling in proactive protocols

lack of routing and MAC coordination, e.g.• large number of collisions with CSMA MAC during broadcasts used by

routing protocols for probing• TDMA slot scheduling, and clustering overheads lead to sub optimal route

selection in algorithms such as DSR What can be done?

obvious one: power-based routing metrics leverage location information during routing intelligently combine and filter replies at intermediate nodes exploit path diversity tightly coupled routing + TDMA MAC

• soft-state slot schedule, locally proactive + globally reactive

Exploiting Path Diversity for Power

Idea is distribute traffic over alternative paths to increase network lifetime and coverage

packet disperser and combiner entities Works with DSR as well as gradient based routing Evaluation metrics

time to breakdown # of depleted nodes RMS energy distribution

A problem: do not know which nodes are important as it depends on future target traffic pattern and user movement pattern

Path Diversity Scenario

A and B generate 1 packet every 100 ms until 5s C generates 1 packet every 100 ms from 5s till 15s

A

B C

user

# of Nodes with > 10% Battery

Packets received by t=150:

Normal: 127Stochastic: 133Energy Disperse: 160Stochastic ED: 161Divert streams: 175

RMS Battery Energy Consumption

Lower Bound 1

Lower Bound 2

MAC and Routing Interaction

With DSR Route A->H Route request path:

{A,B,C,E,G,H} Paths depend on slot

assignment With DSDV Route A->G

3 routes with equal length ABCEG,AJOHG, AJIHG

These will fluctuate depending on the route updates

Tightly coupled MAC and routing layers can help resolve these issues and increase flexibility

•TDMA MAC & Routing simulations in ns-2 are now in progress

The “Networking” Viewpoint Alone is Inadequate

Notion of quality of service is quite different and task-specific Hunt for the “best” protocol for sensor nets is inadequate

e.g. different tasks on sensor network work best with different routing boundary between networking & other layers fuzzy in sensor net.

Lifetime

Rapidity of info (latency -1)

Detail and/orCertainty

“Distributed Computing” Viewpoint

A “Distributed Computing” viewpoint is better suited distributed algorithms with application-specific protocols

– application-specific routing helps with power, latency etc. dynamic, resource-constrained environment nodes coordinate to do tasks such as target detection, target

tracking, distributed signal processing, network monitoring Approach: a minimal “substrate” or middleware with support

for mobile scripts easily write and incrementally in situ deploy distributed apps with

application-specific networking administer and manage the network accommodate transient users with specialized tasks etc.

Our Architecture

Small set of common (local as well as distributed) services Scriptable, lightweight runtime at each node on top of a RTOS

compact, platform independent sensor node control scripts used primarily for control flow (protocols) and not data crunching

Node Object Model (SP, communication, sensor resources and services) Scripts can replicate

Sensor Node Hardware

Hardware Abstraction Layer

Node Kernel & APIs

SensorScripts

SensorMiddleware

ApplicationsAPP

SCRIPT

Sensor Node Hardware

Hardware Abstraction Layer

Node Kernel & APIs

SensorScripts

SensorMiddleware

ApplicationsAPP

SCRIPT

Transient External User

download

Downloadmigrate

Implementation Approach

Scripts based on subset of Tcl Tcl interpreter ported to Rockwell nodes on uC/OS Also, in ns via external Unix processes attached to ns nodes

Model: (events, state) actions actions = events | data processing | state change signal processing, communication, and sensing services

available as persistent native code objects Mechanisms:

API: spawn, migrate, replicate, kill, script state maintenance resource-based script admission control future: script compression, authentication

Implementation on RSC Nodes

App1

Hardware Abstraction LayerBase RTOS

SensorStack

NetworkStack

OtherDrivers/Services

App1Apps

Tcl Process #1

Interpreter

script

EventQueue

SensorObject

N/WObject

{..wait e1 e2if (e1=v1)…...}

Script

Tcl Process #n

Interpreter

script

EventQueue

SensorObject

N/WObject

ScriptManager

Implementation on ns nodes

Sensor Model

802.11

DSR

NetIf

ns-2 environment

UNIX process

wireless channel

SensorAgent

CustomRouting

TXRX

main()

( )

( )

( )

Free Thread Pool

Spawned Threads

INJECT( )

State Information

Sensor Model

Example Application #1Custom Network Status Queries

E.g. which node has the minimum battery level? No scripts and with knowledge of global

topology. Ask every node, wait for a reply. Contention around central node. Not scalable.

With scripts. Populate the script so an optimal multicast/gathercast tree is created.

Less contention around central node. Scalable!

Node running a script

#of messages received#of messages transmitted

Example Application #1(contd.)

No scripts, no knowledge of topology. Ask every node for neighbors, wait for a reply, then ask for battery level.

The same problems are sharpened

With scripts. The processes of discovering the topology and the min value are combined.

Still scalable.

#of messages received#of messages transmitted

Script Exampleset node [localNode_memory_read 0]; set minenergy [localNode_memory_read 1];

set neighbors [localNode_memory_read 2];

set send_node [Agent_memory_read 0]; set send_node_neighbors [Agent_memory_read 1];

Agent_memory_write 0 $node; Agent_memory_write 1 $neighbors;

set remaining_nodes $neighbors; set n [lsearch neighbors $send_node];

lreplace $remaining_nodes n n;

foreach i $send_node_neighbors{ set n [lsearch neighbors $i]; lreplace $remaining_nodes n n;}

Agent_replicate $remaining_nodes;

foreach i $remaining_nodes{ set result [wait -msg * -for 1000]; set minenergy [($minenergy < $result) ? $minenergy : $result];}

send send_node:1 $minenergy;

set minenergy;

…

Script size: Uncompressed verbose: 840 bytes Potential compression (byte code): 224 bytes

Example Application #2Mission-specific Target Tracking

Resident application (or initial script flooded to all nodes) sends message to user informing a potential target

User downloads a tracking script to the appropriate node script encodes a custom tracking mechanism, e.g. calculate new

position every 10s and send it to user Script spreads to form an initial sensing cluster Script does data fusion or simple beamforming (using signal

processing modules resident at the node) Script arranges for the active sensor cluster to “migrate” as the

target moves motion prediction using history (e.g. movement direction) sentry scripts spawned around the cluster avoids polling and cluster management by the distant user, which is

needed if nodes only support simple forms of query

Region A

Tracking ScenarioTank @x,y,z,t

Region A

Tracking ScenarioTank @x,y,z,t

Region A

Tracking ScenarioTank @x,y,z,t

Initial Script

Runs on all nodes within the area of interest Straightforward approach where each node sends a

message to the user is energy inefficient with multihop polling-based, interrupt-based

Clustering approach first node that detects the target becomes a clusterhead other nodes join the cluster when they detect the target after MAX_LATENCY the clusterhead sends a message to the

user, then waits for the ACK and distributes the ACK to other members of the cluster

ideally, only one message is sent to the user from one cluster,– however due to unreliable protocols, a node maintains soft-

state waiting for an ACK if an ACK is not received within an interval, cluster dissolves

into smaller clusters whose clusterheads send messages to the user

Tracking Script

To determine an approximate location of a target, a node has to receive messages from several other nodes that detected the target

when a node acquires certain number of messages, either simple intersection or potentially beamforming is used

Due to power constraints in sensor nodes, they should refrain from sending repeated messages about the target

if one node detects the target and sends a message to the neighbors, the nodes in certain area around that node do not add significant information concerning the location of the target

Solution: when a node senses a target it sends a report to other nodes only if none of the other nodes within some area generated a report during certain time interval

similar to IGMP mechanism on LANs

Tracking Script (contd.)

When a node acquires certain number of messages, it determines target position and sends to the user

That message is broadcast to other nodes within an area so that all nodes that want to determine the location and send a message to the user will refrain for a certain time

area where that message is broadcast may be asymmetric, if a motion prediction algorithm is used

Messages containing target location is generated in periodic intervals except when a target moves fast enough and leaves an area before the time interval expires

if target moves fast, location messages generated more often

Simulation Results

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

0.1s 0.5s 1s 2s 3s 5s

RMS

TOTAL

The ratio of consumed energy by the initial script as a function of MAX_LATENCY compared to the approach where each node sends a message directly to the user

200x200m area, 50 nodes, 50m transmission range, 35m sensing range, 10 m/s target speed

Simulation Results

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

50 80 100

RMS

TOTAL

The ratio of consumed energy by the initial script compared to the approach where each node sends a message directly to the user as a function of the number of nodes

area is 200x200, MAX_LATENCY for initial script is 3s