|
Bugzilla – Full Text Bug Listing |
| Summary: | wifi: IdealWifiManager can pick invalid WifiTxVector under certain MIMO conditions | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
| Component: | wifi | Assignee: | Tom Henderson <tomh> |
| Status: | RESOLVED MOVED | ||
| Severity: | normal | CC: | matis18, ns-bugs, sebastien.deronne |
| Priority: | P3 | ||
| Version: | ns-3.25 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://www.nsnam.org/bugzilla/show_bug.cgi?id=2733 | ||
| Attachments: |
patch to fix
(revised) patch to fix |
||
|
Description
Tom Henderson
2016-04-22 16:59:11 UTC
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. |