1. Building Wireless Efficient Sensor Networks with Low-Level Naming J. Heihmann, F.Silva, C. Intanagonwiwat, R.Govindan, D. Estrin, D. Ganesan Presentation by: Moheeb Abu Rajab

2. Agenda Introduction (Motivation, opportunities) Attribute Based naming In-network processing Architecture Implementation Evaluation Issues

3. Motivation Sensor Networks are characterized by low bandwidth and low energy 3000 instructions can be executed for the same energy cost of sending a bit 100m by radio. This motivates finding ways to reduce communication over the network.

4. Opportunities Leverage the idea that :  “Sensor networks are not general purpose networks”, they are application specific networks  Per-Hop communication networks The idea is to extend this notion by two means:  Application Specific naming (Attribute Based naming)  In-network processing: via task aware nodes

5. Attribute Based Naming Eliminating multiple indirection layers of naming and routing data directly in application level terms Two main components in the attribute based naming:  Sensor type  Geography components  Other application specific attributes can be added

6. In-network processing Computation inside the network to reduce data movement. (trade communication with more computation) In-network processing can take different forms:  Localized Data aggregation  Application Specific cashing  Collaborative signal processing (nested queries)

7. Architecture Three main components:  Directed Diffusion Manage information dissemination by using application specific attributes Data is managed as (attribute-value-operation tuples)  Matching Rules Identify when data has arrived to its destination, or whether data should be processed (filtered)  Filters: Provide necessary application specific (in-network) data processing

8. User query: Interest {{attribute, value, operation}} Eg Attributes set: { Type EQ (4-leg animal-search) Interval IS 20ms Duration IS 100 s X GE 100 X LE 120 Y GE 140 Y LE 160 Class IS INTEREST } Sink “user” Source - Intermediate Nodes are task aware nodes- (eg: programmed with animal search routines) - Interpret the query - set-up a gradient : {matching data direction, status} - Nodes is found (based on attribute matching) - Application activates the sensor - Begin collecting data according to the attributes of the query - Sensor nodes generate data messages matching the interest -Eg: Data Msg: { Instance IS Elephant X IS 115 Y IS 150 Class IS DATA } Architecture: Re-enforced path

9. Implementation Architecture Two-tier architecture  First Tier Less resource constrained nodes (PC/104): 66Mhz CPU, 16MB RAM  Second tier small nodes: (Motes) 8 bit CPU, 8 K memory, 10 packets cache Software Publish/Subscribe data handling  A node receives data if it subscribes  interest  Interest is propagated and sets up gradients  Callback functions is invoked whenever relevant data arrives the node (by attribute marching- through the filter code)  A node that generates data publishes this fact by registering an interest in an interest  Optimization opportunity: don’t publish data that has no subscribers

10. Applications: A. In-network Aggregation An event is likely to trigger more than one sensor Opportunistic data aggregation:  Intermediate sensors cash relevant data  Duplicate data can be manipulated (e.g: suppressed) at intermediate nodes using filter with application specific constraints

11. Applications: B. Nested Queries Exploit correlation between different types of events to reduce duty cycle and energy consumption of sensor nodes Smaller nodes invoke “heavier” triggered nodes Since all nodes are task-aware nodes, instead of querying all initial nodes and then query the triggered node, a single nested query is sent to the triggered node Triggered node watches for a nested query and will subtask the query to initial nodes Nested queries localize data traffic near the triggering event rather than sending it to the distant user  reduced traffic volume and reduced latency

12. Evaluation Real time test-bed:  14 PC/104 sensor nodes  One Sink, 4 source nodes “sending data every 6 seconds”  All nodes configured with filters. Measurement difficulties  No tools to measure the operating node energy consumption  MAC protocol dominates the energy consumption! “here were we should work”

13. Aggregation Testing Goal: compare the energy expended per received event at the sink Methodology:  Have the filters suppress data messages with the same seq. number  Measure the total number of bytes normalized per event With event suppression “aggregation” the amount of bytes per application is constant regardless of the number of sensors. Aggregation saves about 40% of the traffic. The results were distorted as a result of high loss rate, poor MAC protocol performance Potential disadvantage of aggregation is increased latency, but this dependent on the filtering followed by the application

14. In-network data Aggregation

15. Nested Queries Proposition:  Nested queries should reduce network cost and latency Used same test bed:  “Expensive” audio sensors  Light sensors Measure the percentage of events successfully delivered to the sink

16. Nested Queries

17. Run-time matching Cost

18. Issues: MAC protocols Use application metrics to optimize diffusion  Rather the need to flood queries, use geographic information to direct them through the network Improve testing environment (metrics, tools)