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

RE: stds-802-16-tg4: Call for input - Data Encoding



John,

Thank you for your response.

As I have said, I am no expert in this area.  Most of my knowledge come from
reading product application notes and talking with DSP engineers.  I didn't
make up that comparison table from thin air -- I could show you the
text/article where I got them from.

When discussing merits of different FEC methods, I doubt there is any
absolute truth, just like debating single-carrier vs OFDM.  That's why I
tried to use the phrase "in my opinion" and "I think ... is better".  If you
don't agree with my opinion, please feel free to argue.  

Now let's take a step back.  Let's just say you were right and most of what
I said was wrong.  That's probably because the books and articles I read
were out-dated and I haven't got any latest findings like the JPL paper.  So
what's your opinion on the pros and cons of the four methods?  There is an
old Chinese saying: "throwing out a brick and soliciting a gem".  I would be
delighted if my contribution could result in more expert opinions.  That's
really why we are doing this: by iterative process we reach a concensus for
the standard.  So far you basically pointed out that mine was a piece of
ugly brick.  I am not sure if it's true, even if it were, then I am waiting
for the gem.

--------------------------------------------------------------------------
Minfei Leng
Phone: (716)631-4584; Fax: (716)631-6080
Clearwire Technologies
P.O.Box 850
Buffalo, NY 14225-0850
www.clearwire.com


> -----Original Message-----
> From: Liebetreu, John [mailto:jliebetr@intersil.com]
> Sent: Thursday, April 12, 2001 5:24 PM
> To: Minfei Leng; Octavian Sarca; Stds-802-16-Tg4 (E-mail)
> Subject: RE: stds-802-16-tg4: Call for input - Data Encoding
> 
> 
> Minfei,
> 
> Here is my 5 cents... (by the way, Sean, the originator of 
> this thread, is from
> AHA).
> 
> Very little of what you have written about convolutional and 
> concatenated codes
> is true.  To whit:
> 
> 1. convolutional codes with puncturing ususally have rates of 
> n/(n+1).  This
> means that the code could be configured to have a code rate 
> of 0.9 or higher
> (compare to your statement limiting the maximum rate to 0.5)
> 
> 2. the interleaving, and not the coding scheme itself, is the 
> most dominant
> factor in addressing performance in a fading environment, but 
> the interleaver
> depth must be matched to the fade duration.  It isn't correct 
> to make the
> blanket statement that TPC codes are better at handling 
> fading channel error
> statistics.
> 
> 3.Research at NASA JPL has shown that TPC codes are no closer 
> to the Shannon
> limit than convolutional turbo codes.  See their website and 
> publications.
> 
> 4. Concatenated coding schemes (e.g., Viterbi/RS) have a 
> decoder implementation
> complexity that is less than that of TPC codes.  Furthermore, 
> any code will be
> less stressed in an AWGN environment.  As I noted earlier, 
> the interleaver is
> the dominant factor in addressing burst error statistics.
> 
> 5. There has been a great deal of effort expended on 
> comparing different coding
> schemes by participants in TG1.  See the website and examine 
> the documents for a
> wealth of useful infomation.
> 
> Mis-information is worse than no information.
> 
> John Liebetreu
> Intersil Corporation
> Scottsdale, Arizona
> 
> 
> -----Original Message-----
> From: Minfei Leng [mailto:Mleng@Clearwire.com]
> Sent: Thursday, April 12, 2001 12:31 PM
> To: Octavian Sarca; Stds-802-16-Tg4 (E-mail)
> Subject: RE: stds-802-16-tg4: Call for input - Data Encoding
> 
> 
> Octavian,
> 
> Here is my two cents on the error correction schemes.
> 
> Of the four methods suggested, I think block turbo codes 
> provide the best
> performance/price ratio.  I don't know much about 
> convolutional turbo codes
> - method 4, but in my opinion TPC is better than Convolutional or
> Concatnated RS & Convolutional.  TPC is very good at handling 
> burst noise,
> which is typical of HUMAN environment; and its block 
> structure lends well to
> the TDD scheme.  TPC has the highest potential for 
> performance -- closest to
> Shannon limit, and has seen a lot of R&D works recently.  The 
> other methods
> either don't have as good performance, or are better suited 
> for a different
> noise environment, like AWGN or different applications, like 
> streaming data.
> 
> I do want to suggest another method: RS with Eraser.  You basically
> determine which block has error before correcting the data.  
> The advantage
> is obvious.  I am no expert in it, but maybe someone else 
> from 16.4 can
> voice their opinions.
> 
> Talking about evaluating FEC schemes, I wonder if any 16.4 
> subscriber is
> from AHA.  I gained most of my FEC knowledge from their products and
> literature.  They have products in all kinds of FEC and 
> therefore should
> have the expertise to evaluate different technologies with a 
> relatively
> unbiased opinion.
> 
> I made up a table comparing the pros and cons of the 5 methods in
> performance, implementation, and future growth.  I will try 
> to copy and
> paste below.  I have been told the reflector doesn't support 
> attachments.
> So I have to be a little creative.
> 
> Coding schemes		Convolutional
> Examples			Viterbi
> Applications		VOIP, video streaming
> Performance: Pro		decent performance
> Performance: Con		low code rate (typical 0.5); 
> Implementation:Pro	easy implementation, cheap chip; 
> Implementation:Con	sharp increase in complexity with 
> increasing memory,
> better suited for streaming data
> Future Development	haven't seen much
> 
> Coding schemes		Concatnated RS & Convolutional
> Examples			encode: RS + Viterbi; decode: 
> Viterbi + RS
> Applications		DSL?
> Performance: Pro		high code rate (typical 0.93);     
> Performance: Con		not as good performance as TPC, 
> better for
> AWGN than burst noise
> Implementation:Pro	serial concatnation, less complex than TPC;
> Implementation:Con	expensive chip
> Future Development	haven't seen much
> 
> Coding schemes		Block Turbo 
> Examples			Turbo Product Code
> Applications		wireless MAN
> Performance: Pro		good for burst error, highest 
> potential for
> performance; closest to Shannon limit; 
> Performance: Con		output is not hard decision; CR 
> used to be
> <0.8, now 0.9 or higher
> Implementation:Pro	block intrisically fits TDD
> Implementation:Con	parallel concatnation more complex to 
> implement;  
> Future Development	much development recently
> 
> Coding schemes		Convolutional Turbo
> Examples			don't know
> Applications		don't know
> Performance: Pro		slightly better performance than TPC for
> higher BER; 
> Performance: Con		probably lower code rate;  BER 
> performance
> floor
> Implementation:Pro	don't know
> Implementation:Con	better suited for streaming data
> Future Development	don't know
> 
> Coding schemes		RS with Eraser
> Examples			don't know
> Applications		wireless LAN
> Performance: Pro		high CR, good for burst error
> Performance: Con		not as good as TPC, similar to Viterbi
> Implementation:Pro	less complex than TPC
> Implementation:Con	complex algorithm to determine bad 
> block to erase
> Future Development	don't know
> --------------------------------------------------------------
> ------------
> Minfei Leng
> Phone: (716)631-4584; Fax: (716)631-6080
> Clearwire Technologies
> P.O.Box 850
> Buffalo, NY 14225-0850
> www.clearwire.com
> 
> 
> > -----Original Message-----
> > From: Octavian Sarca [mailto:osarca@redlinecommunications.com]
> > Sent: Monday, April 09, 2001 7:49 PM
> > To: Stds-802-16-Tg4 (E-mail)
> > Subject: stds-802-16-tg4: Call for input - Data Encoding
> > 
> > 
> > Dear Colleagues,
> > 
> > I would like to receive input on the Data Encoding ASAP. As we
> > discussed, this section contains:
> > 1. Data randomizer (scrambler)
> > 2. FEC
> > 3. Interleaving
> > Since we did not reach an agreement on these choices and 
> > based on Sanjay
> > recommendation, we have to include all the proposed/discussed 
> > methods in
> > this section. Since FEC and interleaving are strongly related each
> > other, I would suggest organizing the section as follows:
> > 
> > 4. Data Encoding
> > 4.1. Data randomizer
> > 4.1.1. Method 1 - As in 802.11a
> > 4.1.2. Method 2 - As in DVB
> > 4.2. Encoding and interleaving
> > 4.2.1. Method 1 - Convolutional
> > 4.2.1.1. Convolutional encoder
> > 4.2.1.2. Interleaving
> > 4.2.2. Method 2 - Concatenated RS and convolutional w/ tail biting 
> > 4.2.2.1. RS encoder
> > 4.2.2.2. Convolutional encoder
> > 4.2.2.3. Interleaving
> > 4.2.3. Method 3 - Block turbo codes
> > 4.2.3.1. Block turbo encoder
> > 4.2.3.2. Interleaving
> > 4.2.4. Method 4 - Convolutional turbo codes
> > 4.2.4.1. Convolutional turbo encoder
> > 4.2.4.2. Interleaving
> > 
> > I can review the randomizer (4.1.1.) and the convolutional 
> part (i.e.
> > 4.2.1) which unfortunately are the only ones present in the current
> > draft) but I would need submissions on the other topics.
> > 
> > I am especially interested in getting detailed input from 
> people that
> > proposed the methods (i.e. Yossi and Brian) but other 
> people can also
> > submit.
> > 
> > Thank you very much in advance,
> > 
> > Octavian Sarca
> > Redline Communications Inc.
> > 90 Tiverton Crt. #102
> > Markham, ON, L3R 9V2
> > E-mail: osarca@redlinecommunications.com
> > 
>