Optimizing dense meshes for call capacity and bandwidth

Revision as of 10:12, 7 February 2011 by Elektra (talk | contribs) (→‎Step three)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

In densly populated areas where many MPs are deployed in close proximity, you can and should adapt the MP configuration in order to optimize network performance. The steps to achieve this are simple and have been tested in Orange Farm (a densely populated township, which is located about 40km outside of Johannesburg/South Africa)

Step one

Configure the radio interfaces to use 802.11g-only mode.

The 802.11 WiFi protocol is coordinating channel access much faster in g-only mode. It takes less time for each device to gain access to the channel and perform a transmission. This is particularly helpful for VOIP (Voice Over IP), since VOIP requires the transmission of many, relatively small data packages.

The easiest way to perform this step is to use the LUCI web interface. Connect to the MP IP with a browser and go to Network -> Wifi -> WIFI0. Find the pull-down field named "Mode" and select "802.11g" in the section "Device wifi0".

Step two

Increase the data rate of broadcasts

The protocol messages of routing protocols are typically send as broadcasts. Broadcasts are send at basic rate. If you run a mesh in 802.11b/g mode the speed of basic rate transmissions is 1Mbit/s. In 802.11g-only mode this means 6Mbit/s. While broadcast messages are typically small, they occupy a lot of air time. At lowest data rate the transmissions have the greatest range.

Slow, long range broadcasts are not desirable in a mesh where the node density is dense. Slow transmissions are likely to create a lot of interference in a large area and consume a lot of airtime.

The easiest way to perform this step is to use the LUCI web interface. Connect to the MP IP with a browser and go to Network -> Wifi -> WIFI0. Scroll down to the section "Interfaces" and select the button "Additional field". Select "Multicast rate". A new input box will appear. If you enter 18000 in this box, the multicast rate will be set to 18Mbit/s. Available data rates are 6, 12, 18, 24, 36, 48, 54 Mbit. Note that you have to enter the rate in kilobit, so multiply the value in Mbit by 1000.

You will need to perform some experiments to find the best multicast data rate. Note that increasing the broadcast rate will reduce the BATMAN score. If it is set too high, long links will be ignored by the mesh protocol, because the protocol messages are not travelling far enough. Shorter, faster links will be preferred. In high node density areas this is desirable.

You can mix different multicast rate settings in your mesh. Increase it in dense areas, slow down or don't make changes if you need to connect nodes that need long links to connect to the mesh cloud.

Step three

Increase the BATMAN protocol message interval

BATMAN - the default mesh routing protocol in the MP - sends protocol messages, called Originator messages (OGMs) at a fixed interval. By default it is 1000ms - one second. This is quite often, since the protocol forwards and repeats messages from other nodes. This value has been chosen initially to test the scalability of the protocol from the protocol developers point of view, not to minimize overhead. Since our mesh is very static (MPs should be placed on roofs and they usually don't move or go up and down all the time) this interval can be increased to several seconds.

This setting can be changed by connecting to the CLI interface of the MP, using the uci command. Note: The interval must be entered in miliseconds.

root@MP:~# uci set batmand.general.originator_interval=5000
root@MP:~# uci commit

We are configuring the BATMAN OGM interval to 5 seconds in this example. This will reduce the protocol overhead by a factor of five compared to the default setting.

Step four

Use ah-demo mode instead of ad-hoc mode

802.11 protocol messages are send at basic-rate. In dense WiFi networks it is a good idea to limit the impact of the 802.11 protocol overhead. 802.11 requires accesspoints and ad-hoc nodes to send beacons.

It is possible to avoid beacons by switching to the non-standard ah-demo mode. In ah-demo mode the MPs will send no beacons. The tradeoff is that normal WiFi devices will not see the WiFi network and they will not be able to associate. This is a very good property of ah-demo mode in many scenarios, particularly if you don't want other stations to interfere with your mesh. On the other hand: Other WiFi networks operating on the same channel will not be able to coordinate channel use. And normal devices that are not compatible with ah-demo mode can not associate, as mentioned above.

It is possible to mix ad-hoc and ah-demo MPs. So you don't have to run ad-hoc mode on all MPs.

You can select the mode with LUCI, in the same menu as mentioned above.

Alternative: Increase the beacon interval time

By default most WiFi devices send a beacon every 100ms. In ad-hoc mode with high node density this is very often. You can increase the interval to 1 second.