ophmr n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
OPHMR PowerPoint Presentation
Download Presentation
OPHMR

Loading in 2 Seconds...

  share
play fullscreen
1 / 39
william-osborn

OPHMR - PowerPoint PPT Presentation

196 Views
Download Presentation
OPHMR
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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 MN’s 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 paper’s 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 MN’s 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 • OPHMR’s reactive behaviour is based on the On-Demand Multicast Routing Protocol (ODMRP) • relatively simplistic. generates on-demand route paths for multicast message requests • OPHMR’s 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 MN’s power level is high, the most proactive (PM1) mode is used so it can maintain topology information and react quickly to changes • when a MN’s 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 MN’s 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 MN’s entry in their NRT • i.e. for a mode change to PM1, the entry’s 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 packet’s 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 entry’s 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 Feeney’s 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