wifi: SNR shift fix for TableBasedErrorRateModel

Miguel González-Lópezrequested to merge
mgonzalezlopezudc/ns-3-dev:patch-1 into master

I've been reviewing the nice work carried out by the FUNLAB from University of Washington on the Table-Based error model incorporated in ns-3. The associated papers are very nice to read and to learn from. Thanks to all of their authors!

However, I've realized that there might be an error on how the table data is used by ns-3 at runtime. In my opinion, a calibration mismatch exists within TableBasedErrorRateModel::DoGetChunkSuccessRate that systematically shifts lookup table queries across all operational Wi-Fi modes up to 802.11ax (Wi-Fi 6).

During runtime execution, InterferenceHelper::CalculateSnr computes an absolute broadband, time-domain SINR based on integrated signal power vs. noise power evaluated across the entire frequency block (e.g., all IFFT bins matching the active channel width). However, the hardcoded data matrices compiled inside table-based-error-rate-model.cc track a different SNR metric. They were generated using link-level simulation tools from the FUNLAB. Those link-level scripts (available at https://wp.ece.uw.edu/funlab/resources/, very nicely from the FUNLAB!) scale down the SNR to take into account the ratio of active subcarriers Vs total FFT subcarriers. For instance, in line 62 of file wh_runner_parallel.m from the Link-to-system-mapping-wns3-2020-code available at the FUNLAB:

AWGN.SNR = snr(i)-10*log10(Nfft/Nst_ht); % Account for energy in nulls

The same can be observed in the repo from one of the model authors, Rohan Patidar: at line 38 of https://bitbucket.org/rohanpatidar/wlan/src/master/linksim_awgn_11n.m:

AWGN.SNR = snr(i)-10*log10(Nfft/Nst_ht); % Account for energy in nulls subcarriers

I've rerun this last script and the values it produces match those included in ns-3.

Because ns-3 queries this table using raw broadband metrics directly without applying the inverse scaling factor, it mistakenly matches incoming frames to over-pessimistic, higher-error cells.

Impact Across 802.11 Generations

The magnitude of this indexing shift depends on the structural configuration of the modulation family and active channel width:

  1. Legacy OFDM (802.11a/g 20 MHz): 64 FFT bins / 52 active tones => +0.902 dB offset
  2. HT/VHT (802.11n/ac 20 MHz): 64 FFT bins / 56 active tones => +0.580 dB offset
  3. HT/VHT (802.11n/ac 40 MHz): 128 FFT bins / 114 active tones => +0.503 dB offset
  4. VHT (802.11ac 80 MHz): 256 FFT bins / 242 active tones => +0.244 dB offset
  5. HE (802.11ax 20 MHz): 256 FFT bins / 242 active tones => +0.244 dB offset
  6. HE (802.11ax 80 MHz): 1024 FFT bins / 996 active tones => +0.120 dB offset

Proposed Resolution

Rather than altering the static lookup data tables or contaminating macroscopic metric variables inside InterferenceHelper, the calibration should happen locally within the translation loop of TableBasedErrorRateModel::DoGetChunkSuccessRate.

This commit resolves the issue by evaluating mode.GetModulationClass() and txVector.GetChannelWidth() to dynamically identify the exact FFT-to-active-tone ratio for the current channel layout, shifting appropriately the roundedSnr value.

Best regards,

Miguel González-López, University of A Coruña (Spain)

Merge request reports