[Commotion-discuss] Battlemesh talk about mesh-wide channel hopping (for DFS, etc)

[Andy Gunn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It would be great to see something like this implemented, as spectrum
is only going to get tighter and tighter as time goes on.

Most OpenWRT devices should support "auto" Wi-Fi channel selection by
default, do we know what mechanism is used to select those channels?
There may already be driver-level noise or channel quality hooks in
the system to use, and expand upon.

The coordination across the mesh will be the tricky part, as Simon
points out. Hopefully across the community some solutions will come up!


On 05/20/2014 08:29 PM, Ben West wrote:
> Indeed, using a tool that switches a node's radio over to monitor
> mode would yield lots of info about free or occupied channels,
> although this would have to be 'out of band' since it effectively
> disables the AP.  I was curious more about doing periodic noise
> surveys using both the 'iw wlan0 survey dump' tool, in conjunction
> with the link ETX values reported by olsrd, so as to not disable
> the AP.
> 
> The survey dump could at least help identify those neighbor's APs
> which are particularly strong (i.e. sources of interference).  The
> link ETX values, along with the signal dB values vs. TX retry
> amounts reported by iw wlan0 station dump, would give some measure
> of the current channel's quality.
> 
> 
> 
> On Tue, May 20, 2014 at 8:43 AM, Grady Johnson 
> <grady at opentechinstitute.org <mailto:grady at opentechinstitute.org>>
> wrote:
> 
> I had some thoughts a while back about using nodes for spectrum 
> sensing and came across LinSSID, a Linux-based spectrum analyzer: 
> http://sourceforge.net/projects/linssid/
> 
> It uses the Linux Wi-Fi drivers to dynamically sense the spectrum 
> environment across compatible channels. It's probably too resource 
> intense to run on the average node, but could be used on higher 
> resource backbone nodes (or client devices) and could feed the
> data into a central server.
> 
> Obviously, this would largely tie up the node's radio while it was 
> sampling the spectrum, but it wouldn't have to do it continuously, 
> only say every hour or even once a day.
> 
> On 05/19/2014 05:23 PM, Ben West wrote:
>> Simon Wunderlich gave a talk at this year's Battlemesh about 
>> progress in implementing DFS (dynamic frequency selection) in
>> mesh networks, whether through user-space tools or in kernel
>> space.
> 
> 
> http://www.battlemesh.org/BattleMeshV7/Agenda?action=AttachFile&do=view&target=2014-05-17_wbmv7_DFS.pdf
>
> 
>> The intended application from Simon's perspective is to permit 
>> automated channel hopping for meshes, as required for operating
>> on those 5.8GHz bands shared with radar installations.  Although
>> his talk focused on the EU regulatory environment, the incentives
>> for using these channel in the US would be similar (avoiding
>> otherwise crowded channels).
> 
>> My understanding is that the FCC presently requires unlicensed 
>> 5.8GHz radios operating on these channels to be be able to sense 
>> the present of radar and hop to another channel, and Ubiquiti
>> stock firmware for their AirMAX products (e.g. Nanostation M5)
>> now does this.  W/r/t running adhoc networks on DFS channels, I'm
>> not sure if the FCC explicitly forbids beaconing, or if radios
>> may sample the band for 30secs before sending out beacons.  The
>> FCC regs may be vague on this detail right now.
> 
>> I'm pointing out this particular talk, however, because the
>> ability for a mesh to reliably channel-hop would also be *very
>> useful* for 2.4GHz meshes.  That band now sees potentially
>> destructive noise from channel-hopping neighbors, i.e. one day
>> your mesh works, the next day it doesn't.  Manually keeping up
>> where a clear channel happens to be becomes increasingly
>> untenable.
> 
>> Any high-level thoughts about mesh-wide noise sensing and
>> channel hopping schemes for a platform like Commotion?


- -- 
Andy Gunn, Field Engineer
Open Technology Institute, New America Foundation
andygunn at opentechinstitute.org | 202-596-3484
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTfLKXAAoJEO7c3Fzx1WU8DasH/ia15370CA3t7hyvBYV/k8p5
9JWXaP4hqcDPz/cB0FJEBsjhQ9xtxFPyGj7gRe8X772P0DsC0dM0BZfJIE4uscfD
x9VbMljLkZg02r+/i2gFkpWCo+yPdaTX0x+NzNaZO1XrQSgn8K54KlyAzVr3oVQT
X0pLJM6KrWj3F7XFbjMiau4UpcWoiXpdQa+EqhoRFU6PxoFCY8s3byNSEWqUgmUf
GLtUCjUvSzy3BtMeEfYGPRfOwcaj+MQLVbZEnD5/Zyk50cfkKqQiZhBCu3Q7cVLQ
tJrrXKCdh9on3p4qi8dhUI+M1MbiTz/bZxPb6grVjBBFjwnMIfqLEQ52da0w71Y=
=XsLg
-----END PGP SIGNATURE-----