| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Rojan, Yunbo and Insun, Thank you all for the comments. Per Rojan’s comment: “What about NAV on the non-primary blocks for AP? I think you replied that NAV is only maintained on the primary 20, but I think that is
risky. I think NAV should be extended to non-primary blocks too, else it is not fair to OBSS or legacy STAs that have P20 on those channels, since their channel access may be blocked due to NAV.” I think NAV extension to non-primary segments will cause high complexity and require high capability for the AP to be capable of doing multiple preamble detection.
For the fariness issue to OBSS or legacy STAs which have P20 on those channels, I think PBT does not make it worse. Currently if primary 20 is idle, only do PIFS check on the non-primary channels which might be OBSS’s P20. With PBT, a backoff is still performed.
We can also think more to improve it if necessary. Per Yunbo and Insun’s comments, the AP is not totally “deaf” on the primary 20 because the AP can set NAV or obtain PPDU length based on the received signal
(TBD for other system signal) on the primary 20. The PBT backoff is after determining that the primary 20 is busy assuming AP is capable of one preamble detection at a time. The PBT transmission can be restricted within a period of time (TXOP or PPDU length
or other parameters). During the PBT, the AP is unavailable on the primary channel. When it is back to primary 20, it can do NAVSyn wait or some other channel access strategies. I am open to further discussion for this point. Hope my responses are clear to you. Thanks, Kaiying From:
장인선 [mailto:insun.jang@xxxxxxx]
Hi Kaiying Thanks for reminding us of that and discussing it I just had almost similar question as Yunbo (regarding deaf issue) Regarding that, you assume the following? (I may miss your point) - Performing PBT back-off only when any OBSS PPDU is detected in PCH
- Performing PBT back-off after detecting its TXOP and aligning theirs TXOPs (ends) Thanks Best Regards Insun From: Liyunbo [mailto:liyunbo@xxxxxxxxxx]
Hi Kaiying, It is a good way to put the Q list in the email to remind people. Thanks for initiating the discussion. I have a clarification question: when AP transmit on secondary channel according PBT, during the transmission period, it will be
deaf to receive packet at primary channel (similar as non-STR MLD scenario). After the AP finish the transmission, does it need to wait NAVSyncDelay on primary channel before backoff on primary channel? Regards, Yunbo 发件人:
Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
Hi Kaiying, I had the same question as Minyoung: What about NAV on the non-primary blocks for AP? I think you replied that NAV is only maintained on the primary
20, but I think that is risky. I think NAV should be extended to non-primary blocks too, else it is not fair to OBSS or legacy STAs that have P20 on those channels, since their channel access may be blocked due to NAV. Regards, Rojan From: Kaiying Lu <Kaiying.Lu@xxxxxxxxxxxx>
Hi
all, Due to the time limitation I did not have chance to hear all your comments and questions
during my presentation 20/429r0 Basically, in a wide operating bandwidth (eg.320MHz,240MHz,160MHz) BSS, enabling devices
of lower BW capability (eg. 80MHz) to park on different 80MHz segments make the wide band resource allocation more flexible and efficient. When the primary 20MHz channel is blocked, instead of just waiting in the primary 20/80, allowing some opportunistic
transmissions on other free 80MHz segments would be beneficial for the STAs parking on the non-primary 80 segments and enhance the system throughput. I would like to collect more comments from the group for further offline discussion. I
saw the Q list below. It would be very helpful if I can know your concerns. from [V] Ming Gan (Huawei) to everyone: Q from [V] Pooya Monajemi (Cisco) to everyone: Q from [V] Chunyu Hu (FB) to everyone: Q from [V] Yunbo Li (Huawei Technologies) to everyone: Q from [V] Sharan Naribole (Samsung) to everyone: Q from [V] George Cherian (Qualcomm) to everyone: Q from [V] Rojan Chitrakar (Panasonic) to everyone: Q from [V] dibakar das (Intel) to everyone: Q from [V] Yonggang Fang (ZTE TX) to everyone: Q from [V] Insun Jang (LGE) to everyone: Q (if possible) Thanks, Kaiying *********** MEDIATEK Confidentiality Notice ***********
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or
otherwise exempt from disclosure under applicable laws. It is
intended to be conveyed only to the designated recipient(s). Any
use, dissemination, distribution, printing, retaining or copying
of this e-mail (including its attachments) by unintended recipient(s)
is strictly prohibited and may be unlawful. If you are not an
intended recipient of this e-mail, or believe that you have received
this e-mail in error, please notify the sender immediately
(by replying to this e-mail), delete any and all copies of this
e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 *********** MEDIATEK Confidentiality Notice *********** The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you! To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |