1. Proposed Resolutions for PICS & other General Comments
July 2007
doc.: IEEE /2121r0
July 2007
Proposed Resolutions for PICS & other General Comments
Date: 2007-July-13
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Bruce Kraemer, Marvell
Bruce Kraemer, Marvell

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

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

4. MCS Normative text 20.3.5 Modulation and Coding Scheme (MCS)
July 2007
MCS Normative text
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 are reserved.
Bruce Kraemer, Marvell

5. 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

6. 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 HTP thru HTP and leaving only HTP2.3.5 would suggest that implementing HTP2.3.5 requires that all MCS 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

7. 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 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 makes the sentence, "It is optional for a STA to process an NDP.", of 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 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.HTP becomes HTP (RX) with "O HTM14.1:M" for status column andHTP (TX) with HTM14.2:M for status column
Bruce Kraemer, Marvell

8. 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

9. 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

10. 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

11. 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

12. #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

13. 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

14. 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
CF16:M
Yes a No a
N/A a
Bruce Kraemer, Marvell

15. #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

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

17. 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 P – No change to the PICS format is required.
Bruce Kraemer, Marvell

18. #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

19. July 2007
P PICS for QoS
Bruce Kraemer, Marvell

20. 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

21. 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

22. July 2007
CID # 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

23. CID #1273 - Resolution Option 2
July 2007
CID # Resolution Option 2
Proposed Resolution: Counter, accept in principle.
TGn editor: Amend the table in Annex A on page 323 (D2.04) as follows:
Item
Protocol capability
References
Status
Support
QB4
Block Acknowledgements (Block Acks) , ,
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