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