| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello Sanket, sorry, for changing the status of the previous comment and requesting again to consider it part 3.
I have received a note that is better to clarify the re-TX timing rule for the TXOP return phase in the current PDT.
I have composed the draft of the text for the TXOP return phase.
It will help members and you to facilitate the review and receive critique.
As part of the TXOP return phase: “If a coordinated AP does not receive an ACK to its TXOP return frame, it shall retransmit
its TXOP return frame. The coordinated AP shall attempt such retransmission only if the time required for successful completion of the TXOP return which is the time
required to transmit the TXOP return and ACK frames, including the SIFs,
does not exceed the remainder of the allocated time.
“ Please note, I reused the term “remainder of the allocated time” from the same section.
I also enclosed the draft of this comment for the recommended placement in the specs, Thank you, samat From: Samat Shabdanov <0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx>
Hello Sanket, thank you for taking the time and efforts in addressing the comments.
We think that all the BW related topics may need further discussions. Please refer to the latest comments from Kaiying. I also have 2 minor comments:
I think it is important to add an additional definition to this field.
Since this 1 octet field is as an integer, we need to limit it to the specific range [0,255] or specified it as an unsigned integer.
However, I think it raises more questions now.
Let me ask you to remove it and we will defer this comment for further discussions with members
to understand their preferences of handling the re-TX mechanism for the TXOP return phase. I have also enclosed suggested changes for comments 1), feel free to revise if necessary.
Thank you, samat From: Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>
Hi Samat, Thanks for the feedback. I have already addressed some of your comments as part of the responses to other comments. For TXOP return, I added a clarification that the TXOP return will be sent within the allocated
time. Best, Sanket From: Samat Shabdanov <0000490d4a372b74-dmarc-request@xxxxxxxxxxxxxxxxx> WARNING: This email
originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hello Sanket, Thank you for the C-TDMA PDT rev. 3. Our comments are as follows:
we understand motivation for incorporating c-tdma profile into the MAPC framework, which is to help a sharing AP to decide which APs to poll. we also find it useful to exchange capability parameters between APs, e.g., we support the BW control field. However, we request to defer this part for further discissions to evaluate the benefits of the mechanism for polling. Since it was only published last week, it is premature to include this part in the PDT without obtained wide support. It is a very new topic with significant conceptual changes that perhaps will require revision of previous concepts, e..g, “mandatory polling” We haven’t even remotely discussed this concept. Note that previously referred doc.
11-24/1016,
in my opinion, is not very relevant. We agree with many questions raised by members that is indicative for further discussion on this topic Clearly, if C-TDMA profiles incorporated into MAPC framework, APs now need periodically negotiate to update C-TDMA profiles. This raises questions on the need of new MAPC mechanisms to update/re-negotiate, periodicity of these exchanges, and qualifying events ( new traffic flow, change of delay bounds, amount of traffic.. We also want to understand the mechanics of using periodicity to help for polling. The “bottleneck” of this part is also “expected TXOP allocation”. This is not only highly variable but also depending on MCSs and the amount of LLT parameter. How this can be incorporated into MAP framework, not clear
You are very familiar that we disagree to limit the BW on NBT ICFs. We think this part requires further discussions. We think that during the polling phase, sharing AP’s in-BSS BW should not be limited by the overlapping BW, as well as during the allocation phase, to limit the BW of MU RTS TXS BW which is related to the sharing AP’s in-BSS BW. We are also interested in support the dynamic BW operation for MU RTS TXS -CTS exchange. We request to defer so we can present to members the issues related to BW and let the group decide if our arguments are reasonable.
We don’t find it reasonable to support >4ms duration for LLT as the shared TXOP portion is bounded by the TXOP_limit[VI] The granularity, as indicated earlier, of duration in the MU RTS TXS is 16usec so the granularity of this field is recommended to be 4usec as well.
1.
If a shared AP does not RX an ACK, is it required to re-TX the return frame ?
2.
if the shared AP is required to re-TX the return frame, but the time required for re-TX of the return frame is greater than the shared TXOP duration, is it still required to re-TX ? thank you, samat from mtk 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 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 |
Attachment:
11-25-1082-02-00bn-pdt-mac-co-tdma-cr-cc50-part-3_Samat_MTK_rev2.docx
Description: 11-25-1082-02-00bn-pdt-mac-co-tdma-cr-cc50-part-3_Samat_MTK_rev2.docx