Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] 答复: [

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

2022년 5월 17일 (화) 오후 2:59, Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx>님이 작성:

Hi Shawn, thanks for your response. I suggest we do another review of the baseline spec and iTWT related spec changes added in 35.8.2, and address the issue in a rigorous manner. Let’s continue this discussion post D2.0.

By TWT related capabilities/support, I meant TWT Requester Support, TWT Responder Support, Broadcast TWT Support, Flexible TWT Schedule Support in HE MAC Capabilities which are defined per STA.

Kumail.

On May 16, 2022, at 4:04 AM, Shawn Kim <shawn.kim@xxxxxxxxxxxxxx> wrote:

Hi Kumail,

Thanks for your response.

Please see my response inline

Best regards,
Shawn

2022년 5월 16일 (월) 오전 8:00, Muhammad Kumail Haider <kumail.ieee@xxxxxxxxx>님이 작성:
Hi Shawn,

Thanks for sharing your analysis. I agree that we need to revise definition of TWT requesting/responding STA now that we defined a way to signal TWT element for iTWT setup on a different link. However, I don’t agree that we need to amend TWT identifier definition for this purpose. I also don’t agree that we should indicate multiple links in link ID bitmap, as I have shared earlier in this thread and meeting, but for this email I will keep comments to the TWT identifier issue you raised.

[Shawn] Thanks for sharing your opinion. In my opinion, amending the definition is not the only way to resolve the inconsistency issue (a TWT requesting STA / a STA transmit TWT request frame). The issue can be addressed by considering an entity performing TWT negotiation as an MLD. In this case, it is necessary to define the TWT identification method for the MLD. I believe this is a separate issue from indicating multiple links using a single LinkID bitmap.

I think we all can agree that just because another STA of an MLD is sending the TWT element does not make it TWT requesting/responding STA; this attribute of the STA should be based on membership in a TWT agreement and participation in the operation. And we can address this by amending the baseline definition alone, preferably post D2.0 after due discussion.

[Shawn] My concern is that there are many behaviors defined/described in the baseline considering a TWT request/response STA as the STA transmitting the TWT element.
Therefore, if we modify the definition of the TWT req/resp STA, we need to modify a lot of parts considering the TWT req/resp STA as the STA transmitting the TWT element as well.

I also don’t agree that current iTWT text in 35.8.2 makes individual TWT operation MLD level. Because some information is shared across STAs of an MLD does not make the operation MLD level. E.g., TSF information may be shared across STAs. TWT agreements are established between STAs on the same link and all other signaling, except from TWT setup frame which may be sent across links, is link level. We have to consider MLME primitives as well. Further, different STAs of an MLD may have different capabilities/support related to TWT operation; we haven’t defined them at MLD level. TWT Flow IDs are also maintained per link.

[Shawn] As you know, an AP affiliated with an AP MLD and a non-AP STA affiliated with a non-AP MLD can negotiate TWT agreement on their operating link following baseline.
Even in this case, Although it clearly seems link-level operation, information regarding the negotiated TWT agreement should be shared between the APs/non-AP STAs of the same AP MLD/non-AP MLD. This is because a non-AP STA trying to negotiate a new TWT agreement on behalf of the other STA, the non-AP STA should avoid setting the Flow ID subfield as one of the values in use for the other STA. (Unless the non-AP STA intends to delete the already negotiated TWT agreement for the STA.)
Therefore, I believe that the TWT negotiation procedure defined in D1.5 (Performing TWT agreement on behalf of other STA) can only be achieved when performed at the MLD level.
I didn't understand what the problem was when each STA had different TWT-related capabilities/support. Would you explain more about the problem?

Moreover, the proposed modification of TWT identification as proposed in 22/552 also does not make TWT MLD level; Ming also commented this in the meeting that that is not the point of this proposal. So I would disagree that individual TWT operation as defined in current spec in D1.5 is MLD level.

[Shawn] In my understanding, the proposed TWT identification method using <Flow ID, MLD MAC address of a TWT Req STA, MLD MAC address of a TWT Resp STA, Link ID> tuple is for the MLDs.

Regards,
Kumail.

On May 13, 2022, at 1:12 AM, Shawn Kim <shawn.kim@xxxxxxxxxxxxxx> wrote:

Hi Ming, Kumail,

Thanks for the discussion regarding the TWT identification.

Let me share my understanding on the topic. Please correct me if my understanding is wrong.

The reason why Ming tries to define a new TWT identification method (<Flow ID, TWT Req MLD MAC add, TWT Resp MLD MAC add, LinkID> tuple) is to resolve the problem Kumail has mentioned.
-Definition of 'a TWT requesting STA' in the baseline is:
(9.4.2.199 TWT element) A STA that transmits a TWT element with the TWT Request subfield equal to 1 is a TWT requesting STA or TWT scheduled STA. Otherwise, it is a TWT responding STA or TWT scheduling STA.(11ax)
Hence, if a first STA performs TWT negotiation on behalf of a second STA of the same MLD, the first STA becomes a TWT requesting STA of the negotiated TWT agreement following definition in the baseline.

To make the second STA be a TWT requesting STA, we need to change not only the definitions of the TWT requesting/responding STA but a bunch of defined/described operations regarding a STA transmitting a TWT element as a TWT requesting/responding STA.

In my understanding, as suggested by Ming, keeping what is already defined in the baseline and considering the TWT negotiation procedure between two MLDs as the MLD level procedure is also a good way to solve the problem.
- In this case, a TWT requesting STA is still a first STA if the first STA performs TWT negotiation on behalf of a second STA of the same MLD(intent not to change the baseline). But the negotiated TWT agreement is considered as a negotiated TWT agreement of the MLD for the link the second STA operates.
(Since Ming does not touch the management part of the TWT SP, I believe all the negotiated TWT SPs between the two MLDs can be managed(terminated/suspended/resumed etc.) at the link that each negotiated TWT SP is applied to.)

And I also think we already have defined the TWT agreement procedure in D1.5 as an MLD level operation. As you know, when a first STA transmits a TWT element on behalf of a second STA, the first STA should obtain the TWT element (or at least the information to construct the TWT element) from the upper MAC(This is MLD level operation in my understanding).
Therefore, considering the TWT negotiation as MLD level operation and identifying each TWT agreement that is negotiated between the two MLDs by <Flow ID, TWT Req MLD MAC add, TWT Resp MLD MAC add, LinkID> tuple seems natural and good to me.

Thank you.

Best regard,
Shawn

2022년 5월 13일 (금) 오전 8:40, Ganming(Ming Gan) <000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx>님이 작성:
Hello Abhi

We need to find a way to move forward. Let us recall the history of this topic

1．  I presented this topic in 19/1988 about two year go, you argued there is TSF sync issue between affiliated APs, then one link with bitmap was accepted in 21/80, but bitmap leaves space for multiple links
2．  With the help of Kaiying and Minyoung’s work, TSF sync issue was addressed with the proposals of TSF offset and clock drift requirement. Then you argued it can’t work when I presented the case of multiple links, saying the target wake up time already passed in some links in the call because the starting time of each link is different
3．  After the work of Rubayet, the fig he drew demonstrates that it works well, then you asked how it works, then Minyoung provided the equation to tell you how it works.
4．  Meanwhile Liwen proposed to reference the tsf of the fixed link to address the framebody change issue when the packet is retransmitted on the other link, then you argued there is issue when a fixed link is not available (ML reconfiguration)
5．  To address your concern, Rubayet and I worked together and changed it to reference the tsf of the link that indicated in the bitmap (to which the TWT agreement applies), and kept Minyoung and Liwen’s suggestion. Then you argued it is complex. But there is only “addition” in the equation.

Best wishes,
Ming Gan

发件人: Ganming(Ming Gan) [mailto:000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2022年5月12日 19:31
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 22/552r2 Individual TWT

Hi Abhi

The exiting work already includes bitmap field and can support multiple links, why not use that directly?

To address your concern, I keep “using the TSF of the link to which the TWT agreement applies ”. Meanwhile I also incorporates liwen and Minyoung’s contributive suggestions, Please refer to the following text
•         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 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_ti + TSF_offset, where TWT_ti obtained from the the Target Wake Time field of the TWT element is in reference to the TSF time of i-th link indicated in the Link ID Bitmap subfield of the TWT element, TSF_offset = (TSF_0 - TSF_i) and TSF_0 is the TSF time of the setup link that is associated link ID of the lowest value, where the TSF_i is the TSF time of the i-th link indicated in the Link ID Bitmap subfield of the TWT element.
Best wishes,
Ming Gan

发件人: Abhishek Patil [mailto:appatil@xxxxxxxxxxxxxxxx]
发送时间: 2022年5月9日 12:20
收件人: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 22/552r2 Individual TWT

Hi Ming,

Thank you for your response.

>> 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?

It’s not a question of whether it will work or not. It is an argument of complexity with no added benefits. Why put unnecessary burden on implementations?

Therefore, the question to ask is: 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?

The alternative has undergoing a few rounds of updates as members have pointed out various issues. Each iteration adding more complexity.

With respect to the latest issue: if we were to go with a ‘reference’ link approach:
- Which link is selected as a reference link?
- Is the reference link same for all non-AP MLDs? Or is an AP implementation expected to track different links as “reference” for different non-AP MLDs?
- Is the reference link required to be part of the ML setup? In other words, is a non-AP MLD expected to keep track of TSF for a link that is not part of its ML setup?
- What if the AP MLD performs ML reconfiguration procedure that removes the reference link? Or is the AP MLD not allowed to remove a link that is marked as ‘reference’?
- Can the reference link be different based on who (non-AP MLD or AP MLD) initiates the TWT setup?

Addressing the above items will add more complexity to implementation and may create a new set of issues.

As I mentioned, the existing mechanism is simple to implement and works for all scenarios. And therefore, there is no need to define another way to do the same thing especially if the alternative adds complexity with no benefit.

>> 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 point was about the contents of the frame body. When a frame is retried on to another link, the contents of the frame body remain unchanged (otherwise, you would need to re-encrypt the contents). The TSF reference (in TWT field) will be carried within the frame body.

Regards,
Abhi

From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Sunday, May 8, 2022 6:44 PM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 22/552r2 Individual TWT

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
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]
发送时间: 2022年5月8日 4:43
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 22/552r2 Individual TWT

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>
Sent: Friday, May 6, 2022 4:44 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 22/552r2 Individual TWT

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>님이 작성:
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

From: Ganming(Ming Gan) <000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, May 6, 2022 6:21 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 22/552r2 Individual TWT

Caution: EXT Email
Thanks Minyoung. The following text sounds good to me.

发件人: Minyoung Park [mailto:mpark.ieee@xxxxxxxxx]
发送时间: 2022年4月27日 6:14
收件人: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 22/552r2 Individual TWT

Hi Ming,

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)"
Regards,
Minyoung

On Mon, Apr 25, 2022 at 12:41 AM Ganming(Ming Gan) <000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hello all

This email is for the discussion of Individual TWT issue. If you have comments, please let me know.

Best wishes
Ming Gan
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
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

--
Sanghyun Kim, Ph.D
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com
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

--
Sanghyun Kim, Ph.D
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com

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

Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 22/552r2 Individual TWT