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

Attachment: 11-25-1082-00-00bn-pdt-mac-co-tdma-cr-cc50-part-3-JK-Sanket.docx
Description: 11-25-1082-00-00bn-pdt-mac-co-tdma-cr-cc50-part-3-JK-Sanket.docx