| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |