Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

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

Hi Sanket,

As a reminder, I would like to list my suggested changes as below:

Remove the text for further discussion: “(#825)A PPDU carrying a Co-TDMA ICF shall not occupy any 20 MHz subchannel that lies outside the overlapping portion of the BSS bandwidths between the Co-TDMA coordinating AP and each AP polled by the ICF.”
In the attachment from your previous response email, you modified the text as “(#825)In an MU-RTS TXS Trigger frame that allocates a TXOP to a Co-TDMA coordinated AP, the Co-TDMA coordinating AP shall not allocate an RU to the Co-TDMA coordinated AP outside the overlapping portion of the BSS bandwidths of the ~~two APs~~coordinated AP and the bandwidth of the PPDU carrying the MU-RTS TXS Trigger frame.”. But in r3, it changed back to the original text. May I know the reason?
Remove the text to avoid redundancy: “The PPDU carrying the CTS frame from a Co-TDMA coordinated AP shall be transmitted on the 20 MHz channel(s) indicated in the RU Allocation field of the User Info field of the MU-RTS TXS Trigger frame that allocated the time to the Co-TDMA coordinated AP. ”
Remove the text and CID from the table or change the resolution: “(#821)NOTE—When an AP participates in a Co-TDMA procedure, it can manage UL transmissions from its associated non-AP STAs using existing mechanisms such as RTS enablement (see 26.2.1 (TXOP duration-based RTS/CTS)) or MU-EDCA (see 26.2.7(EDCA operation using MU EDCA parameters)). Such coordination of UL transmissions can facilitate the reception of Co-TDMA-related transmissions, including the reception of an MU-RTS TXS Trigger frame at a polled AP or the reception of a MAPC TXOP Return frame at the Co-TDMA coordinating AP. “

Thanks for your consideration!

Kaiying

From: Kaiying Lu
Sent: Tuesday, July 29, 2025 6:23 PM
To: Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

Hi Sanket,

Thanks for the response.

With the text in r2, “A PPDU carrying a Co-TDMA ICF shall not occupy any 20 MHz subchannel that lies outside the overlapping portion of the BSS bandwidths between the Co-TDMA coordinating AP and each AP polled by the ICF”, it will lead to poor performance for sharing AP if there is at least one polled AP with narrow BW. The subsequent in-BSS transmission BW is nothing to do with the polled AP’s BW and should be based on the channel availability between the sharing AP and its associated non-AP STAs.

The proposed approach will limit the Co-TDMA utilization.

Please also see my further comments attached.

Thanks,

Kaiying

From: Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>
Sent: Tuesday, July 29, 2025 5:07 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx; Kaiying Lu <Kaiying.Lu@xxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

External email : Please do not click links or open attachments until you have verified the sender or the content.

Hi Kaiying,

Thanks for the feedback.

With ICF in a higher bandwidth and ICR in a lower one, the coordinating AP may lose the portion of the bandwidth not used by the ICR, as it would remain idle and thus appear available to OBSS STAs. An OBSS STA could then opportunistically use it. Given these considerations, a straightforward approach is to have the Co-TDMA ICF occupy only the overlapping portion of the bandwidth, along with subsequent in-BSS PPDUs. This approach will also be compliant with regulatory requirements.

The above approach will keep the Co-TDMA protocol simple by avoiding the addition of many rules aimed at optimizing behavior (which otherwise would be necessary based on your proposal), as such rules could lead to complexity, interop issues, and poor adoption.

Best,

Sanket

From: Kaiying Lu <000019325336b823-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, July 29, 2025 1:30 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Sanket,

Thanks for the efforts.

As I commented during your presentation, here are some more questions and comments:

“The ICF, as part of the Co-TDMA procedure, that solicits a (#987)Co-TDMA ICR from a polled AP in a non-HT PPDU or a non-HT duplicate PPDU is called a Co-TDMA NTB ICF.”

Comment: It is less reliable and efficient for a Co-TDMA NTB ICF to solicit Co-TDMA ICR in a non-HT duplicate PPDU. E.g., When ICF BW is 160MHz or 320MHz, if the ICF solicits the ICR in 160MHz or 320MHz, the chance to have successful ICF/ICR frame exchange would be much lower than soliciting ICR in a non-HT PPDU on primary 20MHz. The wide BW sharing AP might hesitate to initiate Co-TDMA due to the risk of losing the TXOP. Suggest limit the ICR in a non-HT PPDU.

“It is less reliable and efficient for a Co-TDMA NTB ICF to solicit Co-TDMA ICR in a non-HT duplicate PPDU. E.g., When ICF BW is 160MHz or 320MHz, if the ICF solicits the ICR in 160MHz or 320MHz, the chance to have successful ICF/ICR frame exchange would be much lower than soliciting ICR in a non-HT PPDU on primary 20MHz. The wide BW sharing AP might hesitate to initiate Co-TDMA due to the risk of losing the TXOP. Suggest limit the ICR in a non-HT PPDU.”

Comment： It is not clear. When the coordinating AP operating BW is 160/320MHz and a polled AP operating BW is 80MHz,

· Can Co-TDMA TB ICF BW be larger than the overlapping BW(80MHz) of the two Aps?

· If yes, since it proposed the RU allocated to ICR shall be within the overlapping portion (80MHz) of BSS BW of the two APs, can RU allocation to ICR be on primary 20MHz only? What about the BW of in-BSS transmission for the coordinated AP?

“The bandwidth of the PPDU carrying a Co-TDMA NTB ICF shall not exceed the overlapping portion of the BSS bandwidths of the two APs. “

Comment: It is not good/efficient for large BW coordinating AP. When the coordinating AP operating BW is 160/320MHz and the polled AP operating BW is 80MHz, this rule will limit the TB ICF BW to be within 80MHz even though 160/320MHz channel might be available at the coordinating AP side. It is very inefficient for wide bandwidth AP to perform Co-TDMA.

Thanks,

Kaiying

From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 28, 2025 5:15 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

External email : Please do not click links or open attachments until you have verified the sender or the content.

Hi Jonghoe,

Thanks for the detailed feedback. Please see my responses inline. I have also provided some responses to your comments in the attached document.

Best,

Sanket

From: Jonghoe Koo <jh89.koo@xxxxxxxxxxx>
Sent: Friday, July 25, 2025 1:19 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Sanket,

Thanks for working on the Co-TDMA negotiation details.

Attached please find my comments and suggestions.

Summary of my comments are as follows:

1. We may need to specify the condition to the value of the Rx TXOP Return Support field to 1 in consideration of the Co-TDMA negotiation results (specifically, Rx TXOP Return Support field setting during the Co-TDMA negotiation) with any polled APs in a Co-TDMA ICF.

[Sanket] I updated the normative text in subclause 37.13.2.3.5 (TXOP return phase) to clarify the condition. Please expect the change in the next revision, which is 11-25/1082r2.

2. It seems more appropriate if Traffic Control field is included in the MAPC Request Parameter Set field rather than the MAPC Scheme Parameter Set field.

[Sanket] The MAPC Request Parameter Set field is present only when the MAPC Operation Type field is set to 5 (i.e., Alternate). This value is used by a responding AP to propose alternate parameters to those provided by the requesting AP. The field is absent if the responding AP's reply is either Accept or Reject (please see subclause 37.13.1.3.1 (General) of 11-25/599r16 (Motion 453)). Given that the requesting AP's traffic profile is specific to the AP, it seems unusual for the responding AP to suggest changes to those parameters by offering alternatives. Furthermore, if the MAPC Request Parameter Set field is to be used, it remains unclear how the responding AP can convey its own parameters to the requesting AP in order to establish a bidirectional agreement. To me, it seems that it would take two Negotiation Request/Response frame exchanges between the APs, compared to just one when the MAPC Scheme Parameter Set field is used.

Considering these points, using the MAPC Scheme Parameter Set field is a more suitable. It enables both APs to exchange their respective parameters, allowing a mutual agreement through a single Negotiation Request/Response frame exchange.

3. It would be much better if we specify reasons to allow multiple Traffic Profiles per AC.

[Sanket] It is up to the requesting AP to decide how many traffic profiles it wishes to report (limited by the value of Traffic Profile Count field). An AP may have multiple traffic flows with varying periodicities and payloads that may not be adequately represented by a single TXOP duration and periodicity.

4. Suggest to have ‘Length’ field in the Traffic Profile field for future extensibility.

[Sanket] We do not need a Length field. If needed, an existing reserved bit can be used to indicate the presence or absence of a field.

5. Suggest not to prevent using ‘Alternate’ MAPC Operation Type for future extensibility.

[Sanket] For Co-TDMA, there seems to be no need for 'Alternate' parameter as discussed in #2.

Regards,

Jonghoe KOO

Communications Standards Research Team, Samsung Research

Samsung Electronics

From: GeonHwan Kim <geonhwan.kim@xxxxxxx>
Sent: Friday, July 25, 2025 4:58 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

Hi Sanket,

Thanks for your work on Co-TDMA PDT.

How about to including “AP TB PPDU Response Supported” into the Co-TDMA Info field?

This information seems to be only used for Co-TDMA, isn’t it?

Best Regards,

GeonHwan Kim

LG Electronics

From: Sanket Kalamkar [mailto:000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Friday, July 25, 2025 4:35 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

Hi all,

Please use this email thread to provide feedback on the Co-TDMA PDT.

Thanks,

Sanket

From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, July 24, 2025 11:34 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi all,

The revision 1 of the Co-TDMA PDT 11-25/1082r1 is uploaded on Mentor.

Best,

Sanket

From: Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>
Sent: Monday, July 21, 2025 11:54 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: PDT-MAC-CR-Co-TDMA Part 3

Co-TDMA TTT

Part 3 of the Co-TDMA PDT (11-25/1082r0) is uploaded on the mentor. Please let me know your feedback.

Best,

Sanket Kalamkar

To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1