Efficient PeertoPeer Information Sharing over Mobile Ad Hoc Networks

1
Efficient Peer-to-Peer Information Sharing over
Mobile Ad Hoc Networks

• Mei Li Wang-Chien Lee Anand
  Sivasubramaniam
• Penn. State University
• May 2004 _at_ MobEAII _at_ WWW04

2
Roadmap

• Introduction
• Motivation
• Proposal
• Performance evaluation
• Conclusion future direction

3
Introduction

• Peer-to-peer (P2P) system
• Properties
• No designated servers
• Every node acts as a server as well as a client
• Gain popularity for wide spread exchange of
  resources/ information over larger number of
  peers
• Primary research issue resource (data, file,
  service) discovery
• Distributed hash tables (DHTs) facilitate
  efficient search in P2P
• Works on wired networks

4
Introduction (cont.)

• Mobile ad hoc networks (MANETs)
• Motivated by wireless technology and demands for
  user mobility
• An infrastructure-less communication structure
  self-formed by small devices (PDA, laptop)
  equipped with wireless communication interface
• Majority research focuses on lower layer (link,
  routing, network layers) to enable communication
  among nodes in MANETs
• Future MP3, DVD players equipped with wireless
  communication enable future application sharing
  text documents, music, movies on these devices
• Resemble peer-to-peer information sharing, called
  as P2P information sharing over mobile ad hoc
  network (MP2PIS)

5
Introduction (cont.)

• Primary challenges in MP2PIS
• Locate and obtain data objects (files, services,
  etc.) of interest efficiently in a potential
  large set of nodes with
• no central coordination
• limited radio range
• limited resource (energy)
• constant movements

6
Research issues

• Scalable to potential large network size
• Reasonable traffic, no performance bottleneck, no
  single point of failure
• Search (energy) efficient ? utilize physical
  proximity
• If multiple copies of the requested data object
  exist in the network, the closest one should be
  located and retrieved
• The search message should not be forwarded much
  further than the closest data object itself
• Node mobility
• Be able to find data object of interest even when
  nodes are constantly moving

7
Existing possible solutions

• Non-index
• Flooding
• High traffic, not scalable
• Cooperative caching
• Search success rate is unpredictable, highly
  depends on query locality

8
Existing possible solutions (cont.)

• Index
• Centralized directory
• Existence of performance bottleneck, single point
  of failure
• Can not make good use of physical proximity since
  every request has to go to the directory first
  even if there is a data object of interest stored
  at a nearby node
• Distributed index (e.g., DHTs) developed for P2P
• Did not consider physical proximity
• Did not consider node mobility

9
Research goal

• Design a distributed index structure
• Scalable
• Search efficient (utilize physical proximity)
• Adaptive to changes

10
Multi-level Peer Index (MPI) Overview To
address scalability

• Distributed index ? Hashing technique
• key ? geographical coordinate
• Search space is partitioned into subspaces and
  assigned to different nodes

11
MPI overview To address search efficiency

• Embed hierarchical spatial information in the
  index structure
• Possible strategies to embed spatial information
• Strategy 1
• Partition the network recursively into squares
  with decreasing size
• Nodes in each square collectively construct a
  hash index
• Strategy 2
• Draw circles centered at each node with
  increasing size
• Nodes in each circle collectively construct a
  hash index

12
Strategy 1

• Only approximate spatial information is embedded
• Peer 1 and 2 are close. However with this
  embedding strategy, peer 1 and 2 are not
  co-located in the same smallest square.
• A node resides at only one square with certain
  size ? low index storage requirement
• Among all smallest squares,
• Peer 1 only resides in the
• yellow one

1
2
13
Strategy 2

• Compared to strategy 1, more precise spatial
  information can be embedded
• Peer 1 and 2 are co-located in the smallest
  circle centered around peer 1
• A node resides in multiple circles with certain
  size ? high storage requirement
• Besides the circle centered around
• itself, Peer 1 also resides in
• other two circles centered
• around peer 3 and 4

4
3
2
1
14
MPI overview To address search efficiency
(cont.)

• Due to the simplicity and low storage
  requirement, we adopt Strategy 1 to embed spatial
  information

15
MPI overview To address adaptivity to changes
(node join/leave/move)

• Possible strategies
• Assign keys to a specific node located at (or
  near) the hashed coordinate
• Very sensitive to changes (especially movement)
• Assign keys to multiple nodes residing in a
  region covering the hashed coordinate
• Grid cell structure
• Nodes within a grid cell are collectively
  responsible for keys hashed into it
• Improve tolerance to node movement as well as
  node join/leave/failure

16
MPI overview To address mobility

• Two possible strategies
• Couple index information with location
  information ? Store tuple (key, location)
• Query can be resolved in one step
• High update overheads in case of constant
  movement and multiple data objects stored per
  node
• Decouple index information from location
  information ? Store tuple (key, NodeID) as index,
  tuple (NodeID, location) as location information
• Query is resolved in two steps find the ID of
  the node storing requested data, then find the
  location of this node
• Low update overhead even if a node stores
  multiple data objects since index is decoupled
  from location information
• To reduce update overheads, we adopt strategy 2
  (called as Multi-level location service (MLS)) to
  deal with node mobility

17
System Model

• Nodes have same radio range
• Use a geographical routing protocol, greedy
  perimeter stateless routing (GPSR), as basic
  routing protocol
• Each Node has two roles
• Form communication structure
• Provide data objects to share with other nodes
• We focus on the case that users are interested in
  obtaining one arbitrary (instead of all) data
  objects satisfying search criteria

18
Terminology

• Source node of a data object
• Node stores the data object
• Index entry (information) for a data object
• Tuple of (key, NodeID)
• Location entry (information) for a node
• Tuple of (NodeID, location)
• Index Node
• node that stores index entry
• Location Node
• node that stores location entry

19
Index structure of MPI

• Network are partitioned into m squares which are
  then partitioned into m smaller squares
  recursively
• Form into H-level hierarchy
• Every node in a square constructs a hash index
  collectively
• F (key, square boundary) ? physical coordinate in
  the square
• A node publishes each data object to the squares
  that this node resides in
• No performance bottleneck and single point of
  failure

20
Grid cell structure

• The lowest level square (minimum sized) is
  partitioned into grid cells
• Nodes in a grid cell becomes the index nodes for
  data objects hashed to the points in the grid
  cell
• To reduce index update cost, the size of grid
  cell should not be too large
• Side length of grid cell, L r/sqrt(2) (r
  radio range)
• In case of empty grid cell
• Apply secondary hashing function to find the
  surrogates index nodes

21
MPI level 4
Level 4
Level 1
Level 2
Level 3
1
Q
Q112
Q111
Q12
Q114
Q113
Q11
Q2
Q14
Q13
Q1
Q4
Q3
22
Benefits of MPI

• Data can always be found in the smallest enclosed
  square that source node and requester are
  co-located
• Overhead is reasonable
• Level of MPI is small

23
MLS

• Hashing
• F (NodeID, square boundary) ? physical coordinate
  in the square
• Using the same grid cell structure to decide
  location nodes
• To reduce location publishing cost, certain
  movements are hidden from location nodes at
  higher levels
• Nodes at lowest levels store precise location
  information
• Nodes at higher level store coarser location
  information
• Location node at level-i stores tuple (NodeID,
  level-(i1) square)
• As long as nodes are moving within level-(i1)
  square, no need to update the location
  information at level-i location nodes

24
MLS
Level 4
Level 1
Level 2
Level 3
1
Q
Q112
Q111
Q12
Q114
Q113
Q11
Q2
Q14
Q13
Q1
Q4
Q3
25
Search in MPI

• Data lookup
• Find the ID of the source node that stores the
  requested data object via MPI
• Location lookup
• Find the location of the source node via MLS
• Data retrieval
• Obtain requested data object from the source node

26
Node 1 requests data object B stored at Node 2
2
3. Data Retrieval
1
1. Data Lookup
2. Locaion Lookup
27
Simulation Setup

• Network Setup
• Node radio range 250 meter
• Network size 64, 256, 1024, 4096
• M 4
• Lowest level square consists of 4 grid cells
• Nodes are randomly placed in a square whose
  average density 4 nodes /per grid cell
• Random waypoint movement model, maximum moving
  speed 0 20m/s

28
Simulation Setup (cont.)

• Workload
• 10 data objects per node
• Average interval between two searches issued by
  the same node 20 seconds.
• Total simulation time 500 seconds

29
Simulation setup (cont.)

• Performance metrics
• Path length
• Hops traversed from requester to source node
• Path stretch
• real_path_length / ideal_path_length
• Message number
• Total number of messages processed by a node per
  second

30
Effect of network size
Path length increases slowly with network size
Path stretch is bound by 5
31
Effect of network size (cont.)
Message number of MPI is much lower compared to
flooding
32
Effect of node mobility

• Message number increases linearly with moving
  speed.
• Even at highest speed, MPI incurs much less
  messages than flooding.

33
Conclusion

• Proposed a distributed index structure,
  Multi-level Peer Index (MPI), enabling efficient
  data search over MANETs
• Preliminary evaluations demonstrate that MPI is
  scalable and adaptive to node mobility

34
Future Works

• Conduct in-depth analysis to obtain the optimal
  settings for level of MPI, and size of grid cells
• Perform more in-depth evaluation
• Expand the search ability of MPI to more complex
  queries
• range query, multi-attribute queries

35

• Thank you!