| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Yunbo and Dibakar,
Thanks for your further comments.
As for the concern of fairness, we are looking beyond the Wi-Fi network.
Since there will have non-WiFi devices on the unlicensed 6GHz band which have more aggressive channel access rules, by following the same channel access rule as non-WiFi devices, WiFi simply levels the playing field.
PBT provides WiFI device the same opportunities to access the idle channels as non-WiFi devices.
The OBSS hidden node issue can be addressed by new mitigation rules and we are open to have further discussions.
OBSS hidden node issue exits even today and it does not prevent us from continue to develop new technologies.
It is a good discussion and hope we can have some consensus first on general idea as mentioned in my straw poll
• Do you agree that partial bandwidth transmission opportunities should be considered when the primary channel is blocked?
Looking forward to further discussions!
Thanks,
Kaiying
From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Sent: Monday, May 25, 2020 10:02 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Fwd: FW: [STDS-802-11-TGBE] 429r0
Hi Kaying,
I have a similar question as Yunbo.
If you are blind on secondary channel, you should do a NAVsyncdelay before transmitting during the PBT. I am not sure how much gain you can actually get that way since the NAVsyndelay will cut into the duration for which you are present on that link.
When you come back to the primary channel, there is still a risk in not having the most recent NAV information and ideally the AP should do another NAVsyncdelay. This also brings concern on performance due to the additional delay.
Regards,
Dibakar
From: Liyunbo <liyunbo@xxxxxxxxxx>
Sent: Monday, May 25, 2020 12:34 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Fwd: FW: [STDS-802-11-TGBE] 429r0
Hi Kaiying,
Thanks for your quick response. Below is my further comments for the mentioned two issues:
1) For OBSS fairness issue on secondary, it is not suggest to setup a primary channel on the secondary channel of other OBSS, so it is kind of corner cases according to the standard. But after we introduce PBT, it will be a natural behavior to transmit on secondary channel only. When two EHT BSS setup on the same channel with same bandwidth and same primary 20MHz, the two BSS will have hidden problem on secondary channel, because they don’t maintain NAV on secondary channel. So I think it is a new scenario, we need to evaluate it.
2) You mentioned “The PBT transmission can be restricted within a period of time (TXOP or PPDU length or other parameters)”, I don’t see a problem for PPDU length based, but for TXOP based, AP may miss the NAV update in primary 20MHz during transmission on secondary channel. We need to think whether NAVSyncDelay need to applied.
Regards,
Yunbo
发件人: Kaiying Lu [mailto:Kaiying.Lu@xxxxxxxxxxxx]
发送时间: 2020年5月25日 12:15
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Fwd: FW: [STDS-802-11-TGBE] 429r0
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]
Sent: Sunday, May 24, 2020 6:17 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Fwd: FW: [STDS-802-11-TGBE] 429r0
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]
Sent: Friday, May 22, 2020 7:13 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Fwd: FW: [STDS-802-11-TGBE] 429r0
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]
发送时间: 2020年5月22日 14:36
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Fwd: FW: [STDS-802-11-TGBE] 429r0
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>
Sent: Friday, May 22, 2020 12:49 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Fwd: FW: [STDS-802-11-TGBE] 429r0
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 anyattachments) may be confidential, proprietary, privileged, orotherwise exempt from disclosure under applicable laws. It isintended to be conveyed only to the designated recipient(s). Anyuse, dissemination, distribution, printing, retaining or copyingof this e-mail (including its attachments) by unintended recipient(s)is strictly prohibited and may be unlawful. If you are not anintended recipient of this e-mail, or believe that you have receivedthis e-mail in error, please notify the sender immediately(by replying to this e-mail), delete any and all copies of thise-mail (including any attachments) from your system, and do notdisclose 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 anyattachments) may be confidential, proprietary, privileged, orotherwise exempt from disclosure under applicable laws. It isintended to be conveyed only to the designated recipient(s). Anyuse, dissemination, distribution, printing, retaining or copyingof this e-mail (including its attachments) by unintended recipient(s)is strictly prohibited and may be unlawful. If you are not anintended recipient of this e-mail, or believe that you have receivedthis e-mail in error, please notify the sender immediately(by replying to this e-mail), delete any and all copies of thise-mail (including any attachments) from your system, and do notdisclose 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
*********** 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