Content-Based Routing: Current Results and Open Issues

1. Content-Based Routing: Current Results and Open Issues Gianpaolo Cugola DeepSE Group Dipartimento di Elettronica e Informazione Politecnico di Milano, Italy cugola@elet.polimi.it

2. Conventional vs. Content-Based Routing • Conventional routing (Address-Based Routing) • The sender explicitly specifies the intended message recipients • Using a unicast or multicast address • Content-Based Routing • Messages do not carry any (explicit) address... • ... they are (implicitly) addressed, based on their content • Nodes express their interests in receiving specific messages • The sender simply injects messages into the network • The network chooses the recipients based on the message content and on the expression of interests of each node SMSCom kickoff meeting - Milan, December 19th, 2008

3. Why CBR (in general) • CBR introduces a strong form of decoupling among communicating parties • Communication is asynchronous, multicast, anonymous, implicit • Adding, removing or even moving components becomes trivial SMSCom kickoff meeting - Milan, December 19th, 2008

4. Why CBR (in WSNs) • WSNs interactions are mainly data-centric... • WSNs are designed to gather data and deliver it • ... and multicast • Each sink collects data from different sensors • The data produced by each sensor may be of interest for different sinks • Which routing for WSNs? • Mapping a multicast, data-centric interaction on top of a conventional (unicast, address-centric) routing protocol may be very inefficient • CBR perfectly fits a data-centric interaction SMSCom kickoff meeting - Milan, December 19th, 2008

5. CBR & Context-Awareness • Interaction in WSNs is often context-aware, e.g. • A farmer could be interested in having the temperature reading (each hour) of young cattle only • In a logistics application different data must be collected for different kind of products • Encoding such context-awareness as part of message content in order to use standard CBR is possible... • ... but can lead to inefficiencies We need a context & content basedrouting protocol (CCBR) SMSCom kickoff meeting - Milan, December 19th, 2008

6. Chooses the relevant components based on their current context • Expressed as a set of tuples <attr. name, comp. op., value> • E.g., to listen only for messages sent by nodes installed on “young” cattles (age<12) • Chooses the relevant messages based on their content • Expressed as a set of tuples <attr. name, comp. op., value> • E.g., to listen only for messages carrying temperature readings greater than 38° (T>38) • Blindly transported to the relevant nodes • Expressed as a set of tuples <attr. name, value> • E.g., the metadata used to inform the relevant nodes that the temperature must be read every hour • A pointer to a function: void notifyMessage(Message) invoked when a matching message arrives • An integer expressing the period of validity (in seconds) for the expression of interest The CCBR protocol: The API listenFor(ComponentFilter, MessageFilter, AdditionalData, MessageListener, LeaseTime) SMSCom kickoff meeting - Milan, December 19th, 2008

7. Advertizes the component’s context • Expressed as a set of tuples <attr. name, value> • E.g., <age,12> • A pointer to a function: void notifyData(AdditionalData) invoked when new data arrives (as part of a listenFor operation invoked somewhere in the network) • Expressed as a set of tuples <attr. name, value> The CCBR protocol: The API setComponentProperties(Properties, DataListener) send(Message) SMSCom kickoff meeting - Milan, December 19th, 2008

8. CCBR: A protocol for mobile & multi-sink WSNs • In SMSCom we are interested in pushing WSNs to their extreme • To monitor people (e.g., elderly care, ...), animals (e.g., in farms, ...), mobile things in general (e.g., in logistics, ...) • Mobility is the distinctive characteristic of all these scenarios • Mobility of sensors and/or sinks • Moreover, in advanced scenarios we cannot ignore the presence of multiple sinks • One or more gateways toward fixed networks • PDAs in the hand of operators roaming around • Actuators acting as sinks SMSComscenarios Traditional scenarios Internet SMSCom kickoff meeting - Milan, December 19th, 2008

9. The CCBR protocol: General approach • CCBR [EWSN09] uses link layer broadcast whenever possible • To minimize traffic • Taking advantage of an ad-hoc MAC capable of optimizing power usage for broadcast communication • It uses an opportunistic/probabilistic approach • To limit the traffic while keeping good delivery in presence of very frequent changes of topology • Each node hearing a packet locally decides if re-forwarding it... • ...using its estimate distance from the sinks it decides if forwarding the packet and how long to delay it before forwarding... • ...if the same packet is received again the delayed packet is thrown away • Overhearing is also used as an implicit ack • An initial number of credits is assigned to packets to limit re-forwarding due to missed acks • The level of mobility is estimated (locally by sinks) and used to determine the frequency of refresh for routing information SMSCom kickoff meeting - Milan, December 19th, 2008

10. CCBR: Status and future plans • CCBR is implemented as a set of TinyOS modules for TelosB • We own 40 of them • It runs on an ad-hoc MAC provided by researchers at RWTH • We plan to “sell” the two as a “cross-layer” protocol for WSNs • There is an on-going master thesis on using gossip-like techniques to increase the protocol’s reliability • Promising results on initial simulations • Nicola Basilico is doing is minor research on adding in-network aggregation capabilities to CCBR • Some possible research proposals • Use CCBR (or a similar protocol) to provide other services, first of all service discovery on a WSN, in an efficient, fully distributed way • Use CCBR as the routing substrate for PERLA (or at least its incarnation in WSNs) SMSCom kickoff meeting - Milan, December 19th, 2008

11. CBR as a general routing infrastructure • Two interaction paradigms gained the attention of researchers • Publish-Subscribe • Node may subscribe to event or publish them • Some technology must be used to route events (based on their content) from publishers to subscribers • Query-Advertise • Nodes may advertise the resources/services they hold or they may query for specific resources/services • Some technology must be used to route queries (based on their content) only toward the nodes that hold matching resources/services CBR is the enabling technology for both SMSCom kickoff meeting - Milan, December 19th, 2008

12. REDS: CBR for “traditional” networks • REDS: REconfigurable Dispatching System • REDS was born at Polimi as a distributed, CBR framework for experimenting with CBR in large scale, dynamic networks • Internet wide networks, p2p networks, MANET • REDS provides reconfigurability at two levels • Logical/Software (Static): a well organized component-based design allows system integrators to build their instance of the REDS system by choosing among a set of predefined components (or to write their own versions) to determine several aspects [SEM06]: • The format of messages and subscriptions • The wire protocol used to transport messages and subscriptions • The architecture of the dispatcher • The routing and forwarding strategies • The strategies to deal with dynamic networks (e.g., p2p, MANET) • Physical (Dynamic) : REDS brokers are designed from the ground up to deal with reconfiguration • Supporting routing reconfiguration [ICDCS03], epidemic recovery of events lost during reconfiguration [ICDCS04], and CBR on mobile networks [TMC08] SMSCom kickoff meeting - Milan, December 19th, 2008

13. On adding context-awareness to CBR • The API • Nodes can specify a set of properties (attribute-value pairs) as their context • setContext(“Name=GPaolo, Site=Polimi, Dep=dei”) • setContext(“Name=Mario, Site=Polimi, Dep=energy”) • Subscriptions and publications may be restricted by context-filters • Subscribe(“Topic==SocialEvents”,”Site==Polimi”) • Publish(“Cluster is DOWN!!”, “Dep==dei”) • The implementation • We are currently experimenting context and content-based routing in REDS 2 • With different protocols to route context information (and subscriptions/messages accordingly) • Measuring the performance of such extension in different scenarios SMSCom kickoff meeting - Milan, December 19th, 2008

14. On Adding In Network AggregationCapabilities to CBR • CBR routes single messages based on their own content • It neither look at set of messages nor keep a history of them • It is often useful to aggregate single messages into complex ones • Complex Event Processing (CEP) extends the traditional publish/subscribe model to allow definition and capturing of composite events • E.g., notify me when a stock quote overcomes its average value as measured in the last 10 days • Data Stream Management Systems (DSMS) extend DBMS to query and filter (continuous queries) data streams coming from different sources • We are interested in developing techniques to perform such kind of filtering/aggregation in a distributed way (in network) From CBR to a (sort of) distributed computing infrastructure built for a specific task:filtering and aggregating simple messages to produce complex ones • Like CBR is the enabling technology for both PS and QA such ComplexCBR layer has the potential to enable not only CEP/DSMS but also complex searching infrastructures • E.g.: search for a set of services with the right characteristics to execute this kind of orchestration SMSCom kickoff meeting - Milan, December 19th, 2008

15. ComplexCBR: Open Issues • Methodological and theoretical • How to exactly define simple messages, complex message, message aggregates, message patterns, .... • Which language to filter and aggregate messages • Expressiveness vs. ease of distributing the matching process • System • How to combine routing with filtering/aggregation • The idea is that filtering/aggregation has to happen as soon as possible within the network of sources/recipients • How to implement the system in different scenarios • Internet wide (e.g., as part of REDS) • In mobile, wireless scenarios • In WSNs (e.g., by adding in network aggregation facilities to CCBR) SMSCom kickoff meeting - Milan, December 19th, 2008

16. Conclusions • CBR has the potential to become the communication layer on top of which building our Self-Managing Situated Computing Infrastructure • Supporting different networking scenarios... • From the Internet to the Internet of Things • ...but also different interaction patterns • From PS to QA to CEP and Complex Querying • Several research lines are open (and funny investigating) • We mentioned some, mostly focusing on the CBR layer itself... • ...many others exists if we focus on how CBR can be used to build higher level communication and coordination services SMSCom kickoff meeting - Milan, December 19th, 2008

17. References [EWSN09] G. Cugola, M. Migliavacca, “A Context and Content-Based Routing Protocol for Mobile Sensor Networks”. EWSN 2009. [SEM06] G. Cugola, G.P. Picco, “REDS: a reconfigurable dispatching system”. In Proceedings of the 6th international workshop on Software engineering and middleware (SEM'06), November 10, 2006. [ICDCS03] G.P. Picco, G. Cugola, A. Murphy, “Efficient Content-Based Event Dispatching in Presence of Topological Reconfigurations”. In Proceedings of the 23rd International Conference on Distributed Computing Systems, May 2003. [ICDCS04] P. Costa, M. Migliavacca, G.P. Picco, G. Cugola, “Epidemic Algorithms for Reliable Content-Based Publish-Subscribe: An Evaluation”. In Proceedings of the 24th International Conference on Distributed Computing Systems, 2004. [TMC08] L. Mottola, G. Cugola, G.P. Picco, “A Self Repairing Tree Topology Enabling Content-based Routing in Mobile Ad Hoc Networks”. In IEEE Transactions on mobile Computing, Vol. 7, No 8, Aug, 2008. SMSCom kickoff meeting - Milan, December 19th, 2008

18. The CCBR protocol (cont.d) • s1 and s2 issue a listenFor • Only the ComponentFilter in s2’s listenFor matches n properties only s2’s MessageFilter is stored by n • n sends a message matching s2’s MessageFilter s1 n setComponentProperties s2’s MF send s2 SMSCom kickoff meeting - Milan, December 19th, 2008

19. Some results Default scenario: 50 sensors, 3 sinks, 0.5 Km2, walking mobility, 0.1 msg/s, selectivity of filters: 10% Fixed scenario: Same as above but no mobility. Growing number of sinks, all receiving messages SMSCom kickoff meeting - Milan, December 19th, 2008