Agenda for Networking Session Chairs: S. Shyne & M. Srivastava

1. Agenda for Networking SessionChairs: 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

2. Some Issues for Discussion • Relationship between diffusion, gradient, and publish-subscribe 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

3. Sensor Networking Issues DSN (ISI) & SensorWare (RSC) Projects at UCLA

4. 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

5. 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

6. Path Diversity Scenario B C • A and B generate 1 packet every 100 ms until 5s • C generates 1 packet every 100 ms from 5s till 15s A user

7. # of Nodes with > 10% Battery Packets received by t=150: Normal: 127 Stochastic: 133 Energy Disperse: 160 Stochastic ED: 161 Divert streams: 175

8. RMS Battery Energy Consumption Lower Bound 2 Lower Bound 1

9. 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

10. Lifetime Rapidity of info (latency -1) Detail and/or Certainty The “Networking” Viewpoint Alone is Inadequate • Notion of quality of service is quite different and task-specific • 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.

11. “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.

12. Transient External User download Sensor Scripts Download migrate SCRIPT Sensor Scripts SCRIPT Applications APP Applications APP Node Kernel & APIs Sensor Middleware Node Kernel & APIs Sensor Middleware Hardware Abstraction Layer Hardware Abstraction Layer Sensor Node Hardware Sensor Node Hardware Our Architecture • Small set of common (local as well as distributed) services • Scriptable, lightweight runtime at each node on top of a RTOS • 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

13. 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

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

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

16. Example Application #1Custom 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 #of messages received Node running a script

17. 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

18. 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: 840 bytes • Potential compression (byte code): 224 bytes

19. Example Application #2Mission-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

20. Tank @ x,y,z,t Region A Tracking Scenario

21. Tank @ x,y,z,t Region A Tracking Scenario

22. Tank @ x,y,z,t Region A Tracking Scenario

23. 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 soft-state 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

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

25. 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

26. 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

27. Simulation Results • The ratio of consumed energy by the initial script compared to the approach where each node sends a message directly to the useras a function of the number of nodes • area is 200x200, MAX_LATENCY for initial script is 3s