zilongwang/ReadingBank huggingface dataset:
294 Bin Tian 106.17 Eqn (26-20) is not completely right, RL-SIG should have different polarity value p_1 (not p_0) on top of pilot sequence applied on pilot tones Add statement or new equation Revised. Change to as in the resolution of CID1099 in doc ax editor: please make the following changes in Clause 26.3.9.9: On P106L17 (CID #294): CID Commenter Section Page Comment Proposed Change Resolution 1099 Koichi Ishihara 112.21 There is no reference of N^Tone_HE-SIG-A. should be defined in Table 26-6 as follow: "The number of OFDM symbols in the HE-SIG-A field" Revised. Change to as in the resolution of CID1099 in doc On P112L21 (CID #1099): Refer to comment resolution of CID #476. CID Commenter Section Page Comment Proposed Change Resolution 1997 Siguard Schelstraete 104.60 unclear language "two at each edge of the subcarriers used by data and pilot tones" is not clear. Either way, it is redundant given the next sentence. Remove "two at Revised. Change to as in the resolution of CID1997 in doc
each edge of the subcarriers used by data and pilot tones". ax editor: please make the following changes in Clause 26.3.9.5: On P104L60 (CID #1997): Extra 4 BPSK modulated tones are added. CID Commenter Section Page Comment Proposed Change Resolution 1998 Siguard Schelstraete 105.21 TBD TBD has been resolved. See line 28. Revised. Change to as in the resolution of CID1998 in doc On P10521 (CID #1998): Refer to comment resolution of CID #1684. CID Commenter Section Page Comment Proposed Change Resolution 1999 Siguard Schelstraete 105.39 missing reference Change "<reference>" to Table 26-13. Revised. Change to as in the resolution of CID1999 in doc On P105L39 (CID #1999): Refer to comment resolution of CID #476. 2000 Siguard Schelstraete 106.25 TBD Define Revised. Change to as in the resolution of CID2000 in doc On P106L25 (CID #2000): to comment resolution of CID #1846. 2019 Siguard Schelstraete 112.21 reference Correct reference is Table 26-13 Revised. Change to as in the resolution of CID2019 in doc
(26-22) 2540 Youhan Kim 111.41 HE-SIG-A has 52 data tones, so cannot use the interleaver procedure of 11a. Change the reference "18.3.5.7 (Data intereleaving)" to a suitable section of 11n or 11ac. Revised. Change to as in the resolution of CID2540 in doc ax editor: please make the following changes in Clause 26.3.9.7.4: On P111L41 (CID #2540): , 2541 Youhan Kim 112.58 Transmit process for HE-SIG-A2 is not clear. Shouldn't it be highlighted that there is no interleaver? Clarify the transmit process. Revised. Change to as in the resolution of CID2541 in doc On P112L58 (CID #2541): Refer to comment resolution of CID #912. 2542 Youhan Kim 112.64 HE-SIG-A4 should not be using an interleaver. Remove data interleaving from P110L35. Revised. Change to as in the resolution of CID2542 in doc On P112L64 (CID #2542): Refer to comment resolution of CID #913.
by the intended receiver of the frame that is currently under way. *Every* device that is permitted to transmit under current rules will still be allowed to transmit under the rule in the diagram. In addition, many more devices will be allowed to transmit. Even worse, *every* new device that is allowed to transmit will be allowed to do so at a transmit power level that results in the maximum level of interference that would apply under the existing rules: essentially the rule requires the new, interfering transmitter to reduce its transmit power, but only by just enough to get the interference down to that existing maximum. The justifications that have been given for this radical departure from prior practice seem extraordinarily weak, and essentially seem to boil down to (a) a misconception that the current rules constitute a safe harbor, at which the interference caused can be treated as if it didn't exist, and/or (b) the argument that other wireless standards, with entirely different deployment models and a vastly different installed base, do the same thing. This is a reckless attack on the fundamental integrity of 802.11 and on the indispensable attribute of backward compatibility. No evidence has been presented that even begins to justify the changes that are being proposed. whole or in part from the draft. safeguards to those previously approved. The net effect of these changes has been to enable the victim transmitter, subject to permission from the victim AP, to disallow OBSS_PD. The TG considers that the safeguards available, including the ones provided in the above referenced document and others (e.g., exclusion of TXOPs protected by CTS-to-self), provide fully adequate assurance of acceptable operation. Discussion: Document 17/458 describes the need and mechanism to disable OBSS_PD based spatial reuse. This document covers the specification text change required to enable the OBSS_PD spatial reuse feature. TGax Editor: OBSS_PD spatial reuse disable setting to disable OBSS_PD spatial reuse on the transmitted packet, add to 28.16: B15-B18 Spatial Reuse 4 Set to SRP Disallowed to disallow SRP-based spatial reuse (see 27.9 (Spatial reuse operation) and 27.11.6 (SPATIAL_REUSE)). NOTE—This part further development.
NSTS is total number of space-time streams for pre-HE fields when BEAM_CHANGE=0 as defined in Table 26-6 (Frequently used parameters) Table 266 - Frequently used parameters Symbol Explanation NSTS,r,total For HE modulated fields, NSTS,r,total is the total number of space-time streams at the r-th RU in a PPDU. For pre-HE modulated fields, NSTS,r,total is undefined Note that = NSTS for an HE SU PPDU. In addition, replace NSTS,total with in equations (26-11), (26-13), (26-16), (26-19) and (26-21). (26-13) (26-16) (26-19) (26-21) 2540 Youhan Kim 169.8 HE-SIG-A has 52 data tones, so cannot use the interleaver procedure of 11a. Change the reference "18.3.5.7 (Data intereleaving)" to a suitable section of 11n or 11ac. Rejected. It is resolved by resolution of CID #2183. 2541 Youhan Kim 170.26 Transmit process for HE-SIG-A2 is not clear. Shouldn't it be highlighted that there is no interleaver? Clarify the transmit process. Rejected. It is resolved by resolution of CID #912. 2542 Youhan Kim 170.35 HE-SIG-A4 should not be using an interleaver. Remove data interleaving from P110L35. Rejected. It is resolved by resolution of CID #913.
IEEE P802.11 Wireless LANs LB225 CR PHY Miscellaneous Part1 Date: 2017-04-11 Author(s): Name Affiliation Address Phone Yongho Seok NEWRACOM 9008 Research Drive, Irvine, CA, 92618 Interpretation of a Motion to Adopt A motion to approve this submission means that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGax Editor: Editing instructions preceded by “TGax Editor” are instructions to the TGax editor to modify existing material in the TGax draft. As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft. CID Page Clause Comment Proposed Change Resolution 9734 The PHY MIB for HE PLME is missing. Also update the PHY MIB in Annex C. As per comment. Revised- Agree in principle. Add PHY MIB. TGax editor changes as shown in the as specified in 10146 add PHY MIB in new in 28.4 HE PLME As in the comment. Revised- Agree in principle. Add PHY MIB. TGax editor makes changes as shown in the as specified in 9052 Wrong reference "Table 25-1" Correct reference Revised- Agree in principle. TGax editor makes changes as shown in the as specified in TGax editor: Insert the following new subclause 28.4.2 (PHY MIB) after 28.4.1 (PLME_SAP sublayer management primitives):
dot11VHTRxSTBCOptionImplemented Static dot11VHTRxSTBCOptionActivated Dynamic dot11VHTMaxNTxChainsImplemented Implementation dependent Static dot11VHTMaxNTxChainsActivated Implementation dependent Dynamic dot11TransmitBeamformingConfigTable dot11ReceiveStaggerSoundingOptionImplemented Static dot11TransmitStaggerSoundingOptionImplemented Static dot11ReceiveNDPOptionImplemented Static dot11TransmitNDPOptionImplemented Static dot11ImplicitTransmitBeamformingOptionImplemented Static dot11CalibrationOptionImplemented Implementation dependent Static Static Static Implementation dependent Static Implementation dependent Static Implementation dependent Static dot11NumberBeamFormingCSISupportAntenna Implementation dependent Static Implementation dependent Static
Implementation dependent Static dot11VHTTransmitBeamformingConfigTable dot11VHTSUBeamformeeOptionImplemented Static dot11VHTSUBeamformerOptionImplemented Static dot11VHTMUBeamformeeOptionImplemented Static dot11VHTMUBeamformerOptionImplemented Static dot11VHTNumberSoundingDimensions Implementation dependent Static dot11VHTBeamformeeNTxSupport Implementation dependent Static dot11PHYHETable dot11HEDualBandImplemented Static dot11HECurrentChannelWidthSet Implementation dependent Dynamic dot11HEPuncturedPreambleTxImplemented Implementation dependent Static dot11HEPuncturedPreambleTxActivated Implementation dependent Dynamic dot11HEPuncturedPreambleRxImplemented Implementation dependent Static dot11HEPuncturedPreambleRxActivated Implementation dependent Dynamic dot11HEDeviceClass Implementation dependent Static dot11HELPDCCodingInPayloadImplemented Static dot11HELPDCCodingInPayloadActivated Dynamic
IEEE P802.11 Wireless LANs 11ax Comment Resolutions for Clause 26.3.10 Date: 2016-08-23 Author(s): Name Affiliation Address Phone Email Yan Marvell , Santa Clara, CA 95054 408-222-0975 Rui Cao Marvell Hongyuan Zhang Marvell Abstract: This document contains proposed resolutions for comments in Clause 26.3.10 from 11ax D0.4 with the CIDs below. Clause 26.3.10 294 873 1099 1698 1997 1998 1999 2000 2019 2531 2540 2541
NSTS is number of space-time streams for pre-HE fields when BEAM_CHANGE=0 as defined in Table 26-6 (Frequently used parameters) Table 266 - Frequently used parameters Symbol Explanation NSTS,r,total For HE modulated fields, is the total number of space-time streams at the r-th RU in a PPDU. For pre-HE modulated fields, is undefined Note that NSTS,r,total = NSTS for an HE SU PPDU. In addition, replace NSTS,total with in equations (26-11), (26-13), (26-16), (26-19) and (26-21). (26-13) (26-16) (26-19) (26-21) 2540 Youhan Kim 169.8 HE-SIG-A has 52 data tones, so cannot use the interleaver procedure of 11a. Change the reference "18.3.5.7 (Data intereleaving)" to a suitable section of 11n or 11ac. Rejected. It is resolved by resolution of CID #2183. 2541 Youhan Kim 170.26 Transmit process for HE-SIG-A2 is not clear. Shouldn't it be highlighted that there is no interleaver? Clarify the transmit process. Rejected. It is resolved by resolution of CID #912. 2542 Youhan Kim 170.35 HE-SIG-A4 should not be using an interleaver. Remove data interleaving from P110L35. Rejected. It is resolved by resolution of CID #913.
CID PP LL Comment Proposed Change Resolution 6187 193 32 The criteria for distinguishing among S-MPDU, A-MPDU, and multiple TID A-MPDU is not clear enough Need to clarify Rejected. S-MPDU and A-MPDU is defined in IEEE 802.11 2016 specification. Multi-TID A-MPDU is defined in 27.10.4. 6183 193 58 As discussed till now, the shorter BlockAck frame is desirable. When a STA receives all of nonzero length MPDUs with the corresponding EOF subfield set to 0 in a multi-TID A-MPDU, the STA can acknowledge the reception for the MPDUs using a Multi-STA BlockAck frame without the bitmap for the MPDUs indicating each TID. Please extend the case of a Per STA Info subfield without the Block Ack Starting Sequence Control field and the Block Ack Bitmap field. Rejected Discussion: if the other modes of M-BA optimization are introduced, the implementation of M-BA becomes more complicated. We believe opther optimization of M-BA is not needed.
CID PP LL Comment Proposed Change Resolution 6187 193 32 The criteria for distinguishing among S-MPDU, A-MPDU, and multiple TID A-MPDU is not clear enough Need to clarify Rejected. S-MPDU and A-MPDU is defined in IEEE 802.11 2016 specification. Multi-TID A-MPDU is defined in 27.10.4. 6183 193 58 As discussed till now, the shorter Multi-STA BlockAck frame is desirable. When a STA receives all of nonzero length MPDUs with the corresponding EOF subfield set to 0 in a multi-TID A-MPDU, the STA can acknowledge the reception for the MPDUs using a Multi-STA BlockAck frame without the bitmap for the MPDUs indicating each TID. Please extend the case of a Per STA Info subfield without the Block Ack Starting Sequence Control field and the Block Ack Bitmap field. Rejected Discussion: if the other modes of M-BA optimization are introduced, the implementation of M-BA becomes more complicated. We believe opther optimization of M-BA is not needed.
CID PP LL Comment Proposed Change Resolution 6187 193 32 The criteria for distinguishing among S-MPDU, A-MPDU, and multiple TID A-MPDU is not clear enough Need to clarify Rejected. S-MPDU and A-MPDU is defined in IEEE 802.11 2016 specification. A-MPDU is defined in 27.10.4. 6183 193 58 As discussed till now, the shorter Multi-STA BlockAck frame is desirable. When a STA receives all of nonzero length MPDUs with the corresponding EOF subfield set to 0 in a multi-TID A-MPDU, the STA can acknowledge the reception for the MPDUs using a Multi-STA BlockAck frame without the bitmap for the MPDUs indicating each TID. Please extend the case of a Per STA Info subfield without the Ack Starting Sequence Control field and the Block Ack Bitmap field. Rejected Discussion: if the other modes of M-BA optimization are introduced, the implementation of M-BA becomes more complicated. We believe opther optimization of M-BA is not needed.
9.4.2.237 HE Capabilities element 9.4.2.237.2 HE MAC Capabilities Informaiton field TGax editor: Change the row of Ack-enabled Multi-TID Aggregation Support in Table 9-262z as follows ( CID 4793, 7943, 7942, 7941,7940, 8393, 9392, 8401, 7864, 7863, 7962, 7948, 7950, 10332, 9672, 9671): Acknabled Aggregation Support Indicates support by a STA to receive a A-MPDU that solicits(#7765) Ack, as described in 27.10.4 (A-MPDU with multiple TIDs) . Set to 1 when the STA supports reception of this format. Set to 0 otherwise. TGax editor: Change Ack-enabled Multi-TID Aggregation Support to Ack Enabled Aggregation Support through 11ax D1.4 ( CID 4793, 7943, 7942, 7941,7940, 8393, 9392, 8401, 7864, 7863, 7962, 7948, 7950, 10332, 9672, 9671).
The equation of the channel center frequency has been changed in D3.0, so change the paragraph at P165L33 accordingly as follows: “The CDMG PHY operates in the channels defined in Annex E and shall support at least channel number 2, 35 and 36.” Technical comments: CID Clause Comment Proposed Change 510 25.3.4 168 20 T "3054.5 ns=21× Tseq". The value of TSTF (Detection sequence duration) shall be 2618.2 ns=18× Tseq. Change to "2618.2 ns=18× Tseq". 511 25.3.4 138 29 T "7.5636 μs=52× Tseq". The value of TSTF-CP(control mode short training field duration) shall be 7.2727 μs=50× Tseq. Change to "7.2727 μs=50× Tseq". Proposed resolution: Accepted. Correct the errors in the table 25-11 as follows: Tale 25-4 Timing-related parameters Parameter Value … … TSTF: Detection sequence duration 2618.2 ns=18× Tseq 3054.5 ns=21× Tseq TSTF-CP: (control mode short training field duration) 7.2727 μs=50× Tseq 7.5636 μs=52× Tseq … …
IEEE P802.11 Wireless LANs Specification Framework for TGba Date: 2017-04-10 Author(s): Name Affiliation Address Phone email Po-Kai Huang Intel 2200 Mission College Blvd, Santa Clara, CA 95054 +1-765-418-6733 po-kai.huang@intel.com Revision history Revision Date Changes 0 April 10, 2017 Added motioned text agreed in March IEEE F2F Definitions Abbreviations and acronyms DFS dynamic frequency selection OFDM orthogonal frequency division multiplexing
types of Beacon frames. 7961 Mark RISON 141.37 11.1.3.10 For dual beacons to work w.r.t. both non-HE STAs and distant HE STAs, group-addressed traffic needs to be sent twice, once after each of the beacon types After "When Beacon frames are transmitted in two PHY formats, the HE AP shall transmit Beacon frames in non-HE format and in HE_EXT_SU format." add "The HE AP shall transmit buffered non-GCR-SP group addressed BUs twice, once immediately after each of these Beacon frames, when they are DTIM Beacons frames (see 11.2.3.4)." Also add a bit to HE Operation to indicate which kind of beacon it is (cf. STBC Beacon in 802.11-2016 page 953) Revised. The Dual Beacon mechanism is deleted. See proposed change in doc. 11-17/0576r1. 7978 Mark RISON 141.44 11.1.3.10 "The Beacon frame transmitted in HE extended range SU PPDU has TBTT at the TSF value 0 plus the TBTT offset which value is a half of the value of the Beacon Interval field of the Beacon frame sent in non-HE format." is unclear Change to "The TBTT for the Beacon frame transmitted in HE extended range SU PPDU format shall be offset by half of a beacon interval from the TBTT of the Beacon frame transmitted in PPDU format." Revised. The Dual Beacon mechanism is deleted. See proposed change in doc. 11-17/0576r1. 7979 Mark RISON 141.50 11.1.3.10 "The non-HE format and HE EXT_SU PPDU format Beacon frames may contain different set of elements." is far too loose Change to "Except for the setting of the TIM field and TSF field, all other fields inside the Beacon frame transmitted in HE extended range SU PPDU format shall be identical Revised. The Dual Beacon mechanism is deleted. See proposed change in doc. 11-17/0576r1.
to the Beacon frame transmitted in non-HE PPDU format." At 141.41 delete "as indicated in the Beacon frame transmitted in PPDU format" and change "Beacon interval" to "beacon interval". At 141.48 delete "as indicated in the Beacon frame transmitted in the HE extended range SU PPDU." 9334 Tomoko Adachi 141.30 11.1.3.10 When the AP transmits beacons in an HE_EXT_SU PHY format, it uses the dual beacon mechanism. However, the dual beacon mechanism is deprecated in the baseline (see Table 9-168 and subclause 11.1.3.2 in 802.11-2016). There is no need to reintroduce this again. Just allowing the beacons to be transmitted in an HE_EXT_SU PHY format is enough. Add in subclause 10.7.5.3 a condition to allow beacon frames and group addressed frames to be transmitted in an HE_EXT_SU PHY format if the BSSBasicRateSet, the Basic HT-MCS Set, and the basic VHT-MCS and NSS set are all empty and only the Basic HE MCS And NSS Set is not empty. Delete subclause 11.1.3.10, delete the definition of high efficient (HE) dual beacon from subclause 3.2, replace the Dual Beacon subfield in the HE Operation Parameters to reserved and delete the description of the Dual Beacon subfield in subclause 9.4.2.219. Revised. See proposed change in doc. 11-17/0576r1. Related Comments in Subclause 27.5.2.6.2 5392 Geonjung Ko 173.31 27.5.2.6.2 When an AP uses the Dual Beacon, a non-AP STA that When an AP uses the Dual Beacon, the STA should Revised. The Dual Beacon
IEEE P802.11 Wireless LANs Comment Resolution on Retansmission of OFDMA Random Access Date: 2016-09-11 Author(s): Name Affiliation Address Phone Email Yunbo Li Huawei Yanchun Li Huawei Kiseson Ryu LG Electronics Jeongki Kim LG Electronics Jayh Park LG Electronics Chittabrata Ghosh Intel Interpretation of a Motion to Adopt A motion to approve this submission means that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGax Editor: Editing instructions preceded by “TGax Editor” are instructions to the TGax editor to modify existing material in the TGax draft. As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft. CID Page Number Line Number Comment Proposed Change Resolution 49 60 34 If an UL MU transmission via UL MU random access was not succeeesful (due to collision, or other error cases), with what value the STA should initialize its OCW; OCWmin, or twice the prior OCW value initialization? As in the comment Revised. Paragraphs are added to specify how to update the OCW after a successful transmission and a failure transmission respectively. TGax editor makes changes as shown in 11-16/1162r1. 601 60 48 The standard define, how the STA changes its backoff when it As mentioned in comments Revised.
602 60 29 It is not clear why the parameter is called OCWmin, if there is no OCWmax Rename OCWmin or introduce OCWmax Revised. An OCWmax parameter is added in Beacon frame or Probe response frame. 1198 60 7 For random access UL-OFDMA, OCWmin is defined but not OCWmax. This is important to make sure that OCW will be upperbounded the same way for all 11ax devices. Define an OCWmax parameter Revised An OCWmax parameter is added in Beacon frame or Probe response frame. 2684 60 8 Other parameters for random access are TBD. We should define it OCWmax or Retry Limits are necessary for a retransmission procedure of the UL random access. Revised. An OCWmax parameter is added in Beacon frame or Probe response frame. 181 78 47 If the OBO counter is 0 or it decrements to 0 are the same condition in terms of this procedure (pick one and remove the other). Also Trigger frame for random access is better referred to as a Trigger frame that contains at least a random RU? As in comment Revised. They are two different ways for OBO counter to get 0. It is better to keep both of them. The sentence is modified to make it clearer. “Trigger frame for random access” is replaced with “trigger frame contains RU(s) assigned for AID value 0”. (IEEE motion passed, slide105 in 440 60 32 initiates begins when the ... receives. Although, really it begins when the AP sends the trigger frame frro random access! .. Revised. Agree in principle. The sentence is deleted. based
IEEE P802.11 Wireless LANs LB225 MAC comment resolutions for clause 6 and 9 Date: 2017-04-xx Author(s): Name Affiliation Address Phone Yasuhiko Inoue NTT 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan +81 46-859-5097 Shoko Shinohara NTT 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan +81 46-859-5107 Yusuke Asai NTT 1-1 Hikari-no-oka, Yokosuka, Kanagawa 239-0847 Japan +81 46-859-3494 asai.yusuke@lab.ntt.co.jp Abstract This submission proposes resolutions for multiple comments related to TGax D1.0 with the following CIDs: CIDs: 3003, 5428, 5429, 5430, 6002, 7705, 7894, and 10190 (8 CIDs). Revisions: Rev 0: Initial version of the document. Interpretation of a Motion to A motion to approve this submission means that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGax Editor: Editing instructions preceded by “TGax Editor” are instructions to the TGax editor to modify existing material in the TGax draft. As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft. Comments on clause 6 CID Commenter Clause P.L Comment Proposed Change Resolution 3003 Abhishek Patil 6.3.3.2 11.15 MLME-SCAN.request should include HT/VHT/HE Capabilities since the Probe Request frames can carry these capabilities elements Add HT/VHT/HE Capabilities to MLME-SCAN.request section Reject. 5428 Graham Smith 6.3.7.4.3 12.37 Ehere did "peer STA" come from? Delete "peer" Rejected. The term “peer STA” is consistently used in this
BSS membership selector value encoding Value Feature Interpretation 126 HE PHY Support for the mandatory features of Clause 28 is required in order to join the BSS that was the source of the Supported Rates and BSS Membership Selectors element or Extended Supported Rates and BSS Membership Selectors element containing this value.
The format of the ESS Information is defined in Figure 9-XYZ1. B0 B1 B2 B7 Planned ESS Edge Of ESS Recommended BSS Transition Threshold Within The ESS Bits: 1 1 6 Figure 9-XYZ1—ESS Information field The Planned ESS subfield indicates whether the BSS is part of an ESS which is planned with several BSSs in overlapping configuration. This subfield is set to 1 to indicate that the ESS is deployed to ensure blanket coverage over the Extended Service Area (ESA). Otherwise this subfield is set to 0 and the Edge Of ESS and Recommended BSS Transition Threshold Within The ESS subfields are reserved. The Edge Of ESS subfield indicates whether the BSS is at the edge of the ESS. This subfield is set to 1 to indicate the BSS is at the edge of the ESS. Otherwise this subfield is set to 0. The Recommended BSS Transition Threshold Within The ESS subfield indicates the RSSI below which an associated STA is recommended to initiate BSS transition to a neighbor BSS belonging to the ESS. The resolution for the Recommended BSS Transition Threshold Within The ESS subfield is 1 dB. The encoding is defined in Table 9-XYZ1 (Recommended BSS Transition Threshold Within The ESS subfield encoding) . Table 9-XYZ1 Recommended BSS Transition Threshold Within The ESS subfield encoding Subfield Description 0-62 100 dBm to 37 dBm 63 Indicates no recommendation The use of the ESS Report element is described in 11.24.27.5. TGax Editor: Please modify this section as follows: 9.3.3.1 Beacon frame format Insert the following new rows into Table 9-27 (Beacon frame body) (header row shown for convenience): Information Notes <next number> ESS Report The ESS Report element is optionally present when dot11HEOptionImplemented is true; otherwise it is not present.
7414 Lei Huang The statement "An HE AP indicates the values of OCWmin and OCWmax in the RAPS element in a Beacon or Probe Response frame for the random access operation. OCWmax is the upper limit of OCW." is redundant since there is the similar statement in Section 27.5.2.6.1 (see L38-L43 of P172). delete "An HE AP indicates the values of OCWmin and OCWmax in the RAPS element in a Beacon or Probe Response frame for the random access operation. OCWmax is the upper limit of OCW." Revised. Agree in principle. The redundant sentence on HE AP is deleted and replaced by a sentence clarifying the behavior of the HE STA. TGax Editor to make the changes to 802.11ax D1.2 as in 11-17/0645r2 under all headings that include CID 7414. 8282 Pascal Viger HE STA shall use the most recently RAPS element, but this element should be received from the intended AP ! Modify the sentence of 4th paragraph: "An HE STA shall use the OCWmin and OCWmax values indicated in the RAPS element within Beacon or Probe Response frames most recently received by the AP emitting the Trigger Frame, regardless of the access category...". Revised. Agree in principle. The proposed changes included in the current document clarify the obtaining rules of the OCWmin and OCWmax values TGax Editor to make the changes to 802.11ax D1.2 as in 11-17/0645r2 under all headings that include CID 8282. 8300 Patrice An AP only "may" include RAPS element even if UL OFDMA-based random access is unable. How can the STA set OCWmin and OCWmax itself if no RAPS is sent by the AP? A non-AP STA must define default values for OCWmin and OCWmax Revised Comment very similar to previous CID#7410. as per #7410 resolution. 1 1
IEEE P802.11 Wireless LANs Comment resolution for UL OFDMA-based random access (UORA) Date: 2017-04-19 Author(s): Name Address Phone email Patrice NEZOU Rennes, France Stéphane BARON Canon Rennes, France Pascal VIGER Canon Rennes, France Julien SEVIN Canon Rennes, France CID Pg, Li Comment Proposed Change Resolution 3237 "For an initial HE PPDU transmission or following a successful HE trigger-based PPDU transmission, when an HE STA obtains the value of OCWmin from the HE AP indicated in the RAPS element, it shall set the value of OCW to the OCWmin and shall initialize its OBO counter to a random value in the range of 0 and OCWmin." "For an initial HE trigger-based PPDU transmission or following a successful HE trigger-based PPDU transmission, an HE STA shall set the value of OCW to the OCWmin obtained from the most recent OCWmin indicated in the RAPS element from the HE AP, and shall initialize its OBO counter to a random value in the range of 0 and OCWmin." Revised – in principle. The commenter asks to clarify the sentence describing the OBO management. The related sentence has been modified:”… an HE STA shall initialize its OBO counter to a random integer value in the range of 0 and OCW.” 6005 The OCWmin value use for UL MU OFDMA random access is not clearly defined. Is the OCW set to OCWMin value everytime a new OCWMin value is obtained by the STA? Please clarify does a reception of new OCWMin value set the OCW value to OCWMin. Revised – Agree in principle. The commenter asks to clarify the OCWmin value and its usage. A new sentence has been added for clarification: “After each successful HE TB PPDU transmission, an HE STA shall set the value of OCW to the OCWmin obtained from the most recent OCWmin indicated in the RAPS element …” based
TBTT Information Length Indicator subfield value TBTT Information field length (octets) TBTT Information field contents 1 1 The Neighbor AP TBTT Offset subfield 5 5 The Neighbor AP TBTT Offset subfield and the subfield 7 7 The Neighbor AP TBTT Offset subfield and the BSSID subfield 11 11 The Neighbor AP TBTT Offset subfield, the BSSID subfield and the Short-SSID subfield 13 13 The Neighbor AP TBTT Offset subfield, the BSSID subfield, and the HESSID subfield 0, 2–4, 6, 8–10, 12, 14–255 Reserved Reserved • In P802.11-REVmd/D0.2 subclause 9.4.2.171.2, change Figure 9-583 at Page 1186 Lines 12-19 as follows: Neighbor AP TBTT Offset BSSID (conditional) or HESSID (conditional) Octets: 1 0 or 6 0 or 4 or 6 Figure 9-583—TBTT Information field format
RA field to the broadcast address. An HE AP that transmits a BlockAck frame with a single AID subfield or with the same values of the AID subfield in Per STA Info subfields sets the RA field to the address of the recipient STA that requested the Block Ack or to the broadcast address. An HE non-AP STA transmits a BlockAck frame with a single AID subfield or with the same values of the AID subfield in Per STA Info subfields and sets the RA field to the TA field of the soliciting frame or the address of the recipient STA whose data/management frames are acknowledged." described in Section 27.4 6950 Joseph Levy 34.23 Changes made to the 3rd paragraph provide changes to the baseline text that while appearing to be a change do not change requirements. The baseline text should be modified in a minimal way. Replace the first sentence with: "The RA field of the BlockAck frame that is not a Multi-STA BlockAck variant is the address of the recipient STA that requested the Block Ack. Rejected - backward compatibility is preserved, 11ax added Multi-BSS control frame response. So, the response may be sent to Transmitting BSS, or to the virtual AP that the STA is associated with. 7133 kaiying Lv 36.55 Change "and" to "or" As in comment Revised - Agree in principle. Updated the text. TGax editor shall incorporate changes in 4852 Alfred Asterjadhi 33.65 The BlockACKReq includes the BAR Control which also has the encoding of the BlockAckReq frame variant, and for different variants there can be a different length. Similar observation for the M-BA, that can have different lengths. Clarify that the lenghts that are defined as of now (11ax) are also applicable for future amendments to ensure forward compatibility. Presentation to be provided Revised - Agree in principle. Updated the text. TGax editor shall incorporate changes in 3109 Adrian Stephens 34.10 Bit numbering of the Reserved field is inconsistent Change reserved to B5-B11. Revised - Agree in principle. Updated the text. TGax editor shall incorporate changes in
TRL-SIG 4 µs Repeated non-HT SIGNAL field duration THE-SIG-A 8 µs = 2 × 4 µs HE-SIG-A duration in an HE SU PPDU, HE MU PPDU and HE trigger-based PPDU THE-SIG-A-R 16 µs = 4 × 4 µs(#279) HE-SIG-A field duration in an HE extended range SU PPDU THE-STF-T 8 µs = 5 × 1.6 µs HE-STF field duration for an HE PPDU THE-STF-NT 4 µs = 5 × 0.8 µs HE-STF field duration for an HE SU PPDU, HE extended range SU PPDU and HE MU PPDU THE-LTF-1X 3.2 µs Duration of each 1x HE-LTF OFDM symbol without GI THE-LTF-2X 6.4 µs Duration of each 2x HE-LTF OFDM symbol without GI THE-LTF-4X 12.8 µs Duration of each 4x HE-LTF OFDM symbol without GI THE-LTF THE-LTF-1X, THE-LTF-2X or THE-LTF-4X depending upon the duration used Duration of each OFDM symbol without GI in the HE-LTF field (#279) THE-LTF-SYM sum of THE-LTF and TGI,HE-LTF Duration of each OFDM symbol including GI in the HE-LTF field THE-SIG-B 4 µs = TDFT,Pre-HE + TGI, Duration of each OFDM symbol in the field(#Ed) Nservice 16 Number of bits in the SERVICE field Ntail 6 Number of tail bits per BCC encoder TSYML 4 µs Symbol duration including GI prior to the HE-STF field TPE 0, 4 µs, 8 µs, 12 µs or 16 µs depending on the actual extension duration used Duration of the Packet Extension field(#279) To TGax Editor: D0.4, P152L48 Section 26.3.9 Tone scaling factor and guard interval duration values for HE PPDU fields Field as a function of bandwidth, and RU size per frequency segment
3049 104.14 9.6.29 Instead of defining a new action Quiet Time Period frames can be of type HE Action frame. Add Time Period category under HE Action frames and create a section that describes frames related to Quiet Time Period Accepted: The resolution of the comment is addressed together with CID 3048 5349 104.01 9.6.28.3 9.47 does not contain a value for HE Action Category Add the row with code <ANA>, meaning "HE" and reference to Clause 9.6.28 Countered: an alternative resolution is provided for CID 3048, 3049 which is more suitable for Quiet Time Period operation. 5351 104.01 9.6.28.3 Table 9.47 does not contain a value for Quite Time Period Action Category Add the row with code <ANA>, meaning "Quite Time Period" and reference to Clause 9.6.29 Duplicated: Same as 5349 4472 97.16 Element ID Extension subfield shown in Figure (Quiet Time Period Response element) is not defined in the text following the figure. Define subfields "Element ID Extension" Duplicated: The comment is addressed in 3048, 3049 Discussion: [CID 3048, 3049, 5349, 5351, 3038, and 4472] : Accepted Accepted: The changes are made to clause 9.4.1.11, 9.4.2.223, 224, and 225 as proposed. There are around 80 CIDs commenting on various aspect of Quiet time operation. Disclaimer: The part 1 of the resolution of the quiet time period is to re-structure the clauses to better match the format of 802.11 specifications. Some text in the revised clauses will be revised further when other CIDs are addressed. Propose: Revised the following text per discussion and editing instructions in 11-17/0693r0. TGax Editor: Modify 9.4.1.11Table 9-47 as the following:
IEEE P802.11 Wireless LANs CRs on Miscellaneous PHY CIDs Date: 2017-05-05 Author(s): Name Affiliation Address Phone email Bin Tian Qualcomm 5775 Morehouse Dr. San Diego, CA, USA btian@qti.qualcomm.com Interpretation of a Motion to Adopt A motion to approve this submission that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGax Editor: Editing instructions preceded by “TGax Editor” are instructions to the TGax editor to modify existing material in the TGax draft. As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft. CID Clause P L Comment Proposed Change Resolution 10117 28.3.7 257 61 If there is no use of "THE-LTF-SYM" through the spec, remove the unnecessary paramter in th table. As in the comment. Revised Tgax editor: please remove the defintion of parameter THE-LTF-SYM in D1.2 P286L23 Table 28-9 9015 330 54 Pilot indices are already listed in Table 28-7. It is better not to duplicate this information. Remove 28-29 and replace with reference to Table Similar comment for Tables 28-31, 28-33, 28-34, 28-36, 28-37 Rejected While there is overlapping information, Table 28-29 clearly spells out the the pilot indices for each of the ith RU26. They are helpful to understand the equations that follow. 9016 331 19 Notation P^KR26i_n is not clear, since the superscript elsewhere denotes a single tone index. Replace with P^k_n and specify that k belongs to K_R26i. Similar for indices that See comment Rejected The notation is clear. The samilar notation is used in VHT clause 21.3.10.10
Bitmap subfield is set to 1 to indicate the 2.16 GHz channel with channel number i for the measurement request applies." Up to 8 2.16GHz Can be indicated and only 6 2.16GHz are available. This needs to be stated in this paragrapgh Revised- Agree in principle with the comment. The Measurement Channel Bitmap subfield should follow the format of the BSS Operating Channels field. TGay editor to make the changes shown in under all headings that include CID 476. 477 17 15 "The Measurement Channel Bitmap subfield indicates one or multiple 2.16 GHz channels for which the measurement report applies. Starting with the MSB, the ith bit of the Measurement Channel Bitmap subfield is set to 1 to indicate the 2.16 GHz channel with channel number i for which the measurement report applies' upt o 8 2.16GHz Can be indicated and only 6 2.16GHz are available. This needs to be stated in this paragrapgh as suggested Same as the resolution to #151 Revised- in principle with the comment. The Measurement Channel Bitmap subfield should follow the format of the BSS Operating Channels field. TGay editor to make the changes shown in under all headings that include CID 477. 340 16 17 If Extended Measurement Configuration subelement is present, the measurement timings over all the requested 2.16 GHz channels may be different. In this case, it does not make to set the Channel Measurement Report Method subfield to 1. 1. add the following sentence at the end of the second paragraph below Figure 8: "The Channel Measurement Report Method subfield shall be set to 0 when the Extended Measurement Configuration subelement is present." 2. add the following sentence at the end of the second paragraph below Figure 10 in page 17: "The Channel Measurement Report Method subfield shall be set to 0 when the Revised- Agree in principle with the comment. In D0.3, the Channel Measurement Report Method subfield sets to 1 to indicate reporting the averaged results of concurrent measurements over all the requested 2.16 GHz channels. Therefore, it does not make sense to set the Channel Measurement Report Method subfield to 1 when the Extended Measurement Configuration subelement is present.
On P39L62 (CID #8982): For an 80+80MHz transmission, ….. On P340L1 (CID #8983): For an 80+80MHz transmission, …. On P340L7 (CID #8984): For an 80+80MHz transmission,…. CID Commenter Section Page Comment Proposed Change Resolution 4893 Bin Tian 311.11 Change "In an UL transmission not using single stream pilots" to "In a full bandwidth UL transmission not using 1x LTF or not using signal stream pilots in in HE-LTF" As in comment Revised. Change to as in the resolution of CID4893 in doc Discussions: The commentor is right that masking should not be applied to 1x HELTF in a non-OFDMA UL transmission although multiple stream pilots are used. ax editor: please make the following changes in D1.2 Clause 28.3.10.10: On P340L13 (CID #4893): In an UL MU-MIMO transmission using single stream pilots the HE-LTF sequence per frequency segment the non-zero elements in the common HE-LTF sequence repeatedly a distinct orthogonal code as defined by Equation (28-51). CID Commenter Section Page Comment Proposed Change Resolution 8573 Rui Cao 311.20 "HELTFk is the k-th element of the common HE-LTF sequence generated by ... ", the usage of "k-th" is vague, which can mean k starts from 1 at the left most of the HELTF sequence. Change it to "HELTFk is value of the common sequence on subcarrier k ..." or refer to Equations and (28-59) Revised. Change to as in the resolution of CID8573 in doc
Need to clarity the wording. for the definition of k. ax editor: please make the following changes in D1.2 Clause 28.3.10.10: On P340L23 (CID #8573): Where HELTFk is the of the common HE-LTF sequence generated by one of the equations from (Equation (28-3) to Equation (28-5) depending on the bandwidth and the HE-LTF mode (excluding the 1x HE-LTF which shall not be masked). CID Commenter Section Page Comment Proposed Change Resolution 9065 Sriram 311.17 For greater clarity, HELTF should include r, u, and m as its subscripts This change will affect the draft in multiple places, but is suggested to improve clarity. Add subscripts m,r,u to HE-LTF Revised. Change to as in the resolution of CID9065 in doc 4906 Bo Yu 313.23 TGI in equations (28-58) and (28-59) should be replaced by TGI,HE-LTF. TGI is not defined. As in comment Revised. Change to as in the resolution of CID9065 in doc 9189 SUNGEUN LEE 313.23 TGI in HE-LTF equation, i.e., Eq (28-58) should be clarified more from the parameter table. Replace TGI to TGI,HE-LTF and also update the description in parameter table accordingly Revised. Change to as in the resolution of CID9065 in doc 9190 SUNGEUN LEE 313.38 TGI in HE-LTF equation, i.e., Eq (28-59) should be clarified more from the parameter table. Replace TGI to TGI,HE-LTF and also update the description in parameter table accordingly Revised. Change to as in the resolution of CID9065 in doc 9485 Yan Zhang 313.23 TGI in equations (28-58) should be replaced by TGI,HE-LTF. TGI is not defined. As in comment Revised. Change to as in the resolution of CID9065 in doc 9486 Yan Zhang 313.38 TGI in equations (28-59) should be replaced by TGI,HE-LTF. TGI is not defined. As in comment Revised. Change to as in the resolution of CID9065 in doc Discussions:
calculate the number of HE-LTF symbols, N_HE-LTF for HE MU PPDU with more than one RUs. The commenter needs to give more details on why he wants to delete “with more than one RU”. 5108 Dong Guk Lim 301.43 28-12 (Frequently used parameters) does not provide any function related with NHE-LTF, so the function of number of HE-LTF symbol would need to be clarified by considering the total number of space time stream. Provide the function of relation between number of LTF symbol and total number of space time stream like as table 21-13 in 802.11-2016. Revised. Change to as in the resolution of CID5108 in doc ax editor: please make the following change in D1.2 Clause 28.3.10.10 On P330L36 (CID #5108): In an HE MU PPDU with more than one RU and in an HE TB PPDU, NHE-LTF may take any value among one, two, four, six or eight, which is greater than or equal to the maximum value of the initial number of HE-LTF symbols for each RU r, which is calculated as a function of NSTS,r,total, separately based on, replacing NVHT-LTF by NHE-LTF. CID Commenter Section Page Comment Proposed Change Resolution 4892 Bin Tian 302.4 1x LTF and 1.6us CI support for UL (trigger-based PPDU) is listed as optional, which should be conditional mandatory. Move the line 4 P302 to Line 62 P301. Revised. Change to as in the resolution of CID4892 in doc 6119 Jian Yu 301.64 Add 4X HE-LTF and 0.8us GI as an optional mode As in comment Revised. Change to as in the resolution of CID4892 in doc
ax editor: please make the following change in D1.2 Clause 28.3.10.10 On P342L5 (CID #5274, CID #8986): When the 1x HE-LTF is used for non-OFDMA UL MU-MIMO, neither masking by orthogonal code nor single stream pilot are used. CID Commenter Section Page Comment Proposed Change Resolution 9067 Sriram 313.16 Beta_r can be used to simplify equation 28-58 and also make it consistent Use beta_r in equation 28-58 to simplify it and make it consistent Rejected. In the spec, Beta_r was only used in general mathematical equations (28-3) and (28-4) for power normalization factor. For each specific field equation, Beta_r is always replaced by the corresponding equations described in To make the spec consistent, we should not use Beta_r in equation CID Commenter Section Page Comment Proposed Change Resolution 8989 Sigurd Schelstraete 314.1 "When a 1x, 2x or 4x is transmitted". This means always, since these are the only modes that are defined. Delete "When a 1x, 2x or 4x is transmitted" Revised. Change to as in the resolution of CID8989 in doc 8990 Sigurd Schelstraete 314.1 Is this paragraph in the right place? Why is this specfifc to HE-LTF. The spatial mapping matrix is applied starting at Move paragraph to more appropriate section. Revised. Change to as in the resolution of CID8989 in doc 9752 Yongho Seok 314.1 "When a 1x, 2x or 4x is transmitted,..." As per comment Revised. Change to as in the resolution of CID8989 in doc
IEEE 802.11 looks forward to a continued and productive interchange between our two organizations on these and other issues during the development of LAA and beyond. Action to 3GPP RAN4: IEEE 802.11 recommends 3GPP RAN4 consider an SIR level of 0 dB for the “Below ED” test configuration. Next IEEE 802.11 meetings: 9-14 July 2017 in Berlin, Germany 10-15 September 2017 in Hawaii, USA. Regards, Adrian Stephens, Chairman, IEEE 802.11 Working Group adrian.p.stephens@ieee.org References R4-1704409, WF on Multi-node tests for Rel-13 LAA R4- 1704501 RAN4#82bis Meeting Report R4-1701879, Further Implications of Wi-Fi Field Measurements for Multi-Node Testing 3GPP TS 36.141 V14.2.0 (2016-12), Base Station (BS) conformance testing
Name Affiliation Attended >= 75%? Aboulmagd, Osama Huawei Technologies Co. Ltd Yes Ahn, Jinsoo Yonsei University Yes Ahn, Woojin WILUS Yes Alpert, Yaron Corporation Yes Ansley, Carol Group Yes Asai, Yusuke NTT Yes Asterjadhi, Alfred Qualcomm Incorporated No Au, Kwok Shum Huawei Technologies Co. Ltd Yes Azizi, Shahrnaz Intel Corporation Yes Banerjea, Raja Qualcomm Incorporated No bang, saehee LG ELECTRONICS No baron, stephane Canon Research Centre France Yes Batra, Anuj Apple, Inc. No Bhandaru, Nehru Broadcom Corporation Yes Calcev, George Huawei R&D USA Yes Cariou, Laurent Intel Corporation Yes Carney, William Sony Corporation Yes Chen, Jiamin HUAWEI Yes Chen, Xiaogang Intel Corporation No Cheng, Yong Huawei Device Yes CHERIAN, GEORGE Qualcomm Incorporated Yes Chitrakar, Panasonic Asia Pacific Pte Ltd. Yes Cho, Hangyu lg electronics Yes Choi, Jinsoo LG ELECTRONICS Yes Chu, Liwen Marvell Semiconductor, Inc. Yes Ciochina, Dana Sony Corporation Yes Coffey, John Realtek Semiconductor Corp. Yes Cordeiro, Carlos Intel Corporation Yes
Holcomb, Jay Itron Inc. No Hong, Hanseul Yonsei University Yes Hsu, MediaTek Inc. Yes Huang, Lei Panasonic Asia Pacific Pte Ltd. Yes Huang, Intel Corporation Yes Sung Hyun Electronics and Telecommunications Research Institute (ETRI) Yes Inoue, Yasuhiko Nippon Telegraph and Telephone Corporation (NTT) Yes Ishizu, Kentaro National Institute of Information and Communications Technology (NICT) Yes Jeffries, Timothy Huawei R&D USA Yes Ji, Chenhe Huawei Technologies Co., Ltd Yes Jiang, Jinjing Marvell Semiconductor, Inc. Yes Jones, Vincent Knowles IV Qualcomm Incorporated Yes Kang, Electronics and Telecommunications Research Institute (ETRI) No Kapetanovic, Dzevdan Ericsson AB Yes Kennedy, Richard Hewlett Packard Enterprise No Kerry, Stuart OK-Brit Yes Kim, Jeong Gon Korea Polytechnic University No Kim, Jeongki LG ELECTRONICS No Kim, Jin Min LG ELECTRONICS Yes Kim, Sang Gook LG ELECTRONICS Yes Kim, Suhwook LG ELECTRONICS Yes
Kim, Sungsoo Samsung Electronics Co., Ltd. No Kim, Youhan Qualcomm Incorporated Yes KNECKT, JARKKO Inc. Yes Ko, Geonjung WILUS Institute Yes Kumar, Manish Marvell Semiconductor, Inc. Yes Kwak, WILUS Institute Yes Lan, Zhou Huawei Technologies Co. Ltd Yes Lanante, Leonardo Kyushu Institute of Technology No Lansford, Qualcomm Incorporated Yes Lee, Hyeong Ho Electronics and Telecommunications Research Institute (ETRI) No Lee, Jae Seung ETRI Yes LEE, JUNG WOON Samsung Electronics Co., Ltd. Yes LEE, SUNGEUN Cypress Semiconductor Corporation Yes Lepp, James BlackBerry Yes Levy, Joseph InterDigital, Inc. Yes Li, Dejian Huawei Technologies; HiSilicon Yes Li, Guoqing Apple, Inc. Yes Li, Qiang HUAWEI Yes Li, Qinghua Corporation Yes Li, Huawei Technologies Co. Ltd Yes Lim, Dong Guk LG ELECTRONICS Yes Lim, Electronics and Telecommunications Research Institute (ETRI) No Lindskog, Erik Qualcomm Incorporated Yes Liu, Jianhan MediaTek Inc. Yes Sam