doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Denver Architectural Issues] Date Submitted: [06 March, 2006] Source: [Vern Brethour] Company [Time Domain Corp.] Address [7057 Old Madison Pike; Suite 250; Huntsville, Alabama 35806; USA] Voice:[(256) ], FAX: [(256) ], Re: [ a.] Abstract:[A brief overview of the architectural issues that have come up since the Hawaii meeting. ] Purpose:[To help members who have not been on the teleconference calls catch up.] Notice:This document has been prepared to assist the IEEE P 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 2 As we work to resolve comments, we are still coming across a few architectural issues. –We improved the bandplan. –The “peak” cross-correlation with a reference waveform does not address tracking performance. –The original delimiter does not work for low data rates & is sub-optimal for the others. –The CCA detection window has problems with low data rates.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 3 The Regulatory situation has been distracting on both the low performance end as well as the high performance end. Lower mask limits than FCC levels are a serious threat to the non-coherent modes. (The non-coherent radios have very little processing gain over what they can do with a single pulse.) The Japanese emphasis on high data rates for UWB is tempting us to overstep the bounds of our PAR. Bob says: “Don’t do it”. Still not sure how to manage a LDC requirement if it amterializes. Still waiting on text from Joe on DAA hooks from Hawaii.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 4 Band Group Channel Number Center Frequency (MHz) Chip Rate (MHz) Mandatory/Optional Optional Optional Optional Mandatory in low band Optional Optional Optional Optional Optional Mandatory in high band Optional Optional Optional Optional Optional Optional Where we’re at on the Band plan: 3 things to note. No longer a 2x relationship Moved the mandatory down one position Base chipping rate is the same between high and low band There is no discussion of band edges: only center frequencies. The intent was to allow narrower bands for Japan. Should think about a restriction of “not to exceed” on the width.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 5 So if we’re not calling out the edges of the bands, how do we expect to interoperate? What we said in Hawaii was that we would have a cross correlation coefficient greater that 0.7 when correlated with a root raised cosine pulse. After more thought, we realize that requirement is too loose.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 6 Requirement too loose? The issue is that a compliant waveform could meet the.7 requirement at the peak just fine, but then have the cross correlation fall off rapidly from the peak. This gets into a tracking issue. We have picked up a number of comments about modulation accuracy and EVM from people who are worried that we’re too loose specifying it this way.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 7 So what do we do? Phil Orlik did a nice analysis of this and it is in 06/099r0 on wirelessworld. Phil’s bottom line from 099r6: Suggest further specifying transmitted pulse shape by –Requiring main lobe of cross correlation function remain above 0.7 for sum length of time (0.6 – 1 ns seems easy to achieve) –Could also place limit on peak sidelobe: around 0.2 – 0.4 A value of 0.2 still admits a low order butterworth pulse shape but prohibits higher orders.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 8 What’s going on with the delimiter? The delimiter we “chose” in San Francisco was never much more than a place-holder. Francois calls the San Francisco placeholder the “baseline SFD” in his work. Francois shows how the delimiter can be improved in 06/011r0 on wirelessworld.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 9 So is this just petty twiddling? No! The San Francisco placeholder is really a crummy pattern. The delimiter also was not changing length for lower data rates.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 10 Baseline SFD SS…-S SFDPreamble For Coherent Rxr Data Slide #5 from 06/011r0

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 11 Length 8 SFD (1 st Sequence) SS…-S0 000 SFDPreamble For Coherent Rxr Data Slide #6 from 06/011r0

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 12 Length 8 SFD (2 nd Sequence) For Coherent Rxr SS…-S S SFDPreamble Data Slide #7 from 06/011r0

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 13 Francois also looked at some length 16 patterns. The length 16 patterns were only worth a 1 dB improvement over the length 8. In the end, he recommended using length 8. For the low data rate he recommended repeating an “8 pattern” 8 times for a total delimiter length of 64.

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 14 The CCA detection window has the same issues as the delimiter length. Yihong Qi and Francois are working this issue together. Yihong is finding trouble fitting the detection patterns into the data stream for the 100 Kbps data rate. How hard to we want to struggle to make the optional CCA work at the optional 100 Kbps?

doc.: IEEE a Submission March, 2006 Brethour, Time DomainSlide 15 Conclusions: There are still some things moving around as we look into the comments. These do not generally rise to the level of “big deal”. The editors have been getting good guidance and help 4 times each week: Thank you!