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