Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] Reassociation

Hi Young-Hoon, 
In the SP2, can we also include the scenario to send a Reassociation Request frame to a new AP as the following?

When a non-AP MLD that has multi-link setup with current AP MLD sends a Reassociation Request frame to either a new AP or a new AP MLD, AP MLD MAC address of the current AP MLD is used in Current AP Address field of the frame.

Thanks, 
Yongho 

2020년 6월 5일 (금) 오전 11:19, Sharan Naribole <n.sharan@xxxxxxxxxxx>님이 작성:

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]
Sent: Friday, June 5, 2020 10:50 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] Reassociation

 

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>
Sent: Friday, June 5, 2020 9:49 AM
To: Young Hoon Kwon <younghoon.kwon@xxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] [STDS-802-11-TGBE] Reassociation

 

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]
Sent: Thursday, June 4, 2020 11:07 PM
To: Sharan Naribole <n.sharan@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] [STDS-802-11-TGBE] Reassociation

 

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>
Sent: Thursday, June 4, 2020 8:33 PM
To: Young Hoon Kwon <younghoon.kwon@xxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [EXT] [STDS-802-11-TGBE] Reassociation

 

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]
Sent: Thursday, June 4, 2020 8:21 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [EXT] [STDS-802-11-TGBE] Reassociation

 

Hi Tomo,

 

Thank you very much for the clarification!

 

Best regards,

Young Hoon

 

From: Tomo Adachi <tomo.adachi@xxxxxxxxxxxxx>
Sent: Thursday, June 4, 2020 7:42 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [EXT] [STDS-802-11-TGBE] Reassociation

 

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

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