Re: [STDS-802-16] [PREAMBLE] Some kick-off discussion for Aug 10 CC

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

-----Original Message-----
From: Peiying Zhu [mailto:pyzhu@nortelnetworks.com]
Sent: Wednesday, August 11, 2004 3:03 AM
To: 'yossis@RUNCOM.CO.IL'; STDS-802-16@listserv.ieee.org
Subject: RE: [STDS-802-16] [PREAMBLE] Some kick-off discussion for Aug 10 CC

Regarding frequency tracking using embedded pilots, are you referring the continuous pilots in FUSC mode? If so, there are no continuous pilots in PUSC or AMC, even for 128 FFT FUSC, what should we do in these cases?

-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Yossi Segal
Sent: Tuesday, August 10, 2004 4:23 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [PREAMBLE] Some kick-off discussion for Aug 10 CC

1) some approaches use the embedded pilots within the symbols to lock/track frequency.
2) My statement was: if you can track these fast changes then you probably do not need
    the midamble, I believe there are simulations from Nortel on the performance.
4) It is your decision on what to use, in any case you for these cases there will be a full collision
    on both pilots and data, but still the preamble could be tracked (this is an historical reason as the
    FUSC mode was once the first symbol and he has only 32 permutations).

-----Original Message-----
From: Jeff Zhuang [mailto:zhuang@labs.mot.com]
Sent: Tuesday, August 10, 2004 8:42 PM
To: yossis@runcom.co.il
Cc: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [PREAMBLE] Some kick-off discussion for Aug 10 CC

Thanks for the message. I have further questions that need your help (please see inline).

>Dear Jeff and preamble ad-hoc participants,
>
>I would like to state my opinion on the good points you have raised:
>
>1) If you assume that the Preamble is there just to give you the frame
>timing for the initial synchronization, then all other tracking can be
>done in the frequency domain (using methods in the literature). No
>additional overhead is needed - or at least not in the rate you have
>mentioned, a very low
rate
>signal could be transmitted if all people insist on that.
>
>
How initial frequency offset is acquired, while the timing offset can at least be acquired with a brute force method? And how the frequency tracking is done in the literature? Can the structure be of any help?

>2) Channel Estimation using a preamble in mobile channel is only good
>for 1 or 2 symbols, therefore channel estimation should be done not
>relying on a MIMO preamble anyway.
>
>
The channel can change that fast under high Doppler. But for static channel, do you think the current embedded pilot design is adequate enough to give good channel estimates? (On average, we have one pilot for about 16 subcarriers and there may not uniformly spaced). I was thinking of a mid-amble that can serve as a good start and let the embedded pilot to track the variation later.

>3) I have stated my opinion on that several times, including the fact
>that it is out of scope.
>
>4) The CellId is being used for modulating the pilots in the first PUSC
>zone, segment is just used to locate the FCH location. Both of them are
>available in the Preamble.
>
On these aspect, you know better than probably any body else. So for the first PUSC zone, cellID is set to zero to ensure non-overlapping subcarrier allocation to three segments, right? The cellID information conveyed from the preamble search is used to determine permutation for other PUSC zone then?? We have two preambles defined by the same cellID and segment (e.g., cellID=0 and segment=0, preamble index 0 and 96), which one do we use?

>
>Regards,
>Yossi
>
>
>-----Original Message-----
>From: owner-stds-802-16@listserv.ieee.org
>[mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Jeff Zhuang
>Sent: Tuesday, August 10, 2004 1:02 AM
>To: STDS-802-16@listserv.ieee.org
>Subject: [STDS-802-16] [PREAMBLE] Some kick-off discussion for Aug 10
>CC
>
>
>Dear preamble ad-hoc participants,
>
>I would like to initiate some technical discussion to prepare for
>tomorrow's conference call. I am supposed to provide comparison
>results on different sequences, but I find it is difficult to do so and
>perhaps not that meaningful at this stage if we still cannot agree on
>the functions we want to achieve. So, the functional requirements are
>still the focus here.
>
>The purpose of the discussion is to help (me at least) to better
>understand where the issues are, whether the existing preamble is
>adequate, and whether the proposed modification is worthwhile. I hope
>people can fill in with what I do not know and what I stated
>incorrectly, and thus drive the same goal together, which is to make
>the system better.
>
>1) Synchronization (Timing and Frequency)
>Let's first look at how synchronization is done in an isolated cell
>environment first and then examine the issues under mobile/multi-cell
>environments. Also, let's look at both the existing preamble design
>and the alternative designs that we are aware of to the best of our
>knowledge.
>
>In an isolated cell, it is well-known from literature how initial
>coarse OFDM symbol timing and frequency offset can be estimated with
>the assist of a repetition structure. Fine timing, such as through
>exploiting the actual sequence rather than only the structure, can then
>kick in to track the variations. Similarly, automatic frequency
>control (AFC) PLL will then kick in for fine frequency tracking. A
>much less reliable approach that I knew is to exploit the cyclic prefix
>to do coarse timing and frequency offset estimation, but the method
>breaks down when the channel is long (up to CP length for example) and
>it can only give symbol timing info at its best, rather than frame
>synchronization that can be achieved if the sync preamble structure is
>unique in a frame (facilitate cell search).
>
>I am not so clear on how initial timing and frequency synchronization
>is done with the current preamble (100-500ms as stated by Yossi and
>Zion's contribution for Runcom). The repetition structure of using
>every third subcarrier does not hold if the FFT size is not a multiple
>of three. Even say if we may compensate for it in the time domain
>samples so that a repetition will appear, the structure is still lost
>when signals from two segments are superposed. I guess timing
>synchronization is always possible with a brute force sliding-window
>correlator (correlate with all sequence candidates) over a frame duration if we can afford the
>waiting time. But I am still fuzzy about frequency sync (pilot-based?
>CP-based?) and whether we perform frequency sync before/after timing,
>or simultaneously.
>
>In a mobile/multi-cell environment, we are receiving from multiple
>bases. The structure of the received signal is the same if all the
>bases use the same structure (not necessarily the same sequence
>though). The result is that the mobile will get synchronized with the
>strongest base, which is fine during the first-time power-up. But the
>timing should track the designated base, not always the strongest base,
>so timing tracking should not rely on the structure (should utilize the
>cell-specific sequences instead). Frequency tracking can use the
>structure as well, but as said previously, it can lock to the strongest
>base during handover, which can be a problem. In (quasi-)synchoronized
>deployment, bases are locked to GPS clock in both time and frequency,
>so locking to the strongest base in frequency may not be a big concern
>(timing from bases can still be different because of propagation delay,
>so lock to a weaker base can still be wanted). In the probably rare
>case of driving directly away from one base and towards another, the
>AFC can confuse Doppler with frequency offset, which may initiate
>frequency re-acquisition. With the current preamble design, it may
>possible to perform timing tracking in a similar fashion (i.e., using
>coherent tracking schemes). I am not so clear on how frequency tracking
>can be done.
>
>In summary, some kind of structure to facilitate initial coarse timing
>and frequency synchronization is helpful. If the structure is only
>helpful for limited scenarios with infrequent occurrence, the overhead
>is something we have to consider. Maybe we should look for ways to
>reduce the overhead. The simplest example is to reduce it to half a
>symbol on average if we transmit such a signal every other frame. The
>structured signal occupies the same subcarriers for all segments, so it
>can be added in front of a preamble that uses orthogonal subcarriers
>for three segments if PUSC is used in FCH and MAP transmission (but if
>FUSC is used, we want interfering preambles between segments). The
>timing tracking to one or more bases is better done through coherent
>schemes. In order to estimate the channel characteristics to cells that
>occupy the same set of subcarriers even though they can be one tier
>apart (for soft handover or advanced interference suppression
>receiving), a low correlation between preambles are desirable provided
>that we have enough CP protection (micro-cell can be a good example
>for that
capability).
>
>2) MIMO channel estimation
>If the default transmission for FCH and MAP is single-antenna
>transmission, any preamble design with multi-antenna transmission will
>degrade the estimation performance of the channel associated with that
>default antenna. From this aspect, I think single antenna transmission
>is fine. On the other hand, I do not think the current scattered
>pilots are enough for MIMO channel estimation . So, it makes sense to
>me to propose a MIMO-zone related single mid-amble symbol to obtain
>good MIMO channel estimation. I am not sure if a mid-amble discussion
>is out of the scope of this ad hoc group.
>
>3) Operation mode identification
>It makes sense to me if we tie a mode (PUSC, etc) with each FFT size,
>which simplifies the "adaptive" mode identification problem. Could any
>one help me to guess the default mode for 128-point FFT when we have
>fewer subcarriers in one symbol than what a FCH needs? Maybe using more
>than two symbols for FCH and MAP? If FUSC, the preamble should be sent
>with a FUSC fashion.
>
>4) Cell ID identification
>As the email exchange between Jason, JY, and Yossi has indicated, the
>questions of how much cell ID information we need to extract from the
>preamble and how many cell ID we need to search may still need to be
>clarified. I benefited from the discussion. I have an additional
>question that is when sometimes we have two preambles defined by the
>same cellID and segment (e.g., 0 and 0), which one do we use?
>
>Best Regards,
>
>- Jeff Zhuang
>Motorola
>
>