Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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



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