Issues in 802.11 CCA

56 views
Skip to first unread message

Rony Ross

unread,
Jul 3, 2025, 9:57:05 AM7/3/25
to ns-3-users

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:

  1. Energy Detection (ED): –62 dBm

  2. Sensitivity Threshold (also referred to as Packet Detection or PD): –82 dBm

According to the specification, the sensitivity threshold serves two specific purposes:

  1. Receiver capability — devices must be able to receive PPDUs at or above this threshold using the lowest MCS.

  2. 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).

  • 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

Tom Henderson

unread,
Jul 10, 2025, 9:20:10 PM7/10/25
to ns-3-...@googlegroups.com, Rony Ross

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

Reply all
Reply to author
Forward
0 new messages