middleware services for information sharing in mobile ad-hoc networks: challenges and approach...
Post on 20-Dec-2015
213 views
TRANSCRIPT
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 – Overview
Watchdogs
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 Manager
Metadata 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