Hello, I am working with BATMAN-ADV and have successfully setup a mesh. In my implementation of the mesh, the network requires BATMAN to operate in a linear topology and ideally have node 1 hop to node 2 then through node 3 and finally node 4. Node1 .Node2 ..Node3 Node4 In this network hops are preferred rather than distant links with low RSSI values(-70). The problem that Im seeing is that the protocol chooses routes that have the least hops but have RSSI values at about -78 to -90 rather than routing through the closest node with RSSI values in the -50 range. We adjusted the hop penalty to a low value (we used 1 and 0) and we did see improvement with the hop selection but the throughput is very low due to an RSSI of -64 or less. Questions: 1) Is there a way to adjust BATMAN using batctl to select routes based on the RSSI value? a. That is, choose to hop through a node with an RSSI of -50 and never select a node that has a lower RSSI 2) Does the algorithm for route selection use RSSI in the calculation and if so can we modify the algorithm to increase the importance of RSSI in the selection? 3) How do we gain access to the code to make these modifications? a. Can you give me a little guidance on how to modify BATMAN-adv to suite my situation? Your help is greatly appreciated. Regards, Joseph Zimmer Telegrid Technology Inc. 19 Microlab Road Livingston, NJ 07039 Email: j.zimmer@telegrid.com Phone: 973.994.4440 X319
Hi Joseph,
On Thursday 07 May 2015 13:00:52 Joseph Zimmer wrote:
Hello,
I am working with BATMAN-ADV and have successfully setup a mesh. In my implementation of the mesh, the network requires BATMAN to operate in a linear topology and ideally have node 1 hop to node 2 then through node 3 and finally node 4.
Node1 .Node2 ..Node3 Node4In this network hops are preferred rather than distant links with low RSSI values(-70). The problem that Im seeing is that the protocol chooses routes that have the least hops but have RSSI values at about -78 to -90 rather than routing through the closest node with RSSI values in the -50 range.
We adjusted the hop penalty to a low value (we used 1 and 0) and we did see improvement with the hop selection but the throughput is very low due to an RSSI of -64 or less.
Questions:
Is there a way to adjust BATMAN using batctl to select routes basedon the RSSI value? a. That is, choose to hop through a node with an RSSI of -50 and never select a node that has a lower RSSI
Nope, BATMAN only uses packet loss as a metric. It could be possibly adjusted to do so or low signal links could be filtered otherwise, but we would consider that a bad hack.
There is another suggestion: You could increase the multicast rate to a high value, e.g. 36 MBit/s or even higher. Higher rates only work with good signals, and since batman-adv uses broadcasts (which is multicast for WiFi), this will have a direct effect on your network.
Does the algorithm for route selection use RSSI in the calculationand if so can we modify the algorithm to increase the importance of RSSI in the selection?
It currently doesn't use RSSI
How do we gain access to the code to make these modifications?
Batman-adv is open source, and so is mac80211 and hopefully the WiFi driver you use. However, it'd really suggest to start with tuning the multicast rate. :)
Cheers, Simon
On Thursday 07 May 2015 19:25:11 Simon Wunderlich wrote: [....]
There is another suggestion: You could increase the multicast rate to a high value, e.g. 36 MBit/s or even higher. Higher rates only work with good signals, and since batman-adv uses broadcasts (which is multicast for WiFi), this will have a direct effect on your network.
[...]
Batman-adv is open source, and so is mac80211 and hopefully the WiFi driver you use. However, it'd really suggest to start with tuning the multicast rate. :)
I definitely agree here. This should tested before trying to hack the TQ calculation with some own RSSI based submetric.
The mcast_rate trick is currently only shown in an old OpenWrt wiki page [1]. Maybe it should also be mentioned in the main OpenWrt configuration page [2]. I will leave this to the interested reader... or I will change it when I have some time to confirm it with a current OpenWrt.
Kind regards, Sven
[1] http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config-... [2] http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config
There is another suggestion: You could increase the multicast rate to a
high
value, e.g. 36 MBit/s or even higher. Higher rates only work with good signals, and since batman-adv uses broadcasts (which is multicast for WiFi), this will have a direct effect on your network.
I received input mentioning the multicast rate. Since the mcast_rate modification looked straight forward I choose to try it out right away.
I did see an improvement in the behavior of our network. By improvement I mean that I see the network routing through adjacent nodes using hops, verified by trace route, and achieved higher throughput values. A value of 36000 was used for the mcast_rate but anything higher broke the system (Not sure why). I used that value since my research indicated that the value was in Kbps and Simon pointed out 36 Mbits.
Thanks for the help,
Joseph
-----Original Message----- From: B.A.T.M.A.N [mailto:b.a.t.m.a.n-bounces@lists.open-mesh.org] On Behalf Of Sven Eckelmann Sent: Friday, May 08, 2015 2:34 AM To: b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] FW: using Batman-adv
On Thursday 07 May 2015 19:25:11 Simon Wunderlich wrote: [....]
There is another suggestion: You could increase the multicast rate to a
high
value, e.g. 36 MBit/s or even higher. Higher rates only work with good signals, and since batman-adv uses broadcasts (which is multicast for WiFi), this will have a direct effect on your network.
[...]
Batman-adv is open source, and so is mac80211 and hopefully the WiFi
driver
you use. However, it'd really suggest to start with tuning the multicast rate. :)
I definitely agree here. This should tested before trying to hack the TQ calculation with some own RSSI based submetric.
The mcast_rate trick is currently only shown in an old OpenWrt wiki page [1]. Maybe it should also be mentioned in the main OpenWrt configuration page [2]. I will leave this to the interested reader... or I will change it when I have some time to confirm it with a current OpenWrt.
Kind regards, Sven
[1] http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config- sophisticated [2] http://www.open-mesh.org/projects/batman-adv/wiki/Batman-adv-openwrt-config
On Thursday 07 May 2015 13:00:52 Joseph Zimmer wrote:
Is there a way to adjust BATMAN using batctl to select routes basedon the RSSI value?
No
Does the algorithm for route selection use RSSI in the calculationand if so can we modify the algorithm to increase the importance of RSSI in the selection?
No.
How do we gain access to the code to make these modifications?a. Can you give me a little guidance on how to modify BATMAN-adv to suite my situation?
But you could patch your wifi driver/framework (for example mac80211) to provide an exported function which returns the rssi for a specific net_device (net_dev of the if_incoming) + the mac address of the other station (mac orig in orig_neigh_node). This function has to basically get the sinfo->signal_avg when the sta exists for this bss.
You have to make sure that this device is really a compatible ieee80211 device - otherwise your kernel might just crash when accessing the private data of the net_device. Maybe this is always true in your situation but I don't know your setup well enough. If it is a mixed setup then you can try the ieee80211_ptr trick from netdev_notify in net/mac80211/iface.c. This has to be done before you are using IEEE80211_DEV_TO_SUB_IF. You can check to ieee80211_get_station see a function which already does parts of what you want (but it has not yet this check). And also keep in mind that sinfo->signal_avg may not be set with correct data. You must check (sinfo->filled & STATION_INFO_SIGNAL_AVG) when you are creating a function similar to ieee80211_get_station for RSSI.
This code would have to be called when the neighbor tq is calculated in batadv_iv_ogm_calc_tq. It basically has to adjust batadv_ogm_packet->tq somewhere at the end of the function. The percentage of reduction would have to be chosen by you based on how "bad" the rssi value is. I don't have a good metric for that.
I am not sure if Antonio/Marek have some proof of concept in their BATMAN V branch. But I think they wanted to use the bandwidth based approach which is queries the mac80211 rate control information [1].
Kind regards, Sven
[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/123514
On Thu, May 7, 2015 at 10:00 AM, Joseph Zimmer j.zimmer@telegrid.com wrote:
Node1…………………….Node2……………………………..Node3…………………………Node4
Joseph, the only way I've been able to be truly successful with this in the past is by selecting different channels for alternating links. It required additional "nodes" but works fantastic and doesn't have a speed reduction due to distance.
Node1......(ch a)............Node2--hardwire--Node3..........(ch b)..........Node4--hardwire--Node5................(ch c)...........Node6
Once the distance is far enough you can start repeating channels. Also, you maximize your end to end throughput if your adjacent nodes use non-adjacent channels. I've had great success hopping buildings in urban environments with this method. This could also be done with two radios in a single node, I suppose, but how you do it depends on what your hardware is.
Good luck,
Ray
b.a.t.m.a.n@lists.open-mesh.org
-
Joseph Zimmer -
Ray Gibson -
Simon Wunderlich -
Sven Eckelmann