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
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?
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
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?
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
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)prepared AP MLD that is in the prepared state.
BRs,
Frank
|
|
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
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
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
|