1 / 281

TGac PHY AdHoc Report

TGac PHY AdHoc Report. Authors:. Date: 2010-11-08. Abstract. Agenda, Minutes and Motions for the TGac PHY Ad Hoc since November 2009. Important IEEE Links. The following slides in this deck are believed to be the latest available however the Source locations are:

relodia
Télécharger la présentation

TGac PHY AdHoc Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TGac PHY AdHoc Report Authors: Date: 2010-11-08 Erceg, Banerjea, and Cheong

  2. Abstract • Agenda, Minutes and Motions for the TGac PHY Ad Hoc since November 2009 Erceg, Banerjea, and Cheong

  3. Important IEEE Links • The following slides in this deck are believed to be the latest available however the Source locations are: • http://standards.ieee.org/faqs/affiliationFAQ.html • http://standards.ieee.org/resources/antitrust-guidelines.pdf • http://standards.ieee.org/board/pat/pat-slideset.ppt • http://www.ieee.org/portal/cms_docs/about/CoE_poster.pdf • For summary, see 11-07-0660-01-0000-opening-presentation • Don’t forget attendance check during PHY AdHoc session. Erceg, Banerjea, and Cheong

  4. Member Affiliation • It is defined in the IEEE-SA Standards Board Bylaws, 5.2.1.5 as: “An individual is deemed “affiliated” with any individual or entity that has been, or will be, financially or materially supporting that individual’s participation in a particular IEEE standards activity. This includes, but is not limited to, his or her employer and any individual or entity that has or will have, either directly or indirectly, requested, paid for, or otherwise sponsored his or her participation. • http://standards.ieee.org/faqs/affiliationFAQ.html Erceg, Banerjea, and Cheong

  5. Declaration of Affiliation • Revision: May 2007 Standards Board Bylaw 5.2.1.1 • 5.2.1.1 Openness • Openness is defined as the quality of being not restricted to a particular type or category of participants. All meetings involving standards development an all IEEE Sponsor ballots shall be open toa all interested parties. Each individual participant in IEEE Standards activities shall disclose his or her affiliations when requested. A person who knows or reasonably should know, that a participant’s disclosure is materially incomplete or incorrect should report that fact to the Secretary of the IEEE-SA Standards Board and the appropriate Sponsors. • http://standards.ieee.org/faqs/affiliationFAQ.html Erceg, Banerjea, and Cheong

  6. Affiliation Policy • Requirement to declare affiliation at all standards development meetings and recorded in the minutes • Affiliation not necessarily same as employer • Declaration requirement may be familiar to some 802 WGs, though WG declaration process may evolve • 11. What if I refuse to disclose my affiliation? • As outlined in IEEE-SA governance documents, you will lose certain rights. In a working group where voting rights are gained through attendance, no attendance credit will be granted if affiliation isn’t declared. Similarly, voting rights are to be removed if affiliation isn’t declared. • Affiliation declaration will be added to Sponsor ballot • http://standards.ieee.org/faqs/affiliationFAQ.html Erceg, Banerjea, and Cheong

  7. Highlights of the IEEE-SA Standards Board Bylaws on Patents in Standards • Participants have a duty to tell the IEEE if they know (based on personal awareness) of potentially Essential Patent Claims they or their employer own • Participants are encouraged to tell the IEEE if they know of potentially Essential Patent Claims owned by others • This encouragement is particularly strong as the third party may not be a participant in the standards process • Working Group required to request assurance • Early assurance is encouraged • Terms of assurance shall be either: • Reasonable and nondiscriminatory, with or without monetary compensation; or, • A statement of non-assertion of patent rights • Assurances • Shall be provided on the IEEE-SA Standards Board approved LOA form • May optionally include not-to-exceed rates, terms, and conditions • Shall not be circumvented through sale or transfer of patents • Shall be brought to the attention of any future assignees or transferees • Shall apply to Affiliates unless explicitly excluded • Are irrevocable once submitted and accepted • Shall be supplemented if Submitter becomes aware of other potential Essential Patent Claims • A “Blanket Letter of Assurance” may be provided at the option of the patent holder • A patent holder has no duty to perform a patent search • Full policy available at http://standards.ieee.org/guides/bylaws/sect6-7.html#6 1 Erceg, Banerjea, and Cheong

  8. IEEE-SA Standards Board Bylaws on Patents in Standards 6.2 Policy IEEE standards may be drafted in terms that include the use of Essential Patent Claims. If the IEEE receives notice that a [Proposed] IEEE Standard may require the use of a potential Essential Patent Claim, the IEEE shall request licensing assurance, on the IEEE Standards Board approved Letter of Assurance form, from the patent holder or patent applicant. The IEEE shall request this assurance without coercion. The Submitter of the Letter of Assurance may, after Reasonable and Good Faith Inquiry, indicate it is not aware of any Patent Claims that the Submitter may own, control, or have the ability to license that might be or become Essential Patent Claims. If the patent holder or patent applicant provides an assurance, it should do so as soon as reasonably feasible in the standards development process. This assurance shall be provided prior to the Standards Board’s approval of the standard. This assurance shall be provided prior to a reaffirmation if the IEEE receives notice of a potential Essential Patent Claim after the standard’s approval or a prior reaffirmation. An asserted potential Essential Patent Claim for which an assurance cannot be obtained (e.g., a Letter of Assurance is not provided or the Letter of Assurance indicates that assurance is not being provided) shall be referred to the Patent Committee. A Letter of Assurance shall be either: a) A general disclaimer to the effect that the Submitter without conditions will not enforce any present or future Essential Patent Claims against any person or entity making, using, selling, offering to sell, importing, distributing, or implementing a compliant implementation of the standard; or b) A statement that a license for a compliant implementation of the standard will be made available to an unrestricted number of applicants on a worldwide basis without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination. At its sole option, the Submitter may provide with its assurance any of the following: (i) a not-to-exceed license fee or rate commitment, (ii) a sample license agreement, or (iii) one or more material licensing terms. 2 Erceg, Banerjea, and Cheong

  9. IEEE-SA Standards Board Bylaws on Patents in Standards Copies of an Accepted LOA may be provided to the working group, but shall not be discussed, at any standards working group meeting. The Submitter and all Affiliates (other than those Affiliates excluded in a Letter of Assurance) shall not assign or otherwise transfer any rights in any Essential Patent Claims that are the subject of such Letter of Assurance that they hold, control, or have the ability to license with the intent of circumventing or negating any of the representations and commitments made in such Letter of Assurance. The Submitter of a Letter of Assurance shall agree (a) to provide notice of a Letter of Assurance either through a Statement of Encumbrance or by binding any assignee or transferee to the terms of such Letter of Assurance; and (b) to require its assignee or transferee to (i) agree to similarly provide such notice and (ii) to bind its assignees or transferees to agree to provide such notice as described in (a) and (b). This assurance shall apply to the Submitter and its Affiliates except those Affiliates the Submitter specifically excludes on the relevant Letter of Assurance. If, after providing a Letter of Assurance to the IEEE, the Submitter becomes aware of additional Patent Claim(s) not already covered by an existing Letter of Assurance that are owned, controlled, or licensable by the Submitter that may be or become Essential Patent Claim(s) for the same IEEE Standard but are not the subject of an existing Letter of Assurance, then such Submitter shall submit a Letter of Assurance stating its position regarding enforcement or licensing of such Patent Claims. For the purposes of this commitment, the Submitter is deemed to be aware if any of the following individuals who are from, employed by, or otherwise represent the Submitter have personal knowledge of additional potential Essential Patent Claims, owned or controlled by the Submitter, related to a [Proposed] IEEE Standard and not already the subject of a previously submitted Letter of Assurance: (a) past or present participants in the development of the [Proposed] IEEE Standard, or (b) the individual executing the previously submitted Letter of Assurance. 3 Erceg, Banerjea, and Cheong

  10. IEEE-SA Standards Board Bylaws on Patents in Standards The assurance is irrevocable once submitted and accepted and shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of those Patent Claims, or for determining whether any licensing terms or conditions are reasonable or non-discriminatory. Nothing in this policy shall be interpreted as giving rise to a duty to conduct a patent search. No license is implied by the submission of a Letter of Assurance. In order for IEEE’s patent policy to function efficiently, individuals participating in the standards development process: (a) shall inform the IEEE (or cause the IEEE to be informed) of the holder of any potential Essential Patent Claims of which they are personally aware and that are not already the subject of an existing Letter of Assurance, owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents; and (b) should inform the IEEE (or cause the IEEE to be informed) of any other holders of such potential Essential Patent Claims that are not already the subject of an existing Letter of Assurance. 4 Erceg, Banerjea, and Cheong

  11. Other Guidelines for IEEE WG Meetings • All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. • Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. • Don’t discuss specific license rates, terms, or conditions. • Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. • Technical considerations remain primary focus • Don’t discuss fixing product prices, allocation of customers, or dividing sales markets. • Don’t discuss the status or substance of ongoing or threatened litigation. • Don’t be silent if inappropriate topics are discussed… do formally object. • --------------------------------------------------------------- • If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org or visit http://standards.ieee.org/board/pat/index.html • See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details. • This slide set is available at http://standards.ieee.org/board/pat/pat-slideset.ppt 5 Erceg, Banerjea, and Cheong

  12. Important Questions about Patents • Are there any patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) that the participant believes may be essential for the use of that standard? • Minute any responses that were given, specifically the patent claim(s)/patent application claim(s) and/or the holder of the patent claim(s)/patent application claim(s) that were identified (if any) and by whom. Erceg, Banerjea, and Cheong

  13. Ad Hoc Operating Rules (1/2) • 11ac selection procedure (11-09-0059r5) 5. b. A straw poll result of >=75% is required within an Ad Hoc to approve the resolution of all or part of an issue and forward that resolved item to the Taskgroup where it becomes a motion that requires >=75% approval to modify the specification framework or the draft specification. c. In the case a consensus can not be reached within an Ad Hoc group (a stalemate that prohibits further progress), the subject is moved to the Taskgroup if an Ad Hoc straw poll vote to move the subject to the Taskgroup achieves >50% approval. Slide 13 Erceg, Banerjea, and Cheong

  14. Ad Hoc Operating Rules (2/2) d. A motion passing with >50% in the Taskgroup shall be sufficient to move an issue previously assigned to an Ad Hoc group to any Ad Hoc group. A straw poll vote of >50% is required in an Ad Hoc group to refuse an issue from the Taskgroup. e. An issue may be sent from one Ad Hoc to another if both the sending Ad Hoc and the receiving Ad Hoc approve straw polls for taking the respective actions with >50% approval. A notice should be sent to the reflector indicating the approval of a straw poll to move an issue. f. To be accepted into the TGac Draft specification, proposals from Ad Hoc group require a motion that passes with >=75% Taskgroup approval Slide 14 Erceg, Banerjea, and Cheong

  15. PHY AdHoc Topics • PHY AdHoc group discussion topics in document 11-09-1175-01-00ac-ad-hoc-groups-scope.ppt: • Pilots • Data tones • Preamble • Enhanced MCS • Sounding • Higher Bandwidth modulation • Parsing and Interleaving • Coding, STBC • Spatial Mapping & Cyclic Delays • Mask, Regulatory, ACI, Sensitivity, etc. - additional possible topics Erceg, Banerjea, and Cheong

  16. Running PHY AdHoc Agenda Pages Erceg, Banerjea, and Cheong

  17. Interpretive Guide – Text Coloring • Text coloring: • Black = pending agenda item • Red = item partially addressed • Green = item completed • Gray = item not addressed in the session indicated at the top of the slide Erceg, Banerjea, and Cheong

  18. TGac PHY Adhoc November 8 -11, 2010 Review Ad Hoc operating rules Review previous activities Review Ad Hoc scope Call for contributions Submissions Next meeting Slide 18 Slide 18 Erceg, Banerjea, and Cheong

  19. TGac Schedule in a Glance Erceg, Banerjea, and Cheong

  20. PHY Adhoc Submissions (1) November 2010 • 11-10/1290r0 VHT SIG B in NDPs (Allert Van Zelst) • 11-10/1282r0 plcp-rx-procedure (Eldad Perahia) • 11-10/1264r1 160 MHz Stream Parser (Hongyuan Zhang) • 11-10/1279r0 Segment Parser for 160 MHz (Minho Cheong) • 11-10/1255r0 Tx Mask for Noncontiguous 160 MHz (Youhan Kim) • 11-10/1300r0 ldpc-for-11ac (Jun Zheng) • 11-10/1301r0 legacy-csd-table (Jun Zheng) • 11-10/1105r1 Explicit Sounding and Feedback (Hongyuan Zhang) • 11-10/1265r0 Explicit feedback dimension reduction procedures (Nir Shapira) • 11-10/1266r0 MCS control over explicit sounding feedback (Nir Shapira) • 11-1275r0 Complexity reduction of time domain H matrix feedback (Laurent) • 11-10/1277r0 MU-MIMO support for Heterogeneous Devices (Daewon Lee) • 11-10/1227r0 11ac Explicit Feedback (Joonsuk Kim) Slide 20 Erceg, Banerjea, and Cheong

  21. Tentative TGac Agenda for the Week Monday AM1 (9:00-11:00) 11-10/1282r0 plcp-rx-procedure (Eldad Perahia) 11-10/1290r0 VHT SIG B in NDPs (Allert Van Zelst) 11-10/1255r0 Tx Mask for Noncontiguous 160 MHz (Youhan Kim) 11-10/1264r1 160 MHz Stream Parser (Hongyuan Zhang) 11-10/1279r0 Segment Parser for 160 MHz (Minho Cheong) 11-10/1300r0 ldpc-for-11ac (Jun Zheng) 11-10/1301r0 legacy-csd-table (Jun Zheng) Tuesday AM1 (8:00-10:00) 11-10/1105r1 Explicit Sounding and Feedback (Hongyuan Zhang) 11-10/1265r0 Explicit feedback dimension reduction procedures (Nir Shapira) 11-10/1266r0 MCS control over explicit sounding feedback (Nir Shapira) 11-1275r0 Complexity reduction of time domain H matrix feedback (Laurent) 11-10/1277r0 MU-MIMO support for Heterogeneous Devices (Daewon Lee) 11-10/1227r0 11ac Explicit Feedback (Joonsuk Kim) November 2010 Slide 21 Erceg, Banerjea, and Cheong

  22. Running TGac PHY AdHoc Minutes Erceg, Banerjea, and Cheong

  23. Pre-Motion #1 (VHT SIG-B in NDP)“11-10-1290-00-00ac-vht-sig-b-in-ndp” Move to accept the bit patterns as listed on slide 5 as the fixed bit patterns for VHT-SIG-B in VHT NDPs? Y : 45 N : 0 A : 7 Pre-Motion passes

  24. Pre-Motion #2 (TX Mask for Non-contiguous 160MHz)“11-10-1255-00-00ac-tx-mask-for-noncontiguous-160-mhz” • Do you support the transmit spectral mask for noncontiguous 160 MHz transmissions as described on slide 5, and to edit the specification framework document (11-09/0992) accordingly? • Y : 46 • N : 0 • A : 1 • Pre-Motion passes Erceg, Banerjea, and Cheong

  25. Pre-Motion #3 (160MHz Stream Parser)“11-10-1264-00-00ac-160mhz-stream-parser” • Do you agree to insert the following text into 3.2.4.3.1 (Stream Parser) of the spec framework? • “For 160MHz MCSs, if each BCC encoder does not generate integer blocks of S coded bits in each OFDM symbol, then apply the same stream parsing method until the last integer block (floor(NCBPS/NES/S)) of S bits at each encoder. Assuming that at this point in each OFDM symbol each BCC has M.s (M<NSS) residue bits, take the last M.s bits in the current OFDM symbol from the first encoder and allocate them to the first M spatial streams (s bits to each stream); then take the last M.s bits in the current OFDM symbol from the second encoder and distribute these among M spatial streams, starting from the (M + 1)-th spatial stream, and so on. Note that upon reaching the NSS’th spatialstream, we cycle back to the 1st spatial stream. Repeat till all bits are distributed in the current OFDM symbol.” • Y : 40 • N : 0 • A : 1 • Pre-Motion passes Erceg, Banerjea, and Cheong

  26. Pre-Motion #4 (Segment Parser for 160MHz)“11-10-1279-00-00ac-segment-parser-for-160mhz” • Do you support to accept supplementation of 160MHz segment parser (as described in slides 10-12) and modify the IEEE Specification Framework for TGac as shown on slide 20? • Y : 46 • N : 0 • A : 0 • Pre-Motion passes Erceg, Banerjea, and Cheong

  27. Pre-Motion #5 (MCS for Both BCC and LDPC)“11-10-1300-00-00ac-ldpc-for-11ac” • Do you support to use the same MCS table for both BCC and LDPC? • Y : 41 • N : 0 • A : 2 • Pre-Motion passes Erceg, Banerjea, and Cheong

  28. Pre-Motion #6 (LDPC Encoding Process-1)“11-10-1300-00-00ac-ldpc-for-11ac” • Do you support to use the same LDPC PPDU encoding process from 802.11n (described in Section 20.3.11.6.5) for 11ac, regarding codeword length, shortening, puncturing and repetition? • Y : 39 • N : 1 • A : 0 • Pre-Motion passes Erceg, Banerjea, and Cheong

  29. Pre-Motion #7 (LDPC Encoding Process-2) “11-10-1300-00-00ac-ldpc-for-11ac” • Do you support to use the proposed solution in slide 9-12 for LDPC encoding/decoding process and modify the IEEE Specification Framework for TGac as suggested by Appendix A? • Y : 40 • N : 0 • A : 1 • Pre-Motion passes Erceg, Banerjea, and Cheong

  30. Pre-Motion #8 (LDPC Tone Mapping) “11-10-1300-00-00ac-ldpc-for-11ac” • Do you support adopting the concept of LDPC tone mapping, as described in slide 15-18, for LDPC-coded streams with DTM=4/6/9/9 for 20/40/80/160 MHz? (Tone interleaving for 160 is done as 2 separate 80)? • Y : 39 • N : 0 • A : 2 • Pre-Motion passes Erceg, Banerjea, and Cheong

  31. Pre-Motion #9 (Legacy CSD Table)“ 11-10-1301-00-00ac-legacy-csd-table-for-11ac” • Do you support to use the following CSD table for legacy preamble and add the language provided in Appendix to Clause 3.2.3.1.1 of the IEEE Specification Framework for TGac ? • Y : 47 • N : 1 • A : 1 • Pre-Motion passes Erceg, Banerjea, and Cheong

  32. Pre-Motion #10(compressed V matrix0 • Do you agree to adopt compressed V matrix feedback (based on 20.3.12.2.5 and 7.3.1.29 in 11n spec) as the only feedback format for SU beamforming and MU-MIMO, and add the same statement into the spec framework? • Yes 57 • No 5 • Abstain 19

  33. Pre Motion #11(11-10-1265-01-00ac-explicit-feedback-dimension-reduction-procedures.ppt) November 2010 • Do you support enabling the beamformer to control the explicit feedback dimension for each user in MU-MIMO operation, and to update the specification framework document accordingly? • Yes 25 • No 3 • Abstain 47 Slide 33 Nir Shapira et al, Celeno Communications

  34. Pre Motion #12 (11-10-1265-01-00ac-explicit-feedback-dimension-reduction-procedures.ppt) November 2010 • Do you support adding TBD dimension reduction information per user in MU-MIMO operation to the NDPA frame, and update the Specifications Framework document accordingly? • Yes 19 • No 4 • Abstain 49 Slide 34 Nir Shapira et al, Celeno Communications

  35. Straw Poll #111-10-1266-00-00ac-mcs-control-over-explicit-sounding-feedback.ppt November 2010 • Do you support having a separate MCS recommendation for uplink traffic and for the explicit sounding feedback frame? • Yes 3 • No 39 • Abstain 28 Slide 35 Nir Shapira et al, Celeno Communications

  36. Pre-motion #13 Do you support updating the spec framework to require that time domain H matrix feedback, be one feedback format for both VHT SU beamforming and DL MU-MIMO? Yes 16 No 38 Abstain 27

  37. Pre-Motion #1411-10-1277-00-00ac-mu-mimo-support-for-heterogeneous-devices.ppt Nov 2010 • Do you agree to redefine the VHT-SIG-A2 bit B2, B4, B5, and B6 in the specification framework document r15 to be described as following? • For SU: • B2: Set to 0 for BCC, 1 for LDPC • For MU: • B2: Set to 0 for BCC, 1 for LDPC for the 1st user • B4: Set to 0 for BCC, 1 for LDPC for the 2nd user • B5: Set to 0 for BCC, 1 for LDPC for the 3rd user • B6: Set to 0 for BCC, 1 for LDPC for the 4th user • Note: if user 1, 2, 3, and/or 4 has 0 Nsts value, then corresponding bit is reserved and set to 1 • Yes: 61 No:0 Abstain:10 Slide 37 Byeongwoo Kang, LG Electronics

  38. Pre-Motion #1511-10-1227-00-00ac-11ac-explicit-feedback-format.ppt • Do you support the VHT MIMO Control Field in the beamforming report frame as described in slide 5 and to update the VHT MIMO Control Field in the spec framework document accordingly? • Yes: 38 • No: 1 • Abs: 9

  39. Pre-Motion #1611-10-1227-00-00ac-11ac-explicit-feedback-format.ppt • Do you support feedback tone mapping as shown on slide 14 and to define it in the spec framework document accordingly? • Yes: 46 • No: 0 • Abs: 2

  40. Pre-Motion #1711-10-1227-00-00ac-11ac-explicit-feedback-format.ppt • Do you support Sub-Channel Feedback Tone Interpretation as in slide 15 and add the text in the spec framework document? • Yes: 48 • No: 0 • Abs: 2

  41. Pre-Motion #1811-10-1227-00-00ac-11ac-explicit-feedback-format.ppt • Do you support to include per-tone-SNR field in the MU-exclusive beamforming report as described in slide 19 and 20, and to add the proposed field in the spec framework document? • Yes: 43 • No: 1 • Abs: 5

  42. Pre-Motion #1911-10-1227-00-00ac-11ac-explicit-feedback-format.ppt • Do you support to define SNR per tone for PT-SNR subfield as described in slide 18 and to add the proposed text in the second bullet in the spec framework document? • Yes: 43 • No: 1 • Abs: 2

  43. Pre-motion #20 • Do you support the following channelization scheme for China, and then modify the 11ac spec framework accordingly? • In this scheme, the 120MHz channel is optional, Compatibility mode 5835 • Yes: 27 • No: 50 • Abs: 21 5735 20MHz 40MHz 80MHz Enhanced mode 20MHz 40MHz 80MHz 120MHz Slide 43 5847.5 5727.5 f MHz

  44. Pre-motion #21 • Do you support the following channelization scheme for China, and modify the 11ac specification framework document accordingly? • In this scheme, the 120MHz channel is optional. • Yes: 32 • No: 35 • Abs: 30 5835 5735 20MHz 40MHz 80MHz f MHz 120MHz 5847.5 5727.5 Slide 44

  45. Pre-motion #22 • Do you support the following channelization scheme for China, and then modify the 11ac spec framework accordingly? • In this scheme, the 120MHz channel is optional, Compatibility mode 5835 5735 • Yes: 27 • No: 37 • Abs: 9 20MHz 40MHz 80MHz Enhanced mode 20MHz 40MHz 80MHz 5847.5 5727.5 f MHz Slide 45

  46. Pre-motion #23 • Do you support an optional 120 MHz channel for China, and modify the 11ac specification framework accordingly? • In this scheme, the 120MHz channel is optional, • Yes: 28 • No: 32 • Abs: 32 f MHz 120MHz 5847.5 5727.5 f MHz

  47. Minutes Taking • Chairs/volunteers will take notes • Lever of detail recorded: • Documents presented • Action items and conclusions, if applicable • Straw polls • Other items, if applicable • No Q&A will be recorded Erceg, Banerjea, and Cheong

  48. TGac PHY AdHoc MinutesMONTH DAY, YEAR • Document xx presentation • Discussion related to yy • Outcome of the discussion: xx • Straw poll: • “ xx “ • Outcome of the straw poll: YES/NO/ABS: xx/xx/xx TEMPLATE Erceg, Banerjea, and Cheong

  49. TGac PHY AdHoc MinutesNovember 8, 2010 AM1 Session (1/3) Document IEEE 802.11-10/1282r0 presented “PLCP Rx Procedure” by Eldad Perahia (Intel) PLCP Rx procedure is proposed including auto-detection, RX-TIME calculation and so son Question on un-supported modes by Asaaf (Intel) Document IEEE 802.11-10/1290r0 presented “VHT SIG-B in NDPs” by Allert van Zelst (Qualcomm) Specific bit pattern is proposed to reduce its PAPR Pre-Motion #1 passes Slide 49 Erceg, Banerjea, and Cheong

  50. TGac PHY AdHoc MinutesNovember 8, 2010 AM1 Session (2/3) Document IEEE 802.11-10/1255r0 presented “TX Mask for Non-contig. 160MHz” by Youhan Kim (Atheros) Spectral mask for non-contiguous 160MHz is proposed Pre-Motion #2 passes Document IEEE 802.11-10/1264r0 presented “160MHz Stream Parser” by Hongyuan Zhang (Marvell) Solution to deal with corner cases in 160MHz stream parsing Pre-Motion #3 passes Document IEEE 802.11-10/1279r0 presented “Segment Parser for 160MHz” by Minho Cheong (ETRI) Segment parsing in blocks of s·Nes bits is proposed Pre-Motion #4 passes Slide 50 Erceg, Banerjea, and Cheong

More Related