Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2)

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

From: Tong Bian <tong.bian@xxxxxxxxxxxxxxxx>
Date: Monday, July 28, 2025 at 6:48 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

Hi Klaus, Taeyoung, Sanket,

Thanks for the discussions. I added my comment inline

Best regards,

Tong

Panasonic

From: Klaus Doppler (Nokia) <0000320c1b22a542-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 28, 2025 11:21 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

Hi Taeyoung,

I also have one comment inline (marked with Klaus)

From: Taeyoung HA <ty1115.ha@xxxxxxxxxxx>
Date: Monday, July 28, 2025 at 3:24 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] PDT-MAC-CR-Co-TDMA Part 3

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

Hi Sanket,

Thanks for quick reponse. Please see my addition question inline.

Best Regards

Taeyoung

-------------------------------------------------------

--------- Original Message ---------

Sender : Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>

Date : 2025-07-26 00:15 (GMT+9)

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

Hi Taeyoung,

Thanks for the questions. Please see my responses inline.

Best,

Sanket

From: Taeyoung HA <ty1115.ha@xxxxxxxxxxx>
Sent: Friday, July 25, 2025 1:43 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBN] (2) [STDS-802-11-TGBN] (2) [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 your hard work on PDT.

I have some clarification question on Traffic Profile field format.

Q1) Could you elaborate the purpose of Allocated TXOP Duration field?

Is it for determining the acceptability of Co-TDMA negotiation or determining the duration of TXOP to be shared in Co-TDMA operation?

[Sanket] When combined with the periodicity of the traffic specified in the Allocation Interval field, the Allocated TXOP Duration field helps the sharing AP make decisions about whom to poll, based on the available resources and the resources requested by APs that have agreements with it.

[Taeyoung] Thanks for the clarification. I agree that this information could assist the sharing AP in making decisions.

However, since the amount of traffic and MCS at the polling phase can vary dynamically, it leads to uncertainties in the TXOP duration required for the shared AP.

Additionally, the sharing AP cannot guarantee Co-TDMA operation during the polling phase with this information.

Therefore, I believe this information could be exchanged during the polling phase. (exchange in the Negotiation phase of MAPC may not be effective.)

[Klaus: Taeyoung, I agree with you and that is also why we have a proposal to include a "Requested Time Allocation” in the ICR. And I also agree with Sanket, having a field in the MAPC negotiation containing the Allocated TXOP Duration and information about the traffic helps the coordinating AP to select whom to poll.

[Tong: Hi Klaus, do you mean that TXOP duration information is added in both MAPC negotiation and ICR? I agree that it’s good to provide requested TXOP duration in ICR. But for Allocated TXOP Duration in MAPC, I’m wondering if the polled AP indicated this Allocated TXOP duration in MAPC, does it mean that it wants to be shared TXOP? So what’s the use of the “TXOP Sharing Solicited” field in ICR (Or in other word, the purpose of polling phase)? So I think adding the Allocated TXOP Duration in MAPC is not necessary. ]

[Klaus: I can see some benefits in including the Allocated TXOP Duration. In some cases the coordinating AP may have a choice to allocate up to 2.5ms of the TXOP for sharing. Based on the Allocated TXOP Duration which I read as “this is what I typically need” the coordinating AP can for example reduce the MAX TXOP Allocation Under Consideration to 1ms if the MAPC negotiations indicate the typical need is only 500us.]

Q2) Why multiple Traffic Profile is needed for each 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.

[Taeyoung] Thanks for the clarification. Could you explain why the Profile ID subfield is necessary?

Since these Traffic Profile fields are included in the MAPC Scheme Parameter Set, this information is just delivered through the MAPC Negotiation Request/Response.

These details do not need to be explicitly identified because they will be overridden by new MAPC Negotiation Request/Response messages.

(i.e., Partial update or delete of Traffic Profile can not be conducted in the current MAPC Framework)

I think Co-TDMA Coordinating AP just need summarized interval to determine which Co-TDMA coordinated AP can be candidate for polling phase.

[Sanket] Could you please elaborate on the design a bit more?

[Taeyoung] I can get your point through the above answer. Some traffic may not be represented by a single periodicity.

Best Regards,

Taeyoung

-------------------------------------------------------

--------- Original Message ---------

Sender : 김정준 <jungjun.kim@xxxxxxxxxxx> Connectivity표준Lab(SR)/삼성전자

Date : 2025-07-25 17:39 (GMT+9)

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

Hi Sanket,

Thank you for preparing the document.

I would also like to share a suggestion on the PDT.

For Per-AC Traffic Info field, an AC may have different meanings for differenet APs in terms of QoS characteristics or channel access probability.

In this context, I think it would be better for a reqeuseting AP to include some more information about ACs.

Best Regards

Jungjun Kim

--------- Original Message ---------

Sender : 구종회 <jh89.koo@xxxxxxxxxxx> Connectivity표준Lab(SR)/삼성전자

Date : 2025-07-25 17:21 (GMT+9)

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

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.

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.

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

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

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

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