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

Re: [STDS-802-11-TGBE] Feedback Requested for CRs related to NSTR operation - 11-21-0558r0



 

Matt,

 

For your first point, the AP at the anchor link can get the info of the exchange between the target non-AP MLD in non-anchor link internally within the MLD without monitoring the link. There should be some time lag, but it can follow the recommended (should) behavior at some point. And such internal exchange is required anyway to stop transmission on other link(s) when detected on a link.

For your second point, if there’s only two links, I agree the cross link is not so complex. I commented to have some restriction on the number of multi-links.

Your third point is what I anticipated as a rejection reasoning. Setting an anchor link is somewhat similar to the channel access rules for wider bandwidth based on the primary link. The non-continuous channels being not further supported, MLO will be their substitutions and more relax transmission rules for NSTR link pairs may be favored. But if there’s a lot of “corner cases” where non-simultaneous transmission happens to occur on one link at the same time with the other link, the gain of NSTR will disappear as normal communication can’t be achieved and it’s better to set some restrictions to the NSTR MLDs. Note that the AP MLD side still have the gain to start TXOP with such NSTR MLDs in my proposal.

 

 

From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, March 31, 2021 8:17 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Feedback Requested for CRs related to NSTR operation - 11-21-0558r0

 


Tomo,

 

 

On Mon, Mar 29, 2021 at 7:57 PM <tomo.adachi@xxxxxxxxxxxxx> wrote:

 

Hi Matthew,

 

I feel a bit of your warlike attitude on this doc not adding please, while your polite in the other one (21/530). :0

 

Anyway

For CID 2980, Ill say that the main load of cross-pair monitoring will be at the AP MLD, and when the AP MLD itself was able to initiate a TXOP on a non-anchor link, it can know without monitoring the links that it should not start nonsimultaneous transmission to the peer device of the NSTR link pair.

And the peer device cannot carrier sense on the anchor link while it is responding to the AP MLD on the non-anchor link, so it cannot initiate transmission on the anchor link.

 

The point was that:

 

a) your proposed resolution was proposed in order to reduce the amount of cross link monitoring

With an anchor link, one "only needs to check the activity on the anchor link"

But this is not true.

If the AP is TX a Trigger on the non-anchor link to STAx, then the AP on the anchor link might want to know this to avoid starting a DL TX to STAx on the anchor link.

I.e. there is still checking of each link by the other.

The goal of the proposed change is not achieved.

 

Also, I'll change the resolution to suggest that the amount of cross link monitoring is not so difficult that reducing the links monitored from 2 to 1 would create a significant release of complexity for an implementation. I.e. I think that the goal of reducing cross link checking is not one that most people care about. It's not a very complex operation.

 

I'll also add to the resolution that removing the ability of a non-AP STA to be able to use the first available link reduces some of the gain of ML operation for an NSTR STA, which includes latency reduction.

 

 

 

 

Best regards,

tomo

 

From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 30, 2021 5:08 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Feedback Requested for CRs related to NSTR operation - 11-21-0558r0

 


see:

 

 

Matthew Fischer

Nice Guy

Broadcom Inc.

+1 408 543 3370 office


This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.


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


This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.


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