
Discussion on MC-OOK Modulation Technique in IEEE 802.11-23/0104r0 Document
This document discusses the technical aspects of MC-OOK modulation technique in the IEEE 802.11 standard, highlighting proposals, arguments, and concerns related to its implementation. It questions the necessity of making MC-OOK a requirement and emphasizes the importance of adhering to antitrust and competition policies in technical standards development.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
January 2023 doc.: IEEE 802.11-23/0104r0 Discussion on MC-OOK Date: 2023-01-16 Authors: Name Affiliations InterDigital Communication, Inc. Address 111 W 33rd Street New York, NY 10120 Phone email Joseph LEVY +1.631.622.4139 jslevy@ieee.org Submission Slide 1 Joseph Levy (InterDigital)
January 2023 doc.: IEEE 802.11-23/0104r0 Abstract This contribution discusses the resolution of LB 270 CIDs: 3067-3068, 3070- 3072, 3095-3096, 3278, 3283, 3458. At the TGme ad hoc meeting in Piscataway NJ Dec 5-7 resolutions were proposed for these CIDs: 11-22/2090r0 and 11-22-2083r1. A straw poll supported continuing in the direction proposed by 1-22/2090r0. This contributions questions that direction. Submission Slide 2 Joseph Levy (InterDigital)
January 2023 doc.: IEEE 802.11-23/0104r0 Status of the MC-OOK discussion Proposals have been made to clarify that MC-OOK is a modulation technique and that it is not a wave form or required to generate the specified WUR OOK modulation. These proposal have not been agreed. There have been no technical arguments made to support that MC-OOK is a modulation or that it is required to generate WUR OOK transmissions. Proposals have been made to make MC-OOK a required technique for generating the WUR OOK transmissions. These proposals seem to have significant support. Submission Slide 3 Joseph Levy (InterDigital)
January 2023 doc.: IEEE 802.11-23/0104r0 A technical discussion of MC-OOK Is MC-OOK a technique for generating the OOK wave form used in WUR? Yes the OOK waveform can be generated by MC-OOK Is MC-OOK a type of wave form? No MC-OOK is a technique for generating an OOK waveform using a multi-carrier transmitter Is MC-OOK the only technique able to generate the WUR OOK signal? No the WUR OOK signal can be generated by any modulation technique that will meet the WRU OOK requirements provide in 30.3.12 Will a WUR receiver be able to receive any WUR OOK signal meeting the requirements 30.3.12 Yes a WUR receiver will receive any WUR OOK signal independent on how it was generated, if it meets the reequipments in 30.3.12 and is encoded with an valid WUR-Sync field and a valid WUR- Data field (Contrary to the current spec which seems to require MC-OOK modulation technique, the technique is not technically required to encode the WUR OOK signal.) Therefore MC-OOK is a modulation technique it is not a waveform or required. Submission Slide 4 Joseph Levy (InterDigital)
January 2023 doc.: IEEE 802.11-23/0104r0 What is the problem with making MC-OOK a requirement IEEE Standards strictly require adherence to Antitrust, Competition and Commercial Terms Policies: There are less obvious kinds of anticompetitive conduct. Technical standards necessarily include technical content, but that content must be technically justified. Technical requirements should never be included for the purpose of unreasonably impeding a company s ability to compete, or unreasonably creating an advantage for one or a group of companies. This does not mean that the technical requirement has to be written so that all competitors can implement the standard without satisfying what would be a more rigorous standard s requirement. But it does mean that you should guard against technical content being inserted for anticompetitive purposes. [1] Submission Slide 5 Joseph Levy (InterDigital)
January 2023 doc.: IEEE 802.11-23/0104r0 References [1] IEEE SA: Antitrust and Competition Policy What You Need to Know , pamphlet Submission Slide 6 Joseph Levy (InterDigital)