June 2006 doc.: IEEE 802.11-06/0851r0 June 2006 LB84 Frame Format Ad-hoc Comment Resolution CID# 701, 7239, 9979, 3773, 7127 Date: 2006-09-14 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/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 <stuart.kerry@philips.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>. Jeremy Gosteau Jeremy Gosteau

CID proposed resolution, general comments June 2006 doc.: IEEE 802.11-06/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

Proposed resolution June 2006 HT Capabilities info field (7.3.2.46.2, 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 (7.3.2.47, 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 9.2.5.4, 9.2.5.4a, pages 70/71) and in (section 9.6, page74) where the former occurrences of “STBC MCS” occur. Add in (section 9.2.5.4a, 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

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

June 2006 BACK UP Jeremy Gosteau

Former resolution proposal (r1–San Diego) June 2006 doc.: IEEE 802.11-06/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