Bug 761

gary, would you care to review and comment ?

(In reply to comment #1)
> gary, would you care to review and comment ?

Hi,

Sorry for late reply. Just got back from winter vacation.

For 802.11b, it should be 304 rather than 192.

192 only covers aPreambleLength+aPLCPHeaderLngth

You need add 8*ACKSize = 8*14 = 112 microseconds for ACKTxTime

Thus, the total is 112+192 = 304 microsecond. Please see figure 9-11 for details. Also, please see equation on page 270 on 802.11-2007 and Figure 9-12. It seems to me that both ACK/CTS timeout should be:

MicroSeconds(10+304+20+GetDefaultMaxPropagationDelay().GetMicroSeconds ()*2)

proposed patch then ?

Both Kirill and Gary are right. The fact is that the standard says that the timeout duration is how much time you are allowed to wait for a RX-START indication. The mac-low code (to my understanding) does not any knowledge of RX-START, it only has knowledge of RX-END. So what mac-low does is to add the ACK duration to the timeout, in order to be able to rely only on the RX-END event. In other words, the mac-low implementation does not comply with the standard in this respect.

So the patch by Kirill will not work, because it sets the timeout values as per the standard, but does not change the mac-low code accordingly.

A proper patch would require significant effort and probably be invasive, so it needs to be designed and tested with care. I would be fine with it in principle, though. Any volounteers?

I get the impression that everybody is fine with the current behavior, so I am marking this as an enhancement.

I want to re-open this bug, since I am not convinced yet we are doing it right.

In the standard, ACK and CTS timeout as defined as aSIFSTime + aSlotTime + aPHY-RX-START-Delay. In wifi-mac, we have aSIFSTime + sSlotTime + ACK duration + GetDefaultMaxPropagationDelay x 2.

I understand the need to add ACK duration compared to the standard, as we are not fully compliant: the standard defined a duration to wait for a RX-START (not implemented in ns-3), whereas we compute a duration to wait for a RX-END in ns-3. This should be changed later maybe, but it is not a big issue so far.

The problem is that GetDefaultMaxPropagationDelay x 2 is NOT equal to aPHY-RX-START-Delay.

Furthermore, IMO aPHY-RX-START-Delay depends on the standard version, while GetDefaultMaxPropagationDelay is set to 33 microseconds for all standard versions.
Finally, I am not sure we are still compliant with IEEE 802.11n.

Does anyone know where comes the value returned by GetDefaultMaxPropagationDelay?
And why does GetDefaultMaxPropagationDelay x 2 replace aPHY-RX-START-Delay in the current implementation?

As I remember, propagation delay corresponds to aAirPropagation time of the standard. A proper value is set in accordance with coverage class table (I can see table 7-27 of 802.11-2007 standard). Any switching timeouts are ignored in ns-3 implementation and this fact caused a lot of discussion.

(In reply to Kirill Andreev from comment #7)
> As I remember, propagation delay corresponds to aAirPropagation time of the
> standard. 

Kirill is right. As a further clarification, the reason why aAirPropagation is included in the timeout definition is because it is one of the components of aSlotTime, see 9.3.7 "DCF timing relations" in the standard.

*** Bug 2223 has been marked as a duplicate of this bug. ***

This topic is now 7 years old, and I think nothing will come more from it. I suggest to close it.

I decide to close this bug, it is a very old topic and nothing seems wrong.