[Olsr-users] OLSR configuration for mobility.
Tue Aug 25 20:16:00 CEST 2015
On Tue, Aug 25, 2015 at 7:35 PM, Dan O'Keeffe <(spam-protected)> wrote:
> I have a few questions regarding the best version of OLSRd to use in a
> mobile scenario, and also whether there are any best practices for
> configuring OLSRd for mobility.
> I'm currently using OLSRv1 0.6.3 (from the ppa at from ppa at
> https://launchpad.net/~guardianproject/+archive/ubuntu/commotion). My
> olsrd.conf is included at the end of this email.
First advise... if you want to keep using olsrd (v1), upgrade to the
most recent version.
> 1) Is OLSRv2 stable and if so is it now recommended to use OLSRv2 over
> OLSRv1? Is the feature set of OLSRv2 strictly better than that of OLSRv1
> (I'm only interested in features related to routing in a standalone MANET)?
Yes, I think its stable enough...
OLSRv2 includes the link speed into its metrics, OLSRv1 does not.
> 2) Do OLSRv2 and/or versions of OLSRv1 > 0.6.3 offer any potential
> performance improvements relevant to a mobile scenario?
> I'm thinking in
> particular of a properly tested implementation of optimized flooding of
> topology control/MPR selection messages (this forum post seems to
> indicate OLSRv1 0.6.x is configured to flood messages by default:
> ). Any other major (routing related) bugfixes in OLSRv2 or OLSRv1 >
> 0.6.3 would also be of interest.
I would advise NOT using MPR flooding... the current MPR algorithms
are pure greedy algorithm without a memory, I don't think they are a
good idea for mobile mesh networks.
> 3) I'm doing some emulation experiments with a distributed application
> in a MANET on top of the CORE/EMANE wireless network emulator. For my
> experiments I use the OLSR version above as the routing protocol. I'm
> having problems with OLSR performance where I see long periods with
> effectively 0 bitrate between two nodes communicating over a TCP socket.
> I suspect it is because the MANET routing is taking a long time to
> converge after routes change, since my network is dense enough that
> partitions shouldn't be that much of an issue. I made some changes to
> the default 0.6.3 conf to reduce the validity times of various control
> messages (HelloValidityTime 600.0 -> 60.0, TcValidityTime 300.0 -> 30.0,
> MidValidityTime 300.0 -> 30.0). This seemed to make the routing more
> responsive, but is this discourage for any reason? Are there any similar
> configuration tips that I should be aware of to help cope with mobility?
The most common change would be to reduce the Hello/TC intervals...
validity time could also be reduced, but the interval is more
Oh, with CORE/EMANE the link-speed detection of Olsrd2 will not work
because there is no Wifi-card to query.
Oh, and please have a look at the default configuration file provided
with the latest Olsrd... and only put values into your file that are
not the default.
More information about the Olsr-users