Am Freitag, 20. März 2009 schrieb Luis R. Rodriguez:
> We need to extend this now and since things are shifting towards nl80211
> (the MLME SAP stuff) I think we may need to rethink this a bit. Ideas,
> wishlists for how to improve our roaming with the help of GSoC students
> would be appreciated.
Ok, here are some considerations regarding roaming:
Basically roaming can be divided into 3 steps:
1) detect if it is time to roam
2) scan for better APs
3) associate with the new AP
Step 1 is the most difficult one here, 2 only needs some tweaking and 3
should work as it is currently.
So, how can we detect if it is beneficial to roam?
a) Just check the signal strength if it drops below a certain threshold
and start a scan if that happens
Advantages:
- Easy to implement
Disadvantages:
- The signal strength values on different cards are not comparable. So the
threshold value has to be different for all cards.
- Ping-pong effect if you sit between two APs both are in range but with a
signal strength around the threshold.
- Unnecessary scanning if the signal strength is below the threshold but no
better AP is in range will further reduce the connection quality and
increase power consumption.
b) Number of consecutivley missed beacons below threshold
Advantages:
- Also easy to implement
- Comparable value on all cards
Disadvantages:
- e.g. 10 consecutively missed beacons means that the connection is already
quite bad but we need around 1 second (beacon interval=100ms) to detect
that => Handoff delay is strictly greater than 1 second (+scan and
association)
- Using smaller values might result in a similar ping-pong effect as
described above
- Unnecessary scanning if the number of missed beacons drops below the
threshold every once and then but no better AP is in range will further
reduce the connection quality and increase power consumption.
c) Only scan for new APs if the environment changes (e.g. we are moving or
the AP is moving etc.)
This could for example be done by computing the sample variance of the signal
strength (maybe measured over the last second) which will change significant
if the client or the AP is moving (see [1] for details).
If the client device has a GPS it would be beneficial to only scan for better
APs if the client is moving.
Advantages:
- Number of unnecessary scans is lower than for a) and b)
Disadvantages:
- Needs some more theoretical research on how to automatically find the
threshold values for the signal strength variance.
- Complex implementation
I already did some research on c) and it looks very promising but the topic
is quite complex and needs more theoretical research first.
Now, some considerations regarding the implementation:
Independently of which trigger is used to start the roaming process I would
suggest the following:
Scanning for new APs should not be started from within the driver or
mac80211. Instead wpa_supplicant should care about that. Why? Just because
the supplicant might have more information (maybe provided by NM) about the
used network. For example a typical multi-AP network won't use all channels
from within the bg-band due to signal interferences. Instead, all APs will be
located on non-overlapping channels. Let's say 1,6 and 11. Hence, if the
supplicant tiggers a scan it will just leave all channels != 1,6,11 out of
the scan request and the scan will take a shorter amount of time, which
in turn speeds up the handoff delay.
However, that infrastructure is not there yet but something like the following
would be worth considering: extend wpa_supplicant's network blocks to allow
the specification of preferred channels ("channels=1,6,11"). This value could
be provided by NM which gathered that information either from the user or
through monitoring. If the client was already connected to several APs in the
same ESS it would just pass these channels to wpa_supplicant. Of course if no
AP is found on the preferred channels a full scan might have to run.
Ok, regarding the second part "scanning":
In order to lower the negative influence a scan has to the ongoing traffic
the software scan implementation would have to be reworked. The scan should
simply switch back to the operating channel every once in a while to allow
queued packets to be delivered (in both directions).
Phew! I'm pretty sure I've missed several ideas/considerations here but that
has to suffice for now.
Helmut
[1] http://www.informatik.uni-mannheim.de/pi4/publications/King2008c.pdf
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
