1 / 33

Wireless Embedded Systems (0120442x) Data-Centric and Content-Based Networking

Wireless Embedded Systems (0120442x) Data-Centric and Content-Based Networking. Chaiporn Jaikaeo chaiporn.j@ku.ac.th Department of Computer Engineering Kasetsart University. Materials taken from lecture slides by Karl and Willig. Overview. Interaction patterns and programming model

ida
Download Presentation

Wireless Embedded Systems (0120442x) Data-Centric and Content-Based Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Wireless Embedded Systems(0120442x) Data-Centric and Content-Based Networking Chaiporn Jaikaeo chaiporn.j@ku.ac.th Department of Computer EngineeringKasetsart University Materials taken from lecture slides by Karl and Willig

  2. Overview • Interaction patterns and programming model • Data-centric routing • Data aggregation • Data storage

  3. Interaction Patterns • Standard networking interaction • Client/server, peer-to-peer • Explicit or implicit partners, explicit cause for communication • Desirable properties for WSN (and other applications) • Decoupling in space – neither sender nor receiver need to know their partner • Decoupling in time – “answer” not necessarily directly triggered by “question”, asynchronous communication

  4. Publisher 2 Publisher 1 Subscriber 3 Subscriber 1 Subscriber 2 Software bus Publish/Subscribe Interaction • Achieved by publish/subscribe paradigm • Idea: Entities can publish data under certain names • Entities can subscribe to updates of such named data • Variations • Topic-based: • Inflexible • Content-based • use general predicates over named data

  5. t = 35! t = 35! t = 35! t = 35! t = 35! P/S Implementation Options • Central server: mostly not applicable • Topic-based: group communication (multicast) • Content-based: does not directly map to multicast • Needs content-based routing/forwarding for efficient networking t < 10 t > 20 t > 20 t < 10 ort > 20 t > 40 t < 10 ort > 20 t > 20 t < 10

  6. Overview • Interaction patterns and programming model • Data-centric routing • Data aggregation • Data storage

  7. One-Shot Interactions • Too much overhead to explore topology • For small data sets • Flooding/gossiping • For large data sets • Idea: exchange data summary with neighbor, ask whether it is interested in data • Only transmit data when explicitly requested • Nodes should know about interests of further away nodes • E.g., Sensor Protocol for Information via Negotiation (SPIN)

  8. (1) (2) (3) REQ REQ REQ DATA DATA DATA ADV ADV (4) (5) (6) ADV ADV ADV SPIN example

  9. Repeated Interactions • More interesting: Subscribe once, events happen multiple times • Exploring the network topology might actually pay off • But: unknown which node can provide data, multiple nodes might ask for data • How to map this onto a “routing” problem?

  10. Repeated Interactions • Idea: Put enough information into the network so that publications and subscriptions can be mapped onto each other • But try to avoid using unique identifiers • One option: Directed diffusion • Try to rely only on local interactions for implementation

  11. Sink 1 Sink 2 Sink 3 Source Source X X Sink Directed Diffusion • Two-phase Pull • Phase 1: nodes distribute interests • Interests are flooded in the network • Apparently obvious solution: remember from where interests came, set up a convergecast tree • Problem?

  12. Direction Diffusion • Option 1: Node X forwarding received data to all “parents” in a “convergecast tree” • Not attractive, many needless packet repetitions over multiple routes • Option 2: node X only forwards to one parent • Not acceptable, data sinks might miss events

  13. Direction Diffusion • Option 3: Only provisionally send data to all parents, but ask data sinks to help in selecting which paths are redundant, which are needed • Information from where an interest came is called gradient • Forward all published data along all existing gradients

  14. Gradient Reinforcement • Gradients express not only a link in a tree, but a quantified “strength” of relationship • Initialized to low values • Strength represents also rate with which data is to be sent • Intermediate nodes forward on all gradients • Can use a data cache to suppress needless duplicates

  15. Directed Diffusion • Second phase: Nodes that contribute new data (not found in cache) should be encouraged to send more data • Sending rate is increased, the gradient is reinforced • Gradient reinforcement can start from the sink • If requested rate is higher than available rate, gradient reinforcement propagates towards original data sources • Adapts to changes in data sources, topology, sinks

  16. Directed Diffusion - Example

  17. Directed Diffusion – Extensions • Two-phase pull suffers from interest flooding problems • Mitigated by combining with topology control, in particular, passive clustering • Geographic scoping & directed diffusion

  18. Directed Diffusion – Extensions • Push diffusion – few senders, many receivers • Same interface/naming concept • Do not flood interests, but flood the data • Interested nodes will start reinforcing the gradients • Pull diffusion – many senders, few receivers • Still flood interest messages, but directly set up a real tree

  19. Overview • Interaction patterns and programming model • Data-centric routing • Data aggregation • Data storage

  20. Data Aggregation • Packets may combine their data into fewer packets • Data Aggregation • Depending on network, aggregation can be useful or pointless

  21. Metrics for Data Aggregation • Accuracy • E.g., differences, ratios, statistics • Completeness • A form of accuracy • Latency • Message overhead

  22. Expressing Aggregation Request • One option: Use database abstraction • Request by SQL clauses • E.g., SELECT AVG(temperature), floor WHERE temperature > 30 GROUP BY floor HAVING floor > 5

  23. Intermediate Results • Aggregation requires partial information to represent intermediate results • Called Partial State Records • E.g., to compute average, sum and number of previously aggregated values is required • Expressed as <sum,count> • Update rule: • Final result is simply s/c

  24. Categories of Aggregation • Classified by properties of aggregation functions • Duplicate sensitive • E.g., median, sum, histograms • Insensitive: maximum or minimum • Summary or examplary • Composable: for aggregation function f, there exists a function g such that f(W1W2) = g( f(W1), f(W2) ) • Monotonic

  25. Categories of Aggregation • Behavior of partial state records • Distributive – end results directly as partial state record, e.g., MIN • Algebraic – p.s.r. has constant size; end result easily derived • Content-sensitive – size and structure depend on measured values (e.g., histogram) • Holistic – all data need to be included, e.g., median • Unique – only distinct data values are needed

  26. Placement of Agg. Points • Convergecast trees provide natural aggregation points • But: what are good aggregation points? • Ideally: choose tree structure that minimizes size of aggregated data • Figuratively: long trunks, bushy at the leaves • In fact: a Steiner tree problem in disguise • Good aggregation tree structure can be obtained by slightly modifying Takahashi-Matsuyama heuristic

  27. Placement of Agg. Points • Alternative: look at parent selection rule in a simple flooding-based tree construction • E.g., first inviter as parent, random inviter, nearest inviter, … • Result: no simple rule guarantees an optimal aggregation structure

  28. Broadcasting Aggregated Value • Goal: distribute an aggregate of all nodes’ measurements to all nodes • Construcing |V| convergecast trees not appropriate • Idea: Use gossiping combined with aggregation • Compute new aggregatewhen receiving new value • If significant, gossip

  29. Overview • Interaction patterns and programming model • Data-centric routing • Data aggregation • Data storage

  30. Data-Centric Storage • Goal: Store data for later retrieval • Difficult in absence of gateway nodes/servers • Question: Where to put a certain datum? • Avoid a complex directory service

  31. Data-Centric Storage • Idea: Let name of data describe which node is in charge • Data name is hashed to a geographic position • Node closest to this position is in charge of holding data • Similar to peer-to-peer networking (DHT) • Geographic Hash Tables (GHT) • Use geographic routing to store/retrieve data at this “location” (in fact, the node)

  32. Geographic Hash Tables • Nodes not available at the hashed location • Use nearest node • Failing and new nodes • Replicate data to neighbors • New nodes learn existing value-key pairs from neighbors • Limited storage per node • Distribute data to other nodes in the vicinity Key location Timeout New keylocation

  33. Conclusion • Data-centric networking considerably changes communication protocol design paradigms • Nicely supports an intuitive programming model – publish/subscribe • Aggregation is a key enabler for efficient networking

More Related