[RFC 0/6] Using DFS channels in 802.11s mesh mode

[Simon Wunderlich]

Hi Jouni,

On Thursday, December 1, 2016 8:51:16 PM CET Jouni Malinen wrote:
> On Mon, Nov 28, 2016 at 04:38:37PM +0100, Benjamin Berg wrote:
> > I have been working a bit on allowing channels which require DFS to be
> > used
> > for mesh mode. There are still a number of rough edges, but the following
> > patches add very limitted DFS support.
> > 
> > What currently works is that wpa_supplicant will start the CAC when
> > required and will use the channel if it is available. In general it will
> > also correctly switch the channel if radar is detected (during CAC or
> > operation).
> I'm a bit concerned about enabling channels requiring DFS for mesh based
> only on the existing radar detection and DFS functionality that has been
> certified in AP mode. While radar detection itself would hopefully work
> fine, I'd want to get somewhat better understanding on potential
> implication this could have or alternatively, use a new driver
> capability advertisement for mesh-DFS that would be enabled explicitly
> for drivers that have been tested in this combination.

I believe this is already handled by the interface combinations - drivers can 
announce that they support radar with certain WiFi modes with DFS. I don't see 
that we need another flag for this.

> 
> How does the channel switch on radar detection during operation work
> between the multiple devices? 

Basically, other devices hearing a CSA will adopt the CSA into their beacons/
probe request and perform the same switch. In this way, the CSA gets flooded 
through the mesh/IBSS and all devices should (hopefully) switch at the same 
time).

> Will all STAs in the mesh BSS move to the
> same channel? 

If the CSA adoption is succesful, yes. However, there is no gurantee, it is a 
"best effort" process.

One possible approach would be to scan whether other stations already moved to 
the previously agreed next channel, to follow those.
 
> Who decides which channel to use? 

The standard doesn't specify that. (For IBSS mode, there is something like a 
DFS master, but that appraoch seems far from practical).

We could have an (external) function which decides the channel. But it would 
really be integration/vendor-specific.

> And will all the STAs
> stop transmission immediately on radar detection and meet the FCC
> requirements for total aggregate TX time after this for any following
> frames needed for coordination to the channel change? That limit is
> pretty small if it were to be interpreted as a total aggregate over all
> STAs in the mesh..

Hm, as far as I remember, the standard only requires the "master" to not 
exceed a specific total transmission time. And ETSI as well as DFS say that for 
IBSS/Mesh mode, the devices should be tested as if they were masters. I agree 
that it is a question of interpretation, but I'd assume that the limit is 
interpreted per AP, not aggregate ...

> 
> Does something prevent a non-radar-detect-capable STA from joining an
> already operating mesh on a DFS channel?

In Linux, regdb should avoid it. Since the master rules apply for IBSS/mesh 
mode, a device can only join once it performed a CAC (regardless of other 
stations already sending there). And it must be radar-capable.

Cheers,
    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20161201/eb83646e/attachment.sig>