1 / 19

Content-Based Routing: Current Results and Open Issues

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. Conventional vs. Content-Based Routing. Conventional routing (Address-Based Routing)

dinos
Télécharger la présentation

Content-Based Routing: Current Results and Open Issues

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. 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

More Related