| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Sanket, apologies for the delayed response. I have uploaded rev. 6 of doc 1988; I hope it may address your concerns/questions. Also, please see my responses inline in
[green] and appreciate your feedback. From: Sanket Kalamkar <sankal@xxxxxxxxxxxxxxxx>
Hi Samat, >Making TXOP return optional even after it has been solicited would create an ambiguity, i.e., it leaves the coordinating AP uncertain whether
the >coordinated AP will return the remaining time or use the allocation until it expires or use only a portion of the allocation. When an AP acting as a coordinating AP has set the RX TXOP Return Support field to 1, it indicates the capability of the AP to receive/process the TXOP return frame.
Since the TXOP return mechanism does not have an error recovery mechanism to handle the cases when
the TXOP return frame is lost, the coordinating AP needs to be able to reclaim a TXOP return upon the expiration of the allocated time.
Currently, the specs allows both mechanisms: see D2.1 page 371 line 37-39 ->
non contradiction on this
Quite the contrary. Sending the TXOP return frame in the multi-AP sharing decreases airtime utilization linearly with the number of coordinated APs.
Rev. 6 addresses this concern by returning to the original purpose of the TXOP return: a coordinating AP sends a TXOP return frame when it has an unused portion of the allocated time
left. Regarding insufficient allocation of time, I agree that the coordinating AP has to allocate sufficient time. There are other CIDs addressing
this Issue, and I am working on the corresponding resolution. Well, I think the suggested changes address it.
The retransmission scenario, however, is not a contradiction caused by TXOP return. With or without TXOP return, the coordinated AP is required
to ensure that its PPDU transmissions and expected responses fit within the allocated time. Please note that the acknowledge frames are scheduled ahead of the queued TXOP return frame If the AP lacks sufficient time after retransmission, it
won't be able to send out the TXOP return frame. 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 All, regarding doc 26/1988. Thank you for the opportunity to present the CR. I saw some questions in the chat windows but unfortunately, I didn have a chance to copy these questions, could please duplicate your question(s) for me per email ? Also, members who had questions but didn’t have a chance to ask (due to time limit), Your questions are welcome, so please email me your questions. Thank you in advance, samat From: Samat Shabdanov Hello Alfred/All, after receiving some comments offline, I have revised doc 26/1988 “, “urgent MAPC/Co-TDMA
CID” to address them. the uploaded rev. 1 of doc 1988 is here https://mentor.ieee.org/802.11/dcn/26/11-26-1988-01-00bn-urgent-mapc-co-tdma-cid.docx thank you, samat On Sun, Oct 11, 2026 at 4:58 PM Samat Shabdanov <Samat.Shabdanov@xxxxxxxxxxxx> wrote:
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 |