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

Re: [STDS-802-11-TGBE] 答复: [Suspected Marketing Mail] 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


Thanks to all who have commented.
It's a complicated topic.

Here is a consolidated set of replies:
Feel free to read any or all or none, each of which is identified by the commenter:

See R12 for any referenced changes:
https://mentor.ieee.org/802.11/dcn/20/11-20-1395-12-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str.docx

Hanseul:

The question of MU-RTS, as you noted, is not addressed by the motion, and therefore, remains unaddressed by the PDT

The questions regarding the last two paragraphs were resolved by SP during the SEP 21 CC

Yonggang:

Definition: presence of "requirements" therein - this point was discussed during the SEP 21 CC and is addressed in a new revision by modifying the definition

Definition wording/inclusion of too many details - the specific requirements have been moved to the 33.x.y.3 subclause and remain intact
The reason for the complete set of details is due to some discussion that occurred after the previous CC presentation
Basically, all of the items mentioned can have in influence on the NSTR-ness of a pair of links
I.e. a pair of links might be NSTR given:
a) one value of TX power, but not at another
b) one PPDU width vs another PPDU width

use of the term "RTS link" - agreed that there is no formal definition for this term - I have reluctantly changed it to "the link on which the RTS was received" which uses many more words and makes the bullet item harder to read due to its length, but is more correct

10.3.2.9 CTS - proposal to remove the first bullet "the STA is affiliated with an MLD that has at least one NSTR link pair"
Previous discussion had not only suggested keeping the first bullet, but adding the phrase "that has NSTR link pairs"
I.e. I agree with you that it is implied that if the second bullet says that the RTS has to be received on one or more of the MLD's NSTR link pairs, then there must be at least one NSTR link pair in order to satisfy this bullet, and that only an MLD can have even one link pair, but others disagreed - so it is not me that you have to convince, but everyone else

Your comment on the second paragraph of 33.x.y.3 suggests that the behavior is described for an STR, not NSTR device.
This is not correct.
You have assumed that NSTR means "It is impossible for an NSTR device to transmit on linkA while receiving on linkB." but this is not correct.
An NSTR device may transmit on LinkA while receiving on linkB, the difference between STR and NSTR is that for STR, there are NO consequences to TX while RX, but for NSTR, there are potential consequences.
The group has never suggested that an NSTR device SHALL NOT TX while RX on the other link
So, TX during RX for an NSTR device is allowed, possible and addressable

33.x.y.3 
Regarding the wording of: An AP of an MLD should not transmit to an NSTR STA if that NSTR MLD is transmitting on the other link of an NSTR link pair
Your comment is that it is much easier for a device to take a directed action based on reception at its own antennas rather than based on transmission at the antennas some other device

I understand the general nature of the comment but there are many cases for which the reception at the AP might yield either no information or fuzzy information

a) there might be a transmission by the non-AP which is undetected by the AP due to overlapping signal
b) there might be reception activity at the AP which is not correctly decoded, even at the PHY header, due to interference or overlapping reception
c) there might be a valid PHY header which provides COLOR and AID information that might indicate that STAx is the transmitter, but that information can be incorrect because of color collision or incomplete AID information, etc.
d) there might be a valid phy header, but invalid MPDU header information
e) MPDU header information might not be available until near the end of a PPDU, meaning that the AP would have to wait until there is no activity whatsoever on the other link
f) The AP might not want to wait to determine which STA is the transmitting source

I.e. the AP is provided with a choice, due to the use of "should" instead of "shall" and therefore, the conditions do not need to be exact


Zhijie:

NSTR definition complexity:

The complexity is reduced by reverting to a reference, but the elements of that definition remain in the new paragraph in the behavior subclause for the reasons stated earlier in this email

If you feel that some aspect of TX RX alignment is needed in the definition (which is now specified in the behavioral subclause), then please provide some text suggestion.

Yunbo:

CCA sensitivity
As suggested during the CC, there is no single "CCA sensitivity", there are at least three components to CCA:
a) ED
b) RX minimum sensitivity
c) NAV

We could add something about ED, but the RX min sens item is a stricter requirement, so I believe that ED is not needed, unless you want to make the definition looser

i.e. right now, a link pair is NSTR if you cannot RX MCS0 at -82, i.e. your link-link interference must be about -85
It is my assumption that if you CAN RX MCS0 at -82, then you certainly can also do ED at -62, confirmed by the idea that the interference is -85, implying that a random signal at -63 or even down to -80 would trigger ED

If you want to mention the ED part, then you would say:
a link pair is NSTR only when you are NOT able to perform ED at -62, which means that your link-link interference must be about -62 which is clearly demanding a lot less of a device
I.e. that's a looser requirement for NSTR - i.e. an MLD remains able to call itself STR for an additional 20 dB of cross link interference
i.e. a worse-performing MLD could still be called STR



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


On Sat, Sep 19, 2020 at 3:22 AM Liyunbo <liyunbo@xxxxxxxxxx> wrote:

Hi Matt and all,

 

I have below comments for Matt’s updated definition about NSRT link pair.

 

1)       The last version in R9 only mentioned “causes an impaired ability to receive a PPDU”, it is not clear what does impaired ability exactly means. In the latest version in R10, it is much clear what the inability means. So the STA MLD will know what’s the exact rule to follow when it report the STR capability. So I more prefer the updated version.

2)       Response to Jay’s question. I think the main factors already mentioned in Matt’s definition. Power (the maximum allowed transmission power), bandwidth (any PPDU bandwidth) and MCS (Receiver minimum input sensitivity is MCS related).

3)       Besides minimum receive sensitivity level, I think the CCA sensitivity level should also be considered in the definition. The reason is receive sensitivity level is considered from the angle that the STA MLD receive a packet. But CCA sensitivity is considered from the angle that the STA MLD do channel contention. I think when either one is affected by the transmission on another link, it should be defined as NSTR link.

Matt, do you think the 3rd comment is reasonable to considered?

 

 

Regards,

Yunbo

 

 

发件人: Yang, Zhijie (NSB - CN/Shanghai) [mailto:zhijie.yang@xxxxxxxxxxxxxxx]
发送时间: 2020年9月19日 6:44
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] 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

 

Hi Dibakar,

 

A general question, why we thought TX power & RX sensitivity is the mainly factor to cause the NSTR issue? I think there are other factors to cause such issue as well, such as TX &RX synchronization mechanism due to the PHY design. And I doubt whether it’s correct or not if we thought the TX power & RX sensitivity is the only one factor in the new definition.

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: 2020年9月19日 2:25
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [Suspected Marketing Mail] 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

 

Hi Jay and Yonggang,

 

The previous text was unclear about whether STR/NSTR link pair is defined per PPDU or for the entire operation. The new text clarifies that this definition does not change from PPDU to PPDU. As such it is a step in the right direction.

 

Regards,

Dibakar

 

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Friday, September 18, 2020 7:20 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] 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

 

Hi Matt,

Agree with Yonggang, the NSTR definition is too complicated compared with the previous version. I think we could use some general sentence to define it in initial version, and then enhance it in the further if necessary. For the factors like Max TX power and min RX sensitivity, we could use a note to cover them temporarily.

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Yonggang Fang <yfang@xxxxxxxxx>
Sent: 2020年9月18日 12:08
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] 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

 

Hi Matt,

 

Thanks a lot for your effort on preparing the PDT.  I have some comments on the 1395r10.

 

1) "Non-simultaneous transmit and receive (NSTR ) link pair: A pair of links of a multi link device (MLD ) for which the transmission by a STA of the MLD on one of the links of a PPDU using the maximum allowed transmission power on the primary 20 MHz channel of the BSS using any PPDU bandwidth permitted within the BSS that the STA is capable of transmitting causes the inability of the STA of the MLD on the other link to meet the minimum receive sensitivity requirement defined in 34.w.x..y (Receiver minimum input sensitivity). Each link of such a pair is a member of the NSTR link pair."

a) Does the spec allow to refer to the requirement in the definition? 

b) This definition of NSTR  is too complicated.  Your previous definition of NSTR before R8 is much simple and clear. Why is it necessary to add such condition in the NSTR definition?  It would be better to describe those conditions in the NSTR ML setup and operation.   

 

2) RTS link

There is no definition for RTS link. Suggest to change to the link that carries the RTS frame or other words.

 

3)  "In this subclause , a STA is NSTR limited if all of the following conditions are true:

-        the STA is affiliated with an MLD that has NSTR link pairs

-        the STA has received the RTS on a link that is a member of one or more of the MLD ’sNSTR link pairs

-        a  STA  of the MLD is a TXOP holder or TXOP responder  on one of the other links  that is a member of at least one of the NSTR link pairs of which the RTS link is a member"

The first bullet is not necessary as it has been covered by the the second and third one. 

 

4) "A STA that is affiliated with a non-AP MLD and that transmits a frame on a link of one of its NSTR link pairs at the same time that another STA affiliated with the same non-AP MLD is receiving a frame on the other link of the NSTR link pair should ensure that the transmitted PPDU ends at the same time or earlier than the PPDU that is being recevied ."

a) It seems this sentence describes the case of STR not for NSTR .   Could you please clarify this sentence ?

 

Best Regards

Yonggang Fang

ZTE (TX)

 

Original Mail

Date: 2020/09/16 14:42

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


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.

 

 

 

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

 


D mitry ,

 

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 @intel.com> 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.

 

 

 

 

 

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@MEDIATEK .COM>
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@ZTE .COM.CN>
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

Image removed by sender.

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

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature