Hi,
I’ve been examining the CCA-related behavior in ns-3's Wi-Fi PHY implementation and wanted to raise several concerns I believe are quite important.
For basic 20 MHz channel access, the IEEE 802.11 standard defines two fundamental thresholds:
Energy Detection (ED): –62 dBm
Sensitivity Threshold (also referred to as Packet Detection or PD): –82 dBm
According to the specification, the sensitivity threshold serves two specific purposes:
Receiver capability — devices must be able to receive PPDUs at or above this threshold using the lowest MCS.
Envelope detection for recovery — as described in section 19.3.21 of 802.11-2024, when a receiver PHY encounters errors (e.g., HT-SIG CRC failure), it falls back to energy detection based on the sensitivity threshold to determine the end of the PPDU.
In virtually all other contexts, ED governs channel access decisions.
The current usage of GetCcaThreshold() in ns-3 appears to conflate these two thresholds in meaningful scenarios. For instance, the following functions always call it with a non-null PPDU, which results in using the PD threshold — even when the ED threshold should be used:
EndReceivePayload(): If the PHY didn't encounter errors, ED should be used to assess medium state (even if all MPDUs weren't successfully decoded).
Described in the following Issue https://gitlab.com/nsnam/ns-3-dev/-/issues/1056
DropPreambleEvent(): While PHY errors may be involved, certain drop reasons (e.g., TXING or RXING) imply that the error doesn’t originate from the current device’s PHY. In such cases, the function is still called with a non-null PPDU, defaulting to PD. This doesn’t align with real-world device behavior — a PHY engaged in transmission or reception wouldn't be aware of another incoming preamble, let alone apply PD-based logic because of it.
This misclassification of threshold logic can introduce significant discrepancies between simulation and real-world behavior, particularly in dense or coexistence-focused scenarios. I hope this feedback is helpful. I’d be happy to clarify further.
Best regards,
Rony
Thanks very much for reporting this-- I've copied the below to issue #1247 (https://gitlab.com/nsnam/ns-3-dev/-/issues/1247) to track it further.
- Tom