zilongwang/ReadingBank huggingface dataset:
IEEE P802.11 Wireless LANs 11mc MAC operation comment resolutions Date: 2015-10-13 Author(s): Name Affiliation Address Phone email Guido Hietrz Ericsson Dorothy Stanley HP (Aruba Networks) 1322 Crossman Ave Sunnyvale, CA 94089 +1 630-363-1389 CID 5746- MAC 5746 2088.29 13.4.3 "Configuration": there is nothing called "Configuration" in the definition of mesh peering instance (which does have, for instance, "peerLinkID"), so what is this thing and where is it defined? Either define the parameter, type, or whatever is, or delete the standalone "Configuration" term from the mesh specification in this standard. Discussion: The cited text is below: We believe the term "configuration" is well specified in the context of WLAN Mesh. Clause 8.4.2.97 explains the "Mesh Configuration element" and Clause 13.2.4 explains the "Mesh STA configuration" that consists of "the mesh profile (see 13.2.3 (Mesh profile)), the Supported Rates and BSS Membership Selectors element, the Extended Supported Rates and BSS Membership Selectors element, the HT Operations element (if present), and the VHT Operations element (if present)." To satisfy the commenter, we propose to be more precise in replacing the generic term "configuration" with "mesh configuration". Proposed resolution: Revised In Clause 13.4.3, at 2088.29, delete "as indicated by the Configuration," In Clause 13.4.3 replace all occurences of "configuration" or "Configuration" with "Mesh Configuration". CID 5861 - MAC
what the previous para *really really* meant. Such reassurance should be unnecessary if the previous para is written *really really* clearly enough. Discussion “9.10 Control Wrapper operation A STA supporting the HT Control that receives a Control Wrapper frame shall process it as though it received a frame of the subtype of the wrapped frame. NOTE—A STA supporting the HT Control field can reset the NAV set by a wrapped RTS frame following the rules defined in 9.3.2.4 (Setting and resetting the NAV).” So, is the Note stating the obvious? Obviously it is to the commenter, but then he is probably cleverer than the average mere mortal who reads this Standard. I suppose that in this case I would say that the NOTE is much more an example than a note. Two options come to mind: A – Delete the NOTE (as proposed by commenter), i.e. ACCEPT B – Change NOTE into an example i.e. REVISE “A STA supporting the HT Control field that receives a Control Wrapper frame shall process it as though it received a frame of the subtype of the wrapped frame. For example, a STA supporting the HT Control field can reset the NAV set by a wrapped RTS frame following the rules defined in 9.3.2.4 (Setting and resetting the NAV).” Straw Poll / Discussion Proposed resolution: Accept Identifiers Comment Proposed change CID 5125 Stephens, Adrian 9.9 1308.25 "shall set the +HTC Support subfield " - there is no such subfield Change "+HTC" to "+HTC-HT". Make similar changes at 1397.41 Discussion Agreed (see 883.44) ACCEPT Identifiers Comment Proposed change CID 5124 Stephens, Adrian 9.8 1308.17 "For or A-MSDUs belonging to the service class of QoSNoAck when the receiver is a QoS STA" Either there is a third condition to follow this one "service class of QoSNoAck and the receiver is not a QoS STA" or the constraint Either remove "when the receiver is a QoS STA", or add the missing third condition stated in the comment.
… … … … Wakeup Schedule 143 10 Yes Extended Schedule 144 17 to 257 STA Availability 145 4 to 257 DMG TSPEC 146 16 to 253 Next DMG ATI 147 8 Yes DMG Capabilities 148 19 Yes … … … … DMG Operation 151 12 Yes DMG BSS Parameter Change 152 9 Yes DMG Beam Refinement 153 7 Yes Channel Measurement Feedback 154 6 to 257 … … … … Awake Window 157 4 Yes 158 24 to 257 Yes ADDBA Extension 159 3 Yes NextPCP List 160 4 to 257 PCP Handover 161 15 Yes DMG Link Margin 162 10 Yes Switching Stream 163 6 to 257 Session Transition 164 13 Yes Dynamic Tone Pairing Report 165 34 Yes Cluster Report 166 3 to 257 Relay Capabilities 167 4 Yes Relay Transfer Parameter Set 168 10 Yes BeamLink Maintenance 169 3 Yes Multiple MAC Sublayers 170 8 to 254 Yes U-PID 171 11 Yes DMG Link Adaptation Acknowledgement 172 7 Yes … … … … Quiet Period Request 175 19 Yes … … … … Quiet Period Response 177 12 Yes … … … … Policy 182 13 or 17 Yes Cluster Time Offset 183 3 Yes Antenna Sector ID Pattern 190 6 Yes Cluster Probe ANA 11 Yes Extended Cluster Report ANA 15 or 20 Yes Cluster Switch Announcement ANA 16 Yes Reserved ANA–220
General Flow of the meeting Slides 13 and 14 of the 15/0735r1 contain general flow of the meeting. Monday Tuesday Wednesday Thursday AM1 TGax (ad hoc) TGax TGax AM2 TGax (PHY) TGax (MAC) PM1 TGax TGax (MU) TGax (SR) TGax (PHY) TGax (SR) TGax PM2 TGax (PHY) TGax (MU) PM3 TGax (PHY) TGax (MAC) Presentations Chittabrata Ghosh (Intel) presented “Discussion on Deep and Shallow Sleep States,” based on the submission 11-15-1100-02. Summary The Simulations Scenario document [1] described the common model parameters in Deep Sleep, Shallow Sleep, Listen, Receive, and Transmit states. This submission proposes: specific values for current consumption in Deep Sleep state, and to modify the current definition of Deep and Shallow Sleep states Discussions – No discussion. Chitto highlighted the changes. Straw Polls Straw Poll #1: Do you agree to define the current consumption value in Deep Sleep state in the Simulation Scenarios document as proposed in Slide 5? Discussion – no discussion. Result: No objection. Straw Poll #2: Do you agree to include the modified definition for Shallow and Deep Sleep state in the Simulation Scenarios document as discussed in Slide 6? Discussion: SSD editor asked how to modify the SSD. Result: No objection. Straw Poll #3: Do you agree to modify the transition time from Deep Sleep to Listen state in the Simulation Scenarios document as proposed in Slide 8? Discussion: Result: No objection. Kome Oteri (InterDigital) presented “Link level Simulation Assumption Updates to Evaluation Methodology,” based on the submission 11-15-1176-00. Summary
11-15-1375, “11ax Support for IoT - Requirements and Technological Implications,” Shimo Shilo (Huawei Technologies) (Late Submissions - not presented) 11-15-1386, “Hybrid Multiple Access in 802.11ax,” Yanyan Guo (BUPT) 11-15-1389, “TA Address Field in Trigger Frame,” Kaiying Lv (ZTE) Agenda items for the week Approve TG and Teleconferences minutes since September 2015 meeting. Continue to advance task group documents. Simulation Scenarios and Evaluation Methodology Channel Model Function Requirements Specification Framework Ad Hoc group meetings Technical Presentations and related straw polls and/or motions Schedule Teleconference times. General Flow of the meeting Slides 13 and 14 of the 15/0735r1 contain general flow of the meeting. Monday Tuesday Wednesday Thursday AM1 TGax (ad hoc) TGax TGax AM2 TGax (PHY) TGax (MAC) PM1 TGax TGax (MU) TGax (SR) TGax (PHY) TGax (SR) TGax PM2 TGax (PHY) TGax (MU) PM3 TGax (PHY) TGax (MAC) Presentations Chittabrata Ghosh (Intel) presented “Discussion on Deep and Shallow Sleep States,” based on the submission 11-15-1100-02. Summary The Simulations Scenario document [1] described the common power model parameters in Deep Sleep, Shallow Sleep, Listen, Receive, and Transmit states. This submission proposes: specific values for current consumption in Deep Sleep state, and to modify the current definition of Deep Sleep and Shallow Sleep states Discussions – No discussion. Chitto highlighted the changes. Straw Polls Poll #1: Do you agree to define the current consumption value in Deep Sleep state in the Simulation Scenarios document as proposed in Slide 5? Discussion – no discussion. Result: No objection.
8107 Stephens, Adrian 141.7 TGmc has changed single operand "floor()" and "ceil()" to use the equivalent glyphs throughout. See 1.5 in REVmc D4.0 Change all single-operand and ceiling functions to the glyph form throughout. Accepted How it looks like: PSnumber = floor(SBSTA/ PSlength) PSnumber =
IEEE P802.11 Wireless LANs 802.11 REVmc Initial Sponsor Ballot – MAC Comment resolutions Date: 2015-11-09 Author(s): Name Company Address Phone email Michael Montemurro BlackBerry Ltd 4701 Tahoe Blvd, Mississauga, ON. CANADA. L4W 0B4 mmontemurro@blackberry.com Comments "Specifies additional parameters associated with the block ack agreement." -- this is about as useful as a chocolate teapot. When you have nothing to say, say nothing. Ditto at 255.06, 256.23 and 257.46. Remove cited sentence. Discussion: Looks like a reasonable change. Proposed Resolution: Accept. Use of "block ack" without a noun to qualify it ambiguous. Does it relate to the mechanism, a specific agreement, a specific frame? Suggest that all such uses be qualified with one of these terms, rewording as necessary. Review all such uses and add qualifying noun where missing. Discussion: Proposed Resolution: Revised. Change all occurences of "Block ACK is" to "Block Ack agreement is" throughout the document. 2 0 3
Nothing seems to ever require its presence Proposed Text: Change the sentence in Section 10.1.4.3.2 of TGai D6.2 as follows: (P96L39) A FILS STA may indicate its MaxChannelTime in the Max Channel Time field of the FILS Request Parameters element of the Probe Request frame to prevent the responding STA from transmitting the Probe Response after the time indicated by the MaxChannelTime is elapsed. When the Max Channel Time field of the FILS Request Parameters element of the Probe Request frame is Present, the The Max Channel Time shall be set to the MaxChannelTime of the primitive as defined in 8.4.2.173 (FILS Request Parameters element). Comments (CID 10448) CID Clause Comment Proposed Change Proposed Resolution 10448 8.4.2.173 67 55 "of units of 200 [micro seconds]" --- why is 200 used as a basis. This seems akward. 100 would feel more natural and would make calculations much more easier replace 200 --> 100 Rejected See the rationale in 11-13/1431 Discussion on CID 10448 The Max Channel Time field is just 1 octet. If we use units of 100 μs, then the Max Channel Time field can indicate up to 25.5 ms. If we use units of 200 μs, then the Max Channel Time field can indicate up to 51.0 ms. In a very dense environment, it will take more time for channel access by the AP to transmit Probe Responses, and STA may not find some APs if we limit the Max Channel time value less than or equal to 25.5 ms. It is safe to use a little bit larger range, up to 51.0 ms for such dense environment. It is better to use units of 200 μs to allow enough range for Max Channel Time. Comments (CID 10236) CID Clause Comment Proposed Change Proposed Resolution
IEEE P802.11 Wireless LANs D6.0 Comment Resolution on some CIDs in Clause 8.4.2.173 and 10.1.4.3 Date: 2015-11-24 Author(s): Name Affiliation Address Phone email Jae Seung Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 1326 jasonlee@etri.re.kr Moon-Sik Lee ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 5966 moonsiklee@etri.re.kr Dong-Seung Kwon ETRI 161 Gajeong-dong, Yuseong-gu, Daejeon, Korea +82 42 860 6250 dskwon@etri.re.kr Comments (CID 10651, 10652, and 10653) CID Clause Comment Proposed Change Proposed Resolution 10651 10.1.4.3.2 102 39 If nothing happens by the end of the MinChannelTime, you just move on to the next channel. Therefore it is not true that MaxChannelTime indicates the time the transmitter of a probe will be available to receive the response Advertise MinChannelTime rather than MaxChannelTime, as this is the amount of time a scanning STA is guaranteed to be on the channel Rejected See the rationale in 11-13/1431r2 10652 10.1.4.3.4 103 35 If nothing happens by the end of the MinChannelTime, you just move on to the next channel. Therefore it is not true that MaxChannelTime indicates the time the transmitter of a probe will be available to receive the response Advertise MinChannelTime rather than MaxChannelTime, as this is the amount of time a scanning STA is guaranteed to be on the channel Rejected See the rationale in 11-13/1431r2 10653 10.1.4.3.4 104 2 If nothing happens by the end of the MinChannelTime, you just move on to the next channel. Therefore it is not true that Advertise MinChannelTime rather than MaxChannelTime, as this is the amount of time a Rejected See the rationale in 11-13/1431r2
SP Result: 41Y/1N/7A; SP passed SP #3: Do you support to add the following text in Section x.x.x in current SFD: A MU-MIMO user block includes a “spatial config” field of 4bit indicating the number of spatial streams for each multiplexed STA. The field is constructed by using the entries corresponding to the value of Nuser of this RU in the following table? Nuser B0…B3 Nsts[1] Nsts[2] Nsts[3] Nsts[4] Nsts[5] Nsts[6] Nsts[7] Nsts[8] #Entries 2 0000~0011 1~4 1 10 0100~0110 2~4 2 0111~1000 3~4 3 1001 4 4 3 0000~0011 1~4 1 1 13 0100~0110 2~4 2 1 0111~1000 3~4 3 1 1001~1011 2~4 2 2 1100 3 3 2 4 0000~0011 1~4 1 1 1 11 0100~0110 2~4 2 1 1 0111 3 3 1 1 1000~1001 2~3 2 2 1 1010 2 2 2 2 5 0000~0011 1~4 1 1 1 1 6 0100~0101 2~3 2 1 1 1 6 0000~0010 1~3 1 1 1 1 1 4 0011 2 2 1 1 1 1 7 0000~0001 1~2 1 1 1 1 1 1 2 8 0000 1 1 1 1 1 1 1 1 1 SP Result: 48Y/1N/10A; SP passed
IEEE P802.11 Wireless LANs Long Range Low Power (LRLP) Operation in 802.11: Use Cases and Functional Requirements: Guidelines for PAR Development Date: 2015-12-09 Author(s): Name Affiliation Address Phone email Tim Godfrey EPRI Michael Fischer NXP Semiconductors michael.fischer@nxp.com Chittabrata Ghosh Daniel Bravo Intel Yasantha Rajakarunanayake Mediatek Hongyuan Zhang Lei Wang Marvell Leileiw@marvell.com Nokia Corporation Minseok Oh Kyonggi University 154-42 Suwon-shi, Gyeonggi-do 16227, Republic of Korea msoh@kgu.ac.kr Youn-Kwan Kim The Catholic University of Korea 43 Jibong-ro Wonmi-gu, Buchun-shi, Gyeonggi-do, Korea ykkim123@catholic.ac.kr LRLP use cases and metrics Smart Grid
Some PatCom FAQ entries Some of FAQ entries are reproduced below (from the version as approved on 2015-09-01). 11. When does the IEEE send out a request for a Letter of Assurance? The Working Group chair or, where appropriate, the Sponsor chair will send out a request for a Letter of Assurance whenever the chair is notified, at any time and by any means, that the [Proposed] IEEE Standard may require the use of a potential Essential Patent Claim. 18. How do I find out if a particular company has submitted an Accepted Letter of Assurance? Accepted Letters of Assurance are listed on the IEEE-SA’s web site at . Letters of Assurance accepted after 31 December 2006 will be posted on the web site as they are accepted and Letters of Assurance accepted prior to that date will be posted over time. 64. Can a Working Group chair provide participants with a list of requested LOAs? Yes. The Working chair should maintain a list of the requests that the chair (or his/her designee) has made and the date of each request. The chair may make this information available to participants in the working group and should make it available to participants upon request. 65. How does a participant know if a Letter of Assurance has been requested from a particular company? A participant may ask the Working Group chair whether he or she has requested an LOA from that company. Accepted Letters of Assurance are available on the IEEE’s web site. Open LoA requests These are requests that the WG chair will take future action on in the form of a follow-up LoA request. 2018 Siemens Corporation TGax Holder notification via email 2018-03-20 Request for LoA Sent 2018-03-27 to Hans-Jeorg Meuller () Project TGax Cited Patent: US 2015/0212505 A1 Related to the dynamic transmit power adjustment feature Response from Hans-Jeorg Meuller () acknowledging reception Closed LoA requests – resulting in positive LoA 2018 Endiio Engineering GmbH Request for an LoA Sent 2018-02-27 to Tolgay Ungan () Project P802.11ba (Wake-up Closed. One accepted LOA was received on 2018-05-04. Microsoft 2015 TGai Request for LoA Sent 2015-08-15 to Project P802.11ai Cited patents:
2016-09-27 Telefon- aktiebolaget LM Ericsson 802.11ax 2016-10-07 Nokia Technologies Oy 802.11ah 2016-10-07 Nokia Technologies Oy 802.11ai 2017-03-15 InterDigital Patent Holdings Inc 802.11ax 2018-02-14 Panasonic Corporation 802.11ax 2018-02-14 Panasonic Corporation 802.11ay
Graham SMITH (90 mins) Editor Report: Review Draft was sent out to have a 2 week review of the comments that have been edited in. Need to have check done to allow for Dec Draft. Review Doc 11-15/1488r0 – Stephen MCCAAN CID 6200 and CID 6201 (MAC) Review comment Add to the proposed change as bullet #3 : “Authentication frame with Authentication Algorithm Number field equal to 1 (Shared Key) and AuthenticationTtransaction Sequence Number field equal to 3” Change bullet #1 from “this clause” to “Clause 11” Proposed Resolution: REVISED (MAC: 2015-12-08 14:17:50Z):; incorporate the changes as shown in 11-15/1488r1 < for CIDs 6200 and 6201. No objection – Mark Ready for Motion CID 6500 (MAC) Review Comment Discussion on the order field Concern on how the name is renamed (“Frame Control the Order/+HTC”). Changing to “Order/+HTC” was thought to be better than dropping the “order” sense entirely. Swap order of the name “+HTC/Order” as the name of the bit. Check the changes listed to look for any missing locations. Review of potentially duplicated sentences 615.36 and 620.18 Same in different figures but the description is the same. – Concern while valid is a different comment. Proposed Resolution: REVISED (MAC: 2015-12-08 14:26:09Z): Incorporate the changes as in 11-15/1488r1 for CID 6500. No objection – Mark for Motion That Clears the CIDs assigned solo to Stephen 6331 is working with Mark HAMILTON, Stephen has open action item to resolve. 6094 is working with Mark HAMILTON, but Mark has open action item to resolve. Review document 11-15/762r14 – Mark CID 6684 (EDITOR) Review comment 985.58 – concern on the plural – Change “recipients replies” with “recipient reply” etc. Drop semicolon and recipients, leaving “and does not reply otherwise”. 1869.22 change “so” to “therefore”
under the heading for CID 1238 to 2950. 1732 187.31 9.42.2.1 There is no "IE" in IEEE 802.11. Replace "IE" with "element" throughout the Accepted. 1950 208.53 9.42.2.1 I am a bit confused over this PRAW feature. Surely the idea of the STA is that it only does not wan t to listen to beacons because it to sleep for long periods, but here we have feature that sets up periodic slots for such STAs. Now these STAs sleep for long periods so they lose syncronization with the AP so have to now resync before they can use the PRAW allocation. BUT they have now sent a packet to find out when to send a packet. How is this PRAWs really useful? Al it seems to do is penalize TIM STAs by taking away time from them. Convince me that this is a good thing and really aids long term sleeping STAs Rejected. The comment failed to identify a real issue. In response to the commenter: Even non-TIM STAs are supposed to wake up and adjust its synchronization by checking TSF value before they totally lose synchronization. Therefore, current working assumption in TWT scheduling is that at least those non-TIM STAs can be in synchronized state and can wake up at their scheduled TWT timing. Therefore, assigning the TWT scheduled duration by PRAW can protect non-TIM STAs’ channel access. 2948 186.56 9.42.2.1 PRAW is no longer for non-TIM STAs only. Delete 'non-TIM' in the sentence. Accepted. 2949 186.57 9.42.2.1 Identical resource allocation' is not clear Specify that identical resource allocation may be refer to same RAW start time / RAW duration, etc. Further qualify that such resource allocation is only identical within the beacon interval of each PRAW period. Revised – Agree with the commenter in principle. TGah editor to make changes in 14/0298r0 under the heading for CID 1238 to 2950. 2950 187.10 9.42.2.1 PRAW update procedure is not clear Specify the PRAW update rules. Revised – Agree with the commenter in principle. TGah editor to make changes shown in 14/0298r0 under the heading for CID 1238 to 2950. Discussion:
2:30 CHEM M12H Substantial: DE; GE-A2 (Originator: Deanna Franke) 2:45 CHEM M13 Substantial: DE; GE-A2 (Originator: Deanna Franke) 3:00 CHEM M80 Substantial: (Originator: Deanna Franke) 3:15 CHEM M122 Substantial: (Originator: Deanna Franke) 3:30 General Business, Proficiency New: (Originator: Navreet Sumal) 3:45 General Business, Certificate of Achievement New: (Originator: Navreet Sumal) Business, AS New: (Originator: Navreet Sumal) Adjourned at __________pm
Yavapai-Apache Nation Special Business Meeting November 15, 2018 Revision 1 9:00 AM to 2:38 PM Middle Verde Administration Building Meeting called by: Chairwoman Jane Russell-Winiecki Note taker: Karla Reimer Agenda topics 1 1. Call to Chairwoman 5 2. Invocation 1 3. Roll Call Karla Reimer 10 4. Approval of Agenda 10 5. Minutes of 10-11-2018 30 6. Culture/History Vincent Randall 10 15 7. Approval of Resolution for an Independent Consultant Agreement for Alliant Insurance Services Inc. 8. Approval of Resolution for Application to the Freeport McMoRan Office for a Financial Contribution Christine Hurley & Lisa Bluelake Robert Mills 10 15 9. Approval of Resolution for an Independent Contractor Agreement with Christopher R. Corliss, CPA 10. Approval of Resolutions for Homes VII Low Income Housing Tax Credit Project a. Execution of Closing Documents Jaci Ulmer Sharie Benson
Form 10—Statement under Section 5(9A) of the Crown Proceedings Act 1958 in the Matter of a Forfeited Recognisance 22 Form 11—Order Forfeiting an Undertaking of Bail 24 Form 12—Notice to Surety of an Undertaking of Bail Forfeited in His or Her Absence 26 Form 13—Application to Vary or Rescind Order in the Matter of a Forfeited Undertaking 28 Form 14—Application for a Stay of Proceedings in the Matter of a Forfeited Undertaking 30 Form 15—Warrant of Seizure and Sale of Surety's Property for Moneys Due a Forfeited Undertaking of Bail 32 Form 16—Warrant to Seize Surety's Property for Money Due under a Forfeited Undertaking of Bail 34 Form 17—Warrant to Imprison Surety for Want of Seizure and Sale of Property Due a Forfeited Undertaking 36 Form 18—Notice to Member of the Police Force Executing Warrant to Imprison Against Surety of a Forfeited Undertaking 38 Form 19—Statement under Section 6(10) of the Crown Proceedings Act 1958 in the Matter of a Forfeited Undertaking 39 ═══════════════ ENDNOTES 41
holder of a mining licence that covers an area of 5 hectares or less that was granted before 1 February 2012, lodging a work plan under section 40 of the Act, must ensure it contains the information set out in Schedule 13AA.". 47 Technical reporting requirements for a mining licence of 5 hectares or less After regulation 27(7) of the Principal Regulations insert— "(8) Subregulation (1) does not to the holder of a mining licence that covers an area of 5 hectares or less that was granted before 1 February 2012.". 48 New Schedule 13AA inserted—work plan requirements for a mining licence of 5 hectares or less r. 48
which an offender is directed to attend for unpaid community work, treatment and rehabilitation or for any other purpose in accordance with the direction by the Secretary, Regional Manager, community corrections officer or other person authorised under the Act, these Regulations or the Corrections Act 1986 or the regulations made under that Act (as the case requires); prohibited poison any Schedule 8 Poison or Schedule 9 Poison within the meaning of the Drugs, Poisons and Controlled Substances Act 1981; the Act means the Sentencing Act 1991; r. 5 unauthorised area an area designated by the Regional Manager or a community corrections officer to be an unauthorised area. __________________ 6 Copies of community correction orders, drug treatment orders or orders in relation to fines r. 6
(f) the address and telephone number of the community corrections centre that the offender must report at; and Reg. 21(1)(g) revoked by S.R. No. 74/2012 reg. 13(4). * * * * * Reg. 21(1)(h) substituted by S.R. No. 74/2012 reg. 13(5). regulation 23 prescribes the obligations that the offender must comply with under the order; and date the order was made by the court; and date the order commences; and Reg. 21(1)(ja) inserted by S.R. No. 74/2012 reg. 13(6). period of the order; and signature of the proper officer constituting the who made the order; and name and signature of the offender (or if the offender is unable to sign the order, the signature of his or her legal practitioner) confirming the offender's consent to the order; and information the court thinks appropriate to include in the order.
Reg. 36 substituted by S.R. No. 74/2012 reg. 23. 36 Proper officer of sentencing court to fix date for transferred proceeding If a proceeding is transferred under section 83AJ(1) of the Act, the proper officer of the sentencing court must fix a date for the proceeding to be heard. Reg. 37 substituted by S.R. No. 74/2012 reg. 23. 37 Transfer of a proceeding r. 36 For the purposes of section 83AJ(1), the form of an order made by the Magistrates' Court that a proceeding be transferred is Form 1A in Schedule 1. Reg. 38 revoked by S.R. No. 74/2012 reg. 23. * * * * * __________________ 39 Review of a justice plan condition r. 39 For the purposes of section 82 of the Act, the form of the application is Form 2 in Schedule 1. Reg. 40 substituted by S.R. No. 57/2014 reg. 5.
Sentencing Amendment Regulations 2013, S.R. No. 73/2013 Date of Making: 25.6.13 Date of Commencement: 30.6.13: reg. 3 Sentencing Amendment Regulations 2014, S.R. No. 16/2014 Date of Making: 15.4.14 Date of Commencement: 19.4.14: reg. 3 Sentencing Further Amendment Regulations 2014, S.R. No. 57/2014 Date of Making: 17.6.14 Date of Commencement: Regs 5–7 on 1.7.14: reg. 3 ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– Explanatory Details Endnotes
does the receiving device know the TSF timer value of the transmitting STA? by concatenating the 4 octet TSF Completion field in the S1G Beacon Compatibility element with the Timestamp field in the S1G Beacon frame as described in 10.1.3.10.3 (TSF timer accuracy with S1G Beacon). TGah editor makes changes for Page 16 Line 14 sentence (from a table of sub-clause 6.3.3.3.2) as the following: “When a Short Probe Response or an S1G Beacon is received, the timestamp is the 4 least significant octets of the TSF timer value of the transmitting STA.” to “When a Short Probe Response or an S1G Beacon is received, the timestamp is reconstructed as described in 10.1.3.10.3 (TSF timer accuracy with S1G Beacon).” 8245 The replacement figure now conflicts with figure 9-2 in the base standard. This may be an in the editing instructions, intending that the new 9-1 replace both 9-1 and 9-2? Correct figure or editing instructions: either remove the content that replicates figure 9-2 in the base standard or change to "replace figure 9-1 and figure 9-2" Revised- Agree in principal. In the base standard, the DMG related figure was separated to Figure 9-2. TGah editor changes as shown in 8248 The text shown as NOT changed does not match the text in the base standard. (Tble 10-2 row 2). This makes applying the modified text and understanding the result impossible, or at least highly improbably. Delete all changes to cluase 10.2 Revised- Agree in principal. The text of Table 10-2 of the base standard has been updated. TGah editor changes as shown in 8249 It is not entirely clear what standard this amendment is amending. The draft states that "This Withdraw the from sponsor ballot, bring it in line with the base standrd being amended, and Rejected- All amendments developed in IEEE 802.11 WG are aligning
PMDIDList As defined in 8.4.2.185 (PMKID List element) As defined in 8.4.2.185 (PMKID List element) Data used by the FILS authentication algorithm. This parameter is optionally present if dot11FILSActivated is true; otherwise not present. Integer As defined in 8.4.2.171 (Association Delay Info element) Minimum association response timeout (in TU) that the non-AP STA sets to the value given by seTimeOut. AuthenticationType Enumeration OPEN_SYSTEM, SHARED_KEY, SAE, FILS_PUBLIC_KEY Specifies the type of authentication algorithm to use during the authentication process. Content of FILS Authentication Sequence of elements and fields As defined in 8.4.1.42 (Finite Cyclic Group field), 8.4.1.40 (Element field), 8.4.2.24 (RSNE), 8.4.2.171 (Association Delay Info element), 8.4.2.175 (FILS Session element), 8.4.2.183 (FILS Wrapped Data element), and 8.4.2.xxx (FILS Nonce element) The set of elements and fields to be included in the second message of the FILS authentication sequence, as described in 11.11 (Authentication for FILS). Present if AuthenticationType indicates FILS shared key authentication without PFS, FILS shared key authentication with PFS or FILS public key authentication; otherwise not present. 6.3.5.4 MLME-AUTHENTICATE.indication 6.3.5.4.2 Semantics of the service primitive Modify as following: [3, 5, 6] MLME-AUTHENTICATE.indication( PeerSTAAddress, AuthenticationType, AuthenticateFailureTimeout,
Koichi Ishihara +81 46 859 4233 ishihara.koichi@lab.ntt.co.jp Junichi Iwatani +81 46 859 4222 Iwatani.junichi@lab.ntt.co.jp Akira Yamada NTT DOCOMO 3-6, Hikarinooka, Yokosuka-shi, Kanagawa, 239-8536, Japan +81 46 840 3759 Masahito Mori Sony Corp. Masahito.Mori@jp.sony.com Yusuke Tanaka Yuichi Morioka Yuichi.Morioka@jp.sony.com Kazuyuki Sakoda William Carney Preface Revision history Revision Date Changes 0 January 15, 2016 Initial draft Notation Editing instructions are shown in bold italic. Editor’s notes in red bold italics are provided to aid in drafting the document. For example, missing text or indicating the placement of future text. Baseline document This document is written as an amendment to the Draft P802.11-REVmc/D4.00 revision of the 802.11 specification.
PHY service interace Introduction TXVECTOR and RXVECTOR parameters The parameters in Table 251 (TXVECTOR and RXVECTOR parameters) are defined as part of the TXVECTOR parameter list in the PHY-TXSTART.request primitive and/or as part of the RXVECTOR parameter list in the PHY-RXSTART.indication primitive. Table 251 - TXVECTOR and RXVECTOR parameters Parameter Condition Value TXVECTOR RXVECTOR FORMAT Determines the format of the PPDU. Enumerated type: NON_HT indicates Clause 18 (Orthogonal frequency division multiplexing (OFDM) PHY specification) or non-HT duplicate PPDU format. In this case, the modulation is determined by the NON_HT_MODULATION parameter. HT_MF indicates HT-mixed format. HT_GF indicates HT-greenfield format. VHT indicates VHT format. HE_SU indicates HE SU PPDU format. HE_MU indicates HE MU PPDU format HE_EXT_SU indicates HE Extended Range SU PPDU format HE_TRIG indicates HE Trigger-based PPDU format Y Y PE_DURATION FORMAT is HE_SU or HE_MU or HE_EXT_SU or HE_TRIG. Determines the duration of PE field in an HE PPDU. Possible values are 0 µs, 4 µs, 8 µs and 16 µs. BEAM_CHANGE FORMAT is HE_SU Indicates beam change between pre-HE and HE modulated fields. 1 indicates that the beam is changed between the two portions. NOTE— BEAM_CHANGE shall be set to 1 if NSS > 2 or the PPDU is the first PPDU in a TXOP. Otherwise Set to 1
Mark Hamilton (Ruckus Wireless) Architecture (ARC) Chair +1 (303) 441-7553 Andrew (Cisco Systems, Inc.) ISO/IEC/JTC1/SC6 shadow committee (JTC1) Chair +61 2 84461010 Rich Kennedy (Unlicensed Spectrum Advocates) Regulatory Chair +1 (832) 298-1114 Jon Rosdahl (Qualcomm ) Project Authorization Request (PAR) review Chair +1 (801) 492-4023 Task Groups Name (Affiliation) Position Contact Details Dorothy V. Stanley (HPE) TGmc Chair (Revision mc) +1( 630) 363-1389 Yongho Seok (Self) TGah Chair (Sub 1 GHz Operation) +82-10-7581-0828 Hiroshi Mano (Koden Techno Info K.K.) TGai Chair (Fast Initial Link Setup) +81-3-5436-8350 Xiaoming Peng (Institute for Infocomm Research) TGaj Millimeter Wave) +65-64082429 Donald Eastlake, 3rd (Huawei Technologies) TGak Chair (General Link) +1 508-333-2270 Stephen McCann (BlackBerry Ltd.) TGaq Chair (Pre-association Discovery) +44 1753 667099 Aboul-Magd (Huawei) TGax Chair (pro-tem) (High Efficiency WLAN) +1 (613) 287-1405 Edward Au (Huawei) TGay Chair (Next Generation 60 GHz) +1 773 782 6875 Jonathan Segev (Intel Corporation) TGaz Chair (Next Generation Positioning) +972-54-2403587 Study Groups Name (Affiliation) Position Contact Details Interest Groups Name (Affiliation) Position Contact Details Tim Godfrey (Electric Power Research Institute) Long Range Low Power (LRLP) TIG +1 (650) 855-8584 (office) Liaison Officials to non IEEE 802 organizations Name (Affiliation) Position Contact Details
TGah Editor: Please make the following changes to figure 8-577bv-Relay Discovery Info field format as follows in D5.1 Change “Information Not Available field” bit4 and “optional Information Not Available field” bit5 to “Reserved” in figure 8-577bv-Relay Discovery Info field format on page 176 line TGah Editor: Please delete the last two paragraph of 8.4.2.204 S1G Relay Discovery element in page 176 line 30-36 in D5.1as below: “The Information Not Available field is set to 1 if the relay cannot provide the requested information in the fixed fields of S1G Relay Discovery element. Otherwise, the Information Not Available field is set to 0. The Optional Info Not Available is set to 1 if the relay cannot provide the requested information in the optional fields. Otherwise, the Optional Info Not Available field is set to 0.”
Channel Width Indicates the width of the channel in which the measurement to create the compressed beamforming feedback matrix was made: Set to 0 for 20 MHz Set to 1 for 40 MHz Set to 2 for 80 MHz Set to 3 for 160 MHz or 80+80 MHz … Codebook Information Indicates the size of codebook entries: If Feedback Type is SU: Set to 0 for 2 bits for ψ, 4 bits for  Set to 1 for 4 bits for ψ, bits for  If Feedback Type is MU: Set to 0 for 5 bits for ψ, 7 bits for  Set to 1 for 7 bits for ψ, bits for  … … TGah Editor: Remove text (#8080):
Discussion - No discussion. Result: Y/N/A = 28/2/many Straw Poll #2: Do you agree the following text? LDPC is the only coding scheme in the HE PPDU Data field for allocation sizes more than 242 tones when multiple RU allocation is allowed to a user. Discussion Since the SP#1 passed, this straw poll was withdrawn. Jianhan Liu (MediaTek) presented “On QPSK DCM Modulation and LDPC Tone Mapper for DCM,” on the submission 16/0056r0. Summary DCM Modulation schemes and LDPC tone mapping parameters have not yet been defined in 11ax SFD. QPSK DCM modulation scheme and LDPC tone mapper in this contribution proposed. Discussion – No discussion. Poll Straw Poll #1: Do you agree to add the following QPSK DCM modulation scheme to the IEEE802.11ax SFD? The coded/interleaved bits are modulated as QPSK and mapped to the lower half frequency segment: [d1, d2, … dN_SD/2]; The modulated symbols of the lower half frequency segment are repeated and conjugated and then mapped to the upper half frequency segment: [dN_SD/2+1, dN_SD/2+2, … dN_SD] = conj([d1, d2, … dN_SD/2]) Discussion – No discussion. Result: Y/N/A = 71/0/16, this poll will be converted to a motion. Straw Poll #2: Do you agree to add the following LDPC Tone Mapping parameters DTM for DCM modulations to the IEEE802.11ax SFD? Discussion – No discussions. Result: Y/N/A = 76/0/21, this straw poll will be converted to a motion. AOB PM2: One presentation by Reza Recess until PM2 (16:00) today.
NDP CTS training frames.” 8334 P325 L43 9.50.5.2 "This use of ""signal"" seems in conflict to the use of signal later in this subclause (""received signal quality""). The former seem to infer ""indicate"" while the later seems to refer to ""electromagnetic waves""." Use "indicate" when that is the intent. Revised. Instruct the editor to replace the sentence by “The STA may use the Sector ID feedback frame (see 8.6.25.11 (Sector ID Feedback frame format)) to indicate to the AP which sector is selected.” 8335 P325 L49 9.50.5.2 "This use of ""signal"" seems in conflict to the use of signal later in this subclause (""received signal quality""). The former seem to infer ""indicate"" while the later seems to refer to ""electromagnetic waves""." Use "indicate" when that is the intent. Revised. Instruct the editor to replace the sentence by “By setting the MAI=14 in the Link Adaptation Control subfield of the HT Variant Control field, the STA indicates the HT variant control field is used for sector training (or Antenna Selection) information.” 8452 P324 L32 9.50.4 Four SO sequences are discussed in 9.50.4, all containing an and a sectorized portion, it is much easier to include an early sector indication in the transmissions of the existing portion of the SO, instead of using a separate CTS to self, since using an extra will provide the same function but with higher overhead Include early sector indication in the transmissions in the omni-directional portion of the SO sequence exchanges, to provide the same indication of sectorized transmissions but with reduced overhead. Rejected- Reject. There is no more bit left in the SIG A for signaling sectorized transmission. 8180 9.50.4 Figure 9-98 doesn't follow IEEE-SA style. Remove the shading in three places. Revised. Instruct the editor to replace Figures 9-98, 9-99, 9-100, and CID 8180: Instruct the editor to replace Figures 9-98, 9-99, 9-100, 9-101 Figure 9-98
IEEE P802.11 Wireless LANs REVmc - BRC Minutes for January 2016 - Atlanta Date: 2016-01-23 Author(s): Name Affiliation Address Phone email Jon Rosdahl Qualcomm Technologies Inc. 10871 N 5750 W Highland, UT 84003 +1-801-492-4023 jrosdahl @ ieee . org REVmc BRC F2F in Atlanta, GA – 18 January 2016 – PM2 – 16:00 Called to order by the chair, Dorothy STANLEY (HPE) at 16:00 Review Patent Policy – 5 slides reviewed. No issues noted. Introduction of TG officers Chair - Dorothy STANLEY – HPE Vice - Jon ROSDAHL – Qualcomm Vice Chair – Mark Hamilton – Ruckus Wireless (Not Present this week). Editor – Adrian Stephens – Intel Editor - Emily QI – Intel Editor - Edward AU - Huawei Review of Objectives Ballot is currently open Encourage to review and comment on ballot This week to review items not directly related to ballot comments Review Agenda – 11-15/ Monday PM2 Chair’s Welcome, Status, Review of Objectives, Approve agenda Editor’s Report Presentations 11-15/1274 – ACK frame –Graham SMITH 11-16/117, EIFS CID 5966 Menzo WENTINK Tuesday PM2 Presentations 11-15/1530 – VHT 160MHz signaling Menzo WENTINK 11-16/106, 107 Probe dwell time – Peter KHOURY Wednesday PM2 Presentations ARC proposed changes, see 11-15/540 – Joseph LEVY 11-15/1184r5 – OWE – Dan HARKINS Thursday PM1 Presentations Motions Plans for Jan – March Schedule AOB, Adjourn Call for additional presentations
4 Request Extended Capabilities Extended Capabilities element 5 Request BSS Load BSS Load element 6 Request EDCA Parameter Set EDCA Parameter Set element 7 Request Supported Operating Classes Supported Operating Classes element Table 8-248w—Probe Response Option Bitmap subfield(#8103) 3 Bit position Subfield Meaning Definition 0 Measurement Pilot Transmission element 1 Multiple element 2 RM Enabled Capabilities element 3 Request AP Channel Report AP Channel Report element 4 Request BSS Average Access Delay BSS Average Access Delay element 5 Request Antenna Antenna element 6 Request BSS Available Admission Capability BSS Available Admission Capacity element 7 Request BSS AC Access Delay BSS AC Access element Table 8-248x—Probe Response Option Bitmap subfield(#8103) 4 Bit position Subfield Meaning Definition 0 Mobility Domain element 1 QoS Traffic Capability element 2 Channel element 3 Request Time Advertisement Time Advertisement element 4 Request Time Zone Time Zone element
5 Request IBSS Parameter Set IBSS Parameter Set element 6-7 Reserved Reserved Table 8-248y—Probe Response Option Bitmap subfield(#8103) 5 Bit position Subfield Meaning Definition 0 Interworking element 1 Advertisement Protocol element 2 Roaming Consortium element 3 Request Emergency Alert Identifier Emergency Identifier element 4 Request QLoad Report QLoad Report element 5 Request Multi-band element 6 Request Multiple MAC Sublayers Multiple MAC Sublayers element 7 Request Reduced Neighbor Report Reduced Neighbor Report element CID 8128 CID Clause Page Comment Proposed Change Proposed Resolution 8463 347 65 The behavior of the active-scanning STA after receiving short Probe Response frame vs. Probe Response frame is mixed and as a result, the description for the procedure is very confusing. It should be clearly described. Change "Otherwise, if it receives (Short) Probe Response frame, the STA may transmit a Probe Request frame/Association Request frame or listen to a full Beacon frame for obtaining the more information." into "Otherwise, if it receives a Short Probe Response frame, the STA may transmit a Probe Request frame/Association Request frame or listen to a full Beacon frame to obtain more information. If it receives Probe Response frame, the Revised – TGah Editor to make changes in 131r0.
IEEE P802.11 Wireless LANs IEEE 802.11 TGax, MU Ad hoc January 2016 Atlanta TGax MU Ad hoc Meeting Minutes Date: 2016-01-19 Author(s): Name Affiliation Address email Kaushik Josiam Samsung k.josiam@samsung.com Kiseon Ryu LG kiseon.ryu@lge.com Sigurd Schelstraete Quantenna Communications sigurd@quantenna.com IEEE 802.11 Task Group ax, MU Ad hoc January 2016 Atlanta Meeting January 18th – 22nd, 2016 MU Adhoc Session #1 Tuesday, January 19th, 2016, PM3 TGax Session (7:30 – 9:30PM) The meeting called to order by Sigurd Schelstraete (Quantenna), the co-chair of the TGax MU Ad hoc At 8:30 pm, 157 people are present. Announcement Agenda Doc.11-15/0147 on the server. Rev. 0 is the working document. Meeting Protocol: The asked to state name and affiliation when speaking for the first time. Attendance reminder. The attendance server: https://imat.ieee.org/ The chair reviewed the mandatory 5 slides of P&P. Instructions from the WG Chair. [reviewed, did not review] Participants, Patents, and Duty to Inform. [reviewed, did not review] Patent Related Links. [reviewed, did not review] Call for potentially essential patents. Chair asked if anyone is aware of potentially essential patents Did not ask] Potentially essential patents [None reported. Reported as follows] Other Guidelines for IEEE WG Meetings.
Wednesday- Jan 27, 2016 TGaj Session in Harbin China Called to order at 13:30pm Beijing Standard Time Number of Attendees: 11 LB217 Comment Resolutions on CIDs 87-95 in 11-16/0206r0 by Dejian Li (Huawei) Proposes 7 editorial comments and 2 technical comments. Comment “operating a infrastructure BSS” in CID 91 should be changed to “operating an infrastructure BSS”. If you add new changes beyond the suggested remedy, you should change “Accept” to “Revised”. Also, the new changes should be properly marked in the comment database. Q: For CID 95, this is a similar comment with a CID in Jiamin’s proposal? A: Yes, this is a similar comment, but they are different. Resolutions for CID2-7 comments on 11aj in 11-16/0209r2 by Shiwen HE (SEU) Proposes resolutions for 5 technical comments Comment No comments. Discussion on comments database of LB217 for 11aj D1.0 in 11-16/0193r1 by Jiamin Chen (Huawei) Comment Q: what is the relationship between a CDMG and DMG? A: A commenter suggests to define “a CDMG STA is a DMG STA with some new features” in Clause 4. Q: Is there a Group ID field in 11ad. A: No, there is no “Group ID” in 11ad. Q: QMG STAs uses the DMG Beacon frame? A: Yes. Q: Discussions on resolution to CID 30, requests to Clarify how the existing RSN operations work in QMG BSS and update RSNE/security clauses for QMG, if needed, similarly to how P802.11ad updated them for DMG.
field for S1G MU PPDUs using S1G_LONG. Rate-dependent parameters for the full set of S1G-MCSs are shown in Table 24-38 (S1G MCSs for 1MHz, Nss Nss= 1) to Table 24-57 (S1G MCSs for 16MHz, Nss Nss = 4) (in 24.5 (Parameters for S1G-MCSs)). These tables give rate-dependent parameters for S1G-MCSs with indices 0 to 9 (and index 10 solely for 1MHz, N SS Nss = 1), with number of spatial streams from 1 to 4 and bandwidth options of 1 MHz, 2 MHz, 4 MHz, 8 MHz and 16 MHz. Equal modulation (EQM) is applied to all streams for a particular user.
RESOLUTION: OPTION A REJECT The set of data rates in the OperationalRateSet and the BSSBasicRateSet are limited to the rates as per Table 6.5.5.2 which is a superset of the dot11SupportedDataRatesRXTable. This is stated in the text for “9.4.2.3 Supported Rates and BSS Membership Selectors element” and “9.4.2.13 Extended Supported Rates and BSS Membership Selectors element” where the supported rates are provided. Hence, further clarification is not necessary. OPTION B P201.54 Add the following to the “Valid Range” entry of “BSSBasicRateSet”: “Only data rates present in dot11SupportedDataRatesRxTable and dot11SupportedDataRatesTxTable may be present” Identifiers Comment Proposed change CID 7292 Mark Rison 6.5.4.2 534.28 "The delay, in microseconds, from a point in time specified by the PHY to the issuance of the PHY-RXSTART.indication primitive." -- none of the PHYs do so Change to "The delay, in microseconds, from the start of the PPDU at the receiver's antenna to the issuance of the primitive." Discussion: A search for “from a point in time” indeed shows that this is the only place in the Standard this expression is used. RESOLUTION: ACCEPT Identifiers Comment Proposed change CID 7360 Mark Rison G.2 3402.42 "Except where modified by the pifs attribute, frames are separated by a SIFS" -- so no frame exchange sequences involving RIFS are allowable? Append "or RIFS" Discussion: “G.2 Basic sequences The allowable frame exchange sequence is defined by the rule frame-exchange-sequence. Except where modified by the pifs attribute, frames are separated by a SIFS.” 10.3.2.3.2 RIFS The use of RIFS is obsolete, and support for such use might be subject to removal in a future revision of the standard. A VHT STA shall not transmit frames separated by a RIFS. RIFS is a means of reducing overhead and thereby increasing network efficiency. RIFS may be used in place of SIFS to separate multiple transmissions from a single transmitter,
“The use of RIFS in the 2.4 GHz and 5 GHz bands is obsolete, and support for such use might be subject to removal in a future revision of the standard.” AND P3402.42 Add “and RIFS” at end of sentence to read as follows: “Except modified by the pifs attribute, frames are separated by a SIFS or RIFS.” Identifiers Comment Proposed change CID 7361 Mark Rison 10.3.2.3.2 1270.33 "The use of RIFS is obsolete" -- even for DMG? After "RIFS" add "in the 5 GHz band" Discussion: Depends on whether RIFS was made obsolete (first appears in D3.0) with votes that included DMG participants. MARK See Carlos’ email. RESOLUTION: OPTION A REJECT RIFS is obsolete even for DMG OR OPTION B REVISED P1270.34 Edit as follows: “The use of RIFS in the 2.4 GHz and 5 GHz bands is obsolete, and support for such use might be subject to removal in a future revision of the standard.” Identifiers Comment Proposed change CID 7373 Mark 11.2.3.5 1602.13 "BUs may be sent to STAs in active mode at any valid time." -- and what's a "valid time"? Delete the sentence Discussion: “If power management is in use within an IBSS, a STA shall buffer individually addressed BUs for STAs that are known to be in PS mode. BUs may be sent to STAs in active mode at any valid time.”
CID 7324, 7378, 7553, 7658, 7807, 7816, 7317 (all MAC) assign to Mark HAMILTON CID 7437(GEN), 7438(GEN), 7767(Editor), 7355(GEN), 7698(GEN) assign to Edward AU CID 7649(GEN), 7346(MAC) – Dorothy STANLEY CID 7038, 7039, 7043, 7212, 7434, 7435, 7580, 7581, 7822 , 7279, (MAC) – assign to Graham SMITH CID 7176(MAC) Pyam CID 7316, 7590(MAC) – Emily QI CID 7468, 7812, 7276 – assign to Mark Rison CID 7577, 7805 – assign to Sigurd CID 7676 – Assign to Peter E. CID 7276 – Assign to Carlos Aldana CID 7219 – Assign to Guido Adjourned at 3:09pm References: Monday: https://mentor.ieee.org/802.11/dcn/16/11-16-0268-00-000m-resolution-for-cid-7090-d5.docx Tuesday: Wednesday: