Content-Based Routing: Current Results

tansysoapweedRéseaux et Communications

16 févr. 2014 (il y a 2 années et 9 mois)

76 vue(s)

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

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

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 based

routing protocol (CCBR)

SMSCom kickoff meeting
-

Milan, December 19th, 2008

6

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

SMSCom kickoff meeting
-

Milan, December 19th, 2008

7

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>

SMSCom kickoff meeting
-

Milan, December 19th, 2008

8


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

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

19

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