doc.: IEEE /0701r0 Submission May 2007 Petranovich (CNXT) and Kasher (INTC)Slide 1 Non-HT Duplicate Format 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. ieee802.org/guides/bylaws/sb-bylaws.pdf Date: Authors:

doc.: IEEE /0701r0 Submission May 2007 Petranovich (CNXT) and Kasher (INTC)Slide 2 Abstract Discussion on how the standard should refer to non-HT duplicate format. The central question is whether non- HT duplicate format should be considered an HT format. This is a standard structural issue and there is no intent for any possible resolution of the issues stated to cause functional changes to devices complying with the standard

doc.: IEEE /0701r0 Submission May 2007 Petranovich (CNXT) and Kasher (INTC)Slide 3 Non-HT Duplicate format Non-HT duplicate format is a format defined in n –40 MHz transmission –Consists of two non-HT (legacy) transmission in adjacent 20 MHz bands –Intended to allow transmission of legacy-compatible frames (for setting NAV, etc.) HT duplicate format (MCS 32) is quite different and will not be discussed in this presentation

doc.: IEEE /0701r0 Submission May 2007 Petranovich (CNXT) and Kasher (INTC)Slide 4 Issue n D2.0 includes non-HT duplicate format –802.11n is the High Throughput (HT) PHY –Non-HT duplicate format is defined only in the HT draft, not in any other drafts –Non-HT duplicate format is subject to a transmit mask found only in the HT draft –Rules for transmitting non-HT duplicate format are found in the HT draft Yet non-HT duplicate format is defines as not being an HT-format. What is it?

doc.: IEEE /0701r0 Submission May 2007 Petranovich (CNXT) and Kasher (INTC)Slide 5 Proposal #1 Propose to –Rename non-HT duplicate format to be HT-Dual Format (HT-DF) –Define HT-DF to be an HT format There will be 3 HT PHY formats: HT-MF (Mixed Format), HT-GF (Greenfield Format), and HT-DF (Dual format) Clarify each reference on non-HT formats in the draft as to whether the rule applies to HT-DF or not –Potentially create two new PHY group names One for HT-GF and HT-MF One for HT-DF and non-HT formats

doc.: IEEE /0701r0 Submission May 2007 Petranovich (CNXT) and Kasher (INTC)Slide 6 Proposal #2 Define HT-Duplicate (and 20MHz_Upper and 20MHz_lower) as a new type of legacy modulations. –Define modulations according to their nature and behavior (“technical” issue) and not where they are defined in a document (“editorial” issue) –All of these modulations are used in places where “legacy” modulations can be used. –All of these modulations can be decoded by non-HT devices. Reserve the HT definition to devices that can only decode the HT-SIG. –Defining these modulation as non-HT simplifies many parts of the draft. See r1 for changes in TX/RXVECTOR

doc.: IEEE /0701r0 Submission May 2007 Petranovich (CNXT) and Kasher (INTC)Slide 7 Strawpoll Do you prefer –Option #1 –Option #2 –D2.0 usage –Need a different solution –Abstain