Bug 2855 - Primary channels should be aligned
Primary channels should be aligned
Status: RESOLVED LATER
Product: ns-3
Classification: Unclassified
Component: wifi
ns-3.27
All All
: P3 enhancement
Assigned To: sebastien.deronne
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-15 04:38 EST by Rediet
Modified: 2018-01-24 09:25 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rediet 2018-01-15 04:38:30 EST
As hinted in bug #2843 (namely description and comment 1), when a HT/VHT/HE AP sets up a >20MHz BSS (when turned on or prior to channel switch), it should align its primary channel to existing BSSs so as to facilitate coexistence.
It would thus be interesting to implement this feature in ns-3, knowing that the primary channel is always the lower channel in the current implementation.
Comment 1 sebastien.deronne 2018-01-19 15:59:16 EST
Redit, can you please elaborate on this?
Are you working on a fix or should this be taken up?
Comment 2 Rediet 2018-01-22 03:30:48 EST
(In reply to sebastien.deronne from comment #1)
> Redit, can you please elaborate on this?
> Are you working on a fix or should this be taken up?

It would be interesting to take this up when you have some time to spare (and if there is a specific need). I don't have any plans to work on this on my side. I committed this bug just to have something in the tracker on the subject.
Comment 3 sebastien.deronne 2018-01-22 15:11:23 EST
Rediet, it is not clear for me what you are expecting as feature, can you please give more details?

I am not in favor to put all missing features in this tracker (might end up quite full :-)), especially if nobody is targeting to work on them, I am more in favor to list them in the wiki.
Comment 4 Tom Henderson 2018-01-22 15:49:13 EST
(In reply to sebastien.deronne from comment #3)
> Rediet, it is not clear for me what you are expecting as feature, can you
> please give more details?
> 
> I am not in favor to put all missing features in this tracker (might end up
> quite full :-)), especially if nobody is targeting to work on them, I am
> more in favor to list them in the wiki.


IMHO, we should coordinate who is doing what in the wiki, and use the tracker for active work, but maintain information about missing features in the more structured documentation, such as here:

https://www.nsnam.org/docs/release/3.27/models/html/wifi-design.html#scope-and-limitations
Comment 5 sebastien.deronne 2018-01-22 15:55:55 EST
Tom, agreed, I will update the information.
Comment 6 Rediet 2018-01-23 02:18:44 EST
(In reply to sebastien.deronne from comment #3)
> Rediet, it is not clear for me what you are expecting as feature, can you
> please give more details?

Sorry. Here's more detail concerning the feature, which, by the way, might be rather be related to automatic channel selection. When an AP boots or switches channels, if it cannot find a set of free channels to set up a 40/80/160 MHz BSS, it'll normally try to make its primary channel correspond to the primary channels of existing BSSs. As a consequence it will also adapt the structure of its secondary channels to fit existing deployments (and signal this in the HT/VHT Operation IE).

E.g. ("Existing" being already deployed BSSs, "Auto sel" the adaptive scheme, and "Impl sel" the currently implemented scheme)
Scenario 1
Existing |1ary 20 MHz|2ary 20 MHz|-----------|-----------|

Auto sel |1ary 20 MHz|2ary 20 MHz|-------2ary 40 MHz-----|
Impl sel |1ary 20 MHz|2ary 20 MHz|-----------|-----------|


Scenario 2
Existing |-----------|-----------|1ary 20 MHz|2ary 20 MHz|

Auto sel |-------2ary 40 MHz-----|1ary 20 MHz|2ary 20 MHz|
Impl sel |1ary 20 MHz|2ary 20 MHz|-----------|-----------|


Scenario 3
Existing |2ary 20 MHz|1ary 20 MHz|-----------|-----------|

Auto sel |2ary 20 MHz|1ary 20 MHz|-------2ary 40 MHz-----|
Impl sel |1ary 20 MHz|2ary 20 MHz|-------2ary 40 MHz-----|


As we can see in the examples, the current implementation assumes that secondary channels are always higher than primary channels.

I have to admit that these are simple scenarios and that more complex configurations will surely lead to advanced algorithms, but the idea was to leave a possibility to implement such a feature (or rather note that it as a limitation).


> I am not in favor to put all missing features in this tracker (might end up
> quite full :-)), especially if nobody is targeting to work on them, I am
> more in favor to list them in the wiki.

OK, I'll take note of it.
Comment 7 sebastien.deronne 2018-01-23 15:20:05 EST
Rediet, Ok, that's clearer, I know we have some improvements to be done here but this is indeed listed nowhere. 

Is this fine for you if I close this bug and I add this limitation in the documentation: the current implementation assumes that secondary channels are always higher than primary channels.
Comment 8 Rediet 2018-01-24 02:29:59 EST
I'm perfectly in phase, please do proceed as planned.
Comment 9 sebastien.deronne 2018-01-24 09:25:36 EST
Updated documentation, bug moved to postponed.