zilongwang/ReadingBank huggingface dataset:
Mark HAMILTON – CID 338 Matthew FISCHER: Obsolete comments: CIDs 59 and 62 in 11-17-1518 – text prepared, pending review – Menzo WENTINK Update from Menzo’s review: Menzo WENTINK CIDs: 194, 222, 223 Guido HIERTZ – CID 289 Graham SMITH – 11-17-1137r6 includes edits discussed at ad-hoc GEN CIDs 140, 290 4. AOB, next meeting: Jan 14-19 2018 Irvine CA MAC CIDs 339, 179, 180, 362, 363 Tues PM1: Additional CIDs 5. Adjourn Teleconferences are subject to applicable policies and procedures, see Thanks, Dorothy ================================================== • IEEE Code of Ethics – • IEEE Standards Association (IEEE-SA) Affiliation FAQ – • Antitrust and Competition Policy – • IEEE-SA Patent Policy – – – – • IEEE 802 Working Group Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Chair's Guidelines (Approved 17 Mar 2017) – as updated in • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 10 Nov 2017)
IEEE P802.11 Wireless LANs Proposed FD-TIG report text on self-interference cancellation Date: 2018-07-10 Author(s): Name Affiliation Address Phone email Yan Xin Huawei Technologies 303 Terry Fox Dr., Suite 400, Ottawa, ON, Canada yan.xin@huawei.com Genadiy Tsodik genadiy.tsodik@huawei.com Ming Gan ming.gan@huawei.com Peiwei Wang peiwei.wang@huawei.com Shimi Shilo shimi.shilo@huawei.com Doron Ezri Doron.Ezri@huawei.com Ben Arie Tho Le-Ngoc McGill University Room 633, McConnell Engineering Building 3480 University Street Montreal, Quebec, Canada H3A 0E9 tho.le-ngoc@mcgill.ca Robert Morawski Harry Lee FD Technical Feasibility FD operations within a BSS Self-interference cancellation level
PHY PART in Section 29. TGaz Editor: Insert the following item to the end of the 29.1.1 Introduction to the EDMG PHY: 29.1.1 Introduction to the EDMG PHY An EMDG STA may support the following features: … 2.16 GHz, 4.32 GHz, 6.48 GHz, and 8.64 GHz EDMGz secure ranging PPDU using EDMG SC mode (transmit and receive) TGaz Editor: In section 29.2.2, replace the two rows of “SECURED_TRN” and “SECURED_TRN_WAVEFORM” with the following ones in Table 40: Table 40— TXVECTOR and RXVECTOR parameters Parameter Condition Value TXVECTOR SECURED_TRN FORMAT is EDMG, is EDMG_SC_MODE, NUM_USERS is 1, NUM_STS is 1 Indicates whether TRN field, if present in the PPDU, contains Secure TRN sequences. Enumerated type: SECURED_TRN NON_SECURED_TRN Y Y Otherwise Not present N N SECURE_TRN_ FORMAT is EDMG, is EDMG_SC_MODE, NUM_USERS is 1, NUM_STS is 1 Indicates the Secure TRN Sequences used in the EDMGz secure ranging PPDU. Y N
reachable address update frame containing "current list" STA1 and STA2 to root AP based on condition 1) in L23, overwriting the correct forwarding entry for STA1 in root AP 5. Later traffic to STA1 is forwarded to relay AP1, causing relay AP1 disassociation of STA1, which triggers another reachable address update frame sent to root AP, based on condition 2) in L23. This completely removes STA1 from root AP's "current list" of reachbale addresses the S1G relay AP of the S1G relay For condition 1) and 2), the reachable address update frame only contains the newly associated/disassocated STA addresses For condition 3), the relay AP ignores/removes an address from the reachable address element with add/remove subfield set to 0, from the received reachable address update frame, if the current forwarding relay for the address is not the same as the the STA sending the reachable address update frame to the relay AP
MACs. An additional virtual CS mechanism referred to as response indication deferral (RID) shall be provided by S1G MACs" (the current wording does not require RID in S1G MACs; is it a requirement?) Update the subsequent paragraphs as appropriate. Discussion: Proposed resolution: Revised Note to the commenter: RID is required for S1G MACs. TGm Editors: Please modify clause 10.3.2.1 of REVmd/D1.2 as follows: (11ah) The NAV maintains a prediction of future traffic on the medium based on duration information that is announced in RTS/CTS frames by non-DMG STAs and RTS/DMG CTS frames by DMG STAs prior to the actual exchange of data. The duration information is also available in the MAC headers of all frames (M53)other than (11ah)PV1 MAC frames and PS-Poll frames, and during the BTI, the A-BFT, the ATI, the CBAP, and the SP. (11ah)The duration information in a frame transmitted by an S1G STA is also available in PS-Poll+BDT frames, in NDP CTS frames, in NDP Ack frames whose Idle Indication field value is 0, and in NDP_2M PS-Poll-Ack frames whose Idle Indication field is 0. (11ah)The mechanism for setting the NAV RTS/CTS or RTS/DMG CTS in the DCF is described in 10.3.2.4 (Setting and resetting the NAV), (#65)and use of the NAV in HCF is described in 10.24.2.2 (EDCA backoff procedure) and 10.24.3.4 (NAV operation of a TXOP under HCCA). Additional details regarding NAV use appear in 10.3.2.6 (RTS/CTS with fragmentation), 10.3.2.15 (NAV distribution), 10.40.10 (Updating multiple NAVs), and 10.28 (Protection mechanisms). (11ah) The mechanism for setting the RID is described in 10.3.2.5 (Setting and resetting the RID(11ah)).
The chair stated that All CIDS would get appropriate attention and discussion and any rejection would be on a case by case basis. Adjourned 12:02 pm ET. 802.11md - – Telecon, Friday 24 August 2018, 10:00- 12:00 ET Call to Order at 10:03 ET by the TG Chair, Dorothy STANLEY (HPE) Attendance: Jon ROSDAHL (Qualcomm) Dorothy STANLEY (HPE) Emily QI (Intel) Mark HAMILTON Mark RISON (Samsung) Michael MONEMURRO (Blackberry) David Goodall (Morse Micro) Menzo Wentink (Qualcomm) Sean Coffey (Realtek) Yasu (NTT) Graham Smith (SR Technologies) Jerome Henry (Cisco) Liwen Chu (Marvell) Viewer 92, 112 (did not respond) Review of Patent Policy Patent Policy: Ways to inform IEEE: Call for essential patents – No comments. Participation slide: Agenda Review – 11-18/1351r10 draft Agenda: The agenda for the teleconferences is below: 1. Call to order, attendance, and patent policy a. Patent Policy: Ways to inform IEEE: Cause an LOA to be submitted to the IEEE-SA (); or Provide the of this group with the identity of the holder(s) of any and all such claims as soon as possible; or up now and respond to this Call for Potentially Essential Patents If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance, please respond at this time by providing relevant information to the WG Chair b. Participation 2. Editor report – Emily QI a. Editor report document, 11-17-920, including P802.11ak editorial roll-in issues b. Comments received LB 232 are here: 11-18-611 3. Comment resolution.
IEEE P802.11 Wireless LANs Real-time mobile game Wi-Fi problem highlight Date: 2018-08-15 Contributors: Name Affiliation Address Phone email Kate Meng Tencent Holdings Limited C1, Hi-Tech Park, NanShan, Shenzhen, China +86 166-7516-1765 Katemeng@tencent.com Abstract This document contains introduction of background information and network requirements of mobile game under Wi-Fi. time
IEEE P802.11 Wireless LANs Real-time mobile game Wi-Fi problem highlight Date: 2018-08-17 Contributors: Name Affiliation Address Phone email Kate Meng Tencent Holdings Limited C1, Hi-Tech Park, NanShan, Shenzhen, China +86 166-7516-1765 Katemeng@tencent.com Abstract This document contains introduction of background information and network requirements of mobile game under Wi-Fi. time
Packet size (Byte) Largest Value Largest Extreme Value a=50, b=11 a=38, b=3.7 End packet (Byte) Uniform Uniform a=500, b=600 a=400, b=550 Traffic for frame lockstep sync real-time mobile game Component Distribution Parameters PDF DL UL DL UL Initial packet size(Byte) Uniform Uniform a=0, b=80 a=0, b=80 Packet arrival time (ms) Largest Value Largest Extreme Value a=28, b=4.2 a=22, b=3.4 Packet size (Byte) Largest Value Largest Extreme Value a=210, b=35 a=92, b=38 End packet (Byte) Uniform Uniform a=1400, b=1500 a=500, b=600 Problem Highlight Users connect to game under various environment, such as home, restaurants, subway, malls etc. Around 60% users connect to game via Wi-Fi, with 20-30% possibilities that users encounter lagging 60-70% lagging because of problems between client and gateway. (around 10-15% are remain unknown which pending a validate process/ test plan to locate problem). Algorithm to identify reasons of lagging (simplified) Note: The environment is home based. Home AP is different from enterprise AP which use as widely spaced channels as possible.
IEEE P802.11 Wireless LANs Real-time mobile game Wi-Fi problem highlight Date: 2018-08-22 Contributors: Name Affiliation Address Phone email Kate Meng Tencent Holdings Limited C1, Hi-Tech Park, NanShan, Shenzhen, China +86 166-7516-1765 Katemeng@tencent.com Abstract This document contains introduction of background information and network requirements of mobile game under Wi-Fi. time
Initial packet size(Byte) Uniform Uniform a=0, b=20 a=0, b=20 Packet arrival time (ms) Largest Value Largest Extreme Value a=13, b=3.7 a=15, b=5.7 Packet size (Byte) Largest Value Largest Extreme a=50, b=11 a=38, b=3.7 End packet (Byte) Uniform Uniform a=500, b=600 a=400, b=550 Traffic model for frame lockstep sync real-time mobile game Component Distribution Parameters PDF DL UL DL UL Initial packet size(Byte) Uniform Uniform a=0, b=80 a=0, b=80 Packet arrival time (ms) Largest Value Largest Extreme Value a=28, b=4.2 a=22, b=3.4 Packet size (Byte) Largest Value Largest Extreme Value a=210, b=35 a=92, b=38 End packet (Byte) Uniform Uniform a=1400, b=1500 a=500, b=600
IEEE P802.11 Wireless LANs Real-time mobile game Wi-Fi problem highlight Date: 2018-08-22 Contributors: Name Affiliation Address Phone email Kate Meng Tencent Holdings Limited C1, Hi-Tech Park, NanShan, Shenzhen, +86 166-7516-1765 Katemeng@tencent.com Abstract This document contains introduction of background information and network requirements of mobile game under Wi-Fi. time
Initial packet size(Byte) Uniform Uniform a=0, b=20 a=0, b=20 Packet arrival time (ms) Largest Value Largest Extreme Value a=13, b=3.7 a=15, b=5.7 Packet size (Byte) Largest Value Largest Extreme Value a=50, b=11 a=38, b=3.7 End packet (Byte) Uniform Uniform a=500, b=600 a=400, b=550 Traffic for frame lockstep sync real-time mobile game Component Distribution Parameters PDF DL UL DL UL Initial packet size(Byte) Uniform Uniform a=0, b=80 a=0, b=80 Packet arrival time (ms) Largest Value Largest Extreme Value a=28, b=4.2 a=22, b=3.4 Packet size (Byte) Largest Value Largest Extreme Value a=210, b=35 a=92, b=38 End packet (Byte) Uniform Uniform a=1400, b=1500 a=500, b=600
IEEE P802.11 Wireless LANs Comment resolutions for 9.4.2.200 Date: 2018-09-01 Author(s): Name Affiliation Address Phone email Alfred Asterjadhi Qualcomm Inc. 5775 Morehouse Dr, San Diego, CA 92109 +1-858-658-5302 aasterja@qti.qualcomm.com Abhishek Patil Qualcomm Inc. George Cherian Qualcomm Inc. Abstract This submission proposes resolutions for multiple comments related to TGax D3.0 with the following CIDs (17 CIDs): 15025, 15026, 15027, 15030, 15031, 15032, 15242, 15243, 15880, 15881, 15882, 15883, 16436, 16445, 16459, 16460, 16461 Revisions: Rev 0: Initial version of the document. Rev 1: Has three CIDs deferred (15026, 15027, 16461). Interpretation of a Motion to 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. CID Commenter P.L Comment Proposed Change Resolution 15025 Abhishek Patil Reference to Broadcast field is made before the field is actual defined (which happens on pg 140 on line 47). Also the description of TWT Parameters occurs before description of fields in Control field. Move the paragraph on pg 139 and Figures 9-589av1 and 9-589av2 after Table 9-262j1 (i.e., after all the fields of Control field have been described which includes Negotiation Type field). Revised – Agree in principle with the comment. Moved as suggested. TGax editor to make the changes shown in under all headings that include CID 15025. r1
CID PP LL Comment Proposed Change Resolution 15084 284 7 TRS Control subfield solicits response from a single STA. Change plural STAs to single STA. Change the second sentence to: "An AP shall not set any subfields of a TRS Control subfield to a value that is not supported by the recipient STA of the TRS Control subfield." Accepted. 15684 284 17 Requiring at least one RU allocated for each 20MHz subchannels occupied by DL MU is not necessary because the AP can specify unassigned RUs to any of the 20MHz subchannels Remove the text: "If an AP transmits one or more Trigger frames or frames carrying a TRS Control subfield, then the frames shall collectively elicit HE TB PPDU responses such that at least one Rejected. Discussion: In UL MU PPDU transmission, each 20MHz channel occupied by Trigger/TRS is required to allocate at least one UL RU. If a 20MHz channel is not covered by any UL RU, the 20MHz channel can’t be protected and get wasted.
27.9.2.2 338.23 The devices have temptation to set the value at the end of the beacon period, because there is no penalty for doing it, i.e. the time when reuse cannot be used for non-SRG transmissions is only to the next TBTT. This may cause variation when STAs allow the reuse. When reuse is allowance varies, then the interfernce level varies as well. In order to minimize interference level variation for more precise link adaptation, the interference level should not vary. Also there should not be easy benefits for denying other STAs to use the SRG at transmissions at the end of the beacon period. increase the time when a STA cannot use spatial reuse after transmitting a frame with Set allow the spatial reuse only after the following beacon period, i.e. after two beacon transmissions, or alternatively calculate the duration of one beacon period from the time when the frame with was transmitted. Revised – We can extend the rule to the current beacon interval and the previous beacon interval. Apply the changes as proposed in . 15175 27.9.2.2 338.25 The settings and where this values are allowed or not allowed is still very confusing. Suggest to have a table that mentions where certain settings of this SPATIAL REUSE are allowed and were they are not. As in comment. 15742 27.9.2.2 338.36 It is unclear why RTS needs to be mentioned in the spatial reuse rules. If CTS is received, then it will deny the spatial reuse. The complicated sentences on possible RTS reception before the CTS frame are not needed. The sentence does not enable any special operation when RTS is received. Delete the sentence starting:"or the received..." Rejected – RTS is mentioned here because there is a special case where OBSS_PD is allowed when receiving both RTS and CTS.
15709 27.9.2.4 349.15 Please clarify TX_PWR in the case of a MIMO transmision "TXPWR is the STA transmission power in dBm at the output of the antenna connector." Please clarify. Reject – the definition of antenna connector is clarifying this point already in the specification. 27.9.2.4 349.55 "Not applicable if the Spatial Reuse Parameter Set element is not received" for the case of AP, it shall be "Not applicable if the Spatial Reuse Parameter Set element is not transmitted." Please include conditions for AP as well Revised – agree with the commenter. table is only for a non-AP STA. Apply the changes as proposed in doc . 27.9.2.4 351.60 Change "OBSS_PDmax ΓëÑOBSS_PDlevel >OBSS_Pdmin" to " OBSS_PDlevel > OBSS_Pdmin" because first part of condition is already specified in Equation 27-4, no need to repeat here. as described Reject – there is redundancy indeed, but this helps the understanding. 15715 27.9.2.5 352.61 In Example shown in Figure please clarify that a STA might choose to maintain the same OBSS_PDlevel with the same TX_PWRmax1 and not ignore the PPDU from D1. Same situation as receiving PPDU from S1' and D1'. as described Revised – agree with the commenter. Add some words about this in the example description. Apply the changes as proposed in doc .
HE beamformed transmissions come with a "smoothing" or "beamformed" indication in the preamble, so the receiver can adjust. This is not possible if BF is applied from the start of the packet. Since the receiver can not know whether BF is applied or not, it may have no choice but to disable channel smoothing. This would be quite ironic since it would result in a reduction of channel estimate quality, which BEAM_CHANGE is supposed to help with. the the case of BEAM_CHANGE = 0. Smoothing or not is a receiver’s decision, it is not related to BEAM_CHANGE. The receiver checks if the channel can be smoothed or not. Even for beamformed frames, sometimes it can be smoothed. For 11ax, even beamformed packet, the channel needs to be smoothable in 1x and 2x HE-LTF.
IEEE P802.11 Wireless LANs LB234 Comment Resolutions – PHY and BF Date: 2018-09-11 Author(s): Name Affiliation Address Phone email Claudio da Silva Intel claudio.da.silva@intel.com CID Clause Page Comment Proposed change 3169 29.5.11.1.11 473.7 EVM values are missing in Table 94 Add missing EVM values 3270 29.5.11.1.11 473.7 TX EVM requirements for SC DCM must be defined 94) See 18/1420r0. 3709 29.5.11.1.11 473.7 94: column of EVM value is blank Please define Proposed resolution: Revised Discussion: EVM values for EDMG SC DCM were proposed in contribution 18/1420r0, presented to TGay in the August 29th conference call. Modifications: Editor – please modify 94 (D2.0, page 473) as defined in 18/1420r0. CID Clause Page Comment Proposed change
1 1 1 1 1 1 1 1 B69 B70 B72 B73 B74 B75 B76 B77 Midamble Tx/Rx 2x And 1x HE-LTF DCM Max BW Longer Than 16 HE SIG-B OFDM Symbols Support CQI Feedback Tx < 242-tone RU Support Rx < 242-tone RU Support Rx Full BW SU Using HE MU PPDU With SIGB Rx Full BW SU Using HE MU PPDU With SIGB 1 2 1 1 1 1 1 1 HE PHY Capabilities Information field format TGax Editor: Update Table -9262aa on D3.1 P165 and 168 as shown below. Subfields of the HE PHY Capabilities Information field Subfield Definition Encoding … … Rx Full BW SU Using HE MU PPDU With SIGB Indicates support for reception of an HE MU PPDU with a bandwidth less than or equal to 80 MHz, an RU spanning the entire PPDU bandwidth and a HE-SIG-B format. Set to 0 if not supported. Set to 1 if supported.
D3.1 P530: Proposed Resolution: CID 16031 Rejected. Draft is clear that DCM can be applied “only” to RUs containing data for 1 user. Hence, the change proposed by the commenter is redundant. CID 16978 CID Clause Page.Line Comment Proposed Change 16978 28.3.11.9 526.09 "DCM is not applied with MU-MIMO", and in the paragraph after the spec say "DCM can be applied only to RUs containing data for 1 user". these are talk about the same rule. only need one or the other. remove "In an HE MU PPDU or HE TB PPDU, DCM can be applied only to RUs containing data for 1 user." Background D3.1 P530: Proposed Resolution: CID 16978 Rejected. The first phrase (“DCM can be applied only to RUs containing data for 1 user”) does indicate that DCM cannot be used together with MU-MIMO. However, the first phrase also clarifies that the if an HE MU or HE TB PPDU has multiple RUs, where some RUs have 1 user while other RUs have multiple users, then the RUs with 1 user can still use DCM. Hence, it is recommended to keep both phrases. CID 17099 CID Clause Page.Line Comment Proposed Change 17099 28.3.11.10 526.64 Better wording needed. This is really an editorial comment, but marking it as technical so that people can review. At P526L64, change "If in an RU, DL MU-MIMO is applied, STBC shall not be used in any RU in the HE MU PPDU." to "If any RU in an HE MU PPDU uses DL then STBC shall not be used in any RU in the HE MU PPDU." Background D3.1 P530-531: Proposed Resolution: CID 17099
1 1 1 1 1 1 1 1 B69 B70 B72 B73 B74 B75 B76 B77 Midamble Tx/Rx 2x And 1x HE-LTF DCM Max BW Longer Than 16 HE SIG-B OFDM Symbols Support CQI Feedback Tx < 242-tone RU Support Rx < 242-tone RU Support Rx Full BW SU Using HE MU PPDU With SIGB Rx Full BW SU Using HE MU PPDU With SIGB 1 2 1 1 1 1 1 1 HE PHY Capabilities Information field format TGax Editor: Update -9262aa on D3.1 P165 and 168 as shown below. Subfields of the HE PHY Capabilities Information field Subfield Definition Encoding … … Rx Full BW SU Using HE MU PPDU With SIGB Indicates support for reception of an HE MU PPDU with a bandwidth less than or equal to 80 MHz, an RU spanning the entire PPDU bandwidth and a HE-SIG-B format. Set to 0 if not supported. Set to 1 if supported.
see M21-1, Part IV, Subpart iii, 3.C, and upon the remarriage of the spouse, see M21-1, Part IV, Subpart iii, 3.D. a determination of physical impairment authorize payment to or on behalf of the child, without referral to the rating activity, as described in M21-1, Part III, Subpart iii, 7.3 M21-1, Part IV, Subpart iii, 3.D, and M21-1, Part III, Subpart v, 9.C.4. 7. Discontinuance of Benefits When Child Is No Longer Permanently Incapable of Self-Support Introduction This topic contains information on discontinuance of benefits when a child is no longer permanently incapable of self-support, including protection of disability ratings 38 U.S.C. 110 considering qualification under school attendance provisions, and the procedure for reducing or discontinuing benefits. Change Date July 11, 2015 a. Protection of Disability Ratings Under 38 U.S.C. 110 Disability ratings are provided some protection from reduction under . This protection does not apply to a rating of permanent incapacity for self-support. b. Considering Qualification Under School Attendance Provisions Determine whether the child may be entitled to benefits as a schoolchild before discontinuing benefits based on a child’s permanent incapacity for self-support.
Discussion: Extemporized. Proposed Changes to Draft Text of TGax D2.0: TGax editor: within subclause 9.4.2.200 TWT element, modify the text and figures as shown and instructed: 9.4.2.200 TWT element Change the first paragraph as follows: The TWT element format when the Broadcast subfield of the Control field is 0 is shown in Figure 9-589av. Replace the title of Figure 9-589av with “TWT element format when the Broadcast subfield is 0” Insert a new paragraph and associated figure after the first paragraph as follows: The TWT element format when the Broadcast subfield of the Control field is 1 is shown in Figure 9-589av1 (TWT element format when the Broadcast subfield is 1). TGax editor: modify Figure 9-671 – TWT element format, consolidating all fields the control field into a single field called “TWT Parameter Information” with an octet count of variable, the resulting figure without change marks would appear as shown: (#11123) Element ID Length Control TWT Parameter Information Octets: 1 1 1 variable Figure 9-671 - TWT element format
B B B3B B NDP Paging Indicator Responder PM Mode Reserved Bits: 1 1 64 Control field format TGax editor: throughout Draft 2.0, replace “Broadcast field is set to 1” with “Negotiation Type field has the value 10 or 11” (#11007) TGax editor: throughout Draft 2.0, replace “Wake TBTT Negotiation is set to 1” with “Negotiation Type field has the value 01” (#11123) (#11007) Insert the following three paragraphs after the 5th paragraph (“The Responder PM Mode subfield...”): for broadcast or individual TWT(s). (#11006) (#11007) When is 1 then one or more broadcast TWT parameter sets are contained in the TWT element where each TWT parameter set contains the Request Type, Target Wake Time, Nominal Minimum TWT Wake Duration, TWT Wake Interval Mantissa and Broadcast TWT Info subfields. (#12230) When is equal to 0, only one TWT parameter set is contained in the TWT element. An S1G STA sets field to 0. (#11007) The determine the interpretation of the Target Wake Time, TWT Wake Interval Mantissa and TWT Wake Interval Exponent subfields of the TWT element as defined in . Interpretation of Target Wake Time, TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields (#11007) (#11007) Target Wake Time field TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields Description (#11007) Individual TWT Interval between individual TWT SPs Individual TWT negotiation between TWT requesting STA and TWT responding STA. See 10.43 (Target wake time(TWT)), and 27.7.2 (Individual TWT agreements). (#12394) (#11007) Next Wake TBTT Interval between wake TBTTs Wake TBTT and wake interval negotiation between TWT scheduled STA and TWT scheduling AP. See 27.7.3.4 (Negotiation of wake TBTT and wake interval). Broadcast TWT Interval between broadcast TWT SPs Provide broadcast TWT schedules to TWT scheduled STAs by including the TWT element in broadcast MGMT frames sent by TWT scheduling AP. See 27.7.3.2 (Rules for TWT scheduling AP).
IEEE P802.11 Wireless LANs LB232 CID1543 – Proposed Comment Resolution Date: 2018-09-12 Author(s): Name Affiliation Address Phone email Marc Emmelmann SELF; Koden-TI Berlin, Germany Hitoshi Morioka SRC Software 2-14-38 Tenjin, Chuo-ku, Fukuoka 810-001 JAPAN CID 1543 CID Clause Number(C) Page Comment Proposed Change 1543 9.4.2.182 1280.01 "The AP verifies that the extracted source MAC address is equal to the source MAC address of the (Re)Association frame. If these are different, the AP shall discard the FILS HLP Container element;" -- so there's no point passing the source MAC address, since the transmitter will always ensure they are the same (why bother sending something you know the other end will discard?) Delete step 2) at 2301.42 and the bullet at 2302.21. In Figure 9-634 delete the Source MAC Address and Destination MAC Address fields. In 9.4.2.182 delete the penultimate paragraph. Discussion Note: P1280.01 refers to D1.0 which is in D1.4 on page 1337. Also, the clause number in D1.4 has changed from xxx.182 to xxx.183. Context: D1.4 P1337
IEEE P802.11 Wireless LANs Suggested resolution to MIB comments Date: 2018-09-12 Author(s): Name Company Address Phone email Kazuyuki Sakoda Sony Kazuyuki.Sakoda (at) sony (dot) com Comment: CID Comment Proposed Change Suggested Resolution 1247 dot11STACivicLocation is a control variable, but its MAX-ACCESS is not-accessible. Why we cannot access it? Please clarify. REVISED: Adopt changes proposed in doc11-18/1636. Discussion: MAX-ACCESS of the dot11STACivicLocation is supposed to be read-write, as it is a control variable written by an external management entity or the SME. FYI, there are some more issue with the MIB variable. There is no reference to dot11STACivicLocation in main body of the standard. The same thing apply to dot11STACivicLocationType. Furthermore, it seems that dot11STACivicLocationConfigTable is poorly defined and probably does not pass MIB compilation. In description of “dot11RMCivicConfigured”, there is a reference to dot11STACivicLocationEntry. However, dot11STACivicLocationEntry is not defined anywhere.
IEEE P802.11 Wireless LANs Comment Resolution on MIMO BF Date: 2018-11-12 Author(s): Name Affiliation Address Phone Lei Huang Panasonic Corporation lei.huang@sg.panasonic.com CID Page Number Line Number Comment Proposed Change Resolution 3385 249 7 In the MIMO BRP TXSS procedure, if the number of sectors for a pair of TX and RX DMG antennas that were received in the last Initiator/Responder BRP TXSS is larger than 16, the BRP frame sent during the feedback phase shall contain feedback for at least 16 received sectors for the pair of TX and RX DMG antennas. Otherwise, the BRP frame shall contain feedback for all the received sectors for the pair of TX and RX DMG antennas. as per comment Revised- 3454 250 23 "reciprocal MIMO phase shall be supported by all EDMGSTAs that are capable' Need to add condition of 'Antenna Pattern Reciprocity=1' for both parties" as in comment Revised- 3386 251 29 The statement "If the initiator has antenna pattern reciprocity, the initiator may also reduce the number of TRN subfields required for receive AWV training to reduce the responder SMBT training time." is redundant since it talks about the same thing as the following note. as per comment Revised- 3387 252 27 The statement "If the responder has antenna pattern reciprocity, the responder may also reduce the number of TRN subfields required for receive AWV training to reduce the initiator SMBT training time." is redundant it talks about the same thing as the following note. as per comment Revised- 3233 255 11 "for the responder link shall be determined in such a way that no transmit or receive AWV come from the same DMG antenna." -this sentence is obscure - not clear what should be avoided Refer to spefic fields in the EDMG channel measurement Revised-
– • IEEE Standards Association (IEEE-SA) Affiliation FAQ – • Antitrust and Competition Policy – • IEEE-SA Patent Policy – – • IEEE 802 Working Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Chair's Guidelines (Approved 13 Jul 2018) – • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 10 Nov 2017) – References:
Teleconferences are subject to applicable policies and procedures, see below. ================================================== Teleconferences are subject to applicable policies and procedures, see below. • IEEE Code of Ethics – • IEEE Standards Association (IEEE-SA) Affiliation FAQ – • Antitrust and Competition Policy – • IEEE-SA Patent Policy – – • IEEE 802 Working Group Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Guidelines (Approved 13 Jul 2018) – • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 10 Nov 2017) – References:
• IEEE 802 Working Group Policies &Procedures (29 Jul 2016) – • IEEE 802 LMSC Guidelines (Approved 13 Jul 2018) – • Participation in IEEE 802 Meetings – • IEEE 802.11 WG OM: (Approved 10 Nov 2017) – References:
Request Type Target Wake Time TWT Group Nominal Minimum TWT Wake Duration TWT Wake Interval Mantissa TWT Channel NDP Paging (optional) Octets: 2 8 or 0 9 or 3 or 0 1 2 1 0 or 4 Figure 9-589av666 – Individual TWT Parameter Set field format TGax editor: replace Figure 9-589av1 – TWT element format when the Broadcast subfield is 1 with the following Figure and caption: (#11123) Request Type Target Wake Time Nominal Minimum TWT Wake Duration TWT Wake Interval Mantissa Broadcast TWT Info Octets: 2 2 1 2 Figrue 9-589av1 - Broadcast TWT Parameter Set format Change Figure (Control field format) as follows. B B B(#11007) B3B B (#12033) NDP Paging Indicator Responder PM Mode Reserved Bits: 1 1 64 Control field format
from the scrambler initialization value in the Service field (as defined in 23.3.9.2 (SERVICE field)) prior to descrambling, and the FCS field of the PSDU that carries the soliciting frame. " According to the conventions FCS should be transmitted commencing with the coefficient of the highest-order term. Which is the highest bit of the FCS field? When generating the ACK ID field, should we take the received or transmitted order of the FCS? 11 9.8.4.2 A1 of the STACK frame is defined as "The A1 is an SID field that contains the AID of the intended recipient of the frame in the AID subfield. " which means that STACK frame cannot be transmitted to AP because it doesn’t have AID. Define version of the STACK frame that can address AP Revise - TGmd editor to make changes as shown in 11-18/1724r3 that are marked with CR11, which prescribe a value of 0 to be used for A1 for the frame when it is transmitted to an AP. 12 9.8.4.3 A1 of the BAT frame is defined as "The A1 is an SID field that contains the AID of the intended recipient of the frame in the AID subfield. " which means that BAT frame cannot be transmitted to AP because it doesn’t have AID. Define version of the BAT frame that can address AP. Potential solution is to follow address mechanism of PV1 management frames. Revise - TGmd editor to make changes as shown in 11-18/1724r3 that are marked with CR12, which prescribe a value of 0 to be used for A1 for the frame when it is transmitted to an AP. 13 9.2.4.5.4 When ACK Policy bits in QoS Control field are set to 00, both originator and addressed recipient support fragment BA procedure and frame that doesn’t contain fragment is transmitted, behaviour of addressed recipient is not clear. It looks like that this fits in Otherwise case and addressed recipient should react with BlockAck frame. Describe behaviour of the addressed recipient in this scenario. Revise - TGmd editor to make changes as shown in 11-18/1724r3 that are marked with CR13, which modify table 9-13 by explicitly naming the case and by explicitly naming STACK, TACK and BAT as response choices and by including references to 10.48.2 (TWT acknowledgement procedure) 17 MPDU
IEEE P802.11 Wireless LANs CC28-XDMGz-Comment-Resolution Date: 2018-09-17 Author(s): Name Affiliation Address Phone email Assaf Kasher Qualcomm akasher@qti.qualcomm.com 86 28.00 16 9.4.2.127.7 "TRN field sent by the receiver STA" - what receiver replace by "TRN field sent by the peer STA" Proposed Resolution: Revised TGaz Editor: Modify the text P24L24-26 as follows: A DMG/EDMG STA sets the AOD Channel Measurement Feedback subfield to 1 to indicate the ability to send a Channel Measurement Feedback element based on measurement on a TRN field sent by the STA, for the purpose of AOD estimation. TGaz Editor: Modify the text in P63L25-27: In a Direction Measurement FTM pair that agreed on I2R AOD, the ISTA shall add a TRN field to the frames in the exchanges specified by the Direction Measurement Density by setting the TRN_LEN to a non-zero value and PACKET_TYPE to 1. 232 29.00 9.4.2.166 "The DMG Direction Measurement Parameters subelement is included in the initial FTM request to describe the requested set of parameters that the initiator proposes to use and in the initial FTM frame from the responder when either STA is a STA. " -- only included if both STAs are DMG STAs As it says in the comment 233 29.00 9.4.2.166 "The DMG Direction Measurement Parameters subelement is included in the initial FTM request to describe the requested set of parameters that the initiator proposes to use and in the initial FTM frame from the responder when either STA is a STA. " -- this is not backward-compatible with existing DMG STAs, which will not include this As it says in the comment 235 30.00 9.4.2.166 It seems guaranteed to cause trouble to have fields in different orders for DMG and EDMG Swap R2I AOA Request and I2R AOA Request in Figure 9-4.f EDMG
CIDs Patil 9.4.2.200 131.01 The procedure for indicating validity of a TWT schedule is not well thought through. The mechansim uses 3-bits which can only signal up to 6 beacon intervals (value 7 is reserved). This is too short and STAs in extended sleep (e.g., long Listen interval or Negotiated can easily miss an announcement of an upcoming change (Setup Command = Alternate) or termination (Setup Command = Reject). Define an encoding scheme so the field can represent larger intervals. Since 3-bits doesn't offer many combinations, increase the size of the field (to perhaps 1 octet). Have the update interval to be DTIM instead of a Beacon interval. As in comment Revise - TGax editor to make changes as in 11-17/1893r6 that are marked with CID 11005, see also CID 12036 11006 Patil 9.4.2.200 125.15 Add Wake TBTT Negotiation = 0 with Broadcast = 0) to indicate an Individual TWT As in comment Revise - TGax editor to make changes as shown in 11-17/1893r6 that are marked with CID 11006
12039 9.4.2.200 127.14 The "Request TWT" TWT Command Value says that requesting STA does not specify target wake time. To which value the Target Wake Time value is set? Are all other values of TWT parameter set to requested values? Please clarify to value the STA sets the Target Wake Time value when Request TWT TWT Command value is used. One possibility would be to set the Target Wake Time to 0 to indicate that STA does not have any preference. Reject – the setting of Target Wake Time is already specified as 0 when the command is Request within the baseline. 9.4.2.200 124.29 Currently, the AP does not get information of the times that are not suitable for the TWT requesting STA to have a TWT SP. The AP needs the information of the unsuitable times to select the best times for the TWT SPs, if the AP needs to alternate or dictate the TWT SP times. Without knowledge of the unsuitable times, the TWT setup signaling may require unnecessary many signaling messages transmissions or the TWT SPs may occur during the times when STA needs to suspend the frames delivery or use lower transmission rate that degrades the link performacne and BSS throughput. Allow the non-AP STA to signal by using TWT Setup signaling the times that are not suitable for it to have TWT SPs. This information is only available at non-AP STA and it enables AP to select more wisely the TWT SP times and ensures good performance for the BSS. Reject – a proposal for such functionality was presented and a straw poll showed insufficient support to add the functionality to the draft. 12084 Jinsoo Ahn 9.4.2.200 131.33 What is the 'special broadcast TWT'? Define the term or change to TWT with OPS Revise - TGax editor to make changes as shown in 11-17/1893r6 that are marked with CID 12084, which simply delete the word “special”
TGax editor makes changes as shown in the as specified in 15940 The "color in use" (report) mechanism is not well described. How does this differ from (or relate to) "color collision"? How can a non-AP STA be using a color, if that color is not in collision? And, clearly, the non-AP STA should not report the associated AP's own color to it, even thought the non-AP STA is using that color to talk to it. This is confusing, and should be clarified. Revised- Please the following submission for the background of the BSS color in use event report. When a non-AP STA that is associated with an AP is communicating (e.g., Soft AP, P2P, mesh network) with a peer STA that uses the different BSS color with its associated AP, the STA uses the BSS color in use even report for avoiding an interference from the SR. But, for more background information, some clarification texts are added in 11.24.2.8. TGax editor makes changes as shown in the as specified in 15062 Spec should define rules to prevent abuse. For example, define rules to prevent a STA from sending frequent event report frames and/or blocking all 63 colors. Also clarify if a STA can cancel its previous report and enable SR on the reported color As in comment Revised- Agree in principle. The AP uses only the most recently received BSS color in use event report. And, use the BSS color value 0 to cancel the previously sent BSS color in use event report. TGax editor changes as shown in the as specified in 16465 According to DCN456r1, a HE STA can have two BSS colors. In this subcluause, it says "The Change it to "The BSS color in use event report enables a non-AP HE STA to inform a BSS color in use by the Revised- The BSS color in use event report provides the AP
IEEE P802.11 Wireless LANs [CC28 Trigger frame format comment resolution] Date: 2018-10-23 Author(s): Name Affiliation Address Phone email Dibakar Das Intel Ganesh Venkatesan Intel Chittabrata Jonathan Segev Intel Feng Jiang Intel CID Page Clause Comment Proposed Change Resolution 10 22 9.3.1.23.9 Do we need to add behavior for the "Location Negotiation" subtye if not, let's delete it. As per comment Revised. Agreed in principle to delete the behavior. Removed the corresponding entry. 11 23 9.3.1.23.9.1 9.3.1.23.9.2 9.3.1.23.9.3 It might make sense to remove the text "except that the AID12 subfield carries an AID12 for an associated locating STA or an RID12 for an unassociated locating STA." from each specific Location trigger (Poll, sounding, LMR) to a common As per comment Revised. Agreed in principle. Moved the statement to an already existing common section.
section under new title. 12 23 9.3.1.23.9.3 Should we add a new title for common section to include all texts below line 32? As per comment Revised. Agreed in principle. it to an already existing section. 13 24 9.3.1.23.9.3 Remove 'is TBD from text "The UL Target RSSI field in the User Info field is TBD." I believe we would need RSSI target for UL MIMO Revised. Agreed in principle. This is the same as in 11ax. 224 23 9.3.1.23.9.2 "The User Info field for the HEz Uplink Sounding is defined in Figure -- the baseline defines the format for all Trigger frames in Figure so you can't just change this here As it says in the comment Revised. Agreed in principle. However, in the revised version we have included a field “UL Rep” to indicate number of HE LTF repititions in the HE Ranging NDP PPDU or HE TB Ranging NDP PPDU sent as response to the TF. Hence, we have a revised Fig. 9-52 and Fig. 9-53. 221 23 9.3.1.23.9.1 "The Per User Info field in the HE Poll Trigger -- there is no such field Change to "User Info field" Accept. 223 9.3.1.23.9 Is it a subvariant or a subtype? Be consistent Accept. Revised the Section to replace “type” with “variant” and “sub-type” variant
9.3.1.23.9.1 ubvariant 9.3.1.23.9.2 ubvariant The Trigger Dependent User Info subfield is present the Trigger . The User Info field for the subvariant is defined in Figure 9-5??. B0 B11 B12 B20 B21 B2 B25 B26 B31 B32 B38 B39 Reserved Reserved SS Allocation Target RSSI Reserved Trigger Dependent User Info Bits: 12 9 6 7 1 —Figure 9-5??—User Info field for Sounding subvariant
IEEE P802.11 Wireless LANs [CC28 Trigger frame format comment resolution] Date: 2018-11-13 Author(s): Name Affiliation Address Phone email Dibakar Das Intel Ganesh Venkatesan Intel Chittabrata Ghosh Intel Jonathan Intel Feng Jiang Intel CID Page Clause Comment Proposed Change Resolution 10 22 9.3.1.23.9 Do we need to add behavior for the "Location Negotiation" subtye if not, let's delete it. As per comment Revised. Agreed in principle to delete the behavior. Removed the corresponding entry. 11 23 9.3.1.23.9.1 9.3.1.23.9.2 9.3.1.23.9.3 It might make sense to remove the text "except that the AID12 subfield carries an AID12 for an associated locating STA or an RID12 for an unassociated locating STA." from each specific Location trigger (Poll, sounding, LMR) to a common As per comment Revised. Agreed in principle. Moved the statement to an already existing common section.
section under new title. 12 23 9.3.1.23.9.3 Should we add a new title for common section to include all texts below line 32? As per comment Revised. Agreed in principle. We moved it to an already existing section. 13 24 9.3.1.23.9.3 Remove 'is TBD from text "The UL Target RSSI field in the User Info field is TBD." I believe we would need RSSI target for UL MIMO Revised. Agreed in principle. This is the same as in 11ax. 224 23 9.3.1.23.9.2 "The User Info field for the HEz Uplink Sounding is defined in Figure -- the baseline defines the format for all Trigger frames in Figure so you can't just change this here As it says in the comment Revised. Agreed in principle. However, in the revised version we have included a field “UL Rep” to indicate number of HE LTF repititions in the HE Ranging NDP PPDU or HE TB Ranging NDP PPDU sent as response to the TF. Hence, we have a revised Fig. 9-52 and Fig. 9-53. 221 23 9.3.1.23.9.1 "The Per User Info field in the HE Poll Trigger -- there is no such field Change to "User Info field" Accept. 223 9.3.1.23.9 Is it a subvariant or a subtype? Be consistent Accept. Revised the Section to replace “type” with “variant” and “sub-type” variant
IEEE P802.11 Wireless LANs [CC28 Trigger frame format comment resolution] Date: 2018-11-14 Author(s): Name Affiliation Address Phone Dibakar Das Intel Ganesh Venkatesan Chittabrata Ghosh Jonathan Segev Intel Feng Jiang CID Page Clause Comment Proposed Change Resolution 10 22 9.3.1.23.9 Do we need to add behavior for the "Location Negotiation" subtye if not, let's delete it. As per comment Revised. Agreed in principle to delete the behavior. Removed the corresponding entry. 11 23 9.3.1.23.9.1 9.3.1.23.9.2 9.3.1.23.9.3 It might make sense to remove the text "except that the AID12 subfield carries an AID12 for an associated locating STA or an RID12 for an unassociated locating STA." from each specific Location trigger (Poll, sounding, LMR) to a common As per comment Revised. Agreed in principle. Moved the statement to an already existing common section.
section under new title. 12 23 9.3.1.23.9.3 Should we add a new title for common section to include all texts below line 32? As per comment Revised. Agreed in principle. We moved it to an already existing section. 13 24 9.3.1.23.9.3 Remove 'is TBD from text "The UL Target RSSI field in the User Info field is TBD." I believe we need RSSI target for UL MIMO Revised. Agreed in principle. This is the same as in 11ax. 224 23 9.3.1.23.9.2 "The User Info field for the HEz Uplink Sounding is defined in Figure -- the baseline defines the format for all Trigger frames in Figure so you can't just change this here As it says in the comment Revised. Agreed in principle. However, in the revised version we have included a field “UL Rep” to indicate number of HE LTF repititions in the HE Ranging NDP PPDU or HE TB Ranging NDP PPDU sent as response to the TF. Hence, we have a revised Fig. 9-52 and Fig. 9-53. 221 23 9.3.1.23.9.1 "The Per User Info in the HE Poll Trigger -- there is no such field Change to "User Info field" Accept. 223 9.3.1.23.9 Is it a subvariant or a subtype? Be consistent Accept. Revised the Section to replace “type” with “variant” and “sub-type” variant
439 9.4.2.273 31.22 The following text is a little ambiguous: "If the ID Bitmap size is set to zero, Starting Group ID is reserved." What is that case? It's no meaning/usage case. In that case, AP can simply set the Group ID List present to 0. As per comment Revised – Proposed text update clarifies that if the Group ID Bitmap field is set to 0, the Starting Group ID field contains a single group ID assigned by the WUR AP to the WUR STA. As a result, the issue raised by this CID no longer exists. TGba editor, please make changes as shown in doc 11-18/1823r2 under all headings that include CID 439. 841 9.4.2.273 31.15 If the Group ID bitmap size field is set to 0, Group ID Bitmap field is not present, and Starting Group ID field is reserved. In this case, Group ID List subfield shall not be even present. Change the indication of Group ID Bitmap Size field. 0 indicates 16-bit bitmap, 1 indicates 32-bit bitmap, and 2 indicates 64-bit bitmap. Revised – Proposed text update clarifies that if the Group ID Bitmap field is set to 0, the Starting Group ID field contains a single group ID assigned by the WUR AP to the WUR STA. As a result, the issue raised by this CID no longer exists. TGba editor, please make changes as shown in doc 11-18/1823r2 under all headings that include CID 841. Discussion: None. Propose: Revised for CID 700, 706, 1013, 778, 842, 701, 1228, 1093, 1094, 1095, 1096, 67, 439, 841 per discussion and editing instructions in 11-18/1823r2. TGba editor: replace “Group ID” by “WUR Group ID” in whole D1.0 (#1013). TGba editor: Insert the following acronym definition in 3.4: 3.4 Abbreviations and acronyms TGba editor: Change Table 9-318c on P30L30 as follows: of WUR Parameters field from WUR AP