Content-Based Routing: Current Results and Open Issues Gianpaolo Cugola DeepSE Group Dipartimento di...

Content-Based Routing: Current Results and Open Issues

Gianpaolo CugolaDeepSE GroupDipartimento di Elettronica e InformazionePolitecnico di Milano, [email protected]

SMSCom kickoff meeting - Milan, December 19th, 2008 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


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


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


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)

We need a context & content basedrouting protocol (CCBR)


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

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 <attr. name, value>• E.g., <age,12>

send(Message)

• Expressed as a set of tuples <attr. name, value>


• 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

SMSComscenarios

Traditionalscenarios


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


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)


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


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]


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


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


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)


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


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.


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


Some resultsDefault 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

Content-Based Routing: Current Results and Open Issues Gianpaolo Cugola DeepSE Group Dipartimento di...

Documents

Transcript of Content-Based Routing: Current Results and Open Issues Gianpaolo Cugola DeepSE Group Dipartimento di...