Re: [STDS-802-11-TGBN] Roaming TTT - Please review 11-25/2366

[Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>]

Thanks a lot Abhi. Generally this looks good (and thanks for all the hard work)... although I have comments on a couple details:

  - Added missing â??shallâ?? to make the non-AP MLD association-with-SMD-ME sentence normative (CID 12309)

It is not clear to me what the revised sentence is trying to say.

Previously it was, to my read, simply declaring that the way to associate with an SMD-ME is through an AP MLD in the SMD.

Now the normative text seems to imply a requirement to do something, but the conditions are unclear. For example, it could be implied:

• The non-AP MLD is not allowed to associate to any other entity than an SMD-ME (which is not correct in general, and I assume is not intended even if the AP MLD is part of an SMD), and/or
• The non-AP MLD must, if it associates with an SMD-ME, do so through an AP MLD of the SMD (which is true, but no need for a normative statement because there is no other mechanism defined by which this could be done anyway)

  - Removed (Re) from the initial association sentence in §37.15.3 to clarify this procedure applies only to initial association, not reassociation (CID 6379)

I don't see any changes tagged with 6379, but note that reassociation will occur when, for example, a non-AP MLD does an FT roam into a (new) SMD. All the procedures we have defined for SMD association also apply when reassociation occurs, so I am not sure why we are removing it.

(By the way, the original comment seems to justify this proposed change on the basis that the text applied to "initial association" to the SMD, but I believe we removed the word "initial" in this context for this very reason)

Related, the text (commented below) on contents of association request/response being included in ML elements should probably refer to "(re)association" so the contents would be that of the reassoc frames in the reassoc case

  - Explicitly specified that the per-STA profile in the Basic MLE of the ST preparation response carries the same content as an Association Response frame  (Complete Profile = "" including BPCC/EBPCC fields and UHR Capabilities/Operation elements

In 37.3.3.5.1.2 (Inheritance from first Per-STA Profile subelement), it is stated this applies to ST Prep Response and ST Exec Response via target (and some other non-ST frames). However:

• In 37.15.6.2 it is stated the per-STA profiles (in Reconfiguration ML element) of an ST Prep Request also use inheritance per the above subclause, so should this also be in the list?
• It seems the motivation to add the per-STA profiles in ST Exec Response via target AP is related to critical updates (per 4894), but (maybe I missed something) it's not clear to me how that issue is addressed if the Exec is done via Current AP MLD (where there are no per-STA profiles present in the response)

One minor note, there is at least one element (MSCS Descriptor) that is specified to be directly included in frame body of ST Prep resp and could also be present in assoc response and hence also included in per-STA profiles.

The usage is slightly different (the frame body version appears if MSCS was transferred, while the profile/assoc one appears if MSCS was re-setup during assoc, which I think, indirectly, is not currently precluded in ST prep). We might need to say something on how those two usages inter-relate. (Maybe also for OCI too in certain cases)

Thanks

Thomas

On May 6, 2026 at 00:40:12, Abhishek Patil <0000297b717f2a04-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Roaming TTT members,

 

I have prepared the following CR doc that is addressing several comments in the roaming subclauses. It is filling in the gaps in the spec + covering aspects that have been discussed offline between the TTT members in the past.

 

https://mentor.ieee.org/802.11/dcn/25/11-25-2366-00-00bn-lb291-cr-for-cids-assigned-to-abhi-37-16-part-2.docx

 

Could you please review and let me know if you have any suggestions to improve the doc?

 

Hereâ??s a high-level summary to help you with your review (you can search for the corresponding changes in the doc based on the CID):

 

  SMD Membership Clarifications (§37.15.1, §37.15.2.1, §37.15.3)

  - Added missing â??shallâ?? to make the non-AP MLD association-with-SMD-ME sentence normative (CID 12309)

  - Added normative text stating a UHR AP MLD that is part of an SMD shall set the Link Reconfiguration Operation Support field to 1, and that no two AP MLDs sharing a co-channel colocated set (multiple BSSID or co-hosted BSSID set) shall be part of the same SMD (CID 12126, 12127)

  - Added a normative rule requiring the transmitted BSSID AP to include the SMD Information element for a nontransmitted BSSID AP (that is part of an SMD) in the Nontransmitted BSSID Profile subelement (CID 12127)

  - Clarified how a non-AP MLD can determine (not merely infer) a colocated AP's SMD affiliation using the Same SMD field and AP MLD ID field of the RNR element; added guidance on using the AP ID field to differentiate colocated APs that do not belong to the same SMD as the reporting AP (CIDs 9566, 6969, 8431, 10064)

  - Updated NOTE 4 to explain that since all SMD AP MLDs share the same ESS/SSID, a non-AP MLD can use the Short SSID field to determine SMD affiliation of non-colocated APs (CID 9567)

  - Removed (Re) from the initial association sentence in §37.15.3 to clarify this procedure applies only to initial association, not reassociation (CID 6379)

 

  Per-STA Profile Inheritance â?? New Subclauses in §35.3.3.5.1 (CIDs 12357, 6362, 5162)

  - Restructured §35.3.3.5.1 into two new subclauses:

      - §35.3.3.5.1.1 â?? Inheritance from frame content: the existing 802.11be inheritance rule (element absent from per-STA profile is inherited from the frame body), scoped to Probe Response, (Re)Association Request/Response frames

      - §35.3.3.5.1.2 â?? Inheritance from first Per-STA Profile subelement: a new rule (borrowed from TGbi) allowing subsequent per-STA profiles to omit elements that are identical to those in the first per-STA profile, applicable to EPP Capabilities frame, UHR Neighboring AP Probe Response, ST preparation response, and ST execution response (via target AP MLD)

  - This enables frame-size optimization when multiple links are prepared/executed simultaneously, which is a key UHR use case

 

  ST Preparation Response â?? Complete Profile Clarification (CIDs 4894, 11963, 12357)

  - Explicitly specified that the per-STA profile in the Basic MLE of the ST preparation response carries the same content as an Association Response frame  (Complete Profile = "" including BPCC/EBPCC fields and UHR Capabilities/Operation elements

  - Added that the AP Removal Time Present field is set to 0 and the STA MAC Address field carries the affiliated non-AP STA's MAC address

 

  ST Execution Response via Target AP MLD â?? Complete Profile + AID (CIDs 12397, 4311, 6050, 4894)

  - Added a new normative paragraph to §37.15.8 specifying that the Basic MLE in the ST execution response carries a per-STA profile with complete profile for each accepted link, with contents matching an Association Response frame (with inheritance per §35.3.3.5.1.2)

  - Specified that the AID field in the per-STA profile carries the same value assigned during ST preparation (from the SMD BSS Transition Parameters element in the ST preparation response)

  - Removed the Reconfiguration Status List field from the ST execution response frame body table â?? per-link accept/reject is now conveyed via the Status Code field in each per-STA profile

 

  Critical Update Notification After ST Preparation â?? New §37.15.6.3.6 (CID 12237)

  - Added a new subclause specifying the structure of the Reconfiguration MLE carried in the ST Update Notification frame (Type=5) for two urgent update types at the target AP MLD:

      - AP removal (Op Type 0): per-STA profile carries the AP Removal Timer field; no STA Profile field

      - Link disablement (Op Type 7): per-STA profile carries the TID-To-Link Mapping element in the STA Profile field

  - Added NOTE 4a to §37.15.8 noting that the UHR Parameters Update element is included in the per-STA profile STA Profile field when the target AP MLD is performing enhanced critical update procedures per §37.30

 

  TTLM Reset After ST Execution (CID 5437)

  - Added normative sentences to both §37.15.7 and §37.15.8 requiring the target AP MLD and non-AP MLD to operate in default TTLM mapping mode after successful ST execution, until replaced by a negotiated TTLM or modified by an advertised TTLM â?? explicitly rejecting the proposal to negotiate TTLM during ST preparation

 

  Single-Radio Non-AP MLD During DL Draining (CID 6106)

  - Added a should sentence to §37.15.10 recommending that the non-AP MLD prioritize reception of DL data from the current AP MLD during the DL draining period; added a NOTE clarifying that a single-radio non-AP MLD can use PS mode to manage frame exchanges with both the current and target AP MLD during this period

 

  Reconfig MLE Cross-References in §9.6.43.2 (CID 12027)

  - Added a paragraph pointing readers to the specific subclauses that describe the Reconfig MLE contents for each use case: ST preparation request (§37.15.6.2), ST execution request via current AP MLD (§37.15.7), ST execution request via target AP MLD (§37.15.8), and OMP request (§37.29).

 

Regards,

Abhi

---

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature