Bugzilla – Bug 2385
wifi: IdealWifiManager can pick invalid WifiTxVector under certain MIMO conditions
Last modified: 2020-04-18 09:29:34 EDT
Current IdealWifiManager code (as of release 3.25) supports MIMO and multiple spatial streams. The code considers the available MCSes that were initialized to the WifiPhy, and the capabilities of the remote station, to select the highest rate MCS supported by the SNR that has been reported for the association. This works when the configuration (number of transmit and receive antennas) is the same internally and between the two stations, but when there is an imbalance (such as a 1x2 configuration, 1 transmit and 2 receive antennas), the WifiTxVector picked may not be supported in the PHY. When that occurs, MacLow will try to send a packet, but the Phy will not actually send the packet, and the assert in mac-low is triggered: assert failed. cond="m_phy->IsStateTx ()", file=../src/wifi/model/mac-low.cc, line=823 The solution is more rigorous checking that the WifiTxVector picked by the rate control will actually be usable by the Phy.
Created attachment 2397 [details] patch to fix
Solution looks ok for me
+1
Created attachment 2402 [details] (revised) patch to fix This patch is improved as follows: - the trace source was not appropriate for the AP use case since all rate updates (all stations) were rolled into one traced value; this patch aligns with the MinstrelHtWifiManager trace source (adds a second parameter-- the Mac address) and renames it from 'Rate' to 'RateChange') Note: this trace source deprecation should be considered along with the other bug concerning deprecation of trace sources and attributes (bug 2149) - the previous patch was still not correctly finding the highest possible rate - some refactoring was done since the code was getting unwieldy and hard to read
Still some possible enhancements: - the rate control caches the last used configuration if the reported SNR is stable. It may be possible to change the configuration at runtime (e.g. change number of transmit antennas or other transmit properties), but it may be the case that the code will not re-check for a better mode. Possible remedies are: disable caching (such as with an attribute if run-time configuration changes are expected), or enable some more checks before using the cached value, adding a method to "ReInitialize()", etc. - automate the testing with a test suite (currently, using external shell script to run the example with a number of configurations and inspecting the resulting plots) - RTS/CTS mode selection may still be questionable (e.g. doesn't use HT/VHT modes for such frames)
Any updates on this?
(In reply to sebastien.deronne from comment #6) > Any updates on this? I suggest to merge the existing patch and leave open for two additional items that I will complete at a future date: 1) automate the testing with a test suite (currently, using external shell script to run the example with a number of configurations and inspecting the resulting plots) 2) ensure that management and control are handled as follows (any comments on this proposal would be appreciated): - control (RTS/CTS/ACK) are sent at the highest available (i.e. SNR is high enough) rate of the basic rates (6/12/24 OFDM, or 1/2/5.5/11 for DSSS). - management (beacon, probe, assoc req) are sent at the lowest basic rate (6 Mbps for OFDM, 1 Mbps for DSSS) - broadcast and multicast sent at the highest available basic rate considering the SNR to all known STAs in the network
(In reply to Tom Henderson from comment #7) > (In reply to sebastien.deronne from comment #6) > > Any updates on this? > > I suggest to merge the existing patch and leave open for two additional > items that I will complete at a future date: > > 1) automate the testing with a test suite (currently, using external shell > script to run the example with a number of configurations and inspecting the > resulting plots) OK. > > 2) ensure that management and control are handled as follows (any comments > on this proposal would be appreciated): > > - control (RTS/CTS/ACK) are sent at the highest available (i.e. SNR is high > enough) rate of the basic rates (6/12/24 OFDM, or 1/2/5.5/11 for DSSS). > > - management (beacon, probe, assoc req) are sent at the lowest basic rate (6 > Mbps for OFDM, 1 Mbps for DSSS) > > - broadcast and multicast sent at the highest available basic rate > considering the SNR to all known STAs in the network I am fine with that proposal.
Moved to https://gitlab.com/nsnam/ns-3-dev/-/issues/178