zilongwang/ReadingBank huggingface dataset:
Question/Comment (Q): It to me the information may be obtained through the PCR assuming that the STA is associated with the AP? Answer(A): In case of location scan, association is not required. In case of roam scan I agree it would have to be associated. Q: It seems you just need to scan for the WUR beacon? A: Yes, but with a fixed number of discovery channels, the scan can be made faster. Q: Maybe you are out of range for your WUR channel? A: Basically this is why we propose the discovery channel. Of course, there is always a risk to be out of range. Q: I don’t believe this is needed. Q: It seems to me all APs must support this feature, otherwise the idea may not work. Meeting is adjourned at 6.00pm (ET). List of Attendees: Name Affiliation 1 Minyoung Park Samsung 2 Leif Wilhelmsson Ericsson 3 Kaiying Lv ZTE 4 Peter Loc Huawei 5 Yunsong Yang Huawei 6 Po-Kai Intel Teleconference on Monday, February 26th, 2018, 11:00 – 12:00pm (ET) Agenda: 1. Call meeting to order 2. Agenda setting 3. Patent policy (link at the end of the email) 4. Attendance: send email to the chair or secretary (leif.r.wilhelmsson@) 5. Presentations 1) 11-18-0356-00-00ba-compressed-ssid-for-wur-discovery-frame, Taewon Song, LG Electronics 2) 11-18/0358 Dynamically Changing WUR ID, Enrico Rantala, 6. Adjourn Please note that teleconferences are bound by the conditions stipulated by the documentation below. Please review them and bring up any questions/concerns you may have before proceeding with
Resolution: Accepted. Editor: page 388, add the text below the Table 87, [2] 30.9.2.2.6 TRN subfield definition for EDMG SC PPDUs and EDMG control mode PPDUs The TRN field shall consist of NTX orthogonal waveforms, where NTX is the number of transmit chains used in the transmission of the EDMG PPDU.
IEEE P802.11 Wireless LANs TGaz Meeting Minutes November 7th-9th, 2017 Orlando, Florida, USA Date: 2017-11-07 Author(s): Name Affiliation Address Phone email Roy Want Google 1600 Amphitheatre Parkway, Mountain View, CA 94043 USA 650-691-3600 roywant@google.com IEEE 802.11 Task Group AZ November 7th-9th, 2017 TGaz – 7th November 2017 – Slot #1 Called to by TGaz chair, Jonathan Segev (Intel Corporation) at 4.00pm EST, Vice Chair Carlos Aldana (Intel Corporation), Roy Want (Google) Secretary. Agenda Doc. IEEE 802.11-17/1552r02 Review Patent Policy and logistics Chair reviewed the IEEE-SA Patency Policy, additional guidelines about IEEE-SA meeting and logistics – no clarifications requested. called for any potentially essential patent, no one stepped up. Chair reviewed IEEE 802 WG participation as individual professional – no clarification requested. Chair reminded all to record their attendance Recorded Participation requirement Headcount: ~56 present Review Agenda Called for any additional submissions for the week. Reviewed and modified the agenda Chair called for any additional feedback and changes to agenda. An additional slot (5th) will be requested for Wed PM2. In AM1 we will review the needed for one more depending on progress. Motion: We approve the agenda for document 11-17/1552r02 Approved by unanimous consent Approve previous meeting minutes (posted Sept 21st) Roy Want (Google) reviewed Sept Meeting Minutes 11-17/1481r0 Motion: Move to approve document 11-17-1481r0 as TG meeting minutes for the Sept meeting Mover: Roy Want, Seconder: Assaf Kasher Discussion of the motion: none Vote: Y: 20, N: 0, A: 2; motion passes No telecom last and so no minutes to approve
(FILS Wrapped Data element format(11ai)). The Element ID, Length, and Element ID Extension fields are defined in 9.4.2.1 (General). The FILS Wrapped Data field is the data used by the FILS authentication algorithm (see 12.12 (Authentication for FILS(11ai))) and PASN authentication algorithm (see 12.xx (Pre-Association Security Negotiation)). -- Change FILS Wrapped Data to Wrapped Data in Figure 9-645 (p1286.45) -- Change references to ‘FILS Wrapped Data’ to ‘Wrapped Data’ in the document -- Add PASN Parameters Element at the end of 9.4.2 p1337.36 9.4.2.xx PASN Parameters Element Element ID Length Element ID Extension Control Wrapped Data Format Comeback Info Finite Cyclic Group ID Ephemeral Public Key Length Ephemeral Public Key Octets: 1 1 1 1 1 Variable 0 or 2 0 or 1 Variable Figure XXE PASN Parameters Element format The Element ID, Length and Element ID Extension fields are defined in 9.4.2.1 (General). The Control field indicates the presence of PASN Parameters Element subfields as follows B0 B1 B2...B7 Comeback Info Present Group and Key Present Reserved Bits: 1 1 6 Figure 9- XXCI PASN Parameters Element Control Wrapped Data Format field indicates the format of data in Wrapped Data element included along with the PASN parameters element. The values defined for this format are: 0: No wrapped data 1: Fast BSS Transition Wrapped Data (See 12.xx.6 PASN Authentication with FT) 2: FILS Shared Key authentication without PFS Wrapped Data (See 12.xx.4 PASN authentication with FILS Shared Key) 3: SAE Wrapped Data (see 12.xx.5 PASN authentication with SAE) Other: Reserved The Comeback Info field, present only when indicated by the corresponding bit in the Control field, is of variable length and is formatted as follows Comeback After Cookie Length Cookie Octets: 0 or 2 1 Variable Figure 9- XXCI PASN Parameters Element Control field
13489 Sigurd Schelstraete 28.3.11.9 462.39 Change "1024-QAM is optional for SU and MU for RUs equal to or larger than 242 subcarriers." to is optional for SU and MU and, when supported, can only be used for RUs equal to or larger than 242 subcarriers." See comment Revised Editor delete the sentence in 486.52 in D2.2: “1024-QAM is optional for SU and MU for RUs equal to or larger than 242 subcarriers” 13397 Ron Porat 28.3.11.5 455 Mention here also that RU 26/52/106 dont support 1024 QAM As in ncomment Rejected This document proposes support for 1024QAM over small RU Discussion The current spec does not support transmission of 1024QAM over RU smaller than 242 even though this is possible without any changes to the spec. However we find that supporting 1024QAM over small RU seems to be important for many scenarios e.g.: 20MHz DL/UL OFDMA – currently the peak throughput of this mode is 25% lower than 20MHz SU and hence reduces the appeal of this mode 40MHz DL/UL 4x106RU OFDMA (4 user OFDMA) - currently the peak throughput of this mode is 25% lower than 40MHz SU or 2 user OFDMA and hence reduces the appeal of this mode 80MHz DL/UL 8x106RU OFDMA (8 user OFDMA) - currently the peak throughput of this mode is 25% lower than 80MHz SU or 4 user OFDMA and hence reduces the appeal of this mode We therefore propose to simply remove this artificial limitation in the spec and the missing rates to the tables of 26/52/106RU. Editor: Changes for comments 13404: Please make the following change on page 548 lines 45,46:
Is this sentence meaningful? Doesn't it end the same with "may be transmitted with any MCS"? outcome between the suggested and the existed text is the same, BRP frame can be sent with any MCS 1566 10.7.7.5 An EDMG BRP packet is a concept of PHY Change "EDMG BRP packet " to " EDMG BRP frame" Accepted 1567 10.7.7.5 EDMG BRP frame is included in the single channel case as well as EDMG BRP packet insert "2.16GHz" between "over a" and "4.32 GHz, 6.48 GHz, 8.64 GHz, 2.16 + 2.16 GHz or 4.32 + 4.32 GHz channel" Accepted 1565 10.7.7.5 Lack of definition of "a BRP transaction". According to 11ad, " A beam refinement transaction is a set of BRP frames composed of request and responses." Define " BRP Transaction" or Change" a BRP transaction" to "a beam refinement transaction" Rejected BRP is a short for Beam Refinment hence no need to include it in text Revised text 10.7.7.5 Rate selection for BRP packets Change the following subclause as follow EDMG BRP packet sent during a BRP transaction to perform beamforming training over a 4.32GHz, 6.48 GHz, 8.64 GHz, 2.16 + 2.16 GHz or 4.32 + 4.32 GHz channel should be transmitted with MCS0. CID Clause Page Comment Proposed change 1852 10.7.7.7 Grammatical error in TXVECTOR parameter restrictions Change "NUM_USERS is set" to "NUM_USERS set" Accepted 1853 10.7.7.7 Grammatical error in TXVECTOR parameter restrictions Change "NUM_MOD is set" to "NUM_MOD set" Accepted 1854 10.7.7.7 Grammatical error in TXVECTOR parameter restrictions Change "set LONG" to "set to LONG" Accepted CID Clause Page Comment Proposed change 1965 10.7.7.9 Lack of relevant modulation class selection in the table 10-6 Append "IsSC field of L-Header is set to 1" to the second column, second row, and "IsSC field of is set to 0" to the second column, third row. Accepted
IEEE P802.11 Wireless LANs Resolution of “Procedures common to the DCF and EDCAF” related CIDs Date: 2018-02-25 Author(s): Name Affiliation Address Phone Oren Kedem Carlos Cordeiro Intel carlos.cordeiro@intel.com Solomon Trainin Qualcomm strainin@qti.qualcomm.com CID Clause Page Comment Proposed change 1473 10.3.2.14 I think by "to the desired channel bandwidth" we mean to say "the channel bandwidth of the packet to be transmitted after receiving a corresponding CTS frame". Clarify. Revised As proposed in the text: An EDMG STA transmitting an RTS carried in duplicate format and addressed to an EDMG STA in order to establish TXOP for transmission of only SISO PPDU, shall set the TXVECTOR parameter CH_BANDWIDTH to the set of channels as achieved
11ax Editor: Add the following lines in Tables E-4 in Annex E: Global operating classes Operating Nonglobal operating class(es) Channel starting frequency (GHz) Channel spacing (MHz) Channel center frequency index (11ac)(#3077) Behavior limits set
IEEE P802.11 Wireless LANs CR for 6GHz Date: 2018-03-01 Author(s): Name Affiliation Address Phone email Laurent Cariou laurent.cariou@intel.com Introduction 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. The introduction and the explanation of the proposed changes are 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 Comment Proposed Change Resolution 12153 Change 6GHz to 7.125GHz as comment Revised – resolved by CID12205 11960 1 Update the introduction to match the updated PAR by raising the 6 GHz top end. Revised – agree with the commenter. Make the changes as in doc 397r2. 12302 The PAR was recently modified to allow 11ax to operate in the 6-7GHz band. 11ax operation needs to be defined. Include at least the channelization for 11ax operation in the 6GHz band. Revised – agree with the commenter. Make the changes as in doc 397r2. 12959 11ax PAR covers up to 7.125GHz now. The Abstract should reflect this. Replace "between 1 GHz and 6 GHz." with "between 1 GHz and 7.125 GHz." Revised – agree with the commenter. Make the changes as in doc 397r2. 12961 While not a part of 11ax D2.0, the Introduction should reflect the fact that 11ax PAR covers up to 7.125GHz now. Replace "between 1 GHz and 6 GHz." with "between 1 GHz and 7.125 GHz." Revised – agree with the commenter. Make the changes as in doc 397r2.
11ax Editor: Add the following lines in Tables E-4 in Annex E: Global operating classes Operating class Nonglobal operating class(es) Channel starting frequency (GHz) Channel spacing (MHz) Channel center frequency index (11ac)(#3077) Behavior limits set
CID PP LL Comment Proposed Change Resolution 12718 170 3 "All of the MPDUs within an have the same TA." -- either this is a new requirement that can't apply to legacy devices, or it's already a requirement Delete the cited text Rejected Discussion: This avoids that in a broadcast RU, frames from multiple virtual APs are aggregated in one A-MPDU. 13079 170 7 a broadcast RU is a DL RU intended for multiple STAs (according 27.11.1), so this RU can convey frames addressed to several stations. This new form of RU mandates relaxing the TA MPDU As indicated per comment, MPDUs aggregated in a AMPDU of an HE PPDU sent in a broadcast RU may have a RA field set to distinct MAC addresses Rejected Discussion: a broadcast RU can only carries frames to a single STA or broadcast frames. With this the A-MPSU reception functionality doesn’t need to be changed.
QoS Null MPDUs with Ack Policy set to No Ack In a DMG BSS, QoS Null MPDUs with Ack Policy set to No Ack. QoS Null MPDUs with Ack Policy set to No Ack. Immediate BlockAckReq At In a single TID A-MPDU context, at most one BlockAckReq frame with a TID that corresponds to an HT-immediate block ack agreement. In multi-TID A-MPDU context, at most one multi-TID BlockAckReq frame with TIDs that correspond to block agreements. This frame is the last MPDU in the A-MPDU. It is not Neither a BlockAckReq nor a BlockAckReq frame is present if any QoS Data frames for that TID are present. Action At most one Action frame
IEEE P802.11 Wireless LANs CR on EDMG Channel Measurement Feedback Date: 2018-3-6 Author(s): Name Affiliation Address Phone email Lei Huang Panasonic CID Page Line Comment Proposed Change Proposed Resolution 1975 68 3 N_TXxN_RX - neither are defined in the subclause. Either reference to another place in which they were defined or better, define the values here Define or reference N_TX, N_RX, N_Tsc. Revised NTX and NRX have been defined in D1.1. 1996 67 1 In the EDMG Sector Order field, subscript Nmeas may be not consistent with its original definition in 802.11-2016 (The number of channel/SNR measurements reported, Nmeas, is equal to the number of TRN-T subfields). In 11ay D1.0 P77L13: The number of measurements, Nmeas, is NTX *NRX Use another variable instead of if necessary. Revised Agreed that there is inconsistency between two definitions of Nmeas in DMG Beam Refinement element (see P72 of D1.1) and MIMO Feedback Control element (see P100 of D1.1). TGay editor to make the changes shown in under all headings that
multiples of the number of TX sector combinations, Ntsc. include CID 1996. 2018 68 21 The part "where the AWV feedback ID_i indicates the AWV for a TX DMG antenna having its TX antenna ID equal to the TX antenna ID value, which is used to transmit the BRP_TX/RX packet" is only applicable if the BRP packet was sent with just one antenna. If more antennas are used simultaneously this behaviour can be ambiguous. Please clarify the definition of the AWV when multiple TX antennas are used simultaneously. An easy fix can be to define the AWVs as MIMO AWVs so the same value is used for the j configuration, when the bitmap indicating the TX mask contains more than a "1". Rejected The part mentioned in the comment is also applicable if the EDMG BRP packet is transmitted through multiple antennas simultaneously. In this case, a TRN subfield of EDMG BRP packet is transmitted using AWVs of multiple antennas simultaneously which have the same AWV feedback ID value. 2237 68 19 Not clear why the RX antenna id is needed by transmitter when reporting SISO id subset Add a sentence to describe that RX antenna id is reserved in EDMG sector ID order when included in MIMO BF Revised Agreed in principle. TGay editor to make the changes shown
for the purpose of tx sector combination. The responder maintains an association between SISO id subset index and the rx antenna/awv setting Feedback frame in under all headings that include CID 2237. 2019 69 2 There seems to be something missing in the sentence after the equation insert: where h_(m,n)^(j) (m=1,.., n=..) represents ... Accepted TGay editor to make the changes shown in under all headings that include CID 2019. Proposed changes to D1.1: 9.4.2.130 DMG Beam Refinement element Change Table 9-235 as follows (CID #1996) Subfield Meaning
IEEE P802.11 Wireless LANs 802.11ba Teleconference Minutes November-December 2017 Date: 06-28-2017 Author(s): Name Affiliation Address email Leif Wilhelmsson Ericsson AB Mobilvägen 1, 22632 Lund, Sweden +46-706-216956 Teleconference on Monday, November 27, 2017, 10:00 – 11:00am (ET) Agenda: 1. Call meeting to order 2. Agenda setting 3. Patent policy (link at the end of the 4. Attendance: send email to the chair or TGba secretary (Leif Wilhelmsson) 5. Presentations 6. Adjourn Please note that teleconferences are bound by the conditions stipulated by the documentation below. Please review them and bring up any questions/concerns you may have before proceeding with the teleconference: IEEE Patent Policy - Patent FAQ - LoA Form - Affiliation FAQ - FAQ - Ethics - IEEE 802.11 Working Group Operations Manual – Minyoung Park (Samsung) calls the meeting to order at 10:00am (ET). Minyoung goes through the agenda and asks if is anything that should be added to the agenda. No discussion on the agenda, so the proposed agenda will be used.
IEEE P802.11 Wireless LANs CR on Hybrid Beamforming feedback Date: 2018-05-07 Author(s): Name Affiliation Address Phone email Sunwoong Yun LG Electronics Seocho LG R&D Lab, Korea sunwoong.yun@lge.com Kome Oteri InterDigital 9710 Scranton Road, #250, San Diego, CA, 92121 Kome.oteri@interidigital.com Dana Ciochina Sony Europe Ltd dana.ciochina@sony.com Thomas Handte Sony Europe Ltd thomas.handte@sony.com SungJin Park LG Electronics allen.park@lge.com Saehee Bang LG Electronics saehee.bang@lge.com Jinmin Kim LG Electronics jinmin1230.kim@lge.com Jinsoo Choi LG Electronics js.choi@lge.com Sanggook Kim LG Electronics San Diego/California/US sanggook.kim@lge.com Chris Hansen Peraso chris@covariantcorp.com Nelson Costa Peraso nelson@perasotech.com CID Clause Number(C) Page Comment Proposed Change Resolution 1375 10.38.9.2.4.4 179.17 The feedback phase is not defined, not in terms of protocol and not in terms of which frames are used Define the feedback Revised TGay editor to make the changes in under all headings that include CID 1375 1579 10.38.9.2.4.4 174.16 Currently, there is no spec text for HBF grouping element Ng. If details for HBF feedback are defined, the value of Ng shall be defined. Define HBF feedback grouping element Ng See resolution to CID 1375
1580 10.38.9.2.4.4 174.16 If the values of HBF grouping element Ng are defined, subcarrier indices for compressed beamforming matrix shall be defined for each channel bonding case Define subcarrier indices for compressed beamforming matrix See resolution to CID 1375 1581 10.38.9.2.4.4 174.16 Currently, is no spec text for compressed beamforming report information. If defined, quantization bit of psi and phi for compressed beamforming shall be defined Define quantization bit of psi and phi See resolution to CID 1375 1905 10.38.9.2.4.4 179.16 Feedback for Hybrid BF needs to be finalized finalize feedback See resolution to CID 1375 2026 10.38.9.2.4.4 179.16 The actual feedback format for the digital beamforming matrix is not defined. Please define feedback format for SC and OFDM digital beamforming matrix. See resolution to CID 1375 TGay Editor: Please make the following change on Pg 97 ln 19 (#1375, #1887, #1579, #1580, #1581, #1905, #1994, and #2026): MIMO BF Feedback frame format The MIMO BF Feedback frame is an Action No Ack frame. The format of a MIMO BF Feedback frame Action field is shown in Table 17.
trigger frame as a TXOP initiator cause useless NAV duration causing channel inefficiency. a PIFS recovery shall not be used in such case. 13055 "Use of RTS/CTS exchange to obtain the TXOP" needs to be explained. As far as I am concerned HE STA still uses CSMA/CA to obtain access and TXOP. How does the RTS/CTS exchange obtain a TXOP? clarify the statement highlighted in the comment Revised- Agree in principle. Initiating a TXOP with the RTS/CTS is more reasonable wording. TGax editor makes changes as shown in the as specified in 13188 Clarify that when TXOP Duration RTS field is set to 1023, the STA defaults to baseline behavior as specified in 10.3.1 Add a sentence to the end of this paragraph as follows: "The AP may set the TXOP Duration RTS Threshold field to 1023 to not require the use of by its associated STAs for enabling RTS/CTS exchanges. In such case, the associated STAs follow the rules defined in 10.3.1 (General)" Revised- Agree in principle. When TXOP RTS/CTS exchange is disabled, the associated STAs follow the rules defined in 10.3.1. TGax editor makes changes as shown in the as specified in 14228 Features described in this subclause are for HE devises, so it is not needed to mention that legacy devises do not support them. Delete "The is not present at a non-HE non-AP STA." Accepted 14326 TXOP duration-based RTS/CTS is not a well designed mechanism. The threshhold should be in PSDU length rather than the TXOP duration. as in the comment Rejected- The commenter is failed to indetify the issue. There is no sufficient reason why the unit of the threshold has to be changed from the TXOP duration to the PSDU length. 11483 The is sent to associated STAs in HE operation element either individually or to all associated STAs. There should be a option to sent to a group of associated STAs, for example type of STAs. commenter will submit contribution to propose a solution. Revised- See the discussion part of 11-18/0455r2. TGax editor makes changes as shown in the as specified in
AOB None. Recess TGax ad hoc meeting is in recess at 17:50 until 9:00 AM tomorrow (Local Time). List of Attendees of day 1 Name Affiliation 1 Osama Aboul-Magd Huawei Technologies 2 Alfred Asterjadhi Qualcomm 3 Edward Kwok Shum Au Huawei Technologies 4 Laurent Cariou 5 Chu Marvell Semiconductors 6 Matthew Fischer Broadcom Ltd. 7 Ming Gan Huawei Technologies 8 Jason Yuchen Guo Huawei Technologies 9 Po-Kai Intel 10 Chunyu Hu Broadcom Ltd. 11 Yasuhiko Inoue NTT 12 Jeongki Kim LG Electronics 13 Jarkko Knect Apple 14 Zhou Lan Broadcom Ltd. 15 Guoqing Li Apple 16 Li Huawei Technologies 17 Kaying Lv ZTE 18 Pooya Monajemi Cisco Systems 19 Patrice 20 Minyoung Park Samsung 21 Abhishek Patil Qualcomm 22 Al Petrick InterDigital Communications 23 Kiseon Ryu LG Electronics 24 Yongho Seok MediaTek 25 Robert Stacy Intel 26 Bo Sun ZTE 27 Chao-Chun Wang MediaTek 28 Huizhao Wang Quantenna Communications 29 Xiaofei Wang InterDigital Communications 30 David Xun Yang Huawei Technologies Thursday, 1st, 2018, 9:00 – 18:00 TGax ad hoc – Day 2 Meeting called to order by Osama Aboul-Magd (Huawei Technologies), the chairperson of TGax @ 09:00 (Local Time). Introduction of the chairperson Aboul-Magd (Huawei Technologies) and the secretary Yasuhiko Inoue (NTT). Reminder Chair reminded that we are still operating under IEEE 802 and IEEE 802.11 Policy and Procedure. Chair asked people to state name and affiliation when addressing for the first time in the session. also asked people to signed up the attendace sheet. It is just for the minutes and is not affecting the voting right.
AoB 2 minutes left. No business to conduct in 2 minutes. Adjourn TGax ad hoc March 2018 adjourned @ 16:58 (Local Time) List of attendees Name Affiliation 1 Osama Aboul-Magd Huawei Technologies 2 Alfred Asterjadhi Qualcomm 3 Laurent Cariou Intel 4 George Cherian Qualcomm 5 Liwen Chu Marvell Semiconductors 6 Vinko Erceg Broadcom 7 Matthew Fischer Broadcom 8 Ming Gan Huawei 9 Jason Yuchen Guo Huawei 10 Chunyu Hu Broadcom Ltd. 11 Po-Kai Huang Intel 12 Yasuhiko Inoue NTT 13 Jeongki Kim LG Electronics 14 Jarkko Knect Apple 15 Zhou Lan Broadcom 16 Guoqing Li 17 Yunbo Li Huawei Technologies 18 Kaying Lv ZTE 19 Patrice Nezou Canon 20 Abhishek Patil Qualcomm 21 Al Petrick InterDigital Communications 22 Kiseon Ryu LG Electronics 23 Yongho Seok MediaTek 24 Chao-Chun Wang MediaTek 25 Huizhao Wang Quantenna Communications 26 James Wang MediaTek 27 Xiaofei Wang InterDigital 28 James Yee MediaTek
CID Commenter Clause Page/Line Comment Proposed Change Resolution 13342 Ron Porat 27.12 309.00 The text is not explict PPE threshold values to use for RU 106 + DCM. There are two interpretations: 1) 0, because RU106 falls outside the RU set that has PPE threshold values defined. 2) The PPE threshold values belonging to RU 242, due to the 'b+1' formula. The text needs to clarify this. Make it more explicit and clear. Revised Editor: Please make the changes shown in document 13401 Ron Porat 9.4.2.237.5 149.10 Packet extension should be enabled for RU<242 in to harmonize the design with RU>=242 and limit power consumption change in the column 'RU allocation size' of table 9-262ad the number 242 to 'less than or equal to 242' Revised. Editor: Please make the changes shown in document Hongyuan 9.4.2.237.5 147.65 In Table (RU Allocation Index), RUs that are smaller than RU242 is not present, this means that PE shall always be 0 for these smaller RUs? Add a note saying "No PE is required for RUs smaller than 242 subcarriers". Revised. Editor: Please make the changes shown in document 13338 Ron Porat 9.4.2.237.5 148.64 Previously, variable 'm' was used as max index of RU allocation index 'b' ; Change RUm to RUb Accepted. Editor: Please make the changes in D2.2 153.33
where b =[x, ..., m]. Variable 'b' is used to represent RU allocation index in general. 13340 Ron Porat 27.12 309.00 Clarity of the text needs improvement. 'value' is present in middle column but missing in first and third columns. 'm' is introduced only as NSSnRUm subfield, but it is not explicit what m is. change all columns as .. RU Allocation m = (b + DCM) to the ... Revised. Editor: Please make the changes shown in document 13341 Ron Porat 27.12 309.00 The text on RU allocation index selection when using DCM is unclear. Adding an example will prevent interpretation errors. Add a note with an example for RU 242 + DCM, the PPE threshold values for RU size 484 are to be used. Revised. Editor: Please make the changes shown in document 13343 Ron Porat 27.12 309.00 In case of RU 2x996 + DCM, b+1 refers to non-existing entry in the PPE threshold table. Clarify that for RU + DCM the PPE threshold values for RU 2x996 are used. Revised. Editor: Please make the changes shown in document 13344 Ron 27.12 309.00 typo Change"greater than equal" to "greater than or equal to" Accepted. Editor: Please make the changes in 27-10 in D2.2 Discussion The proposed changes in this document clarify the packet extension in relation to the DCM Editor: Changes for all comments are as follows:
lower and upper 80 MHz frequency portions. NOTE--The signal phase of the two 80 MHz frequency portions might not be correlated." 14202 485 39 HE-SIG-A field consists of many fields as shown in Table 28-18. Bandwidth subfield should be modified with Bandwidth field as in comment Revised. 11ax editor, please see the discussion for instructions of CIDs 13765, 14202, 14203, 14204 and 14205 in doc IEEE 14203 485 40 HE-SIG-A field consists of many fields as shown in Table 28-18. Bandwidth subfield should be modified with Bandwidth field as in comment Revised. 11ax editor, please see the discussion for instructions of CIDs 13765, 14202, 14203, 14204 and 14205 in doc IEEE 14204 485 43 HE-SIG-A field consists of many fields as shown in Table 28-18. Bandwidth subfield should be modified with Bandwidth field as in comment Revised. 11ax editor, please see the discussion for instructions of CIDs 13765, 14202, 14203, 14204 and 14205 in doc IEEE 14205 485 44 HE-SIG-A field consists of many fields as shown in Table 28-18. Bandwidth subfield should be modified with Bandwidth field as in comment Revised. 11ax editor, please see the discussion for instructions of CIDs 13765, 14202, 14203, 14204 and 14205 in doc IEEE 14320 494 12 In draft 2.0, 28.3.11.16 Midamble is added to support long packets in fast fading environment, i.e. insert midamble every 10 or 20 OFDM symbol. However the EVM measurement method is not updated accordingly in 28.3.18.4.4 Transmitter modulation accuracy (EVM) test. Please evaluate and suggested a reasonable long packets for EVM test, which eventually will guarantee a good throughput in real operation. Maybe we should use 32 OFDM for all cases, Rejected. Midamble is an optional feature and it is not essential to the EVM tests. In the 11ax spec, the following sentence is added to exclude the
CID Clause Page Line Comment Proposed Change Resolution 12311 491 51 It is important for the AP to know the Max Power for MCS7 or to derive the target RSSI for max power for MCS 7 as this is the threshold between 2 different EVM requirements. There should be an efficient way of collecting such information, or requiring STAs to operate at or below that power level. Ensure that the spec defines efficient operation around Max power for MCS7 to allow the AP to force STAs to operate with good EVM Rejected. it is for HE TB PPDU, the transmit power of each STA is controlled the AP. And different immplementations have different max power for MCS7. The requirement for EVM of other MCSs for HE TB PPDU is just to reduce the inter-user interferences. 3.2 29 42 the definitions of 20MHz mask PPDU for i), j) and k) are unnecessary since they are covered by b), c), and d), respectively. delete bulletins i), j) and k) Revised. 11ax editor, please see the discussion for instructions of CID 12319 in doc IEEE 802.11-18/0475r2. 12320 3.2 30 44 the definitions of 40MHz mask PPDU for k) and l) are unnecessary since they are covered by a) and f), respectively. delete bulletins k) and l) Rejected. In D2.2, item k) and l) specify the HE STA, they are different from a) and f). 12321 3.2 31 21 the definitions of 80MHz mask PPDU for f) and g) are unnecessary since they are covered by a) and b), respectively. delete bulletins f) and g). Revised. 11ax editor, please see the discussion for instructions of CID 12321 in doc IEEE 802.11-18/0475r2.
with 40 MHz, 80 MHz ... and apply the same change if needed. 13120 3.2 29 39 item (a) already covers item (h) Remove item (h) Revised. Please refer to the resolution of CID 12319. 13500 494 22 "shall meet the relative constellation error staircase mask ". Provide reference. See comment Revised. 11ax editor, please see the discussion for instructions of CID 13500 in doc IEEE 802.11-18/0475r2. 13765 485 38 "The bandwidth of the spectral mask applied to an HE SU PPDU, an HE TB PPDU and an HE MU PPDU with the Bandwidth subfield of the HE-SIG-A field equal to 0, 1, 2 or 3 shall be determined by the bandwidth indicated in the Bandwidth subfield of the HE-SIG-A field." If 20MHz only STA is multiplex with 80MHz capable STAs via OFDMA in MU PPDU and TB PPDU, the mask of 20MHz only STA should still be 20MHz instead of the BW indicated in HE-SIG-A. Add the following sentence before the last sentence of P.L. 485.46. "The bandwidth of the spectral mask applied to an 20MHz only STA shall be 20MHz regardless of the Bandwidth field indicated in in the MU PPDU or TB PPDU" Rejected. The STA can only transmit HE SU PPDU and HE MU PPDU using 20MHz spectral mask. For HE TB PPDU, 20MHz only STA should be no difference with other STAs. 14088 491 11 Transceivers for HE160/80+80 MHz PPDUs may use two RF LOs, one for each 80 MHz portions. Add to the end of 28.3.18.3: "Transmit signals with TXVECTOR parameter CH_BANDWIDTH set to CBW160 or may be generated using two separate RF LOs, one for each of the Revised. Already Resolved in D2.2, see comment resolution for CID 11890 (11-17/1730r2). A
IEEE P802.11 Wireless LANs Comment resolution on CIDs on Clause 28.3.18.1 for signal leakage to preamble punctured channels Date: 2018-02-16 Author(s): Name Affiliation Address Phone Email Jianhan Liu Mediatek Jianhan.liu@mediatek.com Ron Porat Broadcom ron.porat@broadcom.com Abstract: This document contains comment resolution on the following CIDs for 28.3.18.1 and the proposed specification changes are in draft 2.2: 11358 and 13200. CID Clause Page Line Comment Proposed Change Resolution 28.3.18.1 489 58 Revised. 11ax editor, please see the discussion for instructions for CID 11358 in doc IEEE 802.11-18/0xxxr0. 13200 28.3.18.1 489 55 When preamble puncturing is used, the spectral mask stays the same as for the total bandwidth. This effectively means that preamble puncturing is useless. Define some mask requirement for preamble puncturing or remove preamble puncturing completely. Revised. 11ax editor, please see the discussion for instructions for CID 13200 in doc IEEE 802.11-18/0xxxr0. Discussions for CID and 13200: In 11ax, 4 preamble puncturing modes are defined. Preamble puncturing in 80 MHz, where in the preamble only the secondary 20 MHz is punctured.
IEEE P802.11 Wireless LANs Abstract Proposed language to address the issue of disallowed subchannels. The proposed change is to add a new field to the end of the HE Operation IE called Operational Subchannel Information field. One additional bit called Punctured Operation is added inside of the HE Operation Information field to signal the presence/absence of the new field The new field is a combination of resolution indication, length and a bit map, where the resolution is a coded 3 bit value and the length is a 3 bit value and the bit map is the length of octets indicated in the length field. Each bit of the bitmap corresponds to a subchannel of the resolution 20 MHz indicated in the resolution field. The lowest numbered bit corresponds to the subchannel with the lowest frequency of the BSS operating channel, etc. A bit set to 1 indicates transmissions are allowed on that subchannel. A bit set to 0 indicates transmission is not allowed on that subchannel. The absence of the field indicates no puncturing, i.e. transmission is allowed on all subchannels of the BSS channel width. Corresponding behavioral language is added to subclause 27. The proposed changes on this document are on TGax Draft 2.1. REVISION NOTES: R0: initial
Summary of the proposed change: The proposed change is to add a new field to the end of the HE Operation IE called Operational Subchannel Information field. One additional bit called Punctured Operation is added inside of the HE Operation Information field to signal the presence/absence of the new field The new field is a combination of a length and a bit map, where the length is a 3 bit value and the bit map is the length of octets indicated in the length field. Each bit of the bitmap corresponds to a specific subchannel. The lowest numbered bit corresponds to the subchannel with the lowest frequency of the BSS operating channel, etc. Note that a length field is needed in order to maintain extensibility of the HE Operation element. A bit set to 1 indicates transmissions are allowed on that subchannel. A bit set to 0 indicates transmission is not allowed on that subchannel. The absence of the field indicates no puncturing, i.e. transmission is allowed on all subchannels of the BSS channel width. Corresponding behavioral language is added to subclause 27. Proposed Changes to Draft Text of TGax D2.1: 9.4.2.238 HE Operation element TGax editor: change one of the reseved bits of the HE Operation Parameters field to be a new one-bit subfield called “Punctured Operation” and add the following paragraph as a description of the new subfield: The Punctured Operation subfield indicates whether the BSS channel width includes disallowed subchannels. The Punctured Operation subfield is set to 1 to indicate that the BSS channel width includes disallowed subchannels and is set to 0 otherwise. The Punctured Operation subfield is set to 0 when transmitted by a STA operating in the 2.4 GHz band. (#14323) TGax editor: add one new subfield called “Operational Subchannel Information” to the side of Figure 9-589cq – HE operation element format, label the width of the new subfield as “variable” and add the following paragraphs and figures as descriptions of the new subfield and its sub-subfields:
IEEE P802.11 Wireless LANs CR for MU EDCA parameters Date: 2017-11-28 Author(s): Name Affiliation Address Phone email Laurent Cariou laurent.cariou@intel.com Introduction 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. The introduction and the explanation of the proposed changes are 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 As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft. Clause Page Comment Proposed Change Resolution "its MIB variables related to CWminand CWmax" -- lazy specification Cite the specific variables or delete the note. Revised – agree with the comment. Delete the note and apply the changes as proposed in doc . Smith 27.2.6 "A STA that has not received an MU EDCA Parameter Set element from the AP to which it is associated does not follow the procedure described in this subclause." Why not make this positive rather than negative. Much better Replace cited text with "A STA that has received an MU EDCA Parameter Set element from the AP to which it is associated follows the procedure described in this subclause." Revised – agree with the commenter. Apply the changes as proposed in doc . n
16723 Ron 28.3.16 547.53 preamble puncturing as currently defined in D3.0 is lacking several features needed to make it useful especially in Radar channels when some subchannels are blocked for very long durations Please consider adding the following enhancements: 1. Broadcast message to declare Subchannel Punctureds 2. Punctured NDP to enable BF and DL MU-MIMO 3. NDPA signaling of punctured subbands in the NDP 4. Punctured Non-HT Dup to NDPA 5. New PHY modes to enable single user transmission across the entire available punctured BW with at least 60MHz support and one mode for >80MHz (e.g. 120MHz) Revise - TGax editor to make changes as shown in that are marked with CID 16723 15920 28.3.16 Enable sounding in transmissions where certain channels are punctured As in comment Revise - TGax editor to make changes as shown in that are marked with CID 16723 which are redundant to changes for CID 15920. Discussion: Operation within some bands in some regulatory jurisdictions requires monitoring and/or other means of determining whether a primary operator is using channels in the band (e.g. database information). If primary devices are detected or otherwise indicated as operating within a channel, then regulations might require that secondary users, e.g. WLAN devices, are required to cease transmissions in the channel. Because some regulations allow operation on an aggregation of multiple disjoint channels in some of these “shared” bands, and might add additional similar regulations for various bands in the future, and provided that it is in the interest of 802.11 devices to be able to take advantage of disjoint aggregation,
Self-interference produced by the transmitted signal can be a billion times stronger than the desired received signal and thus has a significant impact on RF and digital properties of the desired signal [20]. In general, self-interference includes: linear components: leakage from Tx to Rx, possible reflections due to antenna/transceiver, and reflections from environment. The main signal power could be about the same level of the Tx power; nonlinear components: nonlinear distortion due to Tx power amplifier (PA), which is about 30 dB lower than the main signal in linear self-interference [2]; Tx noise: due to PA noise and phase noise, which is about -50 dBm [2]. Assume that in an indoor environment, noise figure (NF) is 6 dB; bandwidth (BW) is 20 MHz; and implementation margin (Io) is 5 dB (note: thermal noise Nthermal = k*T*BW, k is Boltzman’s constant (=1.38 x 10-23 J/K), absolute temperature T=290 K, BW is channel bandwidth) The noise floor is calculated as: – 114 dBm = -90 dBm. If the transmit power equals 20 dBm, it requires an FD receiver to have an ability to cancel in a level of 20-(-90) = 110 dB in order to reduce the main signal to the noise floor power level. The self-interference channel impulse response can be appropriately modelled as shown in [20] where the parameters of the internal portion of the self-interference channel impulse response depend on the internal antenna structure. They are quasi-static and can be calculated/estimated based on the antenna structure specifications while the parameters of external portion of the self-interference channel impulse response depend on the external possible reflectors in the surrounding environment and are time-varying. Figure 4 illustrates the locations of various parasitic self-interference mechanisms present in a full duplex transceiver that need to be mitigated. Figure 4 Self interference mechanisms in a Full Duplex transceiver. Whereas Figure 5 illustrates the relative magnitudes of the transmitted and received signal levels in a full duplex use case along with the relative magnitudes of the signal levels after each stage of process. Received signal power Path loss The received signal power can be calculated using the following Friis transmission equation: where the terms in the equation are: Pr — Received signal power in watts Pt — Peak transmit signal power in watts Gt — Transmitter gain interference
IEEE P802.11 Wireless LANs Comment Resolutions on Clause 10.38.7 (Beam Tracking) Date: 2018-02-28 Author(s): Name Affiliation Address Phone Kome Oteri InterDigital 9710 Scranton Road, San Diego, CA 92121 +1-858-210-4826 kome.oteri@interdigital.com Rui Yang Abstract This submission proposes resolutions for the following 2 comments on Clause 10.38.7 (Beam Tracking) of TGay D1.0: 1925, 1926 Revisions: Rev 0: Initial version of document 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 TGay Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGay Editor: Editing instructions preceded by “TGay Editor” are instructions to the TGay editor to modify existing material in the TGay draft. As a result of adopting the changes, the TGay editor will execute the instructions rather than copy them to the TGay Draft. CID Clause Number P.L Comment Proposed Change Resolution 1925 10.38.7 161.04 "NOTE--If the parameter in the RXVECTOR is Baseband Beam Tracking, the baseband beamformers at the initiator and responder can be set to a predetermined orthogonal matrix (e.g., the identity matrix) during the transmission of the appended TRN-R subfields only and the measurement at the initiator is based on the appended TRN-R packets". We can remove the transmitter as the TRN fields Modify text: NOTE--If the parameter in the RXVECTOR is Baseband Beam Tracking, the baseband beamformers at the INITIATOR can be set to a predetermined orthogonal matrix (e.g., the identity matrix) during the transmission of the appended TRN-R subfields only and the measurement at the initiator is Revised TGay editor to make the changes shown in 11-18/0500r0 under all headings that include CID 1925
IEEE P802.11 Wireless LANs CR for CID 14331, 14332, 14347 Date: 2018-02-27 Author(s): Name Affiliation Address Phone email Zhou Lan Broadcom Ltd. 250 Innovation Dr, San Jose, CA 95134 +1-408-9223450 zhou.lan@broadcom.com Chunyu Hu Broadcom Ltd. 250 Innovation Dr, San Jose, CA 95134 chunyu.hu@broadcom.com Matthew Fischer Broadcom Ltd. 250 Innovation Dr, San Jose, CA 95134 matthew.fischer@broadcom.com Abstract This submission proposes resolutions for multiple comments related to TGax D2.3 with the following CIDs: 14331, 14332, 14347 Revisions: Rev 0: Initial version. 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 As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft. CID Commenter P.L Comment Proposed Change Resolution
13214 Robert Stacey 264.09 This statement is not necessary. An HE beamfomer controls what it receives: it sets the Feedback Type And Ng field in the HE NDP Announcement frame appropriately. Remove the statement. REVISED (MU: 2018-01-24 05:51:29Z) TGax editor to make the changes shown in 11-18/0042r1 under all headings that include CID 13214. 13215 Robert Stacey 264.14 This statement is not necessary. It's the behavior when the field is set a certain way that is important. Remove the statement. REVISED (MU: 2018-01-24 05:51:58Z) TGax editor to make the changes shown in 11-18/0042r1 under all headings that include CID 13215. 13216 Robert Stacey 264.18 This statement is not necessary. The behavior that is important is the restriction on the HE beamformer sending an HE NDP Announcement requesting partial bandwidth to an HE beamformee that has not set the Trigger MU Beamforming subfield to 1. And, BTW, this subfield is poorly named. Remove the statement. REVISED (MU: 2018-01-24 05:52:25Z) TGax editor to make the changes in 11-18/0042r1 under all headings that include CID 13216. 13217 Robert Stacey 264.23 This statement is not necessary. The behavior that is important is that the HE beamformer not send the HE beamformee an HE NDP Announcement with certain settings in the Feedback Type And Ng field unless the HE beamformee has indicated approriate support for those settings. Remove the statement. REVISED (MU: 2018-01-24 05:52:59Z) TGax editor to make the changes shown in 11-18/0042r1 under all headings that include CID 13217.
“What is an ESS?” (Tues PM2) MLME-RESET, versus MLME-JOIN and MLME-START AP/DS/Portal architecture and 802 and GLK concepts - , , , , (slides 9-11) Continue the Wednesday, March 7, AM1 Investigation of WUR architecture topics; may lead into “split” PHYs (LC, 28 GHz (Phazr)): (Wed AM1) Continue the Future sessions / SC activities Administration: The Chair reviewed the Administrative information in slides 5-10 in Agenda document, Call for Patents: The Chair reviewed the Patent policy and called for potentially essential patents – there was no response to the call. Approval of the Agenda: The Chair called for comments or amendments to the agenda – there was no response to the call The proposed agenda was approved by unanimous consent. ARC Minutes: January face-to-face minutes: Minutes approved by unanimous consent. IEEE 1588 mapping to IEEE 802.11/802.1ASrev use of FTM update - Chair asked Ganesh Venkatesan (Intel) for a status report: Ganesh Venkatesan – nothing new to add - have not met with anyone this week on this. Currently ok with the current mapping of FTM. Will update if anything changes. 802 (and 802.1) activities: 802c, 802.1CQ Chair: This looks like it is basically done regarding the 802.1Q revision and we have no known issues. Called for comments, none were coming. Chair: Regarding 802c and (follow on) 802.1CQ, reviewed status Comment – they (802c) really screwed up the 802.11aq timeline and what can be done to not have this happen again. Chair: in the future .11 can look at 802c and avoid the issue. Comment - a call was made for more than monitoring. Chair: indicated that we could allocate agenda time. Question: Is there a section in 802.11 where we say we comply – do we need to run an 802c check. Chair: we already incorporate 802 (which includes 802c) – but any review may be an MDR type thing.