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 Editor” are instructions to the TGax editor to modify existing material in the “TGax 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 It'd be worthwhile to As in the Rejected- Hedayat clarify the restrictions comment on group-addressed Having multiple broadcast MPDUs across RUs; RUs complicates the e.g. only one RU can implementation of the carry MPDUs with receiver to support broadcast address, simultaneous data receiption and at most one RU from multiple. So the group for a given decided to have such address ID etc. "The restriction. There is no Type and Subtype obligation for the spec to subfields in the explain the reationale of the Frame Control field design. The current text and type already provides sufficient (individually clarity for implementation. addressed or group addressed) of TGax editor no changes MPDUs may be to the current spec. different across in different RUs within a same HE MU PPDU." 3224 Ahmadreza If a STA gain access As in the Rejected- Hedayat via RA and sends comment BQR then it's an Per a STA gain access via “If unsolicied BQR and RA and sends BQR…”, this should be gathered in BQR is still solicited by a the upper clause BQRP. So it is not an P163L26: "... the STA unsolicited BQR. shall follow the rules defined in 27.5.2.6 TGax editor makes no (UL OFDMA-based changes to the current spec. random access) to gain access to a random RU and generate the HE trigger-based PPDU when the Trigger
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.
11-17-1286-00-00ax-cr-dl-mu-procedure.docx