Re: [STDS-802-16] [PREAMBLE] Aug 23 Preamble Ad-Hoc group CC sum mary
Jason,
I hope the discussion is to help all of us to understand your proposal,
especially for people who have not invested their time in this. If you
think otherwise, I was wasting my time.
So, if I am correct, you acknowledged the problem I mentioned, but you
think that cell planning can help you to avoid cases of getting two long
channels (SUI-5 for example with 10us delay) from both the desired and
neighboring cell with similar power (from the same segment number, of
course). Our field experience and experience of 2G and 3G systems tell
that the scenario is not rare and more so for micro-cell environments
(for example, in your scenario 2). I am not going to say more about
whether the fact represents a problem. We can leave this topic right here.
It seems that your challenge to the rest of us is whether GCL/PN can do
better than the one sequence CAZAC design. I can only say from my
experience that we have some simulation results to let me believe decent
estimation can still be done for channels to both the desired and
interfering cells at the subscriber, exploiting the cross correlation of
two GCL/PN sequences. When I say "decent", I mean, in one of the
simulation for example, a subscriber can use these channel estimates to
get 1% frame error rate at -4.5dB SINR (both channels have over 100
channels tap with a CP length of 128, rate-1/4 QPSK 3GPP Turbo code, use
an ML receiver).
In terms of the complexity of GCL/PN, you have a big misunderstanding on
the "time-domain" channel estimation technique. You should never use the
IFFT'd GCL/PN sequence to do a sliding window correlation with the
received data in the time domain. If you do, as you mentioned, it is
"mind-boggling". What you should do is, assuming pilots are on all data
subcarriers for the sake of this discussion, that you take an size-N FFT
to get the subcarrier data (say X), divide them by your sequence (say
S), take an IFFT back to time (say Y). It is equivalent to do a (cyclic)
time correlation over N samples, but way more efficient. This is also
the step you want the interfering channel taps are spread to a low level
so that at least the significant taps of the desired channel is only
minimally distorted. The desired channel should occupy only the first CP
samples of the IFFT's values Y (but the interfering channel is spread
over all N values of Y after this correlation). Now if you want to
estimate the channel to another cell, divide by the other preamble
sequence, and so on.
In terms of sequence storage if you do not want to generate GCL on the
fly, you can use a trigonometric look-up table and the phase increment
for GCL is discrete.
I hope the discussion is still helpful.
Regards,
Jeff
Jason Hou wrote:
>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
>>
>>
>>