|
16148
|
|
|
|
The MU Beamformer subfield has no associated behaviour. The resolution to CID 12673 states that "For less then 4SS, support of MU-MIMO is optional for AP." -- this
is true but beside the point. There needs to be some kind of shall/should/may behaviour associated with the subfield (i.e. what does another STA do based on the setting of this subfield), or it serves no purpose
|
|
15651
|
|
|
|
6GHz AP Discovery: Add the ability for a STA operating in 2.4/5GHz BSS to discover a 6GHz HE AP
|
|
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
|
|
16222
|
|
|
|
New amendment style is a bad idea. It means you need to look in multiple places to find what the requirements really are
|
|
16041
|
|
|
|
There is no such thing as "unsuccessful reception" of a frame: either a frame is received, or it is not
|
|
16221
|
|
|
|
It is not clear whether "ack-enabled A-MPDU"s and "ack-enabled multi-TID A-MPDUs" are the same thing or not
|
|
16211
|
|
|
|
An MPDU delimiter with a Length field of 0 indicates that the A-MPDU subframe does not contain an MPDU. Hence most of the discussion of non-zero length MPDU delimiters
is spurious
|
|
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
|
|
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)
|
|
16190
|
|
|
|
Various places that explicitly refer to HE SU PPDUs need to also refer to HE ER PPDUs
|
|
16184
|
|
|
|
"a frame with the duration information indicated by a Duration field in the PSDU of the PPDU with the RXVECTOR parameter TXOP_DURATION" (4 instances: 10.3.2.4 2x,
27.2.4 2x) is not clear
|
|
16171
|
|
|
|
"long GI" from the baseline needs to be changed since it is now the shortest of the three GIs for ax
|
|
16161
|
|
|
|
"An ER BSS may have larger coverage area." -- this is not an implementation option
|
|
16160
|
|
|
|
"An HE AP may operate an ER BSS in addition to a non-HT BSS. An ER BSS, when present, shall operate independent of the non-HT BSS and shall have a BSSID different
from the non-HT BSS operated by the AP." is written as if an AP is a physical device. But it's not, in the 802.11 standards, it's a logical concept, and one that corresponds to exactly one BSS and BSSID
|
|
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
|
|
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
|
|
16026
|
|
|
|
PPDUs don't have a MAC header, in general
|
|
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
|
|
16081
|
|
|
|
All the D1.0 comments "resolved" as "REJECTED in the interest of releasing D2.0" or similar (about 500 of them!) were not in fact resolved
|
|
16082
|
|
|
|
All the D2.0 comments "resolved" as "[REJECTED] Due to lack of submission or consensus" or similar (about 300 of them!) were not in fact resolved, including many
where no submission was needed as the proposed change was simple and unambiguous, and no attempt was in fact made to find consensus (they were not even discussed)
|
|
16086
|
|
|
|
The resolution to CID 12587 suggests that there is no pre-compensation, just compensation
|
|
16156
|
|
|
|
"left" and "right" are not well-defined for frequencies
|
|
16103
|
|
|
|
It is not clear whether an HE ER SU PPDU is a type of HE SU PPDU, i.e. whether rules that apply to HE SU PPDUs also apply to HE ER SU PPDUs
|
|
16150
|
|
|
|
An S-MPDU is a type of MPDU, so "MPDU or S-MPDU" is pleonastic
|
|
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
|
|
16120
|
|
|
|
It is not clear what the value of transmission of HE MU PPDUs by a non-AP STA is
|
|
16124
|
|
|
|
"HESIGA_Spatial_reuse_value15_allowed" is a very odd and unclear (what is value 15) field name?
|
|
16144
|
|
|
|
It is not clear whether a GCR MU-BAR is a type of MU-BAR (cf. BlockAckReq v. Basic BlockAckReq v. Compressed BlockAckReq); see also constructs like "a GCR MU-BAR
Trigger frame or MU-BAR Trigger frame" and "The Trigger Type of the Trigger frame is either MU-BAR or GCR MU-BAR"
|
|
16146
|
|
|
|
That an AP with >= 4SS needs to support DL MU-MIMO is stated too many times
|
|
16254
|
|
|
|
Some subclause (and maybe other) cross-references are not hyperlinks
|
|
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
|
|
16373
|
|
|
|
Do not use the Symbol font anywhere, as this introduces proprietary Unicode codepoints that are not found in search (cf. CID 12705 resolution)
|
|
16313
|
|
|
|
The changes to allow for fake STA Info fields in TB sounding are the wrong fix to the problem of being about to use TB sounding with a single STA. Instead, make the
choice between TB sounding and non-TB sounding dependent only on whether the NDPA is broadcast or unicast
|
|
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
|
|
15647
|
|
|
|
Need to specify 6GHz operation for 11ax.
|
|
17052
|
|
|
|
The premable puncturing mechanism on the DFS channels is useful to improve the spectrum efficiency.Please refer the submission (11-18-0496r03).
|
|
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.
|
|
16367
|
|
|
|
It is not clear whether an HE STA in the 2.4 GHz band uses the HT or VHT capabilities related to MPDU size
|
|
16363
|
|
|
|
Preamble puncturing is inadequately defined and described. Needs to be clearer that it's basically about using OFDMA and restricting the allocated RUs
|
|
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
|
|
16353
|
|
|
|
Can an S-MPDU sent by a non-AP STA be acked by an M-BA from the AP? Maybe only if the S-MPDU is sent in an UL MU transmission (i.e. HE TB PPDU)?
|
|
16352
|
|
|
|
Should allow for more than one ack-enabled MPDU in an ack-enabled multi-TID A-MPDU (with a mechanism to ensure it's clear which is being acked, of course)
|
|
16351
|
|
|
|
Shouldn't be allowed to have an S-MPDU TID (EOF=1) and a BA TID (EOF=0 for same TID) in the same (ack-enabled) multi-TID A-MPDU
|
|
16354
|
|
|
|
The baseline does not allow EOF=0 MPDUs after EOF=1 MPDUs, but ack-enabled multi-TID A-MPDUs can be like that
|
|
16383
|
2.06
|
keywords
|
|
"dense deployment" should be added to the keyword lists. It is used in the draft (either literally or in the form of "dense deployments" or "dense network") and this
is one of the primary goals of 11ax existence to begin with.
|
|
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.
|
|
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
|
|
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.
|
|
15804
|
33.22
|
3.2
|
|
Define what a High Efficacy (HE) AP is, as this term is used throughout the amendment
|
|
15803
|
33.22
|
3.2
|
|
Define what a High Efficacy (HE) non-AP STA is, as this term is used throughout the amendment. This is a key term for the amendment and defining it in 4.3.14a is
not adequate.
|
|
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.
|
|
15931
|
36.38
|
3.1
|
|
Are A-MSDUs still Bufferable Units for HE STAs?
|
|
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.
|
|
15000
|
36.60
|
3.2
|
|
It is possible that a STA is in coverage range of an OBSS AP that has assigned the same AID value to one of it's associated STA. Therefore, "STA-ID in HE-SIG-B" is
not sufficient to identify the desired STA.
|
|
16130
|
36.60
|
3.2
|
|
"user: An individual station or group of stations (STAs) identified by a single receiver address (RA) or aSTA-ID in HE-SIG-B in the context of single-user multiple
input, multiple output (SU-MIMO), multi-usermultiple input, multiple output (MU-MIMO), or orthogonal frequency division multiple access (OFDMA)." has confusing precedence. Also it omits SISO users and the signalling for users for VHT DL MU-MIMO, which does
not use a STA-ID
|
|
16847
|
37.00
|
3.2
|
|
Is it intentional to have STA ID value 2045 appear in both conditions? If yes, please explain.
|
|
16100
|
37.00
|
3.2
|
|
There are two definitions of "high efficiency (HE) extended range (ER) single user (SU) physical layer (PHY) protocol data unit (PPDU)"
|
|
16101
|
37.00
|
3.2
|
|
There are two definitions of "high efficiency (HE) extended range (ER) single user (SU) physical layer (PHY) protocol data unit (PPDU)"
|
|
16102
|
37.00
|
3.2
|
|
There are two definitions of "high efficiency (HE) extended range (ER) single user (SU) physical layer (PHY) protocol data unit (PPDU)"
|
|
15998
|
37.24
|
3.1
|
|
"by the STA-ID values 2045, 2047 and 0 to 2n - 1 when the AP transmits a Multiple BSSID element and n is equal to the MaxBSSID Indicator field advertised by the AP
in the Multiple BSSID element" -- it is not clear whether the "when" applies to 2045 and 2047 too
|
|
15999
|
37.24
|
3.1
|
|
There should not be so much detail in a definition
|
|
16386
|
37.24
|
3.2
|
|
The mapping between the STA-ID values and either an unassociated STA (2045) or any associated STA (0) is not clearly defined in the broadcast resource unit (RU) definition.
Please consider clarification /reordering. Something like:"a resource unit within an HE MU PPDU, intended for any STA associated with the BSS or unassociated STAs, identified by the STA-ID values 0 and 2045, respectively when the AP does not transmit a Multiple
BSSID element. A resource unit within an HE MU PPDU, intended for unassociated STAs or any STA associated with a BSS, identified by the STA-ID values 2045, 2047 and STA-ID values 0 to 2n - 1, respectively when the AP transmits a Multiple BSSID element and
n is equal to the MaxBSSID Indicator field advertised by the AP in the Multiple BSSID element."or just a simple inversion:"resource unit within an HE MU PPDU, intended for any STA associated with the BSS or unassociated STAs, identified by the STA-ID values
0 and 2045 when the AP does not transmit a Multiple BSSID element, and by the STA-ID values 2045, 2047 and 0 to 2n - 1 when the AP transmits a Multiple BSSID element and n is equal to the MaxBSSID Indicator field advertised by the AP in the Multiple BSSID
element.
|
|
15935
|
37.31
|
3.2
|
|
Aren't all MU PPDUs "downlink" MU PPDUs?
|
|
15001
|
37.54
|
3.2
|
|
Definition of HE ER SU PHY appears twice
|
|
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).
|
|
17077
|
39.01
|
3.2
|
|
"OBSS PD SR opportunity" is defined but not used.
|
|
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.
|
|
17001
|
39.17
|
3.2
|
|
There should be the definition of Spatial Reuse Group (SRG) in subclause 3.2.
|
|
16375
|
65.00
|
9
|
|
There should be no behavioural requirements in Clause 9, which is about format only
|
|
15805
|
65.36
|
9.2.4.1.8
|
|
Why is it necessary to restrict the optional AP behavior of setting the More Data subfield to 1 in Ack frames to a non-HE STA. If an HE STA receives and Ack frame
with the More Data subfield set to 1 is there a problem? I hope not as if there is then there is a significant backward compatibility issue as HE AP should be able to support non-HE STAs. Therefore remove the restriction on an AP not setting the More Data
subfield to an Non-HE STA.
|
|
15806
|
65.38
|
9.2.4.1.8
|
|
There is no need to specify the behavior of an HE AP regarding the use of the more data subfield in the frame format section on the More Data subfield. How an HE
AP indicates its support or nonsupport of the More Data subfield should be described elsewhere.
|
|
16078
|
67.54
|
9.2.4.5.6
|
|
It needs to be clear that the Queue Size is based on what has been passed in MA-UNITDATA.request and there is no visibility of any traffic queued above the MAC SAP
|
|
16001
|
68.06
|
9.2.4.5.6
|
|
"of all MSDUs and A-MSDUs buffered at the STA". A STA does not buffer A-MSDUs. The things it receives via MA-UNITDATA.request are MSDUs, and those are the things
it buffers prior to transmission
|
|
16000
|
68.06
|
9.2.4.5.6
|
|
"of all MSDUs and A-MSDUs buffered at the STA". A STA does not buffer A-MSDUs. The things it receives via MA-UNITDATA.request are MSDUs, and those are the things
it buffers prior to transmission
|
|
16077
|
68.30
|
9.2.4.5.6
|
|
"including the MSDUs or A-MSDUs in the transmission" -- it is not clear what is meant by "the transmission"
|
|
17111
|
71.26
|
9.2.4.6.4
|
|
mismatch between Table 10-8a and Table 9-18a. Add ONES to the case where Control ID value equal to 16
|
|
16646
|
94.01
|
9.3.1.20
|
|
TB sounding sequence is adequately distinguished from non-TB sounding sequence using the RA field alone (individually addressed vs broadcast). Additionally using
the number of STA Info fields to distinguish the sequences just complicates things. HE TB sounding can involve 1 or more STAs (NOT 2 or more). HE non-TB sounding only a one STA.
|
|
15622
|
108.00
|
9.3.2.23.8
|
|
P-matrix codes are only mentioned in this one note. Clarify what the relevant P-matrix codes are.
|
|
16155
|
122.00
|
|
|
"left" and "right" are not well-defined for frequencies
|
|
15885
|
148.48
|
9.4.2.237.2
|
|
Change to "Dynamic Fragmentation Support"
|
|
17084
|
149.26
|
9.4.2.237.2
|
|
The size of the HE Capabilities element has been evolving. And since the HE Capabilities element has variable size, and does not have any version bit(s), it is not
possible for the recipient device to know which draft of HE Capabilities element is being received. Note that B7 of HE PHY Capabilities Information field in D2.0 is equivalent to B47 of HE MAC Capabilities Information field in D3.0. And both of these bits
are reserved. Hence, changing this bit to 1 could help provide some information to dinstinguish between D2.3 and D3.X. Also, we should add additional version bits to be future proof.
|
|
15884
|
149.57
|
9.4.2.237.2
|
|
Add the sentence in encoding column that an AP sets it to 1.
|
|
15886
|
153.14
|
9.4.2.237.2
|
|
The definition of the Capability is not in line with the nomative description subclause. Harmonize them.
|
|
15887
|
154.17
|
9.4.2.237.2
|
|
Change the name to "A-MPSU in Ack-enabled A-MPDU Support"
|
|
16283
|
154.17
|
9.4.2.237.2
|
|
"A-MSDU In A-MPDU Support" is a bad name since this is actually about ack-enabled A-MPDUs
|
|
16293
|
154.19
|
9.4.2.237.2
|
|
"an A-MSDU is carried ina QoS Data frame for which noblock ack agreement exists." -- an A-MSDU is always carried in a QoS Data frame
|
|
15033
|
154.30
|
9.4.2.237
|
|
UL 2×996-tone RU Support is reserved for AP
|
|
15034
|
154.38
|
9.4.2.237
|
|
OM Control UL MU Data Disable RX Support is reserved for non-AP STA
|
|
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.
|
|
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
|
|
15895
|
164.15
|
9.4.2.237.4
|
|
This field is also valid when R3 is 1 (80+80MHz is supported)
|
|
15896
|
164.26
|
9.4.2.237.4
|
|
This field is also valid when R3 is 1 (80+80MHz is supported)
|
|
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.
|
|
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?
|
|
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)
|
|
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?
|
|
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
|
|
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).
|
|
15820
|
174.20
|
9.4.2.242
|
|
The default value for the resource request buffer threshold exponent is missing from the description.
|
|
15637
|
179.10
|
Table 9-262ag
|
|
Table Title should include RSSI
|
|
16443
|
181.17
|
9.6
|
|
Coordination between Aps is needed to ensure good utilization of DL OFDMA and TWT. Provide some simple coordination mechanism or at least signaling that allows Aps
and STAs to exchange information regarding their scheduled activity.
|
|
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.
|
|
15047
|
189.14
|
9.6.28.4
|
|
OPS frame doesn't carry Vendor Specific element
|
|
15158
|
203.05
|
10.3.1
|
|
Under 1st criteria if an HE AP that "is NOT a TXOP holder" shall update the NAV if all 3 conditions are met.The 2nd criteria if an HE AP "is a TXOP holder" shall
update the NAV if all 4 conditions are met. 3 of the 4 conditions are the same in both criteria.
|
|
16588
|
209.02
|
10.7.5.1
|
|
6 GHz band is enabled for 11ax AP and non-AP STA. In 6 GHz band, there is no non-HE STA, and transmission of beacon frame with non-HT format is then not a requriement,
and enabling beacon transmission with HE SU PPDU format is then possible. HE SU PPDU maybe transmitted with larger MPDU content and higher data rate. These features are beneficial because when multiple BSSID concept is used larger MPDU content is reuqired
for carrying all nontransmitted BSSID profiles, and higher data rate can redcue the transmission overhead.
|
|
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.
|
|
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
|
|
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?
|
|
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.
|
|
16172
|
242.43
|
11.23.1
|
|
The set of features that TDLS STAs may and shall not use needs to be specified
|
|
15940
|
243.24
|
11.24.2.8
|
|
The "color in use" (report) mechanism is not well described. How does this differ from (or relate to) "color collision"? How can a non-AP STA be using a color, if
that color is not in collision? And, clearly, the non-AP STA should not report the associated AP's own color to it, even thought the non-AP STA is using that color to talk to it.
|
|
16465
|
243.26
|
11.24.2.8
|
|
According to DCN456r1, a HE STA can have two BSS colors. In this subcluause, it says "The BSS color in use event report enables a non-AP HE STA to inform a BSS color
in use by the non-AP HE STA to its associated AP." It is not clear whether the BSS color in use event report is the same as that of the accocitated AP or not.
|
|
17046
|
243.31
|
11.24.2.8
|
|
"..., it shall not transmit frames to the non-AP HE STA."The restriction shall be applied only in the valid timer (e.g., OBSS PD SR transmit power restriction period).
|
|
16255
|
253.00
|
27
|
|
The protection rules for HE ER PPDUs are not specified. This was rejected under CID 12736 because "It is generally up to the TXOP holder to decide if RTS frame or
MU-RTS Trigger frame will be used for protection at the start of the TXOP. Hence, the spec does not need to mandate the protection operation when an HE ER SU PPDU is transmitted." However, the point is to protect non-ER STAs (including non-HE STAs) from the
ER SU PPDUs, not protecting the TXOP per se
|
|
16605
|
278.20
|
27.5.1.1
|
|
This language belongs to a PHY section
|
|
16128
|
278.24
|
27.5.1.2
|
|
"If an RU is intended for an AP, then the STA_ID_LIST contains only one element that is set to the 11 LSBs of the AID of the non-AP STA transmitting the PPDU." contradicts
other statements like "Each element of the TXVECTOR parameter STA_ID_LIST identifies the STA or group of STAs that is the recipient of an RU in the HE MU PPDU." in 27.11.1 and "for an HE MU PPDU and indicates the STA or group of STAs that is the recipient
of an RU" in 8.3.5.2.2 and " The STA-ID field in each User field indicates the intended recipient user of the corresponding spatial streams and the RU." in 28.3.2.5
|
|
15944
|
278.35
|
27.5.1.2
|
|
A receiving non-AP STA can't possibly know what the AP set in its TXVECTOR parameter to its PHY.
|
|
15679
|
278.51
|
27.5.1.3
|
|
Many restrictions in the text to restrict 26-tone RU use cases in 5G. For example: must satisfy N * 4 * 26-tone for the entire PPDU; at least 2x26-tones has to be
modulated for each 20MHs subchannel. Instead of adding these restrictions, propose to eliminate 20-tone RU for 5G, restrict it to be used in 2.4G only.
|
|
15718
|
278.63
|
27.5.1.3
|
|
What is OBSS B? what does B refer to?
|
|
16168
|
290.05
|
|
|
"(A-)MPDU" is wrong because an A-MPDU and an MPDU are quite different things (one contains the other)
|
|
16584
|
296.00
|
|
|
An HE AP has no way of knowing if there is an unassociated STA or STAs wanting to join the BSS, so it frequently allocates RA RUs with AIDs 2045 for unassociated
STAs to transmit UL. This is very inefficient because most of the time, there is no STAs wanting to associate. Regardless of the setting of its dot11OFDMARandomAccessOptionImplemented, an HE STA should contend for the WM using EDCA for sending UL frames to
the HE AP with which it intends to communicate, then follows the UORA procedure if its dot11OFDMARandomAccessOptionImplemented is set to true.
|
|
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.
|
|
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."
|
|
15955
|
353.01
|
27.1.1
|
|
"The AP may include only one element with" -- I think the intent here is that it shall not include more than one, but that is not what it says
|
|
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
|
|
15743
|
361.01
|
27.14
|
|
The intra-PPDU power save is STA internal operation and it is not visible outside of the device. Such a feature should not be described in the specification, because
it is totally invisible ourside of the device and optional for the STA. The ax specification should specify signaling or operation that is needed to ensure good interoperability of the devices.
|
|
15839
|
361.06
|
27.14.1
|
|
Intra PPDU power save can also be used by active STAs. The statement currently only refers to "move to doze state" so this should be change to something such as "become
unavailable" to cover the unavailability of any STAs, in active mode or PS mode.
|
|
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?
|
|
16780
|
390.20
|
|
|
Enumerated formats are ususally indicated with a name and a brief explanation (see other instances of enumerated type in Table 28-1).
|
|
16781
|
394.14
|
|
|
"8 bits for 20 MHz and 40 MHz PPDU;16 bits for 80 MHz PPDU;32 bits for 160 MHz and 80+80 MHz PPDU."This is the number of bits per content channel. This would not
cover the total BW for 40, 80 and 160 MHz.
|
|
16782
|
395.40
|
|
|
"1x HE-LTF for 3.2 ╬╝s". By definition, 1x HE-LTF means 3.2 usec.
|
|
16783
|
399.26
|
|
|
Shouldn't entry on column "RXVECTOR" be "MU" instead of "Y" for NDP_REPORT?
|
|
16784
|
402.17
|
|
|
"Set to 1 to indicate that midambles are present.". For consistency with other rows, change to "Set to 1 to indicate that midambles are present in the expected HE
TB PPDU".
|
|
17056
|
677.15
|
G.5
|
|
"(Trigger) | (Trigger +a-mpdu + mu-user-respond + a-mpdu-end) 1{Data[+HTC]+QoS+(no-ack | block-ack)+a-mpdu}+ a-mpdu-end; [+mu-user-respond other-users];"Syntax of
the above formula is not correct.
|
|
17054
|
677.15
|
G.5
|
|
"dl-mu-sequence | ul-mu-sequence | cascading-mu-sequence"An dl-mu-sequence, ul-mu-sequence and cascading-mu-sequence are not defined.
|
|
17055
|
677.15
|
G.5
|
|
The usage case of the He-mu-sequence is not inclued in the basic sequence.
|
|
16701
|
677.17
|
Annex G
|
|
Annex G is incomplete.
|
|
15912
|
677.31
|
G5
|
|
MU-RTS can't be transmitted with HTC
|
|
16075
|
677.52
|
G.3
|
|
The production rules are incomplete
|
|
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.
|
|
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
|
|
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
|