CWS keeps reseting, High packet loss for WiFi UDP CBR (30Mbps/UE)

[George]

Hello,

This is part of a question I asked on Zulip as well. 

I used UDP_CBR, to achieve something close to Virtual Reality (VR) 3GPP specs:

• Dgoog_2122634158ata rate: 30Mbps/UE = udpPacketSize = 62500 bytes * lambda = 60
• Some more context:
• WiFi standard: 11ax or 11ac with AP antenna 2col x 2row and STA 2col x 1 row,
• Mtu size: 1000,
• Channel settings: {44, 20, BAND_5GHZ, 0}, with InH_OfficeMixed model and propagation loss.
• AP NoiseFigure: 5, STA NoiseFigure: 9, AP TxPower: 20dBm, STA TxPower: 18dBm.

As deployment scenarios, I will refer to:
InFrontOf for AP0-->STA0 STA1<--AP1 (meant to show a worst-case interference)

SINR for this setup: ranges from 22 dB to 52 dB.

Q1: Looking at the InFrontOf scenario, creating a high interference scenario for testing I see that (*the apps do not start at the same time) :
WiFi gets for :

• AP0: 97% packet loss
• AP1: 36% packet loss

*max_CWS (contention window size) is 1023
Despite all this interference and packet loss when I print from Txop the Backoff generated and what UpdateFailedCw produces I get nearly all generated backoffs with (0, min_CWS).

I looked further to see why this is, and from FrameExchangeManager I see that link.cw it is all the time reset in function FrameExchangeManager::ReceivedNormalAck.

So basically having max_CWS either 1023 or 31 does not make any difference because somehow even in this worst scenario where we lose so many packets, ReceivedNormalAck keeps resetting the CWS to the minimum all the time.

Q2.1:How is this possible considering the high interference, and the packet loss I get? How can CWS not go above 31 while having such high interference? 

Thanks.

regards,
George

[George]

So the packet loss seems to be fixed by adjusting the Maximum Transmission Unit (MTU) for WiFi.  Previously I was using the MTU size that was working for NR (MTU = 1000). But it seems the same  NR-U and WiFi require a different MTU size (MTU = 4500) for the same traffic type. 

To answer the question regarding resetting CWS to min_CWS all the time based on ACKS or at least explain what I understand so far...

• WiFi by default uses a -62dBm ED Threshold( "CcaEdThreshold") to detect signals from devices that are not WiFi. 
• WiFi by default uses a -82dBm ED Threshold ( "CcaSensitivity") to detect signals from devices that are WiFi. 

For the InFrontOf scenario explained above: 

1. Testing for WiFi/WiFi I get a between 100% to 50% of packets received. The CWS  resets to the min_CWS most of the time based on ACKs. ( So in this WiFi / WiFi, the CcaSensitivity of -82 dBm was used ).
2. Testing for WiFi / NR-U  (NR-U ED Threshold = -72 dBm ,  and  WiFi uses CcaEdThreshold= -62 dBm ), WiFi gets around 20% of packets received. In this case, the CWS is constantly updating up to the max_CWS of 1023 based on NACKs. 
   

To test this I set CcaEdThreshold from -62dBm to -82dBm (what wifi uses for itself) and it increased packets received from 20% to 82% in WiFi/NRU. And the same as in WiFi/WiFi, when using -82dBm to detect NR-U signal, makes WiFi CWS to stay mostly at min_CWS.

So, the CWS resetting always to min_CWS was correct in the first place because with a high threshold such as -82dBm the channel is likely to be IDLE and result in no collisions, while a more relaxed threshold such as -62dBm can wrongly allow WiFi to transmit, constantly getting packets loss and increasing CWS to its max.