Transcript slides

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 Informatics
Distributed 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
TAK
E 32
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 – Overview
Knowledge Manager
Metadata & Ontology
Framework
Data Dictionary Mgnt.
LDD GDDD
Query Management
Profile Management
Resource Manager
Watchdogs
Distributed Event
Notification Service
Watchdogs
Manager
Delivery
Resource Monitor
Replication
Manager
Proposal
Unit
Adjacency
Monitor
Local
Monitor
Watchdogs
Execution
Environment
Resource
Availability
State
Storage
Management Management
Availability & Scaling
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
Knowledge Manager
Metadata and Ontology
Framework
Data Dictionary Mgnt
LDD
GDDD
Query Mgnt
Profile and Context Mgnt
XML Parser
• Metadata and Ontology
Framework
• Data Dictionary
Management
– Local Data Dictionaries (LDD)
– Global Distributed Data
Dictionaries (GDDD)
• Query Management
• Profile and Context
Management
• XML Parser
Resource Manager
Replication
Manager
•Group
concepts
•Lists:
Groups &
Resources
KM
Resource Monitor
Watchdogs
Manager
Adjacency Monitor
Local Monitor
Proposal
Unit
Resource Availability
Resource Manager
Watchdogs
Execution
Environment
Watchdogs
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
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
3
Dens
7
5
1
8
2
4
DENS
overlay
6
Mobile
Ad-hoc
Network
DENS – Subscription (cont.)
Subscribe(Change in data)
Locate nodes that store the data with GDDD
Install watch dog
DENS components
Watchdogs
Distributed Event
Notification Service
Watchdogs
Manager
Delivery
Watchdogs
Execution
Environment
State
Storage
Management Management
Availability & Scaling
Sub
DENS
Pub
DENS
DENS
DENS
DENS - Subscription
A node in the chain becomes inaccessible
Propagation of subscription
Subscribe(Event specification)
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)
Application layer
DENS
Middleware
encryption
routing
IP
MAC layer
Physical layer
Confidentiality barrier
IP blacklist (firewall)
Authentication barrier
Discard repeating messages
Clear: third parties can be
used for message relaying
Key Management
Pa5
Pa1
Pa2
Pb1
CA(T)
(top level)
CA(P)
RA(Pa)
RA(Pb)
(...)
Pa1 Pa2
PaN
CA(F)
(...)
Pb1 Pb2
PbN
(...)
RA(Fa)
(...)
CA(H)
(...)
Fa1 Fa2
(...)
RA(Ha)
(...)
FaN
Ha1 Ha2
HaN
Pa4
Pa3
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