Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

stds-802-16-tg3: OFDMA Ranging

[This is a continuation of the "Re: How Are You" thread which has been going
on privately.]


You emailed something a few days ago which got my attention:
Itzik Kitroser wrote:

> Some of the sub-channels can be used for Ranging sub-channels, in this case,
> each Ranging sub-channels is build out of two ≥regular≤ sub-channels and
> will contain 106 carriers. The MAC messages that contain reference to
> Ranging sub-channels.

This is not my impression and not what it says in the current draft IEEE
P802.16a/D3-2002.  On pg. 209 line 53 it says (in text which I wrote!):

> The MAC shall define a single ranging channel. This single ranging channel
> is composed of one or more subchannels.

and on page 211, line 19:

> The length of each ranging code is a multiple of 53 bits. The default
> is two subchannels allocated as the ranging channel; in this case the ranging
> code length is 106.

I hope you see the difference between your remarks and the text in the
current draft.  Your remarks say that there may be MORE THAN ONE "ranging
channel", and that each ranging channel is comprised of two subcarriers;
thus the ranging code length is always 2x53=106.  In the current draft, it
says that there is ALWAYS ONE ranging channel, and that the code length
varies with the number of subchannels allocated to ranging.  If two
subchannels are allocated to ranging, then the code length is 106 bits.  If
four subchannels are allocated to ranging, then it is 212 bits.  However,
the BS may also allocate one, three, five, six, etc. subchannels which would
result in code lengths of 53, 159, 265, 318, etc. respectively.

When I ran my simulations of the ranging process last year, I simulated it
both ways:  with multiple ranging channels as you described, and with a
single ranging channel as in the current draft.  I found that, for a given
ranging subchannel allocation (of, say, 4 subchannels), performance was
slightly better using the single ranging channel as in the current draft
(say, a single ranging channel of code length 212) rather than as you
described (say, two ranging channels of 106 bits each).  It seemed that the
increased coding gain was slightly more beneficial than the decreased
collisions in the frequency domain, which you get from having two channels

In KiHo's contribution IEEE C802.16a-02/33r1, he describes selection of a
"Ranging Subchannel Index". According to the current draft, since there is
only a single ranging channel and therefore no need to index one channel.
Thus, it appears that KiHo he believes the same as you.

The way I wrote the current draft is the way I thought it was intended by
Runcom's original contributions.  If you want it changed to the way you
understand, you must submit a comment someday to change it.  Although my
simulations show slightly better performance using the method in the current
draft, I personally do not care that much which way we do it, because in my
opinion the CDMA scheme performs poorly in either case.  (But that is
another discussion!)

Regarding the current discussion by Changhoi, I have re-read the
contributions from Samsung and agree with Itzik that inter-cell interference
is sufficiently randomized by the our use of different subchannel
permutations in adjacent cells, assuming adjacent cells have different
values of the parameter ID_cell.  I do not believe that the proposed
quasi-random selection will have any advantage.

Changhoi, thank you very much for restarting this discussion which brought
this misunderstanding to light.  I hope you can contribute some simulations,
and prove us wrong if you may.  May I suggest you please post a top-level
description or block diagram of your algorithms before you code the routines
in detail, so that others can review the basic assumptions.  Otherwise,
we'll just have another set of simulation results that no one understands
and no one agrees with.

One final note: I have copied this message to the TGa email reflector.  I
believe that this email reflector is underutilized, and I discourage the use
of private email lists for technical discussions.  There may be new members
of the working group who can contribute, or at least need to begin
understanding the issues!

Jerry Krinock <>
Radia Communications
275 N. Mathilda Suite A
Sunnyvale, CA   94086
phone/voicemail:  408-830-9726 ext 239