Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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]
发送时间: 2020522 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 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