Agenda for Networking Session
Chairs: 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 publishsubscribe 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
Sensor Networking Issues
DSN (ISI) & SensorWare (RSC) Projects at UCLA
Mani Srivastava
UCLA - EE Department
mbs@ee.ucla.edu
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
B
C
A
user


A and B generate 1 packet every 100 ms until 5s
C generates 1 packet every 100 ms from 5s till 15s
# of Nodes with > 10% Battery
Packets received by t=150:
Normal:
Stochastic:
Energy Disperse:
Stochastic ED:
Divert streams:
127
133
160
161
175
RMS Battery Energy
Consumption
Lower Bound 2
Lower Bound 1
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
Lifetime
Rapidity of info (latency -1)
Detail and/or
Certainty


Notion of quality of service is quite different and taskspecific
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.

“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
Transient External User
download
Sensor
Scripts
SCRIPT
AP
Applications
P
Sensor
Middleware


Sensor
Scripts
AP
Applications
P
Sensor
Middleware
Node Kernel & APIs
Hardware Abstraction Layer
Hardware Abstraction Layer
Sensor Node Hardware
Sensor Node Hardware
Small set of common (local as well as distributed) services
Scriptable, lightweight runtime at each node on top of a RTOS


SCRIPT
Node Kernel & APIs


Download
migrate
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
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
Interpreter
App1
App1
Apps
script
script
Event
Queue
Script
Manager
Sensor N/W
Object Object
Tcl Process #1
Sensor
Stack
Interpreter
{
.
.
wait e1 e2
if (e1=v1)…
.
.
.
}
Event
Queue
Sensor N/W
Object Object
Tcl Process #n
Network
Other
Stack
Drivers/Services
Base RTOS
Hardware Abstraction Layer
Script
Implementation on ns nodes
Free Thread Pool State Information
Spawned
Threads
Sensor Model
UNIX process
ns-2 environment
()
INJECT( )
main()
()
Sensor
Agent
DSR
()
RX
Custom
Routing
802.11
Sensor Model
NetIf
wireless channel
TX
Example Application #1
Custom 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!
#of messages transmitted
Node running a script
#of messages received
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 transmitted
#of messages received
Script Example
set 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:
 Potential compression (byte code):

840 bytes
224 bytes
Example Application #2
Mission-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

Tracking Scenario
Tank @
x,y,z,t
Region A
Tracking Scenario
Tank @
x,y,z,t
Region A
Tracking Scenario
Tank @
x,y,z,t
Region A
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 softstate 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


Due to power constraints in sensor nodes, they should
refrain from sending repeated messages about the target


when a node acquires certain number of messages, either
simple intersection or potentially beamforming is used
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

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
1.2
1.1
1
0.9
0.8
0.7
RMS
TOTAL
0.6
0.5
0.4
0.3
0.2
0.1
0
0.1s
0.5s
1s
2s
3s
5s
Simulation Results

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
1.2
1.1
1
0.9
0.8
0.7
RMS
TOTAL
0.6
0.5
0.4
0.3
0.2
0.1
0
50
80
100