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

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

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:

  1. “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.

 

  1. “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?

  1. “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

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

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

 

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

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

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

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