| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, Please see my follow-up responses. Regards, Dibakar From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Dibakar, Thanks for the detailed feedback. Please see my responses
inline. Best, Sanket From: Das, Dibakar <dibakar.das@xxxxxxxxx> 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:
[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. [DD: If there is need for future extensibility, it should apply equally to both parameters and need to be changed accordingly. For now, I don’t see any value in keeping them different. Also, there is no practical case when AC VI limit assigned
to a non-AP STA would be 16ms. If you have real-life examples where APs are allowing STAs to use 16ms for VI TXOP, will be good to know. ]
[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. [DD: I see. If shared AP doesn’t support TB PPDU transmission, is it needed ?]
[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. [DD: today if non-AP STA is not requesting any TWT or SCS, AP still triggers that STA based on its own logic (network load being high etc.). For C-TDMA, you can leave it to implementation in same way for simplicity. ]
[Sanket] This assumes that Co-rTWT and Co-TDMA are deployed together. However, we should avoid making such an assumption when drafting the spec. [DD: While we should not assume things, we should not invent multiple ways of achieving the same thing. Is this profile applicable for the narrower scenarios where APs are not doing Cr-TWT ? Conversely, are you saying if there is no periodic
traffic profile, there is no C-TDMA possible ?]
[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. [DD: that’s not always necessary as I mention above. Moreover, in CTDMA unlike Basic UL MU case, there is already a way to return unused allocation to minimize impact of inaccurate time allocations. So, its even less needed. ]
[Sanket] While SCS mechanisms are primarily tailored for in-BSS operations and per-STA traffic management,
[Not true. SCS for direct link is not for in-BSS traffic signaling. It’s actually tailored for the same scenario as what you are talking below: asking AP to trigger you for “NOT in-BSS
traffic” according to some periodicity. Also, P2P-TWT is similarly also not about signaling in-BSS information. ] 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:
[The parameters you listed have analogous terms in SCS.]
[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. [DD: Will be good to have that discussion.] 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> Hi all, Please use this email thread to provide feedback on the Co-TDMA PDT. Thanks, Sanket From: Sanket Kalamkar <000033b8f79f2eb4-dmarc-request@xxxxxxxxxxxxxxxxx> 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> 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 |