250 likes | 383 Views
This paper presents the Tiny Aggregation Service (TAG), a system designed for optimizing data aggregation in ad-hoc sensor networks. TAG employs a basic query interface resembling SQL to facilitate efficient distribution of queries, while maintaining power and time efficiency. It utilizes a routing tree to ensure that queries reach all nodes without duplications. Fundamental to TAG is its support for high-level language abstractions that lead to various optimization techniques. The study also explores the benefits of reduced communication overhead and loss tolerance strategies essential for network reliability.
E N D
TAG: a Tiny Aggregation Service for Ad-Hoc Sensor Networks Samuel Madden, Michael J. Franklin, Joseph Hellerstein, Wei Hong Published in 2002 Research funds coming from IBM, Intel, and Microsoft Andrew OfstadECE 256, Spring 2008
Motivation • Sensor networks are computers • Applications extract Info from network • Aggregation saves resources • Philosophy: Aggregation as network service • Extract info aggregation to higher level Andrew OfstadECE 256, Spring 2008
TAG Contributions • Basic query interface (like SQL) • Power and time efficient distribution of queries • Query Language Abstraction leads to Optimizations • High level language leads to network loss techniques Andrew OfstadECE 256, Spring 2008
Ad-Hoc Routing • Doesn’t matter, as long as: • Query requests deliverable to all nodes • Provides routes from every node to root • No duplicate messages received by node • TAG uses a routing tree Andrew OfstadECE 256, Spring 2008
Routing Tree Root P = Parent L = Level P: None L: 0 1 P: 1 L: 1 P: 1 L: 1 2 3 P: 2 L: 2 6 P: 3 L: 2 P: 3 L: 2 4 5 Andrew OfstadECE 256, Spring 2008
Query Model • SQL style query syntax • Table called “sensors” • Schema known to base station • Append-only relational database Andrew OfstadECE 256, Spring 2008
TAG Query Syntax Example SELECT AVG(volume), room FROM sensors WHERE floor = 6 GROUP BY room HAVING AVG(volume) > threshold EPOCH DURATION 30s Andrew OfstadECE 256, Spring 2008
TAG Query Syntax SELECT {agg(expr), attrs} FROM sensors WHERE {selPreds} GROUP BY {attrs} HAVING {havingPreds} EPOCH DURATION i Andrew OfstadECE 256, Spring 2008
Aggregate Functions (agg) e(<S, C>) = S/C 3 Components: 1) Merging function f<z> = f(<x>, <y>) 2) Initializer i 3) Evaluator e 4 <S4, C4> f(<S2, C2>, <S3, C3>, <S4, C4>) <S2, C2> f(<S1, C1>, <S2, C2>) = <S1 + S2, C1 + C2> 3 2 <S3, C3> i(x) = <x3, 1> 1 <S1, C1> i(x) = <x1, 1> Andrew OfstadECE 256, Spring 2008
Classes of Aggregates • Duplicate Sensitivity • Exemplary or Summary • Monotonicity • Amount of Partial State Information • Distributive • Algebraic • Holistic • Unique • Content Sensitive Classification based on four categories: Andrew OfstadECE 256, Spring 2008
Attribute Catalog • Queries contain named attributes • Each mote has catalog of supported attributes • Assume central query processor stores attributes of motes • Mote returns NULL if attribute not supported • Increases scalability Andrew OfstadECE 256, Spring 2008
Algorithm • Two Phases: • Query Distribution • Collection • Single aggregate value every epoch • Aggregation before propagation • Children deliver partial state in time interval specified by parent Andrew OfstadECE 256, Spring 2008
Collection Andrew OfstadECE 256, Spring 2008
Grouping • Specified by GROUP BY query clause SELECT AVG(volume), room FROM sensors WHERE floor = 6 GROUP BY room HAVING AVG(volume) > threshold EPOCH DURATION 30s • Each sensor reading in single group • Groups partitioned by attributes Andrew OfstadECE 256, Spring 2008
Grouping Example Andrew OfstadECE 256, Spring 2008
A Few Advantages… • Decreased Communication • Nodes send one message per epoch • “Lost Nodes” can reconnect Andrew OfstadECE 256, Spring 2008
Simulation • Done in Java • Java Objects passed as messages Andrew OfstadECE 256, Spring 2008
Optimizations • Snooping on Shared Channels • Nodes can overhear missed query • Nodes can exclude certain messages • Hypothesis Testing • Somewhat query specific • Nodes don’t send data if irrelevant • Ex: root finds level 1 min, then uses “having” to narrow down query Andrew OfstadECE 256, Spring 2008
Optimizations Andrew OfstadECE 256, Spring 2008
Improving Loss Tolerance Important because single node loss causes entire subtree loss… • Each node keeps track of neighbor link quality • Keeps proportion of messages received • Chooses parent’ over weaker parent • Node chooses a new parent if no messages received over set time Andrew OfstadECE 256, Spring 2008
Loss Tolerance Andrew OfstadECE 256, Spring 2008
Realistic Simulation Caching: use old “cached” information when new info not received from children Andrew OfstadECE 256, Spring 2008
Implementation • Prototype with TinyOS motes Andrew OfstadECE 256, Spring 2008
Conclusions • High Level Query Language • Aggregation and Bandwidth Reduction • Tight network integration, optimizable • Currently working towards “event driven” model Andrew OfstadECE 256, Spring 2008
Thanks! Q and A Andrew OfstadECE 256, Spring 2008