An Introduction to the Sensor Network WorkBench -- SNBench

1
An Introduction to the Sensor Network WorkBench
-- SNBench

• Michael Ocean
• Azer Bestavros Assaf Kfoury
• Computer Science Department
• Boston University

2
Imagine a networked world of ...
... sensors, actuators, processors and
storage all part of a shared physical
infrastructure

• Not separate specialized sensor networks, one
  common shared, adaptable infrastructure of
  heterogeneous sensors tasked by novice users

3
Deployments not yet materialized

• Assistive Environments
• e.g. for home/hospice/elder care/
• Safety Monitoring
• e.g. in factories/daycare/hospitals/garages/subway
  
• Intelligent Spaces
• e.g. for classrooms/meeting rooms/theaters/farms
• Secure Facilities and Homeland Security Uses
• e.g. at airports/embassies/prisons/
• People Flow/Activity Studies
• e.g. at retail stores/museums/

4
Sensorium _at_ BU
A common space equipped with a variety of
sensors, actuators and computing elements to
detect and respond to activities therein

• Infrastructure
• Pan-Tilt-Zoom cameras
• Video sensors
• 802.11b/g sensors
• Backend computation
• Backend TByte storage
• Berkeley motes
• Full-time Research Engineer

5
Sensor Networks Everywhere?

• The hardware is willing, but the spirit is weak.
• Programming and administration are tedious
• Time and expertise are needed to
• program device and role specific code (across
  heterogeneous devices)
• deploy the code onto physical resources
• schedule and monitor operation
• Provide OS-style services to SN applications

6
Beyond the Status Quo

• Virtual Sensor Networks A Paradigm Shift
• Distributed Systems aim to make resource
  management/allocation transparent
• SN applications need explicit negotiation, QoS
  management and coordinated arbitration of
  (sensory) resources
• Applications that are event-driven, periodic and
  spatio-temporal --Not just queries

VSNs
traditional Distributed Systems
traditional Sensor Networks
7
Overview

• Traditional Sensor Networks
• Highly constrained
• w.r.t computation, communication, power, etc.
• Singularly tasked entities
• Shared single common goal
• Program the nodes
• Our domain
• Heterogeneous/Hybrid networks
• Not all devices/networks are uniformly
  constrained
• Shared, transient entities
• Multiple, potentially conflicting goals
• Program the network

8
SNBenchSN Workbench

• The Sensorium is the computer
• The SNBench provides users with their own
  Virtual Sensor Network via programming and
  run-time infrastructure that eases specification
  and automates deployment of distributed
  applications onto the physical infrastructure.

What sensors can I use and what functionality do
they expose?
9
SNBench Goals

• Program and deploy a SN App in minutes
• High-level languages abstract away irrelevant
  details
• Program the network, not the nodes
• Each program runs on an SN slice (i.e., a VSN)
• Painless administration
• Self-organizing, automated dispatch
• SN can grow or shrink with resource availability
• common run-time resource management
  infrastructure
• Extensibility
• Support for new sensing hardware, modalities or
  computations require implementing Java interfaces
• SN programmers continue to use a simple,
  high-level language and can immediately leverage
  new capabilities

10
snBench Programming Cycle

• Program
• Program specified by gluing together building
  blocks using SNAFU language
• Compile
• SNAFU program is compiled to produce a plan of
  execution expressed in STEP
• Map and Link
• STEP plans are decomposed in smaller
  dispatch-able STEPs which are linked
• Load and Execute
• STEP plans are dispatched (i.e., loaded) onto a
  common runtime/execution environments (SXEs)

11
SNBench Program Life-cycle
Unbound STEP graph
SNAFU Program
email(security_at_bu.edu, trigger(
(motion(snapshot(cam2)) (2amltNOWlt4am)),
snapshot(cam2)))
compilation
Bound STEP graph Resource management
components solve graph embedding

• Deployment
• Sensor eXecution Environments

email
linking
trigger
security_at_bu.edu
dispatch
SXE

SXE
motion
lt
lt
SXE
snapshot
2AM
clock
4AM
cam2
12
Overview of SNAFU

• SNAFU Sensor Network Applications as Functions
• Functional specification language
• computational dependency and concurrency are
  explicit
• Programs describe a SN data-flow
• video/audio/scalar data is acquired by sensors
• data is manipulated by functions
• e.g., computation, sensing, communication,
  storage, decision, repetition
• respond with actuators or other actions
• SNAFU is an interface to (is compiled into) STEP
• Functions in SNAFU are Opcodes in STEP

13
SNAFU SNet Apps as FUnctions

• Functional specification language
• identify the face seen through camera 1
• variable assignment has functional syntax
• if-then-else

identify(facefind(get(image,cam1)))
let x get(image,cam1) in cond(facefind(x),facec
ount(x),0)
cond(predicate,do-if-true,do-if-false)
14
Persistence and Iteration

• SNAFU does not allow recursion
• Repetition or persistent computation achieved
  through the trigger construct
• event monitoring
• Two general types of triggers
• Transient i.e., will expire naturally
• Persistent i.e, will run forever

15
Transient wait until Trigger

• Evaluate p until p becomes true then evaluate r
• Respond to event p with response r
• trigger(p,r)
• ? do until (p)
• return (r)
• After r, evaluation of trigger is complete

P True
P False
Trigger
Time
trigger(greater(roomtemp,80c),hvac_heatoff)
16
Persistent (1) Level Trigger

• Evaluate p until p becomes true then evaluate r
  --forever
• every time p is true re-evaluate r
• level_trigger(p,r)
• ? while(true)
• if (p) return (r)
• Level triggers are persistent queries that return
  a stream of evaluations of r while p is true

P True
P False
Trigger
Time
17
Persistent (2) Edge Trigger

• On Every First
• When p transitions to true re-evaluate r
• edge_trigger(p,r)
• ? while(true)
• if (p) return(r) while(p)
• Edge triggers are persistent queries that return
  a stream of evaluations of r every time p
  transitions from false to true

P True
P False
Trigger
Time
18
Extension Annotating triggers

• Level triggers could be made periodic
• This is an example of scheduling annotations
• Persistent triggers could have explicit longevity

period(100ms, level_trigger(motion(cam1),snapsho
t(cam1)) )
expires(10min, level_trigger(motion(cam1),snapsh
ot(cam1)) )
19
Triggers Accessing results

• persistent triggers values change over time
• Three trigger read semantics
• Non-blocking read - Last result is returned
• Blocking read - Wait for next result
• Fresh read - Wait for a from scratch result

P True
Non-blocking
Blocking
P False
Fresh
Trigger
Time
Read
20
Trigger recursion

• LAST_TRIGGER_EVAL
• Allows the body of a trigger to access the value
  returned at the last evaluation of that trigger
• i.e., history, state, recursion
• Example the following counts from 1 to 5

level_trigger( not(equals(5,LTE)),
cond(isnil(LTE),1,add(LTE,1)) )
21
SNAFU Primer/Cheat Sheet

• Iterative computation via trigger construct
• no recursion by reference (no cycles in a STEP
  graph)
• repeatedly test for event and respond when true
• trigger(p,r) ? once p is true return r
• level_trigger(p,r) ? every time p is true
  return r
• edge_trigger(p,r) ? every time p transitions to
  true return r
• LAST_TRIGGER_EVAL is cycle-safe reference to
  previous trigger value within trigger predicate
  or body (simulate recursion)
• References
• leteach A F in X ? each A is expanded to
  inst of F in X
• letconst B G in Y ? B is the constant result
  of G in Y
• letonce C H in Z ? C is an evaluation of H
  done once per iteration in Z (Z is a
  trigger)

22
SNAFU ? STEP

• STEP Sensorium Task Execution Plan
• explicit graph of the evaluation strategy (data
  flow w/ computation dependency)
• In evaluation values percolate up the STEP graph
  from the leaves
• Demand for evaluation is pushed down from the
  root
• Most nodes require all children to be evaluated
  before they may evaluate however there are
  exceptions
• add(a,b,c) requires a,b,c
• cond(a,b,c) ? if(a) then (b) else (c)
• level_trigger(p,r)

23
STEP Sensorium Typed Exec Plan
Virtual Instruction Set Architecture Directed
Acyclic Graph
level_trigger
level_trigger( not(equals(5,LTE)),
cond(isnil(LTE), 1, add(LTE,1)
))
cond
not
add
isnil
equals
1
5
LTE
LTE
1
LTE

• STEP is an XML representation of this DAG
• let nodes dont exist ? indicate edges point to
  the same node
• Recursion is disallowed, one must be careful!
• LAST_TRIGGER_EVAL is like a cycle-safe cycle...

24
STEP XML Representation

• STEP Graphs are serialized/stored as XML

level_trigger( not(equals(5,LTE)),
cond(isnil(LTE),1,add(LTE,1)) )
ltstepgraph id"prog_count"gt ltlevel_trigger
id"TriggerHead"gt ltexp id"not"
opcode"sxe.core.not"gt ltexp
id"equals" opcode"sxe.core.equals"gt
ltvalue idstop_value"gt
ltsnobject type"snbench/integer"gt5lt/snobjectgt
lt/valuegt
ltlast_trigger_eval id"lte" target"TriggerHead"/gt
lt/expgt lt/expgt ltexp
id"cond" opcode"sxe.core.cond"gt
ltexp id"isnil" opcode"sxe.core.isnil"gt
ltlast_trigger_eval id"lte1"
target"TriggerHead"/gt lt/expgt
ltvalue id"start_value"gt
ltsnobject type"snbench/integer"gt1lt/snobjectgt
lt/valuegt ltexp idadd"
opcode"sxe.core.math.add"gt
ltlast_trigger_eval id"lte2" target"TriggerHead"/
gt ltvalue id"1"gt
ltsnobject type"snbench/integer"gt1lt/snobjectgt
lt/valuegt lt/expgt
lt/expgt lt/level_triggergt lt/stepgraphgt
25
snBench Runtime components

• Sensor eXecution Environment (SXE)
• Runtime that executes STEP
• Sensorium Resource Manager (SRM)
• Monitors local-area SXEs, network
• Sensorium Service Dispatcher (SSD)
• Partitions STEPs to fit onto SXEs

26
SSD STEP decomposition

• Given the state of the resources in the SN, split
  the STEP into smaller STEPs to be deployed onto
  available resources
• Insert into the sub-STEPs additional nodes (e.g.,
  network sockets) that allow the sub STEPs to
  compute the larger STEP
• Find a partitioning that minimizes new
  computation
• i.e., maximize the reuse of already deployed STEP
  nodes
• Mapping and linking

27
SSD Mapping/Linking Resources
email
SXE
trigger
security_at_bu.edu

SXE
motion
lt
lt
snapshot
clock
4AM
2AM
SXE
cam2
28
SSD Code Reuse in Mapping

• Different programs may share STEP sub-graphs
• Example

email(security_at_bu.edu, trigger((motion(snapsh
ot(cam2)) (2amltNOWlt4am)),
snapshot(cam2)))
trigger( facerecognizer( trigger((motion(sna
pshot(cam2)) (2amltNOWlt4am)),
snapshot(cam2)), facelibrary(amber.alert.image
s.boston.gov)), email(lpd_at_boston.gov, Amber
Alert match!))
29
Dispatching Tasks onto Resources

• Bound STEP nodes are annotated with the resources
  they are to be deployed on
• Sockets are added to reconnect flow of
  computation across physical resources

30
Sensor eXecution Environment

• A run-time environmentpresent on most resources
  in the Sensorium
• Advertises the nodes computational/sensing
  capabilities
• An SXE is an abstraction of physical resources,
  accessible via STEP

31
SXE STEP Interpretor/Evaluator

• Accepts STEPs from SSD
• Maintain STEP nodes state, enable data flow
• Schedule nodes for execution when ready
• Provide results via HTTP

32
SXE Implementation

• Java 1.5 based
• XML parser, STEP interpreter, web server, XSLT
  for HTML interface
• STEP Functions are Java based, easily added
• New sensor types require the addition of a new
  SensorHandler (Java based) for the SXE
• detects, communicates with, and reformats data
  from a specific device to produce snBench typed
  data
• idiosyncrasies of the particular
  hardware/interface are abstracted away by
  SNAFU/STEP
• Image/Video Java Media Framework
• Berkeley motes via wireless gateway
• Wireless Network Intrusion Detection Kismet via
  gateway

33
SXEs

• What if we cant run SXE on a node?
• STEP as a virtual ISA
• Embedded C dialects?
• Java ME?
• ASM?
• Alternate linking protocols
• Serial (base station)
• SN wireless protocols (e.g. 802.15.4)

34
Intrinsic Research Expressive PL

• Better Programming Languages
• Alternate Execution Environments

SnLOG
SnQL
SnC
SNAFU
STEP
SXE
Native C
JXTA
J2ME
35
SNBench Progress

• Foundation for SNBench is done
• basic SNAFU-gtSTEP compiler
• SXE
• Mid-powered computing nodes
• Sensor integration for
• Video sensing
• Berkeley Motes (temperature)
• PTZ image sensors
• Wireless network intrusion
• SSD
• Basic STEP linking/dispatch
• Basic SRM

36
Future Directions/Work

• Types
• Real-Time/QoS Scheduling
• Confidentiality/Trust
• Verification
• Model checking approach to analyze STEP programs
• Basic STEP interpreter in TLA
• Type safety, timing invariants, verify if certain
  nodes are executed (in finite time), etc.
• Generate TRAFFIC gadget specs from STEP programs
• Other Programming Languages beside SNAFU
• Alternate Execution Environments
• Compile STEP to C ? ASM?

37
Our Experiment Environment

• Linksys WRT54GL Access Points imaged w/ OpenWRT
• Axis Pan-Tilt-Zoom Cameras on dedicated gigabit
  LAN
• motes, servers, compute node, 750GB SQL server,
  etc.

38
Kismet support in SNBench

• Each OpenWRT AP runs a Kismet drone and connects
  to a separate Kismet Server process
• required to distinguish where events were
  detected
• also reduces impact if a Kismet server
  hangs/crashes
• KismetHandler on SXE
• UDP client to Kismet Server
• an SXE is configured to host a KismetSensor by
  the presence of a local (or remote) configuration
  file that specifies remote sensors (e.g.,
  KismetSensor via UDP)
• state of the KismetSensor is inferred by the
  Handler from the state of the communication link
• translator between the published, non-standard
  Kismet Server protocol and well-typed
  KismetMessage objects (tagged XML, incl. local
  timestamp and sensor source)

39
KismetMessage

• KismetMessage is a subtype of snStruct
• Tagged fields correspond to fields in Kismet
  events
• New Opcode to read the data produced by
  KismetSensors (via KismetHandler)
• For example the SNAFU function
• get(WIFI-alert, w02)
• is compiled into a call to Java-based STEP Opcode
  sxe.core.wifi.get where the sensor parameter is a
  KismetSensor with ID w02 (resolved by the
  run-time infrastructure) and returns a
  KismetMessage (event)
• reading the fields from KismetMessages is done
  using existing snStruct Opcodes
• getField() ? sxe.core.struct.get()

40
WNID in SNAFU Example 1

• Log every detected wireless alert/infraction into
  a SQL table
• Unlike the logging provided by Kismet, this
  program records which sensor has detected the
  event and logs events into a central log backed
  by an SQL table (rather than a flat file)
• The table is keyed by MAC address and includes
  entries for each detected violation containing a
  timestamp, the base station where the violation
  was detected, the type of violation and the
  signal strength observed by the base station.

letonce WIFIALERT get(WIFI-alert, ALL) in
letonce SRC getField(BSSID,WIFIALERT) in
level_trigger( not(isNull(WIFIALERT)),
sqlAppend(SSIDBLACKLIST,
SRC, PACKET,WIFIALERT) )
41
Example 2

• E-mail an administrator on every detected
  DEAUTHFLOOD
• The email operation could be replaced with any
  number of response mechanisms including for
  example, sending an explicit de-authorization to
  that MAC address.

letonce WIFIALERT get(WIFI-alert, ALL) in
letonce SRC getField(BSSID,WIFIALERT) in
level_trigger( equals(getField(TYPE,WIFIA
LERT),DEAUTHFLOOD), email(mocean_at_cs.bu.e
du, concat(Deauth flood detected
from , SRC, at ,
getField(TIME,WIFIALERT)) )
)
42
Example 3

• Take a picture of a region when an alert is
  detected
• The Opcode findAdjacentSensor assumes a well
  configured deployment environment in which a
  central SQL database has a mapping of sensor
  names to other adjacent sensor names
• Something better next

letonce WIFIALERT get(WIFI-alert, ALL) in
letonce SRC getField(BSSID,WIFIALERT) in
level_trigger( equals(getField(TYPE,WIFIA
LERT),DEAUTHFLOOD), email(mocean_at_csa.bu.
edu, drawstring(
concat(Deauth flood detected from ,
SRC, at ,
getField(TIME,WIFIALERT)),
findAdjacentSensor(Image,
getField(WIFIALERT,
BASESTATION)) ) ) )
43
Example 4

• Visually track a user by detections of their MAC
  address
• PTZImageCaputre drives PTZ network to best
  capture a particular point in space, w/ that
  point being the centroid overlap region of the
  signals detected (yes, we could use other
  location estimates)
• listmerge takes results from every responder, not
  just first

define LogImagesOfUser(name,locale) as letconst
mac getMacAddrFor(name) in letonce img
GetImageOfMac(mac,locale) in
level_trigger( notnull(img),
sqlAppend(ImageLog,username,img)) define
GetImageOfMac(mac,locale) as PTZImgCapture(
ComputeCentroid( ComputeOverlapRegion(
listmerge(get(WIFI-comm,locale)) )
))