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



Following comments received during discussion during Monday's call and some email exchange, I have updated 11-21-0558 to R8
Interested parties should review the changes to ensure that they understand those changes.

https://mentor.ieee.org/802.11/documents?is_dcn=558

It looks complicated, but it is not, really.

A short tutorial is provided herein:

1) in the language regarding when an AP or STA "should" not transmit, it was noted that the AP or STA might not always know if the NSTR STA is, for example, transmitting on the other link.

this prompts the change to "if the AP determines that the STA is transmitting on the other link"
i.e. the changes include the addition of "determines that"

2) slight language modification - consistent choice between "circumstances" and "conditions"

3) the "editors note" stating that the first two paragraphs are TBD has been deleted

4) the point was raised that 10.23.2.2 (baseline EDCA process) describes all of the conditions for when backoff is invoked and that 35.3.13.3 is adding two new conditions for when to invoke backoff
it was suggested that all of the backoff invoking conditions should appear in one place, i.e. 10.23.2.2

As such, changes to 10.23.2.2 are added to the document

5) it was noted that since the condition of changing from "virtual empty queue" to "non-empty queue" in 35.3.13.3 matches item a) of 10.23.2.2, then provided that the 35.3.13.3 description of the transition from virtual empty to non-empty references item a) [as it has now been changed to do], it is further noted that 10.23.2.2 explicitly indicates that CW is unchanged for the item a) invocation of backoff, so the explicit mention of unchanged CW in 35.3.13.3 can be removed, and as such, has been removed

6) it was noted that EACH of the paragraphs that includes a SHOULD clause creates the same conundrum for the STA or AP involved - that is to say, whenever a STA or AP takes the recommendation to NOT transmit a frame, then some statement must exist as to what to do with EDCA/backoff due to that TX deferral - i.e. the change made to the first SHOULD paragraph needs be added to the other two SHOULD paragraphs for the same reason - and so, it has been done, with slight modification, as not all of the conditions apply to all of the SHOULD paragraphs



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


On Mon, Apr 19, 2021 at 2:05 PM Matthew Fischer <matthew.fischer@xxxxxxxxxxxx> wrote:
Ronny,


On Tue, Apr 13, 2021 at 8:22 PM Ronny Yongho Kim <ronny1004@xxxxxxxxx> wrote:
Hi Matthew, 

Thank you for your proposed resolutions on NSTR related CIDs. 
I have a question on your resolution regarding CID 3147. 
Your proposed resolution is regarding the AP's behavior when the frame cannot be transmitted to the NSTR STA while it is transmitting on the other link. 
My comment was how the AP can handle the frame that needs to be transmitted to the NSTR STA during "should not transmit" circumstances. 

I would like to clarify the proposed text. 
Your proposed text a) suggests that AP shall abort the transmission to the STA and initiate the new transmission to a different STA.
Abort would normally be used when the transmission is in process and is then halted.
This is not an abort.
This is a "do not start the TX"
 
Then, what will happen to the frame that needs to be transmitted to the NSTR STA?
If an AP has many frames for TX for a single AC but to different STA, then certainly, the AP has some method for managing which frame will be transmitted at any given access event.

Note that each EDCF of the EDCA is invoked and running for an AC, and not for a specific frame.
 
The AP will wait until the end of the transmission of the STA of the same MLD on the other link and initiate the backoff procedure?
No.
The proposed rules say that if the AP is running an EDCF for AC_X and the frame that it "intended" to TX when that EDCF reaches backoff==0 is not available, then the AP may substitute some other frame of AC_X and transmit that frame instead.
To some extent, the proposed language is not really necessary because again, an EDCF is running for an AC and the decision of which frame from that AC TX queue is to be the one that is transmitted when backoff==0 for that AC is an implementation decision, and therefore, the choice of sending some other frame of the same AC should already be available to the AP. However, some might argue that there is either an explicit or implicit ordering of the frames in the TX queue for each AC, as first come, first serve, but I know of no such requirement.
 
What if there is no other frame to transmit to the other STA , what would be the AP's behavior?
This is definitely the interesting case and the proposed text attempts to provide an answer.
 
  
Is your proposed text b) for the frame that was intended to transmit to the NSTR STA ?
Again, the EDCF backoff==0 is not for a frame, but for an AC
 
If this is the case, then why the new backoff procedure needs to be invoked again? Since the AP has already gained the right to initiate transmission of a frame, the AP can just wait with backoff count 0 until the end of the transmission of the STA of the same MLD on the other link and then transmits the frame. If the AP follows the b), it has to repeat the new backoff procedures until the end of the transmission of the STA of the same MLD on the other link. 

This is an interesting point.
The proposed text is modeled on the behavior for the internal collision.
The internal collision is different, though, in that there is only one WM, so once the winning AC starts transmitting, the losing AC is not counting backoff.
However, for this case, the winning WM is idle and if this AP has nothing to transmit, then it is possible that the winning WM remains idle.
Therefore, the situation is different from the internal collision case, and could be handled differently.
So, what could be done differently?

Along the lines of what you are hinting at, we could allow the AP to transmit nothing, holding the backoff==0 and waiting for the NSTR limiting condition to go away.
Provided that the winning WM has not become BUSY during this wait time, then it is probably ok for the AP to then begin transmission of the deferred frame with no other action required.
However, if, during the wait for the NSTR limitation to go away, if the winning WM becomes BUSY, then the AP MUST start a new backoff, as a randomization must be invoked.
Actually, you could argue that no backoff needs to be invoked only if the winning WM is BUSY at the point in time when the NSTR limitation disappears, as this moment would correspond to the baseline condition of a TX queue changing from empty to non-empty and when that happens, an initial examination of the medium is performed and backoff is only invoked if the WM is BUSY at that moment.

So - all of that could be accommodated with another bullet:

c) if no frame to a different STA is in the TX queue for that AC, consider the TX queue for that AC to be empty until either a frame to a different STA appears in the queue or the condition described above no longer exists, in which case the procedure described in 10.22.2.2 (EDCA backoff procedure) shall be followed and if the backoff procedure is not invoked per the conditions described therein, then transmission may proceed immediately.

I'll upload a new 558r5 shortly.

An AP that is affiliated with an MLD should not initiate the transmissiont to a STA affiliated with a non-AP MLD, of a frame on aone link of an NSTR link pair of the intended recipient MLD non-AP MLD at the same time that the a STA of the non-APintended recipient MLD is transmitting a frame or is a TXOP holder on the other link of the NSTR link pair. An AP of an MLD that has gained the right to initiate transmission of a frame of an AC on a link through the rules for EDCA backoff in 10.23.2.4 (Obtaining an EDCA TXOP) but which does not initiate the transmission of a frame on that link due to this circumstance shall perform exactly one of the following actions:

a)     Initiate transmission on that link, of a different frame of the same AC to a different STA

b)     Invoke the backoff procedure for that AC of that link, while leaving CW[AC] and QSRC[AC] unchanged (#2100, #3147)

 

Best Regards, 
Ronny Yongho Kim

On Tue, Mar 30, 2021 at 5:07 AM Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

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

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