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

Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11TGBE] Straw poll on "0427 synchronous multi-link operation"



Hi Rojan,

 

Thanks for the follow up comments.

I think your understanding on this proposal is mostly correct. However, it is somewhat misleading when you say the AP is allowed to transmit at any time without performing contention….

It’s not “at any time” but is specifically given to the immediate response time (+ SIFS).

I think there are two issues that are involved in this discussion. One is collision issue and the other is fairness issue.

For the collision issue, I think having a CCA before resuming the transmission can resolve the issue. Of course, as Yongho mentioned, it is still TBD the level of CCA for better protection.

For the fairness issue, regardless of the time before resuming the transmission, this transmission is happening during the TXOP that the AP has already obtained. (If this proposal is not fair to other, then with the same logic PIFS recovery is also considered to be not fair.) So, I think fairness is not a critical issue to be considered here.

Regarding your suggestion, EIFS is not meant to resolve a fairness issues among multiple STAs but is introduced to avoid possible interference during an on-going transmission sequence. In this sense, it’s not quite clear to relate length limitation with EIFS for resolving fairness issue.

So, I’m still hesitating to include your suggestion into the SP.

 

Best regards,

Young Hoon

From: rojan.chitrakar@xxxxxxxxxxxxxxxx <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Wednesday, June 24, 2020 7:39 PM
To: Young Hoon Kwon <younghoon.kwon@xxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 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