[PATCH] roaming: start a scan if the SNR is below customized threshold

[Dan Williams]

On Fri, 2009-09-18 at 09:16 +0200, Holger Schurig wrote:
> > What is roam_snr supposed to be in?  dBm?  What about cards
> > that have no idea what their dBm is?
> 
> When it comes to user-space roaming *WITH A KNOB*, then I don't 
> actually care what is it. As long as it has the following 
> properties:
> 
> * the farther away from the AP the lower the number
> * we have one number reserved for "invalid", "don't know"
>   or "not yet measured", e.g. -1.
> * the value should react promptly to changed environment,
>   this allows roaming of vehicle-mounted WLAN devices
> 
> 
> Say one card gives me the quality between 0..70. The I'd set 
> the "knob" to scan when it's below 30 or 25.
> 
> Another card gives qual between 0..100. I'd set the knob to 30.
> 
> Another card gives me a signal in dBm. I could set the knob 
> to -65.
> 
> 
> You see, the actual range doesn't really care. When I produce a 
> dvice (and I'm a producer of hand-held and fork-lift terminals) 
> I know what card I have, so I can pre-set a sane value. The 
> customer can then modify that value, e.g. to roam early, late or 
> normal. But he has a number to start with, as orientation.
> 
> 
> Now about the necessity of the knob.
> 
> Suppose for a second that every card under the linux earth gives 
> me mBm. And that, by an astonishing miracale, all cards are even 
> calibrated. So they give exactly -53 dBm if the card is in the 
> same position/condition relative to the AP. Could I then life 
> without a justification knob?
> 
> No way. As soon as I put another antenna on my device, or change 
> the housing of the fork-lift terminal, I get back different 
> values, because I changed the electromagnetic environment.
> 
> So I need a knob anyway. And because of the knob, I don't care if 
> I get Qual, Signal, SNR, RSSI or whatever. As long as a lower 
> number means "worse signal" or "farther away from AP".
> 
> We can solve (or try to solve) the dBm/SNR/RSSI/qual mess, but 
> it's not a pre-requisite for good roaming.
> 
> 
> 
> However, I'd prefer "Signal in dBm", so that applications like 
> can come up with a sane default.

Right, that's useful.  I'm also always thinking about how this gets
presented in the UI for users that have no idea what dBm or RSSI are,
nor do they care.  So to make a programmatic intelligent choice, we need
to know in the level above the supplicant what unit it will be, so we
can choose, or we need to make some guarantees about the numbers that
the supplicant reports to the upper layers (ie NM) like whether the
values are linear or quadratic or whatever so we can pick appropriate
bounds.

If there's *any* out-of-band data that the supplicant controller has to
know (ie, "I know this card has an antenna with X gain and the card
reports in dBm so the bounds are Y and Z") that doesn't work for me
because too much a-priori knowledge is required.  Its fine if the
supplicant somehow provides the unit that the driver reports so that NM
can pick the right set of defaults, or if the supplicant says that the
SNR will always change in a linear fashion between two bounds X and Y as
reported by the driver or soemthing.  We may have already nailed this
with mac80211, but likely not with WEXT.

Dan