An Introduction to the Sensor Network WorkBench -- SN Bench Michael Ocean Azer Bestavros & Assaf Kfoury Computer Science Department Boston University

Jan 24, 2007CS5112 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

Jan 24, 2007CS5113 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/…

Jan 24, 2007CS5114 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  b/g sensors  Backend computation  Backend TByte storage  Berkeley motes + Full-time Research Engineer

Jan 24, 2007CS5115 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

Jan 24, 2007CS5116 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 traditional Sensor Networks traditional Distributed Systems VSNs

Jan 24, 2007CS5117 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

Jan 24, 2007CS5118 SN Bench:SN Workbench The Sensorium is the computer The SN Bench 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?

Jan 24, 2007CS5119 SN Bench: 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

Jan 24, 2007CS51110 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)

Jan 24, 2007CS51111 Unbound STEP graph Bound STEP graph Resource management components solve graph embedding Deployment Sensor eXecution Environments SN Bench: Program Life-cycle SXE trigger cam2 snapshot motion clock4AM 2AM << && SNAFU Program dispatch linking trigger( (motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2))) trigger cam2 snapshot motion clock4AM2AM << && compilation

Jan 24, 2007CS51112 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

Jan 24, 2007CS51113 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))) cond(predicate,do-if-true,do-if-false) let x = get(image,cam1) in cond(facefind(x),facecount(x),0)

Jan 24, 2007CS51114 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”

Jan 24, 2007CS51115 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 Time Trigger P = True P = False trigger(greater(roomtemp,”80c”),hvac_heatoff)

Jan 24, 2007CS51116 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 Time Trigger P = True P = False

Jan 24, 2007CS51117 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 Time Trigger P = True P = False

Jan 24, 2007CS51118 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),snapshot(cam1)) ) expires(10min, level_trigger(motion(cam1),snapshot(cam1)) )

Jan 24, 2007CS51119 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 Trigger P = True P = False Time Non-blocking Blocking Fresh Read

Jan 24, 2007CS51120 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)) )

Jan 24, 2007CS51121 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)”

Jan 24, 2007CS51122 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)

Jan 24, 2007CS51123 STEP: Sensorium Typed Exec Plan add LTE 5 cond isnilequals level_trigger not Virtual Instruction Set Architecture Directed Acyclic Graph level_trigger( not(equals(5,LTE)), cond(isnil(LTE), 1, add(LTE,1) )) LTE 1 1  STEP is an XML representation of this DAG  let nodes don’t exist  indicate edges point to the same node Recursion is disallowed, one must be careful!  LAST_TRIGGER_EVAL is like a “cycle-safe” cycle...

Jan 24, 2007CS51124 STEP: XML Representation STEP Graphs are serialized/stored as XML level_trigger( not(equals(5,LTE)), cond(isnil(LTE),1,add(LTE,1)) ) 5 1 1

Jan 24, 2007CS51125 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 SD, SXE SXE SXE, Compiler

Jan 24, 2007CS51126 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]

Jan 24, 2007CS51127 SSD: Mapping/Linking Resources SXE trigger cam2 snapshot motion clock4AM 2AM << &&

Jan 24, 2007CS51128 SSD: Code Reuse in Mapping Different programs may share STEP sub-graphs Example: trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2))) trigger( facerecognizer( trigger((motion(snapshot(cam2)) && (2am<NOW<4am)), snapshot(cam2)), facelibrary(amber.alert.images.boston.gov)), “Amber Alert match!”))

Jan 24, 2007CS51129 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

Jan 24, 2007CS51130 Sensor eXecution Environment  A run-time environment present on most resources in the Sensorium Advertises the node’s computational/sensing capabilities An SXE is an abstraction of physical resources, accessible via STEP

Jan 24, 2007CS51131 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

Jan 24, 2007CS51132 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

Jan 24, 2007CS51133 SXEs  What if we can’t 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 )

Jan 24, 2007CS51134 Intrinsic Research: Expressive PL  Better Programming Languages  Alternate Execution Environments STEP SNAFU SnQL SnLOG SnC SXE J2ME Native C JXTA

Jan 24, 2007CS51135 SN Bench: Progress  Foundation for SN Bench is done basic SNAFU->STEP 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

Jan 24, 2007CS51136 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?

Jan 24, 2007CS51137 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.

Jan 24, 2007CS51138 Kismet support in SN Bench  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)

Jan 24, 2007CS51139 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()

Jan 24, 2007CS51140 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) )

Jan 24, 2007CS51141 Example #2  an administrator on every detected DEAUTHFLOOD The 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”,WIFIALERT),“DEAUTHFLOOD”), concat(“Deauth flood detected from ”, SRC, “ at ”, getField(“TIME”,WIFIALERT)) )

Jan 24, 2007CS51142 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”,WIFIALERT),“DEAUTHFLOOD”), drawstring( concat(“Deauth flood detected from ”, SRC, “ at ”, getField(“TIME”,WIFIALERT)), findAdjacentSensor(“Image”, getField(WIFIALERT, “BASESTATION”)) )

Jan 24, 2007CS51143 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)) ) ))