| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hello All,
There are 142 comments without an assignee and another 67 editorial comments that either need group discussion or are better resolved along with technical comments on that topic. If you are working on resolutions to comments and see something here that is related, let me know and I will assign it to you.
Comments without an assignee.
comments
CID
Page
Clause
Resn Status
Comment
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
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1