1. doc.: IEEE 802.11-06/1774r0 Submission 2006-11-14 Peter Loc, MarvellSlide 1 802.11 TGn Frame Format Ad Hoc Status 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2006-11-14 Authors:

2. doc.: IEEE 802.11-06/1774r0 Submission 2006-11-14 Peter Loc, MarvellSlide 2 Status on 11/14 – CIDs remained in Frame Format ad hoc Resolution StatusTotal CIDs To be submitted for motion this week AAccepted 12 Yes CCountered 13 Yes DDeferred 36 RRejected 6 Yes ER Editor Rejected for clarification 5 Yes EMR Edited with changes, recycled for TGn approval 2 Yes Remaining CIDs that have not been addressed 37 Total 111

3. doc.: IEEE 802.11-06/1774r0 Submission 2006-11-14 Peter Loc, MarvellSlide 3 Deferred CIDs with Assignees (1) 3715AdrianTable n6 - Spell the bit combination more clearly (ie which bit is more significant etc As suggested 2142MarcSTBC support - "BSS does/does not…"Change to "device", remove conditional definition since its meaning isn't based on frame type 7299Sanjiv"When a responder is unable to provide an immediate response to MRQ and sets MFB to all-ones it also sets MFS to 111." Now the requester does not know which MRQ is being responded to. "When a responder is unable to provide an immediate response to MRQ and sets MFB to all-ones it also sets MFS to the corresponding MRS." 8075SolomonSeparated basic MCS set for 20Mhz and 40Mhz New field 8066Solomon and Sanjiv Separated supported MCS set for 20Mhz and 40Mhz New field

4. doc.: IEEE 802.11-06/1774r0 Submission 2006-11-14 Peter Loc, MarvellSlide 4 Deferred CIDs with Assignees (2) 2125SriniIE length of 26 is excessive for listing these capabilities. Reduce the number of options. Reduce the number of bits needed to describe these options, and consider putting them in the Extended Capabilities IE rather than a new IE. 3756SriniGiven the large number of optional frames, this field will have a few bits set to 1 (for mandatory only 8) and all the other bits set to 0. Given this case, it makes more sense to have the supported MCS set indicated in an IE. Remember that in 2.4 GHz, generally the beacon will be sent at 1 Mbps and a beacon already lasts longer than a millisecond (200 bytes = 1600 bits takes 1.792 microseconds). Please do not be indiscriminate with the fields in a beacon. Move the Supported MCS set out of HT Capability Information Element. Create a new Supported MCS IE with a variable length field. 3758SriniThis field is a great candidate to have its own IE. There is no real danger of specifying too many IEs - there are still around 200 available Make this field into an IE 3760SriniGroup parameters based on the functionality and put them in IEs to make the parsing of the frames easier. Move MCS feedback out of the Extended HT Capability Info field 4634SriniA status code that AP denies association when a STA does not meet the 802.11n feature should be defined. Add a status code for the HT AP to deny association due to the requesting STA not supporting the 802.11n feature. 3741SriniSurely there should be some new reason codes for disassociation - such as not switching the required mode etc. Add a few reason codes

5. doc.: IEEE 802.11-06/1774r0 Submission 2006-11-14 Peter Loc, MarvellSlide 5 Deferred CIDs with Assignees (3) 7254YuichiThe comments on the first row, inclusion of BlockAck in an A- MPDU states that BA may be aggregated. Note that statement in page-88 line 22- 23 specifies that control frames use non-HT basic rate according to sub clause 9.6.2. and that is chosen primarily (amongst a few reasons) so that the legacy STAs and OBSS STAs can hear the legacy PPDU and set their NAV accordingly. If however the transmitter obeys the rate decision rule but use A-MPDU aggregation this defeats the purpose. Change the text in the table to "BlockAck SHALL be non- aggregate frame (see BlockAck explanation)". Alternatively, remove BA from this table and mandate not to include BA in the A_MPDU aggregation even if it is delayed BA with no ACK. Efficiency improvement can be achieved by RIFS/SIFS bursting instead. It's agreed that a resolution is deferred until a submission (work in progress by Yuichi et all) is put forward to further clarify section 9.6

6. doc.: IEEE 802.11-06/1774r0 Submission 2006-11-14 Peter Loc, MarvellSlide 6 Request for transfer to Beam Forming from Remaining CIDs Tomoya Yamaura has a submission that will resolve the following CIDs and has requested the transfer to Beam Forming 1236, 2268, 3810, 7820, 660, 1235, 2257, 4222, 7823, 7826, 7830