Outline

1. Middleware Services for Information Sharing in Mobile Ad-hoc Networks: Challenges and ApproachThomas Plagemann1, Jon Andersson2, Ovidiu Drugan1, Vera Goebel1,Ellen Munthe-Kaas1, Katrine Skjelsvik1, Matija Puzar1, Norun Sanderson11University of Oslo, Department of InformaticsDistributed Multimedia Systemshttp://www.ifi.uio.no/dmms2Thales Communications AS, Oslo This research is funded by the Norwegian Research Council in the IKT2010 programme, Project Nr. 152929/431

2. Outline • Introduction: • Application domain • (State-of-the-Art) • Our Approach • Four core components: • Knowledge management • Resource Management • Distributed Event Notification • Security • Conclusions

3. Ad-hoc Networks • Characteristics: • Several mobile or portable devices, e.g., PDA’s, laptops, etc. • Small wireless networks, e.g., IEEE 802.11, Bluetooth, IrDA, etc. • Mobile devices are part of the network if they are in close proximity to the network • Infrastructure-less, ”pure” ad-hoc networks • Main research focus (see IETF WG MANET): • Routing • Service location

4. Application Domain • Application scenario: emergency and rescue • Important information: • Medical records of injured persons • Layout of buildings, installations, dangerous goods • Collected evidence • Status reports for coordination • Information sources: • Mobile end-user devices, stationary devices, Internet • Information access and sharing is mission critical • Cooperation is necessary, but not always desired

5. Rescue and Emergency Source: applica.no

6. Rescue and Emergency (cont.) Source: applica.no

7. Rescue and Emergency (cont.) Source: applica.no

8. Rescue and Emergency (cont.) Source: applica.no

9. Rescue and Emergency (cont.) Source: applica.no

10. Rescue and Emergency (cont.) Source: applica.no

11. Rescue and Emergency (cont.) • Lesson learned: information sharing and coordination is mission critical! • But what are the concrete applications? • Sharing of medical information • Collection of evidence • Prediction of possible threats • Access to maps and building plans • Dispatching and coordination of rescue personell and equippment

12. State-of-the-Art • ”Classical” middleware: • STEAM • Ensemble, OpenORB, dynamicTAO, LegORB, MULTE-ORB • Enabeling middleware: • iMAQ, Jini, SLP, Proem, JXTA, 7DS, SyncML • Replication, service location, tuple spaces: • ASF, Coda • JetFile, Farsite, PAST • Napster, Gnutella, CAN, Chord, LANES • LIME, XMIDDLE • Content integration and management: • TSpaces, SDL, SDS, XML, RDF, DAML, DIANE

13. Our Approach • Using a-priori phase & knowledge: • Class of device, e.g., which tasks should be supported where • Trust within organizations • Agreements between organizations (ontologies, meta-data, …) • Coordination of knowledge management and resource managemet • Integration of information • Information, data, meta-data, resources • Context awareness • Resource and QoS aware data placement • Separation of mechanisms and policies • Identification of (and focus on) four central tasks: • Knowledege Management • Event Notification • Resource Management • Security

14. Knowledge Manager Resource Manager Watchdogs Distributed Event Notification Service Resource Monitor Metadata & Ontology Framework Replication Manager Watchdogs Manager Delivery Adjacency Monitor Data Dictionary Mgnt. State Management Storage Management LDD GDDD Watchdogs Execution Environment Local Monitor Proposal Unit Query Management Profile Management Resource Availability Availability & Scaling Security and Privacy Management Authentication Access Control Key Management Encryption Ad Hoc InfoWare – Overview

15. Knowledge Management • Main objective: to manage knowledge sharing and integration in the mobile adhoc network. • Provide services that allow relating metadata descriptions of information items to a semantic context (through ontologies). • Adds a layer of knowledge to the information shared in the network. • Only give the tools, not decide usage & content. • Not addressing learning of new knowledge (in participating organizations)

16. Knowledge Manager Metadata and Ontology Framework Data Dictionary Mgnt LDD GDDD Query Mgnt Profile and Context Mgnt XML Parser KM - subcomponents overview • Metadata and Ontology Framework • Data Dictionary Management • Local Data Dictionaries (LDD) • Global Distributed Data Dictionaries (GDDD) • Query Management • Profile and Context Management • XML Parser

17. KM Resource Manager Watchdogs • Group • concepts • Lists: • Groups & • Resources Replication Manager Resource Monitor Watchdogs Manager Adjacency Monitor Local Monitor Watchdogs Execution Environment Proposal Unit Resource Availability Resource Manager

18. DENS • Important: separation of mechanisms and policy • Event notification service as mechanisms • Nodes can specify and subscribe to events: • New node joins the network • New data appears • Important data values have changed • Task of recognizing events is delegated to watch dogs • Each subscriber is notified over events and can react to events • Concept: distributed event notification service (DENS)

19. Why DENS? • Goals: • Beeing informed as good as possible • Beeing up-to-date as good as possible • Synchronous services do not work in mobile ad-hoc networks • Connections are interrupted • Network might be partitioned • Central solutions do not work • If server and client cannot communicate the service is not existing • Scalability and single point of failure • Handle network partitioning and connection failures gracefully: • Provide service under all conditions (with lower quality if otherwise impossible) • Establish full quality service as quickly as possible

20. DENS-architecture • Distributed event dispatcher (nodes running DENS) • DENS-nodes are organized in an overlay (chain vs. multicast), and cooperate to deliver events • Subscriptions are replicated • DENS-nodes are mobile DENS overlay Dens Dens Dens 7 3 5 Mobile Ad-hoc Network 1 8 2 6 4

21. DENS – Subscription (cont.) Subscribe(Change in data) Locate nodes that store the data with GDDD Install watch dog

22. DENS components Watchdogs Distributed Event Notification Service Watchdogs Manager Delivery State Management Storage Management Watchdogs Execution Environment Availability & Scaling Sub DENS Pub DENS DENS DENS

23. A node in the chain becomes inaccessible Propagation of subscription Subscribe(Event specification) DENS - Subscription Propagate to successor At least one DENS node does not know about this subscription → inconsistency

24. DENS nodes report to head of chain DENS – Detection & Propagation Watch dog detects change and reports to known DENS nodes

25. Notification of subscribers Notification Propagate event and subscriber information Back preassure of detected inconsistencies DENS – Detection & Notification Consistency is no guaranteed

26. Security • Limited resources • Authentication of nodes • Groups: forming, merging, splitting, ... • Confidentiality: different levels • Cooperation between groups • Protection from external and internal attacks • Users’ involvement reduced to a minimum • 1. Step: Secure infrastructure • 2. Step: How to integrate security appropriately?

27. Security architecture (1) Application layer DENS Middleware encryption Confidentiality barrier IP routing IP blacklist (firewall) Authentication barrier Discard repeating messages MAC layer Clear: third parties can be used for message relaying Physical layer

28. Pa1 Pa3 Pa2 Pa4 Pb1 Pa5 Fa1 Key Management

29. Conclusions • Grand Challenge: • Simplify application development for MANETS with appropriate middleware services • Concrete challenges: • Tradeoff between abstraction and awarness of location, resources, context, …. • Tradeoff between non-functional requirements, e.g., performance vs. security and availability • Using a-priori phase & knowledge: • Class of device, e.g., which tasks should be supported • Trust within organizations • Agreements between organizations (ontologies, meta-data, …) • Development and test environment