Data-Centric Networking 01204525 Wireless Sensor Networks and Internet of Things Chaiporn Jaikaeo (chaiporn.j@ku.ac.th) Department of Computer Engineering Kasetsart University Materials taken from lecture slides by Karl and Willig Cliparts taken from openclipart.org Last updated: 2018-10-27

Overview Interaction patterns and programming model Data-centric routing Data aggregation

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

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 Software bus Publisher 1 Publisher 2 Subscriber 1 Subscriber 2 Subscriber 3

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 = 35! t < 10 t > 20 t = 35! t > 20 t = 35! t < 10 or t > 20 t > 40 t = 35! t = 35! t < 10 or t > 20 t > 20 t < 10

Overview Interaction patterns and programming model Data-centric routing Data aggregation

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)

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

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?

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

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? Sink 1 Sink 2 Sink 3 Source X Sink Source X

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

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

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

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

Directed Diffusion - Example

Overview Interaction patterns and programming model Data-centric routing Data aggregation

Data Aggregation Packets may combine their data into fewer packets

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

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

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

Behavior of Partial State Records Distributive – end results directly as partial state record, e.g., MIN, MAX, SUM Algebraic – p.s.r. has constant size; end result easily derived, e.g., AVG Content-sensitive – size and structure depend on measured values (e.g., histogram) Holistic – all data need to be included, e.g., median Unique – similar to holistic ones, but only distinct data values are needed

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