| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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>
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]
Hi Yunbo,
Thanks for your prompt response.
Please see my 2nd response in-line.
Best regards, tomo From: Liyunbo <liyunbo@xxxxxxxxxx>
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]
Hi Yunbo,
Although I didn’t 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 it’s
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 can’t 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 shouldn’t transmit on link 2 because PIFS didn’t 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 don’t transmit in both link 1 and link 2 concurrently, you
don’t 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 I’m 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 don’t
want to cover it in the SP1 before the group has a full discussion. Best regards, tomo From: Liyunbo <liyunbo@xxxxxxxxxx>
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 |