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
> >
>