Distribution & Aggregation
Technologies for SensIT
SensorWare and DSN Projects at UCLA
Mani Srivastava
UCLA - EE Department
mbs@ee.ucla.edu
Two Projects: Distinct but
Complementary

SensorWare (RSC subcontract, start January 2000)

Sensor Control Scripts
– lightweight, mobile, platform independent, secure
– target tracking application concept demonstration

Distributed Middleware Services
– spatial addressing & communication (multicast, gathercast etc.)
– timing synchronization, fault management services

DSN (ISI subcontract, start Oct 1999 with 1 student funding)

Network protocol stack
– low-power and power-aware routing, MAC, and link protocols
– protocols for GPS-synchronized communication subsystem
– capability and attribute based addressing and connectivity
partially leverage SensorWare spatial algorithms
Network boot-up: discovery & distribution of location, capabilities
 Sensor network simulation and emulation

– leveraged by SensorWare
Introduction to the Project Teams
SensorWare


Mani Srivastava
Miodrag Potkonjak



Mani Srivastava

Graduate students:
CS faculty, co-PI
Graduate students:

DSN
Athanassios Boulis

• scripting environment

Sascha Slijepcevic
• tracking with mobile
scripts


• simulation platform

Vlasios Tsiatsis (*)
• spatial addressing
Andreas Savvides
• MAC & routing

Scott Zimbeck
• node software
Sung Park
Curt Schurgers
• power-aware routing

Vlasios Tsiatsis (*)
• attribute based routing
Selected Work-In-Progress,
Accomplishments, and Plans
Sensor Control Scripts
[SensorWare]

Desired capabilities
rapid development and deployment of mission-specific sensor
network applications
 allow transient users to access collective capabilities of sensor
network in a mission-specific fashion
 go beyond the simple (static) query and response

– query as scripts, low latency customized tracking

Approach
scriptable, lightweight runtime system at each node
 compact and platform independent sensor node control scripts
 Node Object Model (sensor, SP, and communication)
 scripts can migrate (download, replicate), i.e. mobile
 modeled on systems with embedded runtime scripting
environments to provides users access to system resources

– e.g. javascript (web servers and browsers)
– e.g. Tcl (routers, CAD tools, VxWorks RTOS, NS)
SensorWare Software
Architecture
Transient External User
download
Sensor
Scripts
SCRIPT
AP
P
Applications
Sensor
Middleware
Download
migrate
SCRIPT
Sensor
Scripts
AP
P
Applications
Sensor
Middleware
Node Kernel & APIs
Node Kernel & APIs
Hardware Abstraction Layer
Hardware Abstraction Layer
Sensor Node Hardware
Sensor Node Hardware
Implementation Approach

Scripts based on subset of Tcl


RTOS/node resources & services visible as Tcl objects


embeddable scripting language with portable interpreter
network protocol stack, signal processing stack, battery
Model
scripts express interest in RTOS events and messages
 events and messages put in a queue
 processed by handlers specified by script
 script can send, activate, and kill scripts at remote nodes


Alternative organizations being evaluated
single script per interpreter, all interpreters in a single process
 single script per interpreter, single interpreter per process

Scripting Environment
Single Process Approach
Interpreter #1
script
Variables
HandlerFunc1 {}
HandlerFunc2 {}
.
.
Interpreter #n
script
{
{Event1
HandlerFunc1}
{Event2
HandlerFunc2}
.
.
}
Scheduler & Event Distributor
App1
App1
Apps
Script
Manager
Sensor
Object
Sensor
Stack
Event Queue
N/W
Object
Tcl Process
Network
Other
Stack
Drivers/Services
Base RTOS
Hardware Abstraction Layer
Script as FSM
Scripting Environment
Multiple Process Approach
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
Free-form
Script
Plan and Status

Implementation plan

FY00
– uC/OS on ARM processor in RSC nodes
– script-based target tracking application for demo in August
– no support for safety, security and authentication

FY01
– implementation on Win CE with support for Sensor.com nodes

FY02
– support for security, safety, and authentication

Status
port of basic Tcl interpreter to RSC node being debugged
 initial tracking algorithm using script model
 initial work on Tcl-ns link for rapid prototyping and testing

Tracking and Taxonomy of
Queries

Synchronous
immediate reply
 Is there movement anywhere in the 2nd floor?


Asynchronous
establish a trigger
 Inform me whenever there is movement on the 2nd floor?


Tracking
continuous sampling
 Inform me of the location of the object every 10s

Mission-specific Tracking Using
Sensor Scripts


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

Tracking Scenario
Tank @
x,y,z,t
Region A
Monitor
Track
Region
A
Tank 10s
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
Relationship with Other Mobile
Code Technologies

Download new firmware (OS, apps) over the air


RSC’s node allow this, useful for long timescale
Penn State’s Reactive Sensor Network
downloads executables and DLLs, identified by URLs, from
repositories and their caches
 read/write data from URLs
 essentially, lookup service + Java’s applet model generalized to
arbitrary executables and data
 general-purpose, heavyweight (no scripting) but may
complement SensorWare environment

– can be used as the basis for search-and-fetch of modules
needed by a SensorWare script, and for node initialization

Mobile Streams in AGNI (Ranganathan)

Mstreams not directly applicable, but underlying Tcl technology
may be leveraged
Sensor Network Simulation &
Emulation [DSN]
Sensor Network Simulation &
Emulation [DSN]


Accurate modeling of power consumption by the
protocol stack and applications
Modeling of sensors and targets
 creation
of standard application scenarios for
comparison of protocols

Hybrid simulation/emulation
 network
of “virtual” and “real” sensor nodes
– scalability studies with live sensor data
– easier debugging and development of protocol code
 “real”
application on “virtual” nodes
– easier debugging and development of application code

Approach: ns based
Power Modeling: ns-based
Mobile Node in ns
Mobile Sensor Node with Power Model
Agent
Agent
Routing
Routing
Link Layer
Link Layer
Sensor
Battery
CPU
Buffer
MAC
Buffer
MAC with
Power Management
PHY
Model-aware
PHY
Channel
Channel
Baseband
(Rate)
RF
(analog)
Node Model
Power
Amplifier
(PRF)
Hybrid Simulation & Emulation
monitor and control
hybrid network
(local or remote)
real sensor apps on
virtual sensor nodes
app
GUI
app
socket
comm
event gw
V
V
V
ns
Ethernet
serial
comm
RS232
gateway
Dll (RSC)
R
V
R
Gateway
(Windows PC)
modified event scheduler
Simulation Machine
(Linux PC)
Proxies for real
sensor nodes
Status

Accomplishments so far
detailed radio model
 MAC layer with radio shutdown management
 low-power ad hoc routing protocol
 first generation hybrid capability (demonstration)

– routing layer and higher layers can be hybrid
– network with one real and n virtual nodes
– GUI to monitor the hybrid network

Collaboration with Deborah Estrin’s group
interest in UCLA’s more sophisticated energy consumption
models for diffusion algorithm simulation
 they will incorporate UCLA’s models into standard ns release

– available to SensIT community
Power-aware Routing [DSN]
Power-aware Routing [DSN]

Traditional power unaware multihop ad hoc routing
protocols focus on fast topology changes
metrics used: shortest hop, shortest delay, link quality, location
stability, message & time overhead
 reduced node and network lifetime, and coverage

– power hot-spots
– power lost in signaling messages in quiescent state

UCLA effort: routing protocols that focus on power
power-based routing metrics
 leveraging location information during routing
 exploiting path diversity
 Intelligent combining of replies at intermediate nodes
 interaction between MAC and routing (TDMA MAC)

Power Metrics Considered

Minimize energy consumed / packet

large dissipation at selected bottleneck nodes
– just as with shortest path metric

Maximize time to network partition
important for sensor networks etc.
 load balance across the nodes in the cut-set
 difficult to implement


Minimize variance in node power levels


no single node is penalized, but difficult to implement
Minimize cost / packet

cost for a node reflects remaining battery life
– nodes “reluctance” to forward packets

Minimize maximum node cost
delay node failure and reduce variance in remaining battery lives
 difficult to implement

Accomplishments

Evaluation of several power metrics with DSR


significant extension of network lifetime (time to partition)
Scheme to exploit 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

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
Intelligent Combining of Replies
Target
User
Target
User
Naive Approach
Better Approach
Other Accomplishment: Sensor
Subsystem for ISI Platform [DSN]
•GPS
•IR
•Light
Processing
•Sound in/out
•2D accelerometer
•Temperature
•Magnetometer
•Angular velocity
•3D accelerometer
Analog
64Kx16 Flash
3.3v
A1-A16
D0-D15
Processor
AT91M4040033AC
3.3v
JTAG
A0 - A15
128Kx8 SRAM
3.3v
D0-D7
A0 - A15
128Kx8 SRAM
3.3v
D8-D15
PC Serial Port 1
XChecker
XC4013XLA
FPGA
3.3v
Communications
General purpose
I/O lines
DAC
Amp
3.3V to 5V
Transceiver
RPC, 5V
IR ENC/
DEC
TFDU
IR
Speaker
ADC, 8ch
8:2 mux
Serial Port
8:1 mux
PC Serial Port 2
Microphone
3D
Accel
Angular
Velocity
Angular
Velocity
Humidity
5v
UART 3.3v
Magnetometer
6v
I2C Bus
Counter/Timer Ports
Light to
Freq 1
Light to
Freq 2
RS232
2D Accel
ADXL202
Temp 1
Digital
Serial Port
GPS
Temp2