Re: [STDS-802-16] [PREAMBLE] Aug 23 Preamble Ad-Hoc group CC sum mary
Jeff,
Thanks for your detailed email.
I guess your concern is with situations when there are two SUI-5 (max 10uS)
interference
paths in the same segment without HOs. That must be a horrible cell
planning. Anyhow,
you can still use "common segment signaling" set to locate the symbol
boundary properly.
If one path is stronger than the other, the cross-correlation will pinpoint
the IDcell
right away. If the two paths are equal in strength, then the method may
fail. BUT,
are you expecting me to demodulate both SUI-5s jointly without errors????
If you can
then I will withdraw my contribution and you can deploy 3-sector
FUSCs/OFUSCs as PUSCs
everywhere with severe coverage overlaps and not hurting data rates.
You did your math correctly. Overlapping of multipath responses happens
when the max is
over 5.6 us. From the "common segment signaling" you can see that. BUT,
overlapping
has no performance degradation when they are in two segments.
Cross-correlations between
segments and the "common segment signaling" can pinpoint the two IDcells
exactly right away.
Seperation of only 4 shifts between adjacent IDcells is not a problem at
all. You can consult
with CDMA IS95 and 2000 to see how BS PN offsets are assigned. It is proper
cell planning
that matters that maximizes code phases between adjacent and interfering
BSs.
As to 128-mode, yes there are only 16 element. But if you FFT the 16-elemnt
then you can
another CAZAC. The crosscorrelation between the two 16-element is a sine
function.
And yes, the processing gain is not much, only 10log16. So again, are you
saying GCL or PN
can perform better?
NOW!!!
Here is the question for you. In order for GCL and PN to get CIR so as to
know multpath profile,
there are only two methods. With time domain method you have to IFFT your
GCL/PN to time
domain use the coefficient as taps (with 1024FFT you have 1024 taps).
Truncating taps will
hurt performance so i will not elaborate on that. Be fair you have to do at
least 32 tap delay filters,
full-multiplier operations, in order to get proper CIRs (assuming zero
autocorrelaton).
The amount of processing is mind-boggling!!!! And don't tell me neighbor
list helps you much.
In sleep mode scanning when you need to save power the most, you still have
to go through all
sequences. You will be lucky if your battery can stay up more than a day.
With frequency domain method, you will have to phase-rotate GCL/PN sequence
(with CORDIC?)
and inner-product with your FFT results. For 1024-FFT and SUI-5, you will
have to do at least
100 times per sequence. On top of that with unknown timing uncertainly you
will have to add
another 40. Are you expecting the hardware complexity is low???
To add matters worst, sensible implementation of GCL requires MSS to store
coefficient in memory.
You need at least 16x amount of storage when compared to PN.
Every design has tradeoffs. I am not saying CAZAC preamble is perfect. But
you should know whether
your design can outperform CAZAC. So far I cannot see performance
advantages of GCL/PN over
CAZAC. So if I want to make 16e genetically sound, I will choose CAZAC over
GCL/PN, if you
still want 16e to be a mobile standard.
Thanks,
Jason Hou
-----Original Message-----
From: Jeff Zhuang [mailto:zhuang@labs.mot.com]
Sent: Friday, August 27, 2004 4:37 AM
To: Jason Hou
Cc: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [PREAMBLE] Aug 23 Preamble Ad-Hoc group CC
sum mary
Jason,
Thanks for running the simulations.
If you change the SUI-3 (three-tap, maximum delay @1 us) to SUI-5
(three-tap, maximum delay @ 10us), you may be able to see already that
the "channel overlapping" problem is immanent in both scenario 1 and 2
(slide 11 and 12 of your latest file s80216e-04_265r11.pdf)
</cgi-script/CSUpload//upload/temp%252edb/s80216e%2d04_265r11.pdf>. For
an symbol period of 100us, a CP length of 1/8 Nfft means that it can
accommodate up to 12.5us delay. We should prepare for this long channel
then.
Here are some more math. Your 1024 design is based on a single
length-128 CAZAC sequence, you assign a "code phase" (i.e., cyclic shift
of the frequency domain length 128-sequence) of "4*IDcell" to each of
the 32 cells. Since you use every fourth subcarrier, the length-1024
time domain waveform is essentially a repetition of four blocks
(assuming you use set #0). I verified with simulation that a code phase
of "k" means that the block unit is shifted by 2k samples (cyclic shift
actually, then the block are repeated four times before adding a CP). In
the result you shown using IDcell 7 and 14, which gives a relative code
phase of 4*(14-7)=28, the preamble waveform from the two cells are 56
samples apart. For a 10MHz sampling rate system (close to the sampling
rate for 1024 FFT with 10MHz BW), 56 samples means a separation of
5.6us, well short of the 12.5us we should be ready for. That means the
interfering channel will show up from 5.6us, undistorted. Of course, you
cannot differentiate those taps from those desired taps that are 5.6us
out from the first tap.
If you have an unoptimized cell planning, you can assign consecutive
IDcells as neighbors, then you really have a code phase difference of
only 4 (or just 0.8us separation). That is why I was saying it is a
"risky" design. You may get away with cell ID detection with the help of
your "common segment signaling", but the "channel overlapping" problem
is there to significantly impact your channel estimation.
It becomes even more of a problem in 128 mode, where your design tries
to define 32 code phases with a length-16 sequence. If I think one
sequence is sufficient, I will be doing that. And that applies to any
single sequence (PN or GCL) design where different cell just use a
differently cyclic shifted waveform. The shift is in time domain, which
is equivalent to applying a phase ramp in frequency domain. Since CAZAC
itself is a phase ramp, applying a phase ramp is equivalent to
cyclically shifting the sequence.
Now you posted the question of how multi-sequence (GCL and PN) design
can do better in this situation. The answer is yes if the waveforms have
good cross correlation. Imagine a time domain correlator that correlates
the received signal with the desired sequence (of course, the sliding
correlator is implemented with a single FFT/IFFT pair). After
correlation, each multipath of the interfering channel will be spread
over the correlation interval (a OFDM symbol time) according to the
cross correlation property at each relative shift. Hopefully, the
interference energy will be spread evenly over a large interval, so that
the distortion to the desired taps (at least to the significant ones)
can be minimized. Both PN and GCL has this effect, except that the GCL
will spread more evenly. You can verify easily in a simulation to see
how the interfering channel gets "whitened", you can do that in time
domain or in frequency domain (divide by the pilot sequence and IFFT
back to the time domain).
Regards,
Jeff
Jason Hou wrote:
> Jeff and all,
> I am asking a fellow coworker to help me upload a revised slide
> s80216e-04_265r1.pdf within
> the hour into the temp directory. It includes few simulation runs
> answering to Jeff's
> concern of lack of code phase when using CAZACs. You can find in those
> simulations that
> lack of code phase has not been a problem at all even in large delay
> spread environment.
> So it is only fair to ask, how do GCL and PN sequence score in those
> situations? Can you
> maintain the same hardware complexity while providing adequate
> performance? Can you do
> better when compared to CAZAC preamble?
> Thanks,
> Jason Hou
>
> -----Original Message-----
> From: owner-stds-802-16@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of Peiying Zhu
> Sent: Thursday, August 26, 2004 3:18 AM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16] [PREAMBLE] Aug 23 Preamble Ad-Hoc group
> CC sum mary
>
> Proposed agenda for tonight's CC:
> 1. Sequence poll results
> 2. Update of sequence harmonization
> Please review new contributions on http://temp.wirelessman.org/
> Comments on the GCL series.doc
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/Comme
nts%20on%20the%20GCL%20series.doc>
> S80216e-04_265.pdf
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/S8021
6e%2d04_265.pdf>
> C80216e-04_265r1.pdf
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/C8021
6e%2d04_265r1.pdf>
> Motorola_GCL_fast cell_search.pdf
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/Motor
ola_GCL_fast%20cell_search.pdf>
> 3. Discuss conclusions of the preamble ad-hoc
>
> The conference bridge is:
>
> 1+(613)7650160
>
> Pass code: 3958089#
>
> Regards,
>
> Peiying
>
> -----Original Message-----
> From: Zhu, Peiying [CAR:DP13:EXCH]
> Sent: Wednesday, August 25, 2004 12:58 PM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16] [PREAMBLE] Aug 23 Preamble Ad-Hoc group
> CC sum mary
>
> Hit the send button too fast. Due to this clarification, I
> will extend the dead line to Aug. 25 3pm US pacific time,
> which gives me few hours to count the votes before tonight CC.
> This is also a reminder that we have a CC tonight
> Aug. 25, Wednesday --20:00-22:00 USA pacific time, 12:00 for
> Seoul, 6:00 for TelAviv, 23:00 for Ottawa
> Regards,
> Peiying
> -----Original Message-----
> From: Zhu, Peiying [CAR:DP13:EXCH]
> Sent: Wednesday, August 25, 2004 12:51 PM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: RE: [STDS-802-16] [PREAMBLE] Aug 23 Preamble Ad-Hoc
> group CC sum mary
>
> Hi, All:
> Just to clarify the straw poll procedure since I got some
> questions:
> 1. Poll is open to everyone.
> 2. Vote is counted on individual base according to IEEE rule.
> The results will be also reported to the Chair
> (Brian)/.16e community if we do not reached any consensus
> in ad-hoc.
> Regards,
> Peiying
> -----Original Message-----
> From: Zhu, Peiying [CAR:DP13:EXCH]
> Sent: Tuesday, August 24, 2004 4:17 PM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16] [PREAMBLE] Aug 23 Preamble
> Ad-Hoc group CC sum mary
>
> Hi, All:
> This is a reminder that please voice your opinions by
> casting votes to the straw polls on sequence design,
> the deadline is Aug. 25 (tomorrow) noon US pacific time.
> Please note that there are two uploaded contributions
> related to CAZAC sequences from Jason.
>
http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/S80216
e%2d04_265.pdf
>
http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/C80216
e%2d04_265r1.pdf
> Regards,
> Peiying
>
> -----Original Message-----
> From: Zhu, Peiying [CAR:DP13:EXCH]
> Sent: Monday, August 23, 2004 10:08 PM
> To: Zhu, Peiying [CAR:DP13:EXCH];
> STDS-802-16@listserv.ieee.org
> Subject: RE: [STDS-802-16] [PREAMBLE] Aug 23
> Preamble Ad-Hoc group CC sum mary
>
> Dear preamblers:
>
> Here is a summary of the today's CC.
>
> Attendees: Due to a larger number of participants,
> I only captured the company names here.
>
> Adavcom, Alvarion; Beceem; Broadband Mobile
> Technologies; ETRI; Hanaro Telecom; Hexagon;
> Intel; KT; LGE; Motorola; Nortel; Qualcomm;
> Runcom; SOLiD Technologies; Samsung; Sprint; ZTE
>
> I may miss few people, some joined after the
> meeting started, I did not checked the name.
> Please let me know if I missed you.
>
> We discussed the following items:
>
> 1. Yossi's contribution on simulation results:
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/Pream
ble_FrameDetection_1.doc>
>
> Yossi presented some simulation results based on
> the current preamble design. Several people asked
> questions for clarifications in term of simulation
> condition etc.. Jiho indicated that he tried the
> same simulation as Yossi, however, he could not
> reproduce the same results for 2dB shadowing case,
> please see Jiho's Email. There might be some
> inconsistence between simulation assumptions. Jiho
> suggested to have more time to verify the
> simulation results.
>
> 2. Status updated of common sync symbol
>
> There are few contributions uploaded and comments
> in the database. Please see the document for
> preamble and midamble related contributions.
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/Sessi
on33%20contributions%20organization%20and%20overview%20document%20Rev.4.xls>
.
> Please note that Contribution 241 from Motorola
> can be found in
>
<http://www.ieee802.org/16/tge/contrib/C80216e-04_241.pdf>.
> The rest of the contributions can be found in
> <http://tge.wirelessman.org/>.
>
> I submitted a comment (# 1007) for the eventual
> ad-hoc harmonized proposal.
>
> There are basically two joint contributions
> related to common sync symbol: contribution number
> 261 and 327. Seung Joo gave a short update on the
> contribution 327. Wen gave an update on the
> contribution 261. The basic concept of both
> contributions is the same, however, the actual
> location, the interval of the common sync symbols
> and mandatory vs. optional are different. Members
> involved in both contributions are requested to
> continue the harmonization efforts.
>
> Chair asked for a straw poll on both proposals to
> give indications of member's preference, also in
> the event that no unanimous agreement can be
> reached, Chair will present the results of straw
> poll in the cover page. Here is the result.
>
> Members who are against the contribution 261:
>
> Jiho from Samsung
>
> Members who are against the contribution 327:
>
> Yossi from Samsung
>
> Sirram from Beceem (concern on overhead)
>
> Izhar from Adavcom
>
> Avi from Hexagon
>
> Mark from Motorola (reservation on overhead)
>
> Joss from Intel
>
> Masoud from Nextel asked to give him some time to
> read the contributions before he gave the answer.
> For 261, he is ok if it is post amble.
>
> 2. Status update on sequence harmonization
>
> Jeff provided an update on his complexity
> comparison results. He prepared a contribution,
> and did not have enough time to upload before the
> meeting. It is now on the server:
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/Motor
ola_GCL_fast%20cell_search.pdf>.
> Please take a look. Jeff thinks that ZTE's
> sequence design has a similar complexity as GCL
> sequence, Jason disagreed. He said that he will
> also upload a document on his finding.
>
> Yossi, Tal, Jason and Seung Joo each gave an
> update on their thinking of sequence
> harmonization. Basically, there are two types of
> sequence design proposed: PN type, similar to the
> existing sequence, polyphase type, such as (CGL
> and CAZAC) Seung Joo think that there might be
> some potential of harmonization with Tal. All the
> other members think that it is difficult to
> harmonize, basically we need to select one
> sequence design.
>
> Jose asked for a clarification on whether sequence
> designs are for the legacy preamble or Common
> Sync. The answer is for both. It is preferred to
> use the same kind of sequence if there is no
> specific technical reason. In case that no
> consensus can be made regarding the sequence, then
> common sync symbol will use the current PN type of
> sequence.
>
> We had a discussion on what kind of conclusion we
> want to give as ad-hoc group. Several options were
> proposed: 1) no consensus 2) no change, i.e., use
> truncated 2k sequence 3) minimum change, with some
> improvement of 2k truncation, i.e., runcom's new
> hand crafted sequences 3) straw poll for each
> contributions. People agreed to do a straw poll so
> we get some indication on people's preference.
> Mark asked to delay the straw poll in order to
> give people some time to read new contribution on
> the evaluation of sequences. We agreed to do a
> straw poll through Email. Please read the document
> from Jeff and all the other sequence related
> contributions before you reply the poll. The poll
> deadline will be Aug. 25 noon US pacific time. To
> avoid flooding the reflector, please send Email to
> me, I will do a count and report the results.
>
> Poll 1: Do you support PN type sequence? (yes or
> no or abstain)
>
> Poll 2: Do you support Poly phase type sequence?
> (yes or no or abstain)
>
> Poll 3: Which sequence design do you support?
> (Chose 1-5 or abstain)
>
> 1) Contribution from Tal (Alvarion):
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/Pream
ble_Adhoc_Alvarion_PRBS%20based_preamble_design_r1.pdf>
>
> 2) Contribution 241 from Jeff et al.(Motorola):
>
<http://www.ieee802.org/16/tge/contrib/C80216e-04_241.pdf>
>
> 3) Contribution from Yossi et al.(Runcom):
>
<http://www.ieee802.org/16/tge/contrib/C80216e-04_125.pdf>
>
> 4) Contribution from Jiho et al.(Samsung):
>
<http://www.ieee802.org/16/tge/contrib/C80216e-04_164r1.pdf>
>
> 5) Contribution 245 from Jason et al.(ZTE):
>
<http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/TGe%252edb/C80216
e%2d04_265.pdf>
>
> 3. Mid amble
>
> The original requirement for preamble design is to
> provide channel estimation for both MIMO and SISO.
> During the discussion, people prefer to separate
> MIMO channel estimation from the preamble design
> due to the backward compatibility issue. Hence,
> several contributions related to Midamble are
> uploaded to handle MIMO channel estimation. Sirram
> suggested that we should deal with this issue in
> the preamble ad-hoc group. He agreed to
> co-ordinate the mid-amble harmonization and
> discussed the result in next CC.
>
> 4. Next CC:
>
> Aug. 25, Wednesday --20:00-22:00 USA pacific time,
> 12:00 for Seoul, 6:00 for TelAviv, 23:00 for Ottawa
>
> Regards,
>
> Peiying
>