RE: stds-802-16-tg4: Call for input - Data Encoding
I have received individual emails from 16.4 members encouraging me to
address John's argument point by point. Here it is:
> Very little of what you have written about convolutional and
> concatenated codes
> is true.
I would disagree that statement. See my comments below.
> 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)
>
I didn't say maximum CR 0.5, I said typical CR 0.5. My understanding was
Viterbi has lower CR than TPC, which has lower CR than RS. Recent
advancement in technology probably brought the CR of Viterbi and TPC close
to RS. I would therefore argue that my point was not completely correct,
but not completely wrong either.
> 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.
>
I said TPC has the best performance/price ratio for HUMAN environment, which
I will stand fast by it. I also believe, everything considered, TPC is
intrisically better at handling burst errors. I agree with John that
interleaving is important, but I am not sure if it's the most dominant
factor. There is a whole new discussion which I don't enough about to
start.
> 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.
>
When I said TPC is closest to Shannon limit in my introductory paragraph, I
was comparing it with RS and Viterbi. It's the second sentence of the
email. Later, when including TCC, I said in the table that TCC has
slightly better performance than TPC at higher BER, but it has a performance
floor at lower BER. I admit that I didn't read or even know about the JPL
papers. But I didn't think my statement was far from the truth. I will
count this point as in my favor.
> 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.
>
I don't know what you are arguing against. I said clearly in the table as
Implementation Pro for Concatenated schemes "serial concatnation, less
complex than TPC". So we agree with each other.
> 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.
>
I agree. It's not a right or wrong issue. I take it as John's advice to
me. Maybe John or someone else can show us a few good ones.
> Mis-information is worse than no information.
So what's the count? Out of 4 applicable points, I was at least partially
right on two points and close to completely right on the other two. Less
than perfect, not as updated information? Maybe. Mis-information? I beg
to differ.
Again, I just want to stress the importance of having active participation
of the input process. I am waiting for gems...
--------------------------------------------------------------------------
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
> >
>