Bluetooth tethering + Wifi appears to drop OLSR packets about android-manet-manager

[jrobble]

Good find and thanks for sharing!

Here’s an in-depth explanation of low OLSR link quality is calculated:
http://www.olsr.org/docs/README-Link-Quality.html

Note that LinkQualityLevel is set to 2 in the olsrd.conf used by the Manet Manager. The “Link Quality” metric represents the probability of a successful packet transmission from a specific neighbor to us. “Neighbor Link Quality” represents the probability in the other direction. In general, they are calculated based on the number of dropped HELLO packets.

The Bluetooth code is a remnant of the old Wi-Fi Tether for Root Users project that originally formed the basis for the Manet Manager. I never attempted to get things working over BlueTooth (simply because of the shorter range), but it has always been a nice-to-have consideration.

I can’t say for certain why BlueTooth would affect the mesh link quality, but my educated guess would be spectrum overlap. The mesh uses the Wi-Fi 2.412 - 2.472 GHz spectrum and BlueTooth should be using 2.402 - 2.480 GHz. Specifically, the Manet Manager usually operates on Channel 1, which is 2.412 GHz.

A quick online search indicates that what you experienced is pretty common across many pieces of Android and Apple hardware that support Wi-Fi and Bluetooth. Check out this explanation of Wi-Fi / BlueTooth coexistence:
http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence

It might be worth checking into which of the coexistence techniques your device is using.

Overall, the most effective way to address the coexistence issue is to use Wi-Fi over the 5.0 GHz band, which will avoid spectrum overlap altogether. Updating the Manet Manager to use 5.0 GHz (on devices which support it) is one of the most desirable features on our ever-growing TODO list. Of course using 5.0 GHz will cut down the communication range a bit (versus using 2.4 GHz), but the benefits of operating on a clean band will outweigh that cost in certain environments, especially in densely populated areas with lots of Wi-Fi utilization - like conference centers.

I think I saw a setting on some modern Android devices where you can switch between 2.4 GHz and 5.0 GHz. I’m not sure if that would affect which channel the Manet Manager would operate on, but it's worth a try.

[duhmojo]

Thanks for the great reply.

Hmmm... we could try to set the frequency and channel with iwconfig to 5Ghz associated values. e.g. iwconfig wlan0 channel 36, and iwconfig wlan0 freq 5.18G. However I have no clue how iwconfig, the driver, OS, etc... all come together to support 5Ghz in the first place. I know my Samsung S4s have dual band, as does my personal Nexus 10, but the batch of old Lenovo A1s I have for testing don't.

The problem with Wifi + BT coexistence measures, from what I can tell, is that they require a Wifi Access Point that can broker the situation. Typically a router coexistence feature will result in the router and Bluetooth device to taking turns in using the 2,4Ghz spectrum for communication, or "channel skipping" where the router will inform the Bluetooth device about the channel it is operating on and the Bluetooth device can preemptively disable communication on the respective Bluetooth channels.

This would require the BT device to cooperate and support "channel skipping", which our Android devices probably do, but it's with a Wifi router, not other Android devices.

I suspect if we could play with the Wifi and BT channels we could work something out.

Actually I found this: http://stackoverflow.com/questions/4887307/android-rfcomm-socket-on-fixed-channel

The suggestion (however loose) is that RFCOMM will only operate on channel 1 on its own. RFCOMM is used as part of setting up a BT PAN for networking. Maybe changing the MM channel might help?

I noticed that the Wifi channel setting is disabled in MM. Is there a reason for it? I can modify my MM build to force a channel change just to test.

[duhmojo]

Ha! It works. I switched channel changing on in ChangeSettingsActivity.java, then set the channel on my devices to 11. I get no interference. It seems like bluetooth, in my Samsung S4 case, defaults to 2.412Ghz, channel 1, just like the stackoverflow post I pointed to. I believe the built-in coexistence features require an AccessPoint/Router to support them. Basically every work around you see online regarding BT keyboards and bad Wifi all conclude (if they do at all) in a "working" router recommendation, that likely supports channel skipping, etc...

I'm not sure what you plan to test with respect to the channel change setting, but it seems to work for me without any headaches. I'm leaving it on in my build because I need BT to work with 802.11.

Thanks again for the great support.

[jrobble]

Yeah, I haven’t looked too deep into how 5.0 GHz is supported, but in theory it should be possible to switch to that band.

I had a sneaking suspicion about how a Wi-Fi AP might be brokering the spectrum use. Thanks for the explanation.

I’m glad you were able to set the Wi-Fi channel. I disabled the feature in the Manet Manager because not all devices support it and didn’t want to confuse people.

It’s interesting that your BlueTooth device is using 2.412 GHz (Wi-Fi channel 1). Most online resources indicate that BlueTooth is supposed to be using a technique called spread-spectrum frequency hopping where it quickly skips across nearly the entire 2.4 GHz band, hitting nearly every Wi-Fi channel in the process for very short periods of time:

http://www.informit.com/articles/article.aspx?p=21324

Of course that’s all in theory. Your BlueTooth hardware manufacturer can do whatever they want.