Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Comments on 11-20-1395-00-

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

Hi Matt,

Thanks for your hard work on PDT.

Could you take a look at my couple of comments in the attached file?

Thank you

Best Regards,

Hanseul Hong

2020년 9월 17일 (목) 오전 6:41, Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>님이 작성:

Based on discussion during and after presentation during a recent TGbe session, additional changes have been made to 1395 N-STR operation.
Please see r10:

Details of what changed in R10 (and previous revisions) can be found at the top of the document

In particular, despite my assertion that no good would come of any attempt to make the definition of NSTR "inability to receive" specific to some set of parameters, I was convinced by various commenters to believe that it was better to establish a specific set of parameters to define NSTR receive impairment including a relationship to the RX minimum sensitivity specification and those things are now included in the definition of NSTR. I.e. if the decision about whether to label a pair of links as NSTR is implementation dependent, then the information is less useful as the recipient of that information cannot be certain of exactly what it means.

Note that these changes were made with the assumption that additional parameter values could be provided within capability signaling, e.g. the NSTR-ness of any two links could be dynamic based on the values of those parameters, e.g. TX power, TX BW and PPDU location within the operating channel.

https://mentor.ieee.org/802.11/dcn/20/11-20-1395-10-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str.docx

Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office
On Tue, Sep 15, 2020 at 10:55 AM Matthew Fischer <matthew.fischer@xxxxxxxxxxxx> wrote:
Yunbo,

Thanks for the review.

I am blaming my computer for having lost track of your email - my machine had rebooted a couple of times in the last couple of days.

As for your comments - I believe that you were able to bring each of your points up during the presentation Monday PDT, and I responded.
I've included a summary here:

1) NSTR definition

As discussed, I believe that there can never be a specific definition - the best that it can say is "transmission on one link causes receive impairment on the other link of the pair"

See r9

2) "transmit and receive" v "transmission and reception"
Agree to settle on one phrase - currently chose "transmit and receive" - see r9

3) phrasing, "not respond with CTS" v "may respond with CTS"

The convention is "may respond" - this implies that it is ok to NOT respond, this is how the standard is always written
I.e. we never say "a STA may not do something"

4) NSTR non-AP MLD should align PPDU

your comment is that this is not in the motion
I agreed on the call that we should SP this text after the body has had some time to think about whether the recommendation "should" is acceptable here, and noting that the motion was very broad in simply stating that the behavior of the NSTR MLD needs to be specified

Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office
On Fri, Sep 11, 2020 at 3:15 AM Liyunbo <liyunbo@xxxxxxxxxx> wrote:
Hi Matt,

Sorry for my network problem during the teleconference. Please find my comments attached.

Regards,
Yunbo

发件人: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2020年9月5日 9:45
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Dmitry,

On 1) - I understand the reason for your different interpretation.

Maybe it would be better as:

If all of the conditions of the previous paragraph are met, except for "the STA is not NSTR limited"

Would that make it more clear?

Or even more explicitly:

If all of the conditions of the previous paragraph are met, except for the condition "the STA is not NSTR limited"
On Fri, Sep 4, 2020 at 6:35 PM Matthew Fischer <matthew.fischer@xxxxxxxxxxxx> wrote:
Dmitry,

1)
link set should be describable as a set of links rather than a pair - there is no reason to limit it to only 2 links
and yes, the assumption is that all links in the set are NSTR to each other - I thought about whether any asymmetry could exist and it seemed pretty implausible to me

2)
on the CTS response extra condition - you're not reading it correctly
if says, if all of the conditions of the preceding paragraph are met EXCEPT - so you have to reread it as - the only condition that failed in the paragraph was that the STA was NSTR limited
if that is true, then it cannot be the case that an STR STA reaches this point

Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office
On Fri, Sep 4, 2020 at 6:15 PM Akhmetov, Dmitry <Dmitry.Akhmetov@xxxxxxxxx> wrote:
Hi Matt,

Please find my comments attached

From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, September 04, 2020 4:54 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str

Hello,

I've made a small addition.

I've added another AP should not transmit to an NSTR MLD in the case of when the AP might be able to determine that some STA of the NSTR MLD is actively transmitting to anybody else (i.e. currently, it only mentions transmitting to the AP, because that's easy for the AP to figure out) but it is possible that maybe the AP can see the non-AP transmitting for example, a P2P on a link and the AP might be able to decode the EHT PPDU header AID and Color or something in the MAC header that tells it that this is a TX by the non-AP MLD and if it can do that, then again, the AP should not TX to that NSTR non-AP MLD - so this new should not applies only when the AP is able to make that determination.

https://mentor.ieee.org/802.11/documents?is_dcn=1395&is_group=00be

Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office
On Thu, Sep 3, 2020 at 6:35 PM 김상현 <shk0787@xxxxxxxxx> wrote:
Dear Matthew and Kaiying,

I saw R2, and it seems to reflect SFD well.
Thank you for your hard work.

Best Regard,
Sanghyun Kim

Sanghyun Kim, Ph.D
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com

-----Original Message-----
From: "Kaiying Lu"<Kaiying.Lu@xxxxxxxxxxxx>
To: <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Cc:
Sent: 2020-09-04 (금) 03:41:52 (GMT+09:00)
Subject: Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str

Hi Matt and Sanghyun,

I agree with Sanghyun’s comment. The SFD gave the condition on which the responder is allowed to make a choice. But the condition is that the another STA affiliated with the NSTR MLD is participating an TXOP on that link. Without this condition, the NSTR responder shall respond CTS if NAV is idle on this link.

I think the draft text should reflect this condition.

Thanks,
Kaiying

From: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 3, 2020 11:00 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str

Sanghyun,

1)

missing "." added

2)

your comment:
text does not cover “the STA may not respond with a CTS frame." of the SFD. (We need some “may” for a STA with NSTR contrained)

the SFD text bothers me

a. I agree that the SFD says "may" not respond, which appears to allow for the responder to make a choice
b. I agree that doc 1395r0 does not provide a choice to the responder, but instead, always dictates, depending on conditions, that there either shall or shall not be a CTS

When reading the SFD, I assumed that the language was imprecise.

I will create a version which provides the choice as an alternative, assuming that the SFD expresses exactly what the body desired, i.e. that the responder has a choice.
That will be version r2

Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office

On Wed, Sep 2, 2020 at 10:59 PM 김상현 <shk0787@xxxxxxxxx> wrote:
Dear Matthew,

Thanks for preparing the text.
Please find attached comments.

Best Regards,
Sanghyun Kim

Sanghyun Kim, Ph.D
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com

-----Original Message-----
From: "Liuming Lu"<lu.liuming@xxxxxxxxxx>
To: <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Cc:
Sent: 2020-09-03 (목) 11:26:26 (GMT+09:00)
Subject: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str

Hi Matthew,

Thanks for the preparation for the pdt-mac-mlo-multi-link-channel-access-general-non-str.
I have some comments. Please see the attached file.

Best Regards,
Liuming Lu

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
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

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

Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str