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

Re: [STDS-802-11-TGAX] Unassigned comments



Hello, Robert

 

I think I can help some PHY CIDs (15 CIDs) to be resolved below

16525,  16526, 16528, 16529, 16852, 16843, 16536, 16854, 16853, 16856, 16993, 16871, 15572, 16716, 16717

 

Regards,

Yujin

 

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxx> On Behalf Of Stacey, Robert
Sent: Wednesday, October 24, 2018 9:40 AM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] Unassigned comments

 

Hello All,

 

There are still around 60 comments without an assignee:

comments

CID

Page

Clause

Resn Status

Comment

Proposed Change

16117

Field values should not be expressed as binary numbers unless it is clear which bit of the binary number is the msb and which is the lsb

Either express such field values as decimal or put them in a table where each bit has its own explicitly numbered column (see baseline)

16857

The document approaches to maturing (very good shape). Because of that, the consistency/accuracy throughout the document is critical. If not done so yet, I suggest we should consider to have at least two independent coders develop the test vectors to verify all the equations given the TXVECTOR as the input. One of them can be the one close to the editing team, and the other one is preferably an outsider. He/she codes it simply from reading the draft standard.

16025

"power boost factor" is generally about the r thing. However, in a couple of instances it is used for something else. To avoid confusion, those other two instances should be reworded to use a different term. "the received power measured based on the non-HE portion of the HE PPDU preamble and captured in the RXVECTOR parameter RSSI_LEGACY in the PHY-RXSTART.indication primitive shall be decreased by 3 dB to compensate for the power boost factor when compared to the OBSS PD level." in 27.9.2.2 and "eta_field,k is the power boost factor of the k-th subcarrier of a given field within an OFDM symbol," in 28.3.9

Change the term from "power boost factor" to "power difference" in the two pieces of cited text

16086

The resolution to CID 12587 suggests that there is no pre-compensation, just compensation

Change "pre-compensat" to "compensat" throughout, case-insensitively and case-preservingly

16115

There are about a dozen instances of wording referring to transmission of a $something "MHz HE TB PPDU". However, for OFDMA the PPDUs do in general not have a width that is a multiple of 20 MHz

Apparently (see CID 12612) "The term refers to PPDUs that are transmitted with CH_BANDWIDTH set to indicate that value. It would be cumbersome to use "TXVECTOR parameter CH_BANDWIDTH that indicates X MHz" so we use the shorthand "x MHz PPDU"". If that's the intent of the wording, it needs to be stated somewhere

16124

"HESIGA_Spatial_reuse_value15_allowed" is a very odd and unclear (what is value 15) field name?

Change to "SRP And Non-SRG OBSS_PD Allowed" throughout (per CID 12655's resolution)

16146

That an AP with >= 4SS needs to support DL MU-MIMO is stated too many times

Delete in at least one of 4.13.4a, T9-262aa, 27.6.2, 28.1.1, 28.3.3.9.2

16150

An S-MPDU is a type of MPDU, so "MPDU or S-MPDU" is pleonastic

Delete "or S-MPDU" in "MPDU or S-MPDU" throughout

16156

"left" and "right" are not well-defined for frequencies

Fix "NGuard,Left", "NGuard,Right", "LTF80MHz_left_1x", "LTF80MHz_right_1x", "LTF80MHz_left_4x", "LTF80MHz_right_4x"

16171

"long GI" from the baseline needs to be changed since it is now the shortest of the three GIs for ax

In the baseline, change "short GI" to "400 ns GI" and "long GI" to "800 ns GI" throughout

16190

Various places that explicitly refer to HE SU PPDUs need to also refer to HE ER PPDUs

Add references to HE ER PPDUs after the reference to HE SU PPDUs in 27.4.5, 27.15.3, 28.3.11.2, 27.4.4.2, Table 28-15, 28.3.11.5.1

16191

Need to be clearer the packet extension is completely distinct and independent from the signal extension (also need to make sure the HE PHY is mentioned wherever the ERP/HT PHYs are currently mentioned for signal extension, in the baseline)

As it says in the comment

16192

Sometimes the spec wording indicates that an RU is necessarily less than the full PPDU bandwidth, sometimes it indicates that a non-OFDMA transmission contains a single RU of the same width as the PPDU bandwidth

State that a full-width transmission is an RU, and then simplify things like "HE-MCSs for 242-tone RU and non-OFDMA 20 MHz, NSS = 1" to "HE-MCSs for 242-tone RU, NSS = 1"

16282

It seems from the resolution to CID 12927 that the intent is that an ack-enabled multi-TID A-MPDU is not an ack-enabled A-MPDU. Some parts of the spec (e.g. T9-422, T9-425, T9-428, 27.3.3.2/3, 27.10.4.1 in part) support this interpretation, but others suggest an aeAM can be an aeMTAM

Add to the definition in 3.2 of ack-enabled A-MPDU that the TIDs of all the QoS Data frames are the same. Extend "A-MSDU InA-MPDU Support" in T9-262zz and 10.12 to also apply to aeMTAMs. Extend 27.5.3.4, 27.10.2 (2x) to refer to aeMTAMs too where they refer to aeAMs. Add a NOTE in 27.10.4.1 after the definition of aeMTAMs: "NOTE--An ack-enabled multi-TID A-MPDU is not an ack-enabled A-MPDU."

16296

The concept of "would be acknowledged with an Ack frame if it were the only one in the A-MPDU, but since it isn't it gets acknowledged with a particular setting of the Per AID TID Info subfield in a Multi-STA BlockAck frame" recurs but is inconsistently referred to

Change all references to soliciting an Ack etc. to soliciting the acknowledgment context per 27.4.2

16373

Do not use the Symbol font anywhere, as this introduces proprietary Unicode codepoints that are not found in search (cf. CID 12705 resolution)

Change all uses of the Symbol font to Times New Roman

16090

The MAC requirements on HE STAs should be in Clauses 10 and 11, not in a separate subclause. Otherwise it is not clear which of the Clause 10/11 requirements apply to HE STAs

Move the MAC requirements to the MAC/MLME clauses

17052

The premable puncturing mechanism on the DFS channels is useful to improve the spectrum efficiency.Please refer the submission (11-18-0496r03).

As in comment.

16354

The baseline does not allow EOF=0 MPDUs after EOF=1 MPDUs, but ack-enabled multi-TID A-MPDUs can be like that

Soften the baseline to allow this in PPDUs exchanged between HE STAs

16357

There are various references to A-MPDUs that solicit an immediate response. However, A-MPDUs don't do this, only the constitutent MPDUs do

Reword in terms of the MPDUs soliciting an immediate response, not the A-MPDU itself

16363

Preamble puncturing is inadequately defined and described. Needs to be clearer that it's basically about using OFDMA and restricting the allocated RUs

As it says in the comment

16378

We need to look at the PPDU type to decide whether to respond to a DL MU PPDU anyway (because Action frames are allowed and do not have an ack policy), so the HTP Ack ack policy has no value -- just use Normal Ack/Implicit BAR

Delete the references to HTP Ack throughout the draft and instead state that the rules previously described as pertaining to that ack policy instead pertain to frames received by a non-AP STA in an HE MU PPDU

15929

33.10

3.1

The intention seems to be that A-MSDUs can now be fragmented. There are assumptions in legacy MAC/PHY that will likely break (because the baseline text now assumes all A-MSDUs could be a fragment unless stated otherwise, so it needs to be clearly stated otherwise where things will break), and there are other places in the text that are inconsistent with this.

Add to the definition of GCR frame, that it must be an unfragmented A-MSDU. Correct the statement in the Note following the defintion of MMPDU that says, "An A-MSDU is trasmitted in one MPDU." In the first sentence of 10.4, add that the MAC may fragment and reassemble A-MSDUs, also, (but only if it is HE and the peer is HE and both support A-MSDU Fragmentation). Clarify the extent of the Editor's instruction at P109.6. Does this apply to _every_ occurance of A-MSDU in the entire rest of the Standard? (Surely, not.) There are probably more examples.

16385

33.14

3.1

Does the MU MIMO definition intend to cover OFDMA case as well (which I doubt). If not, then may I suggest to add an emphasis on the subcarrier notion or allocation, something like:"multi-user multiple input, multiple output (MU-MIMO): A technique by which multiple stations(STAs), each with one or more antennas, either simultaneously transmit to a single STA with more than one antennas or simultaneously receive from a single STA with more than one antennas independent data streams over the same radio frequency resources"A bit Ambiguous (frequencies

As in comment.

16851

33.22

3.2

Suggest adding the usage description of preamble puncturing since this is a new function for 11ax. It's not about the English definition but about when and how it is implemented.

15932

33.56

3.2

Did this definition really mean to use the Clause 19 (and not Clause 21) spectral mask? Bullet (e) for VHT STAs is only constrained by the clause 21 mask ( -40 dBr at the extreme skirts). Further, since an HE STA _is_ a [V]HT STA, bullets (h) and (e) become contradictory.

Specify the same spectral mask requirements as done for VHT, to make backward implementation easier.

15931

36.38

3.1

Are A-MSDUs still Bufferable Units for HE STAs?

Add "and high efficiency (HE) STAs" to the list of STA types that handle A-MSDUs. Similarly for Individually Addressed BU defintion. Similarly, in NOTE 4 of Table 9-25. There are probably more with slightly different syntax.

15184

36.53

3.2

The definitional sentence is made difficult to read by superfluous information and biclauses. Other definitions of XXX-Ids indicate that they define identifiers (for instance the definitions of FMSID on p. 150, R0KH-ID on p. 158 or TSID on p. 165 of IEEE Std 802.11-2016) and what the identifier identifies. Further, the list of elements from which the identifier can be derived could be made more compact.

Change to "An identifier assigned to a basic service set (BSS) if the multiple BSSID capability is supported and which is not transmitted explicitly. This identifier can be derived from the information encoded in Probe Response, Beacon, directional multi-gigabit (DMG) Beacon frames and Neighbor reports."

15935

37.31

3.2

Aren't all MU PPDUs "downlink" MU PPDUs?

Why do we need a definition of "downlink MU PPDU"?

16846

38.26

3.2

Starting line 26 on page 38 (section 3.2 definition) " ... HE TB PPDU ... is capable of .... (PSDU) for one or more users" seems conflicting with " ... number of users for an ... or HE TB PPDU is always 1" as stated in the Note of NUM_USERS in TXVECTOR (Line 55, p. 393).

Please clarify and update accordingly if agreed.

15936

39.10

3.2

Saying that an RU is (even with a specific list of subcarrier options) an "allocation unit" doesn't help, if "allocation unit" isn't used or defined anywhere.

Change definition to, "a group of 26, 52, 106, 242, 484, 996 or 2×996 subcarriers allocated to a particular user of the channel, within a data transmission to or from several users of the channel."

17001

39.17

3.2

There should be the definition of Spatial Reuse Group (SRG) in subclause 3.2.

As in the comment.

16375

65.00

9

There should be no behavioural requirements in Clause 9, which is about format only

Move all behavioural requirements to Clause 27/28

16155

122.00

"left" and "right" are not well-defined for frequencies

At 122.14 change "For the left of" to "Below"At 122.18 change "For the right of" to "Above"

17044

154.38

9.4.2.237.2

Please clarify whether the OM Control UL MU Data Disable RX Support is a capablity variable or a control variable.

As in comment.

15632

162.40

Table 9-262aa

Two fields listed twice, TX 1024-QAM Support < 242-tone RU and RX 1024-QAM Support < 242-tone RU are listed twice in the table

remove one set of the TX and RX 1024-QAM Support

15895

164.15

9.4.2.237.4

This field is also valid when R3 is 1 (80+80MHz is supported)

As in the comment

15896

164.26

9.4.2.237.4

This field is also valid when R3 is 1 (80+80MHz is supported)

As in the comment

15666

165.51

9.4.2.237.5

"The PPE Thresholds field determines the minimal packet extension value (see 28.3.12 (Packet Extension))...", according to other places of the spec such as 27.12 and 28.3.12, this is not for "minimal packet extention value", but rather the maximum of norminal packet extension duration.

Clarify

15667

166.01

9.4.2.237.5

"The NSTS subfield contains an unsigned integer that is the number of NSTS values minus 1 for which PPEthreshold values are included in the PPE Thresholds Info subfield."--what if the NSTS subfield here has a value smaller than the maximum NSTS value as indicated by the Rx HE-MCS Map table? Does it mean for those NSTS, PPET8 and PPET16 are all zero?

Clarify

16002

166.11

9.4.2.237.5

"6 x (NSTS + 1) bits" -- need to be clear this is the field value rather than the NSTS itself (which is one more than the field value)

After the cited text at the referenced location add ", where NSTS is the value in the NSTS field,"

15663

167.01

9.4.2.237.5

"Each PPET8 NSTSn RUb and PPET16 NSTSn RUb subfield contains an integer that corresponds to a constellation index value related to the minimal transmission constellation of an HE PPDU as defined inTable 9-262ac (Constellation index)."--the minimal transmission constellation for what? Also what "transmission" mean? SHould this be for reception capability?

Change to: ..minimal reception constellation of an HE PPDU that supports the maximum Nominal Packet Extension duration (TPE) when pre-FEC padding factor equals to 4 being 8 us and 16 us respectively, as defined in...

16325

167.33

9.4.2.237.5

"The value of the PPET8 NSTSn RUb subfield is always less than the value of the PPET16 NSTSn RUb subfield, except if the PPET8 subfield is 7." -- there are other constraints

Add the other constraints, e.g. value for NSSi must be no more than for NSSj for given RUm, if i > j

15899

174.01

9.4.2.242

Other resource request may have threshlod value. An AP may support some of them. Based on this observation, it is better to have a Control field with each bit indicates whether an AP supports the NDP feedback report and the related threshold value (followed by optional threshold fields).

As in the comment

15820

174.20

9.4.2.242

The default value for the resource request buffer threshold exponent is missing from the description.

Add the default values in the description of the

15637

179.10

Table 9-262ag

Table Title should include RSSI

Change "Value" to "Encoded Value" and "Description" to "RSSI Value"

15262

186.33

9.6.25.9

Some collective deliberations will be required to bring structure to this entire subclause. Fig 9-740b1 is not referenced anywhere, and the sentences look half-baked.

As in comment.

15904

216.10

10.12

Ack-enabled A-MPDU is like an S-MPDU where the QoS Data asks for Ack. So A-MSDU In A-MPDU is not needed.

Remove A-MSDU In A-MPDU from the draft

16250

216.37

10.13.2

"A STA indicates in the Maxi-mum A-MPDU Length Exponent field in its HT Capabilities, VHT Capabilities and HE Capabilities elementsthe maximum length of the A-MPDU pre-EOF padding that it can receive in an HE PPDU." is not true if the Maximum A-MPDU Length Exponent Extension field is not 0

Change Subclause 10.13.2 to add caveats on the A-MPDU length rules for STAs whose Maximum A-MPDU Length Exponent Extension is non-zero

15905

217.53

10.13.3

DMG STA doesn't consider Minimum MPDU Start Spacing for QoS Null. However HE STA considers Minimum MPDU Start Spacing for QoS Null. What is the reason for such difference?

Clarify it.

17129

232.09

10.28.3

In the last sentence, it mentions that the duration indicated by the Duration/ID field is available for the RD response burst and RD initiator final PPDU. It doesn't include the HE TB PPDU that send by RD initiator that follows the Basic Trigger that send by RD responder.

modify the text to include the HE TB PPDU that send by RD initiator.

16172

242.43

11.23.1

The set of features that TDLS STAs may and shall not use needs to be specified

In the referenced subclause add "A TDLS STA shall not transmit an HE MU PPDU or HE TB PPDU to a peer TDLS STA."

16763

346.00

"minus a safety margin value not to exceed 5 dB". Why do we need to specify this value and be so specific about setting the value of the Acceptable Interference Level? The Acceptable Interference Level is determined by the AP and should be left to implementation.

Use more generic wording like "should be chosen by the AP to ensure correct reception in the presence of the expected interference"

15716

350.43

29.9.2.5

This clause describes the case that a STA ignores an OBSS PPDU following procedure of 27.9.2.2 or 27.9.2.3 and not able to transmit within the received inter-BSS PPDU duration. The STA starts an OBSS PD SR transmit power restriction period may not be able to gain TXOP for a long duration (e.g., receive intra-BSS PPDUs), the OBSS PD SR transmit power restriction period should not be applicable anymore after some duration. Please change to "This OBSS PD(#11726) SR transmit power restriction period shall be terminated at the end of the TXOPthat the STA gains once its backoff reaches zero." to "This OBSS PD(#11726) SR transmit power restriction period shall be terminated at the end of the TXOP that the STA gains once its backoff reaches zero or exceeds max TXOP limit."

as described

16323

358.33

27.12

It is not clear what to do if the PPET8 and PPET16 comparisons in Table 27-12 give different rows

Express as a list: if then the Nominal Packet Padding value is 16 us, otherwise if then 8 us, otherwise 0 us.

16686

365.50

Clause 10.7.6.5.3 in 802.11-2016 defines MCS selection for a control response frame. It is not clear how this applies to the use of HE ER SU PPDUs carrying control response frames. For example, how is DCM applied?

Clarify the MCS seelction rules for control response frames that are sent in HE ER SU PPDUs. I would suggest that we make this implementation dependent, i.e., don't have strong rules, and allow the

15943

679.01

T

Annex T should be updated to discuss BSS color as another method (for HE BSSs) to use for overlapping BSSs, and to give recommendations on its usage.

Add recommendations on use of BSS color to Annex T.

16067

679.04

AA

There should be an example where non-MU-MIMO RUs are skipped over (i.e. unused) by using STA-ID 2046

As it says in the comment

16079

2391.04

12.6.18

"NOTE 2---Because the IEEE 802.11 Null frame does not derive from an MA-UNITDATA.request primitive, it is not protected." -- the real reason is that there is nothing to protect. Some TDLS frames, for example, are not derived from MA-UNITDATA.requests, but are protected nonetheless. It's not clear what the point of this NOTE is anyway

Delete the cited text at the referenced location, and delete the " 1" immediately above

 

 

A few that I’ve passed to the MAC ad-hoc for resolution (currently assigned to Editor):

comments

CID

LB

Commenter(E)

Vote

Type of Comment T/E(C)

Page

Clause

Duplicate of CID

Resn Status

Comment

Proposed Change

Resolution

Owning Ad-hoc

Comment Group

Ad-hoc Status

Ad-hoc Notes

Assignee

16224

233.00

Mark RISON

E

Multi-STA BlockAcks are very badly named, as they are also used in single-STA contexts

Change "Multi-STA BlockAck" to "Extended BlockAck" throughout

MAC

Editorials

Editor

16175

233.00

Mark RISON

E

"dynamic fragmentation" is poorly named

Rename it to "variable-length fragmentation"

MAC

Fragmentation

Editor

15933

233.00

Mark Hamilton

E

37.24

3.2

This definition is getting into normative details of _how_, beyond just the _what_.

Stop the defintion of "broadcast resource unit" before (without) describing how it is identified.

MAC

Editorials

Asking for a technical change

Editor

15939

233.00

Mark Hamilton

E

243.26

11.24.2.8

Parse problemThe first sentence of 11.24.2.8 does not parse properly.

Change to "... to inform its associated AP that a BSS color is in use by the non-AP HE STA."

MAC

HE BSS

I can't make head or tails of this sentence. It looks like the non-AP HE STA is sending the report to it "assocaited AP", but it is not clear whether the second non-AP HE STA is itself or some other STA. Passing to ad-hoc.

Editor

17009

233.00

Yasuhiko Inoue

E

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.

Clarify, or remove this sentence.

MAC

Editorials

Editor

16487

233.00

Naveen Kakani

E

333.00

27.8.1

Table 27-9 is missing HE and the Columns are referring to VHT.

Make the following change:Edit Table 27-9:1. Delete the last two columns as the intent is to signal the Nss for 160MHz and not the center frequency2. Change the header of the column starting with "VHT NSS Support" to "NSS Support"

MAC

OM Control

Editor

16360

233.00

Mark RISON

E

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

Express this in such a way that it seems less of a statement of the bleeding obvious!

MAC

Editorials

Editor

15565

233.00

Amelia Andersdotter

E

645.59

C.3

Change "when" to "after which"

As in comment.

MAC

Editorials

Technical issue - passing to ad-hoc for resolution. I woud assume it indicates the amout of time that can pass since the since a non-AP STA received a Beacon frame carrying the "Narrow Band Tolerance indication" (whatever that is) before it does something. It doesn't say that.

Editor

 

And a few that I’ve passed to the PHY ad-hoc for resolution (currently assigned to “Editor”):

comments

CID

LB

Commenter(E)

Vote

Type of Comment T/E(C)

Page

Clause

Duplicate of CID

Resn Status

Comment

Proposed Change

Resolution

Owning Ad-hoc

Comment Group

Ad-hoc Status

Ad-hoc Notes

Assignee

16008

233.00

Mark RISON

E

"a" is a terrible name for the pre-fec padding factor!

Change all uses of "a" as the PFPF to "PFPF"

PHY

Editorials

Editor

15609

233.00

Carol Ansley

E

37.00

3.2

awkward language needs clarification

change "that uses masked HE-LTF sequence" to "that masks the HE-LTF sequence"

PHY

Editorials

The grammar (case) is wrong here. But is it "uses masked HE-LTF sequences" or is it "uses a masked HE-LTF sequence" (one sequence or one or more sequences)?

Editor

15626

233.00

Carol Ansley

E

122.09

9.4.1.63

DC is not in Acronym list

Add DC to acronym list, maybe defined as center frequency

PHY

Editorials

Editor

16724

233.00

RUI YANG

E

378.00

28.1.1

It looks very strange to have this "not used" cases under "An HE STA shall support the following features".

It is better to create a paragraph to include all "not supported" cases

PHY

Editorials

Editor

16520

233.00

Oghenekome Oteri

E

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.

bullet point three: "An RU allocated to a single user in an HE MU PPDU""bullet point five: "An RU allocated for an HE TB PPDU with a number ofspatial streams greater than 4

PHY

Editorials

Editor

16705

233.00

ron porat

E

378.50

28.1.1

"HE ER SU PPDU is not used" is not an item the HE STA shall support

Move it to a sub-item to the previous line "Single spatial stream HE-MCS ..." similar to the BCC requirement at line 15 of the same page.

PHY

Editorials

Editor

16858

233.00

Song-Haur An

E

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.

Transmission of DL OFDMA in an HE MU PPDU where none of the RUs utilizes MU-MIMO.

PHY

Editorials

Passing to ad-hoc for discussion. My personal opinion is that we should not get too carried away enumerating all the support requirements in the introduction. A few general statements about the HE PHY should sufficient. For example, "The HE PHY supports DL and UL OFDMA and DL and UL MU-MIMO."

Editor

16859

233.00

Song-Haur An

E

379.22

28.1.1

It seems not clear that (UL OFDMA) is to annotate the whole sentence.

Transmission of UL OFDMA in an HE TB PPDU where none of the RUs utilizes MU-MIMO.

PHY

Editorials

Passing to ad-hoc for discussion. My personal opinion is that we should not get too carried away enumerating all the support requirements in the introduction. This is a good example. The HE PHY by design supports UL OFDMA. OFDMA is an access technique -- a technique for multiplexing users in the frequecy domain. It is not something that a STA transmits. The introduction should make general statements about the HE PHY design instead of making detailed individual statements on narrow aspects that shall or may be supported.

Editor

16861

233.00

Song-Haur An

E

380.16

28.1.1

It seems not clear that (DL OFDMA) is to annotate the whole sentence.

Transmission of DL OFDMA in an HE MU PPDU where the RU allocated to the non-AP STA is not utilizing MU-MIMO.

PHY

Editorials

Passing to ad-hoc for discussion

Editor

16862

233.00

Song-Haur An

E

380.19

28.1.1

It seems not clear that (UL OFDMA) is to annotate the whole sentence.

Transmission of UL OFDMA in an HE TB PPDU where the RU allocated to the non-AP STA is not utilizing MU-MIMO.

PHY

Editorials

Passing to ad-hoc for discussion

Editor

16835

233.00

Song-Haur An

E

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

Please discard both terms from the Clause 18 column when confirmed.

PHY

Editorials

Passing to PHY ad-hoc. I believe this is a technical issue. 11ac added BW signaling to the 5 GHz band PHY (Clause 17) but not to the 2.4 GHz band PHY. I think we need it in the 2.4 GHz band PHY as well (for 40 MHz NDP Announcement frame).

Editor

16525

233.00

Oghenekome Oteri

E

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 ?

As in comment

PHY

Editorials

Editor

16526

233.00

Oghenekome Oteri

E

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 ?

Make into bullet points

PHY

Editorials

Editor

16528

233.00

Oghenekome Oteri

E

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)

Have reference table

PHY

Editorials

Editor

16529

233.00

Oghenekome Oteri

E

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)

Have reference table

PHY

Editorials

Editor

15465

233.00

Amelia Andersdotter

E

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,

As in comment.

PHY

Editorials

Editor

16706

233.00

ron porat

E

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"

160MHz not applicable in 2.4GHz band.Need to change band details.

PHY

Editorials

Editor

16733

233.00

RUI YANG

E

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.

Make a new figure to show the duplication of these fields

PHY

Editorials

Passing to ad-hoc for resolution

Editor

16852

233.00

Song-Haur An

E

475.05

28.3.10.7.4

The subclause title "Encoding and modulation" doesn't seem to be compatible to the content description.

Please update accordingly if agreed.

PHY

Editorials

Editor

16843

233.00

Song-Haur An

E

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.

Update accordingly if confirmed.

PHY

Editorials

Editor

16713

233.00

ron porat

E

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

If a single RU overlaps with more than one of the tone ranges[-500:-259], [-258:-17], [17:258] or [259:500] , the corresponding RU Allocation subfields in the respective content channels shall all refer to the same RU.

PHY

Editorials

Editor

16992

233.00

Yan Zhang

E

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

as in comment

PHY

Editorials

Appears to propose a technical change

Editor

16536

233.00

Oghenekome Oteri

E

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

When signaling RUs of size greater than 242 subcarriers, y2y1y0 = 000-111 indicates THE number of User fields inthe HE-SIG-B content channel that contains the corresponding 8-bit RU Allocation subfield. Otherwise, y2y1y0= 000-111 indicatesTHE 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 indicatesT THE 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.

PHY

Editorials

Editor

16714

233.00

ron porat

E

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.

"Preamble puncturing is allowed ... if ..." or "If the preamble is punctured ... then ..."

PHY

Editorials

Editor

16854

233.00

Song-Haur An

E

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.

Please update accordingly if agreed.

PHY

Editorials

Editor

16853

233.00

Song-Haur An

E

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?

Please update accordingly if agreed.

PHY

Editorials

Editor

16856

233.00

Song-Haur An

E

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?

Please clarify.

PHY

Editorials

Editor

16993

233.00

Yan Zhang

E

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

as in comment

PHY

Editorials

Editor

16871

233.00

Stephen McCann

E

524.06

28.3.11.9

Figures 28-36 through 28-39 use very tiny fonts and are difficult to read.

It would be useful to enlarge these figures to the edges of the page, and possibly increase the size of the font by 1 or 2 pts.

PHY

Editorials

Editor

15572

233.00

Bin Tian

E

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

as in comment

PHY

Editorials

Editor

16716

233.00

ron porat

E

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

Change "...PPDU shall not be greater more than that indicated..." to "...PPDU shall not be greater than that indicated.."

PHY

Editorials

Editor

16717

233.00

ron porat

E

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

Denote the number of 20 MHz punctured channels by N. An example transmit spectral mask for Nx20 MHz preamble punctured channel with transmission on both the upper and lower subchannels is shown in Figure 28-51, where the X axis in the plot is centered in the middle of the punctured subbands. Two examples are illustrated below in figures 28-51, 28-52

PHY

Editorials

Editor

 

Any takers?

 

-Robert

 


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