Tuning "roaming"

[Marty Galyean]

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.

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
>