Middleware Services for Information Sharing in Mobile Ad-hoc Networks: Challenges and Approach

Thomas Plagemann1, Jon Andersson2, Ovidiu Drugan1, Vera Goebel1,Ellen Munthe-Kaas1, Katrine Skjelsvik1, Matija Puzar1, Norun Sanderson1

1University of Oslo, Department of InformaticsDistributed Multimedia Systems

http://www.ifi.uio.no/dmms

2Thales Communications AS, Oslo

This research is funded by the Norwegian Research Council in the IKT2010 programme, Project Nr. 152929/431

Outline• Introduction:

– Application domain– (State-of-the-Art)– Our Approach

• Four core components:– Knowledge management– Resource Management– Distributed Event Notification– Security

• Conclusions

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

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

CAMERA 1

Rescue and Emergency

Source: applica.no

Rescue and Emergency (cont.)

Source: applica.no

Rescue and Emergency (cont.)

Source: applica.no

Rescue and Emergency (cont.)

Source: applica.no

Rescue and Emergency (cont.)

Source: applica.no

Rescue and Emergency (cont.)

Source: applica.no

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

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

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

Ad Hoc InfoWare – OverviewWatchdogs

WatchdogsManager

WatchdogsExecution

Environment

Resource Manager

Replication Manager

ProposalUnit

Resource Monitor

Adjacency Monitor

Local Monitor

Resource Availability

Distributed Event Notification Service

Delivery

StateManagement

Availability & Scaling

StorageManagement

Knowledge Manager

Metadata & OntologyFramework

Data Dictionary Mgnt.LDD GDDD

Query Management

Profile Management

Security and Privacy Management

Authentication Access Control Key Management Encryption

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)

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

Knowledge ManagerMetadata and Ontology

Framework

Query Mgnt

Profile and Context Mgnt

XML Parser

Data Dictionary Mgnt

LDD GDDD

Resource Manager

Watchdogs Manager

WatchdogsExecution

Environment

WatchdogsKM

•Group concepts•Lists:

Groups &Resources

Resource Manager

Replication Manager

ProposalUnit

Resource Monitor

Adjacency Monitor

Local Monitor

Resource Availability

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)

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

8

Dens

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 Dens

6

5

4

7

1

3

2

DENSoverlay

MobileAd-hocNetwork

DENS – Subscription (cont.)Subscribe(Change in data)

Locate nodes that store the data with GDDD

Install watch dog

DENS components

SubDENS

PubDENS

DENSDENS

Watchdogs

WatchdogsManager

WatchdogsExecution

Environment

Distributed Event Notification Service

Delivery

StateManagement

Availability & Scaling

StorageManagement

DENS - Subscription

Subscribe(Event specification)

Propagation of subscription

A node in the chain becomes inaccessible

Propagate to successor

At least one DENS node does not know about this subscription → inconsistency

DENS – Detection & Propagation

Watch dog detects change and reports to known DENS nodes

DENS nodes report to head of chain

DENS – Detection & Notification

Notification of subscribers Consistency is no guaranteed

Propagate event and subscriber information

Notification

Back preassure of detected inconsistencies

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?

Security architecture (1)

IP

MAC layer

Physical layer

Application layer

Middleware

routing

DENS

Discard repeating messagesAuthentication barrier

Confidentiality barrierencryption

IP blacklist (firewall)

Clear: third parties can be used for message relaying

Key Management

Pa1 Pa2

Pa3Pa4

Pb1

CA(T)(top level)

CA(F) CA(H)CA(P)

RA(Pa) RA(Pb) RA(Fa) RA(Ha)(...) (...) (...)

Pa1

(...) (...) (...) (...)

Pa2 Pb1 Pb2PaN PbN Fa1 Fa2 FaN Ha1 Ha2 HaN

Pa5

Fa1

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