Wi-Fi hidden terminal performance issues
Someone reported on ns-3-users list that RTS/CTS protection did not seem to work for HT rates and above. I had a look using the program examples/wireless/wifi-simple-ht-hidden-stations.cc to test (using ns-3-dev tip at changeset dcd0ed94).
I was able to confirm that something is not working correctly with the MAC and traced it to likely being related to the BlockAckManager and QosFrameExchangeManager. After some initial time in the simulation, one of the MACs will stop attempting to access the channel. I confirmed that 11n, 11ac, and 11ax all suffer from this issue with this program. There is a separate program wifi-hidden-terminal.cc for 11b that seems to be working as expected, although I didn't look deeply at this.
The topology is a simple two STA, 1 AP topology separated by distance of 5 m (n1<->n2 and n2<->n3) constructed with the RangePropagationLossModel to enforce a 5m transmission range.
// AP
// * * *
// | | |
// n1 n2 n3Both STAs have a saturating UDP traffic generator sending in excess of 100 Mbps. The rate control is set to constant at the highest single stream MCS (e.g. HtMcs7, VhtMcs7, etc.).
The problem is masked somewhat by the printing out of aggregate throughput only, which hides that one of the STAs is starved.
To reproduce, these commands (on ns-3-dev) yield these results:
$ ./ns3 run 'wifi-simple-ht-hidden-stations --enableRts=0 --simulationTime=10 --nMpdus=16'
Throughput: 58.2052 Mbit/s
$ ./ns3 run 'wifi-simple-ht-hidden-stations --enableRts=1 --simulationTime=10 --nMpdus=16'
Throughput: 55.6557 Mbit/sAlthough using RTS costs some channel time and hence some throughput, the expected result is that uncoordinated channel access when enableRts=0 should produce lower throughput due to resolving collisions when there is a hidden terminal.
I modified the program to separately report the throughput from each station, and the results are shown below (and this program is attached).
./ns3 run 'wifi-simple-ht-hidden-stations --enableRts=0 --simulationTime=10 --nMpdus=16'
Throughput: 58.2052 Mbit/s
Throughput1: 0 Mbit/s
Throughput2: 58.2052 Mbit/s
$ ./ns3 run 'wifi-simple-ht-hidden-stations --enableRts=1 --simulationTime=10 --nMpdus=16'
Throughput: 55.6557 Mbit/s
Throughput1: 8.02417 Mbit/s
Throughput2: 47.6316 Mbit/sI enabled logs of QosFrameExchangeManager, BlockAckManager, and HtFrameExchangeManager. The logs show that at some point shortly into the simulation, the block ack manager says that there is no frame to send; e.g.:
+1.702252617s 1 [mac=00:00:00:00:00:02] HtFrameExchangeManager:StartFrameExchange(0x556405f592c0, 0x556405f57dd0, -9.22337e+18ns, 1)
+1.702252617s 1 [mac=00:00:00:00:00:02] HtFrameExchangeManager:SendMpduFromBaManager(0x556405f592c0, 0x556405f57dd0, -9.22337e+18ns, 1)
+1.702252617s 1 [mac=00:00:00:00:00:02] HtFrameExchangeManager:SendMpduFromBaManager(): [DEBUG] Block Ack Manager returned no frame to sendHowever, I confirmed that there are no higher-level failures (e.g. ARP)-- the WifiNetDevice is receiving packets to send throughout the simulation. Furthermore, I confirmed that there is no loss of association between STAs and AP.
Finally, I tested operation when the propagation range is extended to 11m (i.e., to remove the hidden terminal) and observed that throughputs were roughly split in both cases.
If we continue to use this program for regression testing (for now), I would recommend that we do not just check aggregate throughput but check that each STA obtains some proportional throughput.