| Hi Ming, Rubayet, thanks for your responses.
I want to echo what Abhi said; and adding that we should first have a discussion on the possible use-cases for indicating multiple links in a link-ID bitmap before even getting into which link’s TSF applies, which has its set of technical issues that need further thought.
How often do we expect to setup this so-called “synchronized TWT” and what are the potential benefits? We have to consider cases when STAs may be in NSTR/EMLSR/EMLMR modes as well. And for iTWT, it is possible to set this up with separate TWT elements, do we really need to add a complicated way of signaling to do it with single TWT element, which potentially makes “which link’s TSF applies” inconsistent? Why should the AP/STA need to keep track of which link the Setup was signaled? This is not part of baseline and can easily be avoided by setting up separately for each link, such that TSF of respective link applies.
Kumail.
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 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. With the Target TWT Wake Time referring to the TSF time of the link where the TWT Setup frame is transmitted, the frame content of frame needs to be changed if the retransmission of the frame is in a different link. Is it possible to refer the start time to a fixed link? Best Regards, Liwen Caution: EXT Email Thanks Minyoung. The following text sounds good to me. If I understand correctly, what you want is to derive the TWT times of the other links from the TWT time indicated in the TWT element transmitted on one of the links so that the TWT start times across multiple links are aligned. Maybe better to spell that out as follows? "• If multiple links are indicated in the Link ID Bitmap subfield of the TWT element, then multiple TWT agreements are requested to be setup; A TWT agreement is requested on behalf of each of the STAs affiliated with the same MLD and that is operating on each of the indicated links. • The same TWT parameters are requested for all the links.
• The target wake time (TWT_r) of the Target Wake Time field of the TWT element shall be in reference to the TSF time (TSF_r) of the link the TWT element is sent.
• The target wake time of i-th link indicated in the Link ID Bitmap subfield (TWT_i) is derived from the Target Wake Time field of the TWT element as follows: TWT_i = TWT_r + TSF_offset, where TSF_offset = (TSF_i - TSF_r) and TSF_i is the TSF time of the i-th link.
(CID#6240 6241)"
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
|