Re: [STDS-802-16] [PREAMBLE] Technical discussions of preamble sequence design.
Phil,
Thank you for your reply. Could you find where it is specified? If it's already specified, then
we can use it for simulations.
After receiving your email, I just tried to find some contributions on cell radius requirements.
Please comment on their relevancy.
In C802.16e-03/01 "Mobile system and proposal evaluation requirements",
the targeted cell radius is specified as 1~15 Km (is this document still effective or
has been superseded by another document?)
In C802.16e-04/235, "Operator service requirements", even though it doesn't specifically
make a requirement on cell radius, it does ask for 160 dB link budget, with propogation models
the cell radius can be derived accordingly.
Best regards,
--Weidong
-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Thursday, August 12, 2004 7:16 PM
To: STDS-802-16@listserv.ieee.org
Subject: 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.
>