RE: stds-802-16-tg4: Strawman: comments
I definitively agree with "Co-habitation". It describes better the
issue.
Octavian
-----Original Message-----
From: Kostas, Demos [mailto:dkostas@adaptivebroadband.com]
Sent: Thursday, April 26, 2001 3:49 PM
To: Octavian Sarca; Stds-802-16-Tg4 (E-mail)
Subject: RE: stds-802-16-tg4: Strawman: comments
Octavian thanks for encouraging comments.
As to Section 7 title you propose
"I would prefer "Coexistence in the U-NII bands" but I would like to
hear
different opinions."
As the term Coexistence is already being used for the Licensed
environment,
using it for the UNII environment will likely lead to unnecessary
confusion.
At the last 802.16.2 meeting I brought a contribution calling for UNII
we
use the term "Co-habitation" instead of coexistence. What do you think?
Demos
Dr. Demosthenes J. Kostas
Director, Industry Standards
Adaptive Broadband Corporation
3314 Dartmouth Ave
Dallas, TX 75205 USA
tel: 214 520 8411
fax: 214 520 9802
-----Original Message-----
From: Octavian Sarca [mailto:osarca@redlinecommunications.com]
Sent: Thursday, April 26, 2001 12:23 PM
To: Stds-802-16-Tg4 (E-mail)
Subject: stds-802-16-tg4: Strawman: comments
Hi All,
I would like to encourage everybody to make comments on the
TG4 PHY Strawman. As a reminder, it is posted at:
http://www.redlinecommunications.com/802.16b.strawman.doc
We have to gather comments and update sections by April 30.
I will capture all comments. If changes are suggested and there is no
counter-response (i.e. nobody against) I suggest to implement these
changes.
Here are my own comments:
General
-------
There are couple of editing flows (fonts, sizes, etc.) which I will try
to fix ASAP. Please signal me what you find.
Sections 2 and 3
----------------
Section 2 uses FFT to define modes (e.g. 64-FFT) while section 3 uses
DFT. I would prefer FFT since it is the part of the OFDM slang and it is
also used in TG4 slang.
Section 4.2.2.3
---------------
This interleaving method may be interesting but I find its stochastic
trial-and-error approach very impractical. Do we have a bound on the
maximum number of times we have to iterate? This method does not seem
suitable for either HW or SW implementation. For 20MHz channels we may
expect rates higher than 72Mb/s after coding depending on the number of
carriers used. As I see it, the probability to (still) hit a number
grater than 48 is 95% after 1st iteration, 90% after 2 iterations, ...,
23% after 30 iterations. Do you think it is a good idea to clock the
interleaver at 5.7GHz? :-) I think we can "invent" a deterministic
method that provides same performance but requires one step per bit.
Section 4.2.1.2 and section 5.1
-------------------------------
There is a difference between constellations proposed by Yossi in
section 5.1 and those in 802.11a. This reduces the efficiency of the
interleaver in 4.2.1.2. If we all agree with Yossi's constellations I
will propose a quick fix for the interleaver that will restore its
performance without changing its complexity.
Section 5
---------
Regarding power busting or reduction in OFDMA. The introduction mentions
4dB, the table headings say 3dB while the table itself shows 6dB
factors. What is the real desired factor? I believe it is 3dB.
Section 6.4 table 13
--------------------
I think transmit power levels for shall be increased with 1 dB to match
the FCC limits or we should put a note explaining the 1 dB margin. I
would also suggest to add EIRP limits for clarity. The FCC specifies
that, for antenna gains higher than 6dB, the power shall be reduced by
the amount of antenna gain in excess of 6dB. This in fact gives the
following EIRP limits:
20MHz 10MHz 5MHz
U-NII middle 30dBm 27dBm 23dBm
U-NII upper 36dBm 33dBm 30dBm
Again the -1dB factor shall be applied to the above values.
Section 7
---------
I definitively agree with Demos suggestions there. We have to take care
of all interference cases. Note that we have two tiles for the section.
I would prefer "Coexistence in the U-NII bands" but I would like to hear
different opinions.
Section 8
---------
The title is again too long. In my opinion, I would like this section to
contain more techniques to improve performance in cellular and/or
sectorized environments. Therefore, I would like to change the title to
"Recommended practice for cellular and sectorized deployments
(optional)" and the current contents of the section to be embedded into
a subsection called "Base station synchronization and coordination".
Best Regards to everybody,
Octavian Sarca
Redline Communications Inc.
90 Tiverton Crt. #102
Markham, ON, L3R 9V2
E-mail: osarca@redlinecommunications.com