TGn PHY Ad Hoc Submission on Selected Comments June 2006 doc.: IEEE 802.11-yy/xxxxr0 June 2006 TGn PHY Ad Hoc Submission on Selected Comments Date: 2006-06-20 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>. Jim Petranovich, Conexant Systems, Inc. Jim Petranovich, Conexant Systems, Inc.

June 2006 doc.: IEEE 802.11-yy/xxxxr0 June 2006 Abstract The presentation regards resolution of these comments from LB84 (referenced by CID) 517 8017 10373, 7518 140, 4021 4536 7164 Jim Petranovich, Conexant Systems, Inc. Jim Petranovich, Conexant Systems, Inc.

June 2006 CID 517 Comment “There is no editing instruction proceeding sub-clause” referring to P159, L9, clause 20. Recommend classifying this comment as editorial and transferring to the editor. Jim Petranovich, Conexant Systems, Inc.

June 2006 CID 8017 “First sentence refers to 802.11 a/b/g…should refer to the clauses”→“use Clause numbers for references to other 802.11 amendments” Recommend classifying this comment as editorial and transferring to the editor. Jim Petranovich, Conexant Systems, Inc.

CIDs 10373, 7518 June 2006 Recommended action Transfer to general “you can't reference 802.11a/b/g since they don't exist anymore (well soon won't), instead” →“reference the specific capabilities of 802.11 that are intended, either via the specific clauses or the conformance sets defined in Annex A.” “The PHY interface does not describe how to transmit clause 19 ERP-DSSS packets, for example. The issue is that this interface only supports those parameters that related to HT (or possibly clause 16) packet formats. “We are given a choice, either we have to describe a multiplexing function above the PLCP by which a MAC selects between coexisting PHYs, or we describe that a HT STA has a clause 20 PHY (and no other) and provide an interface expanded to support all possible modes and formats. To support this we need to add a DATARATE parameter, which is present for legacy modes and takes the values specified in table 172.” Recommended action Transfer to general Reason for transfer We request general ad hoc to recommend whether we treat legacy elements of 802.11 as a subset of the HT standard we treat legacy elements of 802.11 as a co-set of the HT standard Once the general ah hoc has made its recommendation, the PHY ad hoc and/or the editorial team will recommend how to proceed with specifics Jim Petranovich, Conexant Systems, Inc.

CIDs 140, 4021 Comments: Footnote 7 is missing (P161, L29) June 2006 CIDs 140, 4021 Comments: Footnote 7 is missing (P161, L29) Recommended resolution: Remove the reference to footnote 7 Jim Petranovich, Conexant Systems, Inc.

June 2006 CID 4536 “Format refers to that of the PPDU. PLCP is a procedure, not something that can have a format.” →“Change ‘PLCP’ to ‘PPDU’.” Recommend action: Classify as editorial, transfer to editorial team Jim Petranovich, Conexant Systems, Inc.

June 2006 CID 7164 “A tx PPDU could be quite long in time with aggregation. This makes the demodulator design difficult and also could lead to wasting system resources if the PPDU is huge” → “Limit the time duration of a PPDU to 10 msec explicitly somewhere in the PHY section of the draft. (I'm not sure which section of the PHY draft this belongs in.) The rule on PHY-level PPDU duration should also note that in regulatory regions where the maximum duration is less than 10 msec, this shorter duration must be respected. (It is alleged that the maximum allowed time in Japan is 4 msec, for example.) I expect that this latter regulatory requirement will complicate the MAC_PHY interface somewhat, as some PPDUs may be too long to send. The draft standard must clarify how this problem is resolved.” The motivation in making this comment is to limit the duration of a packet at the PHY level independent of any MAC rules. Since this is a layered specification there should be enough information in the PHY specification to complete a design independent of the MAC specification. I propose to add text under 20.3.14 (Transmit specification) limiting transmit time as measured from start of preamble to end at 10 msec I propose to add text under 20.2.2 (TXVEXTOR parameters) limiting the choice of parameters (including an equation) mandating that the vector passed to the transitter must conform to this requirement Before creating this text, I request an indication from embers of the PHY ad hoc on whether they might be interested in supporting these sort of changed. If there is enough interest I will attempt to craft a more complete proposal for presentation to the ad hoc and/or TGn. Jim Petranovich, Conexant Systems, Inc.

References 11/06-0693 PHY Comments from LB84 for TGn June 2006 doc.: IEEE 802.11-yy/xxxxr0 June 2006 References 11/06-0693 PHY Comments from LB84 for TGn Jim Petranovich, Conexant Systems, Inc. Jim Petranovich, Conexant Systems, Inc.