For case c), I would think that target AP would need to check with current AP over backhaul if ST execution was performed with another target AP already.
I would not want to mandate that the target AP, on (direct) reception of an Exec Req, has to check with all other APs in the SMD whether or not the non-AP MLD already completed exec to some other target since it had last connected to the current AP, before it can send the Exec Resp. The target AP should at least have the option to always accept the Exec Req if it has valid prep state with the STA.ThanksThomas
On Apr 13, 2026 at 15:38:17, Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:Hi Duncan, All,
Thanks for the discussion.
I think if a STA receives a failure for ST execution for a) or b) reasons, then it should not try to perform ST execution to the same target AP unless it first prepares that target AP MLD.
So, to avoid the unnecessary network overhead I think it would make sense to add some text for those cases for STA to not try ST execution without first preparing the target AP.
I think in the text both cases should be covered - when ST execution response is received with Status != SUCCESS and when ST execution response is not received. Your revised text above only covers the 2nd case and seems incomplete.
For case c), I would think that target AP would need to check with current AP over backhaul if ST execution was performed with another target AP already. Current AP can be expected to maintain this state information. I think it would be good to add some text to clarify this part.Thanks,BinitaOn Mon, Apr 13, 2026 at 3:26 PM Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:Hi Po-kai,
Thanks for the comment. Since there are different opinions, I’ll propose the following for now:
- Only cover the ST execution response not received case, in which case the non-AP MLD may try the same or different target AP MLD (see (#6146) below)
- For the Status Code != SUCCESS cases, leave it to non-AP MLD implementation to retry with the same or different target AP MLD
In all retry cases, the (trivial) understanding is that the non-AP MLD is going to get the same failure code if the underlying issues are not corrected before an ST execution retry (with same or a different target). Please let me know if you have further feedback.
Thanks,
Duncan
From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Monday, April 13, 2026 1:04 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] CR for seamless roaming Part 3 11-26/378
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi
If the error code is only the following 3 cases, then the reprepare seems to only address (a). I mean (b) means no preparation at all, so there is no reprepared. I am wondering if we really need to have this shall not retry. If we really want to do this, then it seems to me we have to write 3 sentences for 3 cases. Or leave it, and the STA will just get the same error code if the STA has not addressed the issue. Maybe just leave it?
- (a) preparation timed-out (exec via current only)
- (b) target not prepared (exec via current only),
- (c) exec already performed to another target AP (exec via current or target; although it's a bit unclear how target AP is supposed to know this in the latter case...)
Best,
Po-Kai
From: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, April 13, 2026 12:37 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CR for seamless roaming Part 3 11-26/378
Hi Thomas,
Yes, I think “the non-AP MLD doing (new) roam prep with the same target AP and then trying exec again” is already assumed but not explicitly captured.
Amended the logic as follows:
- If the ST execution response is never received, the non-AP MLD may try the same or diff target AP MLD
- If the ST execution response is received but the Status Code field != SUCCESS,
- The non-AP MLD may try a diff prepared target
- The non-AP MLD shall not retry the same target without re-preparing it
Thanks,
Duncan
From: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Sent: Monday, April 13, 2026 12:08 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CR for seamless roaming Part 3 11-26/378
Thanks Duncan
I think the allowed reasons for rejection of Exec Req are:
- (a) preparation timed-out (exec via current only)
- (b) target not prepared (exec via current only),
- (c) exec already performed to another target AP (exec via current or target; although it's a bit unclear how target AP is supposed to know this in the latter case...)
It seems all of those could be resolved by the non-AP MLD doing (new) roam prep with the same target AP and then trying exec again.
So shouldn't that be an option, in addition to trying exec with any other targets that the STA might already have prepped?
Thanks
Thomas
On Apr 13, 2026 at 11:48:39, Duncan Ho <dho@xxxxxxxxxxxxxxxx> wrote:
Hi Thomas,
That’s a good point. Will the following logic work then?
If the ST execution response is never received, the non-AP MLD may try the same or diff target AP MLD
If the ST execution response is received but the Status Code field != SUCCESS, the non-AP may only try a diff target AP MLD
Thanks,
Duncan
From: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Sent: Monday, April 13, 2026 11:36 AM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CR for seamless roaming Part 3 11-26/378
Hi Duncan, Frank
Thanks for this discussion.
What is the implication of this change if, for example, the ST execution response is sent (either by current or target AP) but is never received by the non-AP MLD (until retry limit)?
Does it imply the non-AP STA is not allowed to send an ST exec request targeting the same AP MLD again?
Thanks
Thomas
On Apr 13, 2026 at 11:21:22, Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Frank,
Thanks for your email and explanation. I’ve updated the resolution per your suggestion. Will be reflected in the next revision I upload.
BR,
Duncan
From: Frank Hsu (徐建芳) <frank.hsu@xxxxxxxxxxxx>
Sent: Sunday, April 12, 2026 11:13 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBN] CR for seamless roaming Part 3 11-26/378
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 the contribution.
Regarding CID 6146, since the only condition to make the ST execution successful is that the non-AP MLD successfully receives the ST response with status code SUCCESS, I think the “fails” conditions should not be left to implementation.
My suggestion is as below.
If the attempted (#5984)ST execution fails (#6901)
(e.g., the status code in the ST execution response is not SUCCESS),(i.e., the non-AP MLD fails to receive an ST execution response or receives an ST execution response with a status code other than SUCCESS), the non-AP MLD may attempt (#5984)ST execution with another (#12377)preparedAP MLD that is in the prepared state.
BRs,
Frank
From: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, April 13, 2026 4:18 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CR for seamless roaming Part 3 11-26/378
External email : Please do not click links or open attachments until you have verified the sender or the content.
Hi all,
I just picked up a few more trivial CIDs and added those to R1 (available on mentor now). Please let me know if you have any questions or comments.
Thanks,
Duncan
From: Duncan Ho <00002b3e54cff3e2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, April 10, 2026 7:45 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBN] CR for seamless roaming Part 3 11-26/378
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Dear seamless roaming TTT members,
I’ve prepared and uploaded Part 3 (59 CRs) here https://mentor.ieee.org/802.11/dcn/26/11-26-0378-00-00bn-lb291-cr-for-seamless-roaming-part-3.docx
Currently scheduled for Monday 4/13 presentation. Any feedback is welcome.
Thanks,
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
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