Non destructive scanning while connected to current AP.

[Andrea G Forte]

Ajeet Nankani wrote:

> Yeah i know that buffered frames are not useful for VoIP, but what if 
> the scanning procedure is modified(selective scaning - your research 
> paper) so that it completes in 20ms to 30ms? I guess in that case 
> these frames might be useful for VoIP.
> Any comments on this.
>
As I said earlier, these frames would be useful if they would not add a 
significant delay to the scanning process. Unfortunately from some first 
measurements I took, it seems that they add some significant delay which 
makes them not useful with any form of scanning (we are always talking 
about real-time traffic here). However, this is a work in 
progress.....will need to take more measurements.
Do you know if these frames behave in this way for Prism2/2.5/3 cards 
only? What about other chipsets? Does anyone know about the madwifi 
group? Do they have the same behaviour with their chipset/card?

Regards,
Andrea


> Also as mentioned in old emails on list that one cant avoid these null 
> frames as these are handled by firmware whenever scanning is done.
>
> Regards,
>
> -ajeet.
>
>
> Andrea G Forte wrote:
>
>> Actually the scenario I was referring to is different from the one 
>> you described. This buffering is particularly useful (if we talk 
>> about NOT real-time apps) when you want to do a pre-scanning. Meaning 
>> that you may want to do an active scanning before the time you may 
>> actually perform an handoff. The STA will send the null function 
>> frame to the AP (start buffering), it will then scan the channels and 
>> ultimately go back to the old AP. It will then send another null 
>> function (stop buffering and send me the buffered frames). The 
>> handoff process is not performed.
>> When the handoff process is performed, buffered frames are not very 
>> useful. SOME of the buffered frames can be sent to the STA between 
>> the last probe response and the auth request by the old AP. An 
>> alternative is that the buffered frames can also be sent by the old 
>> AP to the new AP via IAPP if available. However, when the handoff is 
>> performed, the AP cannot assume that buffered frames will be 
>> delivered (unless IAPP is used for this).
>>
>> Regards,
>> Andrea
>>
>>
>>
>> Ajeet Nankani wrote:
>>
>>> Thanks Forte for the detailed answer, but still i have few more 
>>> question which are not explained in this or the old threads.
>>>
>>> Discussion does not mention that actually at what point STA sends 
>>> authentication and then Re-Association request to new AP. I mean 
>>> when it is currently attached to the AP, then first it sends Null 
>>> Data Frame to curent AP to indicate start of buffering, then it 
>>> scans, then it again send Null Data Frame to current AP to indicate 
>>> stop of buffering, after that i am not sure what happens?
>>> I guess, then STA gets all buffered frames from AP(but does STA 
>>> sends its buffered frames to the current AP or not??), then send 
>>> De-Authentication Frame to current AP, then Sends Authentication 
>>> Frame to the new selected AP from the Scan-Results, then upon 
>>> successful authentication sends re-association frame.
>>>
>>> I guess Forte has a log of captured frames, can you look into your 
>>> frame captures log and see, if it happens like what i described in 
>>> the above para or not or something different?
>>>
>>> Best Regards,
>>>
>>> -ajeet.
>>>
>>> Andrea G Forte wrote:
>>>
>>>> It seems that everytime a handoff occurs, the STA sends Null 
>>>> function packets to the AP, one at the beginning of the scanning 
>>>> process and one at the end of the scanning process. These packets 
>>>> tell the old AP when to start and stop buffering packets for the 
>>>> STA. I had a thread earlier on the meaning of these frames and 
>>>> Jouni explained what I just told you. However, these packets can 
>>>> introduce a significant delay in the handoff process. This means 
>>>> that even though the packets are buffered, if the delay introduced 
>>>> by these null function frames is too big, the buffered packets are 
>>>> useless (at least for VoIP and other real-time applications).
>>>> It would be better to not have them at all when using real-time 
>>>> applications. Unfortunately these frames are controlled by the 
>>>> firmware and not the driver.
>>>> Furthermore if you read the 802.11 standard the particular 
>>>> mechanism that takes care of buffering is "out of the scope" of the 
>>>> standard, so I am not sure if using the null function frames is the 
>>>> "standard" way to do it.
>>>>
>>>> Regards,
>>>> Andrea
>>>>
>>>>
>>>>
>>>> Ajeet Nankani wrote:
>>>>
>>>>> I want to know that when a STA is connected to AP and is actively 
>>>>> transferring and receiving data from AP, and during that when STA 
>>>>> tries to scan network non-destructively then what happens to 
>>>>> current data transfer while scanning, because for scanning, 
>>>>> channel needs to be changed for active probes, so what happens 
>>>>> with the current data frames from current channel?
>>>>>
>>>>> are they lost? or buffered at STA and at AP both? and if buffered, 
>>>>> do STA indicates AP to buffer frames by sending PS frame to AP or 
>>>>> some other procedure?
>>>>>
>>>>> -ajeet.
>>>>
>>>>
>>>>
>>>
>>