Bug 2399

Summary: wifi: add scanning support
Product: ns-3 Reporter: Tom Henderson <tomh>
Component: wifiAssignee: Tom Henderson <tomh>
Status: RESOLVED FIXED    
Severity: enhancement CC: mpuraswani, muh.iqbal.cr, ns-bugs, sebastien.deronne
Priority: P5    
Version: unspecified   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 2400    
Attachments: modified sta-wifi-mac
modified header file
modifed file
example with 1sta and 1 ap
patch file for modification
patch file for modification

Description Tom Henderson 2016-05-03 19:13:14 EDT
This patch adds support to StaWifiMac to allow it to scan and select from multiple possible APs, either on the same channel or across multiple channels.  It relies on bug 2398 patch to carry SNR information up the stack.  It relies on an extension of WifiPhy to define an 'operational channel list' across which it may scan; by default, only the configured channel is scanned.  It defines a scanning timeout (default 120ms) to collect beacons before changing channels.

This is in contrast to the current behavior which will try to associate with the first beacon that it hears on the configured channel.

https://github.com/tomhenderson/ns-3-dev-git/commit/6f5c76a65401f29f031d8c7734dfc6567e4e8eaf
Comment 1 sebastien.deronne 2016-05-04 02:23:40 EDT
It is a really nice new feature. I did not check thoroughly the proposed changes, but it looks ok in general. 
Do you have an example illustrating several different cases (e.g. 1 channel, several channels, several APs on a same channel, several APs on different channels, mobile stations, ...)?
Comment 2 Tom Henderson 2016-05-04 09:13:46 EDT
(In reply to sebastien.deronne from comment #1)
> It is a really nice new feature. I did not check thoroughly the proposed
> changes, but it looks ok in general. 
> Do you have an example illustrating several different cases (e.g. 1 channel,
> several channels, several APs on a same channel, several APs on different
> channels, mobile stations, ...)?

I don't have an example yet since it was used only in the context of 3GPP LAA indoor scenario.  However, I agree that this would be useful as a small standalone example, so I will provide one at a later date.
Comment 3 sebastien.deronne 2016-06-04 06:51:33 EDT
Example to be provided, then ok to be pushed.
Comment 4 sebastien.deronne 2016-11-01 11:35:54 EDT
Tom, by when can you finish this up? 
I think only example needs to be written.
Comment 5 Tom Henderson 2016-11-05 17:17:04 EDT
(In reply to sebastien.deronne from comment #4)
> Tom, by when can you finish this up? 
> I think only example needs to be written.


Not sure; will bump up its priority.
Comment 6 sebastien.deronne 2017-01-02 02:55:51 EST
Tom, any updates? I think it was almost ready to be delivered, so I still believe it could be included in the upcoming release, right?
Comment 7 manish puraswani 2017-02-21 04:27:56 EST
Dear Sir

Requesting you to please update and add this patch in upcomming NS3 release, as channel roaming is my reasearch topic and it will help me lot

regards
manish Puraswani
Comment 8 manish puraswani 2017-03-31 08:54:17 EDT
Created attachment 2815 [details]
modified sta-wifi-mac
Comment 9 manish puraswani 2017-03-31 08:55:04 EDT
Created attachment 2816 [details]
modified header file
Comment 10 manish puraswani 2017-03-31 08:55:40 EDT
Created attachment 2817 [details]
modifed file
Comment 11 manish puraswani 2017-03-31 09:06:58 EDT
Dear Sir;
I have edited attached file to support channel roaming in wifi module and now it works as follows :-

1) if activeprobing is true 
    a) the STA send probe request on each channel configured using 
       AddOperationChannel method of yans-wifi-phy
    b) it wait for minChannelTimeout to switch to next channel if no activity 
       found on current channel
    c) if some activity found it will wait till maxChnnelTimeout to collect 
       probe response.
2) if activeprobing is false i.e. passive probing
    a)it wait till ScanningTimeout on each channel to get Beacon Info.

after selecting best SNR it send association request on that channel and to get AP.

Have tested same for single sta and single AP scenario, and found working fine .

I am testing same for multi STA and multi AP scenario and will update result soon,(facing problem as initialization at same time results in probe request at same time and thus collision in channel.)

With Thanks and Regards
Manish
Comment 12 manish puraswani 2017-03-31 09:15:11 EDT
Created attachment 2818 [details]
example with 1sta and 1 ap

modified wifi simple infra example.
Comment 13 sebastien.deronne 2017-03-31 12:56:34 EDT
(In reply to manish puraswani from comment #8)
> Created attachment 2815 [details]
> modified sta-wifi-mac

Please include patch and tell what you did change compare to Tom's implementation.
Comment 14 manish puraswani 2017-04-01 06:31:06 EDT
Created attachment 2824 [details]
patch file for modification

dear sir

This is the patch file for modification done. 

Following modification has been done :-

IN sta-wifi-mac.cc:-

including new variables :- 
1)MinChannelTimeout & MaxChannelTimeout to store time duration of min channel time and max channel time during active probing
2)activityDetected :- to check some activity on channel

modification of functions 
1)excluding of m_candidateChannels.size check from StaWifiMac::SendProbeRequest (void)
2)modification in StaWifiMac::TryToEnsureAssociated (void) removal of m_bestBeaconObserved.Clear (); as it was resulting in clearing of best becon data of channel and some other improvements
3) inclusion of m_phy->SetChannelNumber (m_bestBeaconObserved.m_channelNumber)in some functions to communicate channel to physical layer
4)modification in StaWifiMac::StartScanning to check active /passive probing and wait on channel accordingly.

Inclusion of new function
1)StaWifiMac::MinScanningTimeout (void)  to check whether to wait for more time to have probeResponse or to switch to new channel

and some other minor modifications.

accordingly modification has been done in sta-wif-mac.h file

some short modification in yans-wifi-phy.cc has been done, to have proper working of GetOperationalChannelList () function

with Regards
Manish Puraswani
Comment 15 manish puraswani 2017-04-01 06:34:21 EDT
Created attachment 2825 [details]
patch file for modification

dear sir

This is the patch file for modification done. 

Following modification has been done :-

IN sta-wifi-mac.cc:-

including new variables :- 
1)MinChannelTimeout & MaxChannelTimeout to store time duration of min channel time and max channel time during active probing
2)activityDetected :- to check some activity on channel

modification of functions 
1)excluding of m_candidateChannels.size check from StaWifiMac::SendProbeRequest (void)
2)modification in StaWifiMac::TryToEnsureAssociated (void) removal of m_bestBeaconObserved.Clear (); as it was resulting in clearing of best becon data of channel and some other improvements
3) inclusion of m_phy->SetChannelNumber (m_bestBeaconObserved.m_channelNumber)in some functions to communicate channel to physical layer
4)modification in StaWifiMac::StartScanning to check active /passive probing and wait on channel accordingly.

Inclusion of new function
1)StaWifiMac::MinScanningTimeout (void)  to check whether to wait for more time to have probeResponse or to switch to new channel

and some other minor modifications.

accordingly modification has been done in sta-wif-mac.h file

some short modification in yans-wifi-phy.cc has been done, to have proper working of GetOperationalChannelList () function

with Regards
Manish Puraswani
Comment 16 Muhammad Iqbal CR 2018-05-28 06:08:59 EDT
Hi everyone,

I have worked with Tom to resolve this bug as a part of my GSoC 2018 project. We improved the state flow of StaWifiMac, refactored part of the code for readability, and added more comments for the documentation. We decided to left out the channel roaming feature since it will complicate the scanning procedure, i.e., for devices running on a standard with a lot of possible operational channel such as 802.11ac, the total scanning timeout can be more than 5 seconds.

The summary of StaWifiMac design improvements is as follows:
- Added a scanning state to gather beacons or probe responses. So rather than STA associating to the first beacon/probe response received, it will wait for an amount of time, then associate to the best AP (i.e., the best beacon/probe resp SNR).
- If the best AP refused STA's association request, STA will try to associate to the next best AP until the list of candidate AP exhausted, if this occur STA will finally go to REFUSED state. Note that we cannot test this behavior since ns-3 haven't implement explicit association refusal from AP.

We have prepared a sequence of 3 patches:
1. Changes on documentation: added information on how Wifi infrastructure association handled on wifi-design.rst, moved StaWifiMac state graph from source file to header file and added more information [1].
2. Refactored part of Receive function that handles updating AP information when receiving beacon, probe response, and association response packets. This changes are for readability and to prepare for patch 3 [2].
3. Implemented the scanning improvements for StaWifiMac, along with documentations and unit tests [3].

[1] https://bitbucket.org/kyuucr/ns-3-dev-lbt/commits/6179c9118c85deb5019808934c051f401032003a?at=bug2399_final
[2] https://bitbucket.org/kyuucr/ns-3-dev-lbt/commits/272843ba5443768036e275cff971bf88321c1f36?at=bug2399_final
[3] https://bitbucket.org/kyuucr/ns-3-dev-lbt/commits/9e74b57a1fc875cbe043c0560a4fbd6a8387cb52?at=bug2399_final
Comment 17 Tom Henderson 2018-05-29 22:11:16 EDT
I would like to include this in the release, so moving to last call.
Comment 18 sebastien.deronne 2018-06-01 15:42:51 EDT
I had a quick look and I don't have objection to have this pushed for the upcoming release. Some comments below:

- Please try to declare any variable representing time using nstime, uint64_t beaconInterval is a wrong choice.

- I don't see the need to have this trace in the final version, or this trace should be more explicit about what it means wrt to AP selection:
NS_LOG_DEBUG ("SnrTag value: " << snrTag.Get());

- I see this: 

In the case when AP responded to STA's association request with a
+ *    refusal, STA will try to associate to the next best AP until the list
+ *    of candidate AP is exhausted which sends STA to Refused state.
+ *    - Note that this behavior is not currently tested since ns-3 does not
+  *     implement association refusal at present.

=> An easy way to have it implemented is by adding attributes in ApWifiMac whether it should refuse non-HT or non-VHT stations. Such options exist for example in hostapd on Linux. I don't mean to have this supported right now, but this could be added somewhere in the wiki?
Comment 19 Muhammad Iqbal CR 2018-06-02 09:02:25 EDT
(In reply to sebastien.deronne from comment #18)

I updated patch 3 according to your suggestion, here is the link to it:
https://bitbucket.org/kyuucr/ns-3-dev-lbt/commits/d3a8b0b5470fc185f72da10d9e1a1e16ec722e37

> - Please try to declare any variable representing time using nstime,
> uint64_t beaconInterval is a wrong choice.

Done, I changed the variable type to nstime.

> - I don't see the need to have this trace in the final version, or this
> trace should be more explicit about what it means wrt to AP selection:
> NS_LOG_DEBUG ("SnrTag value: " << snrTag.Get());

Agreed, I removed the debug log and also moved that SnrTag code block to the appropriate conditional block (i.e., inside if (goodBeacon && m_state == WAIT_BEACON) )
 
> - I see this: 
> 
> In the case when AP responded to STA's association request with a
> + *    refusal, STA will try to associate to the next best AP until the list
> + *    of candidate AP is exhausted which sends STA to Refused state.
> + *    - Note that this behavior is not currently tested since ns-3 does not
> +  *     implement association refusal at present.
> 
> => An easy way to have it implemented is by adding attributes in ApWifiMac
> whether it should refuse non-HT or non-VHT stations. Such options exist for
> example in hostapd on Linux. I don't mean to have this supported right now,
> but this could be added somewhere in the wiki?

Agreed, this is currently outside the scope of the patch, and I would like to implement it next time.
Comment 20 manish puraswani 2018-06-02 10:25:14 EDT
I had just quick look , and has one query.

This patch includes sta-wifi-mac.cc with modification
AddAttribute ("ProbeRequestTimeout", "The duration to actively probe the channel.",TimeValue (Seconds (0.05))

Is it so that the patch have single time duration for active probing (here 0.05 sec)

The standard contains two time duration one Min time and other Max time for active probing.Is it contains both?
Comment 21 Tom Henderson 2018-06-02 11:17:28 EDT
> => An easy way to have it implemented is by adding attributes in ApWifiMac
> whether it should refuse non-HT or non-VHT stations. Such options exist for
> example in hostapd on Linux. I don't mean to have this supported right now,
> but this could be added somewhere in the wiki?

If added on the wiki (such as at https://www.nsnam.org/wiki/Project_Ideas), probably more details are needed to guide someone to the final patch (e.g. the specific API desired, and specific behaviour requested).   Do you want to add this yourself if you have a good idea of what you want to see?
Comment 22 Muhammad Iqbal CR 2018-06-02 11:25:31 EDT
(In reply to manish puraswani from comment #20)
> The standard contains two time duration one Min time and other Max time for
> active probing.Is it contains both?

No, to simplify, I only use one timeout for active scanning (ProbeRequestTimeout), and one for passive scanning (WaitBeaconTimeout). These timeouts are used to gather probe responses or beacons, respectively.

I added small changes in the log for UpdateCandidateApList function, as per Tom's suggestion, the new commit for patch 3 is here:
https://bitbucket.org/kyuucr/ns-3-dev-lbt/commits/a4973ed7f06b54a9b4f8cd33fc2572ed96002d78
Comment 23 Tom Henderson 2018-06-02 11:58:54 EDT
(In reply to manish puraswani from comment #20)
> I had just quick look , and has one query.
> 
> This patch includes sta-wifi-mac.cc with modification
> AddAttribute ("ProbeRequestTimeout", "The duration to actively probe the
> channel.",TimeValue (Seconds (0.05))
> 
> Is it so that the patch have single time duration for active probing (here
> 0.05 sec)
> 
> The standard contains two time duration one Min time and other Max time for
> active probing.Is it contains both?

No, only one.  We should probably point this out in the documentation.  I suppose that we can say that it corresponds to MaxChannelTime since MinChannelTime is not implemented.

I think that supporting Min and Max could be considered in the future as a new feature corresponding to roaming/handoff support.

A related paper, for future reference:  https://arxiv.org/pdf/1102.5189.pdf
Comment 24 sebastien.deronne 2018-06-05 16:28:00 EDT
(In reply to Tom Henderson from comment #21)
> > => An easy way to have it implemented is by adding attributes in ApWifiMac
> > whether it should refuse non-HT or non-VHT stations. Such options exist for
> > example in hostapd on Linux. I don't mean to have this supported right now,
> > but this could be added somewhere in the wiki?
> 
> If added on the wiki (such as at https://www.nsnam.org/wiki/Project_Ideas),
> probably more details are needed to guide someone to the final patch (e.g.
> the specific API desired, and specific behaviour requested).   Do you want
> to add this yourself if you have a good idea of what you want to see?

I can add this if you want. More globally, I'd like to have at least configuration options we don't have but that are available in Linux, in this case in hostapd.
Comment 25 sebastien.deronne 2018-06-05 16:29:50 EDT
(In reply to Tom Henderson from comment #23)
> (In reply to manish puraswani from comment #20)
> > I had just quick look , and has one query.
> > 
> > This patch includes sta-wifi-mac.cc with modification
> > AddAttribute ("ProbeRequestTimeout", "The duration to actively probe the
> > channel.",TimeValue (Seconds (0.05))
> > 
> > Is it so that the patch have single time duration for active probing (here
> > 0.05 sec)
> > 
> > The standard contains two time duration one Min time and other Max time for
> > active probing.Is it contains both?
> 
> No, only one.  We should probably point this out in the documentation.  I
> suppose that we can say that it corresponds to MaxChannelTime since
> MinChannelTime is not implemented.
> 
> I think that supporting Min and Max could be considered in the future as a
> new feature corresponding to roaming/handoff support.
> 
> A related paper, for future reference:  https://arxiv.org/pdf/1102.5189.pdf

If we are not fully supporting the standard, we should indeed document it.

Tom/Muhammad, are you planning to push those changes before the build freeze?
Comment 26 Tom Henderson 2018-06-05 16:33:46 EDT
> 
> Tom/Muhammad, are you planning to push those changes before the build freeze?

Yes, I plan to merge it sometime when I get a chance (merge the latest patch series with an additional documentation note about not supporting Min and Max distinction).
Comment 27 Muhammad Iqbal CR 2018-06-05 16:52:08 EDT
(In reply to Tom Henderson from comment #26)
> > 
> > Tom/Muhammad, are you planning to push those changes before the build freeze?
> 
> Yes, I plan to merge it sometime when I get a chance (merge the latest patch
> series with an additional documentation note about not supporting Min and
> Max distinction).

I can modify the patch if you want me to. I would like to add lines on wifi-design.rst, something like: we did not implement Min/Max channel dwelling time since it is only makes sense for channel roaming, and we currently does not support it.
Comment 28 Tom Henderson 2018-06-07 16:42:15 EDT
pushed in changeset 13633:57d2bb5a9498