Frequency and Clock Tolerance Comments September, 2008 doc.: IEEE 802.11-08/1112r1 September, 2008 Frequency and Clock Tolerance Comments Date: 2008-09-09 Authors: Carl Kain, Noblis Carl Kain, Noblis

September, 2008 doc.: IEEE 802.11-08/1112r1 September, 2008 Abstract This presentation addresses comments concerning frequency and clock tolerance, CID 375-378; 380, 382-384, 386, 387, 388, 389, 391, 392. Carl Kain, Noblis Carl Kain, Noblis

Frequency and Clock Tolerance September, 2008 Frequency and Clock Tolerance Base standard specifies 10 ppm for both frequency and clock tolerance for 5 MHz channels Base standard specifies 20 ppm for both frequency and clock tolerance for 10 MHz channels TGp Draft 4.0 specifies 10 ppm for both frequency and clock tolerance for 10 MHz channels Commenters who oppose tighter values want either rationale or are primarily are concerned with cost Carl Kain, Noblis

Comments From Master Spreadsheet September, 2008 Comments From Master Spreadsheet 375 Fischer, Matthew 17.3.9.4 22 41 TR The tolerance value seems too tight. Previous specifications have always allowed +-/20ppm, which seems to be implementable. Change the tolerance to +/- 20 ppm. 376 Hansen, Christopher The tolerance value is too tight. This will unnecessarily increase the cost of implementations. Previous specifications have allowed +-/20ppm, which is reasonable. 377 Trachewsky, Jason The frequency accuracy requirement is too tight. 378 Wang, Qi "The transmitted center frequency tolerance shall be +/-10ppm maximum for 10 MHz channels used by a STA in the WAVE mode." What is the rational to have such a tight tolerance value? Previous specifications have always allowed +/-20ppm, which seems to be implementable. Carl Kain, Noblis

Comments From Master Spreadsheet September, 2008 Comments From Master Spreadsheet 380 Erceg, Vinko 17.3.9.4 22 46 TR It is not clear to me that the transmit frequency tolerance of +/-10 PPM is required. Crystal at that tolerance level is expensive! Change the tolerance to +/-20 ppm or show simulation results that prove that +/- 10 ppm is required. 382 Kolze, Thomas Transmit frequency tolerance of +/-10 PPM is required but not shown to be needed. Relax the tolerance to +/-20 ppm or present case that proves +/- 10 ppm is required. 383 Moorti, Rajendra 10ppm frequency tolerance is too restrictive and cannot be easily / cheaply implemented. moreover, there is no need for such a tight tolerance since a 20ppm error can be corrected change to 20ppm tolerance 384 Roy, Richard There does not appear to be any requirement for a tighter tolerance on clock frequency or transmitter center frequency than those already in the standard.. The current implementations seem to work just fine in the harshest environments, both experimentally and theoretically. Without a valid requirement to tighten these specs, they should be left alone. Note that if a manufacturer of an ITS system implementing the WAVE capability decided to require a tighter tolerance on either or both of these parameters, such a requirement could easily be imposed in the procurement procedure. Remove this specification. Carl Kain, Noblis

September, 2008 Discussion Document 11-06-0878; Bob Sorrano of JHU discussed issue based on testing done on JHU campus Conclusion was: Results from initial testing using IEEE 802.11a devices as substitutes for 802.11p devices in a high speed environment indicated some problems could result in synching and maintaining signal lock which could be mitigated by requiring a more stringent frequency tolerance of ±10 ppm vs. the current ±20 ppm requirement that is sufficient for non-mobile and mobile platforms not required to communicate over high speeds. Additional rationale for tighter values Commenters are inquiring what TGp is doing differently to ensure the best possible performance for safety applications implemented in vehicles moving at high speeds Liability is a major practical issue; standard should reflect due diligence The 11-06-0878 technical background addressed high speed operation, which is now known not to have a significant effect on the issue of frequency or clock stability. Carl Kain, Noblis

September, 2008 Recommendation Recommend to accept comments 375,376,377,378,380,382,383,384 Instruct the editor to delete 17.3.9 from 802.11p D4.01 Moved: Carl Kain Second: Justin McNew For: 10 Against:0 Abstain:3 Carl Kain, Noblis

September, 2008 References 802.11-06-0878-00-000r0 Carl Kain, Noblis