
IEEE 802.11be Architecture Discussion
Explore detailed discussions on architecture concepts for IEEE 802.11be TGbe AP MLDs, touching on MAC functions, link-level considerations, and shared MLD functions. The presentation delves into security associations, MPDU encryption/decryption, sequence number assignment, and more, shedding light on the intricate details of AP MLD functionalities.
Uploaded on | 0 Views
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
February 2021 doc.: IEEE 11-20/1639r11 802.11be AP MLD Architecture Discussion Date: 2021-01-13 Authors: Name Mark Hamilton Affiliations Address Ruckus/CommS cope Phone +1-303-818-8472 email mark.hamilton@commsco pe.com 350 W. Java Dr Sunnyvale, CA 94089 Sli de 1 Submission Slide 1 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Abstract This presentation considers architecture concepts for TGbe AP MLDs. This follows ideas in presentations in the ARC SC sessions leading up to and during the Nov plenary session, Jan plenary session, and teleconferences. Sli de 2 Submission Slide 2 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 (U) (C) Need to sort out the functions within an AP MLD which are MLD and which are AP(s) IEEE 802.1X Controlled and Uncontrolled Port Filtering (optional) (M) RX/TX MSDU Rate Limiting A-MSDU Aggregation (TX) / De-aggregation (RX) PS Defer Queuing (AP or IBSS STA only) (null) MSDU Flow - Transmitting MSDU Flow Receiving Sequence Number Assignment Consider the MAC stack, as shown in 802.11 Figure 5-1: (null) MSDU Integrity and Protection (optional) Fragmentation (TX) / Defragmentation (RX) Packet Number Assignment Replay Detection (optional) Might be useful to ask, Does this function have to be link-specific? and/or Is this function explicitly shared across the links? Initially (in this discussion), ignore legacy AP, only affiliated AP(s) are considered, then add legacy (slide 18) SYNRA Receiver Filtering (null) Block Ack Buffering and Reordering (null) MPDU Encryption (TX) / Decryption (RX) and Integrity (optional) Duplicate Detection (null) Sli de 3 Block Ack Scoreboarding (null) Address 1 address filtering (null) MPDU Header + CRC Creation (TX) / Validation (RX) A-MPDU Aggregation (TX) / De-aggregation (RX) Submission Slide 3 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 MLD-level , or per-AP/link-level - 1 All the figures/discussion presented in discussion so far have had some concept of some MAC functions that are per-link and lower in the stack, and some MAC functions that are shared across the links at MLD level and shown higher in the stack. A proposed split/allocation of some MAC functions (on this and following slides): - MLD (shared state across all links/can use any available link): - Security Association/state; PN space [Motion 111 #SP0611-29] - 802.11be supports that after multi-link setup between two MLDs, the same PMK and the same PTK across links are used with the same PN space for a PTKSA. - Therefore, MPDU Encryption/Decryption, is a shared MLD function. (Note: see 11- 20/1240, this does NOT mean an implementation is prevented from having parallel blocks.) - Sequence Number assignment; Receive reordering buffer [Motion 62] - For each block ack agreement, there exists one receive reordering buffer based on MPDUs in the MLD which is the recipient of the QoS Data frames for that block ack agreement. The receive reordering buffer operation is based on the Sequence Number space that is shared between the two MLDs. - Note that this implies PS buffering (of individually addressed frames, at least) is a shared MLD function, in order to maintain SN ordering. Sli de 4 Submission Slide 4 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 MLD-level , or per-AP/link-level - 2 Retransmission discussion: - Motion 61: - The established block ack agreement allows the QoS Data frames of the TID, aggregated within the A- MPDUs, to be exchanged between the two MLDs on any available link. - NOTE QoS Data frames that are not fragments might be retransmitted on any available link. - Motion 61 is from 11-20/0434r3 - 11-20/0434r3 goes on, with a second Straw Poll, which was never run: - The MLD MAC address of the recipient MLD is used as the A1 field for the AAD construction. - The MLD MAC address of the transmitting MLD is used as the A2 field for the AAD and Nonce construction. - If the Address 3 field of the protected frame carries the BSSID, the MLD MAC Address of the AP MLD is used as the A3 field for the AAD construction. Otherwise, the Address 3 field of the protected frame is used. - If the above (second Straw Poll) is accepted, Retransmission on any link just works , without any discussion of MLD level or per-link level retransmission. - If the above is not accepted, retransmission behavior on any available link needs to be defined. There is nothing in the SFD or D0.1 describing this, so far. Sli de 5 Is this all TBD in TGbe, still? - Submission Slide 5 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 MLD-level , or per-AP/link-level - 3 Implementation choice (explicitly), of MLD shared or per-link: - Block-Ack scoreboarding [Motion 63. Motion 114. (Motion 112.) ] - The receive status of QoS Data frames of a TID received on a link shall be signaled on the same link and may be signaled on other available link(s). - 802.11be shall define mechanism for multi-link operation that enables the following: A STA of a recipient MLD shall provide receive status for MPDUs received on the link that it is operating on and may provide (if available) information on successful reception of MPDUs received by another STA of that MLD. - ( An originator MLD of a BA agreement: 1) shall update the receive status for an MPDU corresponding to the BA agreement if the received status indicates successful reception. 2) shall not update the receive status for an MPDU corresponding to the BA agreement that has been already positively acknowledged. ) - Sli de 6 Submission Slide 6 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 MLD-level , or per-AP/link-level - 4 Per-link functions: - CCA, backoff, NAV, etc. (although there may be timing alignment done across the links, which puts restrictions on the EDCA access) [Motion 20] - Each of STAs belonging to a MLD performs a channel access over their links independently in order to transmit frames. - A-MPDU aggregation/de-aggregation [I m just assuming, since this is such a low-level function] - Address 1 matching [Allows per-link MAC address; allows per-link scoreboarding. Although, maybe this should be in the Implementation choice category?] - Group addressed frame transmission - After multi-link setup between two MLDs, different GTK/IGTK/BIGTK in different links with different PN spaces are used. GTK/IGTK/BIGTK in different links can be delivered in one 4- way handshake. [Motion 71] - 802.11be agrees that each AP in an AP MLD shall independently transmit all bufferable group addressed Management frames after every DTIM beacon in R1. [Motion 131 #SP206] - No agreement on group addressed data frames (but see 11-20/0661 for discussion of options) - Sli de 7 Submission Slide 7 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Implications Implications: - MLD: - 802.1X controlled/uncontrolled filtering [Done at the MAC SAP] - RX/TX MSDU rate limiting [Done at the MAC SAP] - A-MSDU aggregation/deaggregation [Must be done above encryption and reordering buffer] - ( bufferable unicast MMPDUs need to inject into the stack here, so Action frames??) - PS Defer Queuing (of unicast frames as discussed on slide 4) - what about different PS state on different links?? (_all_ doze => buffer; _any_ active => don t buffer) - Management frames like Authentication/Association/Reassociation Request/Response [Must be above SN assignment] - Sequence Number assignment (per slide 4) - Replay detection on RX [Matches PN assignment on TX] - MPDU Encryption/Decryption (as discussed on slide 4) - Duplicate Detection [Goes with receive reordering buffer] - Per-link: - Control frames (RTS/CTS, Acks, NDP, etc.) - Management frames: Beacon generation, Probe Request/Response - MPDU header creation/validation actual header , not masked header /AAD for integrity? Sli de 8 Submission Slide 8 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 (U) (C) IEEE 802.1X Controlled and Uncontrolled Port Filtering (optional) (M) So, something like: RX/TX MSDU Rate Limiting A-MSDU Aggregation (TX) / De-aggregation (RX) PS Defer Queuing (AP or IBSS STA only) (null) Sequence Number Assignment (null) MSDU Integrity and Protection (optional) MLD-level Fragmentation (TX) / Defragmentation (RX) Packet Number Assignment Replay Detection (optional) SYNRA Receiver Filtering (null) Block Ack Buffering and Reordering (null) MPDU Encryption (TX) / Decryption (RX) and Integrity (optional) Duplicate Detection (null) Sli de 9 Implementation choice Block Ack Scoreboarding (null) Address 1 address filtering Address 1 address filtering (null) (null) . . . MPDU Header + CRC Creation (TX) / Validation (RX) MPDU Header + CRC Creation (TX) / Validation (RX) Per-link-level A-MPDU A-MPDU Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) Submission Slide 9 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Data plane/management plane Note that Figure 5-1 is really just a data plane view. But, we are considering some management plane traffic/functions. It would be helpful to clarify with a diagram that shows management functions. Many years ago (2008), the ARC SC started work on an overall architecture picture that combines data and management (and some control) functions. See 11-08/949 and 11-08/1298. That ARC work was intended to be relatively comprehensive, and therefore got complicated (and never finished). We can try something simpler for 11be purposes (next slide). Sli de 10 Submission Slide 10 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 (U) (C) IEEE 802.1X Controlled and Uncontrolled Port Filtering (optional) (M) TX Action frames RX Action frames RX/TX MSDU Rate Limiting A-MSDU Aggregation (TX) / De-aggregation (RX) RX Assoc, etc frames TX Assoc, etc frames PS Defer Queuing (AP or IBSS STA only) (null) Sequence Number Assignment (null) MSDU Integrity and Protection (optional) MLD-level Fragmentation (TX) / Defragmentation (RX) Packet Number Assignment Replay Detection (optional) SYNRA Receiver Filtering (null) Block Ack Buffering and Reordering (null) MPDU Encryption (TX) / Decryption (RX) and Integrity (optional) (null) Duplicate Detection Implementation choice Block Ack Scoreboarding (null) Beacons, Probe Req/Resp; and Control frames (RTS/CTS, Ack, NDP, etc) Beacons, Probe Req/Resp; and Control frames (RTS/CTS, Ack, NDP, etc) Sequence Number Assignment Sequence Number Assignment (null) (null) PMF and BIP Protection (optional) PMF and BIP Protection (optional) Sli de 11 Creation (TX) / Validation (RX) Packet Number Assignment Replay Detection (optional) Packet Number Assignment Replay Detection (optional) Per-link-level (null) Duplicate Detection (null) Duplicate Detection Address 1 address filtering Address 1 address filtering (null) (null) . . . MPDU Header + CRC Creation (TX) / Validation (RX) MPDU Header + CRC A-MPDU A-MPDU Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) Submission Slide 11 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Let s simplify a bit: TX Action frames RX Action frames RX Assoc, etc frames TX Assoc, etc frames Data frames RX flow TX flow MLD-level Assoc, etc and Action frames Upper MLD MAC Implementation choice Block Ack Scoreboarding (null) Beacons, etc. and CTL, etc. frames Beacons, Probe Req/Resp; and Control frames (RTS/CTS, Ack, NDP, etc) Beacons, Probe Req/Resp; and Control frames (RTS/CTS, Ack, NDP, etc) Beacons, etc. and CTL, etc. frames Impl. choice Upper local mgmt MAC Upper local mgmt MAC flow TX flow TX flow flow RX RX Per-link-level Sli de 12 Address 1 address filtering Address 1 address filtering . . . (null) (null) Lower MAC, and PHY Lower MAC, and PHY . . . MPDU Header + CRC Creation (TX) / Validation (RX) MPDU Header + CRC Creation (TX) / Validation (RX) A-MPDU A-MPDU Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) Submission Slide 12 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Note that, within any AP (legacy or AP MLD), there is a conceptual table, of peer non-AP STAs: State Other info STA1 State 1 (unauth) Data rates, HT capabilities, VHT capabilities STA2 (VHT) State 4 (RSNA) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, etc., etc. STA3 (HT) State 4 (RSNA) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, etc., etc. STA4 (VHT) State 3 (Assoc, not RSNA) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, etc., etc. STA5 (VHT) State 4 (RSNA) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, etc., etc. Sli de 13 STA n (VHT) State 2 (auth, not assoc) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, etc., etc. Submission Slide 13 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Consider adding a little info to the table: - Is the peer MLD/MLO? - If yes, which links are connected; which links are enabled; NSTR/STR/Single Radio, etc. - If no, what is the legacy state for each link (since they can be different) State Other info STA1 State 1 (unauth) Data rates, HT capabilities, VHT capabilities STA2 (EHT) State 4 (RSNA) Data rates, PS state(per link?), RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, MLO(STR, link1(E), link2(D), etc.), etc., etc. STA3 (HT) State 4 (RSNA) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, etc., etc. STA4 (EHT) State 3 (Assoc, not RSNA) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, MLO(Single radio, link1(E), link2(D), etc.), etc., etc. Sli de 14 STA5 (VHT) State 4 (RSNA) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, not MLO(link1), etc., etc. STA6 (VHT) State 4 (RSNA), doing re- association (w/FT) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, not MLO(link1 associated, link2 authenticated(FT state1)), etc., etc. STA n (EHT) State 2 (auth, not assoc) Data rates, PS state, RSNA info, HT capabilities, VHT capabilities, FILS info, SN, PN, Block Ack agreements, MSCS agreement, TFS agreement, MLO(NSTR, link1(E), link2(D), link3(D), etc.), etc., etc. Submission Slide 14 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 So, we have a small database, shared and accessible by the MAC components: Data frames Assoc, etc and Action frames Peer STA database Upper MLD MAC Beacons, etc. and CTL, etc. frames Beacons, etc. and CTL, etc. frames Impl. choice Sli de 15 . . . Upper local mgmt MAC Upper local mgmt MAC Lower MAC, and PHY Lower MAC, and PHY Submission Slide 15 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Data frames Now consider the BSS(s). Each Beaconing component ( AP ?), on each link, would traditionally be considered to create its own BSS: Assoc, etc and Action frames Peer STA database Upper MLD MAC Beacons, etc. and CTL, etc. frames Beacons, etc. and CTL, etc. frames Impl. choice Upper local mgmt MAC Upper local mgmt MAC . . . Lower MAC, and PHY Lower MAC, and PHY Sli de 16 Link 1 BSS Link 2 BSS Submission Slide 16 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 But, a non-AP MLD associates (we ll call it for now) to the AP MLD as a whole, establishing multiple links. And, both devices use any of the links equivalently single security, PN/SN, etc. (per earlier slides). So, the multiple links act like a single logical multi-link ? BSS, for MLO non-AP MLDs that are associated. Data frames Assoc, etc and Action frames Peer STA database Upper MLD MAC Beacons, etc. and CTL, etc. frames Beacons, etc. and CTL, etc. frames Impl. choice Upper local mgmt MAC Upper local mgmt MAC . . . Lower MAC, and PHY Lower MAC, and PHY Sli de 17 Note that some non-AP MLDs may have different (subsets) of the links. But, all non-AP MLDs share a PN/SN, etc., context. [Logical] [Multi-link] BSS Link 1 BSS Link 2 BSS Submission Slide 17 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Legacy AP behaviors alternative 1 1) Keep legacy behavior separate, within a physical device: Data frames Data frames Assoc, etc and Action frames Assoc, etc and Action frames Peer STA database Upper MLD MAC Peer STA database Upper MLD MAC Beacons, etc. and CTL, etc. frames Beacons, etc. and CTL, etc. frames Beacons, etc. and CTL, etc. frames Impl. choice Upper local mgmt MAC Upper local mgmt MAC Sli de 18 PHY . . . Lower MAC, and PHY Lower MAC, and PHY Legacy BSS [Logical] [Multi-link] BSS Link 1 BSS Link 2 BSS Submission Slide 18 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Legacy AP behaviors alternative 1 2) Could share the PHY, like baseline MM-SME see Figure 4-27: 802.1X 802.1X 802.1X MM- SME SME STA 1 SME STA 2 SME STA n MAC 1 SAP MAC 2 SAP MAC n SAP MAC Sublayer Management Entity MAC Sublayer Management Entity MAC Sublayer Management Entity MAC Sublayer MAC Sublayer MAC Sublayer PHY SAP MLME-PLME SAP PLME SAP PHY Sli de 19 3) But, need to sort out the data plane at the top of stack. Similar to current multiple (logical) AP device separate ESS and DS? Multiple Beacons, etc., for each BSS, on each medium 4) Submission Slide 19 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Legacy AP behaviors alternative 2 1) First, note that the AP MLD is handling associations from multiple non-AP STAs/MLDs. a) This implies, for example, multiple PTKSAs, PS buffers/queues, etc. b) Thus, we can think of the MLD AP as being multi-theaded in the sense that it is capable of managing an array of state information, one entry per peer non-AP STA/MLD What does adding legacy AP behavior change in this picture? a) Add 1 bit of state, for each non-AP STA/MLD: Is it a legacy STA or an MLD? b) Stack layers treat the (small) differences between the two, on a case-by- case basis as the functions are accomplished. c) Thus, there is no need for a separate stack/architectural concept to support the legacy interop behaviors. 2) Sli de 20 Submission Slide 20 Mark Hamilton, Ruckus/CommScope
February 2021 Legacy AP behaviors evolution and status doc.: IEEE 11-20/1639r11 1) From the discussion on November 16 telecon, started with the figure on slide 18, then: a) Realized that a goal of 11be (and current direction in SFD/motions) is to have a single PHY for both legacy and the component of the MLD that is on the same band/channel. So, modified the figure to share the PHY (similar to slide 19). b) Next step was to realize/agree that there is only one Beacon, shared between legacy and the MLD component. And, other low-level MAC functions that are link-specific are also shared. Modified the figure to show this sharing shared the Lower MAC and PHY function. 2) See next slide for current figure/status Sli de 21 Submission Slide 21 Mark Hamilton, Ruckus/CommScope
February 2021 With legacy added, WIP figure: doc.: IEEE 11-20/1639r11 Data frames Data frames Assoc, etc and Action frames Assoc, etc and Action frames Peer STA database Upper MLD MAC (multiple peer STAs) Upper legacy MAC Legacy Peer STA Database? Beacons, etc. and CTL, etc. frames Beacons, etc. and CTL, etc. frames Impl. choice Upper local mgmt MAC Upper local mgmt MAC Sli de 22 . . . Lower MAC, and PHY Lower MAC, and PHY Legacy/Link 1 BSS Link 2 BSS Submission Slide 22 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Legacy AP behaviors discussion What is left in the Upper legacy MAC component? a) Note that for the MLD components, the Management, etc., functions that are unique per-link are already pulled out, to the side per the prior discussions on the W shaped MLD figure. b) It seems that all the matching legacy functions are also handled in this component. c) So, the remainder of the Upper legacy MAC component are data plane, and higher-level management (Auth/Assoc, Action frames, etc.). d) This is very similar to the Upper MLD MAC functions e) The Upper MLD MAC component already has many behaviors that are per-peer, based on the peer s capabilities and state. f) So, are the legacy behaviors anything more than an extension of the per- peer state and behavior already built-in to the Upper MLD MAC? If not, consider combining the legacy support into the Upper MLD MAC. Sli de 23 Submission Slide 23 Mark Hamilton, Ruckus/CommScope
February 2021 With legacy added, first alternative (Alternative1): doc.: IEEE 11-20/1639r11 Data frames Assoc, etc and Action frames Peer STA Database (including legacy) Upper MLD MAC (multiple peer STAs, Including legacy peer STAs) Beacons, etc. and CTL, etc. frames Beacons, etc. and CTL, etc. frames Impl. choice Upper local mgmt MAC (including legacy) Upper local mgmt MAC Sli de 24 . . . Lower MAC, and PHY (including legacy) Lower MAC, and PHY Legacy/Link 1 BSS Link 2 BSS Submission Slide 24 Mark Hamilton, Ruckus/CommScope
February 2021 With legacy added, alternative from Dec 7 (Alt2): frames doc.: IEEE 11-20/1639r11 MLO Data MLO Assoc, etc and some Action frames Legacy Data frames Peer STA Database (including legacy) Legacy Data frames Upper MLD MAC (MLD peer STAs) Beacons, Probe Responses etc., legacy Assoc, etc., some Action frames, and CTL, etc. frames Upper legacy & mgmt MAC (legacy peer STAs and broadcast mgmt) Upper legacy & mgmt MAC (legacy peer STAs and broadcast mgmt) Beacons, Probe Responses etc., legacy Assoc, etc., some Action frames, and CTL, etc. frames Impl. choice Sli de 25 Lower MAC, and PHY (MLO and legacy) . . . Lower MAC, and PHY (MLO and legacy) Link 1 BSS Link 2 BSS Mixed Mixed (MLO & legacy) Submission Slide 25 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Alternative 2: Revisit stack operations and how they are split: (U) (C) (U) (C) (U) (C) IEEE 802.1X IEEE 802.1X IEEE 802.1X Controlled and Uncontrolled Port Filtering (optional) (M) Controlled and Uncontrolled Port Filtering (optional) (M) TX Action frames Controlled and Uncontrolled Port Filtering (optional) (M) RX Action frames RX/TX MSDU Rate Limiting RX/TX MSDU Rate Limiting RX/TX MSDU Rate Limiting Beacons, Probe Req/Resp; and Control frames (RTS/CTS, Ack, NDP, etc) Beacons, Probe Req/Resp; and Control frames (RTS/CTS, Ack, NDP, etc) A-MSDU A-MSDU A-MSDU Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) RX Assoc, etc frames TX Assoc, etc frames PS Defer Queuing (AP or IBSS STA only) PS Defer Queuing (AP or IBSS STA only) PS Defer Queuing (AP or IBSS STA only) (null) (null) (null) Sequence Number Assignment Sequence Number Assignment Sequence Number Assignment (null) (null) (null) MSDU Integrity and Protection (optional) ? MSDU Integrity and Protection (optional) ? MSDU Integrity and Protection (optional) Fragmentation (TX) / Defragmentation (RX) Fragmentation (TX) / Defragmentation (RX) Fragmentation (TX) / Defragmentation (RX) Packet Number Assignment Replay Detection (optional) Packet Number Assignment Replay Detection (optional) Packet Number Assignment Replay Detection (optional) SYNRA Receiver Filtering SYNRA Receiver Filtering SYNRA Receiver Filtering (null) (null) (null) Block Ack Buffering and Reordering Block Ack Buffering and Reordering Block Ack Buffering and Reordering (null) (null) (null) MPDU MPDU MPDU Encryption (TX) / Decryption (RX) and Integrity (optional) Encryption (TX) / Decryption (RX) and Integrity (optional) Encryption (TX) / Decryption (RX) and Integrity (optional) (null) Duplicate Detection (null) Duplicate Detection (null) Duplicate Detection Block Ack Scoreboarding Block Ack Scoreboarding Block Ack Scoreboarding (null) (null) (null) Address 1 address filtering Address 1 address filtering (null) (null) . . . MPDU Header + CRC Creation (TX) / Validation (RX) MPDU Header + CRC Creation (TX) / Validation (RX) Sli de 26 A-MPDU A-MPDU Aggregation (TX) / De-aggregation (RX) Aggregation (TX) / De-aggregation (RX) Submission Slide 26 Mark Hamilton, Ruckus/CommScope
February 2021 Analysis of alternatives what is where; what is different? Alternative 1 doc.: IEEE 11-20/1639r11 Alternative 2 Security SAs/Keys (In MLO, agreement, there is 1 PTK/PMK per MLD-MLD (P2P) association , managed by MLD stack) (GTKs are distributed via MLD-MLD association) PTK/PMK: Per peer, all in MLD GTK, IGTK, BIGTK: in each legacy stack PTK/PMK: - MLO: PTK/PMK in MLD stack; - Legacy: legacy stack s PTK/PMK; GTK, IGTK, BIGTK: in each legacy stack (Re)(Dis)Association, (De)Authentication All go to MLD stack Split based on Address1 (or MLO indication?) Authenticator(s) 1 1 per legacy + 1 for MLD * Needs discussion about implications on counts Sli de 27 Submission Slide 27 Mark Hamilton, Ruckus/CommScope
February 2021 Analysis of alternatives what is where; what is different? Alternative 1 doc.: IEEE 11-20/1639r11 Alternative 2 Address1 filter/RX frame routing The value of the RA/TA fields sent over-the-air in the MAC header of a frame is the MAC address of the STA affiliated with the MLD corresponding to that link. [Motion 108, [30] and [186]] All data frames -> MLD; All Auth/Assoc based -> MLD; Most Mgmt -> MLD (?) Any Mgmt -> legacy?? (maybe only Control frames?) Can we arrange a clean Address1 split? (Only MLO peers will know the MLD address?) SAP(s) 1 * MLD is responsible for routing 1 MLO, 1 per legacy * DS is responsible for routing * Need to work through MSDU flow(s) through APs/DS/Portal Sli de 28 Submission Slide 28 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 AP Data plane (Alt 2, simplified) Legacy Data frames MLO Data frames Legacy Data frames Upper legacy & mgmt MAC (legacy peer STAs and broadcast mgmt) Upper legacy & mgmt MAC (legacy peer STAs and broadcast mgmt) Upper MLD MAC (MLD peer STAs) But, how can the Lower MACs know how to route incoming frames? Impl. choice . . . Sli de 29 Lower MAC, and PHY (MLO and legacy) Lower MAC, and PHY (MLO and legacy) Link 1 BSS Link 2 BSS Mixed Mixed (MLO & legacy) Submission Slide 29 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 AP Data plane discussion Consider an alternate view, for MLO: - Frames are received at the Lower MAC, relatively arbitrarily (based on the link the TXer chose) - For MLD/MLO peers, the two stacks share state (with implementation magic ) for all the per-peer attributes that are needed, but either one can process an incoming frame, using that shared state - So, the Lower MAC doesn t need to route incoming frames, they just always go to the matching Upper MAC - Upper MACs can direct transmitted frames into either Lower MAC - (Power save and EDCA queuing FFS, on TX) Sli de 30 Submission Slide 30 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 AP Data plane no MLD stack MAC SAP for MLO Data Frames ??? MAC SAP (Legacy Data Frames) MAC SAP (Legacy Data Frames) Upper legacy & mgmt MAC (legacy peer STAs and broadcast mgmt) Upper legacy & mgmt MAC (legacy peer STAs and broadcast mgmt) Shared (for MLO peers): - PMK/PTK - BA state - Retry buffers - PS state - GAS/ANQP state - Multi-link state Private (for legacy peers): - ... Private (for legacy peers): - ... The legacy MAC SAP is pretty clear, and (I think) agreed But where is the MAC SAP for MLO peers? . . . Lower MAC, and PHY (MLO and legacy) Lower MAC, and PHY (MLO and legacy) Sli de 31 Link 1 BSS Link 2 BSS Mixed Mixed (MLO & legacy) Submission Slide 31 Mark Hamilton, Ruckus/CommScope
February 2021 Reminder of (legacy) DS structure doc.: IEEE 11-20/1639r11 DSAF DSAF DSAF Mesh MAC PHY Portal MAC MAC MAC MAC PHY MAC DS PHY PHY PHY PHY 802.11 Medium 802.11 Medium 802.11 Medium Non-802.11 Medium Non-AP STAs AP1 Mesh Gate Portal AP2 - DS SAP Maybe it doesn t matter where the MLO MAC SAP is? - Each stack has a MAC SAP, which (on an AP) supports a DSAF - The DS doesn t care (or can be designed/fixed to not care) where uplink frames enter - The DS will route all downlink frames to one of the MAC SAPs (the one that has registered this client (really associated, but that s confusing right now) Sli de 32 Submission Slide 32 Mark Hamilton, Ruckus/CommScope
February 2021 Analysis of alternatives what is where; what is different? Alternative 1 doc.: IEEE 11-20/1639r11 Alternative 2 Beacons; Probes All go to legacy stack All go to legacy stack Robust management frames GAS/ANQP (Pre-Assoc or post- Assoc) ?? ?? QoS queues/retry buffers (includes how to merge TX traffic at the lower MAC boundary) One set, in MLD (but need to merge in mgmt. traffic) Two sets? (With normal co- located BSS contention between them?) Block Ack ?? ?? Sli de 33 MLO channel configuration/modification of operation Submission Slide 33 Mark Hamilton, Ruckus/CommScope
February 2021 Analysis of alternatives what is where; what is different? Alternative 1 doc.: IEEE 11-20/1639r11 Alternative 2 SN and PN (including QMF) Single stack, single spaces as per legacy behavior including across BSSs Number spaces per stack need MLO RXr to keep separate DMS Messy Legacy peer: as today; MLO peer: messy Multiple BSSID sets ?? (Being discussed) Are legacy and MLD stacks separate multiple BSSs ? Any impacts on DS interface? Single SAP Separate SAPs so what (??) What is an ESS/BSS? (In MLO, transitions to/from MLO) Access Controls? Sli de 34 Multi-AP coordination? (Mixed-mode) Mesh? Relays? OCB? TDLS? Submission Slide 34 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Then, consider non-AP peers (MLD or legacy): Upper MLD MAC Legacy non-AP STA Non-AP MLD Upper local mgmt MAC Upper local mgmt MAC . . . . . . Lower MAC, and PHY Lower MAC, and PHY Sli de 35 When interacting with STA a , the peer database tells the AP MLD to enable all the components (blue), and use MLD signaling enhancements Submission Slide 35 Mark Hamilton, Ruckus/CommScope
February 2021 doc.: IEEE 11-20/1639r11 Then, consider non-AP peers (MLD or legacy): Upper MLD MAC Legacy non-AP STA Non-AP MLD Upper local mgmt MAC Upper local mgmt MAC . . . . . . Lower MAC, and PHY Lower MAC, and PHY Sli de 36 When interacting with STA b , the peer database tells the AP MLD to enable only the one link (red), and not use MLD signaling enhancements This can include using legacy behavior for re-association within the link information in the database Submission Slide 36 Mark Hamilton, Ruckus/CommScope