support technologies for self- managing situational computing gianpaolo cugola deepse group...

Support Technologies for Self-Managing Situational Computing

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

Como, 17-19 June 2009 1st SMSCom meeting 2

Focus(from the project breakdown point of view)


Issues

• Changes in the external environment– System level

• Nodes appearing, leaving, failing• Networking links appearing, failing (e.g.,

due to mobility)– Software level

• Services/components appearing, leaving, failing

• Such changes must be “tolerated”– We cannot accept a networking protocol

not able of delivering packets to moving nodes...

– ...or a middleware service breaking when a node fails

ApplicationsApplications

Middleware servicesMiddleware services

Networking services(Physical, MAC, Routing, Transport)


HW/SW Platform(PCs, but also sensors, actuators, embedded devices,...)


changeschanges


Issues

• (Some) changes must be reported to the application

– Offering the proper mechanisms to notify interested components about changes

• The middleware have to ease the job of application programmers

– Offering proper communication abstractions• Client/server interactions result in strong

coupling among components...• ...better adopt interaction styles supporting

flexible architectures, e.g. publish/subscribe and query/advertise

– Offering proper facilities to build self-managing applications

• E.g., facilities to discover new components, to monitor them, etc.







changeschanges

reportsreportsapiapi


Issues

• “Situational awareness” must integrate with the entire loop?

– Not only the current “situation” (i.e., context) has to be reported...

– ...but applications should also be allowed to behave differently based on the current situation

• “Context” has to become a first class concept at all layers







changeschanges

reportsreportsapiapi


networkingservices

networkingservices

middlewareservices

middlewareservices

applicationservices

applicationservices

Int. of ThingsInt. of Things traditional scenariostraditional scenarios

pastpast

presentpresent

futurefuture

Solutions: a quick look

CCBRContext & Content Based Routing

for Mobile WSNsCCBR

A-CBRAdvancedCBR: CBR + in-network aggregation

A-CBR

PerlaA language for Pervasive environments

Perla

CA P/SContext Aware Pub/Sub

CA P/S

REDSReconfigurable Event Dispatching

in large scale scenarios

REDS


Content-Based Addressing

• Conventional addressing– The sender explicitly specifies the intended message recipients– Using a unicast or multicast address

• Content-Based Addressing– 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 CBA (in general)

• CBA introduces a strong form of decoupling among communicating parties– Communication is asynchronous, multicast, anonymous,

implicit• Adding, removing or even moving components becomes

trivial


From CBA to CBR

• CBA can be used at different layers• At the middleware layer

– Linda-like systems– Content-based pub/sub systems– Query/advertise systems (e.g., most file-sharing infrastructures)

• At the routing layer– Content-Based Routing protocols

• In ad-hoc networks (e.g., MANET, WSNs)• In traditional networks (as an overlay networking protocol for

implementing CBA in large scale scenarios)

CBR techniques are the building blocks to develop advanced and flexible communication and coordination services

CBR techniques are the building blocks to develop advanced and flexible communication and coordination services


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 addressing for WSNs?

– Mapping a multicast, data-centric interaction on top of a conventional (unicast, address-centric) protocol may be very inefficient

– CBA is a much better answer


WSNs & 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 and 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• A PhD student at DEI is working 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: from the past to the future

• 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 pub/sub

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


AdvancedCBR: CBR + in-network aggregation• Research on CEP and DSMS mostly focused on language expressivity

– Systems are usually built around a centralized dispatcher• This approach does not fit the SMSCom requirements

– In terms of scale (internet wide computing)...– ... and dynamisms (ad-hoc networks, WSNs, P2P networks)

From CBR to a (sort of) distributed computing infrastructure built for a single task:

filtering and aggregating simple messages to produce complex ones

• Like CBR is the enabling technology for both P/S and Q/A such AdvancedCBR 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


AdvancedCBR: Open Issues

• Methodological and theoretical– How to exactly define simple messages, complex message, message

aggregates, message patterns, ....– How to model the routing infrastructure and the cost function that we

want to minimize by distributing the matching process– 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 P/S to Q/A 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.

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

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

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

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

support technologies for self- managing situational computing gianpaolo cugola deepse group...

Documents

transporthwsw platformpcs

embedded devices

interested components

new components

proper mechanisms

message content

middleware layerlinda

changesthe middleware