Sensor Networks Issues Solutions Some slides are from Estrin’s early talks

Disaster Response Circulatory Net Embed Embed numerous distributed devices to monitor and interact with physical world: work-spaces, hospitals, homes, vehicles, and “the environment” Network these devices so that they can coordinate to perform higher-level tasks. Requires robust distributed systems of hundreds or thousands of devices. Scenario

Motivating Applications 2 meters Algae  -scaled Tethered Robot Bio-Tank Laboratory Model Development Inner wall of storm drain Sensors Environmental Monitoring Sensors Complex Structures

What is new? Tight coupling to the physical world –Need better physical models –More experimentation Constraints of a sensor Energy Computing, communication, memory Failure and dynamics Node failures, wireless communication Network scale Most sensors are not mobile typically

Design Goals Long-lived systems that can be untethered and unattended –Low-duty cycle operation with bounded latency –Exploit redundancy and heterogeneous tiered systems Leverage data processing inside the network –Thousands or millions of operations per second can be done using energy of sending a bit over 10 or 100 meters (Pottie00) –Exploit computation near data to reduce communication Self configuring systems that can be deployed ad hoc –Un-modeled physical world dynamics makes systems appear ad hoc –Measure and adapt to unpredictable environment –Exploit spatial diversity and density of sensor/actuator nodes Achieve desired global behavior with adaptive localized algorithms –Cant afford to extract dynamic state information needed for centralized control

Sample Layered Architecture Resource constraints call for more tightly integrated layers Open Question: Can we define an Internet-like architecture for such application- specific systems?? In-network: Application processing, Data aggregation, Query processing Adaptive topology, Geo-Routing MAC, Time, Location Phy: comm, sensing, actuation, SP User Queries, External Database Data dissemination, storage, caching

Directed Diffusion In-network data processing (e.g., aggregation, caching) Application-aware communication primitives –expressed in terms of named data (not in terms of the nodes generating or requesting data) Distributed algorithms using localized interactions and measurement based adaptation

Basic Directed Diffusion Setting up gradients Source Sink Interest = Interrogation in terms of data attributes Gradient = direction and strength

Basic Directed Diffusion Source Sink Sending data and Reinforcing the “best” path Low rate eventReinforcement = Increased interest

Directed Diffusion and Dynamics Recovering from node failure Source Sink Low rate event High rate event Reinforcement

Directed Diffusion and Dynamics Source Sink Stable path Low rate event High rate event

Local Behavior Choices For propagating interests –In our example, flood –More sophisticated behaviors possible: e.g. based on cached information, GPS For data transmission –Multi-path delivery with selective quality along different paths –probabilistic forwarding –single-path delivery, etc. For setting up gradients data-rate gradients are set up towards neighbors who send an interest. data-rate gradients are set up towards neighbors who send an interest. Others possible: probabilistic gradients, energy gradients, etc. For reinforcement reinforce paths, or parts thereof, based on observed delays reinforce paths, or parts thereof, based on observed delays, losses, variances etc. other variants: inhibit certain paths because resource levels are low

Summary of Diffusion Results Under the investigated scenarios, diffusion outperformed omniscient multicast and flooding Application-level data dissemination has the potential to improve energy efficiency significantly –Duplicate suppression is only one simple example out of many possible ways. –Aggregation (in progress) All layers have to be carefully designed –Not only network layer but also MAC and application level

GRAB Design Two protocols addressing the two problems –Robust data delivery: MESH Deliver data to the user in face of node failures and packet losses –Long-lived system: PEAS Extend sensing and data delivery lifetime in proportion to the total number of deployed nodes

Design Goal: a forwarding mesh with controllable width Forward each data packet along parallel paths to the sink these paths interleave to form a forwarding mesh The mesh starts at the source, ends at the sink The width of the mesh should be adjusted to achieve certain delivery reliability source sink

How to forward data along an adjustable mesh build a cost field that gives each sensor the direction towards the sink assign each packet certain amount of credit which controls the width of the forwarding mesh

How to build a cost field? The sink broadcasts an ADV packet with cost 0 Each node sets its cost as the smaller of –Its own cost (  initially) –The sum of the cost of the sender and the link cost to the sender Then broadcasts its own cost

Excessive messages in building the cost field Sink(0) B C sink broadcasts B (1) C (4) C, B broadcasts C (2.5) C broadcasts again the farther a node, the more it broadcasts an example: 1500 nodes, 150mx150m field, the farthest node broadcasts more than 150 times, each node broadcasts 50 times on average

A node waits for a time proportional to its cost Sink (0) B C T=0, sink broadcasts. B and C set timers, expiring after 1, 4 seconds B (1) C (4) T=1, B broadcasts, C cancels the first timer and sets another one that expires after 1.5 seconds B C (2.5) T=2.5, C broadcasts when its timer expires

How to control the width of the mesh Each packet carries a credit A copy can take any path that requires a cost <= credit + Cost_source Different copies can take different paths, forming a mesh sink source Cost <= credit + Cost_source Cost > credit + Cost_source Cost_source

Allocate credit along different hops Calculate how much credit has been used: –alpha_used = P_consumed + C_A – C_source Calculate how much is remaining –R_alpha = (alpha – alpha_used) / alpha Compare to a threshold –R_thresh = (C_A / C_source)^2 sink Cost_source cost_consumed source A Cost_A

Handling mobility Source Stimulus Sink

Mobile Sink Excessive Power Consumption Increased Wireless Transmission Collisions State Maintenance Overhead

Challenges Battery powered sensor nodes Communication via wireless links –Bandwidth constraint –Load balancing Ad-hoc deployment in large scale –Fully distributed w/o global knowledge –Large numbers of sources and sinks Unexpected sensor node failures Sink mobility –No a-priori knowledge of sink movement

Goal, Idea Efficient and scalable data dissemination from multiple sources to multiple, mobile sinks Two-tier forwarding model –Source proactively builds a grid structure –Localize impact of sink mobility on data forwarding –A small set of sensor node maintains forwarding state

TTDD Basics Source Dissemination Node Sink Data Announcement Query Data Immediate Dissemination Node

TTDD Mobile Sinks Source Dissemination Node Sink Data Announcement Data Immediate Dissemination Node Immediate Dissemination Node Trajectory Forwarding Trajectory Forwarding

TTDD Multiple Mobile Sinks Source Dissemination Node Data Announcement Data Immediate Dissemination Node Trajectory Forwarding Source

Other layers MAC layer –Energy efficiency and simplicity Time synchronization Location service Security transport