Agenda for Networking Session Chairs: S. Shyne & M. Srivastava n D. Estrin (USC) : Scalable Directed Diffusion Methods n L. Zhang (UCLA): Gradient Broadcast for Sensor Nets n D. J. Van Hook (MIT/LL): Publish/Subscribe Methods n W. Kaiser (Sensor.com): WINS NG Networking n Break n M. Srivastava (UCLA): Sensor Networking Issues n C. Chien (RSC): Latency, and Security Trade-offs in Wireless Communications n D. Carman (NAI Labs): Security Architecture & Techniques n Discussion

Some Issues for Discussion n Relationship between diffusion, gradient, and publish- subscribe routing models n Above vs. “traditional” multihop routing with spatial and power awareness F is one sufficient, or are both needed? F how do they compare n Interaction of routing with distributed signal processing algorithms n Interaction of routing with sensor task distribution and scheduling n Interaction of networking with mobile code / scripting n Management of sensor network – centralized, distributed n Trade-offs: latency, power, survivability, accuracy

Mani Srivastava UCLA - EE Department Sensor Networking Issues DSN (ISI) & SensorWare (RSC) Projects at UCLA

Power Issues in Sensor Networking n Problems: F 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 F 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 n What can be done? F obvious one: power-based routing metrics F leverage location information during routing F intelligently combine and filter replies at intermediate nodes F exploit path diversity F tightly coupled routing + TDMA MAC soft-state slot schedule, locally proactive + globally reactive

Exploiting Path Diversity for Power n Idea is distribute traffic over alternative paths to increase network lifetime and coverage F packet disperser and combiner entities n Works with DSR as well as gradient based routing n Evaluation metrics F time to breakdown F # of depleted nodes F RMS energy distribution n A problem: do not know which nodes are important as it depends on future target traffic pattern and user movement pattern

Path Diversity Scenario n A and B generate 1 packet every 100 ms until 5s n 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: 127 Stochastic: 133 Energy Disperse: 160 Stochastic ED: 161 Divert streams: 175

RMS Battery Energy Consumption Lower Bound 1 Lower Bound 2

MAC and Routing Interaction n With DSR Route A->H u Route request path: {A,B,C,E,G,H} u Paths depend on slot assignment n With DSDV Route A->G u 3 routes with equal length ABCEG,AJOHG, AJIHG u These will fluctuate depending on the route updates n 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 n Notion of quality of service is quite different and task- specific n Hunt for the “best” protocol for sensor nets is inadequate F e.g. different tasks on sensor network work best with different routing F boundary between networking & other layers fuzzy in sensor net. Lifetime Rapidity of info (latency -1 ) Detail and/or Certainty

“Distributed Computing” Viewpoint n A “Distributed Computing” viewpoint is better suited F distributed algorithms with application-specific protocols –application-specific routing helps with power, latency etc. F dynamic, resource-constrained environment F nodes coordinate to do tasks such as target detection, target tracking, distributed signal processing, network monitoring n Approach: a minimal “substrate” or middleware with support for mobile scripts F easily write and incrementally in situ deploy distributed apps with application-specific networking F administer and manage the network F accommodate transient users with specialized tasks etc.

Our Architecture n Small set of common (local as well as distributed) services n Scriptable, lightweight runtime at each node on top of a RTOS F compact, platform independent sensor node control scripts F used primarily for control flow (protocols) and not data crunching n Node Object Model (SP, communication, sensor resources and services) n Scripts can replicate Sensor Node Hardware Hardware Abstraction Layer Node Kernel & APIs Sensor Scripts Sensor Middleware Applications AP P SCRIPT Sensor Node Hardware Hardware Abstraction Layer Node Kernel & APIs Sensor Scripts Sensor Middleware Applications AP P SCRIPT Transient External User download Download migrate

Implementation Approach n Scripts based on subset of Tcl F Tcl interpreter ported to Rockwell nodes on uC/OS F Also, in ns via external Unix processes attached to ns nodes n Model: ( events, state) actions F actions = events | data processing | state change F signal processing, communication, and sensing services available as persistent native code objects n Mechanisms: F API: spawn, migrate, replicate, kill, script state maintenance F resource-based script admission control F future: script compression, authentication

Implementation on RSC Nodes App1 Hardware Abstraction Layer Base RTOS Sensor Stack Network Stack Other Drivers/Services App1 Apps Tcl Process #1 Interpreter script Event Queue Sensor Object N/W Object {. wait e1 e2 if (e1=v1)…. } Script Tcl Process #n Interpreter script Event Queue Sensor Object N/W Object Script Manager

Implementation on ns nodes Sensor Model DSR NetIf ns-2 environment UNIX process wireless channel Sensor Agent Custom Routing TXRX main() ( ) Free Thread Pool Spawned Threads INJECT( ) State Information Sensor Model

Example Application #1 Custom Network Status Queries n E.g. which node has the minimum battery level? n No scripts and with knowledge of global topology. Ask every node, wait for a reply. F Contention around central node. Not scalable. n With scripts. Populate the script so an optimal multicast/gathercast tree is created. F Less contention around central node. Scalable! Node running a script #of messages received#of messages transmitted

Example Application #1 (contd.) n No scripts, no knowledge of topology. Ask every node for neighbors, wait for a reply, then ask for battery level. F The same problems are sharpened n With scripts. The processes of discovering the topology and the min value are combined. F Still scalable. #of messages received#of messages transmitted

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; … n Script size: F Uncompressed verbose: 840 bytes F Potential compression (byte code): 224 bytes

Example Application #2 Mission-specific Target Tracking n Resident application (or initial script flooded to all nodes) sends message to user informing a potential target n User downloads a tracking script to the appropriate node F script encodes a custom tracking mechanism, e.g. calculate new position every 10s and send it to user n Script spreads to form an initial sensing cluster n Script does data fusion or simple beamforming (using signal processing modules resident at the node) n Script arranges for the active sensor cluster to “migrate” as the target moves F motion prediction using history (e.g. movement direction) F sentry scripts spawned around the cluster F avoids polling and cluster management by the distant user, which is needed if nodes only support simple forms of query

Region A Tracking Scenario Monitor Region A x,y,z,t Track Tank 10s

Region A Tracking Scenario x,y,z,t

Region A Tracking Scenario x,y,z,t

Region A Tracking Scenario x,y,z,t

Initial Script n Runs on all nodes within the area of interest n Straightforward approach where each node sends a message to the user is energy inefficient with multihop F polling-based, interrupt-based n Clustering approach F first node that detects the target becomes a clusterhead F other nodes join the cluster when they detect the target F 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 F 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 F if an ACK is not received within an interval, cluster dissolves into smaller clusters whose clusterheads send messages to the user

Tracking Script n To determine an approximate location of a target, a node has to receive messages from several other nodes that detected the target F when a node acquires certain number of messages, either simple intersection or potentially beamforming is used n Due to power constraints in sensor nodes, they should refrain from sending repeated messages about the target F 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 n 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 F similar to IGMP mechanism on LANs

Tracking Script (contd.) n When a node acquires certain number of messages, it determines target position and sends to the user n 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 F area where that message is broadcast may be asymmetric, if a motion prediction algorithm is used n 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 F if target moves fast, location messages generated more often

Simulation Results n 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 F 200x200m area, 50 nodes, 50m transmission range, 35m sensing range, 10 m/s target speed

Simulation Results n 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 F area is 200x200, MAX_LATENCY for initial script is 3s

Simulation Results n The ratio of consumed energy by the initial script as a function of the covered area compared to the approach where each node sends a message directly to the user F 80 nodes, MAX_LATENCY - 3s

Services for Network Management n Queries not just about the target, but also about the network status n Traditional centralized approach: F a Network Operations Center where nodes report their status F users query the NOC n Alternate distributed approach: F support users asking queries about the network F e.g. –which nodes have energy < threshold ? –which is the weakest path (maximal breach) through the network?

Maximal Breach Path  Given: A field S instrumented with sensors; areas I and F corresponding to initial (I) and final (F) locations of the agent  Problem: Identify the path of maximal breach of surveillance in S, starting in I and ending in F.  Solution: 1) Generate Voronoi Diagram 2) Apply Graph-Theoretic Abstraction 3) Use Binary-Search, Breadth-First-Search to find the solution

Enabling Step: Voronoi Diagaram By construction, each line-segment maximizes distance from the nearest point (sensor). Consequence: Path of Maximal Breach of Surveillance in the sensor field lies on the Voronoi diagram lines. Source: Rockwell Science Center

Graph-Theoretic Formulation Given : Voronoi diagram D with vertex set V and line segment set L and sensors S Construct graph G(N,E): Each vertex v i  V corresponds to a node n i  N Each line segment l i  L corresponds to an edge e i  E Each edge e i  E, Weight(e i ) = Distance of l i from closest sensor s k  S Formulation : Is there a path from I to F which uses no edge of weight less than K?

Sample Results (50, 200, 1000 nodes)