Content-Based Routing: Current Results

tansysoapweedNetworking and Communications

Feb 16, 2014 (7 years and 10 months ago)


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


Conventional vs. Content
Based Routing

Conventional routing (Address
Based Routing)

The sender explicitly specifies the intended message recipients

Using a unicast or multicast address

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


Why CBR (in general)

CBR introduces a strong form of decoupling among
communicating parties

Communication is asynchronous, multicast, anonymous,

Adding, removing or even moving components becomes

SMSCom kickoff meeting

Milan, December 19th, 2008


Why CBR (in WSNs)

WSNs interactions are mainly

WSNs are designed to gather data and deliver it

... and

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


CBR & Context

Interaction in WSNs is often
, 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, 2008


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


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

SMSCom kickoff meeting

Milan, December 19th, 2008


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>


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

SMSCom kickoff meeting

Milan, December 19th, 2008


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


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






SMSCom kickoff meeting

Milan, December 19th, 2008


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


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

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


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


CBR as a general routing infrastructure

Two interaction paradigms gained the attention of researchers


Node may subscribe to event or publish them

Some technology must be used to route events (based on their content)
from publishers to subscribers


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


REDS: CBR for “traditional” networks

REDS: REconfigurable Dispatching System

REDS was born at Polimi as a

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

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

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


On adding context
awareness to CBR


Nodes can specify a set of properties (attribute
value pairs) as their

setContext(“Name=GPaolo, Site=Polimi, Dep=dei”)

setContext(“Name=Mario, Site=Polimi, Dep=energy”)

Subscriptions and publications may be restricted by context


Publish(“Cluster is DOWN!!”, “Dep==dei”)

The implementation

We are currently experimenting context and content
based routing in

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


On Adding In Network Aggregation

Capabilities to CBR

CBR routes

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


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


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



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



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


The CCBR protocol (cont.d)




s1 and s2 issue a listenFor



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


Some results

Default scenario: 50 sensors, 3 sinks, 0.5 Km
, 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