Initial automatic channel selection implementation

Initial automatic channel selection implementation

[Luis R. Rodriguez]

I'm looking to implement some form of Automatic Channel Selection on
Linux. What this would do is review all known channels where we can
initiate radiation on (beaconing modes of operation) and then pick the
best one based on some heuristics. Below are 3 stages I believe we can
take to start supporting this.

I - Simple solution:

  * Look for the frequency in a band that has the less amount of BSSes
with the lowest link quality

II - Load check:

  * In addition to the above take into consideration some metric for
load on the channel: frame count observed

III - Spectral / FFT data scan:

  * Do a spectral scan on each supported frequency and based on the
FFT of the data choose the channel which has the less amount of
interference. This requires FFT data to be sent from each driver to
userspace, userspace to parse it based on the chipset, and to classify
the data into some generic form.

The first solution should be a quick hack and I can likely implement a
proof of concept rather quickly with iw based on scan results. Would
likely be a very poor algorithm though. For load check I'd like to
hear ideas on what we can use, I was thinking simply using a monitor
interface to do a frame count over time on each channel and use this
information in combination with the BSS / link quality information
from phase I to form a decision. The first two should be usable with
any 802.11 mac80211 driver.

The Spectral stuff requires both driver enhancements and some nl80211
changes which enables drivers to export some vendor specific blob
which userspace can parse and use for analysis. This is the ideal
solution but requires quite a bit of work and it the hooks will be
vendor specific both for kernel / processing of the FFT binary data.
Not all devices will support this.

This is the roadmap I'll follow, let me know if you have any other suggestions.

  Luis

Re: Initial automatic channel selection implementation

[Helmut Schaa]

Hi Luis,

Am Dienstag, 24. Mai 2011 schrieb Luis R. Rodriguez:
> II - Load check:
> 
>   * In addition to the above take into consideration some metric for
> load on the channel: frame count observed

Sounds similar to the busy time information some drivers already report
via "iw wlan0 survey dump", no? Counting frames sounds like a lot of
overhead to me.

Helmut

Re: Initial automatic channel selection implementation

[Eduard GV]

Hi all,

>> II - Load check:
>>
>>   * In addition to the above take into consideration some metric for
>> load on the channel: frame count observed
>
> Sounds similar to the busy time information some drivers already report
> via "iw wlan0 survey dump", no? Counting frames sounds like a lot of
> overhead to me.

I don't know to what extent is 802.11k supported so far (anyone?), but
it'd provides useful radio measurements, e.g.:

* Frame Count Report: The STA that performs such a measurement
observes the traffic on a given channel and makes a summary for each
different transmitter detected during the measurement. Similar to the
Beacon Report, for each transmitter, the requested STA informs of
received power, SNR, etc.

* Channel Load Report: provides the load metric of a given channel
based on the measurement of busy time. More precisely, channel busy
time is defined as the proportion of the time during which either the
physical carrier sense, the virtual carrier sense (NAV) or both
indicate that the channel is busy. This measurement is similar,
although not identical, to the CCA report added by the IEEE 802.11h.

* Noise Histogram Report presents a measurement of received power
detected while the carrier sense mechanism indicates a free medium.
The histogram consists of ten different levels (between -92 and -55
dBm) and is drawn by taking into account the portion of time in which
noise is detected in each of the ten levels. This measurement is
similar in conception to the 802.11h’s RPI Histogram, but besides the
power densities, the Noise Histogram Report shall include the average
noise plus interference power on the measured
channel at the antenna connector during the measurement duration.

> Speaking of channels, I think only some channels should be eligible for
> automatic selection (that would be 1, 6 and 11 in the 2.4 GHz range).

I disagree. Sometimes it is better to have adjacent channel
interference (from partially overlapping channels) than co-channel
interference. I could provide some references if you're interested.

Regards

Re: Initial automatic channel selection implementation

[Pavel Roskin]

On 05/24/2011 02:07 PM, Eduard GV wrote:
>
>> Speaking of channels, I think only some channels should be eligible for
>> automatic selection (that would be 1, 6 and 11 in the 2.4 GHz range).
>
> I disagree. Sometimes it is better to have adjacent channel
> interference (from partially overlapping channels) than co-channel
> interference. I could provide some references if you're interested.

My point is that we should play safe, at least when the algorithm is 
simple.  We should try to avoid the situation when our AP chooses a 
channel with no other APs but with a lot of cross-channel interference 
(either at the time of the scanning or later).

-- 
Regards,
Pavel Roskin

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Tue, May 24, 2011 at 7:27 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Hi Luis,
>
> Am Dienstag, 24. Mai 2011 schrieb Luis R. Rodriguez:
>> II - Load check:
>>
>>   * In addition to the above take into consideration some metric for
>> load on the channel: frame count observed
>
> Sounds similar to the busy time information some drivers already report
> via "iw wlan0 survey dump", no? Counting frames sounds like a lot of
> overhead to me.

Yes, thanks this is a lot of work already done. Now we just need a
basic algorithm to parse this, quantify how ideal this channel is and
then spit out a desired optimal channel.

  Luis

Re: Initial automatic channel selection implementation

[Helmut Schaa]

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

On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Yes, thanks this is a lot of work already done. Now we just need a
> basic algorithm to parse this, quantify how ideal this channel is and
> then spit out a desired optimal channel.

That's what I've hacked some time ago (in form of the attached _ugly_ shell
script that does auto channel selection with rt2x00, not sure if it works
correct with other drivers as the survey dump differs somehow between
rt2x00, ath5k and ath9k, and it only does channel 1-11):

- Iterate over all channels and stay on each channel for some time
- Store busy time stats for each channel
- Choose the channel with the lowest busy time (and on 2.4Ghz also
  check the busy times on adjacent channels)

Btw. is the idea to get the auto channel selection into hostapd/supplicant
or in a new userspace tool?

Helmut

[-- Attachment #2: auto_channel.sh --]
[-- Type: application/x-sh, Size: 1386 bytes --]

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> Yes, thanks this is a lot of work already done. Now we just need a
>> basic algorithm to parse this, quantify how ideal this channel is and
>> then spit out a desired optimal channel.
>
> That's what I've hacked some time ago (in form of the attached _ugly_ shell
> script that does auto channel selection with rt2x00, not sure if it works
> correct with other drivers as the survey dump differs somehow between
> rt2x00, ath5k and ath9k, and it only does channel 1-11):
>
> - Iterate over all channels and stay on each channel for some time

Nice, yeah I was thinking of using the offchannel operation if we want
to spend more time there for inspection and if associated. For first
iteration it should be possible to just move around. In fact for AP
purposes I suppose one will want to just start AP mode ASAP and then
later do offchannel operations to do the inspection on the ideal
channel. Otherwise we sit there idle until we complete the Automatic
Channel Selection thingy.

> - Store busy time stats for each channel
> - Choose the channel with the lowest busy time (and on 2.4Ghz also
>  check the busy times on adjacent channels)

So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
we should skip that time from the busy time, otherwise the "busy" time
includes time we induced on TX'ing or RX'ing ourselves. So I was
thinking of using the:

  (active time - rx time - tx time)  / busy time

as a factor for impact on the given frequency. Then somehow we just
need to add to this the channel noise.

> Btw. is the idea to get the auto channel selection into hostapd/supplicant
> or in a new userspace tool?

Yup.

  Luis

Re: Initial automatic channel selection implementation

[Helmut Schaa]

On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
>> On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>> Yes, thanks this is a lot of work already done. Now we just need a
>>> basic algorithm to parse this, quantify how ideal this channel is and
>>> then spit out a desired optimal channel.
>>
>> That's what I've hacked some time ago (in form of the attached _ugly_ shell
>> script that does auto channel selection with rt2x00, not sure if it works
>> correct with other drivers as the survey dump differs somehow between
>> rt2x00, ath5k and ath9k, and it only does channel 1-11):
>>
>> - Iterate over all channels and stay on each channel for some time
>
> Nice, yeah I was thinking of using the offchannel operation if we want
> to spend more time there for inspection and if associated. For first
> iteration it should be possible to just move around. In fact for AP
> purposes I suppose one will want to just start AP mode ASAP and then
> later do offchannel operations to do the inspection on the ideal
> channel. Otherwise we sit there idle until we complete the Automatic
> Channel Selection thingy.

Correct, especially if we also consider 5Ghz channels. Offchannel operations
would be nice but how can we ensure AP mode while being offchannel?

>> - Store busy time stats for each channel
>> - Choose the channel with the lowest busy time (and on 2.4Ghz also
>>  check the busy times on adjacent channels)
>
> So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
> we should skip that time from the busy time, otherwise the "busy" time
> includes time we induced on TX'ing or RX'ing ourselves. So I was
> thinking of using the:
>
>  (active time - rx time - tx time)  / busy time

Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx busy
time separately, we can only advice the hw to include or exclude rx/tx time
from the busy time statistics.

Helmut

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>>> On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>>>> Yes, thanks this is a lot of work already done. Now we just need a
>>>> basic algorithm to parse this, quantify how ideal this channel is and
>>>> then spit out a desired optimal channel.
>>>
>>> That's what I've hacked some time ago (in form of the attached _ugly_ shell
>>> script that does auto channel selection with rt2x00, not sure if it works
>>> correct with other drivers as the survey dump differs somehow between
>>> rt2x00, ath5k and ath9k, and it only does channel 1-11):
>>>
>>> - Iterate over all channels and stay on each channel for some time
>>
>> Nice, yeah I was thinking of using the offchannel operation if we want
>> to spend more time there for inspection and if associated. For first
>> iteration it should be possible to just move around. In fact for AP
>> purposes I suppose one will want to just start AP mode ASAP and then
>> later do offchannel operations to do the inspection on the ideal
>> channel. Otherwise we sit there idle until we complete the Automatic
>> Channel Selection thingy.
>
> Correct, especially if we also consider 5Ghz channels. Offchannel operations
> would be nice but how can we ensure AP mode while being offchannel?

Notification of absence.

>>> - Store busy time stats for each channel
>>> - Choose the channel with the lowest busy time (and on 2.4Ghz also
>>>  check the busy times on adjacent channels)
>>
>> So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
>> we should skip that time from the busy time, otherwise the "busy" time
>> includes time we induced on TX'ing or RX'ing ourselves. So I was
>> thinking of using the:
>>
>>  (active time - rx time - tx time)  / busy time
>
> Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx busy
> time separately, we can only advice the hw to include or exclude rx/tx time
> from the busy time statistics.

Doh, I see.. well in order for the above math to be useful we'd have
to be consistent across drivers. What is being done by rt2x00 right
now? If the later then the math would still work, otherwise then we'd
need to adjust.

  Luis

Re: Initial automatic channel selection implementation

[Felix Fietkau]

On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote:
> On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa
> <helmut.schaa@googlemail.com>  wrote:
>>  On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez<mcgrof@gmail.com>  wrote:
>>>  On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
>>>  <helmut.schaa@googlemail.com>  wrote:
>>>>  On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez<mcgrof@gmail.com>  wrote:
>>>>>  Yes, thanks this is a lot of work already done. Now we just need a
>>>>>  basic algorithm to parse this, quantify how ideal this channel is and
>>>>>  then spit out a desired optimal channel.
>>>>
>>>>  That's what I've hacked some time ago (in form of the attached _ugly_ shell
>>>>  script that does auto channel selection with rt2x00, not sure if it works
>>>>  correct with other drivers as the survey dump differs somehow between
>>>>  rt2x00, ath5k and ath9k, and it only does channel 1-11):
>>>>
>>>>  - Iterate over all channels and stay on each channel for some time
>>>
>>>  Nice, yeah I was thinking of using the offchannel operation if we want
>>>  to spend more time there for inspection and if associated. For first
>>>  iteration it should be possible to just move around. In fact for AP
>>>  purposes I suppose one will want to just start AP mode ASAP and then
>>>  later do offchannel operations to do the inspection on the ideal
>>>  channel. Otherwise we sit there idle until we complete the Automatic
>>>  Channel Selection thingy.
>>
>>  Correct, especially if we also consider 5Ghz channels. Offchannel operations
>>  would be nice but how can we ensure AP mode while being offchannel?
>
> Notification of absence.
>
>>>>  - Store busy time stats for each channel
>>>>  - Choose the channel with the lowest busy time (and on 2.4Ghz also
>>>>    check the busy times on adjacent channels)
>>>
>>>  So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
>>>  we should skip that time from the busy time, otherwise the "busy" time
>>>  includes time we induced on TX'ing or RX'ing ourselves. So I was
>>>  thinking of using the:
>>>
>>>    (active time - rx time - tx time)  / busy time
>>
>>  Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx busy
>>  time separately, we can only advice the hw to include or exclude rx/tx time
>>  from the busy time statistics.
>
> Doh, I see.. well in order for the above math to be useful we'd have
> to be consistent across drivers. What is being done by rt2x00 right
> now? If the later then the math would still work, otherwise then we'd
> need to adjust.
Excluding rx time isn't even a good idea, since it makes no distinction 
between local BSS or other activity in the area.

- Felix

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Wed, May 25, 2011 at 12:20 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote:
>>
>> On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa
>> <helmut.schaa@googlemail.com>  wrote:
>>>
>>>  On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>  wrote:
>>>>
>>>>  On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
>>>>  <helmut.schaa@googlemail.com>  wrote:
>>>>>
>>>>>  On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>>  wrote:
>>>>>>
>>>>>>  Yes, thanks this is a lot of work already done. Now we just need a
>>>>>>  basic algorithm to parse this, quantify how ideal this channel is and
>>>>>>  then spit out a desired optimal channel.
>>>>>
>>>>>  That's what I've hacked some time ago (in form of the attached _ugly_
>>>>> shell
>>>>>  script that does auto channel selection with rt2x00, not sure if it
>>>>> works
>>>>>  correct with other drivers as the survey dump differs somehow between
>>>>>  rt2x00, ath5k and ath9k, and it only does channel 1-11):
>>>>>
>>>>>  - Iterate over all channels and stay on each channel for some time
>>>>
>>>>  Nice, yeah I was thinking of using the offchannel operation if we want
>>>>  to spend more time there for inspection and if associated. For first
>>>>  iteration it should be possible to just move around. In fact for AP
>>>>  purposes I suppose one will want to just start AP mode ASAP and then
>>>>  later do offchannel operations to do the inspection on the ideal
>>>>  channel. Otherwise we sit there idle until we complete the Automatic
>>>>  Channel Selection thingy.
>>>
>>>  Correct, especially if we also consider 5Ghz channels. Offchannel
>>> operations
>>>  would be nice but how can we ensure AP mode while being offchannel?
>>
>> Notification of absence.
>>
>>>>>  - Store busy time stats for each channel
>>>>>  - Choose the channel with the lowest busy time (and on 2.4Ghz also
>>>>>   check the busy times on adjacent channels)
>>>>
>>>>  So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
>>>>  we should skip that time from the busy time, otherwise the "busy" time
>>>>  includes time we induced on TX'ing or RX'ing ourselves. So I was
>>>>  thinking of using the:
>>>>
>>>>   (active time - rx time - tx time)  / busy time
>>>
>>>  Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx
>>> busy
>>>  time separately, we can only advice the hw to include or exclude rx/tx
>>> time
>>>  from the busy time statistics.
>>
>> Doh, I see.. well in order for the above math to be useful we'd have
>> to be consistent across drivers. What is being done by rt2x00 right
>> now? If the later then the math would still work, otherwise then we'd
>> need to adjust.
>
> Excluding rx time isn't even a good idea, since it makes no distinction
> between local BSS or other activity in the area.

What if we do an offchannel operation?

  Luis

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Wed, May 25, 2011 at 12:24 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, May 25, 2011 at 12:20 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote:
>>>
>>> On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa
>>> <helmut.schaa@googlemail.com>  wrote:
>>>>
>>>>  On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>  wrote:
>>>>>
>>>>>  On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
>>>>>  <helmut.schaa@googlemail.com>  wrote:
>>>>>>
>>>>>>  On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>>>  wrote:
>>>>>>>
>>>>>>>  Yes, thanks this is a lot of work already done. Now we just need a
>>>>>>>  basic algorithm to parse this, quantify how ideal this channel is and
>>>>>>>  then spit out a desired optimal channel.
>>>>>>
>>>>>>  That's what I've hacked some time ago (in form of the attached _ugly_
>>>>>> shell
>>>>>>  script that does auto channel selection with rt2x00, not sure if it
>>>>>> works
>>>>>>  correct with other drivers as the survey dump differs somehow between
>>>>>>  rt2x00, ath5k and ath9k, and it only does channel 1-11):
>>>>>>
>>>>>>  - Iterate over all channels and stay on each channel for some time
>>>>>
>>>>>  Nice, yeah I was thinking of using the offchannel operation if we want
>>>>>  to spend more time there for inspection and if associated. For first
>>>>>  iteration it should be possible to just move around. In fact for AP
>>>>>  purposes I suppose one will want to just start AP mode ASAP and then
>>>>>  later do offchannel operations to do the inspection on the ideal
>>>>>  channel. Otherwise we sit there idle until we complete the Automatic
>>>>>  Channel Selection thingy.
>>>>
>>>>  Correct, especially if we also consider 5Ghz channels. Offchannel
>>>> operations
>>>>  would be nice but how can we ensure AP mode while being offchannel?
>>>
>>> Notification of absence.
>>>
>>>>>>  - Store busy time stats for each channel
>>>>>>  - Choose the channel with the lowest busy time (and on 2.4Ghz also
>>>>>>   check the busy times on adjacent channels)
>>>>>
>>>>>  So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
>>>>>  we should skip that time from the busy time, otherwise the "busy" time
>>>>>  includes time we induced on TX'ing or RX'ing ourselves. So I was
>>>>>  thinking of using the:
>>>>>
>>>>>   (active time - rx time - tx time)  / busy time
>>>>
>>>>  Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx
>>>> busy
>>>>  time separately, we can only advice the hw to include or exclude rx/tx
>>>> time
>>>>  from the busy time statistics.
>>>
>>> Doh, I see.. well in order for the above math to be useful we'd have
>>> to be consistent across drivers. What is being done by rt2x00 right
>>> now? If the later then the math would still work, otherwise then we'd
>>> need to adjust.
>>
>> Excluding rx time isn't even a good idea, since it makes no distinction
>> between local BSS or other activity in the area.
>
> What if we do an offchannel operation?

Once we figure out that...

The missing piece is how to deal with noise info here. In short the
lower noise we have the better signal we'll get. The challenge then is
to take into consideration the noise mathematically in such a that a
high noise value would nullify any clean idle air time ratio
conditions from the formula postulated before. Let me review again
with some modifications.

Active time is the time we spend on the channel, so to get an idea of
how "busy" that channel is we have to remove the tx and rx time from
that channel. That gives us the time we spent idle on that channel.
Then the busy time is a subset of the entire active time but we should
also exclude the time we spent tx'ing and rx'ing as well. We then
have:

 (busy time - rx time - tx time) / (active time - rx time - tx time)

This is a bounded ratio already, given that if we spent 0 time tx'ing
0 time rx'ing, but 10 ms on a channel, and all that time we had busy
time as well we'd have a ratio of 10 / 10 = 1. In the best case we'd
have  0 / 10 = 0.

What I'd like to do is to affect the ratio to nullify it if the noise
is very low on the channel. Given that noise is logarithmic we'd have
to use a logarithmic function as well. Working on that now.

  Luis

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Wed, May 25, 2011 at 12:27 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, May 25, 2011 at 12:24 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Wed, May 25, 2011 at 12:20 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote:
>>>>
>>>> On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa
>>>> <helmut.schaa@googlemail.com>  wrote:
>>>>>
>>>>>  On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>>  wrote:
>>>>>>
>>>>>>  On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
>>>>>>  <helmut.schaa@googlemail.com>  wrote:
>>>>>>>
>>>>>>>  On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>  Yes, thanks this is a lot of work already done. Now we just need a
>>>>>>>>  basic algorithm to parse this, quantify how ideal this channel is and
>>>>>>>>  then spit out a desired optimal channel.
>>>>>>>
>>>>>>>  That's what I've hacked some time ago (in form of the attached _ugly_
>>>>>>> shell
>>>>>>>  script that does auto channel selection with rt2x00, not sure if it
>>>>>>> works
>>>>>>>  correct with other drivers as the survey dump differs somehow between
>>>>>>>  rt2x00, ath5k and ath9k, and it only does channel 1-11):
>>>>>>>
>>>>>>>  - Iterate over all channels and stay on each channel for some time
>>>>>>
>>>>>>  Nice, yeah I was thinking of using the offchannel operation if we want
>>>>>>  to spend more time there for inspection and if associated. For first
>>>>>>  iteration it should be possible to just move around. In fact for AP
>>>>>>  purposes I suppose one will want to just start AP mode ASAP and then
>>>>>>  later do offchannel operations to do the inspection on the ideal
>>>>>>  channel. Otherwise we sit there idle until we complete the Automatic
>>>>>>  Channel Selection thingy.
>>>>>
>>>>>  Correct, especially if we also consider 5Ghz channels. Offchannel
>>>>> operations
>>>>>  would be nice but how can we ensure AP mode while being offchannel?
>>>>
>>>> Notification of absence.
>>>>
>>>>>>>  - Store busy time stats for each channel
>>>>>>>  - Choose the channel with the lowest busy time (and on 2.4Ghz also
>>>>>>>   check the busy times on adjacent channels)
>>>>>>
>>>>>>  So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
>>>>>>  we should skip that time from the busy time, otherwise the "busy" time
>>>>>>  includes time we induced on TX'ing or RX'ing ourselves. So I was
>>>>>>  thinking of using the:
>>>>>>
>>>>>>   (active time - rx time - tx time)  / busy time
>>>>>
>>>>>  Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx
>>>>> busy
>>>>>  time separately, we can only advice the hw to include or exclude rx/tx
>>>>> time
>>>>>  from the busy time statistics.
>>>>
>>>> Doh, I see.. well in order for the above math to be useful we'd have
>>>> to be consistent across drivers. What is being done by rt2x00 right
>>>> now? If the later then the math would still work, otherwise then we'd
>>>> need to adjust.
>>>
>>> Excluding rx time isn't even a good idea, since it makes no distinction
>>> between local BSS or other activity in the area.
>>
>> What if we do an offchannel operation?
>
> Once we figure out that...
>
> The missing piece is how to deal with noise info here. In short the
> lower noise we have the better signal we'll get. The challenge then is
> to take into consideration the noise mathematically in such a that a
> high noise value would nullify any clean idle air time ratio
> conditions from the formula postulated before. Let me review again
> with some modifications.
>
> Active time is the time we spend on the channel, so to get an idea of
> how "busy" that channel is we have to remove the tx and rx time from
> that channel. That gives us the time we spent idle on that channel.
> Then the busy time is a subset of the entire active time but we should
> also exclude the time we spent tx'ing and rx'ing as well. We then
> have:
>
>  (busy time - rx time - tx time) / (active time - rx time - tx time)
>
> This is a bounded ratio already, given that if we spent 0 time tx'ing
> 0 time rx'ing, but 10 ms on a channel, and all that time we had busy
> time as well we'd have a ratio of 10 / 10 = 1. In the best case we'd
> have  0 / 10 = 0.
>
> What I'd like to do is to affect the ratio to nullify it if the noise
> is very low on the channel. Given that noise is logarithmic we'd have
> to use a logarithmic function as well. Working on that now.

I also noticed that the survey results will stale out after a period
of time. As such the offchannel operation should ideally be followed
imediately by a survey of the channel. Our current API though allows
only for an entire survey, not a channel specific survey query. Not a
big deal but just something to keep in mind if we intend on using this
further for repetitive heuristics on a channel. We'll have to extend
the survey dump later to accept channel specific queries.

  Luis

Re: Initial automatic channel selection implementation

[Felix Fietkau]

On 2011-05-25 9:27 PM, Luis R. Rodriguez wrote:
> On Wed, May 25, 2011 at 12:24 PM, Luis R. Rodriguez<mcgrof@gmail.com>  wrote:
>>  On Wed, May 25, 2011 at 12:20 PM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>  On 2011-05-25 5:01 PM, Luis R. Rodriguez wrote:
>>>>
>>>>  On Wed, May 25, 2011 at 7:45 AM, Helmut Schaa
>>>>  <helmut.schaa@googlemail.com>    wrote:
>>>>>
>>>>>    On Wed, May 25, 2011 at 4:37 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>>    wrote:
>>>>>>
>>>>>>    On Wed, May 25, 2011 at 5:19 AM, Helmut Schaa
>>>>>>    <helmut.schaa@googlemail.com>    wrote:
>>>>>>>
>>>>>>>    On Wed, May 25, 2011 at 12:54 AM, Luis R. Rodriguez<mcgrof@gmail.com>
>>>>>>>    wrote:
>>>>>>>>
>>>>>>>>    Yes, thanks this is a lot of work already done. Now we just need a
>>>>>>>>    basic algorithm to parse this, quantify how ideal this channel is and
>>>>>>>>    then spit out a desired optimal channel.
>>>>>>>
>>>>>>>    That's what I've hacked some time ago (in form of the attached _ugly_
>>>>>>>  shell
>>>>>>>    script that does auto channel selection with rt2x00, not sure if it
>>>>>>>  works
>>>>>>>    correct with other drivers as the survey dump differs somehow between
>>>>>>>    rt2x00, ath5k and ath9k, and it only does channel 1-11):
>>>>>>>
>>>>>>>    - Iterate over all channels and stay on each channel for some time
>>>>>>
>>>>>>    Nice, yeah I was thinking of using the offchannel operation if we want
>>>>>>    to spend more time there for inspection and if associated. For first
>>>>>>    iteration it should be possible to just move around. In fact for AP
>>>>>>    purposes I suppose one will want to just start AP mode ASAP and then
>>>>>>    later do offchannel operations to do the inspection on the ideal
>>>>>>    channel. Otherwise we sit there idle until we complete the Automatic
>>>>>>    Channel Selection thingy.
>>>>>
>>>>>    Correct, especially if we also consider 5Ghz channels. Offchannel
>>>>>  operations
>>>>>    would be nice but how can we ensure AP mode while being offchannel?
>>>>
>>>>  Notification of absence.
>>>>
>>>>>>>    - Store busy time stats for each channel
>>>>>>>    - Choose the channel with the lowest busy time (and on 2.4Ghz also
>>>>>>>     check the busy times on adjacent channels)
>>>>>>
>>>>>>    So I was reviewing this -- if we are TX'ing or RX'ing it seems to me
>>>>>>    we should skip that time from the busy time, otherwise the "busy" time
>>>>>>    includes time we induced on TX'ing or RX'ing ourselves. So I was
>>>>>>    thinking of using the:
>>>>>>
>>>>>>     (active time - rx time - tx time)  / busy time
>>>>>
>>>>>    Looks good ;) just one problem from a rt2x00 POV: We can't report rx/tx
>>>>>  busy
>>>>>    time separately, we can only advice the hw to include or exclude rx/tx
>>>>>  time
>>>>>    from the busy time statistics.
>>>>
>>>>  Doh, I see.. well in order for the above math to be useful we'd have
>>>>  to be consistent across drivers. What is being done by rt2x00 right
>>>>  now? If the later then the math would still work, otherwise then we'd
>>>>  need to adjust.
>>>
>>>  Excluding rx time isn't even a good idea, since it makes no distinction
>>>  between local BSS or other activity in the area.
>>
>>  What if we do an offchannel operation?
>
> Once we figure out that...
>
> The missing piece is how to deal with noise info here. In short the
> lower noise we have the better signal we'll get. The challenge then is
> to take into consideration the noise mathematically in such a that a
> high noise value would nullify any clean idle air time ratio
> conditions from the formula postulated before. Let me review again
> with some modifications.
>
> Active time is the time we spend on the channel, so to get an idea of
> how "busy" that channel is we have to remove the tx and rx time from
> that channel. That gives us the time we spent idle on that channel.
> Then the busy time is a subset of the entire active time but we should
> also exclude the time we spent tx'ing and rx'ing as well. We then
> have:
>
>   (busy time - rx time - tx time) / (active time - rx time - tx time)
>
> This is a bounded ratio already, given that if we spent 0 time tx'ing
> 0 time rx'ing, but 10 ms on a channel, and all that time we had busy
> time as well we'd have a ratio of 10 / 10 = 1. In the best case we'd
> have  0 / 10 = 0.
>
> What I'd like to do is to affect the ratio to nullify it if the noise
> is very low on the channel. Given that noise is logarithmic we'd have
> to use a logarithmic function as well. Working on that now.
Please explain why you want to remove the rx time, it makes no sense to 
me. Without rx time you will usually not get any useful indication of 
how busy the channel is.

- Felix

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Thu, May 26, 2011 at 3:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-05-25 9:27 PM, Luis R. Rodriguez wrote:
>> The missing piece is how to deal with noise info here. In short the
>> lower noise we have the better signal we'll get. The challenge then is
>> to take into consideration the noise mathematically in such a that a
>> high noise value would nullify any clean idle air time ratio
>> conditions from the formula postulated before. Let me review again
>> with some modifications.
>>
>> Active time is the time we spend on the channel, so to get an idea of
>> how "busy" that channel is we have to remove the tx and rx time from
>> that channel. That gives us the time we spent idle on that channel.
>> Then the busy time is a subset of the entire active time but we should
>> also exclude the time we spent tx'ing and rx'ing as well. We then
>> have:
>>
>>  (busy time - rx time - tx time) / (active time - rx time - tx time)
>>
>> This is a bounded ratio already, given that if we spent 0 time tx'ing
>> 0 time rx'ing, but 10 ms on a channel, and all that time we had busy
>> time as well we'd have a ratio of 10 / 10 = 1. In the best case we'd
>> have  0 / 10 = 0.
>>
>> What I'd like to do is to affect the ratio to nullify it if the noise
>> is very low on the channel. Given that noise is logarithmic we'd have
>> to use a logarithmic function as well. Working on that now.
>
> Please explain why you want to remove the rx time, it makes no sense to me.
> Without rx time you will usually not get any useful indication of how busy
> the channel is.

The busy time that happens when do not TX or RX accounts for
interference on the frequency which is not accounted for. RX time may
mean receiving beacons or probe responses, this type of data exchange
doesn't necessarily mean interference. I believe sampling conditions
each frequency without TX or RX'ing data would yield a more fair
representation of general interference on the channel, otherwise the
interference would be taking into consideration explicit forced
interference on the frequency by our own radio.

  Luis

Re: Initial automatic channel selection implementation

[Felix Fietkau]

On 2011-05-27 1:45 AM, Luis R. Rodriguez wrote:
> On Thu, May 26, 2011 at 3:45 AM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>  On 2011-05-25 9:27 PM, Luis R. Rodriguez wrote:
>>>  The missing piece is how to deal with noise info here. In short the
>>>  lower noise we have the better signal we'll get. The challenge then is
>>>  to take into consideration the noise mathematically in such a that a
>>>  high noise value would nullify any clean idle air time ratio
>>>  conditions from the formula postulated before. Let me review again
>>>  with some modifications.
>>>
>>>  Active time is the time we spend on the channel, so to get an idea of
>>>  how "busy" that channel is we have to remove the tx and rx time from
>>>  that channel. That gives us the time we spent idle on that channel.
>>>  Then the busy time is a subset of the entire active time but we should
>>>  also exclude the time we spent tx'ing and rx'ing as well. We then
>>>  have:
>>>
>>>    (busy time - rx time - tx time) / (active time - rx time - tx time)
>>>
>>>  This is a bounded ratio already, given that if we spent 0 time tx'ing
>>>  0 time rx'ing, but 10 ms on a channel, and all that time we had busy
>>>  time as well we'd have a ratio of 10 / 10 = 1. In the best case we'd
>>>  have  0 / 10 = 0.
>>>
>>>  What I'd like to do is to affect the ratio to nullify it if the noise
>>>  is very low on the channel. Given that noise is logarithmic we'd have
>>>  to use a logarithmic function as well. Working on that now.
>>
>>  Please explain why you want to remove the rx time, it makes no sense to me.
>>  Without rx time you will usually not get any useful indication of how busy
>>  the channel is.
>
> The busy time that happens when do not TX or RX accounts for
> interference on the frequency which is not accounted for. RX time may
> mean receiving beacons or probe responses, this type of data exchange
> doesn't necessarily mean interference. I believe sampling conditions
> each frequency without TX or RX'ing data would yield a more fair
> representation of general interference on the channel, otherwise the
> interference would be taking into consideration explicit forced
> interference on the frequency by our own radio.
I think real channel load (including rx) is much more interesting for 
channel selection than only interference. Interference time shouldn't 
really matter that much in practice unless it's excessively high. Also, 
even normal packets will increase the measured non-rx/tx busy time, 
partially due to collisions, partially (on Atheros radios) because of 
the way the radio works.

- Felix

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Thu, May 26, 2011 at 5:23 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-05-27 1:45 AM, Luis R. Rodriguez wrote:
>>
>> On Thu, May 26, 2011 at 3:45 AM, Felix Fietkau<nbd@openwrt.org>  wrote:
>>>
>>>  On 2011-05-25 9:27 PM, Luis R. Rodriguez wrote:
>>>>
>>>>  The missing piece is how to deal with noise info here. In short the
>>>>  lower noise we have the better signal we'll get. The challenge then is
>>>>  to take into consideration the noise mathematically in such a that a
>>>>  high noise value would nullify any clean idle air time ratio
>>>>  conditions from the formula postulated before. Let me review again
>>>>  with some modifications.
>>>>
>>>>  Active time is the time we spend on the channel, so to get an idea of
>>>>  how "busy" that channel is we have to remove the tx and rx time from
>>>>  that channel. That gives us the time we spent idle on that channel.
>>>>  Then the busy time is a subset of the entire active time but we should
>>>>  also exclude the time we spent tx'ing and rx'ing as well. We then
>>>>  have:
>>>>
>>>>   (busy time - rx time - tx time) / (active time - rx time - tx time)
>>>>
>>>>  This is a bounded ratio already, given that if we spent 0 time tx'ing
>>>>  0 time rx'ing, but 10 ms on a channel, and all that time we had busy
>>>>  time as well we'd have a ratio of 10 / 10 = 1. In the best case we'd
>>>>  have  0 / 10 = 0.
>>>>
>>>>  What I'd like to do is to affect the ratio to nullify it if the noise
>>>>  is very low on the channel. Given that noise is logarithmic we'd have
>>>>  to use a logarithmic function as well. Working on that now.
>>>
>>>  Please explain why you want to remove the rx time, it makes no sense to
>>> me.
>>>  Without rx time you will usually not get any useful indication of how
>>> busy
>>>  the channel is.
>>
>> The busy time that happens when do not TX or RX accounts for
>> interference on the frequency which is not accounted for. RX time may
>> mean receiving beacons or probe responses, this type of data exchange
>> doesn't necessarily mean interference. I believe sampling conditions
>> each frequency without TX or RX'ing data would yield a more fair
>> representation of general interference on the channel, otherwise the
>> interference would be taking into consideration explicit forced
>> interference on the frequency by our own radio.
>
> I think real channel load (including rx) is much more interesting for
> channel selection than only interference. Interference time shouldn't really
> matter that much in practice unless it's excessively high. Also, even normal
> packets will increase the measured non-rx/tx busy time, partially due to
> collisions, partially (on Atheros radios) because of the way the radio
> works.

Alright, I'll include rx time too, I'm not really keen either way,
just trying to get a proof of concept going and moving.

Oh and for the record and quick cache of this information.. the busy
time is defined on Atheros hardware by the "The receive clear counter
" register, (AR_RCCNT, 0x80F4). The receive clear counter counts the
number of cycles the rx_clear signal is "NOT" active.

  Luis

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Thu, May 26, 2011 at 5:59 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>  What I'd like to do is to affect the ratio to nullify it if the noise
>  is very low on the channel. Given that noise is logarithmic we'd have
>  to use a logarithmic function as well. Working on that now.

OK I've figured a way to plug the noise into this, I designed the
following function we can use as a factor:

1.1^(x+110)

Wolfram|Alpha boring details of this function:

http://bit.ly/mJNXE9

x,y results of different noise values in dBm, using apcalc:

mcgrof@tux ~ $ calc
C-style arbitrary precision calculator (version 2.12.3.3)
Calc is open software. For license details type:  help copyright
[Type "exit" to exit, or "help" for help.]

; define f(x) = 1.1^(x+110)
f(x) defined

; f(-130)
	~0.14864362802414368640
; f(-120)
	~0.38554328942953174736
; f(-119)
	~0.42409761837248492210
; f(-118)
	~0.46650738020973341431
; f(-117)
	~0.51315811823070675574
; f(-116)
	~0.56447393005377743132
; f(-115)
	~0.62092132305915517445
; f(-114)
	~0.68301345536507069189
; f(-113)
	~0.75131480090157776108
; f(-112)
	~0.82644628099173553719
; f(-111)
	~0.90909090909090909091
; f(-110)
	1
; f(-109)
	1.1
; f(-108)
	1.21
; f(-107)
	1.331

So then, we'd use a frequency for initiating beaconing (AP, Mesh, P2P)
which uses the lowest value from the following computation:

(busy time - tx time) / (active time - tx time) * 1.1^(noise + 110)

The 1.1 factor can be modified more accurately to represent the
exponential factor of how noise should affect interference decisions,
the 110 value here can be modified for any other arbitrary value we
find as representative of a regular noise value from a simple AP on
the frequency we are observing, my assumption here was -110 dBm.

If I don't hear yells I'll implement this algorithm, but first I want
to add APIs to let us query for survey data for specific frequencies,
the current stuff assumes the dump data will be useful within the time
period we get it, but the way I'm thinking of doing it is to do each
frequency analysis atomically -- change channel / do offchannel
operation on a frequency, and then get the survey data for that
frequency and compute the above. Then choose the frequency with the
lowest value. This would allow us to do work without regards to any
possible stale data. We could also later add a history of these values
and compute an average and keep picking the best one. Anyway, that's
that. Let me know what you think.

  Luis

Re: Initial automatic channel selection implementation

[Felix Fietkau]

On 2011-06-03 12:36 AM, Luis R. Rodriguez wrote:
> On Thu, May 26, 2011 at 5:59 PM, Luis R. Rodriguez<mcgrof@gmail.com>  wrote:
>>    What I'd like to do is to affect the ratio to nullify it if the noise
>>    is very low on the channel. Given that noise is logarithmic we'd have
>>    to use a logarithmic function as well. Working on that now.
>
> OK I've figured a way to plug the noise into this, I designed the
> following function we can use as a factor:
>
> 1.1^(x+110)
>
> Wolfram|Alpha boring details of this function:
>
> http://bit.ly/mJNXE9
>
> x,y results of different noise values in dBm, using apcalc:
>
> mcgrof@tux ~ $ calc
> C-style arbitrary precision calculator (version 2.12.3.3)
> Calc is open software. For license details type:  help copyright
> [Type "exit" to exit, or "help" for help.]
>
> ; define f(x) = 1.1^(x+110)
> f(x) defined
>
> ; f(-130)
> 	~0.14864362802414368640
> ; f(-120)
> 	~0.38554328942953174736
> ; f(-119)
> 	~0.42409761837248492210
> ; f(-118)
> 	~0.46650738020973341431
> ; f(-117)
> 	~0.51315811823070675574
> ; f(-116)
> 	~0.56447393005377743132
> ; f(-115)
> 	~0.62092132305915517445
> ; f(-114)
> 	~0.68301345536507069189
> ; f(-113)
> 	~0.75131480090157776108
> ; f(-112)
> 	~0.82644628099173553719
> ; f(-111)
> 	~0.90909090909090909091
> ; f(-110)
> 	1
> ; f(-109)
> 	1.1
> ; f(-108)
> 	1.21
> ; f(-107)
> 	1.331
>
> So then, we'd use a frequency for initiating beaconing (AP, Mesh, P2P)
> which uses the lowest value from the following computation:
>
> (busy time - tx time) / (active time - tx time) * 1.1^(noise + 110)
>
> The 1.1 factor can be modified more accurately to represent the
> exponential factor of how noise should affect interference decisions,
> the 110 value here can be modified for any other arbitrary value we
> find as representative of a regular noise value from a simple AP on
> the frequency we are observing, my assumption here was -110 dBm.
-110 dBm is not a real noise value. It's an unrealistic, ath9k-specific 
value. I have a patch that changes ath9k to make noise and signal 
strength values more realistic, and I'll submit it soon, as soon as I've 
made it a bit more precise.

- Felix

Re: Initial automatic channel selection implementation

[Luis R. Rodriguez]

On Thu, Jun 2, 2011 at 4:49 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-06-03 12:36 AM, Luis R. Rodriguez wrote:
>>
>> On Thu, May 26, 2011 at 5:59 PM, Luis R. Rodriguez<mcgrof@gmail.com>
>>  wrote:
>>>
>>>   What I'd like to do is to affect the ratio to nullify it if the noise
>>>   is very low on the channel. Given that noise is logarithmic we'd have
>>>   to use a logarithmic function as well. Working on that now.
>>
>> OK I've figured a way to plug the noise into this, I designed the
>> following function we can use as a factor:
>>
>> 1.1^(x+110)
>>
>> Wolfram|Alpha boring details of this function:
>>
>> http://bit.ly/mJNXE9
>>
>> x,y results of different noise values in dBm, using apcalc:
>>
>> mcgrof@tux ~ $ calc
>> C-style arbitrary precision calculator (version 2.12.3.3)
>> Calc is open software. For license details type:  help copyright
>> [Type "exit" to exit, or "help" for help.]
>>
>> ; define f(x) = 1.1^(x+110)
>> f(x) defined
>>
>> ; f(-130)
>>        ~0.14864362802414368640
>> ; f(-120)
>>        ~0.38554328942953174736
>> ; f(-119)
>>        ~0.42409761837248492210
>> ; f(-118)
>>        ~0.46650738020973341431
>> ; f(-117)
>>        ~0.51315811823070675574
>> ; f(-116)
>>        ~0.56447393005377743132
>> ; f(-115)
>>        ~0.62092132305915517445
>> ; f(-114)
>>        ~0.68301345536507069189
>> ; f(-113)
>>        ~0.75131480090157776108
>> ; f(-112)
>>        ~0.82644628099173553719
>> ; f(-111)
>>        ~0.90909090909090909091
>> ; f(-110)
>>        1
>> ; f(-109)
>>        1.1
>> ; f(-108)
>>        1.21
>> ; f(-107)
>>        1.331
>>
>> So then, we'd use a frequency for initiating beaconing (AP, Mesh, P2P)
>> which uses the lowest value from the following computation:
>>
>> (busy time - tx time) / (active time - tx time) * 1.1^(noise + 110)
>>
>> The 1.1 factor can be modified more accurately to represent the
>> exponential factor of how noise should affect interference decisions,
>> the 110 value here can be modified for any other arbitrary value we
>> find as representative of a regular noise value from a simple AP on
>> the frequency we are observing, my assumption here was -110 dBm.
>
> -110 dBm is not a real noise value. It's an unrealistic, ath9k-specific
> value. I have a patch that changes ath9k to make noise and signal strength
> values more realistic, and I'll submit it soon, as soon as I've made it a
> bit more precise.

Nice. As I noted though this value is arbitrary for now, we can change
it at will. Any other feedback? If not I'll start hacking on it.

 Luis

Re: Initial automatic channel selection implementation

[Jouni Malinen]

On Wed, May 25, 2011 at 07:37:31AM -0700, Luis R. Rodriguez wrote:
> Nice, yeah I was thinking of using the offchannel operation if we want
> to spend more time there for inspection and if associated. For first
> iteration it should be possible to just move around. In fact for AP
> purposes I suppose one will want to just start AP mode ASAP and then
> later do offchannel operations to do the inspection on the ideal
> channel. Otherwise we sit there idle until we complete the Automatic
> Channel Selection thingy.

For P2P use cases, it would be convenient to maintain some information
about what could be the best channel on 2.4 GHz and 5 GHz band all the
time. This does not have to be the best possible channel, but something
reasonably good. There is no time to go through additional scanning of
all channels in number of P2P protocol exchanges, so this type of
information is needed before starting GO Negotiation (which could be
started by other devices, too). It is possible to change channels later
if a considerably better alternative becomes known after the group has
been started.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Initial automatic channel selection implementation

[Pavel Roskin]

On 05/24/2011 08:48 AM, Luis R. Rodriguez wrote:

> I - Simple solution:
>
>    * Look for the frequency in a band that has the less amount of BSSes
> with the lowest link quality

I think it would be better to consider every BSS, but use weights based 
on speed, whether it's an ad-hoc node or an AP, and possibly on the 
supported features (power saving etc).

That algorithm may actually give acceptable results, even when there is 
traffic on all channels.

Speaking of channels, I think only some channels should be eligible for 
automatic selection (that would be 1, 6 and 11 in the 2.4 GHz range).

-- 
Regards,
Pavel Roskin

Re: Initial automatic channel selection implementation

[Cristian Ionescu-Idbohrn]

On Tue, 24 May 2011, Pavel Roskin wrote:
>
> Speaking of channels, I think only some channels should be eligible for
> automatic selection (that would be 1, 6 and 11 in the 2.4 GHz range).

May I ask what the rationale behind that may be?


Cheers,

-- 
Cristian

Re: Initial automatic channel selection implementation

[Pavel Roskin]

On 05/24/2011 12:44 PM, Cristian Ionescu-Idbohrn wrote:
> On Tue, 24 May 2011, Pavel Roskin wrote:
>>
>> Speaking of channels, I think only some channels should be eligible for
>> automatic selection (that would be 1, 6 and 11 in the 2.4 GHz range).
>
> May I ask what the rationale behind that may be?

That's a safe distance between channels.  That's why channels 1, 6 and 
11 are used more often than others.

Our algorithm make select, say, channel 3.  That may be the most quiet 
channel at the moment.  We may use absolutely the best algorithm to 
determine that.  However, it is likely that APs operating on channels 1 
and 6 would eventually appear in vicinity, and out AP would interfere 
with both of them instead of just one of them.

Using a car analogy, consider channels 1, 6 and 11 like lanes on a 
highway.  Using other channels would be like driving between lanes.  It 
may seem safe, but only in absence of other traffic.

It's possible that the list of autoselectable channels could be country 
specific.  I would hate to add complexity to CRDA.  Hopefully we could 
device a simple algorithm to find the autoselectable channels based on 
the CRDA data.

-- 
Regards,
Pavel Roskin

Re: Initial automatic channel selection implementation

[Helmut Schaa]

Am Dienstag, 24. Mai 2011 schrieb Pavel Roskin:
> On 05/24/2011 12:44 PM, Cristian Ionescu-Idbohrn wrote:
> > On Tue, 24 May 2011, Pavel Roskin wrote:
> >>
> >> Speaking of channels, I think only some channels should be eligible for
> >> automatic selection (that would be 1, 6 and 11 in the 2.4 GHz range).
> >
> > May I ask what the rationale behind that may be?
> 
> That's a safe distance between channels.  That's why channels 1, 6 and 
> 11 are used more often than others.
> 
> Our algorithm make select, say, channel 3.  That may be the most quiet 
> channel at the moment.  We may use absolutely the best algorithm to 
> determine that.  However, it is likely that APs operating on channels 1 
> and 6 would eventually appear in vicinity, and out AP would interfere 
> with both of them instead of just one of them.
> 
> Using a car analogy, consider channels 1, 6 and 11 like lanes on a 
> highway.  Using other channels would be like driving between lanes.  It 
> may seem safe, but only in absence of other traffic.
> 
> It's possible that the list of autoselectable channels could be country 
> specific.  I would hate to add complexity to CRDA.  Hopefully we could 
> device a simple algorithm to find the autoselectable channels based on 
> the CRDA data.

Why not use a channel list as input to the algorithm (in whatever form).
Hence, it would work for all channels (if the user wishes to do so) but it
can be limited to a list of preferred channels (1,6,11).

Helmut

Re: Initial automatic channel selection implementation

[Adrian Chadd]

On 25 May 2011 12:24, Helmut Schaa <helmut.schaa@googlemail.com> wrote:

>> It's possible that the list of autoselectable channels could be country
>> specific.  I would hate to add complexity to CRDA.  Hopefully we could
>> device a simple algorithm to find the autoselectable channels based on
>> the CRDA data.
>
> Why not use a channel list as input to the algorithm (in whatever form).
> Hence, it would work for all channels (if the user wishes to do so) but it
> can be limited to a list of preferred channels (1,6,11).

FreeBSD's net80211 seems to do something like this in hostap mode. Has
anyone investigated it?

I ask because I'm about to port channel statistics (survey, ext
channel info) to net80211 in FreeBSD so it can be used in channel
selection and survey feedback.


Adrian

Re: Initial automatic channel selection implementation

[Cristian Ionescu-Idbohrn]

On Wed, 25 May 2011, Helmut Schaa wrote:
> Am Dienstag, 24. Mai 2011 schrieb Pavel Roskin:
> > On 05/24/2011 12:44 PM, Cristian Ionescu-Idbohrn wrote:
> > > On Tue, 24 May 2011, Pavel Roskin wrote:
> > >>
> > >> Speaking of channels, I think only some channels should be eligible for
> > >> automatic selection (that would be 1, 6 and 11 in the 2.4 GHz range).
> > >
> > > May I ask what the rationale behind that may be?
> >
> > That's a safe distance between channels.  That's why channels 1, 6 and
> > 11 are used more often than others.
> >
> > Our algorithm make select, say, channel 3.  That may be the most quiet
> > channel at the moment.  We may use absolutely the best algorithm to
> > determine that.  However, it is likely that APs operating on channels 1
> > and 6 would eventually appear in vicinity, and out AP would interfere
> > with both of them instead of just one of them.
> >
> > Using a car analogy, consider channels 1, 6 and 11 like lanes on a
> > highway.  Using other channels would be like driving between lanes.  It
> > may seem safe, but only in absence of other traffic.
> >
> > It's possible that the list of autoselectable channels could be country
> > specific.  I would hate to add complexity to CRDA.  Hopefully we could
> > device a simple algorithm to find the autoselectable channels based on
> > the CRDA data.
>
> Why not use a channel list as input to the algorithm (in whatever form).
> Hence, it would work for all channels (if the user wishes to do so) but it
> can be limited to a list of preferred channels (1,6,11).

Now, that would be a much smarter way to do it.

Remains to decide a similary smart fall back when a preferred channel
list is not provided.


Cheers,

-- 
Cristian