| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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. 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 |