zilongwang/ReadingBank huggingface dataset:
Pedestrian Internet access Pedestrian Information Access/Distribution (including both public and private sector uses) Transition to 802.11 from other communications technologies (e.g. cellular) Vehicular: Some of these applications do not truly require the low latency proposed for 11ai, but would be “bundled” with the more demanding applications in same device. If they may benefit from the added performance achievable with 11ai they are included here. Some of these are adequately supported by 11p but are included here to assist in establishing the bounds of TGai (e.g. establishing low limits as well as high limits on latency for 11ai). Probe data collection Rollover warning Traffic information Low bridge warning Toll collection Mainline screening Traveler information Border clearance In-vehicle signing Work zone warning Highway/rail intersection warning Road condition warning Vehicle safety inspection and safety data transfer Intersection collision avoidance (primarily or only 11p) Driver’s daily log Vehicle to vehicle (primarily or only 11p) Vehicle stopped or slowing Collision avoidance Transit vehicle data transfer (on route, at gate, and refueling) Road infrastructure support (e.g. Signal Timing Optimization, Corridor Management, Load Balancing, and Winter Maintenance) Transit vehicle signal priority Ramp metering Emergency vehicle signal preemption Gas and drive-through payment Emergency vehicle video relay Parking lot payment responder/emergency vehicle on-site networking Navigation (various forms) Vehicle data transfer (PCI, IDB, J1939, etc.) Access control ATIS data Diagnostic data Unique CVO fleet management
IEEE P802.11 Wireless LANs Use Case Reference List for TGai Date: 2011-03-1 Author(s): Name Affiliation Address Phone email Tom Siep CSR, plc 3779 Pecan Acres Dr, Farmersville, Tx, USA +1 214 558 4358 Tom.Siep@ieee.org
dot11NbrOfChangeBeacons BIs with the Old BSSIDset to the BSSID of the PBSSset to the MAC address of the candidate PCP, and the Remaining BIs field within the PCP Handover element set to the number of BIs remaining until the candidate PCP takes over the role of PCP for the PBSS‘s PCP.The initial value of the Remaining BIs field shall be equal to the Remaining BI field value last transmitted by the PCP in a the Handover Remaining BI field within the last transmitted Handover Request frame to the candidate PCP or equal to the Remaining BI field value last received by the PCP in the Handover Remaining BI field within the last received a Handover Request frame from the candidate PCP, whichever is later. A non-PCP STA receiving a DBand Beacon or Announce frame containing the PCP Handover element shall set the STA‘s local countdown counter to the value of the Remaining BIs field contained in the PCP Handover element. The STAs shall then decrease the local countdown counter by one at each TBTT and shall use the candidate PCP‘s address found in the New PCP Address field contained in the PCP Handover element as the new beacon filter address once the STA‘s local countdown reaches zero. When the countdown timer hits equals zero, the candidate PCP shall assume the role of PCP. In Annex D: Change the default values of MIB variable dot11MaxLostBeacons from “4” to “8”. Change the default of MIB variable dot11ImplicitHandoverLostBeacons from “8” to “4”.
Insert a new row in to 10-5 as indicated: Table 10-5—Types of Block Ack agreement based on capabilities and ADDBA conditions Capabilities condition ADDBA condition Type of Block Ack agreement One or both of the STA are non-HT. Block Ack Policy subfield equal to 1 Immediate Block Ack Policy subfield equal to 0 Delayed Both STAs are HT STAs. Block Ack Policy subfield equal to 1 HT-Immediate Both STAs are HT STAs, and both of the STAs set the HT-Delayed Block Ack subfield of the HT Capabilities element to 1. Block Ack Policy subfield equal to 0 HT-Delayed Both STAs are HT STAs, and at least one of the STAs sets the HT-Delayed Block Ack subfield of the HT Capabilities element to 0. Ack Policy subfield equal to 0 Delayed Both STAs are robust AV STAs and the agreement was established using Extended ADDBA Request/Response frames. Block Ack Policy subfield equal to 1, ADDBA GCR Group Address Present subfield equal to 1 GCR-Immediate
IEEE P802.11 Wireless LANs 11ac GID Date: 2011-03-xx Author(s): Name Affiliation Address Phone Email Simone Merlin Qualcomm Inc 5775 Morehouse Dr San Diego, CA 92109 8588451243 Abstract This document provides resolution for the comments listed below. Notes on this document: Comments are from: 11-11-0276-00-00ac-tgac-d0-1-comments.xls. Comments refer to: Draft P802.11ac_D0.1.pdf. In providing instruction for spec editing, the following conventions are used. Red text indicates changes to be applied to existing text in Draft P802.11ac_D0.1.pdf. Text in blue is text copied from the 802.11n-2009 baseline that was not shown in the 11ac draft and that need be added to the draft, with the modifications shown in green. Text in black is unmodified text from Draft P802.11ac_D0.1.pdf. Italic light gray text indicates instruction to the editor. GID description: 972, 986 972 22.3.9.2.3 101 18 TR "A value of 63 (all ones) indicates: A single user transmission A transmission where the group membership has not yet been established A transmission that needs to bypass a group (e.g. capture motion text: "In a SU VHT PPDU, if the PPDU carries MPDUs addressed to an AP STA, the GROUP ID field is set to all zeros, otherwise it is set to all ones" Agree. Modified text to match the motion PHY
IEEE P802.11 Wireless LANs D0.1 Comment Resolution for ID Management Date: March 14, 2011 Author(s): Name Affiliation Address Phone Sameer Vermani Qualcomm svverman@qualcomm.com Santosh Abraham Qualcomm sabraham@qualcomm.com Simone Merlin Qualcomm smerlin@qualcomm.com CommentID Subclause Page Line CommentType Comment SuggestedRemedy Response 772 7.4.12.3 37 29 TR Define this frame using the standard format define new management and use a table to include the field into the new action frame Added table and diagram in proposed text 1046 7.4.12.3 37 29 TR Exact definition of Group ID field is required. The value of 0~62 should indicate Group ID of individual groups. Group ID 63 Explicitly describe the meaning of the value 0~62 and especially 63. Added text to clarify this.
1153 7.4.12.3 37 31 TR The Group ID management frame is inadequately defined. Define frame format. For ease of parsing the should have a 8 octet membership status array (1 bit per subfield for 64 groups) and a 16 octet STA position array (2 bits per STA position for 64 groups). Both arrays are indexed by Group ID. Added table and diagram. 1154 7.4.12.3 37 31 TR The Group ID management frame needs to be classified for management frame encryption. this is a real-time frame - table update is immediate on receipt of the frame - the frame should be classified as Agree in principle. This classification might happen in a different section 225 7.4.12.3 37 32 TR "shall" shall not be used in section 7. Replace "in such frames shall consists of" with "includes" Removed “shall”. 226 7.4.12.3 37 32 TR The frame format of Group ID management frame is not properly defined. Insert a table to define the action frame body. Added table 227 7.4.12.3 37 32 TR The format of the ID Assignment field is not properly defined. Insert a figure to illustrate the ID assignment field. Added figure.
1262 7.4.12.3 37 33 TR "The frame body in such frames shall consist of a" - WG802.11 style is to avoid all normative language in Clause old 7, with one "shall" in old 7.1. Convert all shalls related to structure in clause 7 to declarative language. Move all shalls related to behaviour out of clause 7. Removed 1263 7.4.12.3 37 34 ER A picture or would be nice add one Added 1483 7.4.12.3 37 38 TR "STA position" is the name of 2bit subfield. 2 bits "STA position" that specifyies spatial time stream position of the STA in the corresponding group ID Clarified text. 807 7.4.12.3 54 40 ER There are 24 octets carrying 3 bits of STA info/group so the exact location of the above fields within the frame body should not be TBD Remove the sentence Added diagrams and removed TBD. 1265 7.4.12.3 37 40 TR TBDs resolve them Removed all TBDs. 710 7.4.12.3 37 41 ER TBD should not exists in the standard Define appropriate value for TBD fields. Defined.
44 Asai, Yusuke 7.4a.1 38 30 TR There is no definition of the value of "EOF pad". Add the definition of the bit pattern of "EOF Pad". It seems that one of the possible patterns is "all zero". Disagree It is implementation dependent. Same as Qword pad for subframe 773 u, Yong 7.4a.1 38 46 TR The "last subframe" is not very accurate here. The EOF delimiter can also be considered as a zero length subframe. change to "the last length subframe" Agree Change to “the last subframe with non-zero MPDU length” MPDU MPDU MPDU MPDU MPDU
IEEE P802.11 Wireless LANs CID1559, 207 Date: 2011-03-14 Author(s): Name Affiliation Address Phone Sun Bo ZTE Corporation #10, ZTE Building, Sth Tangyan Rd., Hi-Tech Industries Part, Xi’an, China 86 29 88354130 Abstract This document provides resolution for the comments listed below. on this document: Comments are from: 11-11-0276-00-00ac-tgac-d0-1-comments.xls. Comments refer to: Draft P802.11ac_D0.1.pdf. In providing instruction for spec editing, the following conventions are used. Red text indicates changes to be applied to existing text in Draft P802.11ac_D0.1.pdf. Text in blue is text copied from the 802.11n-2009 baseline that was not shown in the 11ac draft and that need be added to the draft, with the modifications shown in green. Text in black is unmodified text from Draft P802.11ac_D0.1.pdf. Italic light gray text indicates instruction to the editor. 1559 Sun, Bo 22.3.11.4.2 117 51 TR "Using equation 22-47 instead of Equation 20-35" is not appropriate. If we use Equation 22-47 following 22-48 to calculate Npld, we will find Nsym,init is divided by Mstbc once more which changes the meaning of Npld. And this sentence implies that we calculate Navbits using Equation 20-36 as 11n. Actually, as we have achieved Nsym,init ,the calculation of the Navbits could be simplified to Navbits=Nsym,init*NCBPS, instead of using Npld to calculate as 20-36 1). modify equation 22-47 as "Npld=Nsym,init*NDBPS" and move the text in pg117/ln59 to pg118/ln10. 2). Insert following sentence in pg118/ln11 after the equation 22-48: "Following the Npld calculation, Navbits for VHT packets shall be computed using Equation (22-xx) instead of Equation (20-35). Navbits=Nsym,init*NCBPS (22-xx)" See discussion PHY
398 Hart, Brian 22.3.9.2.3 103 5 TR "BF steering matrix … in 20.3.11.10.1" yet 20.3.11.10.1 describes both CDD and Q (called "spatial mapping matrix") but not BF steering matrix Use consistent terminology: e.g. both spatial mapping matrix or BF steering matrix. Proposed resolution: Disagree Discussion: From 11n, “spatial mapping” and “spatial mapping matrix” are general terms, whereas a BF steering matrix is a matrix that improves reception based on some knowledge of the channel.Thus there is a need for two terms and usage in 11ac is unchanged from usage in 11n. 20.3.11.10.1 in 11mb4.01 does describe the Beamforming steering matrix. 402 Hart, Brian 22.3.9.2.3 103 30 TR For clarity, write "The first and second half of the stream of …" As in comment Proposed resolution: Agree in principle Discussion: changes can go further than proposed to maximize clarity Change The stream of 96 complex numbers generated by steps is divided into two groups of 48 complex numbers d_{k,n}, k=0…47, n=0,1 . 404 Hart, Brian 22.3.9.2.4 104 48 TR "replicating it in each 20 MHz band" sounds like freq shifting is happening as a byproduct Remove "frequency shifting" Proposed resolution: Agree in principle Discussion: greater clarity is possible by keeping the language but moving it around. 11n used “duplicating and frequency shifting and by rotating the upper subcarriers by 90deg”, but this language cannot be directly generalized and the repeated “and”s is inelegant. The new text does preserve the “duplicate”verb, in part because “replicate in each ...band”is not a proper use of “replicate”. Change: In 40 and 80 MHz transmissions, the VHT-STF is constructed from the 20 MHz version by frequency shifting, and applying appropriate phase rotations 20MHz sub-band. 407 Hart, Brian 22.3.9.2.4 106 7 TR "QAM mapper outputs" yet BPSK is an allowed constellation QAM mapper => constellation mapper Proposed resolution: Accept
1309 Stephens, Adrian 22.3.16 136 31 TR "The transmitter RF shall follow 17.3.8.5." normative verbs are reserved for description of the behaviour of behavioural protocol entities. And an RF delay is not such Reword so that it relates to STA behaviour or turn into a declarative statement Proposed resolution: in principle Change: 22.3.16 Transmit RF delay The transmitter RF delay 17.3.8.5. 22.3.17 Slot time The slot time is defined in 17.3.8.6. 487 Hart, Brian 22.3.19.1 136 53 TR default is undefined. default => 802.11 Proposed resolution: Accept in principle Change: 22.3.19.1 Transmit spectrum mask NOTE 1–In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements and the mask defined – i.e., emissions can be no higher at any frequency offset than the minimum of the values specified in the regulatory and mask. 490 Hart, Brian 22.3.19.1 139 36 TR 180 => 200. ALso, a linear sum will produce a curved line As in comment Proposed resolution: Accept Change Fig 22-20 to the following (Visio diagram included here) 903 Pulikkoonattu, Rethna 22.3.19.6.4 141 61 TR Channel estimation procedure It is not explicit whether channel estimation to be done only from the training symbols. Is it kept as open deliberately? Say for instance, continuous adaptation of
284 Hart, Brian 22.2.2 77 1 TR User indexing is confusing, and probably would benefit from the concept of a null user. For instance, user indices are USER_NUM is another "index" (see P77L59) that seems to run 1…NUM_USERS. (NUM_USERS != USER_NUM is an error-prone distinction) a) All MU parameters in this table should be length-4, indexed by USER_INDEX. Discard USER_NUM. Parameters for null users (0 STS) should be reserved. NUM_USERS should be the sum of users. Or, b) Rename USER_INDEX to USER_SIGA_INDEX, and update the SIGA descriptions accordingly. Rename USER_NUM to USER_VECTOR_INDEX. Also, relate Nu to NUM_USERS, perhaps at Table 22-5 453 Hart, Brian 22.3.12.1 132 59 TR We are talking about BFee i, and this is equivalent to the (oddly named) USER_NUM in the TXVECTOR Pick a way of indexing the users and stick with it Proposed resolution: Accept in principle (284 was transferred to MU) Discussion: Although the commenter’s intent in CID 476 is unclear, the comment is used to make editorial changes that make the sentence more readable. The other comments relate to USER_INDEX etc. The current language is duplicative. The math uses u and Nu, the MAC/PHY interface uses USER_NUM, NUM_USERS and USER_INDEX. For example, given NSTS = [0 0 3 2] (Matlab notation), then Position or STA position Unspecified: could reasonably be 0 or 1 Unspecified: could reasonably be 1 or 2 Unspecified: could reasonably be 2 or 3 Unspecified: could reasonably be 3 or 4 Notes: NSTSu (e.g.) 0 0 3 2 u - - 0 1 Nu = 2 USER_NUM - - 1 2 NUM_USERS=2 USER_INDEX - - 2 3 Relationships: u = find(NSTSu)-1 % Matlab code Nu = sum(NSTSu > 0) % Matlab code
IEEE P802.11 Wireless LANs CCA – CID 537 Comment Resolution Date: 03 May 2011 Author(s): Name Affiliation Address Phone email Eldad Perahia Intel Corporation eldad.perahia@intel.com CID Clause Page Line Comment Proposed Change Resn Status Resolution 537 22.3.22 149 27 "missed preamble" language is not used anymore Update. ALso, clarify, is this related to the primary20 or the whole bandwidth? (I suspect the former). Ditto P149L31 P in Principle. Refer to discussion in 11/0562 and resolution in 11/0563 TGac editor: modify D0.2 P146L7 (22.3.22 PLCP receive procedure), as follows Upon receiving the transmitted PLCP preamble, PMD_RSSI.indication shall report a receive signal strength to the PLCP. This activity is indicated to the MAC via a PHY-CCA.indication. A channel-list) also issued as an initial indication of reception of a signal. The channel-list parameter of the PHY-CCA.indication is absent when the operating channel width is 20 MHz and includes the element “primary” when the operating channel width is 40 MHz, 80 MHz, 160 MHz or 80+80 MHz. The PMD primitive PMD_RSSI is issued to update the RSSI and parameter reported to the MAC.
IEEE P802.11 Wireless LANs 11ac comments Date: 2011-04-28 Author(s): Name Affiliation Address Phone Email Simone Merlin Qualcomm Inc 8588451243 smerlin@gmail.com Abstract This document provides resolution for the comments listed below on this document: Comments are from: 11-11-0276-00-00ac-tgac-d0-1-comments.xls. Comments refer to: Draft P802.11ac_D0.1.pdf. Edits refer to: Draft P802.11ac_D0.3.pdf. Comments 709 Kneckt, Jarkko 9.2.0b.7 46 14 TR EDCA has not had a possibility to save the TXOP holder. The mechanism is briefly mentioned for HCCA. Please clarify how the receiving STAs detect which STA should be set as the save TXOP holder. Please clarify or delete the saved TXOP holder. Simone will provide a resolution on this and related comments COEX Discussion
IEEE P802.11 Wireless LANs Comment resolutions for definitions etc. Date: 2011-04-28 Author(s): Name Affiliation Address Phone email Yusuke Asai NTT 1-1, Hikarinooka, Kanagawa, 239-0847, Japan +81 49 859 3494 asai.yusuke@lab.ntt.co.jp Takeo Ichikawa NTT 1-1, Hikarinooka, Kanagawa, 239-0847, Japan +81 49 859 3079 Ichikawa.takeo@lab.ntt.co.jp Proposed Resolutions Comments related to the definition of MU-MIMO (CID 239 and 1805) 239 Hart, Brian 3.1 2 9 TR MU-MIMO definition could be confused with FDMA or cellular. For greater definitional power, append "over the same bandwidth in the same area; typically to or from a common STA" As in comment Agree in principle. MU 1805 Yee, James 3.1 2 10 TR the MU-MIMO definition does not require any STA to have multiple antennas. It also to be redefining MIMO when a definition already exists. Should clarify definition and reuse MIMO definition in the baseline spec. Agree in principle. TGac D0.1 allows a STA with single antenna to be a member of DL recipient, so the definition of shall not limit a STA to have multiple antennas. PHY Proposed response to CID 239 and 1805: Change the following sentences in Section 3.1 of TGac Draft D0.1: (P3L9)
IEEE P802.11 Wireless LANs MRQ in NDPA Date: 2011-05-04 Author(s): Name Affiliation Address Phone Email Simone Merlin Qualcomm Inc 8588451243 Menzo Wentink Qualcomm Inc Straatweg 66-S, 3621 BR Breukelen, The Netherlands Allert van Zelst Qualcomm Straatweg 66-S, 3621 BR Breukelen, The Netherlands +31 346 259663 Abstract This document provides resolution for the comments listed below Comments are from: 11-11-0276-00-00ac-tgac-d0-1-comments.xls Comments refer to: Draft P802.11ac_D0.1.pdf Editing instructions refer to: Draft P802.11ac_D0.4.pdf Comments 1072 9.18.3 56 28 TR MFB is not done in case there is mixture of feedback and MU-BF feedback. This unnecessarily creates artificial restriction where if the AP wants MFB as well as CB feedback then it must only assign SU-BF feedback in the NDPA. Remove such restriction. change to make STA feedback MFB only if feedback if configured for that particular STA if MRQ is enabled in NDPA. For STAs configured with MU-BF feedback should disregard the MRQ when MRQ is enabled in NDPA. Suggested text : "The MFB responder shall include the corresponding MFB feedback in the VHT Compressed Beamforming frame that is the response of the same NDP-A and NDP sequence, if the MFB requester sends MRQ in an VHT NDP announcement frame where the Feedback Type subfield in the STA Info field for the MFB spresonder is set to 1 (meaning requesting SU-BF Feedbacks). The MFB responder shall indicate MFB=127 in Daewon. [Ed: removed from 11/304r1] MU BF BF
PHY 1572 Zhao, Hui 22.3.11.10.1 131 48 ER "Refer to the examples of listed in Section 20.3.11.10.1 for examples of that could be used for SU packets". Actually,when Ntx>4 for "spatial expansion",the examples listed in Section 20.3.11.10.1 is not practical,so we need to state more clearly . When Ntx <=4, refer to the examples of listed in Section 20.3.11.10.1 for examples of that could be used for SU packets. When Ntx>=5, the spatial expansion may be performed by duplicating some of the streams to form the streams with each stream being scaled by the normalization factor sqrt(Nsts)/sqrt(Ntx) , or by set the streams as zero. Note that implementations are not restricted to the spatial mapping matrix examples listed in Section 20.3.11.10.1. Proposed resolution: Disagree Discussion: There exist many other alternatives; implementation is not restricted to the spatial mapping matrices shown in 20.3.11.10.1. Note that suggested remedy is only applicable for spatial expansion matrix. Change: none PHY 1104 Seok, Yongho 22.2.3 78 4 TR TBD Fill descriptions. 1617 Zhu, Chunhui 22.2.3 78 4 TR content of the whole section is TBD fill in the missing content 1218 Stephens, Adrian 22.2.3 78 5 TR There's a TBD resolve it
IEEE P802.11 Wireless LANs Comment resolutions on miscellaneous CIDs in 9.9.1.4 Date: Author(s): Name Affiliation Address Phone email Jae Seung Lee ETRI 161 Gajeong-dong, Yuseong-gu, +82 42 860 1326 jasonlee@etri.re.kr Cheong ETRI 161 Gajeong-dong, Yuseong-gu, +82 42 860 5635 Sok-kyu Lee ETRI 161 Gajeong-dong, Yuseong-gu, +82 42 860 5919 sk-lee@etri.re.kr Comments on RIFS (CID 114, 1492, and 1715) 114 Au, (Kwok Shum) 52 5 TR For the rule in clause 9.2.0b.4.2 that a VHT STA shall not transmit frames separated by a RIFS, the sentence "(or RIFS, under the conditions defined in 9.3.2.4.2 (RIFS))" should be deleted. Delete the sentence "(or RIFS, under the conditions defined in 9.3.2.4.2 (RIFS))" Agree in principle. The use of RIFS is for VHT STAs. MAC Lv, Kaiying 52 5 TR the term "STA" here is not change "STA" to "TXOP holder" Agree. Changed the text MAC 52 6 TR Is it correct to include RIFS here, because RIFS is deleted in VHT. Agree in principle. The use of RIFS is for VHT STAs. MAC Discussion Agree in principle. Since the use of RIFS is already deprecated for VHT STAs, a VHT STA shall not transmit frames separated by a RIFS. Although it is already specified in 9.3.2.4.2 of TGac Draft 0.4, we propose to specify it in the sentence for clarity.
IEEE P802.11 Wireless LANs Comment resolution for CIDs: 22, 556, 657, 1085, 1426, 1788, 658 Date: 2011-05-12 Author(s): Name Affiliation Address Phone email Sandhya Samsung Chunhui Zhu (Allan) Samsung Osama Aboul Magd Samsung 22 Asai, Yusuke 7.1.3.1.7 4 49 TR "TXOP power save mode" should be defined in section 3.2. Insert the following definitions in section 3.2: TXOP power save mode: A power management scheme in which a VHT STA may either be in the Awake or Doze state during a TXOP obtained by the VHT AP for VHT transmissions. DISAGREE. For legacy power save mechanism, the active mode and the power save mode are not defined in the definition section. There is no need to define the TXOP power save mode since this is a sub-mode within the Active mode. 556 Hsieh, 11.2.1.4a 61 ER Should the presenting order of clauses "Power management during VHT transmissions" and "VHT TXOP power save mode" be exchanged with each other? It seems that it can be followed more readily if the idea of TXOP PS mode is introduced first and then the conditions that STAs in TXOP PS mode are allowed to enter Doze state. State "VHT TXOP power save mode" in clause 11.2.1.4a and "Power management during VHT transmissions" in clause 11.2.1.4b. The section has been reorganized in the document 11-11-0593r5. 657 Kneckt, Jarkko 11.2.1.4a 61 13 ER The structure of the clause is unclear. The Power management during VHT transmissions having the same content as the clause 11.2.1.4b VHT TXOP Power Management. Please organise sections to Please clarify the structure of the clause The section has been reorganized in the document 11-11-0593r5
IEEE P802.11 Wireless LANs Comment resolution for CIDs: 22, 556, 657, 1085, 1426, 1788, 658 Date: 2011-05-12 Author(s): Name Affiliation Address Phone email Patil Sandhya Samsung Chunhui Zhu (Allan) Samsung Osama Aboul Magd Samsung 22 Asai, Yusuke 7.1.3.1.7 4 49 TR "TXOP power save mode" should be defined in section 3.2. Insert the following definitions in section 3.2: TXOP power save mode: A power management scheme in which a VHT STA may either be in the Awake or Doze state during a TXOP obtained by the VHT AP for VHT transmissions. DISAGREE. For legacy power save mechanism, the active mode and the power save mode are not defined in the definition section. There is no need to define the TXOP power save mode since this is a sub-mode within the Active mode. 694 Kneckt, Jarkko ER The Definitions specific to 802.11 is missing definitions for TXOP power save. Add the definitions DISAGREE. See CID 22 556 Hsieh, 11.2.1.4a 61 ER Should the presenting order of clauses "Power management during VHT transmissions" and "VHT TXOP power save mode" be exchanged with each other? It seems that it can be followed more readily if the idea of TXOP PS mode is introduced first and then the conditions that STAs in TXOP PS mode are allowed to enter Doze state. State "VHT TXOP power save mode" in clause 11.2.1.4a and "Power management during VHT transmissions" in clause 11.2.1.4b. AGREE. The section has been reorganized in the document 11-11-0593r5. 657 Kneckt, Jarkko 11.2.1.4a 61 13 ER The structure of the clause is unclear. The Please clarify the structure of the clause
The agenda is typically: Check contact details Review status of each group Make any adjustment to amendment ordering Discuss and resolve any editorial issues Review matters of or process Help new editors get up to and understand the 802.11 editorial processes Relationship with IEEE-SA IEEE 802.11 editors operate as volunteers, subject to the policies and procedures of the working group (802.11), the LMSC (802) and the IEEE-SA. For an editor, there are the following of with the IEEE-SA: Complying with IEEE-SA style – you must read the style guide! Responding to MEC comments Participating in the publication editing process as reviewer
4.3.7 QoS BSS: The QoS network The third mechanism, designated the service period (SP) access, is applicable only to the DBand and allows for the reservation of channel time with the PCP/AP. A STA based on its requirements requests the PCP/AP for SPs, which can be used for transmission to any other STA in the BSS. The request is initiated by the SME of the STA. The PCP/AP either accepts or rejects the request based on an admission control policy. If the request is accepted, the PCP/AP uses the Extended DBand Schedule element to schedule SPs for communication between the source and destination DBand STAs indicated within the request. Details of this mechanism are provided in 9.33.7.2 Service period (SP) allocation, 9.33.7.4 Pseudo-static allocations, 9.33.7.6 DBand Protected Period and 10.4. 6.3.26 TS management interface 6.3.26.2 6.3.26.2.2 Semantics of the service primitive Editor Instructions: Change the primitive as follows: MLME-ADDTS.request ( DialogToken, TCLASProcessing, ADDTSFailureTimeout, STAAddress, Extended DBand TSPEC, Multi-band, U-PID, VendorSpecificInfo ) Editor Instructions: insert the following entries in the table: Name Type Valid range Description STAAddress MACAddress Specifies the MAC address of the peer STA. Only included in case this refers to the PTP TSPEC. Extended DBand TSPEC As defined in the frame format As defined in 8.4.2.117 Specifies the characteristics and QoS requirements of the of concern. Multi-band As defined in the frame format As defined in 8.4.2.121 Specifies the frequency band and channel number where
6.3.26.5.3 When generated Editor instruction: in the first paragraph, replace “HC” by “DBand STA/HC” 6.3.26.5.4 Effect of receipt Editor instruction: in the second paragraph, replace “HC” by “DBand STA/HC” 6.3.26.6 MLME-DELTS.request 6.3.26.6.1 Function Editor instruction: change the second paragraph as indicated This primitive may be generated at either a DBand STA/non-AP STA or the PCP/HC. 6.3.26.6.2 Semantics of the service primitive Editor Instructions: Change the primitive as follows: STAAddress, TSInfo, ReasonCode, STAAddress, , VendorSpecificInfo ) Editor Instructions: insert the following entries in the table: Name Type range Description STAAddress MACAddress Specifies the MAC address of the peer STA. Only included in case this refers to the PTP TSPEC. As defined in the frame format As defined in 8.4.2.117 Specifies the to be deleted.
IEEE P802.11 Wireless LANs D1 Comment Resolution, brianh, part 1 Date: 2011-07-06 Author(s): Name Affiliation Address Phone email Brian Hart Systems 170 W Tasman Dr, San Jose, CA 95134, USA Baseline is 11ac D1.0. Changes indicated by a mixture of Word and instructions. For equation changes, Latex notation is sometimes used. E.g. a_{xyz}^b denotes axyzb Coex CIDs addressed [16]: 2045, 2339, 2688, 2046, 2689, 2047, 2048 2600 2341 2340 2173, 2344 2198, 3193 2436, 2437 Coex 2045 Asai, Yusuke 102.19 17.2.2 CBW80+80 shall also be defined as one of values for TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT because non-HT duplicate mode using 80+80MHz channel is defined in Table 22-2. As in comment. Accept: see 11/926r0 COEX 2339 Hart, Brian 102.19 17.2.2 Add CBW80+80. Ditto 17.2.2.7, Table 17-2, 17.2.3.7 As in comment Accept: see 11/926r0 COEX 2688 Kim, Youhan 102.19 17.2.2 CBW80+80 is missing. Same comment for P103L14 Change CBW160 to CBW160/CBW80+80 Accept: see 11/926r0 COEX 2046 Asai, Yusuke 102.31 17.2.2.7 CBW80+80 shall also be defined as one of values for TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT because non-HT duplicate mode using 80+80MHz channel is defined in Table 22-2. As in comment. Accept: see 11/926r0 COEX 2689 Kim, Youhan 102.32 17.2.7 CBW80+80 is missing. Same comment for P103L27 Change CBW160 to CBW160/CBW80+80 Accept: see 11/926r0 COEX
2052 Asai, Yusuke 112.21 22.2.2 CBW160 and CBW80+80 are individually defined and there is no definition of "CBW160/80+80". Change "CBW160/80+80" to "CBW160, or CBW80+80". Agree. See 11/954r1 PHY 3391 Rosdahl, Jon 112.21 22.2.2 Are CBW160 and CBW80+80 really intended to be merged in the enum here, unlike everywhere else? Clarify Agree. See 11/954r1 PHY Change: CH_BANDWIDTH_IN_NON_HT FORMAT is NON_HT When present, indicates the channel of the transmitted packet which is signalled via the scrambling sequence. Enumerated type: CBW20, CBW40, CBW80, CBW16080+80 Y Y Otherwise Not present N N 2305 Grandhi, Sudheer 112.38 22.2.2 The LENGTH Value is placed in the Length field for all frames except the NDP frame. Replace line with "This parameter is placed in the VHT-SIG-B Length field rounded up to a 4 octet boundary with the low order two bits removed except in the case of an NDP frame". Accept in principle. Reorder the language so the NDP/non-NDP choice happens first, then a TXVECTOr/RXVECTOR choice, then updated details of the parameters. See 11/954r1 PHY
2745 Kudo, Riichi 114.39 22.2.2 "1 through NUM_USERS-1" is not correct. "0 through NUM_USERS-1" is correct and this is corresponding to Table 22-5 and other parts of Clause 22. As in comment. Accept. See 11/954r1 PHY 2365 Hart, Brian 114.40 22.2.2 1 through NUMUSERS-1 0 through NUMUSERS-1 Accept. See 11/954r1 PHY 3600 Stephens, Adrian 114.40 22.2.2 "values 1 through Obviously we had a battle between the FORTRAN programmers and the C programmers, and they came to a compromize. Unfortunately, like writing alternating lines of a program in FORTRAN and C, the compromise does not work. Take a straw poll as to whether we like FORTRAN ('77 was the last version I learned) or C (ANSI C). Then adjust upper or lower bound accordingly. Those who are COBOL programmers won't understand this comment, and are advised to take it easy. Accept in principle. Right answer is 0..NUM_USERS-1. See 11/954r1 PHY Discussion.The math and usage elsewhere requires that the range be 0 to NUM_USERS-1. Change: See roll-up after next comment for changes
2691 Kim, Youhan 114.49 22.2.2 Is it clear that a parameter with 'MU' in TXVECTOR or RXVECTOR should also be present for SU packets as well? For example, the FEC_CODING (P110L32) should be resent for SU packets as well. in principle: Clarify Note 1. See 11/954r1. PHY Discussion: Good point. Change: NOTE 1—In the “TXVECTOR” and “RXVECTOR” columns, the following apply: Y = Present; N = Not present; O = Optional; MU indicates that the parameter is present per user. Parameters specified to be present per user are conceptually supplied as an array of values indexed by u, where u takes values through NUM_USERS-1.
Scenario RMS DS (ns) Scenario RMS DS (ns) Scenario RMS DS (ns) 4G InH LoS 20 TGn A 0 NLoS 39 TGn B 15 4G UMi LoS 65 TGn C 30 SCM UMi 250 NLoS 129 TGn D 50 O-to-I 49 TGn E 100 4G SMa LoS 59 TGn F 150 SCM SMa 170 NLoS 75 4G UMa LoS 93 SCM UMa 650 NLoS 365 4G RMa LoS 32 NLoS 37 Table 1: Summary of RMS Delay Spread Values 3.1 Spatial Channel Model (SCM) The Spatial Channel Model (SCM) is fully described in [1] and a freeware Matlab implementation can be downloaded from [2]. A Matlab wrapper file for generating 11ah channel profiles using this implementation is provided in the Appendix. This channel model shall be used to evaluate 11ah outdoor link and system performance for SISO or MIMO links. TGah use cases involve up to pedestrian mobility. However as reported in [4] and [5], reflections from cars cause higher Doppler and can be represented by assigning one of the six channel paths a higher Doppler value. The following two simulation scenarios shall be used: SCM with speed up to 3kmph for all paths SCM with the fourth path assigned a speed of 60kmph and the rest of the paths assigned 0kmph.
IEEE P802.11 Wireless LANs A-MSDU section Date: 2011-07-18 Author(s): Name Affiliation Address Phone Email Simone Merlin Qualcomm Inc 8588451243 smerlin@gmail.com Abstract This document provides resolution for the comments listed below Comments are from: 11-11-0907-0x-00ac-lb178-comments-tgac-d1-0.xlsx Comments refer to: Draft P802.11ac_D1.0.pdf Comments 2292 75.32 9.11 ambiguous reference - change "its" to "the recipient's" AGREE IN PRINCIPLE MAC 2293 75.43 9.11 ambiguous reference - whose capability element? change "element" to "element of the recipient" AGREE IN PRINCIPLE MAC 3060 75.44 9.11 Is A-MSDU support mandatory for 'Single MPDU'?. 11n states "Support for the reception of an where the A-MSDU is carried in a QoS data MPDU with Ack Policy (#10128)equal to Normal Ack and the is not aggregated within an is andatory for an HT STA" change to: "Support for the reception of an the A-MSDU is carried in a QoS data MPDU with Ack Policy (#10128)equal to Normal Ack and the is not aggregated within an or is sent as part of a Single MPDU frame, is mandatory for an HT STA" AGREE IN PRINCIPLE MAC
3063 75.28 9.11 specify to which capability the sentence is referred to: "A STA shall not transmit an in a HT PPDU to a STA that exceeds its maximum length capability." A STA shall not transmit an A-MSDU in a HT PPDU to a STA that exceeds its maximum length capability, indicated in the HT Capability element AGREE IN PRINCIPLE MAC Discussion Added the reference to the Capabilities element most recently received from the recipient STA. Added a sentence clarifying that reception of an A-MSDU is mandatory for a VHT STA in case it is carried in a VHT Single MPDU 3349 75.28 9.11 What happens if a VHT STA wants to retransmit an previously sent in a VHT PPDU using an HT PPDU, but this exceeds the max A-MSDU size? Clarify AGREE IN PRINCIPLE MAC Discussion In that case the A-MSDU cannot be transmitted; this limitation is already present in the text though the description of the maximum supported A-MSDU and MPDU lengths; A NOTE is added to further clarify Instructions to the editor
CommentID Subclause Page Line CommentType Comment SuggestedRemedy 2297 8.4.2.102 56 21 T Described Spatial Stream is not a "percentage"- part with multiplier 255. decide for one solution 2726 8.4.2.102 56 21 T The percentage is value 1/100 while in Spatial Stream under utilisation field the value is 1/255. Replace percentage with value, or make it to be percentage. Discussion: The description in line 18-25 is unclear and misleading. The description should instead make it clear that the parameter is defined as percentage of time and linearly scaled with 255 to represent 100% as described below. The Spatial Stream Under-Utilization is defined as the percentage of time but linearly scaled with 255 representing 100%. Proposed Response: COUNTER with the proposed text below. Proposed Resolution Text: The Spatial Stream field is defined as the fraction percentage of time, linearly scaled with 255 representing 100%, that the AP has under utilized spatial domain resources for given busy time of the medium. When more than one channel is in use for the BSS, the spatial stream under-utility value is calculated only for the primary channel. This percentage is computed using the formula, CommentID Subclause Page Line CommentType Comment SuggestedRemedy 3257 8.4.2.102 56 45, 51, 56 T The Forty MHz field, Eighty MHz Utilization field and Hundred Sixty MHz Utilization field are all "defined as the fraction of time". They are not percentages, as described in the Change "percentage" to "fraction" for each of the utilization fields mentioned.
requestIncapable(3), detectedFrequentTransition(4) } MAX-ACCESS read-only STATUS current DESCRIPTION " This attribute contains the status included in the Event Report." ::= { dot11WNMEventTransitReportEntry 4 } dot11WNMEventTransitRprtEventTSF OBJECT-TYPE SYNTAX TSFType MAX-ACCESS read-only STATUS current DESCRIPTION " This attribute contains the value of the Event timestamp field." ::= { dot11WNMEventTransitReportEntry 5 } dot11WNMEventTransitRprtUTCOffset OBJECT-TYPE SYNTAX OCTET STRING (SIZE(10)) MAX-ACCESS read-only STATUS current DESCRIPTION " This attribute indicates the UTC Offset Time Value optionally included in the Event Report." ::= { dot11WNMEventTransitReportEntry 6 } dot11WNMEventTransitRprtTimeError OBJECT-TYPE SYNTAX STRING (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION " This attribute contains the value of the Event Time Error field optionally included in the Event Report. " ::= { dot11WNMEventTransitReportEntry 7 } dot11WNMEventTransitRprtSourceBssid OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION " This attribute indicates the source BSSID for the reported transition event." ::= { dot11WNMEventTransitReportEntry 8 } dot11WNMEventTransitRprtTargetBssid OBJECT-TYPE
IEEE P802.11 Wireless LANs Encoder Parsing Operation Date: 2011-07-21 Author(s): Name Affiliation Address Phone Email Sun Bo ZTE Corporation ZTE Building, #10. Sth Tangyan Rd., Xi’an, 86 29 88723410 Sun.bo1@zte.com.cn Abstract This document provides resolution for the comments listed below Comments are from: 11-11-0907-0x-00ac-lb178-comments-tgac-d1-0.xlsx Comments refer to: Draft P802.11ac_D1.0.pdf Comments 3632 158/16 22.3.10.5.1 in equation 22-47,the subscript Nes of b should be Nes,u .and the last expression of should be Nes,u*i+j Change as comment AGREE PHY Discussion As pointed out by the comment, there’s incorrect expression in equation 22-47 regarding the variable Nes,u . Instructions to the editor Changing the Equation 22-47 P158/L16 as following (22-47)
STA will use this element, so it will be better to use "an IDO STA in an IBSS". 488 32.00 8.4.2.af3 The way different possible modes are defined for CPM looks very complex. The main functions are to indicate required channel switch, and/or power changes. Too many options embedded in each mode are confusing. For example, why the stopping transmissions immediately or not requires to be indicated in two modes. This may be signaled by channel power switch count field as well. Suggest to simplify the text by only covering channel switch and changes in maximum transmit power levels. May be a bit map representation for various options would be the better approach. 743 32.01 8.4.2.af3 Table 8-42paf1—Channel Power Management Mode values It might help to instead have a bit field indicating which fields are actually present and possible action, instead of having enumerated values Assign bits in Channel Power Management Mode value to reflect what all fields are present and possible action corresponding to each bit. 963 32.01 8.4.2.af3 Table 8-42paf1—Channel Power Management Mode values It might help to instead have a bit field indicating which fields are actually present and possible action, instead of having enumerated values Assign bits in Channel Power Management Mode value to reflect what all fields are present and possible action corresponding to each bit. 280 32.43 8.4.2.af3 "requested"? Then is not much of a point. Either you require or your don't. Change "requested" to "required" - make appropriate, corresponding changes elsewhere where behavioral description of this interaciton exists. 388 33.22 8.4.2.af3 I don't understand the following sentence "Stopping transmissions until the actual change(s) in the Constrained Maximum Transmit Power(s) is requested." Who requests what? Who should do what? The sentence occurs also in slighty different form as "Stopping transmissions until the actual channel switch(es) is requested." Clarify 489 32.45 8.4.2.af3 Is the indication of primary and secondary channels in mode 4 or 5 is meant for .11n 40 MHz bandwidth? In the current channelization plan for TVWS band in E.1 does not have primary and secondary channels. Clarify.
For >=2MHz LTFs in Short Preamble format, and D-LTFs in the Long preamble format, the transmitted pilot tone signals, in the k-th tone of each LTF field in the >=2MHz short preamble format, and of each D-LTF field in the >=2MHz long preamble format is expressed as: For >=2MHz SIGB/Data, the transmitted pilot tone signals, in the k-th tone and n-th OFDM symbol in SIGB (when applicable) and Data fields in >=2MHz PPDUs is expressed as: [July 2012 meeting minutes, 11-12/832r2] The pilot mapping and values for 2/4/8/16 MHz transmissions, respectively, refer those for 20/40/80/160 MHz transmissions in section 22.3.10.10 (Pilot subcarriers) of IEEE P802.11ac™/D2.0. [May 2012 meeting minutes, 12/363r2-motion2] For 1MHz LTFs, the transmitted pilot tone signals, in the k-th tone and in each LTFs for 1MHz PPDU is expressed as: For 1MHz SIG field and Data Field, the transmitted pilot tone signals, in the k-th tone and n-th OFDM symbol of 1MHz SIG and Data fields is expressed as: For a 1MHz transmission, two pilot tones shall be inserted in . The pilot mapping for subcarrier k for symbol n shall be as specified in the following equation. [May 2012 meeting minutes, 12/363r2-motion1] where, is given in Table 22-20 of IEEE P802.11ac™/D2.0 and where n is the DATA symbol index.
TSYML 40 s = TDFT + TGI = 1.25 TDFT Duration of OFDM symbol with normal guard interval TSYMS 36 s = TDFT + TGIS = 1.125 TDFT Duration of OFDM symbol with short guard interval TSYM TSYML or TSYMS depending on the GI used OFDM symbol duration TSTF 160 s = 4 TSYML 80 s = 2 TSYML STF field duration TDSTF n.a. 40 s = TSYML ≥2 MHz long preamble D-STF field duration TLTF1 160 s = 4 TDFT + 2 TGI + TGI2 80 s = 2 TDFT + TGI2 First LTF field duration TLTFs 40 s = TSYML Second and subsequent LTF field duration TDLTF n.a. 40 s = TSYML ≥2 MHz long preamble D-LTF field duration TSIG 240 s = 6 TSYML 80 s = 2 TSYML SIG field duration TSIGA n.a. 80 s = 2 ≥2 MHz long preamble SIGA field duration TSIGB n.a. 40 s = TSYML ≥2 MHz long preamble SIGB field duration 3.9 S1G PLME 3.9.1 PHY characteristics [12/1104r2, September 2012 meeting minutes] Characteristics Value aSlotTime 52 us aCCATime 40 us aAirPropagationTime 6 us aSIFSTime 160 us
NSP 2 4 6 8 Number of pilot subcarrier per OFDM symbol NST 26 Total number of useful subcarriers per OFDM symbol NSR 13 Highest data subcarrier index per OFDM symbol F 31.25 kHz Subcarrier frequency spacing TDFT 32 s = 1/F IDFT/DFT period TGI 8 s = TDFT/4 Guard interval duration TDGI 16 s Double guard interval TSGI 4 s = TDFT/8 Short guard interval duration TSYML 40 s = TDFT + TGI = 1.25 TDFT Duration of OFDM symbol with normal guard interval TSYMS 36 s = TDFT + TGIS = 1.125 TDFT Duration of OFDM symbol with short guard interval TSYM TSYML or TSYMS depending on the GI used OFDM symbol duration TSTF 160 s = 4 TSYML 80 s = 2 TSYML STF field duration TDSTF n.a. 40 s = TSYML ≥2 MHz long preamble D-STF duration TLTF1 160 s = 4 TDFT + 2 TGI + TGI2 80 s = 2 TDFT + TGI2 LTF field duration TLTFs 40 s = TSYML Second and subsequent LTF field duration n.a. 40 s = TSYML ≥2 MHz long preamble D-LTF field duration TSIG 240 s = 6 TSYML 80 s = 2 TSYML SIG field duration TSIGA n.a. 80 s = 2 ≥2 MHz long preamble SIGA field duration TSIGB n.a. 40 s = TSYML ≥2 MHz long preamble SIGB field duration 3.9 S1G PLME 3.9.1 PHY characteristics [12/1104r2, September 2012 meeting minutes] Characteristics Value aSlotTime 52 us
Transmission BW(MHz) Averaging subcarrier indices (inclusive) Tested subcarrier indices (inclusive) Maximum Deviation (dB) 1 -8 to -1 and +1 to +8 -8 to -1 and +1 to +8 ±4 -13 to -9 and +9 to +13 +4/-6 2 -16 to -1 and +1 to +16 -16 to -1 and +1 to +16 ±4 -28 to -17 and +17 to +28 +4/-6 4 -42 to -2 and +2 to +42 -42 to -2 and +2 to +42 ±4 -58 to -43 and +43 to +58 +4/-6 8 -84 to -2 and +2 to +84 -84 to -2 and +2 to +84 ±4 -122 to -85 and +85 to +122 +4/-6 16 -172 to -126 to -44, +44 to +126, and +130 to +172 -172 to -126 to -44, +44 to +126, and +130 to +172 ±4 -250 to -43 to -6, +6 to +43, and +173 to +250 +4/-6 802.11ah Spectral Flatness for 2 MHz DUP Mode
+17 to +29, and +35 to +42 +29, and +35 to +42 -61 to -49, -47 to -43, +43 to +47, and +49 to +61 +4/-6 8 -84 to -81, -79 to -67, -61 to -49, -47 to -35, -29 to -17, -15 to -3, +3 to +15, +17 to +29, +35 to +47, +49 to +61, +67 to +79, and +81 to +84 -84 to -81, -79 to -67, -61 to -49, -47 to -35, -29 to -17, -15 to -3, +3 to +15, +17 to +29, +35 to +47, +49 to +61, +67 to +79, and +81 to +84 ±4 -125 to -111 to -99, -93 to -85, +85 to +93, +99 to +111, and +113 to +125 +4/-6 16 -172 to -157 to -145, -143 to -125 to -113, to -93 to -79 to -61 to -47 to +44 to +47, +49 to +61, +67 to +79, +81 to +93, +99 to -172 to -157 to -145, to -125 to -113, -111 to -93 to -79 to -61 to -47 to +44 to +47, +49 to +61, +67 to +79, +81 to +93, +99 to ±4
+111, +113 to +125, +131 to +143, +145 to +157, and +163 to +172 +111, +113 to +125, +131 to +143, +145 to +157, and +163 to +172 -253 to -239 to -227, to -207 to -195, -189 to -175 to -173, to -35, to -17, to -3, +3 to +15, +17 to +29, +35 to +43,+173 to +175, +177 to +189, +195 to +207, +209 to +221, +227 to +239, and +241 to +253 +4/-6
3225 180.29 22.3.18.1 The flatnees spec for 160MHz non-HT duplication is missing. as per comment AGREE IN PRINCIPLE. See 11/1189r1. Discussion: As in case of VHT160, tones within -172 to -44, and +44 to +172 (excluding DC and guard tones of each 20 MHz) should meet ±4 dB requirement. Tones outside of that should meet +4/-6 dB. Change: 22.3.18.2 Spectral flatness Change Table 22-19 (D1.1) as follows: Format Bandwidth of transmission (MHz) Averaging subcarrier indices (inclusive) Tested subcarrier indices (inclusive) Maximum deviation (dB) VHT 20 -16 to -1 and +1 to +16 -16 to -1 and +1 to +16 ±4 -28 to -17 and +17 to +28 +4/-6 40 -42 to -2 and +2 and +42 -42 to -2 and +2 and +42 ±4 to and +43 to +58 +4/-6 80 -84 to -2 and +2 and +84 -84 to -2 and +2 to +84 ±4 -122 to -85 and +85 to +122 +4/-6 non-HT duplicate 40 -42 to -33, -31 to -6, +6 to +31, and +33 to +42 -42 to -33, -31 to -6, +6 to +31, and +33 to +42 ±4 -43 to =58 and +43 to +58 +4/-6 80 -84 to -70, -58 to -33, -31 to +6 to +31, +33 to +58, +70 to +84 -84 to -70, -58 to -33, -31 to +6 to +31, +33 to +58, +70 to +84 ±4 -122 to -97, -95 to -85 and +85 to 95, +97 to +122 +4/-6