zilongwang/ReadingBank huggingface dataset:
Make changes as follows: 9.40 Delete “Annex G” balloons in 2 places (Left hand side and Right hand side) 9.42 Delete “Annex G” balloon in middle column 134.30 Delete “frame exchange sequence: A sequence of frames specified by Annex G”. 201.45 “Clause 6 (Layer management), Clause 8 (PHY service specification), Clause 9 (Frame formats), Clause 10 (bMAC sublayer functional description), Clause 11 (MLME), Clause 14 (MLME mesh procedures) apply to TVHT STAs as well, unless stated otherwise. 202.44 Delete lines 43 to 47 678.53, 1417.18, 1420.34, 1484.59, 1491.45 delete “(see Annex G)” 1419.63 delete “The cases when an Ack or BlockAck frame can be generated are shown in the frame exchange sequences listed in Annex G.” 1427.2, 1719.19, 1751.46, 1751.51 delete “, as described in Annex G” 1431 delete “(described in Annex G)” 1494.52 delete “(using the terminology of Annex G)” 1527.11 delete “The frame exchange sequences are provided in Annex G.” 1690.42 “For each frame received at the RDS during the SP, the RDS shall follow the same rules for frame exchange sequences as described in 10.36 (DMG channel access).” 1720.34, 1752.45, 1755.55 delete “(as described in Annex G)” 3581.1 Delete “Annex G” in its entirety
9.40 Delete “Annex G” balloons in 2 places (Left hand side and Right hand side) 9.42 Delete “Annex G” balloon in middle column 134.30 Delete “frame exchange sequence: A sequence of frames specified by Annex G”. 201.45 “Clause 6 (Layer management), Clause 8 (PHY service specification), Clause 9 (Frame formats), Clause 10 (bMAC sublayer functional description), Clause 11 (MLME), Clause 14 (MLME mesh procedures) apply to TVHT STAs as well, unless stated otherwise. 202.44 Delete lines 43 to 47 678.53, 1417.18, 1420.34, 1484.59, 1491.45 delete “(see Annex G)” 1419.63 delete “The cases when an Ack or BlockAck frame can be generated are shown in the frame exchange sequences listed in Annex G.” 1427.2, 1719.19, 1751.46, 1751.51 delete “, as described in Annex G” 1431 delete “(described in Annex G)” 1494.52 delete “(using the terminology of Annex G)” 1527.11 delete “The frame exchange sequences are provided in Annex G.” 1690.42 “For each frame received at the RDS during the SP, the RDS shall follow the same rules for frame exchange sequences as described in 10.36 (DMG channel access).” 1720.34, 1752.45, 1755.55 delete “(as described in Annex G)” 3581.1 Delete “Annex G” in its entirety RESOLUTION REJECTED A normative definition of exchange sequences is required and Annex G provides this.
an HE AP to manage RTS/CTS usage by HE STAs that are associated with it." Does the HE Duration Based RTS Threshold field manage the MU-RTS/CTS usage as well? Please clarify it. The commenter is asking a question. The answer is no because MU RTS frames are generated by APs, while the HE Duration based RTS threshold controls generation of RTS frames generated by non-AP STAs, which do not generate MU RTS frames. No further clarification is needed because it is already clear. 9665 Yongho Seok 91.64 "The value 0 indicates that RTS/CTS must be used for all frame exchanges." First comment is that any normative text is not allowed in Clause 9. Second comment is that all frame exchanges can not use RTS/CTS. The value 0 can be applied only for an HE STA. As per comment. Revised – First comment, agree, Removed the sentence. Second comment is solved as well because the sentence is not there anymore. Also please note that it is already clear that the functionality is applicable to HE non-AP STAs only (first sentence of the paragraph). TGax editor to make the changes shown in under all headings that include CID 9665.
HE MU PPDU (#5218) For an AP, indicates support for the reception on an RU in an HE MU PPDU where one of the following apply: the RU spans the entire PPDU bandwidth the RU does not span the entire PPDU bandwidth (106-tone RU within 20 MHz bandwidth) .(#3490)(#5143) Set to 0 if not supported. Set to 1 if supported.
HE MU PPDU (#5218) For an AP, indicates support for the reception on an RU in an HE MU PPDU one of the following apply: the RU spans the entire PPDU bandwidth the RU does not span the entire PPDU bandwidth (106-tone RU within 20 MHz bandwidth) .(#3490)(#5143) Set to 0 if not supported. Set to 1 if supported.
802.11 WG – Wireless LAN Working Group 802 EC – LAN/MAN Standards Committee Exceutive Committee eLWA - Enhanced LTE WLAN Aggregation EPC – Evolved Paket Core IEEE – Institue of Electic and Electronic Engineers IMT-2020 – International Mobile Telecommunications System for 2020 and beyond LAN – local area network LWA – LTE WLAN Aggregation LWIP – LTE WLAN Level Intergration with IPsec Tunnel LTE – Long-Term Evolution MAN – metropolitan area network NBIFOM – Network based IP Flow Mobility NR – New Radio QoS – Quality of Service RAN – Radio Access Network RAT – Radio Access Technology SA – Service and Systm Aspcects WG – Working Group WI – Work Item WLAN – wireless local area network
CID PP LL Comment Proposed Change Resolution 3083 195 There are cases (like GCR, FMS) where the traffic is for a limited set of STAs (i.e., not broadcast to all) - in such cases, a STA needs to check the MAC header to see if it is one of the intended recipient. Add text to clarify that when the STA_ID_LIST indicates 'more than one STA', a STA should check the MAC header to see if it is one of the intended recipient. Rejected. Discussion: the checking of MAC header to decide whether the frames carried in a DL RU is mandatory requirement for all RUs, not just for broadcast RUs. The reason is that the BSS color + AID in HE SIG-B to identify a DL RU is not unique. 7778 196 2 2047 is used as start of MAC padding on page 165 line 35 and here it's used to indicate STAs in all BSS when multiBSS is acviated. How does a STA identify if it's for start of the MAC padding or for STAs in all BSS? Clarify Rejected Discussion: 2047 for MAC padding is used in Trigger frame. 2047 for broadcast RU indentification is in HE SIG-B. These two usage should be ok. 8724 195 48 Is it correct that the STA_ID_LIST contains one See comment Revised Generally agree with the commenter.
CID PP LL Comment Proposed Change Resolution 3124 76 8 At 67.16, the HE Capabilities element is defined to be extensible. However at 76.08, the parsing of the PPE Thresholds field presumably relies on the Length field. These are incompatible. Either add a field for the PPE Thresholds in the frame format, or declare at 67.16 that the element is not extensible. Rejected. Discussion: The variable-length PPE Thresholds field can be figured out through NSS M1 subfield and RU Index Bitmask subfield. So extensible HE Capabilities element has no issue.
Rx Control Frame to MultiBSS Indicates whether the non-AP STA when associated with a BSS corresponding to a nontransmitted BSSID supports reception of a control frame with TA equal to the transmitted BSSID Set to 1 if supported. Set to 0 otherwise. BSRP A-MPDU Aggregation Indicates whether or not the STA accepts a BSRP Trigger frame that is aggregated with other control, data and management frames in an A-MPDU destined to the STA Set to 1 if supported. Set to 0 otherwise. QTP Support Indicates support for quiet time period (QTP) operation(#7374) as described in 27.16.4 (Quiet(#6797) HE STAs in an HE BSS)(#9108).(#6364) Set to 1 if supported. Set to 0 otherwise.(#9111) BQR Support For an AP, indicates support for receiving an that contains a BQR Control For a non-AP STA, indicates support for generating an that contains a BQR Control field.(#6364)(#8430) If +HTC-HE Support is 1: Set to 1 if the STA supports the BQR Control functionality. Set to 0 otherwise. Reserved if +HTC-HE Support is 0. SR Responder(#8087) Indicates support for the role of SR Responder.(#6364) Set to 1 if the STA supports the role of SR Responder. Set to 0 otherwise. NDP Feedback Report Support(#6144) For a non-AP STA, indicates support for the NDP feedback report procedure and responding to the NDP Feedback Report Poll Trigger frame.(#6364) Set to 1 if supported. Set to 0 otherwise. OPS Support(17/325r4) For an AP, indicates support for encoding OPS information in the TIM element of FILS Discovery frames or TIM frames as described in 27.14.3.2 (AP operation for opportunistic power save). For a non-AP STA, indicates support for receiving the opportunistic power save encoded TIM elements.(#6364) Set to 1 if supported. Set to 0 otherwise. TGax editor: Change the last two paragraphs as follows:
TID Info subfields(#7734) sets the RA field to the address of the recipi-ent STA that solicited the BlockAck frame(#Ed, #3161). A non-AP HE STA(#6256) that(#9624) transmits a Multi-STA BlockAck frame with a single AID subfield or with the same values of the AID subfield in Per AID TID Info subfields(#7734) and sets the RA field to the TA field of the soliciting frame or the address of the recipient STA whose data or management frames(#3110) are acknowledged.(#7727) 9.4.2.237 HE Capabilities element 9.4.2.237.1 General TGax editor: change the last paragraph in 9.4.2.237.1 as follows: The HE MAC Capabilities Information, HE PHY Capabilities Information, Tx Rx HE-MCS NSS Support(# 7718), and PPE Thresholds fields are defined in . 9.4.2.237.2 HE MAC Capabilities Information field TGax editor: Change Figure 9-589ck as follows: B0 B1 B2 B3 B4 B5 B7 B8 B9 B10 B11 B12 B14 +HTC HE Support TWT Requester Support TWT Support Fragmentation Support Maximum Number of Fragmented MSDUs Minimum Fragment Size Trigger Frame MAC Padding Duration Multi-TID Aggregation Support 1 1 1 2 3 2 2 3 B15 B16 B17 B18 B19 B20 B21 B22 B23 HE Link Adaptation All Ack Support UMRS BSR Broadcast TWT Support 32-bit BA Bitmap Support MU Cascading Multi-TID Aggregation Support Group Addressed Multi-STA BlockAck In DL MU Support 2 1 1 1 1 1 1 1 1(#4467) B25 B26 B27 B28 B29 B30 B31 B32 OM Control RA Support Exponent A-MSDU Support Flexible TWT Schedule Support Rx Control Frame to MultiBSS BSRP Aggregation
List of Abreviations and Acronyms: 3GPP – 3rd Generation Partnership Project 802.1 WG – Higher Layer LAN Protocals Working Group 802.11 WG – Wireless LAN Working Group 802 EC – LAN/MAN Standards Committee Exceutive Committee eLWA - Enhanced LTE WLAN Aggregation EPC – Evolved Core IEEE – Institue of Electic and Electronic Engineers IMT-2020 – International Mobile Telecommunications System for 2020 and beyond LAN – local area network LWA – LTE WLAN Aggregation LWIP – LTE WLAN Radio Level Intergration with IPsec Tunnel LTE – Long-Term Evolution MAN – metropolitan area network NBIFOM – Network based IP Flow Mobility NR – New Radio QoS – Quality of Service RAN – Radio Access Network RAT – Radio Access Technology SA – Service and Systm Aspcects WG – Working Group WI – Work Item WLAN – wireless local area network
36 182 56.16 6480 17-20 37 183 56.16 8640 25-27 Table E-2—Operating classes in Europe Operating Global operating class (see Table E-4) Channel starting frequency (GHz) Channel spacing (MHz) Channel set Channel center frequency index Behavior limits set 19 181 56.16 4320 9-11 20 182 56.16 6480 17-18 21 183 56.16 8640 25 Table E-3—Operating classes in Japan Operating class Global operating class (see Table E-4) Channel starting frequency (GHz) Channel spacing (MHz) Channel set Channel center frequency index Behavior limits set 60 181 56.16 4320 9-11 61 182 56.16 6480 17-18 62 183 56.16 8640 25 Table E-4—Global operating classes Operating class Global operating class (see Table E-4) Channel starting frequency (GHz) Channel spacing (MHz) Channel set Channel center frequency Behavior limits set 181 E-1-35, E-2-19, E-3-60 56.16 4320 9-13 182 E-1-36, E-2-20, E-3-61 56.16 6480 17-20 183 E-1-37, E-2-21, E-3-62 56.16 8640 25-27 Annex B Figure 1. Example transmit spectral mask for a 2.16 GHz mask PPDU. Figure 2. Example transmit spectral mask for a 4.32 GHz mask PPDU. Figure 3. Example transmit spectral mask for a 6.48 GHz mask PPDU. Figure 4. Example transmit spectral mask for a 8.64 GHz mask PPDU. Figure 5. Example transmit spectral mask for a 2.16+2.16 GHz mask PPDU. References: [1] NG60 proposed CSD, IEEE 802.11-14/1152r8. [2] IEEE P802.11ay/D1.0.
IEEE P802.11 Wireless LANs CR for CID5859 and CID5971 Date: 2017-09-02 Author(s): Name Affiliation Address Phone email Jarkko Kneckt, Guoqing Li, Chris Hartman, Yong Liu Apple Inc. Cupertino, CA CID Page Clause Comment Proposed Change Resolution 5958 141.12 11.2.2.6 The use of PS-Poll frame together with the TWT power save mechanism could be clarified and justified. The should be used only with announced TWT. The TWT SP intiated by PS-Poll should be terminated like any TWT SP, i.e. no data should be transmitted outside of TWT SP. Please clarify how TWT and PS-Poll frames are used. It would make sense that if a PS-Poll frame is transmitted within the TWT SP and termiantion of the TWT SP also cancels the solicited DL PPDU transmission regardless if it has not been yet transmitted. Revise – agree in principle that TWT SP termination cancels also PS-Poll frames to wait for DL frame as response to the frame. Disagree with the principle that PS-poll frame needs to be transmitted within TWT SP. The frames to transition to active/power save mode and APSD trigger frame may be transmitted at any time. TGax editor to make
BW Bandwidth of the recommended HE-MCS/ Bandwidth specified by MFB requester to get feedback If the Unsolicited MFB subfield is 1, the BW subfield indicates the bandwidth for which the recommended HE-MCS is intended, as defined in 27.13. If the Unsolicited MFB subfield is 0 and the MRQ subfiled is 1, the BW subfield indicates the bandwidth requested by the MFB requester to get feedback. For an HE STA: Set to 0 for 20 MHz Set to 1 for 40 MHz Set to for 80 MHz Set to 3 for 160 MHz or 80+80 MHz. Otherwise, this subfield is reserved. MSI/PPDU-Type Packet format of the measured PPDU/ MRQ sequence identifier If the Unsolicited MFB subfield is 0 and the MRQ subfield is 1, the MSI/PPDU-Type subfield contains a sequence number in the range 0 to 6 that identifies the specific MCS feedback request. If the Unsolicited MFB subfield is 0 and the MRQ subfield is 0, the MSI/PPDU-Type subfield contains a sequence number in the range 0 to 6 that reponds to the specific solicited MCS feedback request. If the Unsolicited MFB subfield is 1, the subfield contains the Packet Format and Coding subfields as shown in Figure XXX. The Packet Format subfield indicates the packet format of the PPDU from which the unsolicited MFB was estimated: Set to 0 for HE_SU Set to 1 for HE_MU Set to 2 for HE_EXT_SU Set to 3 for HE_TRIG The Coding Type subfield contains the Coding information (0 for BCC and 1 for LDPC) of the PPDU from which the unsolicited MFB was estimated. Tx BF Transmission type of the measured PPDU If the Unsolicited MFB subfield is 1, Tx BF subfield indicateds if the PPDU from which the unsolicited MFB was estimated is beamformed or not. Set to 0 for non-beamformed PPDU Set to 1 for beamformed PPDU Otherwise, this subfield is reserved. B0 B1 B2 Packet Format Coding Type 2 1
CID Page Line Clause Comment Proposed Change 9551 Inoue 275.08 Table 28-16 B8 of (HE SU PPDU) or HE-SIG-A3 (HE extended range SU PPDU): "Indicates the presence of the extra OFDM symbol for LDPC. Set to 1 if an extra OFDM symbol for LDPC is present Set to 0 if an extra OFDM symbol for LDPC is present ..." Value 1 or 0 should indicate that an extra OFDM symbol for LDPC is not present. As in the comment. Revised See resolution to comment 8917 Discussion: CID 8917 is about the coding of B11 of the HE-SIG-A2 for an HE MU PPDU (Table 28-17 in D1.0) while CID 9551 is for B8 of HE-SIG-A2 for an HE SU PPDU and HE extended range SU PPDU (Table 28-16 in D1.0). In 802.11ax D1.4, relevant part of the draft is Table 28-17—HE-SIG-A field of an HE SU PPDU and HE ER SU PPDU Two Parts of HE-SIG-A Bit Field Number of bits Description … … … … … (HE SU PPDU) or (HE … … … …
Although transmissions by an AP are typically received by all STAs associated with that AP, the service provided by a GLK infrastructure BSS might be considered as separate point-to-point links between the corresponding ISS SAPs. Provision of such apparent point-to-point links is natural for MPDUs with an individually addressed RA. In order to provide such apparent point-to-point links for group addressed frames the GLK AP transmit them so that they are accepted by a subset of the associated GLK STAs. Such selective transmission can be provided through the GLK SYNRA addressing facility (see 4.3.27.3 (Selective reception of group addressed frames)) or by serial unicast. Figure 4-13b—infrastructure BSS with general links BSSs that support general links can be components of an extended form of network by using the general links within an IEEE Std 802.1Q bridged network In such a bridged network, the concept of the DS in a non-GLK ESS is replaced by the other components of the IEEE Std 802.1Q network. However, such a GLK topology is more general than the non-GLK infrastructure mode. For example, Figure 4-13c—Example of ESS with general links References: [1] 11-17/0932r6, “802.11ak Figs 4-13”, [2] P802.11ak/D4.2, March 2017, “IEEE P802.11ak™/D4.2 Draft Standard Telecommunications and information exchange between systems – Local and metropolitan area networks Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 4: Enhancements For Transit Links Within Bridged Networks”, Draft P802.11ak_D4.2
However, in the interests of compromise, the IEEE 802.11 Working recommends that reasonable restrictions be placed on the use of blocking energy by all devices in the next revision of EN 301 893 rather than a complete ban, and that these restrictions be defined in a way that are applicable to all technologies. This approach will uphold the important principle of technology neutrality. In particular, IEEE 802.11 Working Group recommends that, in the next revision of EN 301 893, a device only be allowed to transmit energy for a maximum of 100 µs when the primary purpose of that transmission is to block another user from accessing the channel. In the context of LAA, this would mean that an LAA device would only be able to transmit blocking energy for a maximum of 100 µs before a starting position. Noting that an LAA symbol has a length of about 71 µs, this would allow LAA to operate with a starting position at each of the fourteen symbols in a sub-frame. While this different from how LAA currently operates today, a recent contribution to 3GPP RAN1 suggests this is a feasible compromise solution to resolve the blocking energy issue. The effect of such a rule be to force LAA to define fourteen mandatory starting positions if 3GPP RAN1 decided that it is important to enable the use of blocking energy. Of course, 3GPP RAN1 could always decide not to enable the use of blocking energy because, as they noted previously, deferring sending energy until a subframe boundary or partial subframe boundary … also provided good LAA performance. The IEEE 802.11 Working Group requests that ETSI BRAN consider our recommendation to restrict the use of blocking energy. We would be delighted to have further discussions with ETSI BRAN in relation to this topic. Sincerely, Adrian Stephens IEEE 802.11 Working Group
IEEE P802.11 Wireless LANs Comments on 11ax clauses 10.1 and 10.2 Date: 2017-09-13 Author(s): Name Affiliation Address Phone email Mark Hamilton Ruckus/Brocade 350 W Java Dr Sunnyvale, CA 94089 +1.303.818.8472 CID Page Clause Comment Proposed Change Resolution 4746 113.03 10.2.1 Need to update the MAC architecture (Figure and respective definitions to host the enhancements for HE (UL MU, etc). As in comment. Revised. TGax Editor to make changes proposed in <this document> 5373 113.05 10.2.1 Update Figure STA MAC architecture with new 11ax features (OFDMA, HE PHY, etc) As in comment Revised. TGax Editor to make changes proposed in <this document> 8207 113.04 10.2 The 802.11ax amendment introduces MU transmissions which is not supported by any of the control functions in Figure 10-1 of the 802.11-2016. There is a need to introduce a ne MU access function and add to the Figure. as in comment. Revised. TGax Editor to make changes proposed in <this document> 10.1 Introduction The MAC functional description is presented in this clause. The architecture of the MAC sublayer, including the distributed coordination function (DCF), the point coordination function (PCF), the hybrid coordination function (HCF), the mesh coordination function (MCF), and their coexistence in an IEEE 802.11 LAN are introduced in 10.2 (MAC architecture). These functions are expanded on in 10.3 (DCF), 10.4 (PCF), 10.24 (HCF), 10.25 (Mesh
Proposed resolution: Revised TGax editor: In line 7, page 527 of IEEE 802.11ax/D1.4, change “are provided in dot11PPEThresholdsTable” with “are provided in dot11PPEThresholdsMappingTable”.
CID Page Number Line Number Comment Proposed Change Resolution 114 59 29 What is the expected behavior after initiator receives an additional feedback request from responder? We should add statements with "shall" or "should" that describe the intended behavior Please clarify Reject The expected behavior after initiator receives an additional feeback request from responder is well defined at ’10.38.9.2.2 Multiple sector feedback’ in the draft 0.5. CID Page Number Line Number Comment Proposed Change Resolution 152 39 27 Sector sweep field definition with Sector ID and DMG Antenna ID is inefficient for MIMO STAs. Suggest defining an EDMG Sector Sweep field that supports more efficient sector sweeps over multiple antenns both one at a time and simultaneously. Reject Sector sweep does not need to be performed by using MIMO. In the current draft, the MIMO BF training can be supported without the transmission over multiple antenns both one at a time and simultaneously. CID Page Number Line Number Comment Proposed Change Resolution 483 74 2 Beamforming training for channel bonding and channel aggregation should be defined in the section of '10.38.3 Beam Refinement Protocol(BRP) phase'. Define when beamforming training for channel bonding and channel aggregation can be performed. Revised In the draft 0.5, the beamforming training for channel bonding and channel aggregation can be performed in the BRP phase. References: [1] IEEE 802.11ay D0.3 [2] IEEE 802.11ay D0.5 ---------------------------------------------------------------------------------------------------------------------
TX Sector ID for SS3 6 46 This field indicates the sector that the transmitter of this control trailer uses for SS3. Reserved if SISO/MIMO is set to 0. TX DMG antenna ID for SS3 2 52 This field indicates the DMG antenna that the transmitter of this control trailer uses for SS3. Reserved if SISO/MIMO is set to 0. RX DMG antenna ID for SS3 2 54 This indicates the DMG antenna that the recipient of this control trailer uses for SS3. Reserved if SISO/MIMO is set to 0. TX Sector ID for SS4 6 56 This indicates the sector that the transmitter of this control trailer uses for SS4. Reserved if SISO/MIMO is set to 0. TX DMG antenna ID for SS4 2 62 This field indicates the DMG antenna that the transmitter of this control trailer uses for SS4. Reserved if SISO/MIMO is set to 0.
TX DMG antenna ID for SS6 2 82 This field indicates the DMG antenna that the transmitter of this control trailer uses for SS6. Reserved if SISO/MIMO is set to 0. RX DMG antenna ID for SS6 2 84 This indicates the DMG antenna that the recipient of this control trailer uses for SS6. Reserved if SISO/MIMO is set to 0. TX Sector ID for SS7 6 86 This field indicates the sector that the transmitter of this control trailer uses for SS7. Reserved if SISO/MIMO is set to 0. TX DMG antenna ID for SS7 2 92 This field indicates the DMG antenna that the transmitter of this control trailer uses for SS7. Reserved if SISO/MIMO is set to 0. RX DMG antenna ID for SS7 2 94 This field indicates the DMG antenna that the recipient of this control trailer uses for SS7. Reserved if SISO/MIMO is set to 0.
Airtime reflects the amount of channel resources consumed by transmitting the frame over a particular link. This measure is approximate and designed for ease of implementation and interoperability. The airtime for each link is calculated as follows: where O and Bt are constants listed in Table 14-4 (Airtime cost constants) input parameter r is the data rate (in Mb/s) input parameter ef is the frame error rate for the test frame size Bt The airtime link metric shall be encoded as an unsigned integer in units of 0.01 TU. Airtime cost constants Parameter Recommended value Description O Varies depending on PHY Channel access overhead, which includes frame headers, training sequences, access protocol frames, etc. Bt 8192 Number of bits in test Table 14-5 (Parameters of the airtime link metric for extensible path selection framework) gives the parameters of the airtime link metric for the extensible path selection framework. Parameters of the airtime link metric for extensible path selection framework Parameter Notes Path Selection Metric ID See Table 9-218 (Active Path Selection Metric Identifier field values) in 9.4.2.98.3 (Active Path Selection Metric Identifier) Data type Unsigned integer, 0 metric < 4 294 967 296 Length of metric field 4 octets Operator for metric aggregation addition (+)
Comparison operator less than, to, greater than as used with integers metric a is better than metric b iff a < b metric a is equal to metric b iff a = b metric a is worse than metric b iff a > b Initial value of path metric 0 An example of the airtime link metric is shown in S.5 (Airtime link metric usage example).
To REVmd Editor: Change the row representing MP10 in the table in B.4.21.1 (General mesh support) in Annex B as follows: Mesh protocol capabilities B.4.21.1 General mesh support MP9.5 Frame transmission to a mesh STA in deep sleep mode 14.14.7 (Power save support), 14.14.9 (Mesh peer service periods)(Ed) MP9:M Yes  No  N/A  MP10 ink metric computation 14.9 ()(Ed) Yes  No  N/A  *MP11 Link metric reporting 14.8.3 (Link metric reporting)(Ed) Yes  No  N/A  To REVmd Editor: Change the MIB definition of dot11MeshActivePathSelectionMetric in Annex C as follows:
IEEE P802.11 Wireless LANs Resolution to CID7548 Date: 2017-09-10 Author(s): Name Affiliation Address Phone email Yujin Noh Newracom yujin.noh at newracom.com Bin Tian Qualcomm 5775 Morehouse Dr. San CA, USA 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.
IEEE P802.11 Wireless LANs 11ax Comment Resolution for CID 7859 Date: 2017-09-11 Author(s): Name Affiliation Address Phone Email Yan Zhang Marvell , Santa Clara, CA 95054 408-222-0975 Hongyuan Zhang Marvell Rui Cao Marvell Abstract: This document contains proposed resolutions for comments in Clause 28.3.10.8.6 from 11ax D1.4 with the CID Clause 28.3.10.8.6 7859 7859 Mark RISON 28.3.10.8.6 391.30 Is this illustration for one content channel? Add "for one content channel" to the caption for Figure 28-25 Revised. Change to as in the resolution of
IEEE P802.11 Wireless LANs IEEE 802.11 TGax, MU Ad hoc September 2017 TGax Meeting Minutes Date: 2017-09-12 Author(s): Name Affiliation Address Phone email Kiseon Ryu LG kiseon.ryu@lge.com Sigurd Schelstraete Quantenna Communications sigurd@quantenna.com IEEE 802.11 Task Group ax, MU Ad hoc Kona, Hawaii, US September 11th – 15th, 2017 MU Adhoc Session #1 Tuesday, September 12th, 2017, PM3 TGax Session (7:30 – 9:30) The meeting called to order by Sigurd Schelstraete (Quantenna), the co-chair of the TGax MU Ad hoc Announcement Agenda Document 11-17/1487r0 is on the server. Meeting Protocol: The Chair asked to state name and affiliation when speaking for the first time. Attendance reminder. The attendance server: https://imat.ieee.org/ The chair reviewed the mandatory slides of P&P. Instructions from the WG Chair. [reviewed, did not review] Participants, Patents, and Duty to Inform. [reviewed, did not review] Patent Related Links. [reviewed, did not review] Call for potentially essential patents. Chair asked if anyone is aware of potentially essential patents [Asked. Did not ask] Potentially essential patents [None reported. Reported as follows] Other Guidelines for IEEE WG Meetings. The Chair identified 4 presentations assigned by the TGax chair to be treated in MU Ad hoc
Clarification of transmitter behaviour or receiver behaviour requested for some items. Next step Osama to update the document. Osama Aboul-Magd (Huawei Technologies) presented “Clause 4.3.12a Comment Resolution,” based on the submission 11-16-1336-00. Summary Resolutions for the nine CIDs on clause 4.3.12a proposed. CIDs: 81, 82, 710, 1226, 1235, 1236, 1351, 1707, and 1776. Discussion Some editorial corrections suggested. Next step Osama to upload revision 1 of this document incorporating the changes based on the discussion. AoB No other business to conduct. Adjourn TGax teleconference adjourned @ 21:43. List of Attendees Name Affiliation 1 Osama Aboul-Magd Huawei Technologies 2 Tomoko Adachi Toshiba 3 Woojin Ahn WILUS Institute 4 David Bagby Calypso Ventures 5 Jinsoo Choi LG Electronics 6 Chu Marvell 7 Hanseul Hong Yonsei Univ. 8 Yasuhiko Inoue NTT 9 Junichi Iwatani NTT 10 Jinjing Marvell 11 Jeongki Kim LG Electronics 12 Joonsuk Kim Apple 13 Geonjung Ko WILUS Institute 14 Oghenekome Oteri InterDigital 15 Jayh Park LG Electronics 16 Al Petrick Jones-Petrick and Associates 17 Kiseon Ryu LG Electronics 18 L. Sun IDCC 19 Lochan Verma Qualcomm 20 Xiaofei Wang InterDigital 21 22 23 24 25 Teleconference on Thursday, October 20th, 2016, 10:00 – 12:00 (ET) Meeting called to order by Osama Aboul-Magd (Huawei Technologies) @ 10:03 (ET). Agenda Setting Proposed Agenda Call the meeting to order IEEE 802 and 802.11 IPR Policy and Procedure Annoucement Attendance (Please send an e.mail to Yasuhiko Inoue (inoue.yasuhiko@lab.ntt.co.jp) and/or Osama Aboul-Magd (osama.aboulmagd@huawei.com)) Presentation
2057.30 12.2.2 Security methods 2057.40 delete” — TKIP, described in 12.5.2 (Temporal key integrity protocol (TKIP))” 2062.12 Rename 12.3 “Open System authentication” Delete 12.3.1 to 12.3.2.4, and heading 12.3.3. in their entirety Renumber 12.3.3.1 as 12.3.1 12.3.1 Overview In an infrastructure BSS, a non-DMG STA shall complete an IEEE 802.11 authentication exchange prior to association. A DMG STA not in an IBSS complete an IEEE 802.11 authentication exchange prior to association when an authentication algorithm other than the Open System authentication algorithm is requested. A DMG STA shall not perform an IEEE 802.11 authentication exchange using the Open System authentication algorithm. An IEEE 802.11 authentication exchange is optional in an IBSS. All Authentication frames shall be individually addressed, as IEEE 802.11 authentication is performed between pairs of STAs, i.e., group addressed authentication is not allowed. Deauthentication frames are advisory and may be sent as group addressed frames. Delete heading 12.3.3.2 Renumber 12.3.3.2 as 12.3.2 “General” Renumber 12.3.3.2.2 as 12.3.3 Renumber 12.3.3.2.3 as 12.3.4 Delete 12.3.3.3 in its entirety 2089.1 to 2103.44 Delete 12.5.2 Temporal key integrity protocol (TKIP) in its entirety 2128.34 12.6.3 RSNA policy selection in an infrastructure BSS delete “ .” 2130.27 12.6.5 RSNA policy selection in an IBSS and for DLS Delete “ .” 2131.60 12.6.7 RSNA policy selection in an MBSS Delete “ .” 2145.29 12.7.1.1. Key Hierachy Delete . .
3063.61 delete “dot11CFPMaxDuration OBJECT-TYPE” entirely 3472.3 delete “or PCF” 3472.20 delete “or PCF” 3472.38 delete “or PCF” 3472.56 delete “or PCF” 3582.6 delete “CF, Beacon contains a CFP element.”
Discussion: Yes, there is no precedent usage of such term “unicast trigger”. Propose to use “an individually addressed Trigger frame” to replace “unicast trigger”. Proposed Resolution: already fixed in D0.5. 964 42.00 10.3.2.11.3 The figure 10-ax4, "Backoff or PIFS " is confusing. Does "Backoff or PIFS " mean that an AP uses bacoff or PIFS to contend the primary channel or an AP uses backoff to contend the primary channel and PIFS to determine the status of the sencondary channels? Please clarify it. Discussion: are multiple cases that a PIFS could be used. Please refer to 10.3.2.3.4 and also TWT operation. However, the TXOP is not accurately drew in the figure. Proposed Resolution: Remove “PIFS” in all the figures (10.ax4-10.ax8) to eliminate confusion. 823 43.01 10.3.2.11.3 If spec does not allow UL MU MIMO Block ACK and Ack policy, STAs with UL MU MIMO capability and without UL MU OFDMA capablity cannot be the target of Ack Policy '01' in QoS Control field in MPDUs. Change the following An AP shall not set Ack Policy to "01" in QoS Control field in MPDUs of HE MU PPDU if (both) UL MU OFDMA Capable subfield (and UL MU MIMO Capable subfield) of the HE Capabilities element of the receiver of the MPDUs are set to 0. or Specify MU MIMO Ack procedure Discussion: In general, agree with the commenter’s intention to differentiate UL MUMIMO and UL MU OFDMA capability. To remove confusion, the paragraph is to be deleted. Also see CID 2607 Proposed Resolution: Already fixed in D0.5 798 44.46 10.3.2.11.4 in Figure 10-ax5, TXOP starts from the middle of the Backoff or PIFS. On the other hand, all TXOP start from the beginning of the Trigger frame Make the figures consistent or describe the difference in Figure 10-ax5
Presentations: 11-17/1384r0, “WUR Synchronization”, Yongho Seok (MediaTek): The submission is concerned with synchronization using the partial timestamp field in the beacon. Q: You recommend that the WUR beacon is sent every second, but earlier we have discussed 10s in order to reduce channel occupancy. Maybe we can discuss this a bit more. The straw poll is deferred. 11-17/1004r2, “Considerations on WUR format”. Alfred Asterjadhi (Qualcomm): This is a continuation of the presentation, now running the straw polls. Straw Poll 1: Do you agree with the following MAC frame: The length of the MAC header is fixed Whether the Address field contains more than one identifier is open for discussion Y/N/A: 18/2/10 Poll 2: Do you agree to have a Type subfield that identifies the WUR frame type? The Type subfield is contained in the Frame Control field of the MAC header One Type subfield assigned to WUR Beacon and one to Wake Up frame Y/N/A: 9/0/14 Poll 3a: Do you agree to have in the Address field an identifier that: Is the identifier of the transmitter when the frame is WUR Beacon Y/N/A: 18/1/7 Straw Poll 3b:
Move: Eunsung Park Second: Jinsoo Choi Motion passed by unanimous consent. Straw Poll 2: Do you agree to take the following waveform coding as an optional feature of WUR frame format? ON-signal for the data rate of 250Kbps is composed of a TBD usec null portion and a 2-TBD usec signal part The TBD usec is non-zero Indication of capability to handle the proposed waveform is TBD The proposed waveform is for the payload and is not applied to the WUR preamble SYNC symbols and TBD indication bit(s) Y/N/A: 17/23/7 11-17/1394r0, “Discussion of possible BCCs for WUR”, Dennis Sundman (Ericsson): Based on that there in earlier meeting have been some concern regarding reusing the memory 6 BCC currently used in 802.11, alternative BCCs are discussed to address this concern. Straw Poll: Do you support to have a BCC for 62.5kb/s mode of the WUR? Y/N/A: 14/21/15 11-17/0660r1, “WUR Security Proposal” (SP only), Yunbo Han/Yunsong Yang Straw Poll: Do you support that a STA may include a reason of its wake-up due to a unicast wake-up packet in a frame that the STA sends to the AP using its PCR, in order to assist the AP in determining whether the STA’s WURx receives a spoofed unicast wake-up packet? Straw Poll deferred to pm1 session. Minyoung declares the meeting to be in recess at 12.30 pm.
of forwarding information Forwarding information for transmitter of PREQ element Forwarding information for originator mesh STA Forwarding information for transmitter of PREP element Forwarding information for target mesh STA HWMP SN Invalid if created, no change if updated PREQ element Originator HWMP Sequence Number Invalid if created, no change if updated PREP element Target HWMP Sequence Number Next hop Transmitter address of the Management frame containing the PREQ element Transmitter address of the Management frame containing the PREQ element Transmitter address of the Management frame containing the PREP element Transmitter address of the Management containing the PREP element Path metric Accumulation of the initial value of the path metric with the metric of the link to the transmitter of the PREQ element Accumulation of the value of PREQ element field Metric with the metric of the link to the transmitter of the PREQ element Accumulation of the initial value of the path metric with the metric of the link to the transmitter of the PREP element Accumulation of the value of PREP element field Metric with the metric of the link to the transmitter of the PREP element Number of hops 1 Value of PREQ element field Hop Count + 1 1 of PREP element field Hop Count + 1 Precursor list No change No change except in case of an intermediate [see 14.10.9.4.3 (Effect of receipt) step f)] No change See 14.10.10.4.3 (Effect of receipt) step d) Lifetime The longer one of the lifetime of the stored forwarding information and the value of PREQ element field Lifetime The longer one of the lifetime of the stored forwarding information and the value of PREQ element field Lifetime The longer one of the lifetime of the stored forwarding information and the value of PREP element field Lifetime The longer one of the lifetime of the stored forwarding information and the value of PREP element field Lifetime
9.4.2.250.2 Beamforming field Change 1st paragraph in [1] as follows The Beamforming Capability field is defined in Figure 23. B0 B4 B5 B6 B7 B8 B9 B10 B11 B15 Requested BRP SC Blocks MU-MIMO Supported Supported SU-MIMO Supported Grant Required Hybrid Beamforming and MU MIMO Supported Hybrid Beamforming and SU MIMO Supported Reserved 5 1 1 1 1 1 5 Figure 22 —Beamforming Capability field format Insert after 6th paragraph in [1] as follows The MU-MIMO supported field and Hybrid Beamforming and MU-MIMO Supported field shall be set to one to indicate that the STA supports the hybrid beamforming protocol during MU-MIMO transmission including the Hybrid beamforming protocol described in 10.38.9.2.5. If the MU-MIMO supported field is set to one, and the Hybrid Beamforming and Supported field is set to zero, then the STA supports analog MU-MIMO beamforming only. The SU-MIMO Supported field and Hybrid Beamforming and SU MIMO Supported field shall be set to one to indicate that the STA supports hybrid beamforming protocol during SU-MIMO transmission including the Hybrid beamforming protocol described in 10.38.9.2.5. If the SU-MIMO supported field is set to one, and the Hybrid Beamforming and SU-MIMO supported field is set to zero, then the STA supports analog SU-MIMO beamforming only. References: Draft P802.11ay_D0.5 802.11-2016
Dorothy to prepare a motion for consideration at the January Interim Session in Irvine. Doc 11-17/1810r0 - Artyom LOMAYEV Review Submission Missing definition of PHYCONFIG VECTOR Queston on what is being proposed to be added. A new sub clause being added would need to be instructed differently. There already existis a 20.3.1, so is the intent to add before or after the existing clause. Suggested wording “insert a new subclause, and renumber the following clauses). This would give the new clause the number to be 20.2.3. Check the order in 20.1 – make the new 20.3 match the order. Insert the following as subclause as 20.2.3 The coloring is not material to the instructions. Discussion on the indexing method proposed. Change the “can” to fixes the concern (in the red text). Range 1-11 is correct, but it should only be the odd numbers Make a cross reference to avoid duplicate definition It seems to be a definition for Channel number being defined here, and not in Annex E, so only one place should have the definition. It would be better to delete “and channel Number” as it is defined a few line later. Question on “at least channel 2”? Channel 2 is the mandatory channel The “at least” is not necessary in the sentence. Shall support Channel 2 is the requirement, the other Channels are optional. Suggest “Shall support Channel 2 and may support other channels as well”. The changes will be made offline and then the revision to be posted to the reflector for consideration. The difference between Channel number and the “Operating Channel” was questioned. New wording can be created, but will need to be done offline. The Channel number is no longer 1-11, it is from 1-6. Labels on the figure may help It does seem confusion the overloading of “Channel Number” Schedule to review on January 5th. GEN Discuss CIDs: 29, 76, 324 CID 29 (GEN) Review comment Proposed Resolution: REVISED (GEN: 2017-12-01 16:11:11Z) - Change sentence to "This type of IEEE 802.11 LAN is often formed without preplanning." Discussion on if the the sentence was accurate. No objection – Mark Ready for Motion CID 76 (GEN) Review comment
Fridays December 1, 15, Jan 5 10am Eastern 2 hours 7-8, Piscataway NJ ad-hoc A meeting reminder and invite will be sent out. review Adjourned at 4:30pm References: Monday 6 November 2017 PM1: Tuesday 7 November 2017 PM1: Wednesday 8 November 2017 – PM1: Wednesday 8 November 2017 – PM2: Thursday 9 November 2017 PM1: Thursday 9 November 2017 PM2:
– • IEEE 802 Working Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Chair's Guidelines (Approved 17 Mar 2017) – as updated in • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 17 Mar 2017) – September 29th telecon: Editor Report: Submissions:
• Antitrust and Competition Policy – • IEEE-SA Patent Policy – – – – • IEEE 802 Working Group Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Chair's Guidelines (Approved 17 Mar 2017) – as updated in • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 17 Mar 2017) – September 29th telecon: Editor Report: Submissions: October 6, 2017 telecon:
IDFT, and GI insertion blocks. The PPDU encoding uses the seed value defined in the EDMG-Header-B and has independent flow per user. However, transmitter keeps the common space-time streams numeration over all users. If STBC encoder is applied, then a single spatial stream is mapped to two space-time streams as defined in 30.6.7.1. The NSTS space-time streams are further mapped to NTX transmit chains, where NSTS ≤ NTX. Figure 2: Transmitter block diagram for EDMG portion of MU PPDU transmission. NOTE – Interleaver is applied to 16-QAM and 64-QAM modulations only. 30.6.8 OFDM PPDU transmission Editor: add new subclause 30.6.8, shift the rest of the clauses by one 30.6.8.1 General This subclause defines a waveform for OFDM EDMG PPDU transmission over 2.16 GHz, 4.32 GHz, 6.48 GHz, and 8.64 GHz channel using NTX transmit chains. The spatial mapping methods definition is provided in 30.6.8.2. The EDMG SU PPDU transmission shall be as defined in 30.6.8.3. The EDMG MU PPDU transmission shall be as defined in 30.6.8.4. The frequently used symbol notations in this subclause are summarized in Table 1. Table 1: Frequently used parameters Symbol Explanation Space-time stream number Total number of space-time streams over all users User number Total number of users Transmit number Total number of transmit chains SC chip rate, equal to 1.76 GHz SC chip time duration, equal to 1/Fc OFDM sampling rate equal to NCB×2.64 GHz OFDM sample time duration, equal to 1/Fs Number of contiguous 2.16 GHz channels used for PPDU transmission, 1 ≤ NCB ≤ 4 Spatial mapping matrix of size NTX by NSTS, defined for k-th subcarrier Up-sampling parameter 30.6.8.2 Spatial mapping
These are substantially similar to current installations for lighting and the market forces are driving demand independent of LC, in particular for Power over Ethernet solutions suitable for smart buildings. d) Consideration of operational costs (e.g., energy consumption). The added energy cost to support LC is minimal since the energy that is used for illumination may also be used to provide wireless communications. LEDs are being used for illumination and communications, removing constraints on the transmit power for the downlink. Using LC for uplink can be more power consuming. However, as discussed above in “how does uplink of LC-systems work”, when power consumption is an issue, the uplink could use infrared radiation or RF for uplink with similar level of power consumption as current 802.11 devices. e) Other areas, as appropriate. The light spectrum (100 nm – 10000 nm) is already considred licensed-exempt by some government regulators and falls outside of the remit of most other government regulators including outside of the regulatory authorities in Australia, Canada, China, India, Japan, Europe, South Korea and the USA. References: Nikola Serafimovski, Christophe Jurczak, “IEEE 802.11-17/0803r1 Economic Considerations for Light Communications” Global Market Insights, “Li-Fi Market size forecast $75.5 billion by 2023”, available at
Contact Information for Working Group ChairName: Adrian Stephens Email Address: adrian.p.stephens@ieee.org Phone: +44 (1793) 404825 Contact Information for Working Group Vice-Chair Name: Jon Rosdahl Email Address: jrosdahl@ieee.org Phone: +1-801-492-4023 3.2 Sponsoring Society and Committee: IEEE Computer Society/LAN/MAN Standards Committee (C/LM) Contact Information for Sponsor Chair Name: Paul Nikolich Email Address: p.nikolich@ieee.org Phone: +1-857.205.0050 Contact Information for Standards Representative Name: James Gilb Email Address: gilb@ieee.org Phone: +1-858-229-4822 4.1 Type of Ballot: Individual 4.2 Expected Date of submission of draft to the IEEE-SA for Initial Sponsor Ballot: November 2020 4.3 Projected Completion Date for Submittal to RevCom: July 2021 5.1 Approximate number of people expected to be actively involved in the development of this project: 50. 5.2.a. Scope of the complete standard: The scope of this standard is to define one medium access control (MAC) and several physical layer (PHY) specifications for wireless connectivity for fixed, portable, and moving stations (STAs) within a local area. 5.2.b. Scope of the project: This amendment defines a physical (PHY) layer specification and modifications to the medium access control (MAC) layer specification that enables operation of light communications (LC). TBD The MAC and PHY specified in this amendment: • Enable operations in [TBD] nm to [TBD] nm band • Enables a maximum throughput of at least [TBD] Gbps, as measured at the MAC data service access point (SAP) • Enables fast session transfer between LC PHY(s) and based PHYs • Maintains the 802.11 user experience