[Make-wifi-fast] Fwd: "Why Wi-Fi Stinks -- and How to Fix It" (DFS support)

[Dave Taht]

---------- Forwarded message ---------
From: John Gilmore <gnu at toad.com>
Date: Thu, Jul 23, 2020 at 5:49 AM
Subject: "Why Wi-Fi Stinks -- and How to Fix It" (DFS support)
To: Dave Taht <dave.taht at gmail.com>, <gnu at toad.com>


[fixed for easy forwarding.]

https://spectrum.ieee.org/telecom/wireless/why-wifi-stinksand-how-to-fix-it
https://portalwifi.com/technology

This guy, Terry Ngo, founder of Ignition Design Labs, was trying to do
Dynamic Frequency Selection (DFS) for WiFi, to triple the amount of 5
GHz WiFi bandwidth available in places that aren't using those
frequencies for fixed radars.  Early access points that used these
frequencies caused a lot of interference, so governments revised the
rules and now access points have to scan the band for radars for a
significant period of time before transmitting on them (and scoot away
if they hear a radar later).  But if they see no radar, they get access
to a much less congested set of frequencies, adding TWICE the total
bandwidth of all the unrestricted WiFi frequencies.

Seems like you and Mr. Ngo have complementary efforts to Make WiFi Fast.
Are you in touch?  You should ideally coordinate.  You both are engaged
in trying to get vendors to adopt new tech that makes wifi better; you
can probably trade contacts and find some interesting opportunities.

As one example, he was building (and trying to license out designs for)
access points that rapidly and constantly monitor spectrum so they can
immediately switch to a channel that's free of radars (without waiting
30 seconds to scan it for radar interference).  Part of their design
reports usage & interference to a "cloud" server, which is then shared
with other access points (and gets fed back into their engineering
effort).  Perhaps free Linux code could do similar things but just do it
locally, avoiding the cloud.  Possibly share it locally, if there's
any reason to do so, either over Ethernet multicasts, or through WiFi
spectrum.  Then you could get the benefits in any wifi LAN, whether or
not it foolishly allows random infrastructural equipment to phone home
to server farms.

I recently bought one of the "Portal Wifi" access points that they
shipped for a while (it looks like their company is out of business,
there's no support website any more, there's one guy answering support
tickets on Twitter as of last month, but the hardware is still available
from a sales channel and is down to $50 on Amazon).  Scrounging around
on the Wayback Machine for their "open source" legal page, it is based
on openwrt-release-15.05.  When I plug it in, it does succeed in finding
a channel in the DFS frequencies, that's free of local radars at my
location, which is what they claimed as their main innovation.  The
access point lives on that channel, and user nodes are legally able to
use those frequencies when they are connected to an access point there.

I didn't find good web resources about how widespread the hardware
support for using the DFS frequencies is, in current commercially
available hardware (and in free software that drives it).  Does somebody
on the list know?  Is it standard in every AP now?  Or only in
specialized ones like the Portal?

Here are more resources on DFS.  Here's a great conference presentation
with a history of DFS and the problem it solves:

  https://mum.mikrotik.com//presentations/UK16/presentation_3845_1479299009.pdf

The bandplan, at least for the US:

  https://apps.fcc.gov/kdb/GetAttachment.html?id=1K3EcgPRatUcWMwkA%2BuROw%3D%3D&desc=905462%20D06%20802%2011%20Channel%20Plans%20%20New%20Rules%20v02&tracking_number=27155
  (the whole portion between 5250 MHz and 5725 MHz requires DFS)

There's a Wikipedia page that works hard to summarize the global
regulatory structure around these frequencies:

  https://en.wikipedia.org/wiki/List_of_WLAN_channels

Here's some early Linux WiFi work on DFS:

  https://wireless.wiki.kernel.org/en/developers/dfs
  (this looks like it's 10 years old -- anybody want to update it?)

        John


-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729