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] [EXT] [STDS-802-11TGBE] Straw poll on "0427 synchronous multi-link operation"



Hi Younghoon,

 

Thanks for your presentation. I have two questions on the issue you described on slide4.

 

I understand the AP MLD asynchronously re-transmit D3 and transmit D4 on link1 and link2 because of the missing of BA3 on link2.  My question is:

  1. Assume the channel state is idle on both links, MLD AP need to spend almost one BA time to understand the missing of BA3 on link2. Why the Re-TX D3 can happened ahead compared to the TX-D4?
  2. Assume the channel is state busy on both links, as you mentioned, the AP MLD need to do CCA check before decide to send the next data frame on both link. The

asynchronously transmission issue may also happened if the CCA time is different on both link even if  the AP MLD  got BA3 on link2 and decide to send the next data frame. In this case, I understand it not matter to BA3 missing.

 

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: 2020625 10:39
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11TGBE] Straw poll on "0427 synchronous multi-link operation"

 

Hi Younghoon,

 

Thanks for the reply. Let me ask this way, to make sure I understand your proposal:

 

Say the AP on the 2nd link obtains TXOP for 5ms and the second frame in the TXOP, ending at the 2ms mark, fails. In the baseline, the AP is allowed to transmit if CS is idle at the PIFS boundary; if it cannot transmit at the PIFS boundary, it needs to perform a full contention. Your proposal is extending this and the AP is allowed to transmit at any time without performing contention from 2ms to 5ms (if the transmission can complete within the TXOP) as long as the CCA is idle, is this right?

 

If this is right, what I am asking is: shouldn’t there be a maximum duration (e.g. within EIFS starting from 2ms), that the AP can do this? Do we really want to allow the AP to resume transmission without contention for the entire remainig TXOP?

 

Regards,

Rojan

 

From: Young Hoon Kwon <younghoon.kwon@xxxxxxx>
Sent: Thursday, June 25, 2020 12:19 AM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] [EXT] [STDS-802-11TGBE] Straw poll on "0427 synchronous multi-link operation"

 

Hi Rojan and Yongho,

 

Thank you very much for the discussion.

But, I don’t think fairness is an issue for this case.

Before this recovery mechanism involved, the AP MLD already obtained a TXOP.

And, the TXOP owner’s error recovery shall be limited to the existing TXOP duration, which is the baseline error recovery rule (10.23.2.8).

This implies that if the TBD time is longer, the AP MLD has less time to transmit for the follow up frames during the remaining TXOP duration.

So, if the AP MLD can initiate a new TXOP after the TBD time, then I agree that there can be a fairness issue.

However, as I mentioned here, this is not the case for this proposal.

 

Hope this can answer for your concern.

 

Thanks,

Young Hoon

 

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Wednesday, June 24, 2020 1:11 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11TGBE] Straw poll on "0427 synchronous multi-link operation"

 

Hi Yongho,

 

Thanks for the comment. The SP says “ … the AP MLD can continue its transmission on the link within the obtained TXOP TBD (e.g., SIFS or PIFS) time after the failed reception of the immediate response if the channel is idle.

My question was how long can this TBD time be? If there is no maximum specified, that means the AP is allowed to transmit without performing full contention (IFS+backoff) for the whole TXOP; whereas a 3rd party non-AP STAs need to perform a full contention. That’s what I meant by unfair to the non-AP STAs.

 

Best Regards,

Rojan

 

From: Yongho Seok <yongho.seok@xxxxxxxxx>
Sent: Wednesday, 24 June 2020 12:17 PM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11TGBE] Straw poll on "0427 synchronous multi-link operation"

 

Hi Rojan, 

 

The AP MLD is still listening to a primary channel on the link even though it failed to listen to any control response from the TXOP responder. 

In consequence, the AP MLD updates any physical and virtual CCA if it listens to any other transmission during the waiting time for synchronizing both links.

When the AP MLD checks the CCA during the TBD time (e.g., PIFS or SIFS) for accessing the failed link, in such case the CCA may be busy. 

If the AP MLD can't listen to the failed link during the waiting time for synchronizing both links and tries to access the link just based on the ED during PIFS, I agree that it may have some problem like a collision. 

In the SP, the CCA mechanism on the link is TBD. I think that the CCA mechanism should consider the packet detection etc. It should not be just the ED based channel access. In this case, I couldn't understand what is a fairness issue.  

 

Thanks, 

Yongho 

 

2020 6 23 () 오후 8:39, Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>님이 작성:

Hi Younghoon,

 

Thanks for further clarifications.

 

As you also mentioned, even if the AP performs CCA before resuming the TXOP, the longer it waits, the higher the chances of the medium becoming busy. If we allow the AP to hold on to the medium for arbitrary duration of time, there may be fairness issues for non-AP STAs. As such, there should be an upper bound on the time that the AP is allowed to perform the “PIFS like” TXOP recovery, else the chances of collisions in the medium will increase. I think, EIFS may be a good upper bound. If the CCA is idle within EIAFs, AP may perform the TXOP recovery; anything longer and the AP shall perform regular channel access. What do you think?

 

Regards,

Rojan

 

From: Young Hoon Kwon <younghoon.kwon@xxxxxxx>
Sent: Wednesday, June 24, 2020 5:07 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] [EXT] [STDS-802-11TGBE] Straw poll on "0427 synchronous multi-link operation"

 

Hi Ming and all,

 

This is to have follow up discussions on yesterday’s presentation regarding 20/0427 Synchronous multi-link operation.

First of all, thank you very much for your valuable comments during the call.

To the best I remember, the concern that Ming has is that the duration of immediate response frame can be long such that continuing a TXOP when the AP MLD does not receive the immediate response frame correctly may not be appropriate.

If the duration of the immediate response frame becomes longer, it is true that the chance of the wireless medium (that BA was not sent) becomes busy will increase. And, also I agree with you that it is not appropriate to continue the AP MLD’s TXOP if the channel becomes busy.

However, this is why I propose to have CCA before resuming the TXOP in the SP. Therefore, the AP MLD will continue the TXOP on the link that BA is not successfully received only if the channel remains idle before resuming the TXOP.

I think this procedure is actually in line with current PIFS recovery rule (The only difference is that the CCA measurement duration is extended from PIFS to whole BA + SIFS duration).

 

Please let me know if I misunderstood your comment.

 

Thanks,

Young Hoon

 


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