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/Comments%20on%20the%20GCL%20series.doc>
> S80216e-04_265.pdf
> <http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/S80216e%2d04_265.pdf>
> C80216e-04_265r1.pdf
> <http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/C80216e%2d04_265r1.pdf>
> Motorola_GCL_fast cell_search.pdf
> <http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/Motorola_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/S80216e%2d04_265.pdf
> http://wirelessman.dyndns.org/cgi-script/CSUpload//upload/temp%252edb/C80216e%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/Preamble_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/Session33%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/Motorola_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/Preamble_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/C80216e%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
>