Bugzilla – Bug 2120
802.11g networks are not compatible with 802.11b clients
Last modified: 2016-02-17 16:42:06 UTC
It has been observed that a 802.11b client is not supported by a 802.11g network. The issue seems to come from the association process.
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