ACS seems not to select the best channel in 2.4GHz.

[Eduard GV]

Hi,

>> I think it's not necessary to add adjacent value. Because radio survey data
>> of each channel would detect the adjacent interference actually 20MHz.
>> In fact, the test result shows that ch.4 detect the interference of ch.1,
>> similarly ch.8 detect the interference of ch.11.
>> I attached a patch file for hostapd-v2.3 .
>
> I'm not sure skipping the adjacent channels completely on 2.4 GHz would
> be ideal solution here. It is clear that the channels at each end of the
> band will require something more accurate. It may also be reasonable to
> at least drop the importance of the impact from adjacent channels.

Agreed. Our experience shows that the use of partially overlapping
channels (i.e., not only 1, 6 and 11) is beneficial in dense
environments [1][2], but adjacent channel interference must be taken
into account.

> I'm
> consider the following patch as a way of addressing this. If you define
> ACS_ADJ_WEIGHT 0, ACS_NEXT_ADJ_WEIGHT 0, and ACS_24GHZ_PREFER_1_6_11 1,
> you'd get the behavior you should saw with the patch you sent. If
> someone has good suggestions on what the best numbers to use here as the
> default would be, I'm certainly open to changing these. As noted in the
> commit message, I did not really do any real research on picking the
> numbers.
>

After some experiments and some math[3], we concluded that the
adjacent channel (i.e. my center frequency +- 5MHz) is barely filtered
(~0.5dB), so I'd suggest
#define ACS_ADJ_WEIGHT 0.85

For the case of 2-channel separation (i.e. my center frequency +
10MHz) , the attenuation was ~2.5dB, so I'd suggest
#define ACS_NEXT_ADJ_WEIGHT 0.55

In fact, I'd also suggest that the "next to the next" adjacent channel
(i.e. my center frequency +- 15MHz) should also be taken into account
with a weight of 0.22 since transmissions three channels away do have
an impact on my current channel.

> it is clear that this summing
> of three to five values together and then comparing the sum rather than
> average of some kind cannot be correct.
>(...)
>Band-edge channels are
> handled in a way that takes average over the channels that were actually
> considered instead of assuming zero interference from neighboring bands.
>

On the one hand, I agree that summing of interference_factors doesn't
make much sense (you are summing channel utilization ratios, which
could produce values > 100% of channel utilization?!?). On the other
hand, band-edge channels are actually less interfered since they have
less adjacent channels and, hence, it makes sense they are preferred
(i.e., averaging those interference_factors is not my favorite option
either).
What I'd like to try (at some point, when I have time and resources)
is a different formula for the interference_factor. Something like the
linear sum of the average signal level measured in all channels
(applying attenuation factors) and weighted by their utilization.

> This change results in significantly less preference for the band-edge
> channels. That is arguable good thing to do here, but it would also be
> good to avoid picking some arbitrary 2.4 GHz channel and rather give
> significant extra preference for the commonly used channels 1, 6, 11.
> This is now done by picking those channels over the other ones unless
> another channel has significantly better interference factor (0.8 or
> smaller times the one on 1, 6, 11).
>

Why not 1, 5, 9, 13 (where available)?


[1] http://dx.doi.org/10.1109/PIMRC.2013.6666557
[2] http://dx.doi.org/10.1002/wcm.670
[3] http://hdl.handle.net/2117/1234