A motion to approve this submission that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGax Editor: Editing instructions preceded by “TGax Editor” are instructions to the TGax editor to modify existing material in the TGax draft. As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft. CIDs 3223 Ahmadreza Hedayat It'd be worthwhile to clarify the restrictions on group-addressed MPDUs across RUs; e.g. only one RU can carry MPDUs with broadcast address, and at most one RU for a given ID etc. "The Type and Subtype subfields in the Frame Control field and address type (individually addressed or group addressed) of MPDUs may be different across in different RUs within a same HE MU PPDU." As in the comment Rejected- Having multiple broadcast RUs complicates the implementation of the receiver to support simultaneous data receiption from multiple. So the group decided to have such restriction. There is no obligation for the spec to explain the reationale of the design. The current text already provides sufficient clarity for implementation. TGax editor no changes to the current spec. 3224 Ahmadreza Hedayat If a STA gain access via RA and sends BQR then it's an unsolicied BQR and should be gathered in the upper clause P163L26: "... the STA shall follow the rules defined in 27.5.2.6 (UL OFDMA-based random access) to gain access to a random RU and generate the HE trigger-based PPDU when the Trigger As in the comment Rejected- Per “If a STA gain access via RA and sends BQR…”, this BQR is still solicited by a BQRP. So it is not an unsolicited BQR. TGax editor makes no changes to the current spec.
frame contains one or more random RU(s)." 4797 Alfred Asterjadhi This sentence is not clear "An AP shall not transmit to a STA an HE MU PPDU with the HE-SIG-B allocating spatial streams to more than one recipient STA, unless the STA sets the Downlink MU-MIMO On Partial Bandwidth Rx subfield of the HE Capabilities element to 1.". Please clarify what the intention is. As in comment Revised- in principle.DL is not supported with DL OFDMA unless the STA claims it is capable of doing it. The first part of sentence may describe the case of full bandwidth DL MU MIMO operation. The last paragraph of this section already conveyed the intended information. Prpose to delete this sentence. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 4797. 4798 Alfred Asterjadhi It is not the transmission that is padded but the PSDU in each RU. PLease rephrase. As in commnet. Accepted- TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 4798 4799 Alfred Asterjadhi Unicast is not defined. Define it prior to its use. As in comment. Revised- Agree in principle. In the baseline spec, unicast address is defined. Propose to change to “RA set to unicast address”. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 4799. 4801 Alfred Asterjadhi This is not enough. It has to be clear what the MPDU that is sent in the broadcast RU contains. E.g., can it be a broadcast MPDU that was sent in legacy PPDU? If yes then what is the STA receiving both expected to do? As in comment. Revised- The sentence is confusing. A broadcast RU is not part of a HE MU PPDU. We propose to improve the clarity of the sentence. An legacy PPDU will not be able to use an broadcast RU unless the broadcast RU is taking the full bandwidth of the PPDU. In such case, it falls back to the MIMO 56
that are marked with CID 5179 5180 Dorothy Stanley Regarding "An AP shall not transmit to a STA an HE MU PPDU with the allocating spatial streams to more than one recipient STA, unless the STA sets the Downlink MU-MIMO On Partial Bandwidth Rx subfield of the HE Capabilities element to 1.", what is the intent of not allowing DL MU-MIMO w/ HE MU PPDU if the STAs only support full bandwidth? Is the intent to use VHT PPDU? I would think in the future when all the devices are HE, we would not want a mix of VHT and HE PPDU's Allow DL with HE MU PPDU to HE STAs that do not support partial bandwidth. Revised- Agree in principle. Agree in principle. Per proposed resolution of CID 4804, this sentence will be removed. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 5180 5181 Dorothy Stanley I can't find a definition for "DL OFDMA With PPDU". I can't find an HE Capabilities element with "DL OFDMA With MIMO Support" field. Define the terms so the paragraph makes sense. Revised- Agree in principle. Per proposed resolution of CID 4804, this sentence will be removed. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 5181. 5182 Dorothy Stanley Regarding "The STA that receives a BQRP variant Trigger frame shall follow the rules defined in 27.5.2.3 (STA behavior) to generate the HE trigger-based PPDU when the Trigger frame contains the STA's AID in any of the Per User Info fields; otherwise the STA shall follow the as in comment Revised- Agree in principle. A non-AP STA can use UL random access only if it claims the capability (i.e. set OFDMA RA Supports bit in HE MAC Capabilites to 1). Proposes to add a qualifier in the sentence to clarify. TGax editor changes as shown in 11-17/1286r0 that are marked with CID 5182. MIMO 56
5700 Guoqing Li There is terminology called "DL OFDMA with MIMO PPDU" Use a difined terminology Revised- Agree in principle. Per proposed resolution of CID 4804, this sentence will be removed. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 5700. 5701 Guoqing Li There is no field called "DL OFDMA With MIMO Support field" in HE Capabilities Element Use a defined terminology or define it. Revised- Agree in principle. Per proposed resolution of CID 4804, this sentence will be removed. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 5701. 5780 Hanseul Hong DL OFDMA with Support field is not present in HE capabilites element add it in HE capabilities element Revised- in principle. Per proposed resolution of CID 4804, this sentence will be removed. TGax editor changes as shown in 11-17/1286r0 that are marked with CID 5780. 5808 Huizhao Wang If a STA canot find its STA-ID in BQRP trigger frame, then this BQRP is not intended to it, and should not respond Remove the text: "otherwise the STA shall follow the rules defined in 27.5.2.6 (UL random access) to gain access to a random RU and generate the HE PPDU when the Trigger frame contains one or more random RU(s)." Rejected- In the case that AP has no knowledge of which non-AP has clear channel for receiption. It is a smart way for AP to collect such information through OFDMA ramdom access. There is no technical justification to forbit this usage. TGax editor makes no changes on CID 5808. 56
based 5980 Jarkko Kneckt It is unclear whether BQRP Trigger variant that allocates RUs for random access requires that a HE trigger-based PPDU transmitted in the RU for random access contains a BQR information in the field. Please clarify is a STA that detects RUs for random access required to transmit BQR reports in a PPDU in a RU allocated for random access. Please clarify is the same requirement used for other Trigger variants as well? Rejected- A STA who detects RU that is allocated for OFDMA random access in BQRP Trigger variant doesn’t have to use OFDMA random access if it has been named in other RUs. TGax editor makes no changes on CID 5980. 5981 Jarkko Kneckt The non-AP STA should not be forced to perform random access. The use of random access for the BQR transmission should be voluntary for the STAs. If all STAs are required to transmit BQR in random access when a Trigger contains random access RUs, the power consumption of hte STA increases unnecessarily and transmisison overhead in random access becomes high. The non-AP STAs transmission in the RUs allocated for random access should be optional. Change the wording to say that if RUs for random access are included a non-AP STA may respond... Revised- Agree in principle. Per resolution of CID 5182, add qualifier to regulate when a STA can use OFDMA random access to report the BQR. TGax editor makes no changes on CID 5981. 5982 Jarkko Kneckt The BQR support in AP and STA is already described in 35 -39. The second bullet has a lot of repetition. delete the end of hte sentence. Delete:"when the AP has indicated...". Rejected- BQR is optional function for AP and STA, it is necessary to have these sentence to clarify the condition that BQR can be used. TGax makes no changes on CID 5982. Control
7226 Katsuo Yunoki STA behavior after receiving MU DL PPDU should be explained. (e.g. how to respond ACK, Block ACK) STA behavior receiving MU DL PPDU should be explained. (e.g. how to respond ACK, Block ACK) Rejected- The ACK/BA procedure for the DL MU is defined in section 27.4. There is no need to repeat same information in two places of the spec. TGax editor makes no changes on CID 7226. 7385 Laurent Cariou It is not mentioned on bandwidth the report is provided, while the bitmap depends on the bandwidth Clarify Rejected- It is already defined in section 9.2.4.6.4.7. TGax editor makes no changes on CID 7385. 7571 Liwen Chu The channel query can be used by both UL and DL MU. Move the subclause outside of DL MU subclause and change the title accordingly. As in comment Revised- Per proposed resolution for CID 6165, move 27.5.1.3 to 27.5.6 making it general to both UL and DL operation. TGax editor changes as shown in 11-17/1286r0 that are marked with CID 7571. 7572 Liwen Chu Add management frame after QoS Null, QoS Data frames As in comment Accepted- TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 7572. 7647 Liwen Chu The rules about when the DL MU frame exchange is successful is missing from the draft. Add the related rules. Revised- Agree in principle. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 7647. 10316 Zhou Lan BQR now is in the section of DL MU operation. However it should be useful for the AP to make right decision on UL MU scheduling as well Extend BQR to UL MU operation Revised- Per proposed resolution for CID 6165, move 27.5.1.3 to 27.5.6 making it general to both UL and DL operation. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 10316. 1 1
7642 Liwen Chu A-MPDU in HE DL MU PPDU use the rules in 27.10.3. Padding rules for in VHT PPDU is used. As in comment Accepted- Agree in principle. Change reference to 10.13.6. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 7642. 7643 Chu Paragraph at L56 is duplicated with the paragraph at L44. Remove the paragraph at L44 Revised- Agree in principle. Per proposed resolution of CID 4804, this sentence will be removed. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 7643. 7688 Lochan Verma Downlink MU-MIMO on Partial Bandwidth Rx' is no HE Capability Replace with ""An AP shall not transmit to a STA an HE MU PPDU with HE-SIG-B assigning MU-MIMO RU in an DL OFDMA PPDU when the RU does not span the entire PPDU bandwidth, to a STA from which it has not received an HE Capabilities element with DL on Partial Bandwidth subfield set to 1". " Revised- Agree in principle. The right HE Capabilities bit should be refered. Per proposed resolution of CID 4804, this sentence will be removed. The corresponding sentence in to 59 is modified correspondingly. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 7688. 7689 Lochan Verma DL OFDMA With MIMO Support is no capability in HE capabilities Delete lines 56-59. Revised- Agree in principle. The right HE Capabilities bit should be refered. Per proposed resolution of CID 4804, this sentence will be removed. The corresponding sentence in to 59 is modified correspondingly. MPDU 56 56
TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 7689. 7807 Mark Hamilton Use proper normative verbs Change "delivers" to "shall deliver" Accepted- TGax editor changes as shown in 11-17/1286r0 that are marked with CID 7807. 7808 Mark Hamilton Use proper normative verbs Change "can" to "may". Same thing at P163L35, P164L47, P167L2, P171L12, P171L52, P174L36. Accepted- TGax editor changes as shown in 11-17/1286r0 that are marked with CID 7808. 8053 Massinissa Lalam is no "DL OFDMA With MIMO Support" field defined in the HE Capabilities element subclause 9.4.2.218. Either add this field if missing or refer to the correct one(s). So far the intent of the sentence is not really clear for me to decide to which already existing fields of the HE Capabilities element to refer. Does the sentence refer to a DL OFDMA transmission plus DL MU-MIMO on some RUs, or just DL OFDMA with more than one spatial streams on some RUs? As in comment. Revised- Agree in principle. The right HE Capabilities bit should be refered. Per proposed resolution of CID 4804, this sentence will be removed. The corresponding sentence in to 59 is modified correspondingly. TGax editor changes as shown in 11-17/1286r0 that are marked with CID 8053. 8167 Ming Gan "explicitly deliver BQRs in any frame sent to the AP", what is "any frame". It is not clear. Actually it requires this frame contains A-control field. change "any frame" to "any frame which contains field" Rejected- There is no need to put redunt info in the spec. The only way for a STA to report BQR is through BQR TGax editor makes no changes on CID 8167. Control
8168 Ming Gan "implicititly" and "explicitly" seem redudant. Non-AP STA always carries available channle bitmap in the field in these two modes delete "implicititly" and "explicitly" Rejected- It is necessary to differentiate these two usage cases of BQR. TGax editor makes no changes on CID 8168. 8217 Osama Aboulmagd what does "efficient way" mean? How the word "efficient" is defined? delete the fisrt sentence or qualify the word "efficient" Rejected- BQR provides AP the per 20MHz channel availability information so that AP doesn’t make blind scheduling decision to send DL MU PPDU to STAs that doesn’t have corresponding channels availale. Deleting the sentence will only blur people’s understanding of the mechanism. TGax editor makes no change on CID 8217. 8255 Pascal VIGER Buffer Query Report following MU-RTS procedure may be inefficient. As MU-RTS scheme relies on 802.11ac (contiguous band) and BQR supports punctured band among a whole similar BW, there is chance that HE STAs indicate in their BQR some 20 MHz channels that are not protected by The usage of not protected channels may be problematic for legacy devices. The MU-RTS variant may be enhanced to support emission of CTS frames a punctured bandwidth. A HE STA already has the possibility to sense various 20MHz channels, determine those free, and emit on a specific (according BQR capability). During its scheme, the HE AP may inform HE STAs which are (through a single bit in Rejected- MU-RTS/CTS frame exchange needs to be in legacy format for legacy protection. It is almost not impossible to amend on legacy CTS frame for per 20MHz channel availability information. TGax editor makes no changers on CID 8255. Control
MU-RTS TF) that it is ready to receive CTS on channels 8270 Pascal VIGER Following sentence is unclear : "An MPDU sent in a broadcast RU of an HE MU PPDU shall not include information intended for a STA that is identified as the recipient of another RU in the same HE MU PPDU." This lets think a broadcast RU is not destined to any station. Isn't it a unicast RU instead ? as per comment Rejected- It is designed that 11ax receiver has no capability of simultaneous decoding of multiple RUs. So if the a RU is intended for a particular user, then no other should be addressing to that user in the MPDU/A-MPDU in the broadcast RU. TGax editor makes no changes on CID 8270. 8294 Patrice "An MPDU sent in a broadcast RU of an HE MU PPDU shall not include information intended for a STA that is identified as the recipient of another RU in the same HE MU PPDU." Does it mean that broadcasted RU can not be mixed with any other types of RU ? as per comment Rejected- Duplicated CID of CID 8270. 8495 Robert Stacey DL OFDMA With MIMO PPDU is not defined. There is no such thing as a DL OFDMA With MIMO Support field. The capability that most closely resembles this is the DL On Partial Bandwidth field. Describe in of TXVECTOR parameters. Revised- Agree in principle. There is no definition of DL OFDMA with MIMO PPDU. DL OFDMA with MIMO is a feature defined in Table 9-262aa. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 8495. 8496 Robert Stacey "The Type and Subtype subfields ... may be different... ": Meaningless statement. Remove statement Rejected- The sentence helps to clarify the Type and Subtype settings of MPDUs transmitted in different RU of the same HE MU PPDU 56
It is not defined in the HE Capabilities element. Delete the corresponding paragraph. 9889 Young Hoon Kwon What does "allocating spatial streams to more than one recipient STA" mean? Poor description, and needs rewriting. As in the comment. Revised- Agree in principle. Per proposed resolution of CID 4804, this sentence will be removed. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 9889. 9890 Young Hoon Kwon This sub-clause is for HE DL MU operation, however, the padding procedure shown in 27.10.3 is for HE UL MU operation. Therefore, the padding procedure mentioned here is irrelevent. Need further clarification. As in the comment. Revised- Agree in principle. Change to the correct reference for padding. TGax editor makes changes as shown in 11-17/1286r0 that are marked with CID 9890. 9891 Young Hoon Kwon DL OFDMA With MIMO Support field is not defined in HE Capabilities element. Need definition for it. As in the comment. Revised- Agree in principle. The right HE Capabilities bit should be refered. Per proposed resolution of CID 4804, this sentence will be removed. The corresponding sentence in 56 to 59 is modified correspondingly. TGax editor changes as shown in 11-17/1286r0 that are marked with CID 9891. 9892 Young Hoon Kwon It is not clear how to obtain the channel availability information for each 20MHz, especially for unsolicited BQR case. For example, how to measure and when to measure the channel availability for each 20MHz is not clear. It needs further clarification. As in the comment. Rejected- Please refer to section 9.2.4.6.4.7 and 28.3.17.6.5 for further details. All these information has been defined. TGax editor makes no changes on CID 9892.