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

[STDS-802-11-TGBE] 答复: PIFS recovery SP (11-20/1062r3)



Dear all,

 

After discussion with Tomo, there are some changes for the SP text to make the it more clear.

I would like to clarify that this is a high level SP at current stage. Because we see a problem for error recovery in the case showed in the presentation, so propose to allow a IFS greater than SIFS can be used to solve it. What’s  the concrete value of this IFS can be further discussed; whether same rules can be used for other scenario can also be further discussed; any different scenarios that may use a different solution is not disallowed.

Further comments are welcome.

 

    Do you agree that after two PPDUs with end time alignment (and the PPDUs carry the expected response frames are also with end time alignment) are transmitted by a NSTR MLD on link 1 and link2 respectively, STA 1 affiliated with this NSTR MLD may use an IFS greater than SIFS time interval between the ending time of PPDU carries the ending of successful response frame and a following PPDU within a TXOP on link1 when PHY-RXSTART.indication is received but FCS is not correct for response frame on link 2?

  STA 1 shall transmit the following PPDU only if the CS mechanism indicates that the medium is idle.;

  The concrete value for the IFS greater than SIFS is TBD.

  The usagepurpose is to leave enough time for PIFS sensing on link 2;

  The response frames are frames sent from STAs affiliated with the peer MLD in the TXOP in response to the frames carried in the previous PPDUs and conditions of the types of frames may be added in the future.  

  Note: it is for R1

 

Regards,

Yunbo

 

发件人: tomo.adachi@xxxxxxxxxxxxx [mailto:tomo.adachi@xxxxxxxxxxxxx]
发送时间: 20201118 9:01
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: PIFS recovery SP (11-20/1062r3)

 

 

Hi Yunbo,

 

Through the following discussion, it became apparent that there are some conditions and assumptions.

If I understand your intent correctly, the conditions and assumptions are:

-      The duration of PPDUs carrying response frames are assumed to be the same and sent concurrently. How to realize it is yielded to other proposals and TBD.

-      The response frames are Ack and BlockAck frames, which means it is limited to one way (non-bi-directional) data transfer. ß Maybe this is too restrictive from you intent, if response frames can meet the above assumption?

-      The SP text only covers the recovery at the link which the STA received successful a response frame while the STA at another NSTR link failed in receiving a response frame. To realize concurrent transmission on both links after recovery is TBD.

 

Hope these will help for the next step.

 

Best regards,

tomo

 

From: Liyunbo <liyunbo@xxxxxxxxxx>
Sent: Tuesday, November 17, 2020 9:22 PM
To: adachi tomoko(
足立 朋子RDCIT研WSL) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject:
答复: PIFS recovery SP (11-20/1062r3)

 

Hi Tomo,

 

Thanks for the further questions. Please find my response below in-line (in Green).

 

Regards,

Yunbo

 

发件人: tomo.adachi@xxxxxxxxxxxxx [mailto:tomo.adachi@xxxxxxxxxxxxx]
发送时间: 20201117 17:35
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: PIFS recovery SP (11-20/1062r3)

 

 

Hi Yunbo,

 

Thanks for your prompt response.

Please see my 2nd response in-line.

 

Best regards,

tomo

 

From: Liyunbo <liyunbo@xxxxxxxxxx>
Sent: Tuesday, November 17, 2020 5:49 PM
To: adachi tomoko(
足立 朋子RDCIT研WSL) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject:
答复: PIFS recovery SP (11-20/1062r3)

 

Hi Tomo,

 

Thanks for your questions. Please see my reply below in-line. If anything is not clear for you, please let me know it.

 

 

Regards,

Yunbo

 

发件人: tomo.adachi@xxxxxxxxxxxxx [mailto:tomo.adachi@xxxxxxxxxxxxx]
发送时间: 20201117 16:11
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: PIFS recovery SP (11-20/1062r3)

 

 

Hi Yunbo,

 

Although I didnt attend the call, let me jump in.

Is the SP text below intended to describe the behavior in slide 5?

In such case I see the following:

The PPDU durations of BA11 and BA21 are shown to be the same and PPDUs end in the same timing. But its not added as conditions in the SP text.

Do we control the durations of the PPDUs each carrying the BlockAck to be the same before the TXOPs start or by signaling in PPDU11 and PPDU12?

[Yunbo] I think it is necessary to align the ending time of BA11 and BA21, otherwise, one of the BA will overlap with the following PPDU on the link that BA is finished earlier, so the receiving of BA that finished later will be interfered by the transmission of PPDU on another link. In that case, the procedure can not work well. How to control the length of BA, I think it is a different topic that doesn’t covered by this presentation. For example, using TRS Control subfield in QoS Data, or aggregate a Trigger frame with Date to control the length of BA. So the two BAs on different link will align.

[tomo] Although it may be a different topic, if that is not clear, we cannot move forward to discuss on the recovery during TXOP, can we?

[Yunbo] based on current spec, we already have some ways to align the duration of two BAs, for example, what I mentioned in above response. But it may has other ways to improve it, e.g. align the BA transmitted in non-HT PPDU. Since it already have some solutions, I think we don’t need to discuss it here.

 

And what I would like to add is that, there may be other signals or noise overlapping.

We cant guarantee there is no interference even if the TXOP is protected. So, we need to consider such case and think of the recovery behavior.

 [Yunbo] The other signal or noise can not controlled by initiator MLD, and we don’t need to guarantee there is no interference within TXOP,  but it will be covered by CCA during PIFS sensing. If the CCA result is busy, following PPDU can not be transmitted. I don’t see a problem here.

[tomo] Assuming that the BA durations are aligned, if BA21 overlaps with other interference and CCA busy time gets longer, even if CCA is idle at the slot boundary at link 2 PIFS after BA11 and expected/lost BA12,  you shouldnt transmit on link 2 because PIFS didnt really elapsed after CCA being idle. To perform CCA, you need PIFS (SIFS+Slot time to do RxTx turnaround and perform CCA).

[Yunbo] Agree with you. If the some period within PIFS is busy due to other interference, then even the channel is busy at the slot boundary of PIFS is idle on link2, following PPDU shall not be transmitted. But please think about that, this case is also happens in single link error recovery, it doesn’t has any relationship with multi-link operation. So we just follow the same PIFS sensing metric on single link. Here, the problem try to resolve is PIFS sensing on link2 can not be performed due to cross link interference from link1, so we need to leave more inter frame space to allow PIFS sensing on link2. If the PIFS sensing result on link2 is still busy (due to other interference) after leave PIFS on link1, just stop the transmission of next PPDU.

 

Then, we must cross check if the end times are the same even if the durations of BA11 and BA21 are controlled to be the same. That is because if they are not the same, PIFS recovery is meaningless. Are you requiring to do up to such extent? Taking delay for exchanging information between the links into account, do we need to specify or negotiate the maximum duration?

[Yunbo] I don’t understand why it need double check whether the ending time are the same if they are controlled by the initiator MLD. I list some scenarios that need some delay to exchange the BA receiving status, but I didn’t touch that part for this SP. For this SP, it is assume the initiator MLD can get the information without significant delay which is a more simpler case. For example that the two links are implemented in single chip, so it can get the cross link information very quickly.

[tomo] If you dont transmit in both link 1 and link 2 concurrently, you dont need to check the end time. But as I mentioned above, you should take at least PIFS on both links for concurrent transmission. And for the concurrent transmission, starting of PIFS needs to be the same. For the delay, if may in the SP text is covering what you said, i.e., only for the MLD that can achieve quick exchange among links, then Im fine for it. (I will correct my words in the previous comment to do we need to specify the maximum duration? I admit negotiate was confusing. J)

[Yunbo] First, let me clarify. Within a TXOP, if previous transmission is successful, only SIFS is needed before concurrent transmission; If at least one BA is failed to be decoded, then PIFS is needed before next concurrent transmission, For SP1, it only target for the case that MLD can do quick exchange. For the delay exchange case, PIFS is also needed base on my analysis, but the scenario and behavior is not the same. I dont want to cover it in the SP1 before the group has a full discussion.

 

 

Best regards,

tomo

 

From: Liyunbo <liyunbo@xxxxxxxxxx>
Sent: Tuesday, November 17, 2020 2:06 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] PIFS recovery SP (11-20/1062r3)

 

Dear all,

 

Below SP in doc 11-20/1062r3 is failed in today’s MAC call. But I didn’t get people’s concern, it will be appreciate for the people who has concern to send me an e-mail. I am glad to have further discussion with you.

 

    Do you agree that after two PPDUs with end time alignment are transmitted by a NSTR MLD on link 1 and link2 respectively, STA 1 affiliated with this NSTR MLD may use a greater than SIFS time interval between the ending of successful response frame and following PPDU within a TXOP on link1 when PHY-RXSTART.indication is received but FCS is not correct for response frame on link 2?

  STA 1 shall transmit the following PPDU only if the CS mechanism indicates that the medium is idle;

  The usage is to leave enough time for PIFS sensing on link 2;

  Note: it is for R1

 

 

Regards,

Yunbo


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