| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Sindhu and all, After more offline discussion, below is the updated version. The part related to technical changes are marked in red. Other sentence are used for
scenario description and clarification. Please further check. Base on regulation, two constraints are added in SP text: 1) upper limit of this IFS is PIFS; 2) CS is required within this IFS. SP1:
•
In R1, 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
between the ending time of PPDU carries the 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, with an upper limit of PIFS;
–
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. Regards, Yunbo 发件人: Sindhu Verma [mailto:000011381223f2e2-dmarc-request@xxxxxxxxxxxxxxxxx]
Hi Yunbo, IFS being larger than SIFS with the precise value being TBD is not exactly compliant with the ETSI-BRAN regulations which clearly state that the
value should not be greater than PIFS. Maybe, you can add another sub-bullet which says that IFS cannot be greater than PIFS Regards, Sindhu From: Liyunbo [mailto:liyunbo@xxxxxxxxxx]
Hi Sindhu, Thanks for your good input information.
The 1st subbullet of SP mentioned CS is required when the IFS is extended larger than SIFS, so it will aligned with the regulation. The
factor that IFS can not exceed PIFS can be considered when we decide the concrete value of this IFS. Regards, Yunbo 发件人: Sindhu Verma [mailto:000011381223f2e2-dmarc-request@xxxxxxxxxxxxxxxxx]
Hi Yunbo, Below are some comments on your proposals regarding their compliance with the ETSI regulations for 5GHz and 6GHz (the ETSI-BRAN harmonized standards
EN 301.893, etc). Regarding SP1, per ETSI regulations, such a gap between the end of the PPDU carrying the response frame and the start of the next PPDU from the device
that initiated the TXOP, cannot exceed PIFS. And if the gap is more than SIFS and less than equal to PIFS, channel sensing is mandatory in one observation slot of the PIFS. Copying from section 4.2.7.3.2.6 of EN301.893 below: “The Initiating Device and its Responding Devices can have multiple transmissions without performing an additional CCA on the Operating Channel
or combination of Operating Channels providing the gap in between such transmissions does not exceed 16 µs. Otherwise, if this gap exceeds 16 µs and does not exceed 25 µs, the Initiating Device may continue transmissions provided that for a duration of one
Observation Slot the Initiating Device found the Operating Channel(s) to be Unoccupied Channel(s)” Similarly, in SP2 and SP3 below, the gap between 2 consecutive PPDUs from the AP in case the AP does not receive a PHY-RXSTART.indication corresponding
to the response frame, cannot exceed PIFS per ETSI regulations. Regards, Sindhu From: Liyunbo [mailto:liyunbo@xxxxxxxxxx]
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 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
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]
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
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 |