Content-Based Routing: Current Results and Open Issues Gianpaolo Cugola DeepSE Group Dipartimento di Elettronica e Informazione Politecnico di Milano, Italy

SMSCom kickoff meeting - Milan, December 19th, 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, 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, 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, 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 based routing protocol (CCBR)

SMSCom kickoff meeting - Milan, December 19th, The CCBR protocol: The API listenFor(ComponentFilter, MessageFilter, AdditionalData, MessageListener, LeaseTime) Chooses the relevant components based on their current context Expressed as a set of tuples 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 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 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

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

SMSCom kickoff meeting - Milan, December 19th, 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 CCBR: A protocol for mobile & multi-sink WSNs Internet SMSCom scenarios Traditional scenarios

SMSCom kickoff meeting - Milan, December 19th, 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, 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, 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, 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, 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, On Adding In Network Aggregation Capabilities 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, 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, 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, References [EWSN09] G. Cugola, M. Migliavacca, “A Context and Content-Based Routing Protocol for Mobile Sensor Networks”. EWSN [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, [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 [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, [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, The CCBR protocol (cont.d) s1 s2 setComponentProperties s1 and s2 issue a listenFor n send n sends a message matching s2’s MessageFilter s2’s MF Only the ComponentFilter in s2’s listenFor matches n properties  only s2’s MessageFilter is stored by n

SMSCom kickoff meeting - Milan, December 19th, Some results Default scenario: 50 sensors, 3 sinks, 0.5 Km 2, 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