RE: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
All,
The following are my comments on Lior's slides.
Page 2. Yes, but there are no EPON PHYs in the field right now. So I don't
think this factor is important.
Page 3+4. If we use IPG stretching as the rate adaptation method, then the
frame awareness is limited to detecting strings of idles that are longer
than minimum, and doing a standard elastic FIFO. This is classic byte
stuffing. In contrast, the F-FEC system must buffer the whole frame on
reception so that the parity can be received.
Page 5. Changing the line rate is only another option - one that we should
consider. Super-rating the optics would mean that all the ONTs on a PON
would use FEC. We may end up there, especially if that is the only way that
FP lasers can be made to work at this speed and distance. But for now that
has not been decided.
Page 6. First of all, if errors are occuring after the FEC, then the system
is going to fail very quickly. It means that you are on the steep slope of
the corrected BER curve. Even so, it doesn't matter if one or two symbols
are corrupted, because the entire frame is going to be discarded (the CRC
check will fail). On the error burst tolerance, nobody has indicated that
the errors we are correcting are bursty. In contrast, everybody (including
Passave) have indicated that they are random isolated bit errors. So this
is no big deal. Going further, while the burst length is shorter in our
proposal, each block of our FEC is 2080 bits, whereas each block of F-FEC is
~2550 bits. So, S-FEC can tolerate a somewhat higher random BER. But in
either case, the differences are trivial.
Page 7. The byte (word) alignment in the Rx is linked to the frame sync.
The FEC frames are word justified.
Page 8. A single framing byte is used in every fielded FEC system in the
world today. In the downstream, the conventional locking hysteresis could
be used, and would lock in 8 FEC blocks or so. That is 13 us. The comma
state machine produces similar results, since the ONT might power on in the
middle of a long frame during which there are no commas. So, there is no
difference.
In the case of the uplink, as I answered in my Email response to Ryan Hirth,
my assumption is that the upstream burst mode timing recovery would be using
a PON preamble and delimiter. This would be self contained and sufficient
to produce reliable timing in the face of errors. The tutorial presentation
in May 2002 provided an analysis of the burst mis-delineation rate that a
two symbol delimiter would produce.
As for the missing details - this is not a draft specification - it is a
baseline presentation. Furthermore, the issues you raise regarding the
details of burst mode detection are not addressed in any baseline currently.
I thinknthat you are operating under your own assumption that the upstream
delimitation will be done using the 8b10b comma function. That has not been
decided yet. I hope that the PMA-related issues will start to be worked
soon.
I hope that clears up some of the confusion.
Regards,
Frank Effenberger
-----Original Message-----
From: Lior Khermosh
To: Ajay Gummalla; Larry Rennie; stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx
Cc: stds-802-3-efm@xxxxxxxxxxxxxxxxxx
Sent: 7/3/02 12:29 PM
Subject: RE: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
Hi Ajay,
I have attached a few slides with some remarks regarding the Stream-FEC.
Best Regards,
Lior
-----Original Message-----
From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org
[mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org]On Behalf Of Ajay
Gummalla
Sent: Tuesday, July 02, 2002 8:43 PM
To: Larry Rennie; stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx
Cc: stds-802-3-efm@xxxxxxxxxxxxxxxxxx
Subject: [EFM-P2MP] FW: [EFM] EFM FEC Proposals
Larry and all:
I have attached a slide which compares the two proposals.
I am hoping that this will generate more discussions and help
us make progress.
Please take a look at
http://www.ieee802.org/3/efm/public/jul02/p2mp/gummalla_p2mp_1_0702.pdf
for the calculations on efficiency.
Best Regards,
Ajay
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of larry
> rennie
> Sent: Monday, July 01, 2002 6:31 PM
> To: stds-802-3-efm
> Subject: [EFM] EFM FEC Proposals
>
>
>
> Fellow EFM Task Force Members,
>
> At the last EFM meeting in Edinburgh we passed the following FEC
motion:
>
> 17. Motion to add an FEC option for the 1Gig P2P and P2MP PHY,
> maintaining backward compatibility with the 1000BASE-X PCS, for the
> following reasons:
> 1. Improves reach of a MPN limited link by 50% for links with MPN
> penalty of about 2dB
> 2. Permits operation at a SNR lower by 2.5 dB for non-dispersion
> limited links.
>
> Two different FEC implementation proposals will be presented in
> Vancouver and they are posted under the General Session material on
the
> EFM web site. One proposal is frame based and the other is stream
> based. If you are at all interested in FEC for EFM, I encourage you
to
> please take a look at these two proposals and get your comments and
> questions back onto the reflector before the meeting. This will give
> the presenters and their supporters time to formulate a proper
response
> and will conserve our precious meeting time in Vancouver.
>
> Regards,
>
> Larry
>
>
>
>
>
>
<<Remarks on Stream FEC for Ethernet1.pdf>>