Re: Google Summer of Code 2009 -- Linux wireless roaming project

[Helmut Schaa <helmut.schaa@googlemail.com>]

Am Freitag, 20. M=C3=A4rz 2009 schrieb Luis R. Rodriguez:
> We need to extend this now and since things are shifting towards nl80=
211
> (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 studen=
ts
> 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:=20
- 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 wit=
h a
  signal strength around the threshold.
- Unnecessary scanning if the signal strength is below the threshold bu=
t 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 alr=
eady
  quite bad but we need around 1 second (beacon interval=3D100ms) to de=
tect
  that =3D> 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 furth=
er
  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 signif=
icant
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 t=
opic
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 w=
ould
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 beca=
use
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 chan=
nels
from within the bg-band due to signal interferences. Instead, all APs w=
ill be
located on non-overlapping channels. Let's say 1,6 and 11. Hence, if th=
e
supplicant tiggers a scan it will just leave all channels !=3D 1,6,11 o=
ut 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 fo=
llowing
would be worth considering: extend wpa_supplicant's network blocks to a=
llow
the specification of preferred channels ("channels=3D1,6,11"). This val=
ue 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 traf=
fic
the software scan implementation would have to be reworked. The scan sh=
ould
simply switch back to the operating channel every once in a while to al=
low
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.pd=
f=20
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html