Re: [STDS-802-16] [PREAMBLE] Technical discussions of preamble sequence design.
Dear Jason,
I did not understand why you claim that the CAZAC design outperforms the
current design (or any other design for that matter), and I don't think we
currently have a problem of battery drain because in any operating mode of
the system, including sleep and idle you should not have a problem with
scanning for neighbors preambles. This is due to several reasons
1. The network is supposed to be synchronized, so once you are initially
locked on one preamble, you know quite a few things on neighbor preambles,
which make scanning easier
2. The preamble space is divided into 3 distinct groups, so search overhead
is just 1/3 from what it seems
3. Most of the users, most of the time are not that mobile, and your
neighbors change slowly enough so that even with a big sleep window (~1 sec)
you can easily cover all the preamble space
4. Before a MSS goes to sleep, it is awake, and when awake it receives
information about neighbor preambles, so it does not really have to scan
everything. When handing over the MSS again receives information about
neighbor preambles, and again scanning can be avoided.
The above being said, I think that if you want me (or anybody else
interested in this discussion) to seriously consider your proposal, you must
make it fit to the system design, which is OFDMA. Yes, it is scalable, but
it still supports PUSC, FUSC, reuse 1/3, 1/2 or 1/1, specific FEC engines,
and many other things. All these do things do not change when we change FFT
size, and we don't want them to change, because this will make implementing
scalable OFDMA an impossible nightmare.
I do not have anything against CAZAC sequences, but as I said in my previous
email, a preamble that fits with the rest of the system must be 1/3
populated, and should have low PAPR. If you can meet these requirements with
CAZAC sequences, I will be happy to support your proposal.
BR,
Yigal
-----Original Message-----
From: Jason Hou [mailto:yoshenhou@yahoo.com]
Sent: Thursday, August 12, 2004 6:48 PM
To: yigall@runcom.co.il; STDS-802-16@LISTSERV.IEEE.ORG
Subject: RE: [STDS-802-16] [PREAMBLE] Technical discussions of preamble
sequence design.
Yigal,
I guess you want to use the same reasoning to reject all other preamble
contributions.
With due respect, your preamble design may result in battery drain during
sleep mode because
of the need to spend large computing power to search for preambles, timing,
etc.
The trick to increase standby time in a mobile device is to minize
computations in any way possible.
Being able to perform fast cell search not only facilitates HO but most
importantly, save battery power.
IEEE802.16e needs to outperform other cellular standards to be competitive
in the mobile marketplace.
Can you address how your preamble is able to achieve the goals that I set
out to achieve in my design?
As for PAR, we have been very careful not to address 2048-FFT. My CAZAC
design addresses the needs
for mobility and for 1024-FFTs and down. I welcome your opinions on how
your preamble design
resolves mobility requirements in power-saving, timing tracking, computation
reduction, etc.
Jason Hou
ZTE San Diego
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of Yigal
Sent: Wednesday, August 11, 2004 7:02 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [PREAMBLE] Technical discussions of preamble
sequence design.
Dear Jason Hou,
Your proposal is lacking one major feature, which is compliance to the PAR.
Any sequence we choose must fit the general design, which means it must be
1/3 populated, and must support PUSC/FUSC/O-FUSC/O-PUSC operation. Even if
you propose the greatest sequence in the universe, I don't think we should
modify the entire system design to revolve around it.
The mandate of this ad-hoc group is to come up with a preamble that fits in
with the current system design, and not to re-write the entire standard.
BR,
Yigal
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Jason Hou
Sent: Wednesday, August 11, 2004 6:40 PM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [PREAMBLE] Technical discussions of preamble sequence
design.
Hi all,
I'd like to start a technical debate of preamble sequence designs since we
don't have one yet.
Let me start with defending my CAZAC preamble design.
First of all, I'd like to point out advantages of the proposal. For
technical details please refer
to the contribution document.
1. Adopt a single sequence (CAZAC) allowing a mechanizm for fast cell
searching.
2. Fully explore the frequency-time duality of CAZAC sequences (Chu,
Frank-Zadoff).
a. Sequence matched filtering can be done solely in frequency domain.
It yields comparable results in time domain.
b. Inherit timing and frequency offset ambiguity, CAZAC sequence
detection is not impaired
by unknown symbol timing offset and frequency offset. In other
words, detection of
CAZAC sequence is not affected by non-ideal capturing of time
waveform for FFT and unknown frequency offset.
Timing offset in time domain is translated into CAZAC cylic shift
in frequency domain. Detection
of CAZAC is not impaired.
c. Matched filtering (in frequency domain) of CAZAC sequence yields
accurate CIR (channel impulse response).
It produces channel quality info, time of arrival (for MSS
precision adjustment of timing in UL and during HO),
Precision windowing of FFT waveform capturing to minimze OFDM ISI,
etc.
d. WIth proper cell planning that neighering BSs maintian large CAZAC
code-phase spacing (so that multi-path responses
do not overlap), a single scan of the preamble symbol yields CIRs
(channel quality too) and timing (arrival time) of all cells
and segments (sectors). It provides a mechanizm to allow for fast
HO and fast wake-up during sleep (critical to reduce
MSS standby time).
3. Inherit CAZAC characteristics that PAPR is very low ( worst-case 2..6dB
in 1024-FFT, 2.7dB in 512-FFT, and 4dB in 128-FFT).
This is critical to achieve coherence detection where preamble can be
power-boosted.
Questions that may be raised.
1. How frequency offset can be corrected at powerup?
Answers:
a. Frequency offset greater than four carrier subspacings can be
detected/corrected by energy detection of guard band detections
and missing edge subcarriers (critical for MSS to relax the spec
high-precision TCXO).
b. Finer coarse frequency offset to be better than +-0.5 subcarrier in
PUSC can be achieved interpolating CIR results
(from CAZAC matched filtering in frequency domain) of adjacent
frequency segments.
c. +-4 carrier subspacings frequency correction can be done by
hypothesis testings of detected FCH symbols (similarity tests
of the four repetition codes). This is probably the only test
capable of determing false alarms in all preamble sequences.
d. Fine frequency and phase cancellation can only be done via pilot
channel tracking.
2. Since Chu and Frank-Zadoff sequence has time-frequency offset ambiguity,
how to tell them apart?
Answers:
Since initial frequency offset can be cancelled in (1), timing offset
can be immediately identified. Once MSS is in tracking mode,
frequency offset uncertainly is ruled out and timing offset is uniquely
determined.
3. Is there a lack of large code-phase spacing in PUSC deployment (Jeff
from Moto raised it).
Answers:
As soon as we establish that IDcell need not be tied to preamble
sequence, optimal cell planning to maximize CAZAC code-phase
spacing of neighering BS can resolve the concern over overlapping
multi-path responses. Coarse symbol timing of preamble
symbol can be done via CP and power-burst energy detection. CAZAC
code-phase identification is done using the quantization
effect of CAZAC code-phases.
I maintain that there is no need to create preamble sequences for different
segments. Also IDcell needs to be redefined and that
PUSC permutation should stay the same for all cells and zones.
I welcome all comments. Thanks in advance.
Jason Hou
ZTE San Diego,
(760) 419-2689.