Re: [8023-10GEPON] [FEC Superating] - kickoff preso
Glen,
As mentioned in the initial email of this trail a loss of sensitivity of
0.3dB (=1.07). A 7% increase in BW results in a 0.3dB degradation in
electrical SNR. For thermally limited receivers (PIN based) that
corresponds to 0.15dB degradation in optical power and for shot noise
limited receiver (like ideal APD) 0.3dB degradation in optical power.
This assumes that the receiver bandwidth is optimized for the particular
bit rate. For those type of bandwidths however, we are talking about low
pass filtering with capacitance values on the order of 0.1-0.5pF, so
practically the receiver bandwidth can not be optimized with this type
of 7% resolution.
Typical measured degradation for PIN based receiver is 0.5dB between
10Gb/s and 10.7Gb/s. For APD based receivers, which may likely be needed
for high link budget applications, this may be even more.
In addition there will be some penalty on the Tx side as well. Higher
bit rate Tx will have some eye closure, resulting in a need for
increasing the launch power to compensate for the eye closure penalty.
Combining both Rx and Tx penalties, I would estimate that as much as 1dB
more launch power may be needed for a 7% increase in bit rate.
In response to your point that there are two options on the table,
increasing line rate or decreasing MAC rate, either one would benefit
from minimizing the overhead. If the MAC rate is decreased less,
assuming 802.3 is OK with even decreasing it, the net capacity will be
higher. So no matter what the approach is, decreased overhead is always
better if the same link budget can be met with the decreased bit rate
overhead.
Finally in response to your point that if the FEC is mandatory, that
another approach could be taken, why does the FEC have to be mandatory
for this?
For optional FEC couldn't one do the following (again stated from a
FEC/PCS ignorant point of view). When FEC is turned on both PCS(64B/66B,
scrambling or other) and FEC are combined to deliver smaller combined
overhead. When FEC function is turned of only PCS coding is enabled.
Regards,
Thomas
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@teknovus.com]
Sent: Thursday, February 08, 2007 11:47 AM
To: Thomas Schrans; STDS-802-3-10GEPON@listserv.ieee.org
Subject: RE: [8023-10GEPON] [FEC Superating] - kickoff preso
Thomas,
The FEC code used in 1G EPON was *systematic*, meaning that it leaves
data symbols unchanged, and adds parity as a separate block. This was
important to allow non-FEC devices to be able to receive FEC-coded data.
But if we are talking about FEC being mandatory, perhaps we should look
at non-systematic codes.
Effectively, 10G scrambling used together with systematic FEC already
makes it a non-systematic code. And I am wondering if these functions
are more efficient when combined.
Could anyone answer these questions:
1) Are non-systematic codes more efficient? In other words, is overhead
of non-systematic codes different (lower) compared to the overhead added
by a systematic code for the same gain?
2) Are there non-systematic codes that make encoded data sufficiently
DC-balanced? If yes, it could be that scrambler would become
unnecessary.
> I just know that my 10Gb/s transceiver and optics
> have to work at 10.3125Gb/s, and now maybe 11.04Gb/s with FEC.
There are two options on the table. Either keep the data rate as it is
without FEC and increase outgoing line rate (PHY super-rating), or slow
down the incoming data, and keep line rate as it is now - 10.3125 Gb/s
(MAC sub-rating).
You need to tell us what impact going to from 10.3125 to ~11.05 Gb/s
will have on you, from the point of view of manufacturability, yield,
testing, operational stability, etc.
Glen
------------------------------------------------------------------------
--
DISCLAIMER: This e-mail expresses my views as an individual contributor
to
the task force, not as task force chair.
------------------------------------------------------------------------
--
> -----Original Message-----
> From: Thomas Schrans [mailto:TSchrans@OCP-INC.COM]
> Sent: Thursday, February 08, 2007 10:41 AM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>
> Jeff,
>
> Not knowing how to do the PCS and the FEC, I can not tell you if this
is
> what I mean.
>
> All I am trying to ask is the following
>
> We start with 10Gb/s
> We add 3.125% overhead for PCS 64B/66B, to get to 10.3125Gb/s
> We add say 7% overhead for FEC, to get to ~11.04Gb/s.
>
> By increasing the optical line rate, we start squeezing the optical
> specs and their cost.
>
> Wouldn't it be nice if the purpose of the PCS could be combined into
the
> FEC, resulting in a reduced overhead?
>
> From a transceiver point of view, I don't know what the purpose of the
> 64B/66B coding is. I just know that my 10Gb/s transceiver and optics
> have to work at 10.3125Gb/s, and now maybe 11.04Gb/s with FEC.
>
> Hopefully some of the PCS and FEC experts on the reflector can answer
> this, even if the answer is "Thomas you're out of your mind. Those 2
> functions can not be combined because ..."
>
> Regards,
>
> Thomas
>
>
> -----Original Message-----
> From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
> Sent: Thursday, February 08, 2007 10:01 AM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>
> Thomas,
>
> If you mean "why not use 1 bit of the PCS header for FEC parity and
> scramble the other bit like they did in 802.3ap - and then we need
only
> 100 (== 128 - 28) additional bits of parity per FEC codeword?" ...
>
> ... then the answer would seem to be that you could in fact do that,
but
> that the resulting numbers are not any easier to work with. In
> particular if we want to put the parity data into a 66b block (as we
> have been assuming) there is no advantage because 2 66b blocks are
> still needed.
>
>
> -----Original Message-----
> From: Thomas Schrans [mailto:TSchrans@OCP-INC.COM]
> Sent: Thursday, February 08, 2007 7:41 PM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>
> I'm neither a FEC expert nor a PCS expert, so I have what may look
like
> a simple question:
>
> Why can we not combine the PCS overhead (64B/66B =3%) and FEC overhead
> (~7%), so that the combined overhead is less than the sum of the two.
>
> Regards,
>
> Thomas Schrans, Ph.D.
> Design Engineering Manager
> Optical Communication Products, Inc.
>
> -----Original Message-----
> From: EffenbergerFrank 73695 [mailto:feffenberger@HUAWEI.COM]
> Sent: Wednesday, February 07, 2007 11:35 PM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>
> The actual rate is the repeating fraction. But, it is not a problem
to
> have a rate that is not expressible in a short fraction. However, a
> round number has a 'prettiness factor.'
>
> What is important that the rates have a reasonably simple ratio.
>
> Frank E.
>
>
>
>
> ----- Original Message -----
> From: glen kramer <glen.kramer@TEKNOVUS.COM>
> Date: Tuesday, February 6, 2007 5:16 pm
> Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
>
> > Frank,
> >
> > > Just as a for-example, the 11.049 GHz happens to be 15/14ths of
> > 10.3125.
> >
> > I calculate that 15/14ths of 10.3125 is equal
> > 11.049107142857142857142857142857...
> >
> > Is this a problem? Should super-rating employ additional rate
> > adaptationmechanism to make it a "nice" number?
> >
> > For example, inserting one extra block every 1875 blocks will bring
> > the rate up to 11.055.
> >
> >
> > Glen
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Jeff Mandin [Jeff_Mandin@PMC-SIERRA.COM]
> > > Sent: Tuesday, February 06, 2007 1:41 AM
> > > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> > >
> > > Frank,
> > >
> > > I think you might be conflating the loop timing issue with some
> > other> issue raised earlier.
> > >
> > > The point I intended to raise about loop timing is that the
upstream
>
> > > frequency of 1.25 GHz is fixed already, and in the asymmetric 10/1
> > case
> > > the ONU needs to derive the upstream clock from the downstream
> > signal.Of
> > > course how easy or difficult it is to do that depends both on the
> > > dividability of the downstream frequency by 1.25 Ghz and also
> > on the
> > > jitter of the downstream signal.
> > >
> > > 11.25 Ghz (rather than 11.049 GHz) would be fine. Can XFI/SPI
> > components
> > > go that fast?
> > >
> > > - Jeff
> > >
> > > -----Original Message-----
> > > From: Frank Effenberger [feffenberger@HUAWEI.COM]
> > > Sent: Monday, February 05, 2007 6:02 PM
> > > To: STDS-802-3-10GEPON@listserv.ieee.org
> > > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> > >
> > > All,
> > >
> > > I don't think that clock management is so strong an advantage
> > for one
> > > scheme over the other. In all the cases, in all the technologies,
> > there
> > > are a set of frequencies that are phase-locked to each other.
> > Dividers
> > > and PLLs do a fine job of inter-converting them. One is not much
> > harder
> > > than the other, unless we choose a poor frequency for the
> > super-rating.
> > > We should be more careful!
> > >
> > > Just as a for-example, the 11.049 GHz happens to be 15/14ths of
> > 10.3125.
> > > Those are reasonably small clock dividers, and not a big problem
to
> > > implement. Note that this division builds on top of the 33/32nds
> > clock
> > > ratio of 64b66b. If we go with super-rating, then I see no
> > reason to
> > > maintain the redundant framing bit. Rather, I think we would
> > look for
> > a
> > > clock relationship from the FEC super-rate directly to the 10G
base
> > rate.
> > >
> > > In any case, I will add the item to the list, for completeness
sake.
> > >
> > > Regards,
> > > Frank E.
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Jeff Mandin [Jeff_Mandin@PMC-SIERRA.COM]
> > > Sent: Monday, February 05, 2007 9:19 AM
> > > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > > Subject: Re: [8023-10GEPON] [FEC Superating] - kickoff preso
> > >
> > > Frank hi,
> > >
> > > Loop-timing for the asymmetric 10/1 case would appear to be
another
> > "pro"
> > > for the subrating scheme.
> > >
> > > The ONU can - perhaps - use the recovered 10.3125 clock to
> > derive one
> > of
> > > 312.5 Mhz (divide by 33), and then use a PLL to generate the
> > upstreamrate
> > > (multiply by 4). With 11.1 Gb/s XSBI this would probably be
> > much more
> > > difficult.
> > >
> > > - Jeff
> > >
> > > -----Original Message-----
> > > From: Frank Effenberger [feffenberger@HUAWEI.COM]
> > > Sent: Wednesday, January 31, 2007 10:32 PM
> > > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > > Subject: [8023-10GEPON] [FEC Superating] - kickoff preso
> > >
> > > Dear All,
> > >
> > > I have put together the following presentation on the issue of
> > FEC and
> > > line-rate vs. MAC-rate modification. I tried to include in these
> > slides
> > > all the arguments I have heard favoring one method or the other.
> > If I
> > > have forgotten your favorite, you can shoot an Email to me, and
I'll
> > add
> > > it to the list.
> > >
> > > You may also note that the last slide, entitled "Reaching a
> > decision"is
> > > blank. I don't know a truly objective way to solve this
> > problem... It
> > > seems to me that when you stack up the pros and cons, these two
> > schemes
> > > are pretty equal.
> > >
> > > One last thought: The one 'hard' (objective) con for the super-
> > rating> scheme is the loss of 0.3 dB of sensitivity. The one
> > 'hard' con for
> > the
> > > sub-rating scheme is the loss of bandwidth (7% lost). How can
> > we put
> > > these two items
> > > on a common comparative base? Usually, the common denominator in
> > these
> > > situations is cost, so...
> > > What is the relative system cost increase due to 0.3dB optical
loss?
> > > What is the relative system cost increase due to a 7% capacity
loss?
> > > If someone wants to hazard an answer to these questions, please
do.
> > >
> > > Regards,
> > > Frank E.
> >