| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |