Bugzilla – Bug 2854
he-wifi-network crashes when frequency is set at 2.4 GHz
Last modified: 2018-01-31 14:19:29 UTC
./waf --run "he-wifi-network --simulationTime=0.25 --frequency=2.4 --useRts=0" MCS value Channel width GI Throughput 0 20 MHz 3200 ns 6.21773 Mbit/s 0 20 MHz 1600 ns 6.92429 Mbit/s 0 20 MHz 800 ns 7.39533 Mbit/s 0 40 MHz 3200 ns 12.5768 Mbit/s 0 40 MHz 1600 ns 14.2254 Mbit/s 0 40 MHz 800 ns 15.0733 Mbit/s 0 80 MHz 3200 ns 12.9065 Mbit/s Command ['/Users/Sebastien/ns-3/ns-3-allinone/ns-3-dev/build/examples/wireless/ns3-dev-he-wifi-network-debug', '--simulationTime=0.25', '--frequency=2.4', '--useRts=0'] exited with code 1 ./waf --run "he-wifi-network --simulationTime=0.25 --frequency=2.4 --useRts=1" MCS value Channel width GI Throughput 0 20 MHz 3200 ns 6.02931 Mbit/s 0 20 MHz 1600 ns 6.68877 Mbit/s 0 20 MHz 800 ns 7.1127 Mbit/s 0 40 MHz 3200 ns 12.247 Mbit/s 0 40 MHz 1600 ns 13.8486 Mbit/s 0 40 MHz 800 ns 14.6493 Mbit/s 0 80 MHz 3200 ns 12.5768 Mbit/s Command ['/Users/Sebastien/ns-3/ns-3-allinone/ns-3-dev/build/examples/wireless/ns3-dev-he-wifi-network-debug', '--simulationTime=0.25', '--frequency=2.4', '--useRts=1'] exited with code 1
It crashes because throughput at 80 MHz is too low and so it does not pass the check (no idea why the error message is not printed...).
Issue is caused by HtCapabilities which set the max supported channel width to 40. But my guess is that at 2.4 GHz the maximum allowed channel width is 40 MHz, so I suggest to change the example to only test 20 and 40 MHz channels at 2.4 GHz. Tom, can you maybe confirm that 802.11ax is 20-40 MHz at 2.4 GHz, and 20-40-80-160 at 5 GHz?
Created attachment 3003 [details] patch If fine, I will push this.
Created attachment 3004 [details] patch Updated regression
Pushed in changeset 13264:c2f702e4adff
Sébastien, sorry to ask this question only now but why should 40 MHz be forbidden for HE in the 5GHz band? If we compare 11ac behavior wrt 11n in the 5 GHz band, we can see that channel width is obtained from information contained in both HT Operation and VHT Operation (as detailed in section 11.40.1, and namely Table 11-24 "VHT BSS bandwidth", of 802.11-2016). The logic with Operation fields is also adopted by Capabilities fields (as implied in Table 9-249, which refers to section ) Don't you think that it would more logical that such a behavior would be adopted for 11ax?
Rediet, thanks, I think you are right, I closed this bug a bit too fast. At 2.4 GHz, it should make use of both HT and HE capabilities. I will work on this later today if I have some time.
But still according to those capabilities, 40 MHz is the maximum at 2.4GHz, is my understanding correct?
Created attachment 3014 [details] Allow 40 MHz at 5GHz I reworked what I did so that we can now configure 40 MHz channel width at 5GHz, it is now looking at both HE and VHT capabilities to correctly set the supported channel width for a given peer.
Created attachment 3015 [details] allow 40 MHz at 5GHz Updated regression test
(In reply to sebastien.deronne from comment #8) > But still according to those capabilities, 40 MHz is the maximum at 2.4GHz, > is my understanding correct? I'm not sure whether capabilities will be the limiting factor. It would rather be the regulatory per-region operating classes that would limit it to 40 MHz max. The operating class in the U.S. for the 2.4 GHz band forbids the use of channel 13, restricting the maximum band to 3 non-overlapping 20 MHz channels. However, in other regions, it would be theoretically possible to have a single 80 MHz channel covering the 2.4 GHz band (even if a practical use case can be hard to find, except when considering a deployment scenario in an isolated house somewhere in the Alps :-)). Does this logic seem correct to you?
(In reply to Rediet from comment #11) > (In reply to sebastien.deronne from comment #8) > > But still according to those capabilities, 40 MHz is the maximum at 2.4GHz, > > is my understanding correct? > > I'm not sure whether capabilities will be the limiting factor. It would > rather be the regulatory per-region operating classes that would limit it to > 40 MHz max. The operating class in the U.S. for the 2.4 GHz band forbids the > use of channel 13, restricting the maximum band to 3 non-overlapping 20 MHz > channels. However, in other regions, it would be theoretically possible to > have a single 80 MHz channel covering the 2.4 GHz band (even if a practical > use case can be hard to find, except when considering a deployment scenario > in an isolated house somewhere in the Alps :-)). > Does this logic seem correct to you? Yes, regulations should for sure always apply. In any case, I think we can now close this bug with the updated patch that allows again 40 MHz.
Modifications pushed in changeset 13269:aec4048edcac