| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Guogang, Thanks for your feedback. State 4b is to allow the DS mapping update to be performed by the network as soon as possible to avoid further DL data from the DS directed to the current AP MLD whose links are likely deteriorating. Any UL
data to the current AP MLD after the ST execution request will delay and undo the DS mapping update, which will delay the whole ST execution. Therefore the UL data shall be suspended after the ST execution request. Re 5017, the design of the non-AP MLD to send a UHR Reconfig Notify frame has always been a best-effort “goodbye” from the non-AP MLD to the current AP MLD. That allows the current AP MLD to clean up its states
earlier (than an implementation timeout or backhaul indication from the target AP MLD). Given that the links to the current AP MLD are likely deteriorating at this stage, we do not want to mandate the non-AP MLD to stay with the current AP MLD just to send
this Notify frame, which will delay roaming to the target. That’s why we ended up with a “should” requirement to leave it up to non-AP MLD’s discretion whether to send this Notify frame. Given that this is a best-effort frame to begin with and given we already have defined this Notify frame, I do not see a need for defining yet another way to indicate the same in a best-effort manner. Thanks, Duncan From: huangguogang <000017b1384624cd-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 Duncan and all, Thanks for preparing this CR document. For this CR document, I have two main concerns. Firstly, we don’t think it’s over-designed to introduce State 4b, which will complicate the state machine
and the benefit is very limited. The non-AP MLD can take the time needed for the DS mapping change into account and initiate the transmission of the ST execution request a little bit in advance. I’m not convinced of the argument the
current AP MLD shall immediately initiate the DS mapping change when it receives the ST execution request, otherwise the DL data keep going to the current AP MLD and the current AP MLD cannot accurately estimate the Nominal Maximum DL Draining Period Duration.
This estimation is hard to implementation which depends on many factors, e.g. client’s moving speed, channel contention and so on. So I suggest to keep the state machine simple and the non-AP MLD suspends the UL data transmission
only when it receives the ST execution response with SUCCESS. After the UL data is totally delivered to the DS, then the current AP MLD initiates the DS mapping change.
Secondly, for the resolution to CID 5017, we should allow the non-AP MLD as a TXOP responder can timely terminate the DL draining period through a new feedback
type carried within the M-BA frame even it is participating the DL reception. Please find the details attached. It can effectively avoid the following case: the current AP MLD forwards A-MSDUs which are needed for retransmission resulted from the poor link
quality of the current AP MLD. As I mentioned in my contribution, The A-MSDU forwarding is hard to realize. Then lots of data packets will be lost during the SMD BSS transition. In this case, how can we call it as seamless roaming? So the non-AP MLD tends
to terminate the DL draining period when there is no “hole” in the reordering buffer if the data forwarding is supported.
All - please review changes proposed in the attached and I would like to discuss integrating these changes in one combined doc. Regards Guogang Huang 发件人:
Duncan Ho <dho@xxxxxxxxxxxxxxxx> Hi Gougang and seamless roaming TTT members, Guogang, let’s discuss in person and I’ll explain further. In the meantime, I’ve updated Figure 11-23 per your request. Seamless roaming TTT members, any feedback on the attached is welcome. I’m in Victoria and I’ll be happy to discuss with you in person as well. 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 your response. Please find my response inline. Regards Guogang Huang 发件人:
Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Guogang, Thanks for your comment. Please see my responses inline below. 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. One question regarding when to suspend the UL data transmission, I think the following two sentences are conflicted or
misaligned with each other. We should define that the non-AP MLD shall not transmit any Data frames to the current AP MLD upon successful reception of the ST execution response with the Status Code field set to SUCCESS if the SMD Type field in the SMD Capabilities
field in the SMD Information element (see 9.4.2.356 (SMD Information element)) is equal to 0.
[DH] If we follow the above, the UL suspension would be too late. Since the DS mapping may be updated anytime between the ST execution request and ST execution response, if we allow
UL to the current AP MLD this time, any UL packets forwarded to the DS from the current AP MLD will undo the DS mapping update and the DS will point back to the current AP MLD. [HGG]I agree that the UL transmission shall be suspended first. After that, the current AP MLD informs the target AP MLD to update the DS mapping
and initiates the dynamic context transfer. For simplicity, we should define as the above mentioned. I don’t see any issue. (#5017)Upon successful transmission of the ST execution request, the non-AP MLD shall not transmit any Class 3 frames to the current AP MLD if
the SMD Type field in the SMD Capabilities field in the SMD Information element (see 9.4.2.356 (SMD Information element)) is equal to 0. [DH] This condition should be correct, per my explanation above. [HGG]It’s a little over-design. Before receiving ST execution response with SUCCESS, the non-AP MLD keeps in state 4
with the current AP MLD. Considering this, the non-AP MLD should be allowed to exchange data with the current AP MLD, regardless of the DL data or the UP link. Please update Figure 11-23—Relationship between state and services between
a given pair of nonmesh STAs to accommodate SMD transition. (#5017)Upon reception of an ST execution response frame with the Status Code field not set to SUCCESS from the target AP MLD, all Class 3 frames
shall be allowed between the current AP MLD and the non-AP MLD. [DH] This is the case when the non-AP MLD receives an ST execution response with some kind of failure (i.e., ST failed), we allow the non-AP MLD to resume UL tx with its current
AP MLD. Thanks, Duncan Regards Guogang Huang 发件人:
Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Dear Seamless Roaming TTT members, I’ve drafted this CR to address the UL data suspension and MLD state change. Could you please review it and let me know if you have any feedback? Hope to see you in Victoria! BR, 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
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 |