Bugzilla – Bug 1797
Rate adaptation algorithms don't work with new 802.11n/ac standards
Last modified: 2016-06-10 16:13:26 EDT
When the new 802.11n standards (since ns-3.18) are used together with ConstantRateManager, no problem appears. However, when we use a rate adaptation algorithm, it can only change rate between old legacy rates, and will never achieve HT rates. Consequently, throughput is low. Indeed, new HT rates don’t use the previous WifiMode type but use Mcs (uint8_t). As a result, since rate adaptation algorithm are only looking at supported rates and not at supported MCS, the station will never pick a HT rate for Data transmission! -> A first solution would be to use the previous implementation (before ns-3.18) and consider new HT rates as classical rates and not as mcs. According to me, this would be the fastest solution. -> Another solution would be to change the code to enable rate adaptation algorithm to pick non HT rates as well as HT rates via mcs index number. This is the best solution if we want to keep the separation between old rates and new ht rates, but it maybe needs more modifications. Any suggestions about the solution which should be preferred? So then I could work on providing a patch which considers the preferred solution.
Hi, Let me think about that too. My first thought was that the second options sounds better. But let's see others' feedback. I'm also working on the Minstrel manager. Apparently, most people use ConstantRateWifiManager so bugs in the WifiManager are not discovered much.
Thanks for your answer. I have the same feeling, I'm now waiting for more suggestions.
Patch is coming soon, I just had to make minor modifications in WifiRemoteStationManager (just one new function) and adapt the code (just few lines) in all adaptation rate algorithm classes. Now, data rates are well adapted according to succeeded/failed transmissions. However, the control frames (ACK) are always sent at the lowest MCS index. But this point is not really clear for me: - I experimentally noticed that control frame use non-HT rates. - However, I guess that it should be allowed to send control frames using HT rates, up to MCS 7. So, in any case, I think code should be changed! Either we consider that control frames should use non-HT rates (what I get experimentally, but it maybe depends on manufacturers) or we should consider to send control frames using HT rates, up to MCS 7 (and not MCS 0 only). Any help on this point? Thanks.
Hello, I am trying to simulate 802.11n using MinstrelWifiManager. Are there any patches available to use the ht rates? Thanks Dina
Hi, I was wondering if you had a patch to modify the rate adaptation to handle 802.11n ht rates? I would really appreciate your help. (In reply to Sébastien Deronne from comment #3) > Patch is coming soon, I just had to make minor modifications in > WifiRemoteStationManager (just one new function) and adapt the code (just > few lines) in all adaptation rate algorithm classes. > > Now, data rates are well adapted according to succeeded/failed > transmissions. However, the control frames (ACK) are always sent at the > lowest MCS index. But this point is not really clear for me: > > - I experimentally noticed that control frame use non-HT rates. > > - However, I guess that it should be allowed to send control frames using > HT rates, up to MCS 7. > > So, in any case, I think code should be changed! > Either we consider that control frames should use non-HT rates (what I get > experimentally, but it maybe depends on manufacturers) or we should consider > to send control frames using HT rates, up to MCS 7 (and not MCS 0 only). > > Any help on this point? Thanks.
Sorry, I had to postpone patch delivery since I was very busy on MPDU aggregation feature. I will have a look back at it this weekend, but the patch will be available soon. But my worries are still there regarding the rate at which control frames (ACK, ...) should be transmitted: - Should it be MCS0? Then what about legacy devices? - Should it be a higher MCS? If so, how is it selected? Same problem with legacy. - Should it be a legacy rate? If so, how is it selected? Is it similar to what is currently done for legacy stations? If someone (Ghada? Daniel?) could bring his view on that, I could deliver the patch afterwards. On my side, I will check in the standard if something is clearly stated about that.
I've Just got a reply from Ghada. She is working on HT version on Minstrel that should be pushed in ns-3-dev later on. According to her, the rate controls in ns3 reference papers. If someone changes them to include 11n MCSs (the standard treat MCS different than rates!), then the reference is not correct anymore. It is thus proposed that a cleaner way is to implement HT rate control algorithms to deal with 11n. Note that 11n is more than just rates there is using spatial multiplexing, beam-forming, switching from 40MHz to 20MHz and vice versa, ...
Minstrel HT has been posted for review at https://www.codereview.appspot.com/254900043/
Updates to IdealWifiManager found here: http://codereview.appspot.com/283580043 Updates to MinstrelHt (based on Ghada's original patch) have been done by Matias and are posted here: https://codereview.appspot.com/283960043/
Now that MinstrelHt and Ideal does support HT/VHT, we should trigger an assert or a fatal error if a non support RAA is used with HT/VHT. This bug could be close then.
Created attachment 2441 [details] Assert when non-HT RAA is used with HT device I attach a patch to generate an assert when non-HT RAA is used with HT devices. Please let me know what do you think. Tests I did: >>HT device and HT manager: ./waf --run "minstrel-ht-wifi-manager-example --standard=802.11n-2.4GHz" PASS >>non-HT device and HT manager: ./waf --run "minstrel-ht-wifi-manager-example --standard=802.11a" PASS >>HT device and non-HT manager: ./waf --run "rate-adaptation-distance --apManager=ns3::MinstrelWifiManager --standard=802.11n-5HGz" ASSERT >>non-HT device and non-HT manager: ./waf --run "rate-adaptation-distance --apManager=ns3::MinstrelWifiManager --standard=802.11a" PASS
Matias, Thanks for taking care of this. I suggest to find another name for Is(V)HtSupported, it might be confusing since we already have similar name for other functions used to return whether the station does support (V)HT or not. Maybe something like "DoesRateAdaptationAlgorithmSupportHt". Or I even propose to have a single function since HT and VHT are either both supported or both unsupported, so I would go for something like "IsLegacyRateAdaptationAlgorithm".
Matias, could you provide your feedback? If you agree with my comments, feel free to provide a patch.
(In reply to sebastien.deronne from comment #13) > Matias, could you provide your feedback? > If you agree with my comments, feel free to provide a patch. I agree, I'll go for the "IsLegacyRateAdaptationAlgorithm" idea. I'll have the changes done for tomorrow.
(In reply to Matías Richart from comment #11) > Created attachment 2441 [details] > Assert when non-HT RAA is used with HT device > > I attach a patch to generate an assert when non-HT RAA is used with HT > devices. > Please let me know what do you think. Comments: - although you state above and below that it generates an assert, it actually generates a fatal error (which is better than assert here IMO since it will trigger in non-debug modes). I suggest not to change what you have; I am just clarifying the comment. - why can't you just make Set(V)HtSupported() a virtual function and make it FATAL_ERROR in the non-compatible variants? I don't see the need to introduce another method, but maybe I miss some detail. - I would like to see as part of the patch some class doxygen for each rate control that states whether it supports legacy or not. A simple statement such as "This RAA does not support HT or VHT modes and will error exit if the user tries to configure this RAA with a Wi-Fi MAC that has VhtSupported or HtSupported set." could be added to each one. - are there any reasons not to run a HT algorithm with a non-HT standard? e.g. MinstrelHt on 802.11b. Please comment on this in the class doxygen of the HT-aware rate controls-- what happens if user configures this HT-RAA on a non-HT Wi-Fi MAC? If it is not compatible, some additional checking is needed. > > Tests I did: > >>HT device and HT manager: ./waf --run "minstrel-ht-wifi-manager-example --standard=802.11n-2.4GHz" > PASS > > >>non-HT device and HT manager: ./waf --run "minstrel-ht-wifi-manager-example --standard=802.11a" > PASS > > >>HT device and non-HT manager: ./waf --run "rate-adaptation-distance --apManager=ns3::MinstrelWifiManager --standard=802.11n-5HGz" > ASSERT > > >>non-HT device and non-HT manager: ./waf --run "rate-adaptation-distance --apManager=ns3::MinstrelWifiManager --standard=802.11a" > PASS
(In reply to Tom Henderson from comment #15) > > Comments: > > - although you state above and below that it generates an assert, it > actually generates a fatal error (which is better than assert here IMO since > it will trigger in non-debug modes). I suggest not to change what you have; > I am just clarifying the comment. You are right. Thanks for the correction. > > - why can't you just make Set(V)HtSupported() a virtual function and make it > FATAL_ERROR in the non-compatible variants? I don't see the need to > introduce another method, but maybe I miss some detail. I think I can. It was just a decision I made. I'll try your idea. > > - I would like to see as part of the patch some class doxygen for each rate > control that states whether it supports legacy or not. A simple statement > such as "This RAA does not support HT or VHT modes and will error exit if > the user tries to configure this RAA with a Wi-Fi MAC that has VhtSupported > or HtSupported set." could be added to each one. Ok. > > - are there any reasons not to run a HT algorithm with a non-HT standard? > e.g. MinstrelHt on 802.11b. Please comment on this in the class doxygen of > the HT-aware rate controls-- what happens if user configures this HT-RAA on > a non-HT Wi-Fi MAC? If it is not compatible, some additional checking is > needed. Currently, all HT capable RAAs in ns3 (ConstantRate, Ideal and MinstrelHT) are non-HT compatible. In the case of MinstrelHT, when used with non-HT standard it works as legacy Minstrel. > > > > > Tests I did: > > >>HT device and HT manager: ./waf --run "minstrel-ht-wifi-manager-example --standard=802.11n-2.4GHz" > > PASS > > > > >>non-HT device and HT manager: ./waf --run "minstrel-ht-wifi-manager-example --standard=802.11a" > > PASS > > > > >>HT device and non-HT manager: ./waf --run "rate-adaptation-distance --apManager=ns3::MinstrelWifiManager --standard=802.11n-5HGz" > > ASSERT > > > > >>non-HT device and non-HT manager: ./waf --run "rate-adaptation-distance --apManager=ns3::MinstrelWifiManager --standard=802.11a" > > PASS
Created attachment 2464 [details] Assert when non-HT RAA is used with HT device v2 I upload a new patch considering Tom comments. Instead of adding a new method I use Set(V)HtSupported methods or the check.
Thanks, it looks fine.
(In reply to sebastien.deronne from comment #18) > Thanks, it looks fine. Agreed, thanks for this patch.
pushed in changeset 12153:090887671b94