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