Re: [STDS-802-11-TGAX] Assignees for unassigned comments

[Bo Sun <sun.bo1@xxxxxxxxxx>]

Hello, Robert, 

You can assign below CIDs to me. They belong to xVector topic.

16828	383.20	28.2.1		Need to include the new item TRIGVECTOR to the introduction section.
16736	384.48			Define 'HE Training Symbols" when it is first introduced
16831	395.00	28.2.2		The second 1x, 2x, 4x in the respective line seems unnecessary.
15969	395.40	28.2.2		"a 1x HE-LTF for 3.2 us" is confusing. Should always use the x notation
16004	397.32	28.2.2		"If the PPDU contains at least one MPDU whose RA field is broadcast group address, then the value of NOMINAL_PACKET_PADDING is 16 us." -- this should not be buried  in the TXVECTOR table

Best Regards,

Bo

原始邮件

发件人：Stacey,Robert <robert.stacey@xxxxxxxxx>

收件人：STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx>;

日 期 ：2018年10月18日 22:39

主 题 ：[STDS-802-11-TGAX] Assignees for unassigned comments

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	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

 

 

Editorial comments that either need group discussion or are better resolved along with technical comments on that topic:

comments
CID	Page	Clause	Resn Status	Comment
16008				"a" is a terrible name for the pre-fec padding factor!
16050				It would be clearer if the *XVECTOR parameter were called SCRAMBLER_INITIALIZATION_VALUE
16151				Per 802.11 convention, there should be no "shall" in Clause 9 except the one in the baseline at the start
16327				The generic concept should be "HE compressed beamforming and CQI feedback", by analogy with the baseline's "VHT compressed beamforming feedback". This in turn consists  of HE Compressed Beamforming Report information, HE MU Exclusive Beamforming Report information and/or HE CQI Report information. This in turn gets put into one or more HE Compressed Beamforming And CQI frames
16326				The generic concept should be "HE compressed beamforming and CQI feedback", by analogy with the baseline's "VHT compressed beamforming feedback". This in turn consists  of HE Compressed Beamforming Report information, HE MU Exclusive Beamforming Report information and/or HE CQI Report information. This in turn gets put into one or more HE Compressed Beamforming And CQI frames
16163				There are multiple instances of "ack-enabled A-MPDU"
16224				Multi-STA BlockAcks are very badly named, as they are also used in single-STA contexts
16175				"dynamic fragmentation" is poorly named
16169				Per editorial convetions, need to say "dual carrier modulation (DCM)" the first time the term is used after Clause 3
15608	37.00	3.2		Duplicate entries
15609	37.00	3.2		awkward language needs clarification
15934	37.17	3.2		This definition is getting into normative details of _how_, beyond just the _what_.
15606	37.20	3.2		ambiguous definition
15933	37.24	3.2		This definition is getting into normative details of _how_, beyond just the _what_.
16999	37.54	3.2		"high efficiency (HE) extended range (ER) single user (SU) physical layer (PHY) protocol data unit (PPDU): A Clause 28 (High Efficiency (HE) PHY specification PPDU)  PPDU with the TXVECTOR parameter FORMAT equal to HE_ER_SU.high efficiency (HE) extended range (ER) single-user (SU) physical layer (PHY) protocol data unit (PPDU): An HE PPDU transmitted with HE ER SU PPDU format that carries one PHY service data units (PSDU)  for one user."There are two definitions for the HE ER SU PPDU.
15013	96.21	9.3.1.23		Description of RA field setting for TF is scattered across several paragraphs
16273	99.60	9.3.1.23		There is no value, just confusion/verbosity, in having a Packet Extension subfield itself containing two subfields
15626	122.09	9.4.1.63		DC is not in Acronym list
16167	138.41	9.4.2		"(0, 1 or 2 for MCS 0-7, 1 or 2 for MCS 8, 2 for MCS 9)" and "(0, 1, or 2 for MCS 0-7, 1 or 2 for MCS 8-9, 2 for MCS 10-11)" is duplication. The information about  which values indicate which MCSes is already given elsewhere (e.g. "The Max HE-MCS For n SS subfield (where n = 1, ..., 8) is encoded as follows:--- 0 indicates support for HE-MCS 0-7 for n spatial streams" etc.
15879	138.41	9.4.2.158.3		Change to "...that MCS (0, 1 or 2 for MCS 0-7, 1 or 2 for MCS 8, 2 for MCS 9)"
15635	177.00	9.4.2.244.3		poor grammar
15939	243.26	11.24.2.8		Parse problemThe first sentence of 11.24.2.8 does not parse properly.
17009	253.13	27.1		"Frame exchanges are still considered as initiated by the STA as defined in Clause 11, and Clause 12 even if the initiating frame of the frame exchange is sent in  response to a Trigger frame as defined in the subclauses below."The intention of this sentence is not clear enough.
16611	295.62	27.5.4		In this language "a STA" can be interpretted as "at least one of the STAs", while the intention seems to be "any of the STAs"
16487	333.00	27.8.1		Table 27-9 is missing HE and the Columns are referring to VHT.
15763	338.58	27.9.2.2		When we receive an inter-BSS CF-END PPDU, we should clear the basic NAV. But if we follow the OBSS PD spatial reuse rules, we should not update the basic NAV and  enter in a spatial reuse transmit power restriction.Maybe something should be clarified in this case, no ?
15375	339.04	27.9.2.2		Conditional
15764	339.40	27.9.2.3		When we receive an inter-BSS CF-END PPDU, we should clear the basic NAV. But if we follow the OBSS PD spatial reuse rules, we should not update the basic NAV and  enter in a spatial reuse transmit power restriction.Maybe something should be clarified in this case, no ?
15376	339.53	27.9.2.3		Conditional
16682	347.53	27.1		The sublcauses in clause 27 are ordered so that low level features are described ahead of high level features. Move "A-MPDU operation" ahead of "HE sounding procedure".
16360	364.47	27.15.2		"An HE STA may transmit an HE SU PPDU to a peer HE STA." -- really? I'd never have guessed
16724	378.00	28.1.1		It looks very strange to have this "not used" cases under "An HE STA shall support the following features".
16520	378.20	28.1.1		"* An RU allocated to a single user in an HE MU PPDU or for an HE TB PPDU with a number ofspatial streams greater than 4". Material may be organized as frequency  information then spatial information.
16705	378.50	28.1.1		"HE ER SU PPDU is not used" is not an item the HE STA shall support
16858	379.20	28.1.1		It seems not clear that (DL OFDMA) is to annotate the whole sentence. Remember, OFDMA is a new function in 11ax. It's good to be clear.
16859	379.22	28.1.1		It seems not clear that (UL OFDMA) is to annotate the whole sentence.
16861	380.16	28.1.1		It seems not clear that (DL OFDMA) is to annotate the whole sentence.
16862	380.19	28.1.1		It seems not clear that (UL OFDMA) is to annotate the whole sentence.
16828	383.20	28.2.1		Need to include the new item TRIGVECTOR to the introduction section.
16736	384.48			Define 'HE Training Symbols" when it is first introduced
16831	395.00	28.2.2		The second 1x, 2x, 4x in the respective line seems unnecessary.
15969	395.40	28.2.2		"a 1x HE-LTF for 3.2 us" is confusing. Should always use the x notation
16004	397.32	28.2.2		"If the PPDU contains at least one MPDU whose RA field is broadcast group address, then the value of NOMINAL_PACKET_PADDING is 16 us." -- this should not be buried  in the TXVECTOR table
16835	407.00	28.2.6.2		Table 28-4: Cannot find CH_BANDWIDTH_IN_NON_HT and DYN_BANDWIDTH_IN_NON_HT in Clause 18 (in 802.11 2016 version).
16525	410.54	28.3.2.1		"The resource units (RUs) defined for DL and UL transmission are as follows" The acronym RU should be defined much earlier e.g. pg 410 line 2 ?
16526	410.58	28.3.2.1		"The 26-tone RU, 52-tone RU, 106-tone RU and 242-tone RU are used in the 20 MHz, 40 MHz, 80 MHz,160 MHz and 80+80 MHz HE MU PPDU format. The 52-tone RU, 106-tone  RU and 242-tone RU are usedin the 20 MHz, 40 MHz, 80 MHz, 160 MHz and 80+80 MHz HE TB PPDU format. The 26-tone RU is usedin the 20 MHz, 40 MHz, 80 MHz, 160 MHz and 80+80 MHz HE TB PPDU format, except when a STA isoperating in an operating class for which the  behavior limits set listed in Annex E includes theDFS_50_100_Behavior (see 27.5.3.2.1 (General) and 27.5.3.3 (STA behavior for UL MU operation)). The106-tone RU is used in the HE ER SU PPDU format." Bullet points for easier reading ?
16528	417.36	28.3.2.2		"The 20 MHz HE MU PPDU and HE TB PPDU with one or more RUs smaller than 242 tones has 7 DC subcarrierslocated at [∩Ç¡3: 3]. The 20 MHz HE SU PPDU, HE MU PPDU and  HE TB PPDU with a 242-toneRU has 3 DC subcarriers located at [∩Ç¡1: 1]. The 40 MHz HE PPDU has 5 DC subcarriers located at [∩Ç¡2: 2].An 80 MHz HE MU PPDU and HE TB PPDU with one or more RUs smaller than 996 tones has 7 DC subcarrierslocated at [∩Ç¡3: 3]. The  80 MHz HE SU PPDU, HE MU PPDU and HE TB PPDU with a 996-toneRU has 5 DC subcarriers located at [∩Ç¡2: 2]. The same structure as used in the 80 MHz HE PPDU is used foreach 80 MHz frequency segment of the 160 MHz and 80+80 MHz HE PPDU. The DC tones are located  onsubcarriers [∩Ç¡11: 11]."; Place in table like Table 28-9 (Null subcarriers)
16529	417.47	28.3.2.2		"The 20 MHz HE PPDU format has 11 guard subcarriers: the 6 lowest frequency subcarriers [∩Ç¡128: ∩Ç¡123]and 5 highest frequency subcarriers [123: 127] as shown in  Figure 28-5 (RU locations in a 20 MHz HEPPDU). The 40 MHz HE PPDU has 23 guard subcarriers: the 12 lowest frequency subcarriers [∩Ç¡256: ∩Ç¡245]and the 11 highest frequency subcarriers [245: 255] as shown in Figure 28-6 (RU locations in a 40 MHz HEPPDU). The  80 MHz HE PPDU has 23 guard subcarriers: the 12 lowest frequency subcarriers [∩Ç¡512: ∩Ç¡501]and the 11 highest frequency subcarriers [501: 511] as shown in Figure 28-7 (RU locations in an 80 MHzHE PPDU). For 160 MHz and 80+80 MHz HE PPDUs, the same number  of lowest frequency and highestfrequency guard subcarriers as 80 MHz are defined at each edge of the 160 MHz and 80+80 MHz.": Place in table like Table 28-9 (Null subcarriers)
15465	419.32	28.3.2.5		"A full bandwidth MU-MIMO transmission using the HE MU PPDU format shall have a value of 1 for the SIGB Compression field in HE-SIG-A," should be "In a full bandwidth  MU-MIMO transmission using the HE MU PPDU format, the SIBG Compression field in the HE-SIG-A shall be set to 1,
16706	421.50	28.3.2.7		"An HE AP shall not allocate an RU in an 160 MHz or 80+80 MHz HE MU PPDU or HE TB PPDU to a 20 MHz operating non-AP HE STA with the 20 MHz In 160/80+80 MHz HE PPDU  In 2.4 GHz Band subfield in the HE PHY Capabilities Information field in its HE Capabilities element equal to 0"
16733	427.01	28.3.4		It says "When the HE modulated fields are located in more than one 20 MHz channel, the pre-HE modulated fields are duplicated over the multiple 20 MHz channels, as  shown in Figure 28-12", but Figure 28-12 doesn't show those fields, and neither the duplication.
15979	460.43	28.3.10.7.2		The wording for DCM and STBC should be the same
16852	475.05	28.3.10.7.4		The subclause title "Encoding and modulation" doesn't seem to be compatible to the content description.
16843	477.36	28.3.10.8.2		The subclause title "Encoding and modulation" doesn't seem to be compatible to the content description. It seems to me that this subclause addresses frequency allocations  for the users.
16713	481.00	28.3.10.8.3		The nararration on page 482 L62-65 is more accurate and could be carried over to page 481 L1-4
16992	483.29	28.3.10.8.3		"The mapping of the HE-SIG-B content channels to 20 MHz segments shall be the same as for an 80 MHz PPDU (see Figure 28-29 (Mapping of the two HE-SIG-B content channels  and their duplication in a 160 MHz PPDU when the SIGB Compression field in the HE-SIG-A field of an HE MU PPDU is set to 0)), with the exception that punctured 20 MHz channels shall be excluded." Change to "The mapping of the HE-SIG-B content channels to 20  MHz segments shall be the same as for an 160 MHz PPDU (see Figure 28-29 (Mapping of the two HE-SIG-B content channels and their duplication in a 160 MHz PPDU when the SIGB Compression field in the HE-SIG-A field of an HE MU PPDU is set to 0)), with the exception  that punctured 20 MHz channels shall be excluded."
16536	486.43	28.3.10.8.4		"When signaling RUs of size greater than 242 subcarriers, y2y1y0 = 000-111 indicates number of User fields inthe HE-SIG-B content channel that contains the corresponding  8-bit RU Allocation subfield. Otherwise, y2y1y0= 000-111 indicates number of STAs multiplexed in the 106-tone RU, 242-tone RU or the lower frequency 106-tone RU if there are two 106-tone RUs and one 26-tone RU is assigned between two 106-tone RUs. The binaryvector  y2y1y0 indicates 22 ├ù y2 + 21 ├ù y1 + y0 + 1 STAs multiplexed the RU.z2z1z0 = 000-111 indicates number of STAs multiplexed in the higher frequency 106-tone RU if there are two106-tone RUs and one 26-tone RU is assigned between two 106-tone RUs. The binary  vector z2z1z0 indicates22 ├ù z2 + 21 ├ù z1 + z0 + 1 STAs multiplexed in the RU." article "the" is missing before the word "number" three times in this paragraph
16714	487.45	28.3.10.8.4		The preamble is punctured ... if and only if ....The 'is' reads as a 'must' now, and implies that if RU Allocation 01110001 or 01110010 are used, the corresponding  subbands must be punctured. That is not in sync with the MAC requirements: Section: "27.5.1.3. RU allocation in an HE MU PPDU" which does not state that all non-punctured subbands should have at least 1 RU loaded. Actually, on page 483 L35, it already says  "If preamble puncturing is present, then an RU that overlaps a punctured 20 MHz subchannel shall not be allocated." This new section should only serve to make it more concrete without imposing extra constraints.
16854	496.06	28.3.10.10		Does HE SU PPDU or HE ER SU PPDU incur one RU only? If so, r-th RU in the sentence is confusing. Suggest breaking it up to two sentences to cover SU PPDU and MU PPDU  carrying N_STS and N_STS,r,total, respectively, as defined in table 28-15.
16853	496.11	28.3.10.10		Not sure mentioning N_RX is intentional in a transmit centric paragraph. It seems no particular value. Can we delete the sentence or correct it if it is a typo or  elaborate it if N_RX is intended?
16856	512.19	28.3.10.10		The index u and r on the right hand side of eq. 28-59 are fixed numbers. Should they need to appear on the left hand side of the equation like i_Seg and i_Tx?
16993	518.58	28.3.11.5.4		"First compute initial pre-FEC padding factor value (ainit,u) for each user u using Equation (28-61), and the initial number of OFDM symbols (NSYM,init,u) for each  user u using Equation (28-64) if user u is BCC encoded, or Equation (28-64) if user u is LDPC encoded." Remove "if user u is BCC encoded, or Equation (28-64) if user u is LDPC encoded".
16871	524.06	28.3.11.9		Figures 28-36 through 28-39 use very tiny fonts and are difficult to read.
15572	537.33	28.3.11.6		Can be rephased as "An HE STA shall not transmit an HE MU PPDU with midambles if there is MU-MIMO on any RU".
16716	537.55	28.3.11.16		"When midamble is used in an HE SU PPDU, HE ER SU PPDU or HE MU PPDU, the number of space-timestreams in the PPDU shall not be greater more than that indicated by  the maximum..."
16717	548.37	28.3.18.1		Edits to "N is the number of 20 MHz ppunctured channels. An example transmit spectral mask for Nx20..." to improve readability
15565	645.59	C.3		Change "when" to "after which"

 

 

---

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

---

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