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 |