|
|
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.
|
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
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.
3.
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
|
|
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:
- Time Requested
- 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