zilongwang/ReadingBank huggingface dataset:
CID Commenter Clause Page (C) Line (C) Type of Comment Assignee Comment Proposed Change 1280 Stephen McCann 8.4.4.21 14 23 T Stephen McCann, SK Yong What does the "Service Information Query Response" sub-field provide as extra service information, that is not already present in the "Basic Service Information Descriptor field "? Create some text defines what the "Service Information Response" sub-field is. Proposed resolution: Rejected The Basic Service Information Descriptors sub-field is defined in 8.4.2.172, which consists of Advertisment ID, Service Name and Service Status. The basic service information is to provide only a minimal but essential service information for device to make an informed decision to connect or to query for more information. CID Commenter Clause Page (C) Line (C) Type of Comment Assignee Comment Proposed Change 1336 Yongho Seok 8.4.4.21 14 3 T Stephen McCann, SK Yong "The Service Information Response ANQP-element is included in a GAS Query Response, sent by the AP to the non-AP STA." In Table 10-16 - ANQP usage, the STA side usage of the Service Information Response is described as "T, R". Which one is correct? If "T,R" is correct, the Service Information Response ANQP-element can be also sent by the non-AP STA to the AP. Please address this confliction. Proposed resolution: Revised Update the Table 10-16 as follows Service Information Response 8.4.4.21 (Service Information Response ANQP- element) S T R — CID Commenter Clause Page (C) Line (C) Type of Comment Assignee Comment Proposed Change 1347 Lei Wang 8.4.4.21 14 16 T Stephen McCann, SK Yong what's the unit of the field "Service Information Query Response Length"? Do we really need a 2-byte lenth field, which gives 64K values? please clarify. Particularly, to check if we can reduce the length field to 1 byte. Proposed resolution: Rejected Yes. Service information can go beyond 256 and thus 2-bytes length field is needed.
8.3.3.10 Probe Response frame format Table 8-42—Probe Response frame body Order Information Notes <ANA> Estimated Service Parameters The Estimated Service Parameters element is optionally present if dot11EstimatedServiceParametersOptionImplemented is true. TGmc editor: replace the row with value “Last” in the order column in the table of Probe Response frame body components, Table 8-42 Probe Response frame body, as shown: Order Information Notes Last Requested elements Elements requested by the Request element of the Probe Request frame are present if dot11MultiDomainCapabilityActivated or dot11EstimatedServiceParametersOptionImplemented is true. See 10.1.4.3.2 (Active scanning procedure for a STA) and 10.44a (Estimated throughput). TGmc editor: add one row to the of elements, Table 8-85 Element IDs as shown: 8.4.2.1 General Table 8-85—Element IDs Element Element ID Extensible Estimated service parameters (see 8.4.2.170m Estimated service parameters element) <ANA> Yes TGmc editor: add the following new element with appropriate subclause numbering: 8.4.2.170m Estimated service parameters (ESP) element The Estimated Service Parameters element is used by a STA to provide information to another STA can then use the information as input to an algorithm to generate an estimate of throughput between the two STAs.
Table 8-240bb—Setting of the Supported Channel Width Set subfield and Extended NSS BW Support subfield at a STA transmitting the VHT Capabilities Info field Supported Channel Width Set Extended NSS BW Support Meaning 0 0 Transmitting STA (See NOTE 1) supports 20, 40, and 80 MHz PPDUs at Max VHT NSS – See NOTE 2. Transmitting STA does not support 160 MHz PPDUs and transmitting STA does not support 80+80 MHz PPDUs. 0 1 Transmitting STA supports 20, 40, and 80 MHz PPDUs at Max VHT NSS. Transmitting STA supports 160 MHz PPDUs at half Max VHT NSS. See NOTE 3. Transmitting STA does not support 80+80 MHz PPDUs. 0 2 Transmitting STA supports 20, 40, and 80 MHz PPDUs at Max VHT NSS. Transmitting STA supports 160 MHz and 80+80 MHz PPDUs at half Max VHT NSS. 0 3 Reserved 1 0 Transmitting STA supports 20, 40, 80, and 160 MHz PPDUs at Max VHT NSS. Transmitting STA does not support 80+80 MHz PPDUs. 1 1 Reserved 1 2 Transmitting STA supports 20, 40, 80, and 160 MHz PPDUs at Max VHT NSS. Transmitting STA supports 80+80 MHz PPDUs at half Max VHT NSS. 1 3 Transmitting STA supports 20, 40, 80, and 160 MHz PPDUs at 2xMax VHT NSS. Transmitting STA supports 80+80 MHz PPDUs at Max VHT NSS. 2 0 Transmitting STA supports 20, 40, 80, 160, and 80+80 MHz at Max VHT NSS. 2 1 Reserved 2 2 Reserved 2 3 Transmitting STA supports 20, 40, and 80 at 2xMax VHT NSS. Transmitting STA supports 160 MHz and 80+80 MHz PPDUs at Max VHT NSS. 3 0 Reserved 3 1 Reserved 3 2 Reserved 3 3 Reserved NOTE 1 – A transmitting STA refers to the STA transmitting the Supported Channel Width Set and Extended NSS BW Support bits of the VHT Capabilities Info field. NOTE 2 – Max VHT NSS is defined per MCS in 8.4.2.157.3 (Supported VHT-MCS and NSS Set field) NOTE 3 – Half Max VHT NSS is equal to one half of Max VHT NSS rounded down to the nearest integer.
2 3 Transmitting STA supports 20, 40, and 80 PPDUs at twice Max VHT NSS. Transmitting STA supports 160 MHz and 80+80 MHz PPDUs at Max VHT NSS. 3 0 Reserved 3 1 Reserved 3 2 Reserved 3 3 Reserved NOTE 1 – A transmitting STA refers to the STA transmitting the Supported Channel Set and Extended NSS BW Support bits of the VHT Capabilities Info field. NOTE 2 – Max VHT NSS is defined per MCS in 8.4.2.157.3 (Supported VHT-MCS and NSS Set field) NOTE 3 – Half Max VHT NSS is equal to one half of Max VHT NSS rounded down to the nearest integer. NOTE 4 – Three fourths Max VHT NSS is equal to three fourths of Max VHT NSS rounded down to the nearest integer. 8.4.2.157.3 Supported VHT-MCS and NSS Set field TGmc editor: change the reserved bit B61 of Figure 8-557 Supported VHT-MCS and NSS Set field to “VHT Extended NSS BW Capable”. B0 B15 B16 B28 B29 B31 B32 B47 B48 B60 B6 B63 Rx Map Rx Highest Supported Long GI Data Rate Reserved Tx Map Tx Highest Supported Long GI Data Rate Reserved Bits: 16 13 3 16 13 1 TGmc editor: modify some of the text in subclause 8.4.2.157.3 Supported VHT-MCS and NSS Set field, as shown, including the addition of a new row in Table 8-241 – Supported and NSS Set subfields: The Supported VHT-MCS and NSS Set subfields are defined in Table 8-241 (Supported VHT-MCS and NSS Set subfields). Table 8-241—Supported VHT-MCS and NSS Set subfields Subfield Definition Encoding Rx VHT-MCS Map Indicates the maximum of the RXVECTOR parameter MCS of a PPDU that can be received at all channel widths supported by this The format and encoding of this subfield are defined in Figure 8-556 (Rx VHT-MCS Map and Tx VHT-MCS Map subfields and Basic VHT-MCS
Hao Wang Fujitsu Research & Development Center Voting Member 100 Sha Wei CESI Group Aspirant Member 100 Zou Wei-Xia Beijing University of Posts and Telecommunications (BUPT) Voting Member 100 Weimin Xing ZTE Corporation Voting Member 100 XIAOWU ZHAO ZTE Aspirant Member 67 Appendix B: Group Photo of 802.11/TGaj China Interim session attendees – 19-20 May 2015
IEEE P802.11 Wireless LANs Some 11mc comment resolutions (Initial Sponsor Ballot) Date: 2015-06-10 Author(s): Name Affiliation Address Phone email Sigurd Schelstraete Quantenna Communications 3450 W. Warren Ave Fremont, CA 94538 Dorothy Stanley HP (Aruba Networks) 1322 Crossman Ave Sunnyvale, CA +1 630-363-1389 CIDs 5867, 5873 - MAC 5867 595.61 8.3.1.2 "The TA field is the address of the STA transmitting the RTS frame or a bandwidth signaling TA" should be more specific. It's not just any signaling TA, but the specific signaling TA that is obtained by setting the Individual/Group bit of the address of the transmitting STA to one. Suggested wording: "The TA field is the address of the STA transmitting the RTS frame or the bandwidth signaling TA that is obtained by setting the Individual/Group bit in that address to one" 5873 611.56 8.3.1.20 "The TA field is set to the address of the STA transmitting the VHT NDP announcement frame or a bandwidth signaling TA" should be more specific. It's not just any signaling TA, but the specific signaling TA that is obtained by setting the Individual/Group bit of the address of the transmitting STA to one. Suggested wording: "The TA field is set to the address of the STA transmitting the VHT NDP announcement frame or the bandwidth signaling TA that is obtained by setting the Individual/Group bit in that address to one" The text is seen in context below: And at 611.56: The cited text is:
5878 1039.41 8.4.2.157.2 "Maximum MPDU Length" is defined as indicating the maximum MPDU length. It is not clear whether this is a transmit or a receive requirement. For interoperability reasons only receive capability needs to be indicated, so I assume this is receive capability. Clarify Proposed resolution: Revised At 1039.41 in the “Definition” column, first row, change as indicated below: Indicates the maximum MPDU length(see 9.12 (A-MSDU operation)). References:
2250 171 9.20.5.1 The RAW assignment in RPS element is transmitted to STAs in broadcast message, in unlicensed band environment, then, even with the most robust MCS, there is still no guarantee the broadcast message will be correctly delievered, e.g., collision or interference with other RATs. Then, what happens if some of the intended STAs do not receive the broadcast message? Does it mean the allocated resources to those STAs will be wasted? and those STAs will contend for the channel access as without RAW operation? please clarify. Revised- Please see the discussion shown in 11-14- under the heading for CID 2250, 2251. TGah editor to make changes shown in 11-14- under the heading for CID 2250, 2251. 2251 172 9.20.5.1 some fundamental questions about RAW: assign time slot to STAs; and STAs can content for channel access in the assigned time slot; how about the STAs does not support RAW, can they content too? What happens if the AP receives a packet from a STA who transmitted in a slot not assigned to him? please clarify. Revised- Please see the discussion shown in 11-14- under the heading for CID 2250, 2251. TGah editor to make changes shown in 11-14- under the heading for CID 2250, 2251. 2465 171 9.20.5.1 "Assigning restricted uplink channel access windows to different groups of STA increases fairness." -- why? Efficiency I can see, but fairness is not clear to me Add some justification, or delete Accepted- Agree in principle. The basic motion of the RAW is not related with the fairness. So, remove that sentence. 2466 172 9.20.5.1 Surely S1G STAs are required to use EDCA, not DCF? Ditto 174.52 Delete "DCF or" Revised- Agree in principle. See the proposed change from CID 1210. 2467 172 9.20.5.1 "sensor STA", "sensor S1G STA" (also at 210.34) "Sensor type STA" (5 instances in total) Accepted- Agree with the comment.
IEEE P802.11 Wireless LANs Some 11mc comment resolutions (Initial Sponsor Ballot) Date: 2015-06-16 Author(s): Name Affiliation Address email Sigurd Schelstraete Quantenna Communications 3450 W. Warren Ave Fremont, CA 94538 Dorothy Stanley HP Networks) 1322 Crossman Ave Sunnyvale, CA 94089 +1 630-363-1389 CIDs 5867, 5873 - MAC 5867 595.61 8.3.1.2 "The TA field is the address of the STA transmitting the RTS frame or a bandwidth signaling TA" should be more specific. It's not just any signaling TA, but the specific signaling TA that is obtained by setting the Individual/Group bit of the address of the transmitting STA to one. Suggested wording: "The TA field is the address of the STA transmitting the RTS frame or the bandwidth signaling TA that is obtained by setting the Individual/Group bit in that address to one" 5873 611.56 8.3.1.20 "The TA field is set to the address of the STA transmitting the VHT NDP announcement frame or a bandwidth signaling TA" should be more specific. It's not just any signaling TA, but the specific signaling TA that is obtained by setting the Individual/Group bit of the address of the transmitting STA to one. Suggested wording: "The TA field is set to the address of the STA transmitting the VHT NDP announcement frame or the bandwidth signaling TA that is obtained by setting the Individual/Group bit in that address to one" The cited text is seen in context below: And at 611.56: The cited text is:
Proposed resolution: Revised Change the text at the location as shown below to insert reference: The transmission duration of an A-PPDU shall be no greater than aPPDUMaxTime. CID 5893, 5136, 6449 - MAC 5893 1323.61 9.22.2.1 The sentence refers to "reason c), d) or e) above ". There is no e) in the bullet list on lines 19-35. Is anything missing here? Clarify 5136 1323.37 9.22.2.2 This para should be part of the previous list Change this para to become list item e) of the previous para. 6449 1323.37 9.22.2.2 This sentence does not make sense on its own Make it an item e) at the end of the list immediately above it The cited text is below: Proposed resolution to all 3 CIDs: Revised Make the paragraph at 1323L37 into bullet e) of the list that starts at line 20. CID 5894 - MAC 5894 1329.14 9.22.2.7 The words "followed after SIFS by a PPDU containing one or more VHT Compressed Beamforming frames" belong with the second sub-bullet Second sub-bullet should be: "a Beamforming Report Poll frame followed after SIFS by a PPDU containing one or more VHT Compressed Beamforming frames" The cited text is below: Proposed resolution: Revised The words “followed after SIFS by a PPDU containing one or more VHT Compressed Beamforming frames” apply to both sub-bullets. The formatting is somewhat confusing though. Proposed to make this more explicit by duplicating for each bullet. Modify the text as follows: Either
The TA field is the address of the STA transmitting the RTS frame or a bandwidth signaling TA. And The TA field is set to the address of the STA transmitting the VHT NDP Announcement frame or a bandwidth signaling TA. The commenter’s proposed change is: The TA field is the address of the STA transmitting the RTS frame or bandwidth signaling TA. The TA field is set to the address of the STA transmitting the VHT NDP Announcement frame . Proposed resolution: Revised Change the text as shown below: At 591.61: The TA field is the address of the STA transmitting the RTS frame or bandwidth signaling TA of the. At 611.56: The TA field is set to the address of the STA transmitting the VHT NDP Announcement frame or bandwidth signaling TA. CID 5869 - MAC 5869 603.29 8.3.1.9.1 Paragraph mentions "four possible BlockAck frame variants". Table 8-24 shows five. Replace "four" with "five" The Cited text is below: The commenter’s proposed change is below: The values of the Multi-TID, Compressed Bitmap, and GCR subfields of the BA Control field determine which of possible BlockAck frame variants is represented, as indicated in the Table 8-24 (BlockAck frame variant encoding). Discussion: There are indeed 5: Basic, Compressed, Extended Compressed, Milti-TID, GCR Proposed resolution: The values of the Multi-TID, Compressed Bitmap, and GCR subfields of the BA Control field determine which of possible BlockAck frame variants is represented, as indicated in the Table 8-24 (BlockAck frame variant encoding). CIDs 5871, 5872 (MAC)
ANQP-element Name ANQP-element (subclause)(Ed) Type AP Non-AP STA STA Query List 8.4.5.2 (Query List Q T, R T, R T, R Capability List 8.4.5.3 (Capability List ANQP-element) S T, R T, R T, R Venue Name 8.4.5.4 Name S T R — Emergency Call Number 8.4.5.5 (Emergency Call Number ANQP-element) S T R — Network Authentication Type 8.4.5.6 (Network Authentication Type S T R — Roaming Consortium 8.4.5.7 (Roaming Consortium ANQP- S T R — Vendor Specific 8.4.5.8 (Vendor Specific Q, S T, R T, R T, R IP Address Type Availability 8.4.5.9 (IP Address Type Availability ANQP-element) S T, R T, R T, R NAI Realm 8.4.5.10 (NAI Realm S T R T, R 3GPP Cellular Network 8.4.5.11 (3GPP Cellular Network ANQP-element) S T R — AP Geospatial Location 8.4.5.12 (AP Geospatial Location ANQP-element) S T R T, R
IEEE P802.11 Wireless LANs Resolutions for some comments on 11mc/D4.0 Date: 2015-0- Author(s): Name Affiliation Address Phone email Mark RISON Samsung Cambridge Solution Centre SJH, CB4 0DS, U.K. +44 1223 434600 at samsung (a global commercial entity) I'm the letter emme then dot rison Identifiers Comment Proposed change CID 6562 Mark The exception for the PM bit in Probe Responses sent in response to unicast Probe Requests in an IBSS makes no sense Get rid of this special case (in 3.2, 8.2.4.1.7 and 10.2.2.4) CID 6563 Mark 10 1529 Lots of things are ambiguous/unclear in relation to power-saving signalling and mechanisms I will propose text (not possible to give here) CID 6075 Mark Hamilton 8.2.4.1.7 566.52 The details of when the PM subfield is valid are still a bit murky. (This is a follow-on comment to changes already made which improved things, but left a bit of work to do.) Also, PM should be discussed as a field/subfield, not a "bit". A submission will be made by Mark Hamilton with specific proposed changes. Discussion: [Work in progress!] 1) IBSS issue 1 10.2.3.4 [IBSS] STA state transitions says: A STA shall set the Power Management subfield in the Frame Control field of frames containing all or part of a BU or individually addressed Probe Request frame that it transmits using the rules in 8.2.4.1.7 (Power Management field). 8.2.4.1.7 says: In an IBSS, the Power Management field is valid only in frame exchanges as described in 10.2.3.4 (STA power state transitions). This is circular. 2) IBSS issue 2 10.2.3.5 ATIM frame and frame transmission says:
Identifiers Comment Proposed change Discussion: Proposed changes: Proposed resolution: Another missing “ignorethe”; “AVHT”; “IETFRFC”; “setthe”; “bit1”; “tuplesbetween” (several), “TDLS_UNSPECIFIED_REASONexcept”, “STAcan”, “STAswitches”. Font size wacko: 1265.8 “RR5”, 513.53: “6.4.3 Convergence function state list”, 1720.6 “nonprimary”, 564.33 “DMG Beacon” (whole line). Hyphen should be minus: “EIFS-” on e.g. page 1252 Number and its unit split because not NBSP in 17.3.6.8 (“25 µs”) and 10.1.3.9 (“±40 ppm”) and 2200.56 (“1 Mb/s”). References:
Change “An individually addressed Response frame that is sent in an IBSS in response to an individually addressed Probe Request frame” to “An individually addressed MMPDU that is carried in one or more Probe Response frames and that is sent in an IBSS in response to an individually addressed Probe Request frame” at 1548.33. Change “All other Management frames” to “All other MMPDUs” at 1548.37. Change “Data and bufferable Management frames” to “BUs” at 1551.59. The More Data bit of thean individually Addressed Data or bufferable Management frameMPDU containing all or part of a BU, using a delivery-enabled ACs and destined for that STAindicates that more BUs are buffered for the delivery-enabled ACs. The More Data bit equal to 1 in an individually addressed Data or bufferable Management framesMPDU containing all or part of a BU, using a nondelivery-enabled ACs and destined for that STA indicates that more BUs are buffered for the nondelivery-enabled ACs. Change “an individually addressed Data or bufferable Management frame” to “an individually addressed MPDU containing all or part of a BU” at 1557.29. Change “the received Data or bufferable Management frame” to “the MPDU(s) containing the BU” at 1559.40 (in STA during CP). Change “the last Data or bufferable Management frame” to “the last MPDU containing all or part of the BU” at 1560.36 (in STA during CFP). Change 1560.56 (in STA APSD) as follows: The STA may send additional PS-Poll frames if the More Data subfield is 1 in a downlink individually addressed Data or bufferable Management framesMPDU containing all or part of a BU, that does not use any delivery-enabled ACs. The STA may send additional trigger frames if the More Data subfield is 1 in a downlink individually addressed Data or bufferable Management framesMPDU containing all or part of a BU, that uses a delivery-enabled ACs.
Identifiers Comment Proposed change Discussion: Proposed changes: Proposed resolution: Another missing space: “ignorethe”; “AVHT”; “IETFRFC”; “setthe”; “bit1”; “tuplesbetween” (several), “TDLS_UNSPECIFIED_REASONexcept”, “STAcan”, “STAswitches”. Font size wacko: 1265.8 “RR5”, 513.53: “6.4.3 Convergence function state list”, 1720.6 “nonprimary”, 564.33 “DMG Beacon” (whole line). Hyphen should be minus: “EIFS-” on e.g. page 1252 Number and its unit split because not NBSP in 17.3.6.8 (“25 µs”) and 10.1.3.9 (“±40 ppm”) and 2200.56 (“1 Mb/s”). References:
Proposed resolution: Another missing space: “ignorethe”; “AVHT”; “IETFRFC”; “setthe”; “bit1”; “tuplesbetween” (several), “TDLS_UNSPECIFIED_REASONexcept”, “STAcan”, “STAswitches”, “Scheduleelement”, “STAmay” (>=2x), “microseconds))is”. Font size wacko: 1265.8 “RR5”, 513.53: “6.4.3 Convergence function state list”, 1720.6 “nonprimary”, 564.33 “DMG Beacon” (whole line), 938.46: “subelement”, 2297.46 “or Clause 19 (Extended Rate PHY (ERP) specification) operation.”. Hyphen should be minus: “EIFS-” on e.g. page 1252 Number and its unit split because not NBSP in 17.3.6.8 (“25 µs”) and 10.1.3.9 (“±40 ppm”) and 2200.56 (“1 Mb/s”). References: 802.11mc/D4.0
IEEE P802.11 Wireless LANs LB 200 cluase 9.20.5.5 comment resolution Date: 2014-02-26 Author(s): Name Affiliation Address email Yongho Seok LG Electronics 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 TGah Draft. This introduction is not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGah Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents). TGah Editor: Editing instructions preceded by “TGah Editor” are instructions to the TGah editor to modify existing material in the TGah draft. As a result of adopting the changes, the TGah editor will execute the instructions rather than copy them to the TGah Draft. CID Page Clause Comment Proposed Change Resolution 1351 174.54 9.20.5.5 It is mentioned that the first backoff is restored when RAW finishes. But what happens to the second backoff state when the the RAW finishes; Is it going to be restored in the next allowed RAW? Clarify what happens to the second backoff when RAW ends. It seems it'd be fair to keep the second backoff value and restore it in the next occurance of the assigned RAW. Revised- See the discussion shown in 11-14-0235r0 under the heading for CID 1351, 1353. TGah editor to make changes shown in under the heading for CID 1351, 1353. 1352 174.54 9.20.5.5 The first and second backoff are used with upper/lower case letters in this and subsequent paragraphs (e.g. L54 with captalized letters). Use either Backoff or first/second backoff throught the spec. Revised- Agree in principle. Change the Backoff to the first/second backoff (lower case).
Change == to = at 1542.8, 1542.11, 1542.12. At 1232.13, delete “C7 == B16”. Change = to == at 1880.62, 1880.65, 1881.42, 1881.46, 1883.22. Change != to ≠ at 1733.19, 3566.17. Change <> to ≠ at 1514.8, 1514.35, 1820.1, 2183.25, 2183.30, 2185.26, 2212.21, 2271.22. Proposed resolution: REVISED Make the changes shown under “Proposed changes” for CID 6582 in <this document>, which use proper glyphs for ==, !=/<>, >=, <= where not in ASCII text and where not in Boolean contexts. Identifiers Comment Proposed change CID 6661 Mark RISON "attribute values" in the context of PHY characteristics should be "characteristics". As it says in the comment Discussion: It seems reasonable to assert that something describing characteristics, in a subclause about characteristics or carried in a CHARACTERISTICS primitive, should be called a characteristic. For MAC characteristics as well as PHY characteristics, in fact. Proposed resolution: REVISED Change “attribute values” to “characteristics” at 1275.55. Change “sublayer attribute” to “characteristic” at 1840.1, 1840.8. Identifiers Comment Proposed change CID 6754 Mark RISON Table 9-17 should be moved to clause 8, somewhere near Table 8-34 [these might be D3.0 references] As it says in the comment Discussion: The table which needs moving is Table 9-17 Valid address field usage for Mesh Data and Multihop Action frames. This is a table showing frame formats. It should be in Clause 8, not Clause 9. It is very similar to Table 8-26 Address field contents. Proposed resolution: REVISED
Proposed changes: Proposed resolution: Another missing space: “ignorethe”; “AVHT”; “IETFRFC”; “setthe”; “bit1”; “tuplesbetween” (several), “TDLS_UNSPECIFIED_REASONexcept”, “STAcan”, “STAswitches”, “Scheduleelement”, “STAmay” (>=2x), “microseconds))is”. Font size wacko: 1265.8 “RR5”, 513.53: “6.4.3 Convergence function state list”, 1720.6 “nonprimary”, 564.33 “DMG Beacon” (whole line), 938.46: “subelement”, 2297.46 “or Clause 19 (Extended Rate PHY (ERP) specification) operation.”, 880:51: “Tx STBC”. Hyphen should be minus: “EIFS-” on e.g. page 1252 Number and its unit split because not NBSP in 17.3.6.8 (“25 µs”) and 10.1.3.9 (“±40 ppm”) and 2200.56 (“1 Mb/s”). References: 802.11mc/D4.0
Table 8-xyz False Positive Probability Range field values Values of Bits B0~B3 False positive probability range, p 0 p > 25% 20% < p ≤ 25% 2 15% < p ≤ 20% 3 10% < p ≤ 15% 4 5% < p ≤ 10% 5 1% < p ≤ 5% 6 0.5% < p ≤ 1% 7 0.1% < p ≤ 0.5 % 8 0.05% < p ≤ 0.1 % 9 0.01% < p ≤ 0.1 % 10 p ≤ 0.01% 11:15 Reserved The Number of Hash Functions is set to a value equal to k-1, where k is the number of hash functions (out of the maximum of 16) used by the Bloom filter as described 10.25.3.4.4. The Bloom Filter Bit Array field is a variable-length field that provides an indication about the services offered by the AP with a target probability of false positive, p. The maximum length of the Bloom Filter Bit Array field is 128 octets. Each service hash X is mapped to k bit positions that are calculated using the function H(j,X,m) where j = 0,…,k-1 as given 10.25.3.4.4. For more information on the determination of the length of the Bloom Filter Bit Array field for a given false positive probability and the number of services supported see Annex
IEEE P802.11 Wireless LANs MLME-AUTHENTICATE text proposal for TGai Date: 2015-07-05 Author(s): Name Company Address Phone Mark Hamilton Ruckus Wireless 350 W. Java Drive Sunnyvale, CA 94089 +1 303 818 8472 CID 6155 8026 21.32 6.3.5.5 CID 7144 (on the last ballot) was apparently too confusing. The intent of the comment was: The MLME-AUTHENTICATE service to have changes to the .indication primitive. There are new parameters in the (and carried in the Authenticate frames): FILSWrappedData and PMKIDList. So, the primitive needs to be modified by 11ai to add these parameters in the indication to the AP's SME, to complete the transfer of the information to the AP, at Authentication request. Add a clause that modifies the MLME-AUTHENTICATE.indication primitive, to add the FLISWrappedData and PMKIDListt parameters. Discussion: TGai modifies the MLME-AUTHENTICATE.request primitive, to add two new parameters: FILSWrappedData and PMKIDList. Per Table 8-36, the elements derived from these parameters are carried in the Authentication frame with transaction sequence number 1, which is transmitted by the Authentication requester. Finally, 11.11.2.3 discusses how the receiving AP processes and uses the FILS Wrapped Data and the PMKID List that are received in the Authentication frame. Thus, these parameters need to be provided in the MLME-AUTHENTICATE.indication at the AP. Proposed changes: Insert the following subclause changes, after 6.3.5.3: 6.3.5.4 MLME-AUTHENTICATE.indication 6.3.5.4.2 Semantics of the service primitive Change the primitive parameter list and insert new rows (ignoring the header row) in the associated table
239 6.33 4.3.23.3 "Reasons for such selective reception include the MAC service requirement that, when an MSDU is sent, it is not returned to and processed by the transmitting station." It is not clear to me in what situation is assumed here. In the IEEE 802.11-2012 clause 9.3.6, the transmission procedure of group address frames is specified which is not consistent with the above text. Please clarify what situation is assumed here. Revise: “Reasons for such selective reception include the MAC service requirement that, when an MSDU is sent, it is not returned to and processed by the transmitting station” -> “The reason for such selective reception is to support requirements of 802.1Q bridges, and can include the MAC service requirement that, when an MSDU is sent, it is not subsequently received and processed by the transmitting station”. Commentor can review 11-12/1441r1 for discussions. 258 6.33 4.3.23.3 "Reasons for such selective reception include the MAC service requirement that, when an MSDU is sent, it is not returned to and processed by the transmitting station." Its situation should be clarified. It is not clear if the transmission procedure of group address frames specified in the IEEE clause 9.3.6 is included in the above explanation. Please explain clearly what situation is assumed here. Reject: Dup CID239 295 8.19 4.3.23.4.3 The subset of STAs to received a group addressed is not arbitrary, it's a specifc subset as defined in the SYNRA. Change "an arbitrary" to "a specific". Revise: “the GLK AP be able to transmit them so that they are accepted by an arbitrary subset of the associated GLK STAs” -> “the GLK AP must be willing to transmit MSDUs so that they are accepted by an arbitrary subset of the associated GLK STAs, as provided by the 802.1Q bridge”.
401 54.17 9.24.10.3 "A-MSDUs with RA field set to the SYNRA": the RA field doesn't exist in the A-MSDUs. Replace "A-MSDUs with RA field set to the SYNRA" with "A-MSDUs whose MPDU RA field values are the SYNRA". 223 54.23 9.42 Support for 3 modes are overly complicated, and will tend to be a barrier to adoption. Especially when AMSDU deaggregation is handled in HW. Recommend making these optional, or only mandatory fitting in base 48 bit SYNRA w/o extension. If support is not indicated by Clients at association, then AP can reject Clients without required support options or replicate as unicast. Instead call out that unsupported SYNRA types must be dropped by receiver. Revise: Section rewritten in D1.3 with only 1 type that fits in 48 bits. 254 54.34 9.42 Sentence doesn't belong here. Delete "The structure of the SYNRA address, which includes a 2-bit SYNRA Type field and a 22-bit SYNRA Control field, is shown in Figure 8-52a (SYNRA structure)." Revise: Sections rewritten in D1.3. 426 54.34 9.42 The structure of SYNRA related fields shall be specified in clause 8, not in clause 9. Create a new subclause 8.3.2.1.3´╝êSYNRA field) by moving corresponding contents from 8.3.2.1.2 and 9.42. Revise: Sections rewritten in D1.3. 87 54.37 "the Control field consists of an E/I subfield, an AID offset subfield, and an AD bitmap subfield." -- figures are definitive. There is nothing to be gained from attempting to describe the format also in words. Replace by "defined in figure 9-91". Move the figure to occur before the field descriptions. Make similar changes to the other SNRA Types. Revise: Also change “The E/I subfield is a single bit indicating” -> “The E/I subfield indicates”. Editor to make consistant changes throught section.
MAC Motion #17: Do you support to add the following to the SFD: DL/UL can multiplex different type of unicast frames spatial domain Type of frame can be data frame/control frame/management frame Different type of frames are to/from different users by David Xun Yang, Seconded by Simone Merlin. Discussion – No discussion. Result: Motion accepted with no objection. Recess @ 15:27 until PM2 today. Thursday, July 16th 2015, PM2 Session (16:00 - 18:00) The meeting called to order by Osama Aboul-Magd (Huawei Technologies), the chair of TGax, @13:30. Agenda 11-15/0735r4 is on the server. Rev 5 is working document. There were 150+ people in the room. Administrative Items reminded the IEEE 802 and IEEE 802.11 P&P. asked people to state name and affiliation when addressing for the first time in the session. Attendance! Remaining TG Motions MAC Motions MAC Motion #18: Move to add the following to the IEEE 802.11 TGax Specification Framework: The amendment shall define a HE STA to be a QMF STA. by Guido R. Hiertz, Seconded by Filip Mestanov Discussion Commenter is not sure now is the right moment to make something mandatory. Against: Need more time to discuss. It is too early to assume something mandatory at this stage. Another member also asked for deferral of this motion. Result: Y/N/A = 11/21/40, motion fails. MAC Motion #19: Move to add to TGax SFD: The spec shall define a new control frame format that carries sufficient information to identify the STAs transmitting the UL MU PPDUs and allocating resources for the UL MU PPDUs. The format is as in figure
Venue Name 8.4.5.4 (Venue Name ANQP-element ) S T R — 0 Emergency Call Number 8.4.5.5 (Emergency Call Number ) S T R — 0 Network Authentication Type 8.4.5.6 (Network Authentication Type ANQP-element) S T R — 0 Roaming Consortium 8.4.5.7 (Roaming Consortium ANQP- element) S T R — 0 Vendor Specific 8.4.5.8 (Vendor Specific Q, S T, R T, R T, R 0 IP Address Type Availability 8.4.5.9 (IP Address Type Availability ANQP-element ) S T, R T, R T, R 0 NAI Realm 8.4.5.10 (NAI Realm ANQP-element) S T R T, R 0 3GPP Cellular Network 8.4.5.11 (3GPP Cellular Network ANQP-element) S T R — 0 AP Geospatial Location 8.4.5.12 (AP Geospatial Location ANQP-element) S T R T, R 0 AP Civic Location 8.4.5.13 (AP Civic Location S T R T, R 0 (#13006)AP Location Public Identifier URI 8.4.5.14 (AP Location Public Identifier URI ANQP-element) S T R T, R 0 Domain Name 8.4.5.15 (Domain Name S T R — 0
Revision History Rev 0: Initial revision Rev 1: PSIM renamed to UPSIM (unscheduled power save indication map) UPSIM limited to unscheduled power save mode Included tables where UPSIM element needs to be added Updates to the general/overview section (10.2.6.1) to clarify scheduled and unscheduled PS and their co-existence Clarify ATIM response rules when in unscheduled PS mode (no need to wake up) Added an example for ATIM response behavior Rev 2: Allow PCP to use the unscheduled power save mechanism when associated with more than one STA Corrections to figure to reflect need for additional ATIM frame transsmissions Define PS mode as a management primitive instead of the reflection of the STA power state Rev 3: Minor/editorial corrections [Add a new UPSIM abbreviation.] 3.4 Abbreviations and acronyms ... [DTIM is undefined in DMG networks.] 6.3.2.2.2 Semantics of the service primitive The primitive parameters are as follows: MLME-POWERMGT.request( PowerManagementMode, ReceiveDTIMs ) Name Type range Description PowerManagementMode Enumeration ACTIVE, POWER_SAVE An enumerated type that describes the requested power management mode of the STA. ReceiveDTIMs Boolean true, false When true, this parameter causes the STA to awaken to receive all DTIM frames. When false, the STA is not required to awaken for every DTIM Beacon frame. [Clarify the usage of the Power Management field in DMG.] 8.2.4.1.7 Power Management field The Power Management subfield is 1 bit in length and is used to indicate the power management mode of a STA. The value of this subfield is either reserved (as defined below) or remains constant in each frame from a particular
4 Data Center NG60 Connectivity: -Indoor Backhaul with Indoor, LOS only <10m ~20Gbps P2P P2MP 5 Distribution/Video on Demand System: - Multicast Streaming/Downloading - Dense Hotspots Indoor, LOS/NLOS <100m >20Gbps P2P P2MP 6 Mobile Wi-Fi Offloading and Multi-Band Operation (low mobility): -Multi-band/-Multi-RAT Hotspot operation Indoor/Outdoor, LOS/NLOS <100m >20Gbps P2P P2MP 7 Mobile Fronthauling Outdoor, LOS <200m ~20Gbps P2P P2MP 8 Wireless Backhauling with Single Hop: -Small Cell Backhauling with single hop -Small Cell Backhauling with multi-hop Outdoor, LOS <1km <150m ~2 – 20 Gbps P2P P2MP 9 Office docking Indoor LOS/NLOS < 3 m ~13.2 Gbps P2P P2MP As it follows from Table 2.1 the considered use cases differ from each other by the throughput, latency, and topology configuration. Moreover the same use cases can be considered in different propagation environments (scenario), and one environment scenario may host different usage models (and also different STA deployments, AP stations positions, interference environment, antenna configurations and other parameters). For the channel modeling purposes, the classification of the channel models in accordance with scenarios and system operation mode is more appropriate. IEEE 802.11ay evaluation scenarios Table 2.2 shows the correspondence between selected 802.11ay use cases [2] and channel modeling scenarios considered in present document. Table 2.2 Use cases and channel modeling scenarios correspondence Channel modeling scenario Use cases Channel modeling approach Supported mode of operation Living room 2, 3 802.11ad model, extension for SU-MIMO
Karma Wangchuk Tokyo Institute of Technology Jun-ichi Takada Tokyo Institute of Technology Revision History r0 – Sept. 2015 – Initial version contained high-level description of the proposed channel models to be used in IEEE 802.11ay group. r1 – Nov. 2015 – Section 3 describing legacy channel models update to support SU-MIMO schemes. r2 – Jan. 2016 – Sections 4 and 5 added, introducing Quasi-Deterministic (Q-D) channel modeling methodology and new channel models for large-scale environments. r3 – March 2016 – Section 4.5 added, describing the mobility effects within Q-D modeling approach. Section 6 added, with the description of the ultra-shout range channel model and measurements. r4 – May 2016 – Section 7 describing D2D communications channel model. Additional editorial changes made. r5, r6 – July 2016 – Section 8 added, describing additional experimental measurement results presented in the contributions to TGay group. r7 – Sept. 2016 – Minor fixes in references and Q-D model parameters made. r8 – Jan. 2017 – Section 8.1.2 added, with minor formatting changes to whole Section 8. r9 – March 2017. Added section 4.6 on Doppler spread measurements and model. Sections 8.1.3 “Large Indoor Scenarios (Entrance Hall)” 8.2.2 “Street Canyon measurements by Huawei and TU Ilmenau” added. References updated. List of authors updated. Table of Contents
1 Ultra Short Range (USR) Communications: -Static,D2D, -Streaming/Downloading LOS only, Indoor <10cm ~10Gbps P2P 2 8K UHD Wireless Transfer at Smart Home: -Uncompressed 8K UHD Streaming Indoor, LOS with small NLOS chance, <5m >28Gbps P2P 3 Augmented Reality and Virtual Reality: -Low Mobility, D2D -3D UHD streaming Indoor, LOS/NLOS <10m ~20Gbps P2P 4 Data Center NG60 Inter-Rack Connectivity: -Indoor Backhaul with Indoor, LOS only <10m ~20Gbps P2P P2MP 5 Video/Mass-Data Distribution/Video on Demand System: - Multicast Streaming/Downloading - Dense Hotspots Indoor, LOS/NLOS <100m >20Gbps P2P P2MP 6 Mobile Wi-Fi Offloading and Multi-Band Operation (low mobility): -Multi-band/-Multi-RAT Hotspot operation Indoor/Outdoor, LOS/NLOS <100m >20Gbps P2P P2MP 7 Mobile Fronthauling Outdoor, LOS <200m ~20Gbps P2P P2MP 8 Wireless Backhauling with Single Hop: -Small Cell Backhauling with single hop -Small Cell Backhauling with multi-hop Outdoor, LOS <1km <150m ~2 – 20 Gbps P2P P2MP 9 Office docking Indoor LOS/NLOS < 3 m ~13.2 Gbps P2P P2MP As it follows from Table 21 the considered use cases differ from each other by the throughput, latency, and topology configuration. Moreover the same use cases can be considered in different propagation environments (scenarios), and one environment scenario may host different usage models (and also different STA deployments, AP stations positions, interference environment, antenna configurations and other parameters). Therefore for the channel modeling purposes, the classification of the channel models in accordance with scenarios and system operation mode is more appropriate.
Cited clause: Proposed resolution: Revised. At the end of cited clause 10.2.2.10, add a paragraph/sentence: "For receive operation using the U-APSD coexistence capability, see 10.2.2.5.2.” CID Page Clause Resn Status Comment Proposed Change Ad-hoc 10.2.2.6 "The base the aging function on the Listen Interval specified by the STA in the (Re)Association Request frame or the Interval specified by the non-AP STA in the WNM-Sleep Mode Request frame." -- this statement is a subset of the previous may, and is therefore strictly unnecessary. Reword: "The AP might base..." MAC Discussion Cited text: Proposed resolution: Accept. At the cited location, replace “The AP may base …” with “The AP might base …”
clause: Proposed resolution: Revised. At the end of cited clause 10.2.2.10, add a paragraph/sentence: "For receive operation using the U-APSD coexistence capability, see 10.2.2.5.2.” CID Page Clause Resn Status Comment Proposed Change Ad-hoc 10.2.2.6 "The APmay base the aging function on the Listen Interval specified by the STA in the (Re)Association Request frame or the Interval specified by the non-AP STA in the WNM-Sleep Mode Request frame." -- this statement is a subset of the previous may, and is therefore strictly unnecessary. Reword: "The AP base..." MAC Discussion Cited text: Proposed resolution: Accept. At the cited location, replace “The AP may base …” with “The AP might base …”
In 9.22.4.2.1 General Proposed resolution: Revised. At 1552.34, change “The request may be sent for ACs for which the ACM subfield is 0”. to: “The ADDTS Request frame may be sent for ACs regardless of the ACs’ ACM settings.”. CID Page Clause Resn Status Comment Proposed Change Ad-hoc 5214 This paragraph does not acknowledge that the times at which the AP transmits during an unscheduled SP may be additionally constrained by the coexistence mechanism. Add a statement to this para somewhere: "The times at which an AP may transmit during an unscheduled SP might be constrained by the Coexistence mechanism (see 10.2.2.5.2)." MAC Discussion Cited text: with commenter that adding a statement might be helpful. Proposed resolution: Revised. At the end of paragraph, add "The times at which an AP may transmit during an unscheduled SP might be constrained by the U-APSD coexistence mechanism (see 10.2.2.5.2)." CID Page Clause Comment Proposed Change Resolution Owning Ad-hoc 5218 1560.62 10.2.2.10 This subclause doesn't acknowledge the coexistence mechanism, which has a whole raft of Add a sentence, "For receive operation the U-APSD coexistence mechanism, also see 10.2.2.5.2." MAC APSD
IEEE P802.11 Wireless LANs 802.11 REVmc Initial Sponsor ballot - Proposed resolutions for some SB0 power saving comments Date: 2015-12-07 Author(s): Name Company Address Phone email Emily Qi Intel Corporation Emily.h.qi@intel.com CID Page Clause Resn Status Comment Proposed Change Ad-hoc 5212 "The request may be sent for ACs for which the ACM subfield is 0." This statement is not really needed, but the converse one is. Replace with: "The request may be sent for ACs for which the ACM subfield is 0; the request shall not be sent for ACs for which the ACM subfield is 1." MAC Discussion Context at 1552.34: The cited sentence is nothing to do with the context. Agreed with the commenter that this statement is not really needed here. However, the revised sentence suggested from the commenter is incorrect: “….. the request shall not be sent for ACs for which the ACM subfield is 1”. How to send ADDTS request and relationship with ACM values are described in 8.4.2.28 EDCA Parameter Set element and 9.22.4 Admission Control at the HC. As an example, in 8.4.2.28 EDCA Parameter Set element
Description Classification An Action, Disassociation, or Deauthentication frame Bufferable An individually addressed Probe Response frame that is sent in an IBSS in response to an individually addressed Probe Request frame Bufferable All other Management frames Nonbufferable Comment Proposed Change Owning Ad-hoc "For a STA using U-APSD, the AP transmits one BU destined for the STA from any AC that is not in response to PS-Poll from the STA. When all ACs associated with the STA are delivery-enabled, AP transmits one BU from the highest priority AC that has a BU." -- in the first case it would be advisable if high-priority traffic were, like, prioritised After the first sentence cited add "The AP should transmit the BU from the highest priority AC that is not delivery-enabled and that has a BU." MAC Discussion Cited text: Proposed resolution: Revised. After the first sentence cited, add: “The AP should transmit the BU from the highest priority AC that is not delivery-enabled and that has a buffered BU.” Comment Proposed Change Owning Ad-hoc What does "A STA may use both WNM-sleep mode and PS mode simultaneously." mean? Clarify, or demote to a NOTE MAC
Do you agree to add the following text into 11ax SFD: An 11ax STA regards a valid OBSS PPDU as not having been received at all (e.g., should not update its NAV), except that the medium condition shall indicate BUSY during the period of time that is taken by the receiving STA to validate that the PPDU is from an Inter-BSS, but not longer than the time indicated as the length of the PPDU payload if the RXPWR of the received PPDU is below the OBSS_PD threshold and TBD conditions are met, noting that the OBSS_PD threshold is accompanied by a TXPWR value and a reduction in the TXPWR may be accompanied by an TBD increase in the OBSS_PD threshold value. Yes: 38 No: 1 Abstain: 18 passes Question: What about beacons and other management frames? Should the also be discarded because of low power? Answer: Yes, if power is below power and from OBSS. Comment: I have an with the last sentence. We have an action item to improve this sentence in the future. It’s the right direction but needs to become better. 15/1082r1, Analysis of BSS and ESS Structure during Concurrent SR Transmissions Presenter: Chuck Lukaszewski (Aruba Networks) Chuck reviewed document 15/1082r1. Question: Do you believe that roaming decisions need to be further assisted by the network? Answer: Yes, absolutely. With spatial mechanisms applied non-AP STAs and APs need to collaborate more on roaming. More help from the network will be needed. Possibly there are standardized features needed. Question: Can you talk more about the MCS 7 design criteria? Answer: Customers usually look at the rate displayed in devices. Customers complaint if they see something lower in their devices. They believe that they didn’t get what they pay for if they don’t see the full data rate. Comment: System performance maximization may not be able to satisfy everyone. Targeting super high MCS is probably not the best to improve spectral efficiency. Question: What is the SR gain in your model? If you compare with a system that does not have any SR, do you have any results?
IEEE P802.11 Wireless LANs Some LB 199 Proposed Comment Resolutions Date: 2014-03-12 Author(s): Name Affiliation Address Phone email Dorothy Stanley Aruba Networks 1322 Crossman ave, Sunnyvale, CA +1 408 227 4500 CID 2306 (GEN) 2306 105.56 4.10.4.3 Matching line just above, the group addressed messages are frames. Replace "messages" with "frames". Discussion: The cited text is below: Agree with the commenter, change “messages” to “frames” at L56. Proposed resolution: Accepted CID 2303(GEN) 2303 102.35 4.10.3.2 The Group Key Handshake is used to allow the Supplicant to continue to receive group addressed _frames_. Replace "messages" with "frames". Discussion: The cited text is below: Agree with the commenter, change “messages” to “frames” at L35. Proposed resolution: Accepted CID 2296 (GEN) 2296 87.47 STAs protect the contents of frames (though also On line 38 replace "messages" with "frames".