| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi yonggang,
Thanks for your discussion. Please see my response inline. Regards Guogang Huang Huawei Technologies Co.,Ltd. 发件人: yfang@xxxxxxxxx [mailto:yfang@xxxxxxxxx]
Hi Guogang , and all: Thanks for the presentation and initiating the email discussion.
As I said in the meeting, make-before-break is an interesting topic and a valid use case, especially for MLO in the roaming case. The issues are 1)
In the current ML operation model, the association is in MLD level between a non-AP MLD and an AP MLD . Tentative (Re)Association may involve two AP MLDs
. [Guogang Huang] Yes, I agree that the association is in MLD level between a non-AP MLD and an AP MLD. And I also agree that the non-AP MLD
only can associate with only one AP MLD. The reason is that DS needs to determine a unique answer to the question, “Which AP is serving STA X?”. In the 11 Spec., the DS-STA_Notify.request primitive is used to provide this unique answer. In our proposed tentative
association, before new AP MLD sending DS-STA_Notify.request primitive, the non-AP MLD still associate with the old AP MLD. Only when new AP MLD sending DS-STA_Notify.request primitive to DS, then the non-AP MLD will completely associate with the new AP MLD.
Though non-AP MLD and AP MLD successfully exchange Association Request/Response between with Status Code Success, it doesn’t mean that the non-AP MLD have associate with the AP MLD completely. Only after new AP sending DS-STA_Notify.request primitive to DS
to update the routing info, the association is completely finished. As long as the answer to “Which AP is serving STA X?” is unique, the corresponding association relationship is unique.
2)
In 11be, there is another feature in development, i.e. multi-AP. We needs to consider that AP MLD could be the "AP" in multi-AP in the future, i.e. forming
a multi-AP MLD network. [Guogang Huang] What you mean is non-collated MLD, right? The proposed scheme doesn’t need to setup a non-collocated AP MLD.
Therefore from the ML architecture reference model, it is better to consider AP MLD and multi-AP together, and this use case could be addressed naturally. Best Regards Yonggang Fang ZTE (TX)
Original Mail Sender: huangguogang <huangguogang
1@xxxxxxxxxx> Date: 2020/07/23 19:35 Subject: [STDS-802-11-TGBE] Discussion on 834r6 Tentative (Re)Association under MLD framework Hi yonggang , George, Po-kai and all, This is to initiate an email discussion on my presentation 0834r6 Tentative (Re)Association under MLD framework. Maybe I didn’t get your point during the call,
we can continue discussion through email. As a summary, this contribution proposes to allow multi-radio non-AP MLD to do the tentative association. For the tentative association, non-AP MLD will send
a frame to trigger AP MLD sending DS -STA-Notify.request primitive to DS to update the STA-AP routing info.
1.
This is very useful for roaming. Because this can reduce the delay of data delivery introduced by time-sensitive TS setup and BA agreement setup. Thus multiple-radio non-AP MLD can directly transmit data through
multiple links with new AP MLD by using BA manner.
2.
Another benefit is that multiple-radio non-AP MLD can decide the most appropriate time point to switch the data delivery from the old AP MLD to the most appropriate candidate AP MLD
If you have any comments/questions, please feel free to let me know. Thanks, Guogang Huang To unsubscribe from the STDS-802-11-TGBE list, click the following link:https://mentor.ieee.org/802.11/dcn/20/11-20-0834-06-00be-tentative-re-association-for-non-ap-mld.pptx To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |