Proposed Resolutions for PICS & other General Comments July 2007 doc.: IEEE 802.11-07/2121r0 July 2007 Proposed Resolutions for PICS & other General Comments Date: 2007-July-13 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures http://ieee802.org/guides/bylaws.pdf , including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart@ok-brit.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Bruce Kraemer, Marvell Bruce Kraemer, Marvell

Summary of CIDS and Topics July 2007 Summary of CIDS and Topics 349 Too many MCS PICS entries 503 Break PICS into receive and transmit sections 3404 Add TGs amendment to baseline 167 Rx RIFS support should be mandatory in PICS 893 HTM12 PICS format 1269 CF12 mandatory? 1273 HT-immediate needs QB4.1 Bruce Kraemer, Marvell

1. Too Many MCS PICS Entries July 2007 1. Too Many MCS PICS Entries CID Comment Proposed Change 7.3.2.52.4 Normative reference Bruce Kraemer, Marvell

MCS Normative text 20.3.5 Modulation and Coding Scheme (MCS) July 2007 MCS Normative text 20.3.5 Modulation and Coding Scheme (MCS) The Modulation and Coding Scheme (MCS) is a value that determines the modulation, coding and number of spatial channels. It is a compact representation that is carried in the HT SIGNAL field. Rate dependent parameters for the full set of modulation and coding schemes (MCS) are shown in 20.6 (Parameters for HT Modulation and Coding Schemes (MCS) (#665)) in Table 206 (MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1, EQM) to Table 220 (MCS parameters for optional 40 MHz, NSS = 4, UEQM). These tables give rate dependent parameters for MCSs with indices 0 through 76. MCS indices 77-127 are reserved. Bruce Kraemer, Marvell

MCS Tables in Clause 20.6 July 2007 Table 206 -MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1, EQM Table 205 -Symbols used in MCS parameter tables Table 207 -MCS parameters for optional 20 MHz, NSS = 2, NES = 1, EQM Table 208 -MCS parameters for optional 20 MHz, NSS = 3, NES = 1, EQM Table 209 -MCS parameters for optional 20 MHz, NSS = 4, NES = 1, EQM Table 210 -MCS parameters for optional 40 MHz, NSS = 1, NES = 1 Table 211 -MCS parameters for optional 40 MHz, NSS = 2, NES = 1, EQM Table 212 -MCS parameters for optional 40 MHz, NSS = 3, EQM Table 213 -MCS parameters for optional 40 MHz, NSS = 4, EQM Table 214 -MCS parameters for optional 40 MHz HT duplicate format, NSS = 1, NES = 1 Table 215 -MCS parameters for optional 20 MHz, NSS = 2, NES = 1, UEQM Table 216 -MCS parameters for optional 20 MHz, NSS = 3 MCSs, NES = 1, UEQM Table 217 -MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM Table 218 -MCS parameters for optional 40 MHz, NSS = 2 MCSs, NES = 1, UEQM Table 219 -MCS parameters for optional 40 MHz, NSS = 3, UEQM Table 220 -MCS parameters for optional 40 MHz, NSS = 4, UEQM Bruce Kraemer, Marvell

CID #349: Suggested Resolution: Reject. July 2007 CID #349: Suggested Resolution: Reject. The MCS capability is defined by one bit per MCS. Since the granularity is 1 bit per MCS there has been confusion when grouping them. For example, attempting to simplify the PICS by removing HTP2.3.5.1 thru HTP2.3.5.61 and leaving only HTP2.3.5 would suggest that implementing HTP2.3.5 requires that all MCS 16-76 must be implemented as a set. The PICS entries were expanded to show additional detail in response to comments during balloting on Draft 1.0. The group opinion is that the PICS representation is most useful when each MCS entry is shown independently. Bruce Kraemer, Marvell

2. Break PICS into receive and transmit sections July 2007 2. Break PICS into receive and transmit sections CID Comment Proposed Change 503 HTP2.8.2 Sounding with an NDP is marked HTM14:M Using the reference of 20.3.12.1. Yet in this clause there is only the use of the term, may, and a statement that says optional. Thus there is no supporting text within this reference that makes it mandatory. The indirect reference to HTM14 (i.e., 9.19). In fact the first sentence, "... the STA shall process an NDP ...", of 9.19.1 makes the sentence, "It is optional for a STA to process an NDP.", of 20.3.12.1 in direct conflict. Either processing on the NDP by a STA is optional or manadatory. If additional conditions are required to differentiate this behavior, then it should be part of the text and PICS. The use of NDP appears to have special conditions for whether it is transmiting or receiving. The first sentence of 9.19.1 states that there is an indication in the HT Capabilities element for indicating its ability to receive NDP. There is also an indication in the HT Capabilites element for indicating its ability to transmit NDP. So there appears to be a question of whether an entity shall both send and receive NDP (ie., mandatory) or whether one of the other or both are optional. PICS HTM14 and PICS HTP2.8.2 need to be modified to differentiate transmitter and receiver capabilites to match the HT Capabilities element. Otherwise there is no need for two separate bits representing each in the HT Capabilities Element. At a minimum change PICS into two (one for RX and the other for TX. HTM14 becomes HTM14.1 (RX) and 14.2 (TX) both use the same other information.HTP2.8.2 becomes HTP2.8.2.1 (RX) with "O HTM14.1:M" for status column andHTP2.8.2.2 (TX) with HTM14.2:M for status column Bruce Kraemer, Marvell

Discussion Proposal is to create transmit PICS and Receive PICS rows July 2007 Discussion Proposal is to create transmit PICS and Receive PICS rows And differentiate between receive optional and transmit mandatory NDP examples cited are HTM14 and HTM2.8.2 In draft 2.0 the PICS references are: Bruce Kraemer, Marvell

PICS representation in D2.04 July 2007 PICS representation in D2.04 In draft 2.04 PICS entry numbers for NDP have changed but predicate logic is unchanged. Predicate logic: If CF16 is true, HTM16 (NDP) is optional. If HTM16 is true, then HTP2.8.2 is mandatory. There is no difference between Rx and Tx. It is mandatory for both. Bruce Kraemer, Marvell

CID #503 Proposed Resolution: Reject July 2007 CID #503 Proposed Resolution: Reject If NDP is used it applies equally to transmit and receive. Bruce Kraemer, Marvell

3. Add TGs amendment to baseline July 2007 3. Add TGs amendment to baseline CID Comment Proposed Change 3404 Given the time current official time lines for the current ongoing amendments, it appears that TGs will be completed prior to TGn. If this correct a review and assessment of the impact of TGs on TGn needs to be done and required changes made. Proposed Resolution: Reject Discussion: As of July 2007 the proposed Standards board approval dates are as follows: TGn September 2008 TGs June 2009 Given these dates TGs, is not part of the TGn baseline and TGs has no impact on TGn. Bruce Kraemer, Marvell

#4 - Rx RIFS support should be mandatory in PICS July 2007 #4 - Rx RIFS support should be mandatory in PICS CID Comment Proposed Change 167 PICS does not mention that RIFS should be mandatory for the receiver Add such an item Bruce Kraemer, Marvell

RIFS Normative Text PICS July 2007 RIFS Normative Text PICS There is an entry for RIFS protection but no entry for RIFS Bruce Kraemer, Marvell

Resolution CID #167 Proposed Resolution: Counter, accept in principle July 2007 Resolution CID #167 Proposed Resolution: Counter, accept in principle TGn editor: Append to the table in Annex A on page 350 (D2.04) as follows: HTP2.13 PPDU reception with RIFS 20.3.21.7 CF16:M Yes a No a N/A a Bruce Kraemer, Marvell

#5 - HTM12 PICS Format CID Comment Proposed Change 893 July 2007 #5 - HTM12 PICS Format CID Comment Proposed Change 893 please check whether this is legal. HTM12 has no entry for Status, nor for Support. Can it be used in a later Status column Fix if needed Bruce Kraemer, Marvell

July 2007 Sample of HTM12 PICS PICS in 2.00 Bruce Kraemer, Marvell

Proposed Resolution CID # 893 Proposed Resolution: Reject July 2007 Proposed Resolution CID # 893 Proposed Resolution: Reject The PICS formatting used in TGn draft 2.0 is consistent with the formatting used in P802.11 – 2007. No change to the PICS format is required. Bruce Kraemer, Marvell

#6 & 7 - QoS support should be mandatory in PICS July 2007 #6 & 7 - QoS support should be mandatory in PICS CID Comment Proposed Change 1269 CF12 should be mandatory if CF15 is implemented add row for CF12, with status entry "CF15:M" 1273 HT-immediate should depend on QB4.1 change Status to "CF15 and QB4.1:M", insert an asterisk before the item for QB4.1 on page 339 Bruce Kraemer, Marvell

July 2007 P802.11-2007 PICS for QoS Bruce Kraemer, Marvell

July 2007 TGn 2.00 PICS for QoS In D2.0 the only reference to CF12 is in refernce to QB4 and QoS is shown as optional. Bruce Kraemer, Marvell

July 2007 TGn 2.04 PICS for QoS In D2.04 the table is cleaner but the reference to CF12 in QB4 is unchanged. Bruce Kraemer, Marvell

July 2007 CID #1269 - Resolution Proposed Resolution: Counter, accept in principle. TGn editor: Append to the table in Annex A on page 326 (D2.04) as follows: Item Protocol capability References Status Support *CF12 QoS 9.9, 9.10 5.2.8 O CF16:M Yes a No a N/A a Bruce Kraemer, Marvell

CID #1273 - Resolution Option 2 July 2007 CID #1273 - Resolution Option 2 Proposed Resolution: Counter, accept in principle. TGn editor: Amend the table in Annex A.14.4 on page 323 (D2.04) as follows: Item Protocol capability References Status Support QB4 Block Acknowledgements (Block Acks) 7.2.1.7, 7.2.1.8, 7.4.4, 9.10, 11.5 CF12:O CF16:M QB4.1 Immediate Block Ack QB4.2 Delayed Block Ack Yes a No a N/A a Yes a No a N/A a Yes a No a N/A a Bruce Kraemer, Marvell