1. June 2006
doc.: IEEE /0851r0
June 2006
LB84 Frame Format Ad-hoc Comment Resolution CID# 701, 7239, 9979, 3773, 7127
Date:
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 < ieee802.org/guides/bylaws/sb-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 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
Jeremy Gosteau
Jeremy Gosteau

2. CID proposed resolution, general comments
June 2006
doc.: IEEE /0851r0
June 2006
CID proposed resolution, general comments
CIDs relating to the “STBC Basic MCS” field
CID #701
CID #7239
CID #9979
CID #3773
CID #7127
Proposal made with respect to version of Draft D1.03
Jeremy Gosteau
Jeremy Gosteau

3. Proposed resolution June 2006
HT Capabilities info field ( , Table n16, page 36) of the HT Capabilities IE
Rename “STBC Control Frame Support” to “Dual Beacon”
New meaning of this “Dual Beacon”
Set to 1 if a secondary beacon is transmitted by the AP
Move the bit to the HT Information Element (as a replacement of one of the 7 bits signaling the Basic STBC MCS) because it is an AP only information
The old location becomes “Reserved”
Does not change current behavior where the use of the “STBC Control Frame Support” bit influences only section 9.6 (page 74, line 17) and says that: “if the STBC Control Frame support field is set to 1, the secondary STBC beacon shall be transmitted using the Basic STBC MCS and multicast frames shall be repeated using the Basic STBC MCS”
Modify accordingly (section 9.6, page 74, line 17) and replace occurrence of “STBC Control Frame Support” with “Dual Beacon”
Remove the 7bits from the HT Information Element ( , Figure n22, Table n21) allocated to the Basic STBC MCS
These 7bits are useless since they are used to signal one STBC MCS value
We keep the spirit of ONE SINGLE STBC MCS, but this value will be the lowest rate of the Basic MCS Set used with STBC encoder with 1SS, 2STS
Add the definition in Section 9.6 of the Basic STBC MCS value as the MCS of lowest rate in the Basic MCS Set used with STBC encoder with 1SS and 2STS.
Modify accordingly the text in (section , a, pages 70/71) and in (section 9.6, page74) where the former occurrences of “STBC MCS” occur.
Add in (section a, page 71, line 25) after “with a single CTS”: “A non-AP STA may start a TXOP with an STBC RTS if its STBC Tx and Rx capabilities allow to receive and transmit STBC encoded frames with 1SS”
Jeremy Gosteau

4. Proposed resolution June 2006 CID #701 CID #7239 CID #9979 CID #3773
C: countered by the proposed resolution in doc 11-06/1086-r3
CID #7239
CID #9979
A: meaning of STBC MCS clarified by resolution described in doc 11-06/1086-r3
CID #3773
CID #7127
C: field removed as per proposed resolution in doc 11-06/1086-r3
Jeremy Gosteau

5. June 2006
BACK UP
Jeremy Gosteau

6. Former resolution proposal (r1–San Diego)
June 2006
doc.: IEEE /0851r0
June 2006
Former resolution proposal (r1–San Diego)
Keep the current bit budget (7 bits) and find adequate bit mapping in order to allow for more than one STBC MCS to be signaled for use in control and management frames
STBC implies that 1SS is mandatory
The last 2 bits enable the AP to signal which STBC scheme may be used (with 3 or 4 STS) with 2 SS, and with exactly the same MCS options as for 1SS
Exclusions (can be solved but by using more bits…)
3 SS case
64 QAM constellations B0 B4 B5 B6
Indicates used MCS if set to 1
B0 B1 B2 B3 B4
BPSK QPSK QPSK 16QAM 16QAM
1/2 1/2 3/4 1/2 3/4
3STS
2SS
4STS
2SS
Jeremy Gosteau
Jeremy Gosteau