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

stds-802-16-tg3: Re: Mode OFDMA2


Thank you for your constructive comments. We are in the process of writing
additional text (text/figures) to address items 1-3. Regarding item 4, we do
remember your contribution and presentation, and plan to run simulations so
we can provide some additional details on use of sub-channels for ranging
and random access. 

Phil Kelly
BeamReach Networks

On 3/17/02 4:50 PM, "Jerry Krinock" <>

> Dear BeamReach Friends,
> After reading your contribution C802.16a-02/40, I thought of four issues
> regarding mode OFDMA2.  The first three suggest additions to your proposed
> text for the standard; the last one questions the expected performance.
> Here they are:
> In IEEE P802.16a/D2-2002, for OFDM mode, we have two figures which show the
> framing in detail.  Figure 206 on pg 154 of shows the framing when using TDD
> and Figure 207 on pg 155 shows the framing when using FDD.  SC2 has two
> similar figures, which are Figures 177 and 178 in P802.16a/D2-2002.
> Presently, neither OFDMA nor OFDMA2 have such figures.  Even if just for
> editorial consistency, OFDMA and OFDMA2 should probably have such figures.
> This should also satisfy the people who requested better explanation of the
> framing.
> Please review the following process for Initial Ranging, and somewhere in
> your text, explain (a) exactly when in this process the BS gets the
> information it needs to form a receiving beam, and also (b) exactly when the
> beam is formed:
> Step 1:  The SS sends an Initial Ranging CDMA code on the ranging channel
> (note: Ranging Channel = two subchannels), for a duration of two OFDM
> symbols, at an arbitrary time.
> Step 2:  The BS sends a ranging response (RNG-RSP) MAC messge, giving the SS
> a time advance based on its observation of the Initial Ranging code, and
> also an allocation in which to send  a MAC header requesting network entry.
> Step 3:  The SS adjusts its time advance.
> Step 4:  The SS sends a MAC header requesting network entry.
> Ditto for Bandwidth Requesting.  Note that, in this case, the BS may already
> have the measurements "on file" to form a beam from this SS.  But I presume
> that, if this SS has become inactive, it will not be "listening" with this
> beam but will somehow reactivate this beam sometime.  When and how?  Here is
> the process:
> Step 1:  The SS sends a Bandwidth Requesting CDMA code on the ranging
> channel (note: Ranging Channel = two subchannels), for a duration of one
> OFDM symbol, with its proper time advance which it already knows.
> Step 2:  The BS sends a ranging response (RNG-RSP) MAC messge, giving the SS
> an allocation in which to send a normal MAC header with its payload.
> Step 3:  The SS sends a MAC header with its first payload.
> In IEEE P802.16a/D2-2002, pg. 182 line 25, we explain that "The MAC shall
> define a single ranging channel. This single ranging channel is composed of
> one or more subchannels."   Later, we say that the default number of
> subchannels allocated to the ranging channel is two.  If too many SS try to
> send ranging signals, the coding gain available with two subchannels, giving
> a code length of 2x53 = 106, may be insufficient, resulting in many missed
> detections and false alarms.  Under these conditions, BS MAC policies will
> presumably increase the ranging channel to include more subcchannels, say 3,
> 4 or 5, which will give longer code lengths of, say, 159, 212 or 265.
> You may recall that, last year, I and my colleagues submitted a contribution
> showing that, in OFDMA mode, it will be difficult for the BS to receive more
> than one ranging SS at a time under SUI-4 or worse channel conditions,
> because the channel will distort the codes.
> [You may also recall that Runcom disagrees with me on this.  We have their
> presentation, but are not satisfied; therefore this disagreement remains.]
> Anyhow, in the text you submitted on Thurssday, it says that the ranging
> channel allocation is fixed at two subchannels and therefore the code length
> is fixed at 106.  Thus, the BS is not able reduce congestion on the ranging
> channel by allocating more subchannels, as it is able to in OFDMA mode.
> However, I expect this allocation of additional channels to be even more
> necessary in OFDMA2 than in OFDMA for two reasons.
> FIrst, since it has higher capacity due to spatial multiplexing, there  will
> be more SS per BS, and hence more ranging signals.  This looks like a
> fundamental problem with OFDMA2.  Since beams cannot be formed until
> sometime during or after ranging, there is no way to spatially multiplex the
> ranging channel like the other subchannels.  The ranging channel does not
> get the gain in capacity.
> The second reason is AWGN.  It could be argued that AWGN will not be much of
> an issue in OFDMA ranging, because of the robustness of the BPSK signalling
> and because of the power concentration available when transmitting on only a
> few subchannels.  Therefore, to be easy, I did not add AWGN in the
> simluations I did last year which were included in our contribution
> 80216abc-01_24.  However, in OFDMA2, AWGN will probably be significant in
> ranging signals from outlying SS, further increasing the missed detections.
> To summarize, because of (1) the fixed allocation of two subchannels to
> ranging, (2) the higher number of SS and (3) the weaker signals due to
> extended cell radii, the CDMA ranging performance in OFDMA2 is going to be
> even more challenging than in OFDMA.
> I think that we need some simulations of the CDMA ranging (initial ranging
> and bandwidth requesting) in OFDMA2.