OPHMR

1
OPHMR
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
2
Introduction

• Mobile Ad-Hoc Networks (MANETs) are comprised of
  mobile nodes (MNs) that are self-organizing and
  cooperative to ensure efficient and accurate
  packet routing between nodes (and, potentially,
  base stations)
• MANET topologies are unstable and shift
  frequently if MNs are particularly mobile
• routing protocols typically fall under three
  classifications
• proactive
• reactive
• hybrid

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
3
Proactive Protocols

• continuously exchange network topology
  information among MNs
• topology changes are constantly noted and
  distributed throughout the network
• this information is useful for achieving low
  latency data transmission
• proactive protocols are further classified into
  two subcategories
• link-state routing
• distance vector routing

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
4
Proactive Protocols - Categories

• link-state routing
• every MN receives a connectivity map
  representing the current state of the network
  topology
• the map is a graph which identifies the various
  links connecting all known MNs in the network
• each MN figures out the optimal next-hop to a
  destination when routing or sending messages
  using this graph
• the collection of calculated next-hops are
  cached into that MNs routing table (RT)

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
5
Proactive Protocols - Categories

• distance vector routing
• essentially, each MN shares its RT with all
  neighbouring (one-hop) MNs
• each MN maintains its own RT based on the
  messages it receives from its neighbours
• since MNs correspond solely with their
  neighbours, distance vector routing protocols
  typically require less computational overhead and
  protocol packets transmitted

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
6
Proactive Protocols - Drawbacks

• MNs within a MANET are often more mobile than
  traditional static networks
• topology updates will occur frequently,
  requiring more update messages to be sent
• proactive protocols generate a large number of
  control packets
• MNs have a fixed battery life and MANET channel
  capacity is limited

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
7
Reactive Protocols

• were introduced to fix some of the previously
  discussed complications with using proactive
  protocols in MANETs
• takes the lazy approach
• MNs react only on-demand to data transmission
  requests and perform path-finding operations only
  when necessary
• saves channel and battery usage by generating
  fewer control packets when there are no
  transmission requests

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
8
Proactive / Reactive Protocols - Drawbacks

• due to the diversity of MANET applications, it
  is challenging to design a single protocol that
  can operate at maximum efficiency over a wide
  range of operational conditions and network
  configurations
• reactive protocols work well with MANETs where
  the call-to-mobility ratio (CMR) is relatively
  low
• conversely, proactive protocols are well suited
  to MANETs where the CMR is high
• hybrid routing protocol
• MN is able to behave either proactively or
  reactively under different conditions

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
9
Routing Protocol Design Issues

• protocol hybridization
• a well-designed general-purpose routing protocol
  should be hybrid
• power efficiency
• attempt to minimize the power usage among MNs
  utilizing an arbitrary protocol
• optimal solution would vertically combine
  power-saving techniques at the physical, MAC, and
  network layers

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
10
Optimal Routing Protocol Characteristics

• many previous protocols emphasized power
  efficiency combined with adaptability, but fell
  short of hybridization
• the optimal routing protocol would incorporate
  all three desired routing protocol
  characteristics
• hybridization
• adaptability
• power efficiency

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
11
Enter the OPHMR

• the papers proposed solution is OPHMR
• Optimized Polymorphic Hybrid Multicast Routing
  protocol
• this protocol is empowered with different
  operational modes that are either proactive or
  reactive based on a MNs power residue, mobility
  level, and / or vicinity density level
• attempts to address the issues of power
  efficiency, latency, and protocol overhead in an
  adaptive manner

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
12
OPHMR - Polymorphism

• OPHMRs reactive behaviour is based on the
  On-Demand Multicast Routing Protocol (ODMRP)
• relatively simplistic. generates on-demand route
  paths for multicast message requests
• OPHMRs proactive behaviour is based on the
  Multicast Zone Routing (MZR) protocol
• builds a zone around each MN (in hops) and
  periodically sends updates within each defined
  zone
• since the OPHMR protocol is both hybrid and
  adaptive the authors dub it polymorphic

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
13
OPHMR - Optimization

• for added efficiency, OPHMR utilizes an
  optimizing scheme adapted from the Optimized Link
  State Routing (OLSR) protocol
• used to decrease the amount of control overhead
  that is produced

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
14
OPHMR Assumptions and Parameters

• each MN is assumed to have the ability to
  monitor and compute its residual battery power,
  mobility speed level, and vicinity density level
• the protocol algorithm requires four threshold
  parameters to be specified
• P_TH1, P_TH2 two power thresholds
• M_TH mobility speed threshold
• V_TH vicinity density threshold
• these threshold parameters dictate which
  behavioural mode of operation is used

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
15
OPHMR Behavioural Modes

• Proactive Mode 1 (PM1)
• when a MN is in PM1, it periodically updates its
  neighbourhood topology and multicast information
  by sending out an update packet with zone radius,
  R, set as the time-to-live (TTL) and the update
  interval set to a tunable parameter, i
• the MN maintains a neighbourhood routing table
  (NRT) which stores the topology information saved
  in any received update packets
• Proactive Mode 2 (PM2)
• the behaviour is similar to PM1, except the
  update interval is set to 2 i (less proactive)

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
16
OPHMR Behavioural Modes

• Proactive Ready Mode (PRM)
• a MN in PRM does not send out update packets,
  but instead maintains the NRT using information
  stored in any received update packets
• Reactive Mode (RM)
• a MN in RM does not send out update packets and
  discards any received update packets

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
17
OPHMR Algorithm
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
18
OPHMR Algorithm Errata

• when a MNs power level is high, the most
  proactive (PM1) mode is used so it can maintain
  topology information and react quickly to changes
• when a MNs mobility speed is high, the topology
  around the MN will change quickly
• thus, a proactive mode should be used to
  maintain better connectivity and stay aware of
  topology changes
• when a MNs vicinity density level is high,
  excessive update packets could jam the local
  connections in such a dense cluster
• thus, PRM is used, so that the MN can remain
  aware of the local topology without generating
  update packets

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
19
OPHMR Algorithm Errata

• upon a mode switch, a MN must inform its
  neighbours about its state change
• a notification packet is generated and
  broadcasted to all one-hop neighbours
• on receiving this packet, the neighbours will
  change the lifetime attribute in the sending MNs
  entry in their NRT
• i.e. for a mode change to PM1, the entrys
  lifetime is set to 2 i. for PM2, lifetime is 3
  i. etc.
• if no notifications are received by a MN for
  some preconfigured amount of time, it switches to
  RM

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
20
OPHMR Proactive Behaviour

• when a MN is in PM1 or PM2, it periodically
  sends out update packets which have their TTL set
  to the zone radius
• upon receiving a packet, if a MN is in PM1, PM2,
  or PRM, it saves the update information into its
  one-hop NRT, reduces the packets TTL by 1, and
  forwards it

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
21
OPHMR Reactive Behaviour

• when a MN has packets it wants to send to a
  multicast group or when it wants to join a
  multicast group, it sends out a Join_Request
  packet and waits for Join_Reply messages from the
  destination MNs
• MNs in a multicast group will update their
  Multicast Routing Tables (MRTs) when they receive
  a Join_Request
• intermediate MNs check their NRT to see if any
  neighbours belong to the destination multicast
  group
• if so, it unicasts the Join_Request to them

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
22
OPHMR Routing Tables

• each MN maintains both a NRT and MRT
• only MNs in proactive modes maintain the NRT
• a NRT entry contains routing information to the
  MN it corresponds to, including hop count,
  next-hop address, and lifetime
• when an entrys lifetime is exceeded, it is
  removed from the NRT
• MNs use their MRT to maintain both their
  multicast routing information and multicast
  routing topology

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
23
OPHMR Packet Structure
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
24
OPHMR Optimized Forwarding Mechanism

• the Multi-Point Relay (MPR) mechanism of OLSR
  is used to provide an optimized forwarding
  mechanism
• MNs will maintain a two-hop neighbourhood table
  (2NRT) that is used to calculate MPR information
• using MPR, certain MNs are selected to forward
  broadcast messages during the flooding process
• substantially reduces the message overhead
  compared to classical flooding
• each MN has a MPR set and will broadcast its MPR
  information in periodic updates
• when propagating update packets, only MPR MNs
  will forward

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
25
OPHMR MPR Computation

• terminology
• N the set of one-hop neighbours for a given MN
• N2 the set of two-hop neighbours for a given
  MN
• D(y) the degree of a one-hop neighbour, y
  (where y is a member of N), defined as the number
  of symmetric neighbours of y, excluding all
  members of N and the given MN
• each MN includes its one-hop neighbour
  information in each periodic update packet it
  transmits
• when a MN receives an update packet, it updates
  its 2NRT
• if the MN is a MPR, it replaces the one-hop
  information in the packet with its own info and
  forwards it on

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
26
OPHMR MPR Computation
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
27
OPHMR Energy Consumption Model

• energy consumption model used in OPHMR is
  Feeneys model
• network performance has four possible energy
  consumption states
• transmit, receive, idle, sleep
• the cost for a MN to send or receive a
  network-layer packet is modeled as a linear
  function
• Cost m size b
• b fixed cost associated with channel
  acquisition
• m incremental cost that is proportional to the
  size of the packet

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
28
OPHMR Energy Consumption Model

• the total cost of a packet is the sum of the
  costs incurred by the sending MN and all
  receivers
• potential receivers include the destination MN,
  any MNs within radio range of the sender, and any
  MNs within radio range of the destination MNs

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
29
Simulation Scenarios

• simulation-based comparisons were made between
  OPHMR, P_ZODMRP, ODMRP, and MOLSR
• P_ZODMRP is the predecessor to OPHMR that
  includes everything but the MPR-based
  optimization scheme
• simulation parameters are R and i
• R zone radius (in number of hops)
• i tuning factor used to determine the update
  interval and NRT entry lifetimes
• a high zone radius (R) and low update interval
  (i) indicates a more proactive behaviour, and
  vice-versa

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
30
Simulation Scenarios

• configuration
• MNs are placed randomly within a 2000m x 2000m
  area
• radio propagation range for each MN 225m
• channel capacity 2 Mpbs
• 802.11 MAC is used as the MAC protocol
• traffic type generated is a constant bit rate
• size of each data packet 512 B
• random waypoint model is used and pause time is
  zero for continuous mobility
• power distribution among nodes is variable to
  emulate realistic conditions

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
31
Simulation Scenarios

• three metrics are used in performance evaluation
• packet delivery ratio
• end-to-end delay
• average percentage of power conservation
• protocol parameter configuration
• 20 of MNs have 100 power, 20 have 90 power,
  20 have 80 power, and 40 have 75 power
• P_TH1 85, P_TH2 50, V_TH 6, M_TH 20 m/s

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
32
Simulation Results (Mobility)
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
33
Simulation Results (Vicinity Density)
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
34
Simulation Results (Traffic Load)
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
35
Simulation Results (Variation over Time)
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
36
Simulation Results (Different Threshold
Values)P_TH1 70, P_TH2 40
Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
37
Conclusions

• protocol performance as a function of mobility
  speed
• OPHMR has the best packet delivery ratio among
  all four protocols tested, especially at high
  speed
• OPHMR has the best end-to-end delay when R 3,
  i 5 (more proactive)
• for OPHMR, the more reactive behaviour (R 2, i
  8) achieved better power conservation than the
  more proactive modes
• protocol performance as a function of the
  vicinity density level
• when the total number of MNs is low, the
  proactive behaviour in the polymorphic protocols
  could increase overall performance due to the
  provision of fresher information about each MNs
  neighbourhood

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
38
Conclusions

• when MN density is high, more neighbours means
  more control overhead for pure proactive
  protocols and the reactive behaviour of
  polymorphic protocols could reduce the number of
  control packets while still guaranteeing good
  performance
• there is an optimal number of MNs per area that
  guarantees the best performance
• this can be used as a guideline for setting the
  vicinity density threshold value
• protocol performance as a function of traffic
  load
• with an increase of traffic load, most of the
  channel capacity is used by data packets and the
  deliverability is perfect until saturation occurs
• R and i had no impact on performance, but
  affected power conservation

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007
39
Conclusions

• protocol performance variation over time
• polymorphic protocols outperform the others and
  OPHMR is distinguishable
• protocol performance variation with different
  threshold settings
• a high proactivity level improves the protocols
  overall performance at the cost of reduced energy
  conservation and vice-versa

Gavin Mulligan / CS 6204 Mobile Computing /
November 6, 2007