| Message ID | 20211003170405.53036-1-mail@david-bauer.net |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | scan: evaluate AP-reported channel load | expand |
On Sun, Oct 03, 2021 at 07:04:05PM +0200, David Bauer wrote: > When determining the expected throughput from a AP, take the AP-reported > channel utilization (QBSS Load element) into consideration. While it would be nice to do something like this to be able to use that information from the AP, this specific way of doing that would seem to have a significant risk of penalizing any AP that supports this capability compared to APs that do not provide any indication which would be processed as if they had advertised 0% channel load. That does not feel correct and could result in selecting worse candidates. I would also point out that at least the last time I did some testing between vendor implementations, the reported values were completely different between two APs on the same channel in more or less the same location in the test setup.. In other words, I would not place much, if any, trust in this value being something that could be compared between two different APs. The only thing that seemed to be more or less comparable was the values from the same AP device in a sense that the channel load value increased when there was more traffic on the channel..
Hi Jouni, thanks for your review. On 10/15/21 11:22 PM, Jouni Malinen wrote: > On Sun, Oct 03, 2021 at 07:04:05PM +0200, David Bauer wrote: >> When determining the expected throughput from a AP, take the AP-reported >> channel utilization (QBSS Load element) into consideration. > > While it would be nice to do something like this to be able to use that > information from the AP, this specific way of doing that would seem to > have a significant risk of penalizing any AP that supports this > capability compared to APs that do not provide any indication which > would be processed as if they had advertised 0% channel load. That does > not feel correct and could result in selecting worse candidates. Good point, this is indeed a problem in the current state. > > I would also point out that at least the last time I did some testing > between vendor implementations, the reported values were completely > different between two APs on the same channel in more or less the same > location in the test setup.. In other words, I would not place much, if > any, trust in this value being something that could be compared between > two different APs. The only thing that seemed to be more or less > comparable was the values from the same AP device in a sense that the > channel load value increased when there was more traffic on the > channel.. > Just to be sure - do you dislike the idea of implementing the Channel load at all or do you think It's better if we cap the impact at some value (50% of throughput)? I'm aware the implementation on the AP side vary widely. However, when having a multi-AP setup with multiple identical APs with multiple 5GHz radios operating on different frequencies (e.g. a lecture hall), selecting a BSS with lower load is preferable IMHO. I also thought about comparing based on connected Stations, however this would require a larger refactoring of the selection code. Best David
diff --git a/wpa_supplicant/scan.c b/wpa_supplicant/scan.c index 97a8d9a63..e8cc8b623 100644 --- a/wpa_supplicant/scan.c +++ b/wpa_supplicant/scan.c @@ -2617,7 +2617,7 @@ void scan_est_throughput(struct wpa_supplicant *wpa_s, { int rate; /* max legacy rate in 500 kb/s units */ int snr = res->snr; - const u8 *ies = (const void *) (res + 1); + const u8 *ies = (const void *) (res + 1), *ie; size_t ie_len = res->ie_len; if (res->est_throughput) @@ -2631,7 +2631,19 @@ void scan_est_throughput(struct wpa_supplicant *wpa_s, res->est_throughput = wpas_get_est_tpt(wpa_s, ies, ie_len, rate, snr, res->freq); - /* TODO: channel utilization and AP load (e.g., from AP Beacon) */ + /* Estimate throughput based on channel load reported by AP. + * Assume that a load of 255 (100%) means no throughput is + * possible. A load of 0 equals to the full estimated throughput + * being achievable. + * + * Use the calculated throughput without any panilty, in case + * BSS load element is not present. + */ + ie = get_ie(ies, ie_len, WLAN_EID_BSS_LOAD); + if (ie == NULL || ie[1] < 5) + return; /* No BSS Load advertised */ + + res->est_throughput = (res->est_throughput * (255 - ie[4])) / 255; }
When determining the expected throughput from a AP, take the AP-reported channel utilization (QBSS Load element) into consideration. Signed-off-by: David Bauer <mail@david-bauer.net> --- wpa_supplicant/scan.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)