| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Duncan, Let me make my comment clearer.
Considering the following case, the DL next SN transferred is rollover because the amount of buffered or anticipated additional DL data in the current AP MLD for a TID exceeds 4096.
In this case, although the DL next SN is within the WinStartO+buffer size, the target AP MLD still cannot start DL data transmission before receiving the termination indication of the DL draining period.
Regards Guogang Huang 发件人: huangguogang
Hi Duncan, Thanks for your response. I don’t think this note can work. Because we have already allowed the target AP
MLD can start DL data transmission before receiving the termination indication of the DL draining period. The issue is both the non-AP MLD and the target AP MLD have no way to distinguish whether the amount of buffered or anticipated additional DL data in
the current AP MLD for a TID exceeds the block ack window size or not. Regards Guogang Huang 发件人: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Hi Guogang, Pooya, and all, Thanks for your comment. I expect the current AP MLD indicates the proper Next DL SN to the target AP MLD (based on the buffered data and the new data expected from the
DS). Pooya added clarification below that says the target does not start transmitting the new DL data (from the DS) until it receives the Notify frame from the STA that indicates DL drain termination in this case. "NOTE ― If the amount of buffered or anticipated additional DL data in the current AP MLD for a TID exceeds the block ack window size during the DL draining period, the
next SN to be assigned for DL individually addressed Data frames (during context transfer) might be outside the non-AP STA's block ack window, in which case the target AP MLD will not be able to transmit the new MSDUs/A-MSDUs from the DS to the non-AP MLD
until receiving from the non-AP STA a UHR Link Reconfiguration Notify frame with the Type field set to 2 and the DL Draining Completed field set to 1." @Pooya Monajemi, please correct me
if my understanding is wrong. Thanks, Duncan From: huangguogang <huangguogang1@xxxxxxxxxx>
WARNING: This email originated from
outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Duncan, Thanks for preparing this CR document. I have a question on the following note. If the next SN to be assigned for DL individually addressed Data frames (during context transfer) might be outside
the block ack window, does the target AP MLD have a way to know that? We need to add the text to clarify this part. NOTE ―
If the amount of buffered DL data in the current AP MLD for a TID exceeds the block ack window size during the DL draining period, the next SN to be assigned for DL individually addressed Data frames (during context transfer) might be outside
the block ack window, in which case the target AP MLD will not be able to transmit the new MSDUs/A-MSDUs from the DS to the non-AP MLD until the Next SN becomes part of the block ack window. Regards Guogang Huang 发件人: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx> Dear seamless roaming TTT members, We're at the very last stretch. These are the last few CIDs scheduled for Wed AM2 Joint session. 10062 is a deferred CID but the rest have not been presented before. Could you please let me know if you have any feedback before the presentation? Thanks! Duncan 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 |