| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Yunbo, Regarding the use of PIFS on a link that frame exchange is successful (SP1), we already have a similar discussion (487r5) and the SP result was: SP#2: Do you support to define a mode that when doing simultaneous frame exchanges with STA MLD without STR capability, the inter-frame space between the ending time of the short responding PPDU
and the starting time of the following soliciting PPDU may be more than SIFS and no more than TBD time?
·
Note: it may be required to do ED sensing when the IFS is longer than SIFS according to EU regulation. Y/N/A/No answer: 12/36/33/16 Even though we are still positively thinking about the use of PIFS for this case, it looks the group’s feedback on this case was quite not-supportive. And, for your SP2, I have one clarification question. Is the SP2 targeting the case that the AP MLD does not receive any acknowledgement on all links? Or, is it for the case that the AP MLD receives an acknowledgement at least on one link? BR, Young Hoon From: Liyunbo <liyunbo@xxxxxxxxxx> Hi Young Hoon, Thanks for response. I think we don’t have conflict design until now. But we need to discuss how to harmonize the text to make the rule clean for different cases. Please see my response below. Regards, Yunbo 发件人: Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Yunbo, Thanks for letting us know your proposal. It looks interesting and I’ll give my feedback soon. Regarding your comment on my SP, I think your intention is to extend the proposed rule to be applied to a case that the AP MLD even does not receive immediate response on another frame. (but at least PHY-RXSTART.indication is received.) [Yunbo] you are correct. If we go back to the original proposal, one of rationale that I would like to relax current PIFS recovery rule is because an AP MLD has at least maintains a successful frame exchange on at least one link. (It is similar to 11ax OFDMA acknowledgement
case, where the TXOP owner considers the frame exchange successful if the TXOP owner receives successful response from at least one scheduled STA.)
[Yunbo] I think they are quite different. OFDMA acknowledgement is happens in single link. But what we discuss now is for two links, we should decouple the operate in two links as much as possible
if it doesn’t has strong reason to couple them. Now, you want to relax the current PIFS recovery rule even for the case that there’s no link that successful recovery is received.
I’m not totally against this idea, but at least I think it needs further discussion as different members may have different level of flexibility in relaxing current PIFS recovery rule for non-STR MLDs. [Yunbo] we can discuss more, and see opinions from more people. I still prefer the delayed PIFS covers both cases by now. Unless we can find a stronger reason to distinguish the two cases.
So, I would like to have separate discussion on your proposed modification, which can be done together with your other ideas in 1062r0. Good thing is that you are not against the behavior shown in the SP when the AP MLD fails on one link but receives response on another link successfully, right? [Yunbo] I am not against your design, but want to have a fully discuss before you run the SP. Because the delayed PIFS also related to other cases. Thanks, Young Hoon From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Young Hoon, Thanks again for waiting. I uploaded my presentation in the server, please have a look and let me know your comments. After technical discussion we can further think about whether need to merge
or modify our SPs. https://mentor.ieee.org/802.11/dcn/20/11-20-1062-00-00be-error-recovery-for-non-str-mld.pptx After review your SP again, I have one comments: Whether below text in yellow is not needed in your SP, or can extend to PHY-RXSTART.indication of response frame is received in another link.
Because when response is failed on another link, AP MLD should also allowed to continue its transmission on the this link. And AP may follows the same procedure whether response on another link is failed or successful. (When PPDUs are failed in both link,
the procedure can covered by PIFS recovery rules in current spec. my comment doesn’t cover this case)
Regards, Yunbo 发件人: Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Yunbo, Sure, let me know whenever you are ready. Best, Young Hoon From: Liyunbo <liyunbo@xxxxxxxxxx>
Hi Young Hoon, Thanks a lot to defer the SP to have a further discussion. I have several cases that want to discuss with you and all other people. It is a little difficult to discuss only through text in e-mail,
could you give me a couple of days to prepare a presentation, and then we further discuss base on that? It may would be more efficient to discuss with figures and clear motivations. Regards, Yunbo 发件人: Young Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Yunbo and Ming, Based on our discussion during the TGbe MAC call, let me initiate another round of email discussion regarding 20/427 synchronous multi-link operation. To the best I remember, your comment was to figure out the overall solution considering all possible operation scenarios. Let me first explain what is covered by this SP.
And, these operation are limited to the case that AP has ability of relatively fast cross-link communication. So, can you please let me know which operation scenario do you want to consider on top of the operations that current SP covers? Thanks, Young Hoon 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 |