PPDU that follows UnassocUoraBSYM is at least 16 ╬╝s. UnassocUoraBSYM is the OFDM symbol of the PPDU that contains either the last bit of SCH when BCC is used to encode the PSDU or the last coded bit of the LDPC codeword that encodes the last bit of SCH when LDPC is used to encode the PSDU, where SCH is the last User Info field with AID12 subfield equal to 2045." The padding of trigger frame is to allow STA to have sufficient time to prepare TB PPDU with high HE rate. However, unassociated STA only use base rate to transmit management frame. 16us is too much overhead that compromise the efficiency. Remove this paragraph or clarify. CID PP LL Comment Proposed Change Resolution 16250 216 37 "A STA indicates in the Maxi- mum A-MPDU Length Exponent field in its HT Capabilities, VHT Capabilities and HE Capabilities elements the maximum length of the pre-EOF padding that it can receive in an HE PPDU." is not true if the Maximum Length Exponent Extension field is not 0 Change Subclause 10.13.2 to add caveats on the A-MPDU length rules for STAs whose Maximum A-MPDU Length Exponent Extension is non-zero Revised Generally agree with the commenter. What the commenter asks is defined in 27.10.1 TGax editor to make changes in 11-18/2040r2 under CID 16250 10.13.2 A-MPDU length limit rules TGax editor: please change the first paragraph in 10.13.2 as follows: A STA indicates in the Maximum AMPDU Length Exponent field in its HT Capabilities element the maximum AMPDU length that it can receive in an HT PPDU. A STA indicates in the Maximum A-MPDU Length Exponent field in its VHT Capabilities element the maximum length of the A-MPDU pre-EOF padding that it can receive in a VHT PPDU. A DMG STA indicates in the Maximum A-MPDU Length Exponent field in its DMG Capabilities element the maximum A-MPDU length that it can receive. A STA indicates in the Maximum A-MPDU Length Exponent field in its HT Capabilities, VHT
CID PP LL Comment Proposed Change Resolution 16283 154 17 "A-MSDU In A-MPDU Support" is a bad name since this is actually about ack-enabled Change the field name to "A-MSDU In Acknowledgment Context In A-MPDU Support" Revised The field name is change to A-MSDU in A-MPDU Support per CID . No further change is needed. 154 19 "an A-MSDU is carried in a QoS Data for which no block ack agreement exists." -- an A-MSDU is always carried in a QoS Data frame Change the cited text to "an A-MSDU is transmitted that is not under a block ack agreement." Accepted. CID PP LL Comment Proposed Change Resolution 15606 37 20 ambiguous definition clarify if all A-MPDU subframes solicit neither Ack nor BlockAck or if only the ones with 0 in the EOF field solicit neither Ack nor BlockAck. Revised Generally agree with the commenter. TGax editor to make changes CID 15606. 15934 37 17 This definition is getting into normative details of _how_, beyond just the _what_. Stop the defintion of A-MPDU" before (without) describing how individual bits are set within one. Revised Generally agree with the commenter. TGax editor to make changes under CID 15606. 3.2 Definitions specific to IEEE 802.11 TGax editor: make the following change in subclause 3.2: …… ack-enabled aggregate medium access control (MAC) protocol data unit (ack-enabled A-MPDU): An A-MPDU that contains at two A-MPDU subframes . …