zilongwang/ReadingBank huggingface dataset:
Attendance Chair asked the attendees to send an email to Yasuhiko () and/or Osama () to record attendance. Announcement Chair asked people to state name and affiliation when addressing for the first time during the session. Ad Hoc Meeting in Shenzhen from November 7th to 9th, 2018 Information sharing - How to get to the meeting venue from Hong Kong Airport. It is good to bring the document that Ross had sent to the TGax reflector. Unassigned comments There are 142 unassigned comments. Call for volunteers: The TGax technical editor will send an AOB None Adjournment No time to go through the rest of the agenda items. Meeting adjourned at 10:20 (ET). List of Attendees – following people were on the call. Name Affiliation 1 Osama Aboul-Magd Huawei Technologies 2 Stephane Canon Research 3 Yasu Inoue NTT 4 Patrice Nezou Canon Research 5 Stacey Intel 6 Pascal Vigar Canon Research 7 8 9 10 Teleconference on Thursday, November 1st, 2018, 10:00 – 12:00 (ET) Meeting called to order by Osama Aboul-Magd (Huawei Technologies), the chairperson of TGax @ 10:05 (ET). Introduction of the chairperson Aboul-Magd (Huawei Technologies) and the secretary Yasuhiko Inoue (NTT). Agenda Setting Proposed Agenda Call the meeting to order IEEE 802 and 802.11 IPR policies and procedures Attendance reminder: Please send an e-mail to Yasuhiko Inoue (inoue.yasuhiko@lab.ntt.co.jp) and/or Osama Aboul-Magd (osama.aboulmagd@huawei.com) Announcements Ad Hoc meeting in Shenzhen – November 7th – 9th, 2018 – if any.
A member commented that CID 16624 has been rejected and the correct procedure is to submit the comment in the next round of the letter ballot and provide resolution. People mentioned that the clause 28.3.10.8 HE-SIG-B has had hundreds of comments and the text in 28.3.10.8 have been changed. And now people build their product based on current spec, therefore, current text is clear enough. Some participants also suggested the same procedure of re-submitting the comment during the next letter ballot and come back with the proposed text changes. Next Step Brian to work offline with interested people. This document will not be motioned during the Bangkok meeting. AOB None Adjournment No time to go through the rest of the agenda items. Meeting adjourned at 10:45 (ET). List of Attendees – following people were on the call. Name Affiliation 1 Osama Aboul-Magd Huawei Technologies 2 Brian Hart Cisco Systems 3 Lili Hervieu CableLabs 4 Yasu Inoue NTT 5 Al Petrick InterDigital Communications 6 Dinakar Prabhakaran ??? 7 Sigurd Schelstraete Quantenna Communications 8 Jung Hoon Suh Huawei Technologies 9 Rui Yang InterDigital Communications 10
IEEE P802.11 Wireless LANs Comment resolution on dot11EDCATable Date: 2018-11-02 Author(s): Name Affiliation Address Phone email Robert Stacey +1-503-724-0893 robert.stacey@intel.com Comments CID Page Clause Comment Proposed Change Resolution 1080 1567.27 10.2.3.2 Not necessarily consistent with P3788L55 ("Changes take effect as soon as practical in the implementation"). Also, was the intent to ensure that the MIB is up to date or that the EDCA parameters take effect within a certain time? This statement certainly does not achieve the latter. Update the MIB object descriptions and/or the statement here. E.g., "A QoS STA, on receiving an updated EDCA Parameter Set element, should update the dot11EDCATable as soon as pratical in the implementain but shall update the dot11EDCATable within an interval of time equal to one beacon interval." REVISED - in principle with the change. Change the "A QoS STA shall update MIB attributes that to fields in an EDCA Set element within an interval of time to one beacon interval after receiving an updated parameter set." to "A QoS STA, on receiving an updated EDCA Set element, should the dot11EDCATable as soon as pratical in the implementain but shall update the dot11EDCATable within interval of time equal to beacon interval."
IEEE P802.11 Wireless LANs CR for TSPEC Date: 2018-11- Author(s): Name Affiliation Address Phone email Guoqing Li Apple Jarkko Kneckt Apple 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 (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 Commenter Page Clause Comment Proposed Change Resolution 15093 Abhishek Patil 303.01 27.5.7 An HE AP does not respond to an ADDTS Request from a non-AP HE STA. Does that mean HE STAs cannot establish a TS Setup (11.4.4)? Clarify the condition under which an AP doesn't respond - i.e., differentiate between a non-AP STA reporting TSPEC versus STA requesting a TS setup. Revised. There is no need to restrict the HE STA from using schedule. The ADDTS use in clause 11.4.4 and 27.5.3 is clarified. Please implement the changes identified for CID15093 shown in document 11-18-1830r1. 15130 Albert Petrick 133.09 9.4.2.30 Table 9-141 describes the selection Bit 14 and B15 Ack Policy subfield for "Normal Acknowledgment" . Normal Acknowledgement is not defined. The term is not used 802.11-2016 10.3.2.9 Acknowledgment Procedure as referenced in D3.0 Remove "Normal" or define the term. Removing the word Normal clears up any ambiguities Revised. The normal acknowledgement is named as normal Ack in other parts of the spec. Please implement the changes identified for CID15130 shown in document 11-18-1830r1.
459 John Buffington "WID" needs to be defined The first use of "WID" needs to be defined or added to section 3.4. Revised – Agree in principle. Though WID is proposed to be removed and adding the acronym for its sibling “WUR ID”. TGba editor to make the changes shown in 11-18/1834r1 under all headings that include CID 459. r1 r1 541 Leif Wilhelmsson period missing (to be cosistent with e.g. how things are written on page 21. add a period Accepted 637 Michael Fischer Include reference to the place where "critical update ..." is defined (clause 31.7.2). Add cross-reference (something like "as specified in clause 31.7.2") after "... when a critical update ..." Revised – Proposed resolution is to provide a reference to the subclause that provides the normative behavior related to this counter as suggested by the commenter. TGba editor to make the changes shown in 11-18/1834r1 under all headings that include CID 637. r1 r1 r1 787 Osama Aboulmagd "WID" is not defined. What does it mean? Add WID to Clause 3. Revised – Agree in principle. Though WID is proposed to be removed and adding the acronym for its sibling “WUR ID”. TGba editor to make the changes in 11-18/1834r1 under all headings that include CID 787. r1 789 Osama Aboulmagd It is not clear how a receiving WUR non-AP STA would differentiate between the different addresses in the table. as in comment. Revised – The rules are defined in subclause 31.3 where it should be specified that these identifiers do not overlap with each other. TGba editor to make the changes shown in 11-18/1834r1 under all headings that include CID 789. r1 r1 8
IEEE P802.11 Wireless LANs Comment Resolution on PHY Introduction Date: 2018-11-08 Author(s): Name Affiliation Address Phone email Lochan Qualcomm lverma@qti.qualcomm.com Bin Tian Qualcomm CID P.L Comment Proposed Change Resolution "...DCM Max BW subfield indicates the maximum bandwidth...", is this an indication of maximum packet bandwidth or maximum RU size, for example when setting this field to 0 (20MHz), does the device support Rx/Tx an RU106 in an OFDMA packet of total BW=80MHz? Change the defintion of this field to maximum RU size, or add notes to explain the real meaning. Revised Change this capability to be based on RU size instead of PPDU bandwidth Tgax Editor: make changes for CID 15660 according to Discussion ------------- Begin Text Changes --------------- To TGax editor: Please do a global search and replace “DCM Max BW” to “DCM Max RU” To TGax editor: Please make the redline change below on 9.4.2.241.3 P.L 169.47of D3.2 for CID 15660 DCM Max (#11904) If the DCM Max Constellation Tx subfield is greater than 0, then the DCM Max subfield indicates the maximum RU size bandwidth that the STA might transmit with DCM applied. If the DCM Max Constellation Rx subfield is greater than 0, then the DCM Max subfield indicates the maximum RU size with DCM applied that the STA can receive. If both the DCM Max Constellation Tx subfield and DCM Max Constellation Rx Set to 0 for Set to 1 for Set to 2 for Set to 3 for
"UL MU-MIMO and UL OFDMA are preceded by a Trigger frame from the AP." does not account for the TRS frame use statement: UL MU transmissions are preceded by a Trigger or frame carrying a TRS Control subfield from the AP. see pg 420 line for similar language Accept— Discussion ------------- Begin Text Changes --------------- ------------- End Text Changes --------------- CID P.L Comment Proposed Change Resolution "n RU. With OFDMA, different transmit powers may be applied to different RUs.". Clarify that is it both downlink and uplink chane to "n RU. With DL and UL OFDMA, different transmit powers may be applied to different RUs." Reject— While 802.11ax defines UL and DL OFDMA, this specific section is describing the general concept of OFDMA. The DL and UL OFDMA are discussed in the following sections. 409 Conceptually, the description of OFDM and OFDMA in this paragraph is not accurate. Since they are well-known concepts, it is not necessary to have this paragraph. Also, this paragraph is crossed out in the redlined version. Not sure if it is an editorial error or not. Remove this paragraph Reject— The comment doesn’t point out which part of description is not accurate. While the concepts of OFDM and OFDMA are known, this is the first amendment of 802.11 that adds OFDMA feature. A small paragraph introducing the concept is justifiable. Discussion ------------- Begin Text Changes --------------- ------------- End Text Changes --------------- CID P.L Comment Proposed Change Resolution 378 In these three bullets, each has a condition for LDPC coding. It is not See comment Reject— 6
IEEE P802.11 Wireless LANs Resolutions to comments to subclause 9.3.1.9 Date: 2018-11-12 Tomoko Adachi Toshiba 1, Komukai Saiwai-ku, Kawasaki, Japan +81 44 549 2283 tomo.adachi@toshiba.co.jp 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. 9.3.1.9 CID Commenter PP.LL Comment Proposed Change Resolution 16440 Matthew Fischer 85.52 It be nice to have the ability to inform the transmitter of an AMPDU that missing acknowledgements for some MPDUs are not due to a poor MCS choice, but instead, to Add a mechanism in the BA frame, perhaps the MBA, to allow a recipient transmitting the MBA to indicate to the originator that missing acknolwedgements Rejected. Detailed proposal is required to decide. However, it may be presumed by the position of errors in the bitmap, how long is the error
field to 0, AID subfield to 2045, and the TID field to 15 in the Per AID TID Info field, and the RA field of the Per AID TID Info field to the intended recipient's MAC address to indicate the successful reception of that Management frame." And in 27.1 we have "If the Ack Type field is 0, and the AID field is 2045, and the TID field is 15, then Per AID TID Info field indicates the acknowledgement of an EOF-MPDU that is a Management frame soliciting immediate acknowledgment. The RA field in the Per AID TID Info field is the MAC address of an unassociated STA for which the Per AID TID Info subfield is intended." And in 27.4.2 we have "If the Ack Type field is 0 and the TID field is 15, then the Per AID TID Info field indicates the acknowledgment of a single Management frame sent by the unassociated STA as defined by the acknowledgment context." However in the associated context this combination is reserved, and a different combination is used for Management frames AID11 is 2045 and the third reference from the commenter is also mentioning especially of the case when AID11 is 2045 from the context. Note that, when the AID11 is 2045, the settings of the Ack Type and TID subfields are fixed to 0 and 15, respectively, regardless of the original meaning of the subfields. 16374 Mark RISON 91.52 "The responding STA determines that all the carried in the eliciting A-MPDU are successfully received if the all the MPDUs that precede the first MPDU delimiter with EOF Change the text to "The responding STA determines that all the MPDUs carried in the eliciting are successfully Rejected. An EOF-MPDU has a non-zero in the MPDU Length field because an MPDU is carried therein. By saying that MPDUs preceding the first MPDU delimiter
IEEE P802.11 Wireless LANs General and Annex G Comment Resolution Date: 2018-11-06 Author(s): Name Affiliation Address Phone email Aboul-Magd Huawei Technologies General Comments CID Page Line Comment Proposed Change Resolution 15183 3.61 61 There are negative LOAs covering the 802.11ax standard, meaning companies that have claims to essential patents but unwilling to grant a license widely under reasonable terms. As long as these negative LOAs are present, then companies implementing 802.11ax are at risk. Address negative LOAs covering 802.11ax by having them amended to accept to license broadly for free, or under reasonable terms Rejected The commenter point to a technical with the draft. The issues related to patents is not really a discussion and the commenter is raise the issue at the IEEE-SA level. The doesn’t have the to frce changes to submitted LoA. 16081 All the D1.0 comments "resolved" as "REJECTED in the interest of releasing D2.0" or similar (about 500 of them!) were not in fact resolved Resolve all D1.0 comments that were not resolved Rejected Draft D1.0 was on December 1st Since then the draft gone through a revisions with many changes to almost all Clauses. Cmments that were submitted back then either not applicable or have been the satisfaction of the commenter. are alaways welcome use
16701 677.17 17 G Annex G is incomplete. Add missing seqences or add a statement to the effect that HE sequences are note described. Revised Aree with the Annex G is updated adding to the attribute Table and adding sequences TGax Editor: Please the changes in the text in this submission 677.15 G.5 "dl-mu-sequence | | An dl-mu-sequence, and are not defined. An dl-mu-sequence, ul-mu-sequence and have to be defined in Annex G.5. Revised Agree with the The missing defined. TGax Editor: Please the changes in the text in this submission 17055 677.15 G.5 The usage case of the is not inclued in the basic sequence. Include the to the basic sequence. Revised with the The missing sequece defined. TGax Editor: Please the changes in 17056 677.15 G.5 "(Trigger) | (Trigger +a-mpdu + mu-user-respond + a-mpdu-end) 1{Data[+HTC]+QoS+(no-ack | block-ack)+a-mpdu} + a-mpdu-end; other-users];" Syntax of the above formula is not correct. Fix any syntax in Annex G. Revised Annex G is updated. TGax Editor: Please the changes in the text in this submission (11ah)non-S1GAP Frame is transmitted by a non-AP S1G STA. (11ah)S1GAP Frame is transmitted by an S1G AP. sequence
IEEE P802.11 Wireless LANs Unsolicited Block ACK Resolutions Date: 2018-11-15 Author(s): Name Affiliation Address email Chris Hansen Peraso Joe Andonieh Peraso joe@perasotech.com CID Clause Comment Proposed Change 3252 6.3.7.4.2 Use of Unsolicited Block Ack extension should not be limited to EDMG STAs. Remove the sentence "The parameter is present if dot11EDMGOptionImplemented is true and is absent otherwise." from the table. 3253 6.3.7.5.2 Use of Unsolicited Block Ack extension should not be limited to EDMG STAs. Remove the sentence "The parameter is present if dot11EDMGOptionImplemented is true and is absent otherwise." from the table. 3254 6.3.8.1.2 Use of Unsolicited Block Ack extension should not be limited to EDMG STAs. Remove the sentence "The parameter is present if dot11EDMGOptionImplemented is true and is absent otherwise." from the table. 3255 6.3.8.2.2 Use of Unsolicited Block Ack extension should not be limited to EDMG STAs. Remove the sentence "The parameter is present if dot11EDMGOptionImplemented is true and is absent otherwise." from the table. 3256 6.3.8.3.2 Use of Unsolicited Block Ack extension should not be limited to EDMG STAs. Remove the sentence "The parameter is present if dot11EDMGOptionImplemented is true and is absent otherwise." from the table.
TGax editor: change table 9-528 as follows: Table 9-528 A-MPDU Contexts Name of Context Definition of Context Table defining permitted contents Data Enabled Immediate Response The A-MPDU is transmitted outside a PSMP sequence by a TXOP holder, or an RD responder including potential immediate responses. 9-529 (A-MPDU contents in the data enabled immediate response context) Data Enabled No Immediate Response The A-MPDU is transmitted outside a PSMP sequence by a TXOP holder, TXOP responder when transmitted by an HE STA to another HE STA, and the A-MPDU that does not include or solicit an immediate response. See NOTE. Table 9-530 (A-MPDU contents in the data enabled no immediate response context) PSMP The A-MPDU is transmitted within a PSMP sequence. Table 9-531 (A-MPDU contents in the PSMP context) Control Response The A-MPDU is transmitted by a STA that is neither a TXOP holder nor an RD responder or the A-MPDU is transmitted by an HE AP in response to an HE TB PPDU and the transmitter that also needs to transmit one of the following immediate response frames: Ack BlockAck frame with a TID for which an HT-immediate block ack agreement exists BlockAck frame for acknowledging multi-TID A-MPDU Table 9-532 (A-MPDU contents MPDUs in the control response context) S-MPDU context The A-MPDU is transmitted within a VHT PPDU or an HE PPDU and contains an Table 9-533 (A-MPDU contents in the context) aa aa MPDU
TGax editor: change 9-528 as follows: Table 9-528 A-MPDU Contexts Name of Context Definition of Context Table defining permitted contents Data Enabled Immediate Response The A-MPDU is transmitted outside a PSMP sequence by a TXOP holder, or an RD responder including potential immediate responses. 9-529 (A-MPDU contents in the data enabled immediate response context) Data Enabled No Immediate Response The A-MPDU is transmitted outside a PSMP sequence by a TXOP holder, TXOP responder when transmitted by an HE STA to another HE STA, and the A-MPDU that does not include or solicit an immediate response. See NOTE. Table 9-530 (A-MPDU contents in the data enabled no immediate response context) PSMP The A-MPDU is transmitted within a PSMP sequence. Table 9-531 (A-MPDU contents in the PSMP context) Control Response The A-MPDU is transmitted by a STA that is neither a TXOP holder nor an RD responder or the A-MPDU is transmitted by an HE AP in response to an HE TB PPDU and the transmitter that also needs to transmit one of the following immediate response frames: Ack BlockAck frame with a TID for which an HT-immediate block ack agreement exists Multi-STA BlockAck frame for acknowledging multi-TID A-MPDU Table 9-532 (A-MPDU contents in the control response context) S-MPDU context The A-MPDU is transmitted within a VHT PPDU or an HE PPDU and contains an 9-533 (A-MPDU contents in the context) aa aa MPDU
CID PP LL Comment Proposed Change Resolution 15700 349 37 Clairfy ACK Enabled Aggregation Support: only to set ACK Enabled Aggregation Support to 1 when equal to true Change the text: "An HE STA set the Ack-Enabled Aggregation Support subfield to 1 in the HE MAC Capabilities Information field in the HE Capabilities element it transmits." To: "An HE STA shall set the Ack-Enabled Aggregation Support subfield to 1 in the HE MAC Capabilities Information Revised. Gererally agree with the commenter. TGax editor: please make changes in under CID 15700
Parameter Value Description … … … TSym-LDR 4 μs Duration of WUR LDR MC-OOK(#565) symbol in WUR-Data field TSym-HDR 2 μs Duration of WUR HDR MC-OOK(#565) symbol in WUR-Data TSym TSym-LDR or TSym-HDR depend-ing on WUR Data Rate Duration of MC-OOK(#565) symbol in WUR-Data field TSync 2 μs Duration of MC-OOK(#565) symbol in WUR-Sync field … … …
HEALTH RESEARCH AUTHORITY BOARD MEETING AGENDA PART 1 – PUBLIC SESSION Date: Wednesday 22 November 2017 Time: 1.00pm – 3.00pm Nottingham HRA Centre, The Old Chapel, Royal Standard Court, Nottingham, NG1 6FS Item Item details Time (mins) Attachment Page no Apologies Janet Wisely 10 Verbal - Conflicts of interest Verbal - Minutes of the last meeting 18 October 2017 A Matters arising Verbal - Update from Chair 5 Verbal - Executive update 10 To be tabled - HRA Directorate update 5 To be tabled - HRA Assessment Performance Report 15 B Service Improvement Programme update 15 C HRA Performance Report Quarter 2 2017/18 Including: Finance report 15 D E HRA Corporate Risk Register Quarter 2 2017/18 10 F Audit and Risk Committee meeting summary (2017.11.01) Including: Deep dive on social care 10 G Items for information Annual report summary for RECs in England 2016/17 10 H Appeals report 2016/17 5 I Breaches report 2016/17 5 J Out of session business conducted None to note 0 Verbal - Any other business (Any AOB items should be notified to the Head of Corporate Governance no later than 24 hours prior to the Board meeting barring exceptional circumstances) 5 Verbal - Questions from the public Verbal - Date of next meeting
677 32.2.9.2 84.26 The text reads "The other coefficients are selected from BPSK, 64-QAM, or It is unclear what is the purpose of the word "other", I believe it is a typo Remove the word "other". Change the sentence to " The coefficients are selected from BPSK, QPSK, 16-QAM, or Revised- Agree in principle with the commenter. To avoid confusion, modify the corresponding sentence. TGba editor to make the changes shown in 265 32.2.9.2 84.27 1024 QAM was adopted as an optional feature in 11ax, and thus, WUR can also consider supporting it. Change the sentence as follows: "The other coefficients are selected from BPSK, QPSK, 16-QAM, 256-QAM, or 1024-QAM." Revised- Add 1024-QAM in the corresponding text. TGba editor to make the changes shown in 196 32.2.9.2 84.14 Remove " The MC-OOK symbol corresponding to each input bit for ... SymHDROff and SymLDROn denote OFF and ON symbols with 2 ╬╝s duration for WUR HDR, respectively.". since Table 32-8 and already maps the information to the codebits. Here the text only needs to discuss how to map the coded bits to waveform as in the comment Revised- Delete the corresponding sentences and the tables. But, add the definition of “SymLDROn”, “SymLDROff”, “SymHDROn”, and “SymHDROff” because those terms are used in the spec. TGba editor to make the changes shown in 213 32.2.9.2 84.00 We should be consistent with SymHDROn and SymHDROff Replace the table entries "[SymHDROn, SymHDRoff]" with "[SymHDROn, SymHDROff]" and "[SymHDROff, SymHDRon]" with "[SymHDROff, SymHDROn]" Revised- Agree in principle with the commenter. Delete Table 32-10 and 32-11 because those tables are duplicated. Table 32-8 and 32-9 already maps the information to the encoded bits. TGba editor to make the changes shown in LDR
16387 Massinissa 41.18 4.3.14a As far as I know, there is no VHT STA defined in the 6 GHz up to 7.125 GHz band. Replace "An HE STA is also a VHT STA" with "An HE STA is also a VHT STA when operating in the 5 GHz band". Accept. 15153 Albert Petrick 41.35 4.3.14a Add definitions for UL OFDMA, UL MU-MIMO, in clause 3.0 DL is covered 802.11-2016 Change as commented Reject. There is acrynym defined for OFDMA in 11ax spec and uplink defined in 802.11-2016 (on page 169). There is no need to define UL OFDMA.
Yongho Seok 42.16 4.3.14a In 802.11ax PAR, "Average throughput per station is directly proportional to both aggregate basic service set (BSS) throughput and area throughput. The 5th percentile measure of the per station throughput may be used to determine that the desired distribution of throughput among a number of stations in an area is satisfied. These metrics, along with the satisfaction of the packet delay and the packet error ratio (PER) requirements of applications, will directly correspond to user experience in identified scenarios." Please add that 802.11ax STA is also helpful to meet the QoS requirement (such as the packet dealy and the packet error ratio). As in comment. Reject. in principle witih the commenter. However, there is no direct mapping from throughput to delay/PER. Packet latency and PER depen on many factors such as congestion levels, MCS, hidden node scenarios etc. Therefore, suggest to keep the original wording. An experienced designer will be able to map these 11ax features into their QoS design requirements. 16642 Robert Stacey 42.19 4.3.14a Why more than 4 times? Surely the same features might also produce 2 times improvement. Or 3 times imrpovement. What is a VHT? Change to "These features, under certain circumsances improve the aggregate throughput in an HE BSS compared to a VHT BSS." Reject. The four times wording here is to match the PAR requriement that 11ax shll provide 4 times throughput than 11ac. There is also “under circumstatances” to not generalize the 4 times claims to all cases. Editor: please modify the following clause as follows: 4.3.14a High efficiency (HE) STA
286 36.04 9.4.2.276 Why is the definition of the count field convoluted? A count of 0 indicates that one AP information field is present? Modify the definition of the count field to reflect the number of WUR AP subfields included in the list. Rejected. The WUR AP Count field specifies the number of WUR AP subfields that are included in the WUR AP List field, minus one. Therefor count of 0 indicates one AP information is present. Similar encoding is used in various fields in the baseline (FSS, TBTT Information Count etc.). 287 36.64 9.4.2.276 "WUR AP subfield" should be "Transmitting WUR AP subfield". as in the comment. Also in lines 55 and 58. Rejected. "Transmitting WUR AP subfield" does not "WUR AP subfield" is correct since the subfield identifies one AP. 357 26.23 9.3.3.11 There is no need for WUR Discovery element in the Probe Response frame body. Remove it. Remove third row in the table Rejected. A WUR AP may include the WUR Discovery element in Probe Response frames that is transmitted in response to a Probe Request frame that contains a WUR Capability element to advertise the WUR discovery channel(s) used by neighboring WUR APs. 372 35.25 9.4.2.276 "The WUR Discovery element is used to advertise the WUR discovery channels on which WUR APs transmit WUR Discovery frames." Is there any point in advertising this on PCR to STAs that have already found and are decoding packets on this PCR? Maybe I just don't understand all cases for when WUR Discovery is used, but based on the "WUR scanning" concept in 31.10 I don't see the need for ever advertising this information on the PCR. Specify this as a neighbor information or remove it. Rejected. The WUR Discovery element carries information about the WUR Discovery channels of the transmitting AP itself as well as neighbour APs. Knowledge of the WUR Discovery channels helps WUR STAs to track APs (Associated as well as even when its PCR is turned off by periodically scanning for WUR Discovery frames on the advertised WUR Discovery channels.
of ACK index examples. headings that include CID 3310. Proposed changes to D2.0: #3: Change the figure 145 as from page 298, line 18 (CID #3310) Figure 145 —TDD SSW Feedback frame transmit time for TDD group BF CID Page Number Line Number Comment Proposed Change Resolution 3505 297 1 TDD group beamforming is assuming that the initiator knows the mac address and the responder IDs of the responders. The TDD group beamforming should enable beamforming multiple responders not known to the initiator before hand The TDD group beamforming should be modified to enable deployment of group of responders that are not known to the initiator. This can be used for initial deployment of multiple devices. Rejected- Changes required may not be trivial, and the commenter does not specify about alternatives to consider. An individual proposal should be provided. 3506 300 32 The figure shows that the Responder stops sweeping its sectors after receiving the TDD SSW frame till the next TX TDD interval and the start of the new TX sector ID SSW frames transmission. The responder should keep sweeping its sectors though and do not stop as stated in the text Extend the brackets the TDD SSW frame reception to include the TDD interval after the TDD SSW reception for Responder 1 and Responder N Revised- TGay editor to make the changes shown in under all headings that include CID 3506. Proposed changes to D2.0: #4: Change the figure146 from page 300, line 32 as below (CID #3506)
3240 10.43.9.7 289 20 Add that the PPDU that the respodner sends have the tx vector conditions as the one sent by the initiator (lines as in comment 3241 10.43.9.7 289 25 "with the Dual Polarization TRN field in the EDMG BRP Request element." What is this field set to? add that this field is set to 0 3305 10.43.9.7 Dual polarization TRN beamforming traini 289 27 The editors note points out a flaw and the technical/protocol issues need to be corrected. Correct the potential technical issues and add the subsequent text to correct or clarify. The Editors satisafaction for the correct change/additions would change my "Must Be Satisfied" to a "No". 3306 10.43.9.7 Dual polarization TRN beamforming traini 289 34 The editors note points out a flaw and the technical/protocol issues need to be corrected. Correct the potential technical issues and add the subsequent text to correct or clarify. The Editors satisafaction for the correct change/additions would change my "Must Be Satisfied" to a "No". 3363 10.43.9.7 289 27 There are Editor Notes stating some issue with the normative behavior described in 10.43.9.7. They need to be clarified before moving to the sponsor ballot. Please fix broken part of the protocol. Discussion: The editor is correct that the text is confusing and needs to be revised. Resolution: Revised Replace the text: “An EDMG STA initiates a dual polarization TRN beamforming training by sending a PPDU with the 12 following TXVECTOR parameters setting: DUAL POL_TRAINING set to 1; and EDMG_PACKET_TYPE set to either EDMG-TRN-T-PACKET or EDMG-TRN-R/T-PACKET; 15 and EDMG_TRN_LEN set to a value greater than 0; and EDMG-TRN-N set to either 1 or 3 To request dual polarization TRN beamforming training, an intiating STA shall transmit a frame to a responding STA that
3240 10.43.9.7 289 20 Add that the PPDU that the respodner sends have the tx vector conditions as the one sent by the initiator (lines as in comment 3241 10.43.9.7 289 25 "with the Dual Polarization TRN in the EDMG BRP Request element." What is this field set to? add that this field is set to 0 3305 10.43.9.7 Dual polarization TRN beamforming traini 289 27 The editors note points out a flaw and the technical/protocol issues need to be corrected. Correct the potential technical issues and add the subsequent text to correct or clarify. The Editors satisafaction for the correct change/additions would change my "Must Be Satisfied" to a "No". 3306 10.43.9.7 Dual polarization TRN beamforming traini 289 34 The editors note points out a flaw and the technical/protocol issues need to be corrected. Correct the potential technical issues and add the subsequent text to correct or clarify. The Editors satisafaction for the correct change/additions change my "Must Be Satisfied" to a "No". 3363 10.43.9.7 289 27 There are Editor Notes stating some issue with the normative behavior described in 10.43.9.7. They need to be clarified before moving to the sponsor ballot. Please fix broken part of the protocol. Discussion: The editor is correct that the text is confusing and needs to be revised. Resolution: Revised Replace the text: “An EDMG STA initiates a dual polarization TRN beamforming training by sending a PPDU with the 12 following TXVECTOR parameters setting: DUAL POL_TRAINING set to 1; and EDMG_PACKET_TYPE set to either EDMG-TRN-T-PACKET or EDMG-TRN-R/T-PACKET; 15 and EDMG_TRN_LEN set to a value greater than 0; and EDMG-TRN-N set to either 1 or 3 To request dual polarization TRN beamforming training, an intiating STA shall transmit a frame to a responding STA that
3527 9.4.2.2.53 234 2 Dual polarization TRN Measurement is missing description in the text description of Dual Polarization TRN Measurement in the text Reject Discussion: The Dual Polarization TRN Measurement filed is described in the 9.4.2.253 EDMG Channel Measurement Feedback element section page 117 lines 30-36. Resolution: Reject CID 3711 3711 29.9.2.2.5 534 28 When the transmitter changes the antenna polarization at the end of each group of N/2 TRN fields, unmanaged interference is created. Imagine two BSS operating at two different polarizations and in SISO mode. If in one of these BSSs a dual polarization field is sent the other BSS suffers interference without prior notice One way to mitigate interference would be to allow dual polarization TRN only as part of a MIMO transmission. Reject Discussion: The situation described is unlikely to appear in the real and it is not different than any possible interference during the TRN field transmission. Resolution: Reject
IEEE P802.11 Wireless LANs CIDs for LOS Determination 11-18-1894--00ay Date: 2018-11-14 Author(s): Name Affiliation Address Phone email George Calcev Huawei George.Calcev@huawei.com Assaf Kasher Qualcomm Carlos Cordeiro Intel C CID Clause Number(C) Page(C) Line(C) Comment Proposed Change Resolution 3056 10.43.9.7 289 27 Please resolve the Editor's Note regarding the "brokeness" of the normative text in the paragraphs included between lines 20 and 26 Please resolve the Editor's Note regarding the "brokeness" of the normative text in the paragraphs included between lines 20 and 26 as in the proposed text 3057 10.43.9.7 289 34 Please resolve the Editor's Note regarding the "brokeness" of the normative text in the paragraph included between lines 28 and 33 Please resolve the Editor's Note regarding the "brokeness" of the normative text in the paragraph included between lines 28 and 33 3238 10.43.9.7 289 20 "To request dual polarization TRN beamforming training" - this text should be joined with the text in lines 12-13 to have a single definition of the initiating PPDU Move the text and combine the sentences in a sensible manneer (submission may be provided) 3239 10.43.9.7 289 12 Add that when the respodner received the packet defined in lines 12-18, it swithces polarity as described in 29.9.2.2.5 as in comment
IEEE P802.11 Wireless LANs 11ax D3.2 MAC Comment Resolution for Section 27.7.7 Date: 2018-10-26 Author(s): Name Affiliation Address Phone Zhou Lan Broadcom 250 Innovation Dr, San Jose, CA (+1) 408 543 3450 zhou.lan@broadcom.com Huizhao Wang Quantenna Communications Quantenna Communications, Inc. 1704 Automation Parkway, San Jose, CA 95131, USA hwang@quantenna.com Jarkko Kneckt Apple jkneckt@apple.com Monajemi Cisco Chunyu Hu Broadcom 250 Innovation Dr, San Jose, CA Chunyu.hu@broadcom.com Matthew Fischer Broadcom 250 Innovation Dr, San Jose, CA matthew.fischer@broadcom.com 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 D3.2 Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax D3.0 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 Commenter P.L Clause Comment Proposed Change Resolution 15696 Huizhao Wang 331.18 27.7.7 Remove 20MHz-only restriction from HE Subchannel Selective Transmission Operation Change following text: Line 18: subchannel" to subchannel" Line 26: remove "20MHz-only" Revised- Agree with the comment in principle. Due to the text change per D3.2. Propose to adjust the proposed text change to D3.2. TGax editor to make the changes shown in primary primary
IEEE P802.11 Wireless LANs Spec Text for CR for CID 915, 1100 and 1132 Date: 2018-11-11 Author(s): Name Affiliation Address Phone email Xiaofei Wang InterDigital Inc. 2 Hungting Quad, Melville, NY USA +1-607-592-2727 Hanqing Lou Rui Yang Chitrakar Panasonic Abstract This submission proposes resolutions for the following CIDs: 915, 1100 and 1132.The baseline for this comment resolution document is 802.11ba 1.0 CID Clause Page Line Comment Proposed Change Resolution 915 4.3.15a 22 2 A WUR non-AP STA that supports reception of WUR PPDU with High Data Rate may fail to receive the WUR frame in bad channel conditions. In such situations, it would be better for the WUR AP to switch to Low Data Rate; however currently there is no mechanism for WUR STAs to provide feedback to the WUR AP. In the event of CRC or MIC errors during reception of WUR PPDUs carrying WUR frames with High Data Rate addressed to a WUR non-AP STA, add options for the STA to provide feedback to the AP in one of the following two ways: 1) As an Event Report e.g. "FCS Error Event" 2) As a request to switch to Low Data Rate Based on the feedback from the STA, AP can decide to use the more robust LDR for subsequent WUR frames addressed to the STA. Revised— Instruction to the editor: please make changes included in 11-18/1925r0. 1100 9.4.2.273 31 38 A non-AP STA should be able to opt to receive a WUR frame at low data rate. add a row on "preferred data rate" in Table 9-318e and the associated procedures so that a STA can have some AP Revised— Instruction to the editor: please make
High and low data rates are defined in the draft, but a STA has no remedy if the AP decides to transmit to in high data rate. remedy if an decides to transmit to it using high data rate. Otherwise, there is no point to define a high data rate if high data rate is not being used at all. changes included in 11-18/1925r0. 1132 31.6.1 55 1 A WUR non-AP should have a remedy in case the WUR AP chooses to transmit to it using HDR and if HDR doesn't work well as a part of the WUR negotiation process. Provide a remedy in the WUR negotiation process for WUR non-AP STA to switch to a LDR if HDR work well for the current channel condition. Revised— Instruction to the editor: please make changes included in 11-18/1925r0. Discussion: None WUR Mode element TGax Editor: Change Table 9-318e as follows: of the WUR Parameters field from WUR non-AP STA Subfield Definition Encoding On Duration Indicates the preferred On Duration that the WURx of the WUR non-AP STA will be in WURx state for each the WUR duty cycle schedule (see 31.5 (WUR duty cycle operation)). The size of the field is 4 bytes. The unit of the field is 256 µs.The size of the field is 4 octets. The unit of the field is 4 µs.
IEEE P802.11 Wireless LANs REVmd Assorted Comment Resolutions Date: 2018-09-09 Author(s): Name Affiliation Address Phone email Menzo Wentink Qualcomm Utrecht, the Netherlands +31-65-183-6231 mwentink@qualcomm.com Abstract This document contains proposed resolutions for several REVmd comments (16): 1267, 1263, 1143, 1142, 1128, 1126, 1124, 1123, 1122, 1110 1090, 1088, 1432, 1438, 1439, 1583 CID Clause Page Line Comment Proposed Change Proposed Change 1267 Joseph Levy 11.23.6.5 2143 20 Calling a S1G 2, 4, 8, or 16 MHz off-channel TDLS direct link a "wide bandwidth off-channel direct link" seems a bit confusing. I understand the need to allow for an off-channel direct link for S1G STAs, but shouldn't it be called something else. Also the way the feature is implemented in the section 11.23.6.5 seems very awkward. It would be better to add a new set of clauses for the "S1G off-channel direct link", which duplicate 11.23.6.5 with the S1G changes. This would also eliminate the need to keep switching between VHT and S1G requirements. Remove the (11ah) additions to 11.23.6.5 which added S1G to the wide bandwidth off-channel direct link and add a new section "11.23.6.6 Setting up a S1G direct link" with the S1G requirements. Rejected - the wideband aspect is relative to the bandwidth of the base channel, and a wideband direct link is always wider than the base channel. The S1G modifications appear to have been added in a fairly natural way, so there would be no need to restructure the clause. channel
IEEE P802.11 Wireless LANs REVmd Assorted Comment Resolutions Date: 2018-09-09 Author(s): Name Affiliation Address Phone email Wentink Qualcomm Utrecht, the Netherlands +31-65-183-6231 mwentink@qualcomm.com Abstract This document contains proposed resolutions for several REVmd comments (16): 1267, 1263, 1143, 1142, 1128, 1126, 1124, 1123, 1122, 1110 1090, 1088, 1432, 1438, 1439, 1583 CID Clause Page Line Comment Proposed Change Proposed Change 1267 Joseph Levy 11.23.6.5 2143 20 Calling a S1G 2, 4, 8, or 16 MHz off-channel TDLS direct link a "wide bandwidth off-channel direct link" seems a bit confusing. I understand the need to allow for an off-channel direct link for S1G STAs, but shouldn't it be called something else. Also the way the feature is implemented in the section 11.23.6.5 seems very awkward. It would be better to add a new set of clauses for the "S1G off-channel direct link", which duplicate 11.23.6.5 with the S1G changes. This would also eliminate the need to keep switching between VHT and S1G requirements. Remove the (11ah) additions to 11.23.6.5 which added S1G to the wide bandwidth off-channel direct link and add a new section "11.23.6.6 Setting up a S1G direct link" with the S1G requirements. Rejected - the wideband aspect is relative to the bandwidth of the base channel, and a wideband direct link is always wider than the base channel. The S1G modifications appear to have been added in a fairly natural way, so there would be no need to restructure the clause. channel
IEEE P802.11 Wireless LANs REVmd Assorted Comment Resolutions Date: 2018-09-09 Author(s): Name Affiliation Address email Menzo Wentink Qualcomm Utrecht, the Netherlands +31-65-183-6231 mwentink@qualcomm.com Abstract This document contains proposed resolutions for several REVmd comments (18): 1267, 1263, 1143, 1142, 1128, 1126, 1124, 1123, 1122, 1110 1090, 1088, 1432, 1438, 1439, 1583, 1117, 1108 CID Clause Page Line Comment Proposed Change Proposed Change 1267 Joseph Levy 11.23.6.5 2143 20 Calling a S1G 2, 4, 8, or 16 MHz off-channel TDLS direct link a "wide bandwidth off-channel direct link" seems a bit confusing. I understand the need to allow for an off-channel direct link for S1G STAs, but shouldn't it be called something else. Also the way the feature is implemented in the section 11.23.6.5 seems very awkward. It would be better to add a new set of clauses for the "S1G off-channel direct link", which duplicate 11.23.6.5 with the S1G changes. This would also eliminate the need to keep switching between VHT and S1G requirements. Remove the (11ah) additions to 11.23.6.5 which added S1G to the wide bandwidth off-channel direct link and add a new section "11.23.6.6 Setting up a S1G direct link" with the S1G requirements. Rejected - the wideband aspect is relative to the bandwidth of the base channel, and a wideband direct link is always wider than the base channel. The S1G modifications appear to have been added in a fairly natural way, so there would be no need to restructure the clause. channel
IEEE P802.11 Wireless LANs Proposed Resolutions to Miscs PHY and MAC CIDs Date: 2018-11-09 Loc Huawei +1408 807 -0868 peterloc@iwirelesstech.com CID Sub Clause PP.LL Comment Proposed Change Resolution 16557 27.16.2.2.2 374.29 There is potentially a technical issue with the rule for reporting the status of BSS color collision. Based on this paragraph, starting from line 28, once the AP sets the Color Disabled bit to 1 in HE Operation Element that it transmits, the non-AP HE Remove the "Bss color collision no longer exists". The paragraph should read: "A non-AP HE STA that intends to autonomously report a BSS color collision to its associated HE AP, shall do so by scheduling for transmission a BSS Rejected. Although in certain race conditions, to allow the AP to continue to change its BSS color even when the reporting STA no longer detects the BSS Color collision, would
IEEE P802.11 Wireless LANs 11ba D1.1 MAC Comment Resolution for WUR Duty Cycle Part I Date: 2018-11-11 Author(s): Name Affiliation Address Phone email Po-Kai Huang Intel Corporation 2200 Mission College Blvd, Santa Clara, CA 950542200 po-kai.huang@intel.com 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 TGba D1.1 Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGba D1.1 Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGba Editor: Editing instructions preceded by “TGba Editor” are instructions to the TGba editor to modify existing material in the TGba As a result of adopting the changes, the TGba editor will execute the instructions rather than copy them to the TGba Draft. CID P.L Clause Comment Proposed Change Resolution 308 Hanseul Hong 30.07 9.4.2.273 The duty cycle period is only included in the WUR mode element sent by STA. For duty cycle scheduling and transmission of broadcast WUR Wake-up frame, AP should be able to indicate the preferred duty cycle period Include the Duty Period in the WUR Parameters field from WUR AP Rejected – Current spec already provides a mechnaims for AP to regulate the duty cycle and enable transmission of broadcast WUR Wake-up frame. Specifically, AP can deicde the duty cycle period unit and the starting time of the duty cycle. If AP decides the Duty cycle period, it may not match the delay requirement of the non-STA. 792 Osama 52.17 31.5 What is the impact of the WUR duty cycle on the delay experienced by frames destined to a WUR non-AP STA in the off-duration? Some discussion is needed. as in comment Rejected – The commenter does not provide any suggested the resolution for the comment.