Bugzilla – Bug 2275
AdhocWifiMac not compatible with 802.11n/ac
Last modified: 2016-03-01 14:41:58 UTC
Created attachment 2245 [details] initial suggested patch List of supported Mcs must be added upon first Enqueue(). Same type of fix will likely be needed for 802.11ac.
Tom, when using ConstantRate, 802.11n works ok with adhoc. I assume it is fixed needed when a HT rate adaptation algorithm is used. I tested with HT ideal and it indeed fixes the bug. I suggest to extend to VHT as well.
Hi. For which code version is the proposed patch?? I don't see a m_phy member in adhoc-wifi-mac.cc in current ns-3-dev I propose to create a function similar to AddAllSupportedModes in the wifi manager. If you agree I can upload a patch.
(In reply to Matías Richart from comment #2) > Hi. > > For which code version is the proposed patch?? > > I don't see a m_phy member in adhoc-wifi-mac.cc in current ns-3-dev The member is in RegularWifiMac. > I propose to create a function similar to AddAllSupportedModes in the wifi > manager. > If you agree I can upload a patch. Presently, there is an assumption in the Adhoc model that all stations can support all rates. I would like to extend the assumption of supported rates so that HT and VHT are supported, for rate control. However, you are suggesting to enhance the model so that only supported modes are added and sent in the beacon. I would be fine also with this but I just suggest two things: 1) please look at moving this method into RegularWifiMac to avoid duplicating it (if possible) in Adhoc (plus other beaconing wi-fis including mesh and wave), and 2) let's make that patch a second step beyond the original scope of this bug (which is feasible to fix for this coming release).
(In reply to Tom Henderson from comment #3) > (In reply to Matías Richart from comment #2) > > Hi. > > > > For which code version is the proposed patch?? > > > > I don't see a m_phy member in adhoc-wifi-mac.cc in current ns-3-dev > > The member is in RegularWifiMac. > > > I propose to create a function similar to AddAllSupportedModes in the wifi > > manager. > > If you agree I can upload a patch. > > > Presently, there is an assumption in the Adhoc model that all stations can > support all rates. I would like to extend the assumption of supported rates > so that HT and VHT are supported, for rate control. However, you are > suggesting to enhance the model so that only supported modes are added and > sent in the beacon. Not really. I was just suggesting to do the iteration in the manager just to follow the same design as AddAllSupportedModes. I would be fine also with this but I just suggest two > things: 1) please look at moving this method into RegularWifiMac to avoid > duplicating it (if possible) in Adhoc (plus other beaconing wi-fis including > mesh and wave), and 2) let's make that patch a second step beyond the > original scope of this bug (which is feasible to fix for this coming > release).
(In reply to Matías Richart from comment #4) > (In reply to Tom Henderson from comment #3) > > (In reply to Matías Richart from comment #2) > > > Hi. > > > > > > For which code version is the proposed patch?? > > > > > > I don't see a m_phy member in adhoc-wifi-mac.cc in current ns-3-dev > > > > The member is in RegularWifiMac. > > > > > I propose to create a function similar to AddAllSupportedModes in the wifi > > > manager. > > > If you agree I can upload a patch. > > > > > > Presently, there is an assumption in the Adhoc model that all stations can > > support all rates. I would like to extend the assumption of supported rates > > so that HT and VHT are supported, for rate control. Does this assumption also consider that the receiver station supports HT and/or VHT? If yes, we should also call AddStationHtCapabilities. But with which capabilities (sgi, chWidth, greenfield)? However, you are > > suggesting to enhance the model so that only supported modes are added and > > sent in the beacon. > Not really. I was just suggesting to do the iteration in the manager just to > follow the same design as AddAllSupportedModes. > > I would be fine also with this but I just suggest two > > things: 1) please look at moving this method into RegularWifiMac to avoid > > duplicating it (if possible) in Adhoc (plus other beaconing wi-fis including > > mesh and wave), and 2) let's make that patch a second step beyond the > > original scope of this bug (which is feasible to fix for this coming > > release).
Created attachment 2304 [details] patch to fix
It looks ok at first sight, I'll try to test it quickly tomorrow.
I suggest to add a trace log in WifiRemoteStationManager::AddAllSupportedMcs, otherwise patch is working fine.
Tom, feel free to deliver the patch once it's ok at your side.
pushed in changeset 11943:d7faa25126a9