Re: [8023-10GEPON] FEC, and the need to scramble parity bytes.
Dear Duane,
Well, scrambling when you don't have to won't hurt the signal.
It will add a small complexity which we don't need...
If we use a self-synchronous scrambler, then there will be error
multiplication, which is not acceptable in this case (since we are trying to
correct errors!)
So, we'd have to use a codeword-synchronous scrambler (e.g., as defined in
G.975) This, effectively, XORs each codeword with a fixed pseudorandom
pattern. Not a big deal, but just another level of indirection.
There will be plenty of time later to worry about this small nit.
The far bigger issue is the selection of the FEC code. I noticed that
several presentations mentioned that Enhanced FEC might be a good idea for
10G EPON.
As some may be familiar, the ITU has two FEC standards for optical line
systems.
The first, which has been around for some time, specifies RS(239,255).
This has the advantages that it obtains quite a lot of gain and is found in
the text-books (hint: public domain).
The second, which is somewhat new, considers "Enhanced FEC". These codes
can squeeze out some more gain, but typically do so at the price of larger
block sizes (which is an issue in PON) and much larger processing load (so
much that I fear it is more than a typical ONU MAC can carry). The biggest
issue with the enhanced FEC codes is that there is more than one, with each
belonging to its parent company. This produced a deadlock in the ITU, which
was resolved by standardizing all the codes. This was less than ideal, for
obvious reasons, but seems inescapable.
So, what I'm getting at is this: if we plan to go for an E-FEC scheme, then
we may well get pulled into a major controversy and deadlock. This risk,
coupled with the processing and block-size issues of E-FEC, makes me
question whether E-FEC is such a good idea.
Anyhow, it's just food for thought.
Regards,
Frank E.
-----Original Message-----
From: Duane Remein [mailto:duane.remein@ALCATEL.COM]
Sent: Thursday, July 20, 2006 10:43 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC, and the need to scramble parity bytes.
Frank,
Would scrambling the FEC parity bytes have any potential detrimental
effect? I ask this because sometimes its is easier to do something
rather than to not do it in some special case (although in this case I
don't think it is a big difference).
Thanks
Duane
Frank Effenberger wrote:
> Dear All,
>
> At the meeting today, there was a small issue on the need to scramble the
> parity bytes that a FEC algorithm produces. As a reference point, I
looked
> at G.975, which defines the use of RS(239,255) in SDH systems. It seems
> that this standard suggests that scrambling the FEC output is not
necessary.
> (section 6.4.3, first paragraph).
>
> There are two complications that I'd like to point out in fairness.
> 1. G.975 operates by interleaving n encoders (e.g., n=16), so the parity
is
> not transmitted in quite the way that we would do. However, the parity is
> transmitted all in a big bunch at the end of the interleaved block, so if
> the parity had some kind of pathological pattern, it would be revealed in
> these systems.
> 2. Section 6.4.3 mentions that in some systems, the main SDH scrambler may
> be disabled, and then in that case a FEC layer scrambler is defined. But,
> that is really a matter of implementation choice, and I don't believe it
> contradicts the main idea that parity that is calculated on scrambled data
> is effectively also scrambled.
>
> So, I would say that we do not need to worry about scrambling the parity.
>
> Sincerely,
> Frank E.
>
>