These changes account for situations where the CQM threshold
might be approximately the same as the currently received signal,
and thus CQM events are triggered often due to measurement
error/small fluctuations. This results in scanning occurring
too frequently.
Firstly, inhibit the immediate scan when the short-scan count
is at the maximum. This keeps bursts of CQM toggling from
causing a torrent of back-to-back scans. This does not inhibit
immediate scans if the CQM triggers a second time (if the signal
falls lower past the hysteresis). This reduces the scan rate in
the worst case (fast-rate toggling high/low CQM events) to the
short scan interval.
Secondly, change the behavior of the short scan count so it acts like
a "leaky bucket". As we perform short-scans, the bucket fills until
it reaches a maximal short-scan count, at which we back-off and
revert to a long scan interval. The short scan count decreases by
one (emptying the bucket) every time we complete a long scan interval
without a low-RSSI CQM event.
This reduces the impact of medium-rate toggling of high/low CQM
events, reducing the number of short-interval scans that occur before
returning to a long-interval if the system was recently doing
short scans.
If the scan interval switches to the short interval soon after a
scan, bgscan_simple should not immediately scan again. However,
it should also make sure that the next scan occurs no later than
the new, short scan interval.
Signed-off-by: Paul Stewart <pstew@google.com>
We gain diminishing returns by the short scan interval. The short
scan interval is used to hunt for a better AP if the RSSI of the
current AP drops. However, if we never roam, and the AP continues
to have low RSSI, at some point we should give up and return to
the slow background scan rate, otherwise we waste a lot of power.
Signed-off-by: Paul Stewart <pstew@google.com>
It is not guaranteed that we will get a CQM signal shortly after setting
up monitoring. In order to establish the correct initial background
scanning rate, poll directly for the signal strength.
Signed-off-by: Paul Stewart
The driver is likely to indicate an immediate signal event when the
threshold value is configured. Since we do this immediately after
association, there is not much point in requesting a new scan to be
started based on this event.
This allows bgscan modules to use more information to decide on when
to perform background scans. bgscan_simple can now change between
short and long background scan intervals based on signal strength
and in addition, it can trigger immediate scans when the signal
strength is detected to be dropping.
bgscan_simple takes following parameters now:
short interval:signal strength threshold:long interval
For example:
bgscan="simple:30:-45:300"
This fits better in wpa_supplicant/scan.c. Couple of remaining
scan_helpers.c functions are currently used in driver wrappers,
but they can likely be removed in the future.
This allows background scanning and roaming decisions to be contained in
a single place based on a defined set of notification events which will
hopefully make it easier to experiment with roaming improvements. In
addition, this allows multiple intra-ESS roaming policies to be used
(each network configuration block can configure its own bgscan module).
The beacon loss and signal strength notifications are implemented for
the bgscan API, but the actual events are not yet available from the
driver.
The included sample bgscan module ("simple") is an example of what can
be done with the new bgscan mechanism. It requests periodic background
scans when the device remains associated with an ESS and has couple of
notes on what a more advanced bgscan module could do to optimize
background scanning and roaming. The periodic scans will cause the scan
result handler to pick a better AP if one becomes available. This bgscan
module can be taken into use by adding bgscan="simple" (or
bgscan="simple:<bgscan interval in seconds>") into the network
configuration block.
