1. Support Technologies for Self- Managing Situational Computing Gianpaolo Cugola DeepSE Group Dipartimento di Elettronica e Informazione Politecnico di Milano, Italy cugola@elet.polimi.it

2. Como, 17-19 June 20091st SMSCom meeting2 Focus (from the project breakdown point of view)

3. Como, 17-19 June 20091st SMSCom meeting3 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 Applications Middleware services Networking services (Physical, MAC, Routing, Transport) Networking services (Physical, MAC, Routing, Transport) HW/SW Platform (PCs, but also sensors, actuators, embedded devices,...) HW/SW Platform (PCs, but also sensors, actuators, embedded devices,...) changes

4. Como, 17-19 June 20091st SMSCom meeting4 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. Applications Middleware services Networking services (Physical, MAC, Routing, Transport) Networking services (Physical, MAC, Routing, Transport) HW/SW Platform (PCs, but also sensors, actuators, embedded devices,...) HW/SW Platform (PCs, but also sensors, actuators, embedded devices,...) changes reports api

5. Como, 17-19 June 20091st SMSCom meeting5 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 Applications Middleware services Networking services (Physical, MAC, Routing, Transport) Networking services (Physical, MAC, Routing, Transport) HW/SW Platform (PCs, but also sensors, actuators, embedded devices,...) HW/SW Platform (PCs, but also sensors, actuators, embedded devices,...) changes reportsapi

6. Como, 17-19 June 20091st SMSCom meeting6 networking services middleware services application services Int. of Thingstraditional scenarios past present future Solutions: a quick look CCBR Context & Content Based Routing for Mobile WSNs CCBR A-CBR AdvancedCBR: CBR + in-network aggregation A-CBR Perla A language for Pervasive environments Perla CA P/S Context Aware Pub/Sub CA P/S REDS Reconfigurable Event Dispatching in large scale scenarios REDS

7. Como, 17-19 June 20091st SMSCom meeting7 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

8. Como, 17-19 June 20091st SMSCom meeting8 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

9. Como, 17-19 June 20091st SMSCom meeting9 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

10. Como, 17-19 June 20091st SMSCom meeting10 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

11. Como, 17-19 June 20091st SMSCom meeting11 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 based routing protocol (CCBR)

12. Como, 17-19 June 20091st SMSCom meeting12 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 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 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 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

13. Como, 17-19 June 20091st SMSCom meeting13 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 E.g., send(Message) Expressed as a set of tuples

14. Como, 17-19 June 20091st SMSCom meeting14 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 SMSCom scenarios Traditional scenarios

15. Como, 17-19 June 20091st SMSCom meeting15 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

16. Como, 17-19 June 20091st SMSCom meeting16 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)

17. Como, 17-19 June 20091st SMSCom meeting17 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

18. Como, 17-19 June 20091st SMSCom meeting18 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

19. Como, 17-19 June 20091st SMSCom meeting19 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)

20. Como, 17-19 June 20091st SMSCom meeting20 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

21. Como, 17-19 June 20091st SMSCom meeting21 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.