RE: stds-802-16-tg4: Call for input - Data Encoding
Dear All TG4 group
John with Eric were the heads of the group that organized the decisions for
16.1 in this subject and it was not long time ago
and we should welcome his experience. I don't want to go in to this argue. I
am gambling between me and my self what will be the answer.
For who are celebrating the EASTER and PASSOVER hope for Happy days.
All the best
Zion Hadad
Runcom
-----Original Message-----
From: owner-stds-802-16-tg4@ieee.org
[mailto:owner-stds-802-16-tg4@ieee.org]On Behalf Of Minfei Leng
Sent: Friday, April 13, 2001 3:17 PM
To: Liebetreu, John; Stds-802-16-Tg4 (E-mail)
Subject: 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
> >
>