Bug 2120

Is there much need to support this mixed technology use case anymore?

Related to this, there is a comment in WifiPhy::ConfigureStandard for 802.11g that short slot time is not supported.  If we do not have mixtures of 802.11g and 802.11b, should we be instead configuring a slot time of 9us by default for 802.11g?

Actually yes, in my own simulations I was fixing it to 9 microseconds. In pure g networks, it should indeed be fixed to 9us.

The mixed technology is needed, I already got some requests from people willing to consider a network with both 802.11b and 802.11g clients, and I believe it's a "nice to have".

I plan to add support for mixed b/g around the end of the year (unless someone else takes up the story), and dynamic adaptation of the slot time value to 20 microseconds if a 802.11b stations is joining the network.
This should not be too much work.

Created attachment 2144 [details]
proposed documentation patch

(In reply to sebastien.deronne from comment #2)
> Actually yes, in my own simulations I was fixing it to 9 microseconds. In
> pure g networks, it should indeed be fixed to 9us.
> 
> The mixed technology is needed, I already got some requests from people
> willing to consider a network with both 802.11b and 802.11g clients, and I
> believe it's a "nice to have".
> 
> I plan to add support for mixed b/g around the end of the year (unless
> someone else takes up the story), and dynamic adaptation of the slot time
> value to 20 microseconds if a 802.11b stations is joining the network.
> This should not be too much work.


Do you agree to the attached documentation patch, in the meantime?

Yes it's fine.

A review request have been started for changes related to this bug:
https://codereview.appspot.com/273510043

Note that documentation will be updated once the changes are being delivered.

Note that I plan to update documentation accordingly in the middle of next week, so I would be glad if reviews could be handled this week.

I have not yet handled code review comments, because I cannot reproduce scenarios where protection show any improvement...

Even though I slightly improved the implementation since latest patch set, I do not observe any bugs from traces, so I am really wondering in which case protection mechanism really enhance something!

I am still searching from existing studies in the literature, but I have not yet found something significant, maybe this has never really been studied? I am a bit surprised because this is already a quite old feature. 

Any help/tip is welcome :-)

(In reply to sebastien.deronne from comment #8)
> I have not yet handled code review comments, because I cannot reproduce
> scenarios where protection show any improvement...
> 
> Even though I slightly improved the implementation since latest patch set, I
> do not observe any bugs from traces, so I am really wondering in which case
> protection mechanism really enhance something!
> 
> I am still searching from existing studies in the literature, but I have not
> yet found something significant, maybe this has never really been studied? I
> am a bit surprised because this is already a quite old feature. 
> 
> Any help/tip is welcome :-)

All references I could find confirm the results: protection mechanism is needed to ensure a correct NAV setting for 802.11b in case of an ERP OFDM transmission, but at a cost of a throughput degradation.

I will shortly post a new patch set.

New patch set available

Another patch set available.
If no remaining comments, I will deliver those changes by February 18th.

(In reply to sebastien.deronne from comment #11)
> Another patch set available.
> If no remaining comments, I will deliver those changes by February 18th.

Deadpool's movie day !

changeset 11881:8707c44ecc30