Re: [STDS-802-16] [PREAMBLE] Technical discussions of preamble sequence design.
I cannot remember where it says it, but somewhere it says the model cell
radius for 16e is something like 3km or 3.5km.
Thanks,
Phil
----- Original Message -----
From: "weidong yang" <weidong_yang@NAVINI.COM>
To: <STDS-802-16@listserv.ieee.org>
Sent: Thursday, August 12, 2004 7:04 PM
Subject: Re: [STDS-802-16] [PREAMBLE] Technical discussions of preamble
sequence design.
> Actually the preamble timing difference should be 16.7 us for the example
given
> in the previous email. In Wimax, people are talking about 50 Km coverage.
> What is the cell radius 16e OFDMA system should be designed for? Cell
radius and
> shadowing fading should be considered for preamble design.
>
>
>
> -----Original Message-----
> From: weidong yang
> Sent: Thursday, August 12, 2004 6:29 PM
> To: 'yigall@runcom.co.il'; STDS-802-16@listserv.ieee.org
> Subject: RE: [STDS-802-16] [PREAMBLE] Technical discussions of preamble
> sequence design.
>
>
> Dear all,
>
> Will it be beneficial to use some kind of propagation model help us
understand
> to what degree sychronized network can help a MSS locate the preambles for
> other BTSs once the MSS has found the preamble of one BTS?
> (for example, suppose that we have 2 BTSs (BTS A and BTS B) and one MSS.
The distance between
> the MSS and BTS A is 10 km, and the distance between the MSS and BTS B is
5 Km, and due to
> shadowing, the signals from BTS A and BTS B are of comparable strength at
the MSS, and the
> preamble timing difference is 5 Km/light speed= 50 us)
>
> Best regards,
>
> --Weidong Yang
>
>
> -----Original Message-----
> From: Yigal [mailto:yigall@runcom.co.il]
> Sent: Thursday, August 12, 2004 5:50 PM
> To: STDS-802-16@listserv.ieee.org
> Subject: 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.
>