| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Young Hoon, Thanks for providing scenario details and methodology! You raise valid points. Similar to STR capability update possible after ML setup, perhaps STA can inform AP MLD of updated capabilities and avoid resetup with
current AP MLD. Thanks, Sharan From: Young
Hoon Kwon [mailto:younghoon.kwon@xxxxxxx] Hi Sharan, Thanks for the response. In my opinion, the example that mentioned during the call needs to be handled in two separate process. First process is change of link set for a non-AP MLD from 3 links to 2 links. And, second process is initiating a new association on 2.4GHz link, which requires Association Request/Response exchange. Here, the point that the non-AP MLD completely loses its 2.4GHz link as the device’s 2.4GHz link will have separate association. This implies that the non-AP MLD does not support 2.4GHz link in its capability, and in this case, it is not sure if we can still do link disablement
for 2.4GHz. In my understanding, link disablement is a temporarily disable a link even though the a non-AP MLD supports the link. (But of course we didn’t get to an agreement on this yet.) And, in this case Reassociation Request/Response can happen for this process. Thanks, Young Hoon From:
Sharan Naribole <n.sharan@xxxxxxxxxxx>
Hi Young Hoon, Thanks for the clarification! I assumed resetup with same AP MLD meant changing the set of setup links (e.g. removing a link due to out
of coverage). In your below example, I am not sure if it can be considered resetup as establishing separate associations does not retain multi-link
operation. Thanks, Sharan From: Young
Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Sharan, Thank you very much for your comment. I agree with you that if a non-AP MLD just wants to disable a link, it’s better to go through TID-link remapping process instead of resetup/reassociation
process. The reason I mentioned resetup was that the example mentioned was not just disabling a link but instead a non-AP MLD switches from a single multi-link
setup to two separate associations (one association on 2.4GHz, and another association on 5/6GHz). Best, Young Hoon From:
Sharan Naribole <n.sharan@xxxxxxxxxxx>
Hi Young Hoon, Thanks for your contribution! In this case of “resetup” with same AP MLD, the overhead involved in ML teardown and ML resetup including all the agreements would be
significant and is concerning from non-AP point of view. It would be better for non-AP MLD to initiate disabling of that link instead and possibly no “negotiation” overhead in such an update. Thanks, Sharan From: Young
Hoon Kwon [mailto:younghoon.kwon@xxxxxxx]
Hi Tomo, Thank you very much for the clarification! Best regards, Young Hoon From: Tomo Adachi <tomo.adachi@xxxxxxxxxxxxx>
Caution: EXT Email
Hi all, There was a question during Q&A on 20/386 whether BA agreements are valid and no re-setup is required after reassociation.
In REVmd D3.0, 11.3.5.4, it says the following:
If the MLME-REASSOCIATION.request primitive has the new AP’s or PCP’s(#2582)
MAC address in the CurrentAPAddress parameter (reassociation to the same AP or PCP(#2582)),
the following states, agreements and allocations shall be deleted or reset to initial values: 1) All EDCAF state 2) Any block ack agreements that are not GCR agreements(#2228) … Best regards, tomo 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 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 |