Search Linux Wireless

Re: background scanning and fast handovers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 17, 2008 at 8:42 AM, Kalle Valo <kalle.valo@xxxxxxxxx> wrote:
> Dan Williams <dcbw@xxxxxxxxxx> writes:
>
>>> How does the compact-wireless driver handle the case, when a
>>> connection of a STA to an AP gets lost?
>>
>> Right now, the lowest-common-denominator is that the driver sends a
>> disconnection event to userspace, and userspace handles reconnection as
>> it sees fit.  Some drivers may attempt to reconnect to the AP
>> periodically until told not to.
>
> Are you talking about mac80211 drivers here? I haven't seen any
> mac80211 driver do that.
>
>> I personally think the driver/stack should try a few reconnections to
>> the AP (without sending the SIOCSIWAP disconnect event) and only if
>> those all fail, send the disconnect event.
>
> Actually I disagree with this, because it might slowdown roaming too
> much. The logic should be either in user space or in mac80211, but not
> in both. Now it's implemented in user space and, in my opinion, that's
> the best place.
>
>> But if the reconnection was successful, send the SCIOCSIWAP event
>> for the AP even if it matches the old AP's BSSID just so userspace
>> knows that something happened. wpa_supplicany may need to know this
>> to rekey the connection or something.
>
> Yes, we have to send SIOCSIWAP event after every association.
>
>>> Are there any activities to implement something like a "background
>>> scanning" in STA Mode?
>>
>> Some drivers already do this (ipw for example), but I don't think
>> background scanning is really implemented in mac80211 at this time.
>
> My understanding is that mac80211 assumes user space to do this. I
> think wpa_supplicant doesn't do that currently, it only issues a scan
> if it receives a disassociation event.
>
> (Please correct me if I'm wrong.)
>
>> mac80211 certainly will handle beacons and probe responses _on the
>> same channel_, but I don't believe there is any sort of
>> multi-channel background scanning going on, nor should there really
>> be unless it can be made _very_ fast. You don't want the driver
>> doing a multi-channel background scan while you're using VOIP.
>
> If the STA is stationary, then background scanning isn't that
> beneficial, that's true. But if STA is moving, when there are benefits
> from background scanning because of faster roaming. I haven't measured
> it ever, but I assume that background scanning and roaming to an
> another AP beforehand is always faster than loosing a connection.
>
> The way I see this is that mac80211 should follow the connection
> quality (RSSI, transmission failures, beacon losts, etc) and signal
> userspace if the connection quality gets low and the signal would then
> trigger background scanning in user space. If the signal gets better,
> mac80211 would send a signal stating so and user space would turn off
> background scanning.
>
> If background scanning affects the normal data transfer too much
> we can always try to optimise the scan, for example by scanning every
> third channel at a time or something similar.
>
>>> A background scanning will allow a STA to observe the neighbourhood
>>> for new APs.
>>
>> Right.
>>
>>> There are a few drivers that provide this functionality today. The
>>> intention is to reduce Handover latency of a mobile STA, when it
>>> switches from one AP to an other AP.
>>
>> Again, within the same ESS?
>
> I think he is talking about roaming in same ESS here.
>
>>> What do you think: Is it interessting for you, to work jointly on
>>> these challenges?
>>
>> Personally I think anything we can do to make intra-ESS handover faster
>> is a good thing.  wpa_supplicant in userspace is obviously required here
>> for WPA roaming and it can handle things like preauth and other bits of
>> fast reauth defined in the WPA specs.  Since that's where things are
>> going, it's going to need coordination between both the driver and the
>> supplicant to get right.
>
> I'm very interested about this as well. I expect to work on this more
> in a month or two.
>

I think Cisco APs implements fast roaming ... intra-ESSI think they
made it also to 802.11r. So there is no much invention
just implement the spec :) http://en.wikipedia.org/wiki/IEEE_802.11r.

For regular roaming you need background scanning. Such scanning should
be rather limited to not hurt performance.
The best known approach to me is using direct scan scan to known
possible AP. Yet there is no notion
of a profile in mac80211 or wext. So you cannot set bunch of SSIDs to
be scanned for to find appropriate roaming candidate in background.
Iwlwifi HW has this infrastructure but it's not used.
The other approach is limit number of channels in each round of the scan.

Tomas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux