Adaptive Manet
Routing:
A Case Study
| Thomas Kunz | |
| Systems and Computer Engineering | |
| Carleton University |
| Adaptive Routing: | ||
| Mobile node adjusts its routing behavior based on its environment to improve routing performance | ||
| Adjustment is on a per-node basis, not global | ||
| Levels/Timescales of Possible Adjustments: | ||
| Short term: change its routing parameters based on environment | ||
| Mid-term: select stable route with enough bandwidth during Route Discovery | ||
| Long-term: select adequate routing protocol based on application etc | ||
| “Environment” means many things | |||
| Radio environment: could impact route stability and throughput | |||
| Traffic pattern: which flows, between which nodes | |||
| Mobility: topology changes, formation/destruction of links | |||
| First step: adapt to mobility at short time-scales | |||
| Identify mobility metric that | |||
| Captures the mobility-driven impact of routing protocol performance | |||
| Can easily be measured by a node, no extra hardware required | |||
| Is true across a number of mobility scenarios (different patterns/mobility models) and independent of mobility model parameters (RWP: Max/min speed, pause time, …) | |||
| Based on the metric, modify protocol to allow individual nodes to adapt their protocol behavior | |||
First Simulations: Mobility Metrics
Simulation Results: PDR vs. Mobility
Simulation Results: Link Duration
Simulation Results: Link Duration as Performance Predictor
Simulation Results: Link Breaks
Mobility Metrics: Individual Nodes
| OLSR has 4 control parameters | |||
| Hello Interval | |||
| TC Interval | |||
| MPR Coverage | |||
| TC Redundancy | |||
| Idea is to set parameters “appropriately” for network | |||
| They then apply to all nodes and for the whole time | |||
| Our modifications: | |||
| Monitor link breaks, define two thresholds (upper, lower) | |||
| Choose appropriate Hello Interval | |||
| more observed link breaks => higher mobility scenario => faster Hello | |||
| Add states to OLSR nodes that govern processing of Hello messages/selection of MPRs | |||
| Default OLSR, Fast OLSR, Fast Response | |||
| Implemented Adaptive OLSR in NS2 and evaluated performance through experiments | ||
| UM-OLSR version 0.8.8 for NS2 version 2.29 | ||
| The simulation area is 1000x1000m | ||
| 80 mobile nodes | ||
| Default IEEE 802.11 configuration: 250 m transmission range, 11 Mbps data rate | ||
| Traffic: 25 data sources, 4 packets/s, 64 byte packet size (CBR) | ||
| Simulation time is 900 seconds | ||
| Mobility model is “Random Trip Model” (avoids problems of RWP) | ||
| 10-5-1-1 is a mobility scenario with mean node speed of 10m/s, speed variation of 5m/s, mean pause time of 1 second and pause time variation of 1 second | ||
Simulation Results for Default OLSR
Adaptive OLSR vs. Default OLSR
Adaptive OLSR also better in Packet Latency
| Improved OLSR performance, in particular in more mobile scenarios | |||
| Idea of an adaptive protocol (nodes individually adjust their routing protocol behavior) has promise | |||
| Future Work (in increasing order of difficulty, no student right now to do any of it…. J) | |||
| Need more experimental validation | |||
| Different mobility models, in particular group mobility models | |||
| Different levels/type of offered load | |||
| Consider further changes to OLSR | |||
| TC Interval, MPR Selection, etc. | |||
| Apply these insights/ideas to other routing protocols | |||
| Consider additional avenues for adaptive behavior | |||
| A node that is currently routing multiple flows may find it beneficial to spend more efforts in routing that a node that is currently not used | |||