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

Re: [STDS-802-11-TGBN] Co-TDMA ICR related CR SP 11/25-2367

Hello Klaus,

 

thank you for summarizing the key points of doc 2367 and the main questions raised during the ad hoc presentation last week.

 

I still have strong concerns with the new 2 parameters that you propose for Co-TDMA ICR.

 

 

Regarding

 

  • “ Time requested” param

 

I have a few comments and concerns about this parameter

  1. The overallocation can be solved using the TXOP return mechanism.
  2. The amount of time, a coordinating AP may allocate to coordinated AP(s) is constrained by the “max TXOP allocation under consideration” param in the ICF, i.e,

this is the maximum amount of time the coordinating AP may allocate to another AP(s).

             

                                           For the case of 3 AP scenario with 2 coordinated APs: the knowledge of requested times does not help coordinating AP in allocating times to coordinated APs

when  (t1+t2) > “max TXOP allocation under consideration” with t1 and t2 denoting times requested in the ICRs from coordinated AP1 and AP2.

For our practical cases, this happens often.

 

e.g,, for  AC[VO] with TXOPlimit is only about 2ms, so the max TXOP allocation under consideration < 2ms bkz the coordinating AP is expected to allocate the TXOP T to itself as well.


Note that, typically, the AP may need to request a bit more time than estimated for servicing LLT in the buffer in anticipation of additional incoming frames before the MU RTX TXS frame is received by the coordinated AP.

The requested time make sense in the 3 AP scenario but for the case of 2 AP scenario, the coordinating AP may just allocate the time available for sharing without the knowledge of requested time from the coordinated AP.

 

                                           In certain cases, like when (t1 + t2) < “max TXOP allocation under consideration”, the coordinating AP may use this information, but the cases are limited in practice.

 

  1. The requested time for UL.

The proposal also suggests to use the “requested times” for UL traffic.

Please elaborate which additional mechanisms are needed to help the coordinated AP to estimate “requested time for UL” .

At the time when ICR is sent by the coordinated AP, it needs to know at least BSRs from non-AP STAs, when these BSR requests are sent before or after ICRs ?

Please note the coordinated AP is not an owner of the TXOP.

 

              Therefore,  I have these concerns about this parameter which may not be that useful in practice. Besides, it adds additional complexity for UL.

 

  • Vendor-specific information in a vendor-defined format
    1. The use of this parameter is not very clear.

If it is vendor-specific parameters which are intended for proprietary use, then other vendors cannot use it.  
       What is the purpose of Vendor Specific bit used to the presence of the vendor specific parameters. The vendors don’t need the indicator bit to utilize reserve bits for proprietary use.  The example will help.

 

 

Thank you in advance,

samat,  Mediatek

 

 

From: Klaus Doppler (Nokia) <0000320c1b22a542-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, May 12, 2026 2:20 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] Co-TDMA ICR related CR SP 11/25-2367

 

External email : Please do not click links or open attachments until you have verified the sender or the content.

Dear all,

 

I plan to run a SP on the Co-TDMA ICR this week (21 CIDs) 11/25-2367r8

 

For those who could not follow the presentation and discussion during last week’s ad-hoc meeting, I would like to summarize the main points and hope we can run the SP in an efficient way.

The CR document adds two information fields to the Co-TDMA ICR, allowing the Coordinated AP to provide additional information related to the TXOP sharing request in addition to yes/no:

  1. Time Requested
  2. Vendor-specific information in a vendor-defined format

Compared to the previous version, the CR has been significantly simplified and now includes fewer options.

After the presentation, the main discussion points were as follows.

Vendor-specific information in a vendor-defined format

The concern raised was that the Co-TDMA ICR should be kept simple in 802.11bn. Additional fields could be considered later, for example in Wi-Fi 9 or beyond, after Co-TDMA has been tested in the field.

The supporting view was that vendor-specific information would allow vendors to experiment with different feedback options in the ICR and potentially improve the Co-TDMA feature based on practical experience.

Time Requested

The concern raised was that Time Requested may not provide significant benefit, since only a short duration is shared and the information may not be useful in the ICR. It was also noted that TXOP sharing allocation could be based on semi-static information exchanged during Co-TDMA negotiations, without requiring instantaneous information.

The supporting view was that, without Time Requested information, the Coordinating AP may over- or under-allocate time to the Coordinated AP. For example, it may allocate 1 ms when only 0.5 ms is needed while under-allocating another AP that would need 1.5ms, reducing the efficiency of the Co-TDMA procedure. Semi-static information may not be sufficient because variations in MCS, medium access time, and other factors can have a large impact on the instantaneous resource needs.

Best regards,
Klaus

 

 

 

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