|
16117
|
|
|
|
Field values should not be expressed as binary numbers unless it is clear which bit of the binary number is the msb and which is the lsb
|
Either express such field values as decimal or put them in a table where each bit has its own explicitly numbered column (see baseline)
|
|
16857
|
|
|
|
The document approaches to maturing (very good shape). Because of that, the consistency/accuracy throughout the document is critical. If not done so
yet, I suggest we should consider to have at least two independent coders develop the test vectors to verify all the equations given the TXVECTOR as the input. One of them can be the one close to the editing team, and the other one is preferably an outsider.
He/she codes it simply from reading the draft standard.
|
|
|
16025
|
|
|
|
"power boost factor" is generally about the r thing. However, in a couple of instances it is used for something else. To avoid confusion, those other
two instances should be reworded to use a different term. "the received power measured based on the non-HE portion of the HE PPDU preamble and captured in the RXVECTOR parameter RSSI_LEGACY in the PHY-RXSTART.indication primitive shall be decreased by 3 dB
to compensate for the power boost factor when compared to the OBSS PD level." in 27.9.2.2 and "eta_field,k is the power boost factor of the k-th subcarrier of a given field within an OFDM symbol," in 28.3.9
|
Change the term from "power boost factor" to "power difference" in the two pieces of cited text
|
|
16086
|
|
|
|
The resolution to CID 12587 suggests that there is no pre-compensation, just compensation
|
Change "pre-compensat" to "compensat" throughout, case-insensitively and case-preservingly
|
|
16115
|
|
|
|
There are about a dozen instances of wording referring to transmission of a $something "MHz HE TB PPDU". However, for OFDMA the PPDUs do in general not
have a width that is a multiple of 20 MHz
|
Apparently (see CID 12612) "The term refers to PPDUs that are transmitted with CH_BANDWIDTH set to indicate that value. It would be cumbersome to use
"TXVECTOR parameter CH_BANDWIDTH that indicates X MHz" so we use the shorthand "x MHz PPDU"". If that's the intent of the wording, it needs to be stated somewhere
|
|
16124
|
|
|
|
"HESIGA_Spatial_reuse_value15_allowed" is a very odd and unclear (what is value 15) field name?
|
Change to "SRP And Non-SRG OBSS_PD Allowed" throughout (per CID 12655's resolution)
|
|
16146
|
|
|
|
That an AP with >= 4SS needs to support DL MU-MIMO is stated too many times
|
Delete in at least one of 4.13.4a, T9-262aa, 27.6.2, 28.1.1, 28.3.3.9.2
|
|
16150
|
|
|
|
An S-MPDU is a type of MPDU, so "MPDU or S-MPDU" is pleonastic
|
Delete "or S-MPDU" in "MPDU or S-MPDU" throughout
|
|
16156
|
|
|
|
"left" and "right" are not well-defined for frequencies
|
Fix "NGuard,Left", "NGuard,Right", "LTF80MHz_left_1x", "LTF80MHz_right_1x", "LTF80MHz_left_4x", "LTF80MHz_right_4x"
|
|
16171
|
|
|
|
"long GI" from the baseline needs to be changed since it is now the shortest of the three GIs for ax
|
In the baseline, change "short GI" to "400 ns GI" and "long GI" to "800 ns GI" throughout
|
|
16190
|
|
|
|
Various places that explicitly refer to HE SU PPDUs need to also refer to HE ER PPDUs
|
Add references to HE ER PPDUs after the reference to HE SU PPDUs in 27.4.5, 27.15.3, 28.3.11.2, 27.4.4.2, Table 28-15, 28.3.11.5.1
|
|
16191
|
|
|
|
Need to be clearer the packet extension is completely distinct and independent from the signal extension (also need to make sure the HE PHY is mentioned
wherever the ERP/HT PHYs are currently mentioned for signal extension, in the baseline)
|
As it says in the comment
|
|
16192
|
|
|
|
Sometimes the spec wording indicates that an RU is necessarily less than the full PPDU bandwidth, sometimes it indicates that a non-OFDMA transmission
contains a single RU of the same width as the PPDU bandwidth
|
State that a full-width transmission is an RU, and then simplify things like "HE-MCSs for 242-tone RU and non-OFDMA 20 MHz, NSS = 1" to "HE-MCSs for
242-tone RU, NSS = 1"
|
|
16282
|
|
|
|
It seems from the resolution to CID 12927 that the intent is that an ack-enabled multi-TID A-MPDU is not an ack-enabled A-MPDU. Some parts of the spec
(e.g. T9-422, T9-425, T9-428, 27.3.3.2/3, 27.10.4.1 in part) support this interpretation, but others suggest an aeAM can be an aeMTAM
|
Add to the definition in 3.2 of ack-enabled A-MPDU that the TIDs of all the QoS Data frames are the same. Extend "A-MSDU InA-MPDU Support" in T9-262zz
and 10.12 to also apply to aeMTAMs. Extend 27.5.3.4, 27.10.2 (2x) to refer to aeMTAMs too where they refer to aeAMs. Add a NOTE in 27.10.4.1 after the definition of aeMTAMs: "NOTE--An ack-enabled multi-TID A-MPDU is not an ack-enabled A-MPDU."
|
|
16296
|
|
|
|
The concept of "would be acknowledged with an Ack frame if it were the only one in the A-MPDU, but since it isn't it gets acknowledged with a particular
setting of the Per AID TID Info subfield in a Multi-STA BlockAck frame" recurs but is inconsistently referred to
|
Change all references to soliciting an Ack etc. to soliciting the acknowledgment context per 27.4.2
|
|
16373
|
|
|
|
Do not use the Symbol font anywhere, as this introduces proprietary Unicode codepoints that are not found in search (cf. CID 12705 resolution)
|
Change all uses of the Symbol font to Times New Roman
|
|
16090
|
|
|
|
The MAC requirements on HE STAs should be in Clauses 10 and 11, not in a separate subclause. Otherwise it is not clear which of the Clause 10/11 requirements
apply to HE STAs
|
Move the MAC requirements to the MAC/MLME clauses
|
|
17052
|
|
|
|
The premable puncturing mechanism on the DFS channels is useful to improve the spectrum efficiency.Please refer the submission (11-18-0496r03).
|
As in comment.
|
|
16354
|
|
|
|
The baseline does not allow EOF=0 MPDUs after EOF=1 MPDUs, but ack-enabled multi-TID A-MPDUs can be like that
|
Soften the baseline to allow this in PPDUs exchanged between HE STAs
|
|
16357
|
|
|
|
There are various references to A-MPDUs that solicit an immediate response. However, A-MPDUs don't do this, only the constitutent MPDUs do
|
Reword in terms of the MPDUs soliciting an immediate response, not the A-MPDU itself
|
|
16363
|
|
|
|
Preamble puncturing is inadequately defined and described. Needs to be clearer that it's basically about using OFDMA and restricting the allocated RUs
|
As it says in the comment
|
|
16378
|
|
|
|
We need to look at the PPDU type to decide whether to respond to a DL MU PPDU anyway (because Action frames are allowed and do not have an ack policy),
so the HTP Ack ack policy has no value -- just use Normal Ack/Implicit BAR
|
Delete the references to HTP Ack throughout the draft and instead state that the rules previously described as pertaining to that ack policy instead
pertain to frames received by a non-AP STA in an HE MU PPDU
|
|
15929
|
33.10
|
3.1
|
|
The intention seems to be that A-MSDUs can now be fragmented. There are assumptions in legacy MAC/PHY that will likely break (because the baseline text
now assumes all A-MSDUs could be a fragment unless stated otherwise, so it needs to be clearly stated otherwise where things will break), and there are other places in the text that are inconsistent with this.
|
Add to the definition of GCR frame, that it must be an unfragmented A-MSDU. Correct the statement in the Note following the defintion of MMPDU that says,
"An A-MSDU is trasmitted in one MPDU." In the first sentence of 10.4, add that the MAC may fragment and reassemble A-MSDUs, also, (but only if it is HE and the peer is HE and both support A-MSDU Fragmentation). Clarify the extent of the Editor's instruction
at P109.6. Does this apply to _every_ occurance of A-MSDU in the entire rest of the Standard? (Surely, not.) There are probably more examples.
|
|
16385
|
33.14
|
3.1
|
|
Does the MU MIMO definition intend to cover OFDMA case as well (which I doubt). If not, then may I suggest to add an emphasis on the subcarrier notion
or allocation, something like:"multi-user multiple input, multiple output (MU-MIMO): A technique by which multiple stations(STAs), each with one or more antennas, either simultaneously transmit to a single STA with more than one antennas or simultaneously
receive from a single STA with more than one antennas independent data streams over the same radio frequency resources"A bit Ambiguous (frequencies
|
As in comment.
|
|
16851
|
33.22
|
3.2
|
|
Suggest adding the usage description of preamble puncturing since this is a new function for 11ax. It's not about the English definition but about when
and how it is implemented.
|
|
|
15932
|
33.56
|
3.2
|
|
Did this definition really mean to use the Clause 19 (and not Clause 21) spectral mask? Bullet (e) for VHT STAs is only constrained by the clause 21
mask ( -40 dBr at the extreme skirts). Further, since an HE STA _is_ a [V]HT STA, bullets (h) and (e) become contradictory.
|
Specify the same spectral mask requirements as done for VHT, to make backward implementation easier.
|
|
15931
|
36.38
|
3.1
|
|
Are A-MSDUs still Bufferable Units for HE STAs?
|
Add "and high efficiency (HE) STAs" to the list of STA types that handle A-MSDUs. Similarly for Individually Addressed BU defintion. Similarly, in NOTE
4 of Table 9-25. There are probably more with slightly different syntax.
|
|
15184
|
36.53
|
3.2
|
|
The definitional sentence is made difficult to read by superfluous information and biclauses. Other definitions of XXX-Ids indicate that they define
identifiers (for instance the definitions of FMSID on p. 150, R0KH-ID on p. 158 or TSID on p. 165 of IEEE Std 802.11-2016) and what the identifier identifies. Further, the list of elements from which the identifier can be derived could be made more compact.
|
Change to "An identifier assigned to a basic service set (BSS) if the multiple BSSID capability is supported and which is not transmitted explicitly.
This identifier can be derived from the information encoded in Probe Response, Beacon, directional multi-gigabit (DMG) Beacon frames and Neighbor reports."
|
|
15935
|
37.31
|
3.2
|
|
Aren't all MU PPDUs "downlink" MU PPDUs?
|
Why do we need a definition of "downlink MU PPDU"?
|
|
16846
|
38.26
|
3.2
|
|
Starting line 26 on page 38 (section 3.2 definition) " ... HE TB PPDU ... is capable of .... (PSDU) for one or more users" seems conflicting with " ...
number of users for an ... or HE TB PPDU is always 1" as stated in the Note of NUM_USERS in TXVECTOR (Line 55, p. 393).
|
Please clarify and update accordingly if agreed.
|
|
15936
|
39.10
|
3.2
|
|
Saying that an RU is (even with a specific list of subcarrier options) an "allocation unit" doesn't help, if "allocation unit" isn't used or defined
anywhere.
|
Change definition to, "a group of 26, 52, 106, 242, 484, 996 or 2×996 subcarriers allocated to a particular user of the channel, within a data transmission
to or from several users of the channel."
|
|
17001
|
39.17
|
3.2
|
|
There should be the definition of Spatial Reuse Group (SRG) in subclause 3.2.
|
As in the comment.
|
|
16375
|
65.00
|
9
|
|
There should be no behavioural requirements in Clause 9, which is about format only
|
Move all behavioural requirements to Clause 27/28
|
|
16155
|
122.00
|
|
|
"left" and "right" are not well-defined for frequencies
|
At 122.14 change "For the left of" to "Below"At 122.18 change "For the right of" to "Above"
|
|
17044
|
154.38
|
9.4.2.237.2
|
|
Please clarify whether the OM Control UL MU Data Disable RX Support is a capablity variable or a control variable.
|
As in comment.
|
|
15632
|
162.40
|
Table 9-262aa
|
|
Two fields listed twice, TX 1024-QAM Support < 242-tone RU and RX 1024-QAM Support < 242-tone RU are listed twice in the table
|
remove one set of the TX and RX 1024-QAM Support
|
|
15895
|
164.15
|
9.4.2.237.4
|
|
This field is also valid when R3 is 1 (80+80MHz is supported)
|
As in the comment
|
|
15896
|
164.26
|
9.4.2.237.4
|
|
This field is also valid when R3 is 1 (80+80MHz is supported)
|
As in the comment
|
|
15666
|
165.51
|
9.4.2.237.5
|
|
"The PPE Thresholds field determines the minimal packet extension value (see 28.3.12 (Packet Extension))...", according to other places of the spec such
as 27.12 and 28.3.12, this is not for "minimal packet extention value", but rather the maximum of norminal packet extension duration.
|
Clarify
|
|
15667
|
166.01
|
9.4.2.237.5
|
|
"The NSTS subfield contains an unsigned integer that is the number of NSTS values minus 1 for which PPEthreshold values are included in the PPE Thresholds
Info subfield."--what if the NSTS subfield here has a value smaller than the maximum NSTS value as indicated by the Rx HE-MCS Map table? Does it mean for those NSTS, PPET8 and PPET16 are all zero?
|
Clarify
|
|
16002
|
166.11
|
9.4.2.237.5
|
|
"6 x (NSTS + 1) bits" -- need to be clear this is the field value rather than the NSTS itself (which is one more than the field value)
|
After the cited text at the referenced location add ", where NSTS is the value in the NSTS field,"
|
|
15663
|
167.01
|
9.4.2.237.5
|
|
"Each PPET8 NSTSn RUb and PPET16 NSTSn RUb subfield contains an integer that corresponds to a constellation index value related to the minimal transmission
constellation of an HE PPDU as defined inTable 9-262ac (Constellation index)."--the minimal transmission constellation for what? Also what "transmission" mean? SHould this be for reception capability?
|
Change to: ..minimal reception constellation of an HE PPDU that supports the maximum Nominal Packet Extension duration (TPE) when pre-FEC padding factor
equals to 4 being 8 us and 16 us respectively, as defined in...
|
|
16325
|
167.33
|
9.4.2.237.5
|
|
"The value of the PPET8 NSTSn RUb subfield is always less than the value of the PPET16 NSTSn RUb subfield, except if the PPET8 subfield is 7." -- there
are other constraints
|
Add the other constraints, e.g. value for NSSi must be no more than for NSSj for given RUm, if i > j
|
|
15899
|
174.01
|
9.4.2.242
|
|
Other resource request may have threshlod value. An AP may support some of them. Based on this observation, it is better to have a Control field with
each bit indicates whether an AP supports the NDP feedback report and the related threshold value (followed by optional threshold fields).
|
As in the comment
|
|
15820
|
174.20
|
9.4.2.242
|
|
The default value for the resource request buffer threshold exponent is missing from the description.
|
Add the default values in the description of the
|
|
15637
|
179.10
|
Table 9-262ag
|
|
Table Title should include RSSI
|
Change "Value" to "Encoded Value" and "Description" to "RSSI Value"
|
|
15262
|
186.33
|
9.6.25.9
|
|
Some collective deliberations will be required to bring structure to this entire subclause. Fig 9-740b1 is not referenced anywhere, and the sentences
look half-baked.
|
As in comment.
|
|
15904
|
216.10
|
10.12
|
|
Ack-enabled A-MPDU is like an S-MPDU where the QoS Data asks for Ack. So A-MSDU In A-MPDU is not needed.
|
Remove A-MSDU In A-MPDU from the draft
|
|
16250
|
216.37
|
10.13.2
|
|
"A STA indicates in the Maxi-mum A-MPDU Length Exponent field in its HT Capabilities, VHT Capabilities and HE Capabilities elementsthe maximum length
of the A-MPDU pre-EOF padding that it can receive in an HE PPDU." is not true if the Maximum A-MPDU 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
|
|
15905
|
217.53
|
10.13.3
|
|
DMG STA doesn't consider Minimum MPDU Start Spacing for QoS Null. However HE STA considers Minimum MPDU Start Spacing for QoS Null. What is the reason
for such difference?
|
Clarify it.
|
|
17129
|
232.09
|
10.28.3
|
|
In the last sentence, it mentions that the duration indicated by the Duration/ID field is available for the RD response burst and RD initiator final
PPDU. It doesn't include the HE TB PPDU that send by RD initiator that follows the Basic Trigger that send by RD responder.
|
modify the text to include the HE TB PPDU that send by RD initiator.
|
|
16172
|
242.43
|
11.23.1
|
|
The set of features that TDLS STAs may and shall not use needs to be specified
|
In the referenced subclause add "A TDLS STA shall not transmit an HE MU PPDU or HE TB PPDU to a peer TDLS STA."
|
|
16763
|
346.00
|
|
|
"minus a safety margin value not to exceed 5 dB". Why do we need to specify this value and be so specific about setting the value of the Acceptable Interference
Level? The Acceptable Interference Level is determined by the AP and should be left to implementation.
|
Use more generic wording like "should be chosen by the AP to ensure correct reception in the presence of the expected interference"
|
|
15716
|
350.43
|
29.9.2.5
|
|
This clause describes the case that a STA ignores an OBSS PPDU following procedure of 27.9.2.2 or 27.9.2.3 and not able to transmit within the received
inter-BSS PPDU duration. The STA starts an OBSS PD SR transmit power restriction period may not be able to gain TXOP for a long duration (e.g., receive intra-BSS PPDUs), the OBSS PD SR transmit power restriction period should not be applicable anymore after
some duration. Please change to "This OBSS PD(#11726) SR transmit power restriction period shall be terminated at the end of the TXOPthat the STA gains once its backoff reaches zero." to "This OBSS PD(#11726) SR transmit power restriction period shall be terminated
at the end of the TXOP that the STA gains once its backoff reaches zero or exceeds max TXOP limit."
|
as described
|
|
16323
|
358.33
|
27.12
|
|
It is not clear what to do if the PPET8 and PPET16 comparisons in Table 27-12 give different rows
|
Express as a list: if then the Nominal Packet Padding value is 16 us, otherwise if then 8 us, otherwise 0 us.
|
|
16686
|
365.50
|
|
|
Clause 10.7.6.5.3 in 802.11-2016 defines MCS selection for a control response frame. It is not clear how this applies to the use of HE ER SU PPDUs carrying
control response frames. For example, how is DCM applied?
|
Clarify the MCS seelction rules for control response frames that are sent in HE ER SU PPDUs. I would suggest that we make this implementation dependent,
i.e., don't have strong rules, and allow the
|
|
15943
|
679.01
|
T
|
|
Annex T should be updated to discuss BSS color as another method (for HE BSSs) to use for overlapping BSSs, and to give recommendations on its usage.
|
Add recommendations on use of BSS color to Annex T.
|
|
16067
|
679.04
|
AA
|
|
There should be an example where non-MU-MIMO RUs are skipped over (i.e. unused) by using STA-ID 2046
|
As it says in the comment
|
|
16079
|
2391.04
|
12.6.18
|
|
"NOTE 2---Because the IEEE 802.11 Null frame does not derive from an MA-UNITDATA.request primitive, it is not protected." -- the real reason is that
there is nothing to protect. Some TDLS frames, for example, are not derived from MA-UNITDATA.requests, but are protected nonetheless. It's not clear what the point of this NOTE is anyway
|
Delete the cited text at the referenced location, and delete the " 1" immediately above
|