Roaming questions

Roaming questions

[Alexander Ganslandt]

Hello,

I'm looking into different roaming solutions and currently evaluating 
iwd, which seems promising so far! My use-case is a device live 
streaming video while moving around large areas, and the goal is to do 
so without hiccups in the live stream. I have a few questions:

Looking at station_roam_failed(), it will schedule a full scan if the 
previous limited scan failed to find a better BSS to roam to. A full 
scan on our chip takes about 7 seconds, which is often enough time for 
the signal to get low enough to deauthenticate the station when you're 
moving. It seems to me that a better approach would be to schedule a 
scan for either the "known frequencies", or all non-DFS frequencies 
(since passive scanning takes extra time) or some other popular group of 
frequencies that won't take long to scan. If we're lucky there is a good 
BSS in that scan, otherwise we schedule a scan for the rest of the 
frequencies. In the worst case, this should be identical to a full scan 
with minor extra overhead. Do you have any thoughts about this from your 
side? Is it something that could be accepted into iwd or could it cause 
issues for other use-cases?

Another question is about the "CriticalRoamThreshold". There seems to be 
a config for this and some functions for lowering and raising the roam 
threshold, but I can't see that they're called from anywhere? It seems 
to me that only "RoamThreshold" is used, or am I missing something? 
There's also a hardcoded delay of 5 seconds from the point where the 
roam threshold is passed before a scan is started, is that just a 
"hysteresis" to not immediately start a scan if the signal temporarily 
drops, or does it have some other function?

Thanks in advance!

Best regards,
Alexander

Re: Roaming questions

[Denis Kenzior]

Hi Alexander,

On 2/13/25 9:01 AM, Alexander Ganslandt wrote:
> Hello,
> 
> I'm looking into different roaming solutions and currently evaluating iwd, which 
> seems promising so far! My use-case is a device live streaming video while 
> moving around large areas, and the goal is to do so without hiccups in the live 
> stream. I have a few questions:
> 
> Looking at station_roam_failed(), it will schedule a full scan if the previous 
> limited scan failed to find a better BSS to roam to. A full scan on our chip 
> takes about 7 seconds, which is often enough time for the signal to get low 
> enough to deauthenticate the station when you're moving. It seems to me that a 
> better approach would be to schedule a scan for either the "known frequencies", 

The idea is to use neighbor reports when possible.  If neighbor reports are 
supported, iwd scans the frequencies in the neighbor report.  Otherwise the 
limited scan uses the frequencies that iwd knows the network operates on.  If 
the limited scan fails, then iwd falls back to the catch-all full scan.  The 
hope is that falling back to the full scan should never happen in practice.

> or all non-DFS frequencies (since passive scanning takes extra time) or some 
> other popular group of frequencies that won't take long to scan. If we're lucky 
> there is a good BSS in that scan, otherwise we schedule a scan for the rest of 
> the frequencies. In the worst case, this should be identical to a full scan with 
> minor extra overhead. Do you have any thoughts about this from your side? Is it 
> something that could be accepted into iwd or could it cause issues for other 
> use-cases?

If you find that full scans do indeed happen when roaming, then introducing 
intermediate limited / non-DFS scan(s) prior to the catch-all scan would be just 
fine.

> 
> Another question is about the "CriticalRoamThreshold". There seems to be a 
> config for this and some functions for lowering and raising the roam threshold, 
> but I can't see that they're called from anywhere? It seems to me that only 
> "RoamThreshold" is used, or am I missing something? There's also a hardcoded 
> delay of 5 seconds from the point where the roam threshold is passed before a 
> scan is started, is that just a "hysteresis" to not immediately start a scan if 
> the signal temporarily drops, or does it have some other function?

This is currently used with the Affinities property on the Station interface. 
For now it is only useful to lock the station to the currently connected BSS to 
prevent roaming.  For example, for the duration of firmware upgrade or similar 
scenarios.

> 
> Thanks in advance!
> 
> Best regards,
> Alexander
> 

Regards,
-Denis

Re: Roaming questions

[James Prestwood]

On 2/13/25 7:24 AM, Denis Kenzior wrote:
> Hi Alexander,
>
> On 2/13/25 9:01 AM, Alexander Ganslandt wrote:
>> Hello,
>>
>> I'm looking into different roaming solutions and currently evaluating 
>> iwd, which seems promising so far! My use-case is a device live 
>> streaming video while moving around large areas, and the goal is to 
>> do so without hiccups in the live stream. I have a few questions:
>>
>> Looking at station_roam_failed(), it will schedule a full scan if the 
>> previous limited scan failed to find a better BSS to roam to. A full 
>> scan on our chip takes about 7 seconds, which is often enough time 
>> for the signal to get low enough to deauthenticate the station when 
>> you're moving. It seems to me that a better approach would be to 
>> schedule a scan for either the "known frequencies", 
>
> The idea is to use neighbor reports when possible.  If neighbor 
> reports are supported, iwd scans the frequencies in the neighbor 
> report.  Otherwise the limited scan uses the frequencies that iwd 
> knows the network operates on.  If the limited scan fails, then iwd 
> falls back to the catch-all full scan.  The hope is that falling back 
> to the full scan should never happen in practice.
>
>> or all non-DFS frequencies (since passive scanning takes extra time) 
>> or some other popular group of frequencies that won't take long to 
>> scan. If we're lucky there is a good BSS in that scan, otherwise we 
>> schedule a scan for the rest of the frequencies. In the worst case, 
>> this should be identical to a full scan with minor extra overhead. Do 
>> you have any thoughts about this from your side? Is it something that 
>> could be accepted into iwd or could it cause issues for other use-cases?
>
> If you find that full scans do indeed happen when roaming, then 
> introducing intermediate limited / non-DFS scan(s) prior to the 
> catch-all scan would be just fine.

This is an area I want to improve since we do see full scans routinely. 
Not because we didn't see any acceptable BSS's via neighbor reports, but 
because the current one was simply better. Likely another limited scan 
using the very same neighbor reports, just done later, would result in a 
successful roam. But its tough because you can't always the APs are 
sending accurate neighbor reports.
>
>>
>> Another question is about the "CriticalRoamThreshold". There seems to 
>> be a config for this and some functions for lowering and raising the 
>> roam threshold, but I can't see that they're called from anywhere? It 
>> seems to me that only "RoamThreshold" is used, or am I missing 
>> something? There's also a hardcoded delay of 5 seconds from the point 
>> where the roam threshold is passed before a scan is started, is that 
>> just a "hysteresis" to not immediately start a scan if the signal 
>> temporarily drops, or does it have some other function?
>
> This is currently used with the Affinities property on the Station 
> interface. For now it is only useful to lock the station to the 
> currently connected BSS to prevent roaming.  For example, for the 
> duration of firmware upgrade or similar scenarios.
>
>>
>> Thanks in advance!
>>
>> Best regards,
>> Alexander
>>
>
> Regards,
> -Denis
>

Re: Roaming questions

[Alexander Ganslandt]

>>> or all non-DFS frequencies (since passive scanning takes extra time)
>>> or some other popular group of frequencies that won't take long to
>>> scan. If we're lucky there is a good BSS in that scan, otherwise we
>>> schedule a scan for the rest of the frequencies. In the worst case,
>>> this should be identical to a full scan with minor extra overhead. Do
>>> you have any thoughts about this from your side? Is it something that
>>> could be accepted into iwd or could it cause issues for other use-cases?
>>
>> If you find that full scans do indeed happen when roaming, then
>> introducing intermediate limited / non-DFS scan(s) prior to the
>> catch-all scan would be just fine.
> 
> This is an area I want to improve since we do see full scans routinely.
> Not because we didn't see any acceptable BSS's via neighbor reports, but
> because the current one was simply better. Likely another limited scan
> using the very same neighbor reports, just done later, would result in a
> successful roam. But its tough because you can't always the APs are
> sending accurate neighbor reports.

Yes, I also see full scans routinely for exactly the reason you 
highlighted, that no other BSS is better than the current one. I also 
see that the neighbor report doesn't include all nearby BSSes, it seems 
to prioritize 2.4 GHz and leave out 5 GHz, but maybe that's a config 
issue on the AP side or the 5 GHz signal is too weak for it to pick up. 
Either way, immediately going for a full scan seems a bit overkill.

I plan on doing some more testing to see if I can improve this, will 
report back if that's the case!

>>> Another question is about the "CriticalRoamThreshold". There seems to
>>> be a config for this and some functions for lowering and raising the
>>> roam threshold, but I can't see that they're called from anywhere? It
>>> seems to me that only "RoamThreshold" is used, or am I missing
>>> something? There's also a hardcoded delay of 5 seconds from the point
>>> where the roam threshold is passed before a scan is started, is that
>>> just a "hysteresis" to not immediately start a scan if the signal
>>> temporarily drops, or does it have some other function?
>>
>> This is currently used with the Affinities property on the Station
>> interface. For now it is only useful to lock the station to the
>> currently connected BSS to prevent roaming.  For example, for the
>> duration of firmware upgrade or similar scenarios.

Ah, Yocto Styhead is using iwd 2.20 and in that version the functions 
for using CriticalRoamThreshold were implemented but no one was using 
them. I've now updated to 3.2 and see it used for affinities. Thank you 
for the pointer!

BR,
Alexander