Bug 2855

Redit, can you please elaborate on this?
Are you working on a fix or should this be taken up?

(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.

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.

(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

Tom, agreed, I will update the information.

(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.

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.

I'm perfectly in phase, please do proceed as planned.

Updated documentation, bug moved to postponed.