Tuning "roaming"

[Dan Williams]

On Tue, 2012-09-11 at 12:33 -0400, Marty Galyean wrote:
> I'm reminded of the law on the road that says you must maintain a lane 
> for at least 100 feet before changing lanes again.  This is to 
> discourage people from weaving in and out of traffic I assume.
> 
> I'm also reminded of algorithms that traverse linked data structures and 
> how they have to have what is called 'cycle detection' for some 
> structures to keep them from getting caught in an infinite loop 
> traversing a subset of nodes in the structure.  Think of an algorithm 
> that tries to solve a maze.  If it doesn't detect that it has already 
> tried a path, then it will likely end up going in circles at some point 
> if there is a way to circle back in the maze at all.
> 
> Anyway, ping-ponging between APs is really just a cycle in the client's 
> search for the best AP among the available options at any given 
> moment/location.  So perhaps detecting the ping-ponging is the way to go 
> rather than trying to solve solely with durations and S/N levels perhaps 
> we also need an N deep buffer of previous AP association durations and 
> S/N levels.   A ping-pong would be detected by a pattern of entries in 
> the history of the same repeating SSIDs and short association durations. 
>   If ping-ponging detected, and current AP is "good enough", then it 
> ain't broke, so no fix.  AP stays the same.

Except by the time it's ping-ponged, you've already lost.  You need to
detect that it would do so *before* you try to roam to the "better" AP
and terminate that attempt.  And the best way we've got do that right
now is signal strength.  It just turns out that signal strength varies a
lot more than perhaps anyone thought, even when you're stationary and in
LoS to the AP.

The specific issue we've encountered is twofold:

1) many enterprise-class APs can broadcast multiple BSSs/SSIDs from the
same access point hardware.  Obviously that means that the signal
strength from all the BSSs should be almost exactly the same.  But
oddly, drivers report different values at different times, leading the
supplicant to even try to jump between BSSs exposed by the same physical
AP.

2) enterprise class hardware also often has dynamic power control at the
AP to mitigate interference.  So we found that often, when this power
control kicked in, the supplicant would suddenly roam to another BSS
because the signal dropped 5 dBm even though it was a relatively strong
signal.

Each roam attempt might require a completely new EAP exchange, or a
completely new 802.11 authentication if the supplicant is not
preauthenticated to that BSS.  That means  many more steps that could
potentially go wrong, and thus could potentially cause your roam attempt
to fail.  That, in turn, causes your VOIP or video stream to hiccup, or
the supplicant to blacklist the AP, perform another scan, leading to yet
more latency, etc.

In the end, I believe less aggressive roaming thresholds are capable of
fixing most of these issues.

Dan

> A metahistory of detected ping-pong patterns indexed by scan results 
> ("posterized" into discrete S/N ranges) could also inform the client to 
> stick with a given AP before ping-ponging even occurs because the 
> metahistory will tell it that the given S/Ns for the currently visible 
> APs suggests a ping pong will occur and that the AP normally settled 
> upon given this metahistory pattern is a given AP.  If this isn't making 
> much sense then consider that the S/N levels of 3 or more nearby APs 
> offer a crude local geolocating ability that can be leveraged without 
> having to actually fully triangulate.  So just correlate a pattern of 
> AP,S/N ranges with a specific AP that ends up being "good" enough.  The 
> correlation occurs over time by which AP "wins" the ping-pong detection 
> and suppression for that rough "location" (using AP,S/N ranges as 
> "coordinates").
> 
> I know, too many words.  Which is why we are on a mailing list instead 
> of twitter, right?  ;^)
> 
> Marty
> 
> 
> On 9/11/12 12:03 PM, Dan Williams wrote:
> > On Mon, 2012-09-10 at 18:35 +0100, Ed W wrote:
> >> Hi, am I missing, or are there any plans to add some variables to tune
> >> the roaming sensitivity? (ie the wpa_supplicant roaming, card is a
> >> RT2870 usb)
> >>
> >> We have some customers in mobile configuration and whilst all is ok in
> >> the lab, out in the field we seem to find that it's fairly easy to see
> >> reasonable sized swings in signal strength which in turn causes regular
> >> roaming jumps and interruption in service.  In fact several customers
> >> say they are literally bouncing between access points every 30/120
> >> seconds when using a config such as:
> >>       bgscan="learn:30:-64:120"
> >
> > We've had exactly the same problem with some of our larger customers.
> > If you're using background scanning, and have a lot of access points,
> > you'll certainly hit this problem of ping-ponging between APs on each
> > scan which increases the possibility of an 802.1x auth failure.
> >
> > If Jouni thinks that the current signal thresholds shouldn't be changed,
> > then a patch to let them be adjusted via the configuration is probably
> > the best way to go.  FWIW I'm using:
> >
> > dbm < -75 :: min_diff = 4
> > dbm < -70 :: min_diff = 6
> > dbm < -65 :: min_diff = 8
> > else min_diff = 15
> >
> > for a modified wpa_supplicant_need_to_roam() in events.c.  This may not
> > work that well if you're in a car but it certainly seems to be a lot
> > more stable at walking speeds.
> >
> > Dan
> >
> >> The mobile customers are actually on yachts and I think because of the
> >> very subtle movement of the boat tilting, plus sometimes shadows due to
> >> small physical obstructions that will be drifting in/out of the way, the
> >> effect is fairly large implied changes in signal level
> >>
> >> What might be helpful would be to have a frequent scan interval, but
> >> only roam if we have recorded an average signal strength over multiple
> >> periods which is greater than some trigger threshold. Probably someone
> >> smarter than me knows why this won't work, so just kicking around an idea?
> >>
> >> Thanks
> >>
> >> Ed W
> >> _______________________________________________
> >> HostAP mailing list
> >> HostAP at lists.shmoo.com
> >> http://lists.shmoo.com/mailman/listinfo/hostap
> >
> >
> > _______________________________________________
> > HostAP mailing list
> > HostAP at lists.shmoo.com
> > http://lists.shmoo.com/mailman/listinfo/hostap
> >
>