| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Abhi Before debating the new issue you raised below, I just want to confirm that the answer (Including the fig you requested us to draw) to the issue you raised in the call is clear and
it can work, right? Regarding the new issue, you argument conflicts with your previous one. In previous call, you said TWT setup frame should link specific, then the transmitting link should be known,
however, now you argue “you won't know up-front, which link a TWT setup frame will get transmitted on”.
For the retransmission, this is not big issue. Anyway, the retransmission for MLO is different from that single link since at least address field should be changed. Liwen’s and Minyoung’s proposals are more constructive, they work for me. Best wishes Ming Gan 发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
Hi Ming, Rubayet, Liwen touched on a crucial aspect of MLO: Due to the nature of multi-link operation, an individually addressed Mgmt frame can be transmitted on any available link. This is one of the key reasons why the standard has defined
a procedure for identifying the intended link for an individually addressed Mgmt frame (i.e., the Link ID bitmap in TWT IE or an explicit IE to be carried in a mgmt frame). In other words you won't know up-front, which link a TWT setup frame will get transmitted
on. Therefore, you can't tie it to any particular link's TSF. This problem won't occur with the solution already defined in the spec - i.e., the TWT field in the TWT IE is tied to that one link which is signaled via the Link ID bitmap and therefore is agnostic to which link the
setup frame ultimately gets sent out on. If your goal is to setup synchronized TWTs, you can include a TWT IE for each link (with the corresponding Link ID bit set to 1) and the TWT field set to the value based on the TSF of the intended link.
Before adding more "fixes" to your proposal and making more complicated, we need to ask ourselves: Does the existing solution work under all scenarios? If the answer is yes, then what is the need for an alternative (and
more complex) solution? Regards, Abhi From: Yongho Seok <yongho.seok@xxxxxxxxx>
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. I have a similar comment but the solution is different. Current 11be TWT can establish the overlapped TWT SPs on multiple links, and TWT SPs are independent of the transmitting link of the TWT Setup frame. It seems that reusing/extending the existing 11be TWT is better instead
of defining another TWT operation. Thanks, Yongho 2022년 5월 6일
(금)
오전 11:49, Liwen Chu <liwen.chu@xxxxxxx>님이
작성:
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 |