|
Hi Guogang,
Thanks for the clarification and understood now. Let's work on the text more then.
BR,
Duncan
From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: Wednesday, July 15, 2026 5:33 AM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; Pooya Monajemi <p_monajemi@xxxxxxxxx>
Cc: stds-802-11-tgbn@xxxxxxxxxxxxxxxxx <stds-802-11-tgbn@xxxxxxxxxxxxxxxxx>
Subject: 回复: [STDS-802-11-TGBN] Please review - the last few seamless roaming CIDs
WARNING: This email originated from outside of Qualcomm. Please be wary
of any links or attachments, and do not enable macros.
Hi Duncan,
Good question!
In my understanding, the data forwarded from the current AP MLD to the target AP MLD is also from the DS. I’m not sure whether ‘the data from the DS’ can
be used to differentiate ‘the data forwarded from the current AP MLD’. Maybe this description not accurate.
For the green part of the text, maybe we need to add another condition, e.g. the DL data forwarding is not supported. Maybe we need to have more discussion
and improve the wording.
Regards
Guogang Huang
发件人: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
发送时间: 2026年7月15日 20:18
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; Pooya Monajemi <p_monajemi@xxxxxxxxx>
抄送: stds-802-11-tgbn@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Please review - the last few seamless roaming CIDs
Hi Guogang,
Thanks for the discussion. If we remove the "from the DS" part, does that mean if there are forwarded DL packets to the target AP MLD, the
target AP MLD cannot transmit those MSDUs/A-MSUDs until the target receives the Notify drain termination?
Thanks,
Duncan
WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
Hi Pooya,
I’m not sure. What do you think about the following text?
"NOTE1 — 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."
"NOTE2 — 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 rolled-over and within the non-AP STA's block ack window, in which case the current
AP MLD needs to inform the target AP not to transmit the new MSDUs/A-MSDUs 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."
Regards
Guogang Huang
Hi Guogang, thanks for the explanation. We should be able to add a clarification to handle the rollover case, do you have any suggestion for the text
Thanks
Pooya
On Jul 14, 2026, at 10:54 AM, huangguogang <huangguogang1@xxxxxxxxxx>
wrote:
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.
<image001.png>
Regards
Guogang Huang
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
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
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
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
|