Extending Network
Knowledge:
Making OLSR a Quality of
Service Conducive Protocol
|
|
|
Pedro Villanueva pvillanu@site.uottawa.ca |
|
Thomas Kunz tkunz@sce.carleton.ca |
|
Pramod Dhakal pdhakal@eion.com |
Outline
|
|
|
Introduction |
|
OLSR Protocol |
|
Extended Topology Knowledge (TK) |
|
Methodology |
|
Results |
|
Conclusions |
|
Future Work |
Introduction
|
|
|
MANETS require robust and efficient
routing protocols. |
|
|
|
Proactive protocols are preferred over
reactive protocols to support critical systems and QoS. |
|
|
|
OLSR reduces overhead. But, its partial
topology view constrains path computation. |
|
|
|
We gradually extend the partial network
view of OLSR. |
OLSR Protocol
|
|
|
OLSR (Optimized Link State Routing)
allows manipulating the amount of advertised topology information. |
|
|
|
OLSR reduces the amount of advertised
links, advertising nodes and forwarding nodes; by using the MPR mechanism. |
|
|
|
Periodic Hello and Topology Control messages
advertise the known topology. |
MPR Mechanism
Extended Topology
Knowledge
|
|
|
The partial view of the network
topology represents a severe shortcoming when constructing routing paths. |
|
|
|
Lack of network (i.e. load), node (i.e.
battery) and link (i.e. quality) status information acts against robustness
and reliability |
|
|
|
Multiple paths could be provided. |
Extended Topology
Knowledge
Redundant Topology
Information
|
|
|
|
Five strategies defining the links to
be advertised (TC_Redundancy). |
|
TC=0. Links to its MPR Selectors
(MPRS). |
|
TC=1. Every node, links to MPRs and
MPRSs |
|
TC=2. Every node, links to every
one-hop neighbour. |
|
TC=3. Selected MPRs advertise links to
MPRs and MPRSs |
|
TC=4. Selected MPRs advertise every
link to every one-hop neighbour. |
MPR Redundancy
|
|
|
Defines the desired number of one-hop
neighbours to reach every two-hop neighbour (MPR Coverage). |
|
|
|
Analyzed values: MPR =1,2,3. |
|
|
|
Effect: Increases the number of
advertising nodes, advertised links and forwarders. |
Methodology
|
|
|
|
NS-2 simulation using the OOLSR
implementation of OLSR (Hipercom project). |
|
|
|
Three different sets of scenarios |
|
Static scenarios without data traffic. |
|
Static scenarios with data traffic. |
|
Mobile scenarios with data traffic. |
|
|
|
Same scenarios were used for each
strategy. |
Simulation parameters for
static scenarios
Generated TC Messages
Overhead vs TK
Simulation parameters for
data traffic
MPRs vs TK
Delivery rate on static
networks
Simulation parameters for
mobile scenarios
Accuracy of TK
Per Packet Delay
NS-2 Bug
|
|
|
Generated outliers on packet delay |
|
Statistical analysis was used to remove
them |
Conclusions
|
|
|
High levels of TK can be achieved at
different costs without impacting delivery rate |
|
|
|
TC=2 maximizes TK. TC=0 minimizes
overhead. TC=4 offers a fair trade-off |
|
|
|
With data traffic no strategy keeps
large TK |
|
|
Conclusions
|
|
|
Extended TK may support construction of
better paths and QoS |
|
|
|
Higher reliability and robustness may
be achieved if new metrics are applied |
|
|
|
Results can be used as a guideline to
tune up OLSR |
Future Work
|
|
|
Advertise additional node and link
status information to apply more powerful metrics |
|
|
|
Use alternative metrics for path
computation |
|
|
|
Design new criteria to select the links
to be advertised (i.e. quality of links, node’s resources and network load) |
Slide 24
Extending Network
Knowledge:
Making OLSR a Quality of
Service Conducive Protocol
|
|
|
Pedro Villanueva pvillanu@site.uottawa.ca |
|
Thomas Kunz tkunz@sce.carleton.ca |
|
Pramod Dhakal pdhakal@eion.com |