On Tue, 2009-03-24 at 11:15 +0100, Helmut Schaa wrote:
> Am Dienstag, 24. März 2009 schrieb Holger Schurig:
> > > 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.
> >
> > For one the disadvantage you mentioned I have some ideas:
> >
> > > - The signal strength values on different cards are not
> > > comparable. So the threshold value has to be different for all
> > > cards.
> >
> > First thing is to make the drivers report similar values in
> > similar situations. What would be helful for user-space as well,
> > so I think this should eventually be tackled independend of
> > roaming anyway.
>
> Yep, that would help a lot (if it is achievable).
>
> > But consider for now the case where two different cards provide
> > values that are (absolutely) quite different. If we look at
> > signal differences, this wouldn't harm us that much. Consider
> > this bss entries:
> >
> > bss 1: 45
> > bss 2: 42 <- also the current one
> > bss 3: 10
> >
> > In this case the difference from our BSS to the best matching one
> > is only 3. If we have some heuristic that says "Only roam if you
> > find an AP which is 6 points betters" we wouldn't roam. If
> > another card would report for the same situation
> >
> > bss 1: 54
> > bss 2: 50 <- also the current one
> > bss 3: 12
> >
> > (that's the same as above, but multiplied by 1.2) the outcome
> > would be the same.
>
> Got your point. My concern was not about the AP selection ;). More that if
> the values are hardly comparable (like card A returns a value of 40 while
> card B returns a value of 50 for the same AP) it is difficult to find a good
> threshold value when to trigger a scan.
>
> > > - Ping-pong effect if you sit between two APs both are in
> > > range but with a signal strength around the threshold.
> >
> > It's my understanding that a good threshold would also prevent
> > ping-pongs ?!?
>
> Hmm, quick example: AP1 - STA - AP2
>
> We cannot consider the signal strength as constant as it varies over time
> even when neither the STA nor the AP are moving. Assume a threshold value
> of t=40. Furthermore, the signal strength of AP1 and AP2 might alter between
> 35-50 which means we have an average signal strength of 42,5 > t. Nevertheless
> that would result in ping-pongs between AP1 and AP2 because the signal might
> drop below t on both APs, while it would be better to stick to one AP as the
> signal is already quite bad (but still good enough to do some communication).
>
> > > - 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.
> >
> > Either you know that your device is moving, than you want this
> > scanning, because soon the scanning is no longer unnecessary.
> > Even if at the current position (corner of the
> > street/warehouse/whatever) you "scan" in vein, some minutes
> > later the situation has changed.
> >
> > Or you know that you're in hot-spot mode and then you attach to
> > an AP and stay with it. Then you don't need the whole roaming
> > sermon at all --- this is BTW the reason why mac80211 is,
> > despite it's awful roaming, such a success so for.
> >
> > What I meant is that this is a policy decision (or trade-off
> > decision), that the user should be able to influence.
>
> Fully agreed. It would really make sense to turn on roaming on a per
> network base (maybe in wpa_supplicant's network blocks for example).
>
> > For one of my devices, I made lots of local changes:
> >
> > - I provide a list of channels for the driver to scan. In most
> > warehouses only channels 1, 6, 11 are used. Then there's no
> > reason for the driver to scan at channel 2,3,4 etc. If user-
> > space didn't provide such a list, the driver has to scan on
> > all frequencies, so this is merely an optimization. But an
> > important one, helps tremenduously.
> >
> > - I let the driver scan one frequency every n time units, e.g.
> > every second one channel. This makes the driver visit all
> > three channels during 3 seconds.
> >
> > - If I would get all beacons of the current channel, AND if the
> > ESSID is not hidden, I would only scan for the channels I'm
> > not on. Because for my current channels I have the signal
> > strengths of all channels anyway and know also ESSID an IEs
> > to decide if I can roam or not, should the need arise.
> >
> >
> >
> > > b) Number of consecutivley missed beacons below threshold
> >
> > This tends to roam only when it is too late, e.g. when the
> > connection is nearly breaking. But you wrote this by
> > yourself :-)
> >
> > In my case, I'm doing a full scan if this happens, to protect
> > about bad channel list provisioning.
> >
> >
> >
> >
> > > c) Only scan for new APs if the environment changes (e.g. we
> > > are moving or the AP is moving etc.)
> >
> > You very seldom know about this, e.g. GPS is mostly useless
> > inside big buildings.
> >
> > You can however record "Okay, when I associated to the AP my
> > signal strength was 56. If it drops below 50, I'll look if I
> > find something better".
> >
> > > I already did some research on c) and it looks very promising
> > > but the topic is quite complex and needs more theoretical
> > > research first.
> >
> > If you're serious about that then mac80211 should only get the
> > infrastructure necessary so that we can write different roaming
> > implementations, like we now have different rate selection
> > implementations.
>
> Yes, that's a good idea. There are some more scenarios where different
> roaming algorithms might make sense. However, I'm still not sure where
> the roaming decision should be made (and thus where the algorithm should
> be implemented). In user space (wpa_supplicant) or in mac80211. Having
> it in user space would allow non-mac80211-drivers to benefit too but the
> driver would have to provide the necessary information.
>
> > > 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.
> >
> > That's similar to my local, debugfs-based channel list hack, but
> > better :-)
> >
> > But please make this be able to run from wpa_supplicant alone,
> > don't force NM into the picture. Many embedded developers will
> > say "thank you" for this. :-)
>
> Also agreed. The solution should be usable without NM too but I thought
> more about the degree of automatism here. If plain wpa_supplicant is used
> the wpa_supplicant config should simply contain the channel list statically
> configured while in the NM case the channel list could be created by NM
> based on historical data.
Most wifi-related stuff should be implemented in the supplicant anyway.
Shouldn't need NM for that. Think of NM more of an overall network
policy manager and configuration storage manager instead of a wifi
control daemon. NM pushes configuration to the supplicant, and tells
the supplicant "go!". I don't have any particular objection to letting
the supplicant make the roaming decisions (or even pushing multiple
network blocks down to the supplicant from NM) as long as the desired
behavior is achieved.
Dan
> > > 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.
> >
> > Or the value should simply be recorded in wpa_supplicant's config
> > file. No need no stinkin' NM ! :-)
>
> Adding a network block through dbus or through the config file is pretty
> much the same. So, yes, this should of course also work with a plain
> supplicant config.
>
> Helmut
> --
> 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
--
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
