Throughput wi-fi 6 vs wi-fi 7

[G-Anthony]

Hi everyone,

I am currently running simulations in ns-3.47 to compare rate adaptation algorithms across Wi-Fi 6 and Wi-Fi 7, and I would like to get the community's insight on a throughput gap I am observing.

**Setup**
The simulation configuration is identical across both standards, with the only varying parameter being the Wi-Fi standard (802.11ax vs. 802.11be). RTS/CTS is disabled in all scenarios.

**Algorithms compared:** Thompson Sampling, Ideal, and Minstrel HT

**Average throughput results (Mbps):**

| Algorithm                      | Wi-Fi 6 | Wi-Fi 7 |
|-------------------------------------|------------|-------------|
| Thompson Sampling   | 48.87   | 50.73   |
| Ideal                                | 46.21   | 40.02   |
| Minstrel HT                    | 33.73   | 29.11   |

I have attached the throughput curves for reference.

**Observation**
While Thompson Sampling shows a modest and expected improvement when moving from Wi-Fi 6 to Wi-Fi 7 (+1.86 Mbps), both Ideal and Minstrel HT exhibit a noticeable throughput *decrease* in Wi-Fi 7 compared to Wi-Fi 6 (−6.19 Mbps and −4.62 Mbps respectively). This gap is somewhat surprising, especially for the Ideal algorithm, which is typically used as an upper-bound reference.

**Question**
Is this throughput gap between Wi-Fi 6 and Wi-Fi 7 — particularly the degradation observed with Ideal and Minstrel HT — expected or explainable by known ns-3 implementation differences between the two standards? Could the absence of RTS/CTS play a role here, or is this more likely related to how MCS tables and channel width are handled differently in the 802.11be model?

Any insight or pointer to relevant ns-3 documentation would be greatly appreciated.

Thank you!

[Tommaso Pecorella]

Disclaimer: take my comments with a grain of salt, as I know nothing about the difference between ax and be.

Thomson / minstrel / ideal are power / rate control algorithms, and their effect should be (mostly) seen when the channel conditions vary, i.e., when the nodes are moving.

If the nodes are stationary, the effect of these algorithms will take into account the interference of the other nodes, i.e., the collisions.

However, these algorithms are not ment to fight interference, and they even might have a counterintuitive effect: you feel that the channel is bad -> you decrease the speed -> the packets takes longer to transmit -> you increase the congestion and the collisions -> you made things worse.

Shortly put: if your scenario is stationary and you increase the node density, you better have RTS/CTS on.

My best guess...

[G-Anthony]

My hypothesis is that the TableBasedErrorRateModel in ns-3 is not fully populated for EHT MCS 12 and MCS 13 (4096-QAM), or that the corresponding error tables are overly conservative for 802.11be. This would cause IdealWifiManager — which relies on SNR-to-BER table lookups to select the highest feasible MCS — to systematically fall back to lower MCS indices in Wi-Fi 7, resulting in the observed throughput degradation. Thompson Sampling, by contrast, relies on empirical probing rather than table lookups, and would therefore not be affected by this limitation — which could explain why it not only avoids the regression but actually significantly outperforms Ideal in the Wi-Fi 7 scenario.

Any confirmation, correction, or pointer to relevant ns-3 documentation would be greatly appreciated.

Thank you!