Hi Matthew,
I'm Gwangho Lee, affiliated with KNUT.
I would like to follow up on the question I raised during the June 19th CC regarding the MAC header-based bandwidth (BW) condition for NPCA channel switching.
You mentioned that we should consider whether there could be a case in which the third PPDU's bandwidth is wider than that of the preceding ones. In my opinion, the bandwidths of the earlier PPDUs are not critical, since the NPCA switching decision is made after the reception of the PHY preamble of the third PPDU—at which point the BW can be directly determined.
To further examine the concern you raised, I carefully reviewed the RTS/CTS and MU-RTS/CTS exchange procedures defined in the IEEE 802.11-2024 baseline standard. It is clear that a CTS frame—or the following data frame—must not be transmitted with a bandwidth wider than the RTS or MU-RTS frame that preceded it. In other words, once an RTS or MU-RTS is transmitted, all subsequent frames (including CTS and data frames) are constrained to the same or narrower bandwidth.
Therefore, I believe that condition (e) of the MAC header-based condition can be simplified to check only the bandwidth of the third PPDU, which is sufficient to determine NPCA opportunities.
For your reference, I’ve included relevant baseline text from IEEE 802.11-2024 below.
[RTS/CTS exchange]
(IEEE 802.11-2024, 10.3.2.9, CTS and DMG CTS procedure)
A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT equal to Static behaves as follows:
- If the NAV indicates idle and CCA has been idle for all secondary channels (secondary 20 MHz channel, secondary 40 MHz channel, and secondary 80 MHz channel) in the channel width indicated by the RTS frame’s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT for a PIFS prior to the start of the RTS frame, then the STA shall respond with a CTS frame carried in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS frame’s TXVECTOR parameters CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall be set to the same value as the RTS frame’s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT.
- Otherwise, the STA shall not respond with a CTS frame.
A VHT STA that is addressed by an RTS frame in a non-HT or non-HT duplicate PPDU that has a bandwidth signaling TA and that has the RXVECTOR parameter DYN_BANDWIDTH_IN_NON_HT equal to Dynamic behaves as follows:
- If the NAV indicates idle, then the STA shall respond with a CTS frame in a non-HT or non-HT duplicate PPDU after a SIFS. The CTS frame’s TXVECTOR parameters CH_BANDWIDTH and CH_BANDWIDTH_IN_NON_HT shall be set to any channel width for which CCA on all secondary channels has been idle for a PIFS prior to the start of the RTS frame and that is less than or equal to the channel width indicated in the RTS frame’s RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT.
- Otherwise, the STA shall not respond with a CTS frame.
[MU-RTS/CTS exchange]
(IEEE 802.11-2024, 26.2.6.3, CTS frame sent in response to an MU-RTS Trigger frame)
The CTS frame sent in response to an MU-RTS Trigger frame shall be carried in a non-HT or non-HT duplicate PPDU (see Clause 17) with a 6 Mb/s rate and with the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE set to the same value as the RXVECTOR parameter SCRAMBLER_INITIAL_VALUE of the PPDU carrying the MU-RTS Trigger frame. The PPDU carrying the CTS frame shall be transmitted on the 20 MHz channels indicated in the RU Allocation subfield of the User Info field of the MU-RTS Trigger frame.
Please let me know your opinion on this.
Thank you.
Best regards,
Gwangho Lee
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1