DFS implementation status update

DFS implementation status update

[Goldenshtein, Victor]

[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]

Dear all,


We're now in the final DFS development stage and planning to release
RFC patchsets (both hostapd and nl/cfg/mac80211) in the next week or
so.


Main idea
===================

DFS master algorithm is implemented in the hostapd, while
nl/cfg/mac80211 will pipe relevant commands/events to the
driver/hostapd.

Based on the assumption that the device/driver supports radar
interference detection i.e., it is capable to generate radar_detected
event by using different pattern detection techniques:

1. Pattern detection in the HW: the device generates 'radar_detected' events.
2. Pattern detection in the driver: the driver receives radar pulses
from the device and generates 'radar_detected' events.


Main DFS procedures
===================

1. Hostapd gets driver's DFS capabilities.

2. If 80211h is enabled in the hostapd.conf and the driver supports
one of the above radar detection techniques, hostapd may use DFS
channels.

3. Hostapd selects an operational channel (default from hostapd.conf),
if selected channel is a DFS channel, hostapd sends
start_radar_detection command to the device/driver which starts
monitoring for radar interference while hostapd sets a timer for a CAC
(Channel Availability Check) time, which is 60 seconds (DFS spec).

4. As CAC timer expires and no radar has been detected, hostapd may
continue with the init flow, otherwise if interference is detected
hostapd randomly selects another channel (later on this can be changed
to ACS). If the new channel is also a DFS channel hostapd performs CAC
once again, while the original channel is added to a "black list" for
a period of ''No-Occupancy'' time (time that the channel can't be
used/selected).

5. While using the channel the device/driver continuously monitors for
potential radar interference. If interference is detected hostapd
notified with 'radar detected' event, which selects a new channel and
triggers a channel switch procedure, if the new channel is also a DFS
channel, hostapd performs the CAC test, once it's successfully passed
hostapd instructs the driver to initiate the transmission on the
channel.


Enclosed:
1. dfs_init_flow.jpeg: Which illustrates DFS init flow.
2. radar_event_channel_switch.jpeg: Which illustrates radar_detection
event and the channel switch procedure.



-- 
Thanks,
Victor.

[-- Attachment #2: dfs_init_flow.jpeg --]
[-- Type: image/jpeg, Size: 231823 bytes --]

[-- Attachment #3: radar_event_channel_switch.jpeg --]
[-- Type: image/jpeg, Size: 263776 bytes --]

Re: DFS implementation status update

[Martin Schleier]

Goldenshtein, Victor <victorg@...> writes:

> 
> Dear all,
> 
> We're now in the final DFS development stage and planning to release
> RFC patchsets (both hostapd and nl/cfg/mac80211) in the next week or
> so.
> 
> Main idea
> [...]
Don't have the background to tell whenever these ideas are sane or not...

> Enclosed:
> 1. dfs_init_flow.jpeg: Which illustrates DFS init flow.
> 2. radar_event_channel_switch.jpeg: Which illustrates radar_detection
> event and the channel switch procedure.
But your diagrams look really odd to me. They seem to look like shiny UML
sequence diagrams, but some things are wrong.

The kernel will never "call" directly into userspace. But you
use a "synchronizied call" arrow for RADAR_EVENT from "driver" over
mac/nl80211 into hostapd. The same is true for CHANNEL_SWITCH as well.
That's not how this is supposed to work, mac80211 sends an async nl80211
message and hostapd's event listener is processing it.

Also why are you using "alt" [radar_detected], when there's only one
condition? Wouldn't it make it more sense to go for the "opt" fragment there?

Re: DFS implementation status update

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

Hello Victor,

thank you for the update, it is nice to hear that you're working on this!

I have a few questions regarding your implementation and whether you have
some features on your list for possible future extensions, please see below.
If you don't have them on your list, I could work on some of them too, please
don't take this as if I'd expect that you need to do that. ;)

On Tue, Jan 10, 2012 at 10:22:44AM +0200, Goldenshtein, Victor wrote:
> Main DFS procedures
> ===================
> 
> 1. Hostapd gets driver's DFS capabilities.

Do you plan to support IBSS/Ad-Hoc as well?

> 
> 2. If 80211h is enabled in the hostapd.conf and the driver supports
> one of the above radar detection techniques, hostapd may use DFS
> channels.

I guess you're implementing the channel switch part for now, any plans
on the rest of 802.11h? (station measurement, TPC, etc). 

> 
> 3. Hostapd selects an operational channel (default from hostapd.conf),
> if selected channel is a DFS channel, hostapd sends
> start_radar_detection command to the device/driver which starts
> monitoring for radar interference while hostapd sets a timer for a CAC
> (Channel Availability Check) time, which is 60 seconds (DFS spec).
> 
> 4. As CAC timer expires and no radar has been detected, hostapd may
> continue with the init flow, otherwise if interference is detected
> hostapd randomly selects another channel (later on this can be changed
> to ACS). If the new channel is also a DFS channel hostapd performs CAC
> once again, while the original channel is added to a "black list" for
> a period of ''No-Occupancy'' time (time that the channel can't be
> used/selected).

Do you plan to allow band selection or channel selection? For example,
it would be desirable to only select indoor channels or outdoor channels,
exclude weather channels (5600-5650 MHz) or only select a specific subband where
high tx power is allowed.

I'm also not sure if pre-selecting a start channel is conforming to 
ETSI EN 301 893 V1.5.1 - as I'd interpret it (but I might be wrong), a
channel should always be randomly selected from the available channel list
(4.7.2.6 Uniform Spreading) - there is not test specified for this though (Annex A).

I'm also missing the channel switch announcement for associated clients in your
flow chart, but maybe you skipped this to keep it simple. It looks like a good approach, 
I'm really looking forward to your patchset.

Cheers,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: DFS implementation status update

[Goldenshtein, Victor]

Hello Simon,


>
> Do you plan to support IBSS/Ad-Hoc as well?
>

For now we don't have such plans.


>
> I guess you're implementing the channel switch part for now, any plans
> on the rest of 802.11h? (station measurement, TPC, etc).
>

Same here, for now the main implementation is the channel availability
check, radar event and the channel switch mechanism.

>
> Do you plan to allow band selection or channel selection? For example,
> it would be desirable to only select indoor channels or outdoor channels,
> exclude weather channels (5600-5650 MHz) or only select a specific subband where
> high tx power is allowed.
>

For now we use random channel selection after radar event, but later
on this can be changed to more sophisticated algorithms.

> I'm also not sure if pre-selecting a start channel is conforming to
> ETSI EN 301 893 V1.5.1 - as I'd interpret it (but I might be wrong), a
> channel should always be randomly selected from the available channel list
> (4.7.2.6 Uniform Spreading) - there is not test specified for this though (Annex A).
>
> I'm also missing the channel switch announcement for associated clients in your
> flow chart, but maybe you skipped this to keep it simple. It looks like a good approach,
> I'm really looking forward to your patchset.
>

Yep, you're right the CSA is left out for the simplicity ;)


-- 
Thanks,
Victor.