zilongwang/ReadingBank huggingface dataset:
similar to the existing mechanism of using BAR to move the BA window. It can be selective in that the receipient only flushes incomplete MSDUs up to and including the indicated end sequence number. It can be also requesting flush all. No receiver window move occurs. No BlockAck is transmitted in response. MSDUs and fragments of MSDUs that are not covered by the SEQ number range or which are completely assembled in the buffer are unaltered. Adding this function to the BlockAckReq seems to be a good option. original rule, i.e., by setting the SSN in the BlockAckReq. To flush all the MSDUs at the receipient, the originator can do so by the original rule, i.e., by setting the SSN in the BlockAckReq higher than the largest sequence number of the MSDUs that it transmitted. If the receiver window is not changed after the flush as the commenter suggested, it means that the originator can send fragments again and if as a result, the MSDU is completed and passed to the next MAC process, the MSDU reordering will get messed up. 14323 Zhou Lan 75.54 A RX buffer flushing mechanism is needed. It is selective in that the receipient only flushes incomplete MSDUs up to and including the indicated end sequence number. No receiver window move occurs. No BlockAck is transmitted in response. MSDUs and fragments of MSDUs that are not covered by the SEQ number range or which are completely assembled in the buffer are unaltered. Adding this function to the BlockAckReq. as in the comment Rejected. To make the receipient flush the imcomplete MSDUs up to the intended sequence number, the originator can do so by the original rule, i.e., by setting the SSN in the BlockAckReq. To flush all the MSDUs at the receipient, the originator can do so by the original rule, i.e., by setting the SSN in the BlockAckReq higher than the largest sequence number of the MSDUs that it transmitted. If the receiver window is not changed after the
IEEE P802.11 Wireless LANs Resolutions to comments submitted to subclause 9.3.1.9.1 Date: 2018-04-27 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 draft. 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 GEORGE CHERIAN 76.42 Need a corresponding normative text for the following in clause 27: "An HE STA does not send a Multi-STA BlockAck frame under Delayed and agreements" As in the comment Rejected. It is already covered in clause 27. In 27.4.1 Overview, it says “The HE acknowledgment procedure(#13251) builds on the features delayed
Proposed Resolution: Revised These comments are appropriate. Therefore, the following text is proposed. TGay Editor: Please modify subclause “10.60 EDMG phase hopping operation (P234, L17) , [1]” as follows EDMG phase hopping and open loop precoding operation An EDMG STA supports phase hopping if the Phase Hopping Supported field in the STA’s EDMG Capabilities element is one. A phase hopping capable STA may set the TXVECTOR parameter PHASE_HOPPING to PhaseHoppingApplied only if the Phase Hopping Supported field in the STA’s EDMG Capabilities element is one and a peer STA is also phase hopping capable. An EDMG STA supports open loop precoding if the Open Loop Precoding Supported subfield in the STA’s EDMG Capabilities element is one. An open loop precoding capable STA is also phase hopping capable. An open loop precoding capable STA may set the TXVECTOR parameter OPEN_LOOP_PC to OpenLoopPrecodingApplied only if the Open Loop Precoding Supported subfield in the STA’s EDMG Capabilities element is one and a peer STA is also open loop precoding capable. TGay Editor: Please modify “Table 32 TXVECTOR and RXVECTOR parameters (P264, L1), [1]” as follows PHASE_HOPPING FORMAT is EDMG Indicates whether phase hopping modulation is applied when NSTS = NSS =2. Enumerated type: PhaseHoppingNotApplied: indicates that phase hopping modulation is not applied PhaseHoppingApplied: indicates that phase hopping modulation is applied Y Y FORMAT is EDMG Used to differentiate between Static and Dynamic Tone Pairing. Enumerated Type: STATIC: indicates Static Tone Pairing DYNAMIC: indicates Dynamic Tone Pairing Y Y OPEN_LOOP_PC FORMAT is EDMG Indicates whether open loop precoding is applied when NSTS = NSS =2. Enumerated type: OpenLoopPrecodingNotApplied: indicates that open loop precoding is not applied OpenLoopPrecodingApplied: indicates that open loop precoding is applied Y Y
Name Type Valid Range Description ResultCode Enumeration Success, Fail Indicates the result of the TDD Slot Schedule request received. VendorSpecificInfo A set of elements As defined in 9.4.2.26 (Vendor Specific element) Zero or more elements. 6.3.119.8.3 When generated This primitive is generated by the MLME to report the result of TDD Slot schedule establishment in the MAC. 6.3.119.8.4 Effect of receipt The SME is notified of the result of the procedure. 6.3.119.9.1 MLME-TDD-SLOT-SCHEDULE.indication 6.3.119.9.1 Function This primitive indicates that a specific peer MAC entity is requesting TDD slot schedule with the local MAC entity. 6.3.119.9.2 Semantics of the service primitive The primitive parameters are as follows: MLME-TDD-SLOT-SCHEDULE.indication( PeerSTAAddress, TDDSlotScheduleList, VendorSpecificInfo) Name Type Valid Range Description PeerSTAAddress MAC Address Any valid individual MAC address Specifies MAC address of the peer STA from which the TDD Slot Schedule element is received. TDDSlotScheduleList TDD Slot Schedule element As defined in 9.4.2.268 (TDD Slot Schedule element) Specifies the parameters within one or more TDD Slot Schedule elements received from peer STA. VendorSpecificInfo A set of elements As defined in 9.4.2.26 (Vendor Specific element) Zero or more elements. 6.3.119.9.3 When generated
802.11ba Draft Specification Bit location of TSF timer for the Partial TSF field in WUR Beacon Date: 2018-05-07 Author(s): Name Affiliation Address Phone email Po-Kai Huang Intel 2200 Mission College Blvd, Santa Clara, CA 95054 +1-765-418-6733 po-kai.huang@intel.com Editing instructions formatted like this are intended to be copied into the TGba 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 or insert material in the TGba draft. As a result of adopting the changes, the TGba editor will execute the instructions rather than copy them to the TGba Draft. Discussion: We have agreed to have ± 100 ppm accuracy for TSF timer for WUR STA. Further, we have agreed to have 12 bits of Partial TSF timer in the TD control field of WUR Beacon. Several options for the bit location of the TSF timer in the TD control field are listed below. Bit location [7:18] [6:17] [5:16] [4:15] [3:14] Maximum uncorrectable drift when Beacon is received ±128 us ±64 us ±32 us ±16 us ±8 us Percentage of uncorrectable drift under 2ms ON Duration 6.25% 3.125% 1.5625% 0.78% 0.39% Maximum correctable drift ± 2^18 us ± 2^17 us ± 2^16 us ± 2^15 us ± 2^14 us
IEEE P802.11 Wireless LANs Resolution to CIDs related to MU BA and RD Date: 2018-07-09 Author(s): Name Affiliation Address Phone email Ilya Bolotin ilya.bolotin@intel.com Oren CID Page Clause Comment Proposed Change 1762 106.17 10.3.2.10 In Figure 84, "QoS Data frame" should be "A-MPDU subframe". In Figure 84, replace "QoS Data frame" with "A-MPDU subframe". Proposed resolution: Revised Discussion: The paragraph the figure says: “An example of an A-MPDU transmitted in an EDMG MU PPDU is shown in Figure 84”. So Figure 84 introduces only an example but not the general case. In this example A-MPDU subframes are QoS Data frames. Clarification for Ack Policy value of QoS Data frames was added (see proposed text below). CID Page Clause Comment Proposed Change 1960 37.05 9.3.1.23 EOF field is already presented in the delimiter and provides any relevant functionality, No need to duplicate the field. (9.7.1 format) Remove EOF in the Figure 11 and remove text in lines 5, 6 on P37 Remove sentence that starts with "The MU-MIMO initiator shall set the EOF..." at P105L38 MPDU
2175 31.21 9.2.4.5.4 The term "Scheduled Ack" is not used anywhere in normative behaviors. Either the different terms should be unified or this term should be deleted if no normative behavior is associated with it. Unified the term used for "Scheduled Ack" with the term used for normative behavior or delete this term if there is no associated normative behavior. 1962 105.36 10.3.2.10 The existent definition does not pay attention if an immediate BlockAck policy is indicated or not, that makes substantial difference to the normative behavior. An MU-MIMO initiator shall include a Block Ack Schedule frame in each A-MPDU transmitted within an EDMG MU PPDU if Ack policy of MPDUs contained in the A-MPDU is equal to normal ACK or BlocAckReq is aggregated in the A-MPDU and shall not be included otherwise. 1860 31.21 9.2.4.5.4 The term "Scheduled Ack" is used in updates to Table 9-9. It's not clearly defined. In some instances it's reference to as PSMP ACK/Scheduled Ack and others as Block Ack Schedule. Define Scheduled Ack and update Table 9-9 Proposed resolution: Revised. Discussion: The normative behaviour associated with “Scheduled Ack” was added to clause 10.3.2.12 (MU acknowledgment procedure) and 10.29 (Reverse direction protocol). See proposed text below. CID Page Clause Comment Proposed Change 1411 10.3.2.10 If the reverse directon protocol for is used (see 10.28.5), how does the AP estimate the BATT Start offset which determines the required time for the STA to transmit BA back. For example, if STA1 uses reverse direction and transmits additional data together with the BA, STA2 and STA3 may have to wait longer to transmit their BAs back to AP. Otherwise the BA would collide with the data transmitted by STA1. and analyze the impact of reverse direction protocol on MU acknowledgement process and see if changes are needed.
IEEE P802.11 Wireless LANs Resolution to CIDs related to MU BA and RD Date: 2018-07-09 Author(s): Name Affiliation Address Phone email Ilya Bolotin Intel ilya.bolotin@intel.com Oren Kedem oren.kedem@intel.com CID Page Clause Comment Proposed Change 1762 106.17 10.3.2.10 In Figure 84, "QoS Data frame" should be "A-MPDU subframe". In Figure 84, replace "QoS Data frame" with "A-MPDU subframe". Proposed resolution: Revised Discussion: The paragraph above the figure says: “An example of an A-MPDU transmitted in an EDMG MU PPDU is shown in Figure 84”. So Figure 84 introduces only an example but not the general case. In this example A-MPDU subframes are QoS Data frames. Clarification for Ack Policy value of QoS Data frames was added (see proposed text below). CID Page Clause Comment Proposed Change 1960 37.05 9.3.1.23 EOF field is already presented in the delimiter and provides any relevant functionality, No need to duplicate the field. (9.7.1 format) Remove EOF in the Figure 11 and remove text in lines 5, 6 on P37 Remove sentence that starts with "The MU-MIMO initiator shall set the EOF..." at P105L38 MPDU
Discussion: As per Table 9-262aa, there is a HE SU PPDU And HE MU PPDU With 4x HE-LTF And 0.8 µs GI subfield: HE SU PPDU And HE MU PPDU With 4x HE-LTF And 0.8 s GI Indicates support for the reception of an HE SU PPDU and HE MU PPDU with 4x LTF and 0.8 s guard interval duration. Set to 0 if not supported. Set to 1 if supported. This subfield is set to 1 if the HE ER SU PPDU With 4x HE-LTF And 0.8 µs GI subfield is 1. However, the names of the attributes related to this subfield in Table 28-50 and Annex C, namely dot11HESUPPDUwith4xHELTFand0point8GIlmplemented and dot11HESUPPDUwith4xHELTFand0point8GIActivated, are confusing because the info about MU is missing in the names: dot11PHYHETable dot11HEDualBandImplemented false/Boolean Static … … … dot11HESUPPDUwith4xHELTFand0point8GIlmplemented false/Boolean Static dot11HESUPPDUwith4xHELTFand0point8GIActivated false/Boolean Dynamic Proposed resolution: Revised To TGax editor: Please replace dot11HESUPPDUwith4xHELTFand0point8GIlmplemented and dot11HESUPPDUwith4xHELTFand0point8GIActivated from 571.31 to 571.35 in Table 28-50 of P802.11ax D2.3 with the proposed changes below. dot11PHYHETable dot11HEDualBandImplemented false/Boolean Static … … …
CID Clause Page Line Comment Proposed Change Resolution 13383 28.4 515 8 Midamble RX MAX NSTS missing Add to table as in comment. Revised. Agree in principle but the changes are needed in not only clause 28 but also in Annex C. TGax Editor: Please change the text as indicated in doc.: IEEE Discussion: As per Table 9-262aa, there is a Midamble RX MAX NSTS subfield: Midamble Rx Max NSTS If(#11060) the Doppler Rx subfield is 1, indicates the maximum number of space-time streams supported for reception when a midamble is present(#11062) in the Data field. Set to 0 for 1 space-time stream Set to 1 for 2 space-time streams Set to 2 for 3 space-time streams Set to 3 for 4 streams(#13335) However, the attributes of this subfield are missing in Table 28-50. Proposed resolution: Revised To TGax editor: Please add the following 2 attributes before the entry dot11HENDPwith4xHELTFand3point2GIImplemented at 572.34 in Table 28-50 of P802.11ax D2.3. dot11PHYHETable dot11HEDualBandImplemented false/Boolean Static … … … dot11HENDPwith4xHELTFand3point2GIImplemented false/Boolean Static
IEEE P802.11 Wireless LANs Resolution of Flow Control related CIDs Date: 2018-02-13 Author(s): Name Affiliation Address Phone email Oren Kedem Idan Maor idan.maor@intel.com Solomon, Trainin Qualcomm strainin@qti.qualcomm.com CID Clause Comment Proposed change Resolution 1070 9.3.1.9.1 "No_Mem_Kept" Why not simply name it "No Memory Kept"? As in comment. Change throughout the draft. Accepted Name was changed to No Memory Kept 1187 9.3.1.9.1 "No_Mem_Kept" - this is a stylistic departure from the 802.11 baseline. Also, don't unless absltly nccsry. Change subfield globally to "No Memory Kept" 1709 9.3.1.9.1 Undescores in subfield name inconsistent with established style Remove underscores CID Clause Comment Proposed change Resolution
BlockAckPolicy, BufferSize, BlockAckTimeout, GCRGroupAddress, Multi-band, TCLAS, ADDBA Extension, VendorSpecificInfo ) Name Type Valid range Description PeerSTAAddress MACAddress N/A Specifies the address of the peer MAC entity with which to perform the block ack initiation (or modification). ….. …. ….. ……. VendorSpecificInfo A set of elements As defined in 9.4.2.26 Zero or more elements. CID Clause Comment Proposed change Resolution 2130 10.24.2 "The Advanced Recipient Memory Length Capable subfield in the STA's EDMG Flow Control Extension Configuration element is equal to one and the value of the Advanced Recipient Memory Length Exponent field in the STA's EDMG Flow Control Extension Configuration element is greater than or equal to the value of the Maximum A-MPDU Length Exponent field in the STA's EDMG Capabilities element." The Advanced Recipient Memory Length Capable subfield is within the optional subelement EDMG Flow COntrol Capabilities for the EDMG Flow Control Extension Configuration element. change to "The Advanced Recipient Memory Length Capable subfield in the EDMG Flow Control Capabilities subelement of the STA's EDMG Flow Control Extension Configuration element is equal to one..." As suggested Revised: 2131 10.24.2 "The Advanced Recipient Memory Length Capable subfield and the As suggested Revised
to Discussion: As per subclause 27.10.4.1, An HE STA with dot11AMPDUwithMultipleTIDOptionImplemented to true shall set the Aggregation Rx Support subfield in the HE MAC Capabilities Information field in the HE Capabilities element it transmits to a nonzero value. An HE STA with dot11AMPDUwithMultipleTIDOptionImplemented equal to false shall set the Multi-TID Aggregation Rx Support subfield to 0. Multi-TID Aggregation Rx Support subfield is defined in Table 9-262z as follows: Multi-TID Aggregation Rx Support(#12379) Indicates the number of TIDs (#12700)of QoS Data frames that an HE STA can receive in a A-MPDU as described in 27.10.4 (Multi-TID A-MPDU and ack-enabled A-MPDU). Set to the number of TIDs minus 1 of QoS Data frames that an HE STA can receive in a multi-TID The commenter is correct that dot11AMPDUwithMultipleTIDOptionImplemented shouldbe about rx, not tx.
IEEE P802.11 Wireless LANs 11ax D2.0 BSS Operation BW Date: 2018-04-30 Author(s): Name Affiliation Address Phone email Liwen Chu Marvell Menzo Wentink Qualcomm Abstract This submission proposes fix the bugs about BSS operation channel BW. The text is based on 11md D1.0. Revisions: . Interpretation of a Motion to Adopt A motion to approve this submission means that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGax Editor: Editing instructions preceded by “TGax Editor” are instructions to the TGax editor to modify existing material in the TGax draft. As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft.
802.11ba Specification Spec Text for Group ID Negotiation Date: 2018-05-07 Author(s): Name Affiliation Address Phone email Lei HUANG Panasonic lei.huang@sg.panasonic.com Alfred Asterjadhi Qualcomm Editing instructions formatted like this are intended to be copied into the TGba 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 or insert 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. TGba Editor: Instruction: 9.4.2.262 WUR Mode element change Figure 9-589a as the following: Element ID Length Element ID Extension Action Type WUR Mode Response Status WUR Parameters Octets: 1 1 1 1 TBD TBD WUR Mode element format add the following after Table 9-262b:
IEEE P802.11 Wireless LANs Abstract This submission proposes resolutions for the following comments from the letter ballot on P802.11ax D2.0: 13869, 12999, 11311, 13914, 13912, 13913, 11098, 13829, 13915, 13917, 13951 NOTE – Set the Track Changes Viewing Option in the MS Word to “All Markup” to clearly see the proposed text edits. Revision History: R0: Initial version. R1: Updated during teleconference on 5/3/2018 CID Clause Page Comment Proposed Change 13869 9.4.2.27 120.40 "If operating in an operating class for which the behavior limits set listed in Annex E does not include the DFS_50_100_Behavior then a STA sets the OBSS Narrow Bandwidth RU in UL OFDMA Tolerance Support field to 0." Even though an AP is not operating in a DFS band, if the AP has a dot11OBSSNarrowBWRUinULOFDMATolerated equal to true, it is better that the AP sets the OBSS Narrow Bandwidth RU in UL OFDMA Tolerance Support field to 1. Because a DFS band is regionally different. Considering an AP's movement to different DFS regions, the default value should be set based on only the support of the feature if there is no negative impact. Remove the followings: "If operating in an operating class for which the behavior limits set listed in Annex E includes the DFS_50_100_Behavior then the following apply:" "If operating in an operating class for which the behavior limits set listed in Annex E does not include the DFS_50_100_Behavior then a STA sets the OBSS Narrow Bandwidth RU in UL OFDMA Tolerance Support field to 0." 9.4.2.27 120.39 When operating in a channel without DFS, why should the bit "OBSS Narrow Bandwidth RU in UL OFDMA Tolerance Support" be set to 0 and not to 1? Narrow bandwidth RU from an OBSS STA would not cause a false DFS alarm As in comment
SECURED_TRN FORMAT is EDMG Indicates whether TRNs appended to the PPDU are secured TRN Enumerated type: SECURED_TRN NON_SECURED_TRN Y Y SECURED_TRN_WAVEFORM FORMAT is EDMG and SECURED_TRN set to SECURED_TRN Waveform for each of the TRN fields used in secured TRN. ZPWxTRN_LEN Samples Y N TGay Editor: Add the following text before 8.3.5: 8.3.4.4 Vector Descriptions Editor: Add the following line to table 8.4 Vector-Description: SECURE_TRN_WAVEFORM PHYCONFIG_VECTOR Waveform for each of the TRN fields used in receiving secured TRN. ZPWxTRN_LEN Samples
14079 424.46 28.3.10.8.3 What does "punctured 20 MHz channels removed" mean? For example, in case of BW field = 4 in HE-SIGA for HE MU PPDU, do the two HE-SIG-B content channels both have two RU Allocation tables? Similar comment on P424L53. Clarify what "punctured 20 MHz channels removed" means. Revised: Make text modifications as shown in 802.11-18/0815r0 14083 432.32 28.3.10.8.6 What does "load balancing for RUs" mean? Clarify what "load balancing" is. Revised: resolved by CID 11496. Discussion and proposed resolutions CID 14075 14075 423.01 1 28.3.10.8.3 HE-SIG-B of an 80 MHz PPDU has total 256 tones including DC and guard tones. So, saying that HE-SIG-B occupies tones [-500:-259] and duplicated on [17:258] is incorrect. Similar comment on P423L54. Either fix the tone indices used by content channels. Discussion The commenter is correct. The text seems to confuse the tones occupied by HE-SIG-B (which uses “legacy” tone width) with the tones that correspond to 242-tone RUs. The same mistake appears in several places in this section and in Figures 28-26, 28-27, 28-28 and 28-29. However, the text has been updated between 2.0 and draft 2.3 to remove references to the tones [-500:-259], [17:258], etc … The same section now reads: References to tones have also been removed from Figures 28-26, 28-27, 28-28 and 28-29. Resolution Revised: resolved by changes in D2.3. See resolution of CIDs 13368 and 11408.
2216 196.17 10.62.2 It does not make sense that an MSDU segment can be a complete MSDU, as if it can be one there is no reason to segment the MSDU. Hence an MSDU segment may not comprise all or a portion of an MSDU. Change the sentence: An MSDU segment may comprise all or a portion of an MSDU. To be: An MSDU segment comprises a portion of an MSDU. Proposal: Reject Discussion: MAC establishes SAR enabled BA agreement per TID. MAC is not responsible for MSDU sizes arrived at MAC SAP. Any size of MSDU can arrive at the established BA even of single MPDU size. CID Page Clause Comment Proposed Change 2217 197.05 10.62.3 All the discussion of reception of the MSDU fragments which refer to them as MSDUs is very confusing. There has got to be a better way to describe the removal of the fragment MSDU's header and then the concatenation of the fragments MSDU's date with the previously received fragments to form the original MSDU, without calling each fragment an MSDU. Rework the text so that it is clear that each MDPU contains a fragment MSDU and that the fragment MSDUs are reassembled to create the original MSDU and once the MSDU has been reassembled it is passed to the MAC. The current description is lacking.
IEEE P802.11 Wireless LANs Comment Resolution on Channel Measurement for TDD Slot Date: 2018-05-07 Author(s): Name Affiliation Address Phone email SungJin Park LG Electronics Yangjae-daero 11gil, Seocho-gu, Seoul, 137-893, Korea allean.park@lge.com JinMin Kim LG Electronics jinmin1230.kim@lge.com Saehee Bang LG Electronics saehee.bang@lge.com SunWoong Yun LG Electronics sunwoong.yun@lge.com Jinsoo Choi LG Electronics js.choi@lge.com Sanggook Kim LG Electronics San Diego /California/US sanggook.kim@lge.com
IEEE P802.11 Wireless LANs Comment Resolution for EDMG Channel Access CIDs Date: 2018-05-07 Author(s): Name Affiliation Address email SungJin Park LG Electronics Yangjae-daero 11gil, Seocho-gu, Seoul, 137-893, Korea allean.park@lge.com JinMin Kim LG Electronics jinmin1230.kim@lge.com Saehee Bang LG Electronics saehee.bang@lge.com SunWoong Yun LG Electronics sunwoong.yun@lge.com Jinsoo Choi LG Electronics js.choi@lge.com Sanggook Kim LG Electronics San Diego /California/US sanggook.kim@lge.com
CID Page Clause Comment Proposed Change 1010 113.27 10.22.2.12 Idle channel In Table 20 is incorrect. Change "Primary" to "None", "First secondary channel" to "Primary channel", "Second secondary channel" to "Primary channel and first secondary channel", and "Third secondary channel" to "Primary channel, first secondary channel and second secondary channel". 1012 114.20 10.22.2.12 If the action d) is allowed even if secondary or secondary1 channel is busy, for example, primary and secondary2 are idle whereas secondary and secondary1 is busy, the channel-list parameter should be extended to define busy/idle patterns of all subchannels. Define additional channel-list parameters. For example, define "secondary_secondary1" which indicates that the secondary and the secondary1 are busy, and the primary and the secondary2 are idle. Similarly, "secondary_secondary2", "secondary1_secondary2" and "secondary_secondary1_secondary2" might have to be defined. In that case, the parameter "secondary" should indicate that only the secondary 2.16GHz channel is busy, i.e. the primary, secondary1 and secondary2 are idle. Alternatively, bitmap-type channel-list parameter may be used, like per20MHzbitmap in 802.11ax-D2.0. Proposed resolution: revised Discussion: There is the mismatch definition of Table 20 (Channels indicated idle by the channel-list parameter) and Table 8-5 (The channel-list parameter elements) in the current draft. Table 8-5 — The channel-list parameter elements channel-list parameter Meaning
set to the transmitted BSSID, respond with RA set either to the (nontransmitted) BSSID of the BSS it is associated with or the transmitted BSSID (i.e., the TA of the soliciting Trigger frame). A non-AP HE STA that is associated with a BSS corresponding to a nontransmitted BSSID and has indicated support for receiving Control frames with TA set to the transmitted BSSID (via the Rx Control Frame To MultiBSS subfield set to 1 in HE Capabilities element that it transmits) shall, upon receiving an Basic Trigger frame with TA set to the transmitted BSSID, respond with RA set to the (nontransmitted) BSSID of the BSS it is associated with." Following changes are related to CIDs 11000 and 13806 High efficiency (HE) STA TGax Editor: Please make the following changes to the 6th paragraph of this section (11ax D2.0 P37L65): The main MAC features in an HE STA that are not present in VHT STA or non-AP HT STA are the following: Optional support for dynamic fragmentation levels 1, 2 and 3 Mandatory support for an AP to receive and optional an AP to transmit operating mode indication Optional support for a non-AP STA to transmit and receive for operating mode indication Mandatory support for a non-AP STA and optional support for an AP for two NAV operation Optional support in a non-AP STA and mandatory support in an AP for target wake time (TWT) operation Optional support for UL OFDMA-based random access (UORA) Optional support for spatial reuse operation Optional support for multi-TID A-MPDU operation Optional support for ER BSS Mandatory a non-AP STA Following changes are related to CID 11016
See the instructions to the TGax editor in doc. 11-18/0890. Chunyu Hu 79.43 In "An HE AP that transmits a Multi-STA BlockAck frame with different values of the AID11 subfield in Per AID TID Info subfields sets the RA field to the broadcast address.", change "sets the RA" to "should set RA". as in the comment Rejected. As normative requirements are not allowed in clause 9, “should” cannot be used here. 13525 Stephen McCann 79.43 In the cited sentence "AID11" is not defined. Either define "AID11" in the definitions clause or insert a forward reference to Figure 9-38d where it is defined. Rejected. It is said in the cited sentence that the AID11 subfield is in the Per AID TID Info subfield and it is clear that the Per AID TID info subfield carries the AID TID Info subfield and the AID TID Info subfield carries the AID11 subfield, if read patiently. 14340 Zhou Lan 79.43 "An HE AP that transmits a Multi-STA BlockAck frame with different values of the AID11 subfield in Per AID TID Info subfields sets the RA field to the broadcast address. An HE AP that transmits a Multi-STA BlockAck frame with a single Per AID TID Info subfield or with the same values of the AID11 subfield in Per AID TID Info subfields sets the RA field to the address of the recipient that solicited the BlockAck frame." what does it mean by saying "different values of the AID11 subfield"? If it is mean to be multiple AID11 subfield then please state in that way. Also change "sets the RA" to "Shall set". as in the comment Rejected. Please see NOTE 1 after the 8th paragraph in this subclause. Different values of the AID11 subfield means not just multiple AID11 subfields. There can be a case when the AID TID Info subfield is repeated multiple times with the AID11 subfields all the same but the TID subfields being different. In such case, the RA will be an unicast address. Also, “shall” cannot be used here as normative requirements are not allowed in clause 9.
Proposed resolution: Revised 4060.45: change “…11-12/0751r0, located at ” to “…11-12/0751r1, located at ” 295.11: under the column “valid range”, change “DMG BSS: 0-24,…” to “DMG BSS: 0-12,..” 1230.48: change “Values 0-31 indicate MCS 0 to MCS 31” to “Values 0-12 and values 25-31 indicate MCS 0 to MCS 12 and MCS 25 to MCS 31, respectively” 2880.60: in Figure 20-16 (PHY transmit procedure), change “…SC blocks or OFDM symbols” to “or SC blocks” 2883.35: in Figure 20-18 (PHY receive procedure), change “…SC blocks or OFDM symbols” to “or SC blocks” CID Clause Page Line Comment Proposed Change 1589 I.4 2944 4 In table 21-12, why list the bits explicitly, and also number "Number of bits" column? Delete the "Number of bits" column. Same thing in Tables 23-11, 23-13, 23-14, 23-18, 20-11, and 20-13. In 23-16, delete the parentheticals, throughout. Discussion Proposed resolution: Revised Delete the "Number of bits" column in Table 21-12, 23-11, 23-13, 23-14, and 23-18.
1104 Oren Kedem 10.24.2 "An unsolicited ack extension agreement may be torn down following rules defined in 10.24.5." 10.24.5 discuss on sending DELBA for torn up the Block Ack agreement, does it apply to unsolicited Block Ack as well ? Please provide better description how it is done. In order to torn up the unsolicited Block Ack agreement, the recipient shall send Information request without the Unsolicited extension and receives Information Rsp without the unsolicited block Ack IE. Resolution: Revise Discussion: It is not necessary to send an Information request element. A DELBA frame is sufficient. Instruct the Editor to modify the text from 802.11ay D1.2 (bottom of p.150) as shown: An unsolicited block ack extension agreement may be torn down 45Teardown of the block ack mechanism. 1105 Oren Kedem 10.24.2 An unsolicited block ack extension agreement is established per <TA, RA, TID> tuple. The unsolicited block ack extension agreement is considered set up if the following conditions apply: The recipient transmits and the originator receives a BlockAck frame in response to an MPDU with Ack Policy field set to Implicit Block Ack Request sent by the originator; and Consider to add also the following rule to the set: the recipient includes the Unsolicited Block Ack Extension element in one of its re/Association of Information messages. Resolution: Reject Discussion: This additional rule is unnecessary. Originators will only transmit an MPDU using the unsolicited Block ACK protocol if it knows the recipient supports that protocol.
IEEE P802.11 Wireless LANs TGmd 2018-05 & 06 teleconference agendas Date: 2018-05-17 Author(s): Name Affiliation Address Dorothy Stanley Hewlett Packard Enterprise 3333 Scott Blvd, Santa Clara CA 95054 +1 630-363-1389 2018 May and June Teleconference Agendas TGmd will hold 2 (2-hour) teleconferences before the July 2018 session: May 25th, June 1, 15 and 22 2018 at 10am Eastern for comment resolution and presentations. We’ll use the bridge: , see for more detailed instructions. The draft agendas for the May 25th, June 1, 15 and 22 teleconferences is below: 1. Call to order, attendance, and patent policy a. Call for potentially essential patents: If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: i. Either speak up now or ii. Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or iii. Cause an LOA to be submitted b. 2. Editor report – Emily QI a. Editor report: current status; any updates to b. Comments received LB 232 are here: . 3. Comment resolution 2018-05-25 Youhan KIM – CID 1374 (10 mins) Sigurd S 11-18-701 CIDs 1359 (10 mins) Roger MARKS – CID 1533 (10 mins) HIERTZ – 11-18-810, CID 1195 (45 mins) Mike MONTEMURRO - PHY CIDs 1552, 1324, 1264, 1188, 1004, 1552 (40 mins) 2018-06-01 Yujin NOH – 11-18-709 (45 mins) Ganesh VENKATESAN – 11-18-885 (15 mins) Carlos CORDEIRO – DMG CIDs 18/889 (45 mins)
2018-06-15 Matthew FISCHER – 11-17-1192 ESP comment resolution (75 mins) Mike MONTEMURRO - 11-18-1899 (40 mins) 2018-06-22 Robert STACEY – 11-18-702 4. AOB 5. Adjourn Teleconferences are subject to applicable policies and procedures, see below. ================================================== • IEEE Code of Ethics – • IEEE Standards Association (IEEE-SA) Affiliation FAQ – • Antitrust and Competition Policy – • IEEE-SA Patent Policy – – – – • IEEE 802 Working Group Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Chair's Guidelines (Approved 09 Mar 2018) – • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 10 Nov 2017) – References:
and non-DMG are adjectives, not channel" and avoid change to this definition. A comment to REVmd might be to replace "secondary channel" with "secondary 20 MHz channel". DMG is defined in the baseline 802.11 spec – see 11md D1.0. Without including DMG as part of this definition, any use of non-HT in the 802.11 spec could be interpreted as including DMG. This definition is more general and not specific to secondary channels, hence the proposed resolution does not apply. 1891 3.2 should we also consider the 2.16 + 2.16 channel and the 4.32 + 4.32 channels in defining secondary channels ? See Figure 3 on pg 29 line 6 for a discussion of secondary channelse I the 2.16 + 2.16 GHz and 4.32+4.32 GHz cases modify text " In DMG, a 2.16 GHz channel associated with a primary channel used by enhanced directional (EDMG) STAs for 15 the purpose of creating a 4.32 GHz, 6.48 GHz, 8.64 GHz, 2.16 + 2.16 GHz or 4.32 + 4.32 channel." Rejected 2.16 + 2.16 channel and the 4.32 + 4.32 channels options are already defined 2197 3.2 There is no reason to add non-DMG to the beginning of this definition, as the current definition specifically states which non-DMG cases it refers to. it is only necessary to add the new case of a secondary DMG channel. Change the definition to read: "secondary channel: A 20 MHz channel associated with a primary channel used by high-throughput (HT) stations (STAs) for the purpose of creating a 40 MHz channel or used by very high throughput (VHT) STAs for the purpose of creating the primary 40 MHz channel; or a 2.16 GHz channel associated with a primary channel used by enhanced directional (EDMG) STAs for the purpose of creating a 4.32 GHz, 6.48 GHz or 8.64 GHz channel." Selection of secondary channels was addressed in CID 1708 which provided the mechanism to define the secondary channels (8.3.5.12.2 Semantics of the service primitive) . The wording "associated with primary channel" was adopted from HT and VHT.
FORMAT is S1G_DUP_1M and AGGREGATION is NOT_AGGREGATED Indicates the packet duration in number of octets in the S1G 1 MHz Duplicate PSDU. Y Y AGGREGATION is NOT_AGGREGATED Indicates the packet duration in number of octets in the PSDU (#1138) Y Y Otherwise See corresponding entry in Table 19-1 (TXVECTOR and RXVECTOR parameters) and Table 21-1 (TXVECTOR and RXVECTOR parameters). ------------- End Text Changes ---------------
IEEE P802.11 Wireless LANs 802.11ak amendment publication Press Release Date: 2018-06-27 Author(s): Name Affiliation Address Phone Dorothy Stanley HP Enterprise 3333 Scott BLvd Santa Clara, CA 95054 +1 630 363 1389 Donald Eastlake Huawei Technologies 155 Beaver Street, Milford, MA 01757 USA +508-333- 2270 Mark Hamilton Ruckus/ARRIS 350 W Java Dr Sunnyvale, CA 94089 +1 303-818-8472 Jeff Pane IEEE Process This press release was authored by the IEEE marketing department (represented by Jeff Pane) after interviewing 802.11 subject-matter experts (Donald Eastlake and Mark Hamilton). The press release is being notified to the WG and will be notified to the EC for comment. Press Release: References:
d) The STA chooses a random number m from [0, TI]. e) The STA chooses a random number l from [0, L], , 0 is the first authentication control slot. f) The STA may initiate normal EDCA access procedures for the transmission of the Authentication Request frame beginning at the authentication control slot l in the BI m, where m=0 is the current BI. Proposed: a) The STA maintains the following distributed authentication control (DAC) parameters: 1) Authentication control slot duration (Tac) in TU units. The default value is set to 10 TUs. 2) Minimum transmission interval (TImin) in units. The default value is set to 8 . 3) Maximum transmission interval (TImax) in units. The default value is set to 256 . b) The STA maintains a transmission interval (TI) in units. c) The TI is initialized to TImin. d) The STA chooses a random number m from [0, TI]. e) The STA chooses a random number l from [0, L], where , 0 is the firstauthentication control slot. f) The STA may initiate normal EDCA access procedures for the transmission of the Authentication Request frame beginning at the authentication control slot l in the m, where m=0 is the current . Note: the red boxed formula above is removed and replaced with the red text formula. I didn’t know how else to show this in this document. References: 11-18-0611-04-000m-revmd-wg-ballot-comments IEEE P802.11-REVmd™/D1.0, February 2018. (Revision of IEEE Std 802.11TM-2016 as amended by IEEE Std 802.11aiTM-2016, and IEEE Std 802.11ahTM-2016)
Motion that approved the EHT TIG: “Approve formation of an XT TIG to initiate discussion on new 802.11 features for bands between 1 and 7.125 GHz: with the primary objective to increase peak throughput candidate features include but are not limited to: 320 MHz bandwidth, multiband aggregation and operation, and 16 spatial streams, as described in . To support high throughput applications such as video-over-WLAN, AR and VR” The primary purpose of this group is to try to reach consensus on a motion to approve an EHT Study Group. 5. Contributions 6. Plan for July (2 sessions) (at least 10 minutes prior to the end of the call) 7. Adjourn Teleconferences are subject to applicable policies and procedures, see below. ================================================== • IEEE Code of Ethics – • IEEE Standards Association (IEEE-SA) Affiliation FAQ – • Antitrust and Competition Policy – • IEEE-SA Patent Policy – – – – • IEEE 802 Working Group Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Chair's Guidelines (Approved 09 Mar 2018) – • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 10 Nov 2017) – Minutes: Dennis Sundman (Ericsson AB) appointed secretary. 49 people on the call (probably many duplicates, people being both on phone and computer). Dennis sends an e-mail to the reflector so that people can register. Mike goes through the patent policies. No comments. Attendence: Abhishek Patil (Qualcomm) Alfred Asterjadhi (Qualcomm) Allen D. Heberling (GenXcomm) Artyom Lomayev (Intel)
IEEE P802.11 Wireless LANs Resolution to Comments : Abstract This document presents suggested proposal towards CID 1064, 1067, 1180, 1289, 1437, 1438, 1440, 1441, 1442, 1443, 1444, 1446, 1552, 1640, 1658, 1659, 1660, 1661, 1728, 1729, 1862, 1869, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2198, 2199. Date: 2018-06-11 Author(s): Name Affiliation Address Phone email Rob Sun Huawei Technologies, Canada Suite 400, 303 Terry Fox drive, Kanata, On +1 613 2781948 Yan Xin Huawei Technologies, Canada Modify the following definition into 10.3.1 as highlighted in red texts: STA authentication and association
1444 12.12.3.4.1 The handshaking for FAA begins with a beacon which is broadcast by the PCP/AP. This frame contains the Anonce which is put into the KDF. But if two DMG STAs both receive the same beacon, a distinct possibility, after discovering the PCP/AP then the Anonce will be the same for two different sessions. This is a problem because the security of the 4-way handshake, from which it look like FAA has borrowed, is based on the nonces being randomly generated, unique, and ephemeral for each 4-way handshake. If you reuse a nonce you adversely affect the security of the handshake. It seems FAA can very easily reuse a nonce. Stop a broadcast frame from the PCP/AP to initiate the handshake. Replace FAA with SAE and collapse the exchange into "(Re)Association Request, (Re)Association Response, and FAA Authentication Ack", use special DMG action frames to transmit SAE, or just require DMG STAs to use 802.11 Authentication frames now if they want to implement FAA. Rejected 1) Due to the nature of usage for EDMG FAA which is essentially point to point for UC #1. It's safe to use in this case. 2) SAE is a slow process of the password/psk based, very computational intensive. it's not fit for the usage of UC #1. 1446 4.5.4.2 "The FAA authentication exchange is utilized with a non trusted third party (TPP)" What are the 3 entities involved? The STA isn't a third party. Delete the cited text. Revised .
1862 4.5.4.2 EDMG AP used in multiple instances in draft and not defined Add definition in clause 3.0 Definitions Rejected This is not the philosophy used in the 802.11 spec. For example, is no definition (in section 3) for HT AP or VHT AP. 1869 12.7.12 SNonce and ANonce are 16 bit random values. The text doesn't call out that the SNonce and ANonce are to be used only once in a session and not repeated on future sessions. Add Note in the security clause that a Snonce and Anonce are to be used once per session. TGay may discuss this with REVmd Revised partially Duplicated with CID 1064 2011 12.7.2 If FAA is defining a new Key Derivation protocol it should be a new AKM. Define a new AKM for FAA and include it in the RSN AKM table in Section 9. Update Section 12 as appropriate. Rejected The AKM for FAA has been defined in section 9.4.2.23.3 2012 12.12.2 Shared secrets are subject to dictionary attacks. IEEE 802.11 already includes SAE. Any new "shared secret" security protocol for IEEE 802.11 should be based on SAE. Adjust FAA to be based on SAE and make the approprate changes in Clause 12. Rejected Duplicated with 1440
IEEE P802.11 Wireless LANs Text Contributions to the FD-TIG Technical Report regarding Full Duplex for 802.11 Date: 2018-06-01 Author(s): Name Affiliation Address Phone email Allen D. Heberling GenXcomm 1604 San Antonio St. Austin, TX, 78701 This Page Intentionally Blank. of Contents This Page Intentionally Blank.
FD functional requirements Bands and bandwidths of FD operations 2.4 GHz Full Duplex capability shall be operational in these existing IEEE 802.11 2.4 GHz channels and bandwidths: 11b DSSS 11 g/n OFDM 11n OFDM Ch. Idx Min (MHz) Fc (MHZ) Max (MHz) BW (MHz) Ch. Idx Min (MHz) Fc (MHZ) Max (MHz) BW (MHz) Ch. Idx Min (MHz) Fc (MHZ) Max (MHz) BW (MHz) 2401 2402 2402 0 2407 0 2407 0 2407 1 2401 2412 2423 22 1 2402 2412 2422 20 1 2412 2 2417 2 2417 2 2417 3 2422 3 2422 3 2402 2422 2442 40 4 2427 4 2427 4 2427 5 2432 5 2422 2432 2442 20 5 2432 6 2426 2437 2448 22 6 2437 6 2437 7 2442 7 2442 7 2442 8 2447 8 2447 8 2447 9 2452 9 2442 2452 2462 20 9 2452 10 2457 10 2457 10 2457 11 2451 2462 2473 22 11 2462 11 2442 2462 2482 40 12 2467 12 2467 12 2467 13 2472 13 2462 2472 2482 20 13 2472 2482 2482 5 GHz Full Duplex capability be operational in these existing IEEE 802.11 5 GHz channels and bandwidths:
Form Factor Antenna spacing Small Small Small Small Chip-scale Current Full Duplex MACs A review of the current technical literature regarding MAC protocols that support the Full Duplex (FD) exchange of packets in an IEEE 802.11 network revealed an extensive bibliography of papers. Out of this extensive list, these, at the moment, three FD capable MAC protocols were selected as indications of the evolving maturity of the full duplex protocols. The criteria used to select these three protocols are listed in the first column labelled Attributes. Table : FD MAC Comparisons Attributes S-CW Full Duplex [5] SRB-MAC [6] STR-MAC [11] Organization Sabanaci U. Rice U. Toshiba Research Modifications of existing Frame Formats 2 bits in existing MAC Hdr ctrl field; 10 bit next_bo field at head of payload Adds a 13 bit FD Hdr between the MAC Hdr and the Payload FD Capability Info Field; 1-bit mod of reserved bits in CTS (CTS_FD) New MAC Mechanisms Synchronized contention window Shared random backoff; virtual backoff; header snooping Adaptive Tx & ACK TO Supports Heterogeneous FD/HD Yes If HD Nodes support snooping, then Yes, else No Yes Supports Homogeneous FD WLAN Yes Yes Yes BiDirectional FD Yes Yes Yes UniDirectional FD Yes Yes Yes Hidden Node Mitigation Yes via FD & FDmaster bits in MAC Hdr ctrl fld. Via Snooping Via RTS/CTS Backwards Compatible w/ HD WiFi Yes If HD Nodes support snooping, then Yes, else No Yes FD,Throughput Gain in a BSS w/o hidden nodes 1.6x to 2.1x (40 to 2 nodes) FD, Throughput Gain in a BSS w/ hidden nodes 1.7x to 14.4x (2 to 40 nodes) Real World Implementation of Full Duplex Operation in DOCSIS 3.1-FDX DOCSIS 3.1 R-PHY [12] and DOCSIS 3.1-FDX [13] provide yet another example of a wired protocol that borrows heavily from the wireless communications domain (e.g.11n-OFDM and 11ax OFDMA). Both DOCSIS 3.1 documents define the use of a full duplex protocol between cable modems (CM) and
HEP4.1 Values in 20 MHz channel 28.3.8 (Timing-related parameters) CFHE:M Yes  No  N/A  HEP4.2 Values in 40 MHz channel 28.3.8 (Timing-related parameters) CFHE:M Yes  No  N/A  HEP4.3 Values in 80 MHz channel 28.3.8 (Timing-related parameters) CFHE:M Yes  No  N/A  HEP4.4 Values in 160 MHz channel 28.3.8 (Timing-related parameters) HEP3.4:M Yes  No  N/A  HEP4.5 Values in 80+80 MHz channel 28.3.8 (Timing-related parameters) HEP3.5:M Yes  No  N/A  HEP5 STBC 28.3.11.10 (Space-time block coding) CFHE:O Yes  No  N/A  HEP6 Tone allocation *HEP6.1 26-tone RU mapping 28.3.2.2 (Resource unit, guard and DC subcarriers), 28.3.2.3 (Null subcarriers) and 28.3.2.4 (Pilot subcarriers) CFHE:M Yes  No  N/A  *HEP6.2 52-tone RU mapping 28.3.2.2 (Resource unit, guard and DC subcarriers), 28.3.2.3 (Null subcarriers) and 28.3.2.4 (Pilot subcarriers) CFHE:M Yes  No  N/A  *HEP6.3 106-tone RU mapping 28.3.2.2 (Resource unit, guard and DC subcarriers), 28.3.2.3 (Null subcarriers) and 28.3.2.4 (Pilot subcarriers) CFHE:M Yes  No  N/A  *HEP6.4 242-tone RU mapping 28.3.2.2 (Resource unit, guard and DC subcarriers), 28.3.2.3 (Null subcarriers) and 28.3.2.4 (Pilot subcarriers) CFHE80:M CFHE20:O Yes  No  N/A 
11ax Editor: Modify 9.4.2.37 Neighbor Report element as follows: Neighbor Report element Change Figure 9-296 (BSSID Information field) as follows: B0 B1 B2 B3 B4 B9 B10 B11 B12 B13 B14 B15 B1 B31 AP Reachability Security Key Scope Capabilities Mobility Domain High Throughput Very High Throughput FTM High Efficiency HE ER Reserved Bits: 2 1 1 6 1 1 1 1 1 1 1