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

Thanks for the detailed feedback.

Please see my responses inline.

Best,
Sanket

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: Friday, July 25, 2025 11:04 AM
To: Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: RE: 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 PDT.

 

Some comments:

  1. The Allocation Duration in TXS frame and the Max TXOP Allocation Under Consideration in Feedback User Info field  needs to have same granularity. Since the former has granularity of 16us, this one should be 16us too. Moreover, the length of that field should be sufficient to cover the longest VI TXOP limit that a associated STA to the sharing AP would get: so, 16us * 8 bits should be fine.
[Sanket] The Allocation Duration field in a TXS frame indicates the time allocated to a single shared AP, while the Max TXOP Allocation Under Consideration field reflects the max total TXOP duration that may be available for sharing within that TXOP. From both a current and future extensibility perspective, the standard need not be self-limiting. Importantly, allowing the reporting of a larger TXOP value does not imply that an AP will exceed the limits defined by the spec for TXOP sharing duration.

  1. Why is BSS Color Information field of AP-1 needed to be shared to AP-2 ? How is it used in the CTDMA operation ? Also, even if needed why cant AP’s obtain that during active or passive scan ?

[Sanket] Per existing rules, the BSS color of a TB PPDU is that of the soliciting AP. Therefore, when a sharing AP polls (BSRP) one or more APs, the polled AP(s) needs to include BSS color in their response. Since we, as a group, have decided that participating APs will not be reading each other's Beacons/Probes for determining each other's parameters (this came up when Jay was discussing inclusion of RSNE information in MAPC frames), we need to provide BSS color information during C-TDMA negotiations.

  1. Traffic profile info is a major change to CTDMA and unfortunately this is brought up now one week before when we expect to close on draft 1.0. I believe this topic needs much wider discussion rather than adding incremental pieces here and there. These are my main concerns:
    • This is not a necessary feature. We already committed to have polling frame as mandatory in each CTDMA TXOP . Moreover, the polling frame contains explicit indication of how much traffic sharing AP expects to allocate and there is way for shared AP to return unused time. Given that, in each TXOP the sharing AP can efficiently allocate time.
[Sanket] While the expected max time allocation is conveyed by the sharing AP in the polling phase, how does the sharing AP decide whether to share the TXOP (an AP need not share every TXOP it wins) and whom to poll if the candidate APs haven’t shared any traffic parameters? Are you suggesting that the sharing AP pick APs randomly for polling? Blind polling could result in overlooking needy APs, leading to inefficient TXOP sharing. This could degrade overall performance. 

    • When both CRTWT and CTDMA are deployed together, I would assume CRTWT signaling will handle the periodic traffic case (and provide the same periodic information to other AP about when critical LL traffic is going to happen). CTDMA may be used on top to further reduce the peak latency within the r-TWT SP or to catch aperiodic traffic. So, explicit traffic indication seems to be redundant or not relevant.

[Sanket] This assumes that Co-rTWT and Co-TDMA are deployed together. However, we should avoid making such an assumption when drafting the spec.

    • Conversely, if you have such traffic signaling which is accurate enough, then the polling frame just adds constant overhead in each C-TDMA TXOP (btw this was one motivation we heard in 11be timeframe for SCS: reduce excessive BSRP). This discussion about long-term signaling should have happened before we voted to make the polling frame mandatory.

[Sanket] Traffic signaling during negotiation and polling serve distinct purposes. Signaling during negotiation helps determine which AP(s) to poll based on expected traffic periodicity. As discussed in 11-24/1016, actual traffic arrivals may deviate from the expected periodicity reported during negotiation due to jitter. Therefore, polling remains necessary to verify whether a polled AP has traffic for which the sharing AP intends to allocate the TXOP.

    • The proposed design is limiting. It essentially tries to recreate a portion of what SCS is doing but without any extensibility (e.g., cant add in future traffic priority etc.). On the other hand if you do try to make it extensible using your MAPC negotiation, you are just ending up with an SCS-like design, repeat all the discussions we had for SCS and add to spec bloat.

[Sanket] While SCS mechanisms are primarily tailored for in-BSS operations and per-STA traffic management, C-TDMA benefits from a more aggregated view of traffic across APs. The proposed inter-AP traffic signaling mechanism is both simple and intuitive, enabling the exchange of essential aggregated traffic information. Moreover, this approach integrates well with the agreed in-TXOP protocol elements—such as polling and primary AC indication in the ICF—ensuring consistency and minimal overhead. Specifically, the traffic profile includes:

  • AC => aligns with the primary AC
  • Expected priority => determines which AP to poll
  • Expected time allocation => indicates how much time an AP may need if polled

    • Also, not clear why this is for CTDMA only and not other MAPC features. Traffic requirement does not change whether you meet that requirement through CTDMA or CBF if both are in place.

[Sanket] While this traffic profile is currently proposed under the C-TDMA framework, it is general enough to be applicable to other coordination schemes like C-BF and C-SR, should they choose to incorporate traffic profiles in the future. That said, I haven’t seen any discussions in those contexts yet.

          My suggestion is to simplify (similar to what other members are doing for their proposals) by deferring this part or at least not re-invent the wheel this late.

 

The change to the fairness part seems okay.

 

Regards,

Dibakar

 

 

From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, July 25, 2025 12:35 AM
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