Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 |