Middleware Services for Information Sharing in Mobile Adhoc Networks: Challenges and Approach Thomas

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., PDAs,
  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
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
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
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
8
1
6
2
4
21
DENS Subscription (cont.)
Subscribe(Change in data)
Locate nodes that store the data with GDDD
Install watch dog
22
DENS components
Sub DENS
Pub DENS
DENS DENS
23
DENS - Subscription
Propagate to successor
At least one DENS node does not know about this
subscription ? inconsistency
24
DENS Detection Propagation
Watch dog detects change and reports to known
DENS nodes
25
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
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