Re: [STDS-802-16] [PREAMBLE] Some kick-off discussion for Aug 10 CC
Jeff,
Great topic. To maintain the integrity of this email thread, I am copying the private email exchanges here
for general discussion. I will appreciate it if you could contribute to the answers.
Jason Hou
ZTE San Diego
(760) 419-2689
==========================
Yossi,
I guess you haven't answer my questions. Let me try to explain my questions some more.
1. In the current D5, IDcell is allowed to vary in PUSC (first zone). But to maintain
frequency orthogonality in overlaping sectors from adjacent cells (different segments),
IDcell needs to be the same in order to maintain same permutation to minimize
slot collisions. Therefore it can be deduced that it is necessary that in PUSC deployment
all cells have the same IDcell in the first zone. Effectively you have "common preambles"
already. It may necessarily preempt the current "structural preamble designs" that
call for a common preamble.
2. I understand your reasoning to identify 3-tier 6-sector 19 cells deployment concept
that wants to have 19x6=114 identidies. My question is, since frequency lock is already
required in the standard (2%), there is no need to create 114 sequences. You need only
32 sequences for individual IDcells. There is enough side info for you to perform
power-on frequency lock (e.g., decoding FCHs). Creating extra 19x3 sequency just for
power-on frequency lock is excessive and unnecessary. All segments belonging to the same
cell with the same IDcell can use the same preamble sequence (PUSC) without degrading
channel estimation performance.
Please note that answers to this question are vital to us to reach any harmonization.
It ultimately answers to the question whether existion D5 already spell out for a common preamble.
It also affects any preamble design contribution in deciding whether 114 sequences are needed.
Reducing the number of sequences is vital to allow for fast cell-searching, reducing
MSS computing power (therefore battery life), reducing false alarm rate, and a whole lot more.
You may contend that the above reasoning (same IDcell) jeopodizes HOs. I agree. It is
out of scope for sure. My preferred implementation will be that in PUSC permutation stays the
same for all and IDcell is encoded in FCH or other places (with HEC in FCH). We will have
to examine this more once we close the issue with preamble.
Your early reply is appreciated.
Jason Hou
ZTE San Diego
-----Original Message-----
From: Yossi Segal [mailto:yossis@runcom.co.il]
Sent: Sunday, August 08, 2004 12:34 AM
To: 'Jason Hou'; yoshenhou@yahoo.com; 'JY Chun'
Cc: 'Jeff Zhuang'; pyzhu@NORTELNETWORKS.COM
Subject: RE: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Hi Jason,
The different segments in the PUSC are not only for the frequency lock, but also to achieve
channel estimation. By using the same methodology in the preamble and the data regions of
the PUSC we guaranty that the same S/N will be maintained.
The number of preambles was designed to have a 6 sector deployment and not repeat any
preamble for the first ad second tier.
You can switch zones and change the IDCell with it by using the appropriate MAC message.
The structure was planned to have minimal searching mechanism to lock on (so you will have
easier time when you do handoff or some sort of reception between two bases).
Regards,
Yossi
-----Original Message-----
From: Jason Hou [mailto:jhou@ztesandiego.com]
Sent: Thursday, August 05, 2004 6:58 PM
To: yoshenhou@yahoo.com; yossis@runcom.co.il; JY Chun
Cc: Jeff Zhuang; pyzhu@NORTELNETWORKS.COM
Subject: RE: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Hi Yossi and JY,
So do I get it right? IDCell is 0 in PUSC deployment first zone and may change in FUSC deployment?
And Segment ID is redundant upon frequency lock? Does it lead to the conclusion that we can have
a common preamble in PUSC and 32 preambles in FUSC for 32IDcells? I know it is important in PUSC
deployment that subcarrier permutation needs to be done exactly the same so that overlapping sectors
(different segment) between two cells do not interfere. It can only lead to the conclusion that an
identical IDcell is used for all PUSC cells. In FUSC cells can used to randomize collisions in overlapping
What I have concluded so far and verified in simulation is that Segment ID is redundant and is used only
during powerup when frequency offset is not lock. But you can obtain segment ID by locating
FCH and use the 4 repetition coding to verify whether you get the right segment. FCH locations are
permutated and if Segment ID is incorrect, the detected FCH positions are incorrect, leading to non-correlated
FCH repetition symbols. Faster detection of erroneous FCH can be achieve if there is header-check sequence
in FCH (but there isn't).
Looking forward to your responses.
Jason Hou
ZTE San Diego
-----Original Message-----
From: JY Chun [mailto:jychun03@lge.com]
Sent: Wednesday, August 04, 2004 12:52 AM
To: yossis@runcom.co.il; yoshenhou@yahoo.com
Cc: pyzhu@NORTELNETWORKS.COM
Subject: Re: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Dear Yossi,
Thank you for your reply.
But I wonder usage of CellID not Segment ID. That's my original questions.
In Preamble Adhoc, it is defined Minimum information carried in preamble are Segment number and CellID.
But I still don't understand why information of IDCell need in the preamble.
I knew IDCell from the preamble is use on the first PUSC zone pilot modulation,
but I think overhead is large if it use for only that reason .
Are there other important reasons I miss ?
Please see it again.
Thanks,
Best Regards,
JY Chun
----- Original Message -----
From: Yossi Segal
To: jychun03@LGE.COM
Cc: pyzhu@NORTELNETWORKS.COM
Sent: Thursday, August 05, 2004 5:01 PM
Subject: FW: [STDS-802-16] [Preamble] Question about IDCell from the preamble
I got this email and I think you are the original mailer.
PUSC is intended for the reuse of 1/3 (although you may use it for a reuse of 1 also).
The segment identification was done, in order to allow the user to decode the segments FCH.
There are 3 possible locations for the FCH and it is tied to the segment.
Regards,
Yossi
-----Original Message-----
From: Jason Hou [mailto:yoshenhou@yahoo.com]
Sent: Thursday, August 05, 2004 1:35 AM
To: yossis@runcom.co.il
Subject: FW: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Incorrect address. Resend.
-----Original Message-----
From: Jason Hou [mailto:yoshenhou@yahoo.com]
Sent: Wednesday, August 04, 2004 2:21 PM
To: yossis@runcom.il; JY Chun [jychun03@LGE.COM]
Cc: Peiying Zhu [pyzhu@NORTELNETWORKS.COM]
Subject: RE: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Hi Yossi,
While we are on this topic, I'd like to ask few more questions.
1. In an ideal PUSC deployment (reuse 1), it is true that all cells use IDcell=0
in the first zone that include FCH and DL/UL map?
2. Since frequency locking is mandated, segment identification is implicit. Why
is there a need to create different preamble sequences for segment identification?
Permutation of subcarriers is based only on IDcell but not segment.
You reply is appreciated.
BTW, I did not send it to the reflector unless you feel it is necessary.
Jason Hou
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of JY Chun
Sent: Monday, August 02, 2004 7:34 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Hi, Sriram Mudulodu,
I'm sorry I don't understand your reply exactly.
What's mean 'interference averaging'?
I think you say IDcell from preamble is used for doing permutations based on IDcell for data, right?
IDcell used for pilot modulation and IDcell used permutations for data are different.
IDcell info from the preamble is used for pilot modulation and IDCell used permutations for data is default zero at first.
Below, there is Yigal's answer to my questions.
========================================================================================================
In REVd/D5,
p. 567 "In the first PUSC zone of the downlink (first downlink zone) the default used IDcell is 0."
p.526 "The downlink frame shall start in PUSC mode with IDcell = 0 and no transmit diversity."
1. What is the first PUSC zone? Does that include FCH, DL/UL-MAP?
>>> Yes, it includes FCH and DL-MAP
2. Why IDcell = 0 in the first PUSC zone?
>>> To facilitate operation with sector reuse <=1 by ensuring that PUSC zone are orthogonal
3. If answer of question 1 is "yes", where or when will IDcell from preamble be used?
>>> IDCell from the preamble is use on the first PUSC zone pilot modulation
====================================================================
Please see it,
Thanks,
Best Regards,
JY Chun
----- Original Message -----
From: Sriram Mudulodu
To: ???
Sent: Wednesday, August 04, 2004 10:37 AM
Subject: RE: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Hi Chun,
The suggested reason is for doing permutations based on IDcell for data is for better interference averaging.
They want to have this interference averaging effect for the DLMAP as well. So the only way is to
convey this info about IDcell in the preamble.
Yes, we agree the overhead on the receiver is high due to this.
Regards,
Sriram
--------------------------------------------------------------------------------
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of ???
Sent: Monday, August 02, 2004 6:29 PM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [Preamble] Question about IDCell from the preamble
Dear Yigal and all,
– In Preamble Adhoc, •it is defined Minimum information carried in preamble are Segment number, CellID.
But I still don't understand why information of IDCell need in the preamble.
I knew IDCell from the preamble is use on the first PUSC zone pilot modulation,
but I think overhead is large if it use for only that reason .
Are there other important reasons I miss ?
Best regurds,
JY Chun
° 。。 ☆ ˚ ★。 。。★ 。 ˚ ☆ 。 。 。 。 ˚ 。。 ☆ ˚ ★。
Jin-Young Chun
Research Engineer
Standardization & System Research Gr.
Mobile Communication Technology Research Lab.
Phone: +82-31-450-7903
Mobile: +82-10-2263-2797
E-mail: jychun03@lge.com
˚ 。。 ☆ ˚ ★。 。。★ 。
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Jeff Zhuang
Sent: Monday, August 09, 2004 4:02 PM
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