An Innovative Architecture for Context Foraging

1. An Innovative Architecture for Context Foraging Vassileios Tsetsos and Stathes Hadjiefthymiades Pervasive Computing Research Group Dept of Informatics and Telecommunications National and Kapodistrian University of Athens June 29, 2009 @ MOBIDE ’09, Providence, Rhode Island

2. Introduction & Motivation Nomadic computing Embedded devices with limited resources Frequent node relocation / ad hoc communications Broadcast-based data dissemination Context-aware applications A realistic assumption: not all nodes have sensors but all nodes require context inference Context Foraging: efficient collaborative sensing and distributed context inference Cyber Foraging Context Foraging Knowledge Foraging

3. Context Modeling Situation Environmental Situation User Situation is-a Fire InsideBuilding Happy Declarative context description Action Rules: Fire  BroadcastAlert (100) Situation Classification Rules (SCR): Temperature>80 ^ Humidity<10  Fire (100, 10) Context Spatial Validity Temporal Validity Environmental Context User Context is-a Mood Location Temperature vali : property of Context class Ci

4. Overall Architecture • Nodes are moving in random trajectories • Nodes have location sensors • Short range communications: WiFi, WiseMac, DSRC, IEEE 1609 WAVE, ZigBee • Not all nodes have sensors • Nodes are willing to cooperate Context-aware Nomadic Applications CR: Context Requestor CP: Context Provider CRel: Context Relay Context Modeling & Reasoning Sensors CRel Context Foraging CR CP Short Range Communications CP CRel SVCReq Node Architecture

5. Context Requestors Nodes that require context values not locally available periodically generate & disseminate Context Requests Context Request CReq := vali op Vi Viє R(Ci), op є{>, <, =, <=, >=} Spatial validity: the maximum valid range Temporal validity: the period of request retransmissions

6. Context Request Formation & Dissemination Local condition Remote condition SCR: Temperature>80 ^ Humidity<10  Fire (100, 10) Spatial Validity Temporal Validity CReq: Humidity<10 (100, 10) CP CRel 1 2 CR 1 CP CReq is retransmitted every 10 time units and within a range of 100 space units CRel SVCReq = 100

7. Context Providers • Nodes with sensors • They have an index structure that is used: • as a registry of all event filters received through context requests, • as a mechanism that matches incoming sensor values with event filters (context request conditions) • Index resembles a message forwarding engine of content-based network routers • A context request is always decomposed into atomic requests before registered in the index • Context Response • CRes:= vali = V • Spatial validity: equal to the request’s value

8. Context Providers’ Index 1. Context Request (Event filters) 2. Sensor value Humidity < 10 3. Context Response Humidity = 7 Humidity = 7 The responses are aggregated

9. Context Relays They just forward messages they have not forwarded before They may or may not be interested in the forwarded message contents

10. Notes on spatial/temporal validity • The requestor leaves the region after it has sent a Context Request • CPs transmit responses until the respective filter timeouts expire • The responses have spatial validity • CPs with registered event filters go away from the requestor • Time validity also resolves this problem • However, the new neighborhood may be interested in the responses as well

11. Lazy Context Requesting In many cases a situation may never occur or may occur only very seldom  context foraging scheme is not probably the most efficient solution (Temperature>80) ^ (Humidity<20) ^ (Smoke=true)  Fire Remote Condition Local Condition Local Condition • If Humidity >20 or Smoke = false then it makes no sense to request Temperature values • Proposed Solution: • Each SCR has a trigger level: • satisfied local conditions / all conditions • Context requests are only sent when this level exceeds a threshold that depends on the criticality of the respective application  affects the situation detection sensitivity

12. Performance Evaluation Setup • Metrics: • Average Situation Detection Ratio (ASDR) • Number of exchanged messages • Comparison with a Polling Scheme

13. Performance Results I

14. Performance Results II

15. Performance Results III Lazy Context Requesting CPol also uses Lazy Requesting ASDR’ is a more fair metric Real sensor values are expected to give higher ASDR values

16. Performance Results IV Without Lazy Requesting # exchanged messages: ~3-10 times lower

17. IPAC Platform Integrated Platform for Autonomic Computing (EU FP7) Middleware, service creation and execution environment Collaborative sensing, plug ‘n’ play sensors, short range communications Probabilistic broadcasting and epidemic information dissemination Applications/Trials: Autonomic networked objects in industry, Intelligent Transportation Systems, Crisis Management Context models and rules implemented through standard Prolog JIProlog engine was used (J2ME-compliant)

18. Conclusions & Future Work • A framework for fully ad hoc collaborative context awareness • It is based on pub/sub principles but tailored to the nomadic computing setting • In all scenarios tested, the number of messages is much lower than the polling-based scheme, with insignificant reduction in the situation detection capability of the nodes • Open issues • Context caching • Context aware configuration of time validity • Spatial validity without absolute positioning

19. Thank You!!