[PATCH] wpa_supplicant: Prefer 5 GHz networks over 2.4 GHz networks.

[Gary Morain]

[resending from the right account...]

On Tue, Aug 16, 2011 at 3:50 PM, Dan Williams <dcbw at redhat.com> wrote:

> On Tue, 2011-08-16 at 10:43 -0700, Sam Leffler wrote:
> > On Mon, Aug 15, 2011 at 3:41 PM, Dan Williams <dcbw at redhat.com> wrote:
> > > On Fri, 2011-08-05 at 16:23 -0700, Gary Morain wrote:
> > >> In scan.c, merge a channel's noise value into the scan results.  When
> comparing
> > >> scan results, compute the signal-to-noise ratio and use it when
> available.
> > >> Prefer a 5 GHz network if its SNR is really big (> 30) or if its SNR
> is
> > >> relatively close to the other network's.
> > >
> > > Honestly I'd rather have something like a "bands" option on a
> > > per-netblock basis, so you could do this:
> > >
> > > bands=5
> > > bands=5,2
> > > bands=2,5
> > > bands=2
> > >
> > > ie, the connection manager can set whichever band it prefers, or leave
> > > it out entirely to let the supplicant do whatever it's already doing.
> > > The problem with micro-optimizations like this are that they often
> > > break, and they aren't necessarily clear.  I'd advocate for simpler,
> > > clearer rules here, with behavior set by the connection manager, rather
> > > than continually more complicated matching rules in the supplicant
> > > itself...
> >
> > I'm trying to understand how this would be used.  The point of Gary's
> > change is to prefer the 5GHz band only when two AP's have equivalent
> > signal quality. (5GHz is considered better because it has
> > non-overlapping channels, less likely to have interference, etc.)
> > This is meant to improve the algorithm by which a BSS is selected.
>
> Yeah, I guess that's different than I'm proposing.  But making this
> decision is still a policy decision that I'm not sure should be done in
> the supplicant.
>

The supplicant already makes a decision on which channel to use.  I'm not
proposing a new policy but instead a refinement of the existing policy to
prefer 5 GHz channels.

There are in fact two refinements in the CL.

1) Instead of using signal level as the criteria for channel quality, use
signal-to-noise ratio if available.  SNR is a better metric.  Also, cap SNR
at 30 because channels with an SNR greater than 30 will perform equally well
from a signal quality point of view.  Using SNR for selecting channel is
better for all bands.

2) If two channels have the same or close-enough SNR, then prefer the 5 GHz
channel.  Because of the capping of SNR at 30, it is much more likely that
this preference will occur.

What seems to be controversial is preferring 5 GHz channels.  This behavior
can be configurable.  For sake of simplicity, I propose making the 5 GHz
preference a compile-time option, defaulted to off.

Can we get agreement on this?

>
> > Also, specifying a preference on a per-netblock basis seems odd; when
> > would you want to control band preferences only for a specific SSID?
>
> I've had this request come up periodically.  If your institution uses
> the same SSID between the 5GHz and 2.4GHz wifi networks, but you'd like
> to always be on the 5GHz segment because it's less loaded.  But other
> places you may not want to be on the 5GHz network.  It really is a
> per-SSID (ie per network) preference.
>
> > You can lock down a netblock using bssid= and assign priority though
> > it might be painful to list all the AP's in an ESS.  If we really want
> > to add this complexity it seems like it belongs per-interface or
> > global (or at compile-time).
>
> I disagree.  It's not global to the entire decision, it's specific to
> the netblock.  You may not always want to prefer 5GHz networks
> everywhere you are.  The problem with the freq= parameter is that to
> achieve this behavior you'd have to list *all* the frequencies in the
> 5GHz and 2.4GHz range, while using bssid= is a no-go because the
> situation where you want this behavior is one where there are a ton of
> APs around.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20110818/cc46aa1d/attachment.htm