Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thank you Yan,
To clarify, my main concern is not about separating primitives, but about the PHY continuing to hold the CCA state as Busy until the end of a PPDU reception. Since the PHY is a single entity, this Busy-hold applies regardless of whether the STA remains on the BSS PCH or switches to the NPCA PCH.
Therefore, even with separated primitives, the previously held Busy state must be explicitly reset in order to generate the correct CCA indication on the NPCA PCH. This is why I believe a mechanism such as PHY-CCARESET.request is necessary when the Primary channel changes during NPCA operation.
Best regards,
Gwangho
Hi Gwangho,
See my reponse inline
My suggestion is to specify the PHY-CCA.indication(Busy) primitive applies to a specific channel (i.e., BSS PCH or NPCA PCH) rather than using one primitive to indicate state of both BSS PCH and NPCA PCH
Best Regards!
Yan Li
OriginalFrom: 이광호 <gwangho.lee@xxxxxxxxxx>To: 李炎10200040;Date: 2025年09月17日 08:13Subject: Re: [STDS-802-11-TGBN] Requesting feedback on 11-25/0887r2 "CCA Issue in NPCA Operation"Hi Yan.Thank you for your reply.My response are inline belowBest regards,Gwangho2025년 9월 16일 (화) 오전 8:11, <li.yan16@xxxxxxxxxx>님이 작성:Hi Gwangho,
Thanks for initiating this topic.
As i mentioned during your presentation, we can just add a note to clarify that the PHY-CCA.indication(Busy) is related to current operating channel. For example:
When an OBSS PPDU is detected on BSS PCH, a PHY-CCA.indication(Busy) primitive generates and indicates the BSS PCH is busy. And then the STA switches to NPCA PCH via PHY-CONFIG.request primitive indicating NPCA PCH. Since the previous PHY-CCA.indication(Busy) primitive only indicates the BSS PCH is busy other than the NPCA PCH. Therefore, the STA could access the channel without any limitation.
Gwangho:When an OBSS PPDU is received and the PHY generates a PHY-CCA.indication(Busy) primitive, even if a PHY-CONFIG.request primitive is subsequently generated to change the Primary channel to the NPCA PCH, the previous CCA state may be maintained. As described in the Baseline text presented in Slide 4 of my contribution, the PHY shall maintain the CCA state as Busy until the end of the previously received PPDU.
Yan: The maintenance of CCA state of BSS PCH does not make any influence on the NPCA PCH. It may depend on implementation if CCA on BSS PCH needs to be reset. Basically CCA reset is for channel access.
But in this case, you have switched to NPCA PCH and will not do any channel access on BSS PCH.
17.3.12 Receive PHY
In the event that a change in the RSSI causes the status of the CCA to return to the IDLE state before the complete reception of the PSDU, as indicated by the PHY LENGTH field, the error condition shall be reported to the MAC using a PHY-RXEND.indication(CarrierLost) primitive and the PHY receiver shall return to the RX IDLE state. The CCA of the OFDM PHY shall indicate a busy medium for the intended duration of the transmitted PPDU.This requirement also applies to the HE PHY.
27.3.24 HE receive procedure
If signal loss occurs during reception prior to completion of the PSDU reception, the error condition PHY-RXEND.indication(CarrierLost) shall be reported to the MAC. After waiting for the end of the PPDU as determined by Equation (27-146), the PHY shall set the PHY-CCA.indication(IDLE) primitive and return to the RX IDLE state.As noted in your comment, even if the Primary channel is newly configured to NPCA PCH during PPDU reception, the PHY is a single entity, and therefore, due to the ongoing busy-hold procedure, the PHY may not be able to generate a PHY-CCA.indication(Idle) primitive for the NPCA PCH until the PPDU on the BSS PCH is complete.
To address this issue, the CCA state must ultimately be reset. This can be achieved by generating a PHY-CCARESET.request primitive. (Although another possible method is using the PHY-ABORT.request primitive, I could not find any behavior in the standard that explicitly describes the use of this primitive.)
In summary, I believe that when the Primary channel changes during NPCA operation, there is still a need to reset the CCA state, and this should be explicitly specified, for example, by generating a PHY-CCARESET.request primitive.
BTW, according to your contribution, it's a little bit confusing to send a PHY-CCARESET.request primitive during the OBSS PPDU, because BSS PCH is indeed busy and you do not indicate which PCH(BSS PCH or NPCA PCH) this primitive applies to
Gwangho:The CCA-RESET.request primitive instructs the PHY to reset the CCA state, and this operation is not limited to a specific channel. Once the PPDU being received on the BSS PCH is no longer relevant after switching to the NPCA PCH, it does not need to be maintained as Busy. Since an NPCA STA performing channel access on the NPCA PCH will still conduct CCA, the energy detection of the OBSS PPDU on the PCH will be sensed during that period. Therefore, even if the CCA state is reset after switching to the NPCA PCH, the OBSS PPDU remains protected as intended by the baseline.
Yan: i agree that our baseline has not specified CCA state applies to a certain channel. I think the reason is that we do not have more than one primary channel before NPCA. For NPCA, since we have 2 PCH(BSS PCH, NPCA PCH), we need more text to clarify the CCA state applies to a specific channel instead of using one CCA state to indicate channel state of both BSS PCH and NPCA PCH
In genral, when you operates on BSS PCH, PHY-CCA.indication(Busy) primitive only indicates the BSS PCH is busy. STA should maintain a CCA state for BSS PCH
when you operates on NPCA PCH, PHY-CCA.indication(Busy) primitive only indicates the NPCA PCH is busy. STA should maintain a CCA state for NPCA PCH
Such primitive does not cause any influence to the PCH on which the STA does not currently operate. The CCA state(busy) for BSS PCH does not affect the CCA state for NPCA PCH
Best Regards!
Yan Li
OriginalFrom: 이광호 <gwangho.lee@xxxxxxxxxx>Date: 2025年09月16日 14:21Subject: [STDS-802-11-TGBN] Requesting feedback on 11-25/0887r2 "CCA Issue in NPCA Operation"
Hi everyone.
I presented a contribution today (25/0887r2, "CCA Issue in NPCA Operation") during PM1.
I would like to request your feedback on this contribution.
If you have any feedback or questions, please feel free to reply to this thread
Best Regards,
Gwangho Lee (KNUT)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
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