Re: [8023-10GEPON] FEC call details
Jeff,
If what you mean by 'serial locking' is the approach of finding the FEC
codewords by looking for where the parity seems to match the preceding data,
then good luck... I think you will find that with the kinds of codes we are
talking about, the processing power required to even check the parity is
sizable. Actually trying to calculate the errors is quite expensive. So,
the only shot you have is to do checking only.
At 1e-4 BER and a codeword of 2000 bits (typical RS operating point), the
likelihood of getting a 'clean' codeword is only 80%. That means that even
if you are perfectly aligned, the parity indicates error 20% of the time.
So, you will need to have a pretty permissive state machine that takes a
long time to confirm lock with the kind of certainty that 802.3 expects.
At 1e-3 BER and a codeword of 8000 bits (typical E-FEC operating point), the
likelihood of getting a 'clean' codeword is less than 1%. Hard, it is.
The backplane FEC system uses 'serial locking', but that system is in a much
different league: BER of 1e-6, parity of 32 bits, and a code that is
guaranteed not to produce false codewords out of alignment.
It is good to have this discussion, so that we can air it out, look at it,
and then resolve it. So, go ahead with the change... (I would ask that you
add back in the 'sync' pattern on slide 12, with broken lines around it, to
indicate its optional nature. It makes things a little clearer for people
to understand what a sync pattern would be, if we decide to go that way.)
Of course, if our goal is to completely broaden the presentation to include
all possibilities, then perhaps we should include the option of letting the
66b blocks float inside the FEC codeword... it could work (I believe that
this method is actually what some of the ad-hoc FEC-10G Eth PHYs do). We'd
just let the 66b state machine do its job after the FEC does its alignment.
Do you want to add that possibility, too? Perhaps we should, just for
completeness.
Sincerely,
Frank E.
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
Sent: Thursday, September 14, 2006 10:08 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC call details
Frank,
Serial locking is used in other IEEE standards; more info will be
forthcoming. On slide 20, both serial locking and pattern based sync
are listed as options.
Attached version has Frank C.'s changes (please confirm).
BRs,
- Jeff
-----Original Message-----
From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
Sent: Thursday, September 14, 2006 5:33 PM
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] FEC call details
Jeff,
I agree with most of your edits, but you seem to have removed the 'sync'
pattern from slide 12, and introduced this new concept of 'serial
locking'
on slide 20. Pray tell, what is that? How's it work?
Please explain to the group... thanks. By the way, Frank C. has made
additional edits, so you need to coordinate the two forks of the
preso...
Regards,
Frank E.
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@pmc-sierra.com]
Sent: Thursday, September 14, 2006 8:55 AM
To: Frank Effenberger; STDS-802-3-10GEPON@listserv.ieee.org
Subject: RE: [8023-10GEPON] FEC call details
All,
I've made some changes to the framing part of the ppt (attached) - both
to "soften" some language and to broaden the options in a couple of
places.
Regards,
- Jeff
-----Original Message-----
From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
Sent: Wednesday, September 13, 2006 7:33 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC call details
Dear All,
Sorry I couldn't make it to the last call.
I have edited Frank C.'s version 3, mainly addressing the framing slides
at the back half of the slideset. My intent was to highlight each of
the design choices, so as to make the preso more generic and
awareness-building, and less of a position statement.
A couple of comments on Frank C.'s section:
On slide 3, various receiver sensitivities are put forward, but I think
that the type of Rx (PIN or APD) is missing. This makes comparisons
within the slide misleading. I suggest that a more detailed comparison
be made.
On slide 4, the chart on the left has its X-axis labeled "Net coding
gain".
This is not correct. I believe the label should say "Input signal to
noise ratio". The chart on the right lists 'average power' on its
X-axis - I assume that this was the optical average power going into an
APD receiver (of unknown make and model). These details should be
spelled out.
We might put in a slide that puts up the generic transformation between
option input power and electrical SNR.
Finally, I would like to be added to the list of supporters.
Regards,
Frank Effenberger
-----Original Message-----
From: Frank Chang [mailto:ychang@VITESSE.COM]
Sent: Tuesday, September 12, 2006 5:59 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] FEC call details
All;
Here quickly summarize the call on FEC discussion....
The call took about 1 hour. The attendees were: Glen Kramer, Ryan Hirth,
Jeff Mandin, Petre Popescu, Paul Kolesar and Frank Chang. Frank
Effenberger notify unable to attend due to sth. come up. Glen kindly
provide the EA bridge to host the call.
The group ran though the slideset of the algorithm part addressing
coding gain vs. power budgets, the main topics of discussion as follows:
1. The group agreed to keep the topic generic, avoid making a position
statement on any of the issues at this stage. These slides help bring
the whole group up to speed on the topics. This discussion help generate
the list of issues to be considered.
2. 29dB budget reqs was discussed in detail, SOA-based and FEC-based
power budgets were compared. One suggestion was: as 29dB budget isnot
yet the budget choice officially approved by the group, it's restated as
an example under consideration.
3. Still questionable if FEC has to be mandatory for link budget.
Comment this statement is better addressed when the study group concur
on various power budgets. Further consideration was to consider the
choice of FEC
category: frame-based vs stream-based.
4. Discuss the correlation of coding gain vs. resultant optical gain.
Concur the coding gain is a true rep. of FEC code performance. Suggest
tabulate the code option vs. coding gain for various code alternatives.
5. Clarify the 64B/66B rate FEC option, this is standard based code
specified in backplane and OIF-CEI-P.
6. Discuss latency issues, commonly believe there won't be an issue if
fixed latency.
7. Time quanta - As to topic if the time quanta should be changed to
match the 66 bit codeword. Glen propose he will reiterate his previous
slides in
coming meeting to make clear the time quanta doesnot need to change.
8. Path forward - The involved party going to review the new slides
version (here as attached), will access if there is a need to proceed
next call.
Pls add comments if I miss anything.
Thanks,
Frank C.
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@teknovus.com]
Sent: Friday, September 08, 2006 9:34 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: [8023-10GEPON] FEC call details
All,
The conference call for FEC is planned for Monday, September 11th, 9:30
AM US Pacific time. The following is the bridge number, courtesy of the
Ethernet Alliance:
Dial in Number
1-866-228-9900
International Number
1-719-359-4032
Participant Passcode 383731
The bridge is reserved for 1.5 hrs. I hope this would be enough.
Glen
> -----Original Message-----
> From: Glen Kramer [mailto:glen.kramer@TEKNOVUS.COM]
> Sent: Friday, September 08, 2006 12:50 PM
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: Re: [8023-10GEPON] Presentation on FEC for 10G
>
> Frank,
>
> This is rather a short notice. I will see if I can reach the AE today.
> If not, I will find an alternative conference call facility and will
> post the details later tonight.
>
> Glen
>
> > -----Original Message-----
> > From: Frank Chang [mailto:ychang@VITESSE.COM]
> > Sent: Friday, September 08, 2006 11:25 AM
> > To: STDS-802-3-10GEPON@listserv.ieee.org
> > Subject: Re: [8023-10GEPON] Presentation on FEC for 10G
> >
> > Glen;
> >
> > Right now the conf call. is planning to be next Monday 9:30AM PDT,
> > no conflicts heard so far. Could you provide a EA bridge for this?
> > The
> agenda
> > is for FEC associated discussions. (I believe Frank E. is
> > traveling.)
> >
> > Frank C.
> >
> > -----Original Message-----
> > From: Glen Kramer [mailto:glen.kramer@teknovus.com]
> > Sent: Friday, September 08, 2006 11:08 AM
> > To: STDS-802-3-10GEPON@listserv.ieee.org
> > Subject: Re: [8023-10GEPON] Presentation on FEC for 10G
> >
> > Frank,
> >
> > Thank you for organizing the FEC discussions.
> >
> > Few people have asked me for a summary of the FEC call. Would you
please,
> > post to the reflector a short overview of the call: what was
> > discussed
> and
> > any steps planned next.
> >
> > Also, if you plan another conf call, please announce it on the
reflector,
> > so
> > that those who are interested, but missed the first call could join
> > this time.
> >
> > I also want to remind everybody that the Ethernet Alliance has
> > offered 10GEPON group a sponsorship in a form of hosting conference
calls.
> Please,
> > let me know if you would like to have a conference call in
> > preparation
> for
> > the September meeting.
> >
> > Regards,
> > Glen
> >
> > > -----Original Message-----
> > > From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
> > > Sent: Wednesday, August 16, 2006 9:44 AM
> > > To: STDS-802-3-10GEPON@listserv.ieee.org
> > > Subject: [8023-10GEPON] Presentation on FEC for 10G
> > >
> > > Dear All,
> > >
> > > I am interested in putting together a presentation on FEC for 10G
> > (serial)
> > > PONs. Judging from the materials from the July meeting, I think
> > > that there is some common support for the following basic ideas:
> > >
> > > 1. FEC should be applied at the very lowest layer (streaming-FEC).
> > > 2. FEC should be a mandatory part of the line code.
> > > 3. FEC codeword size should be aligned with the other EPON
> > > structure
> > sizes
> > > (such as 66b blocks and MPCP time quanta)
> > >
> > > There are related topics that I don't think we've reached
> > > consensus
> on:
> > > a. Choice of basic FEC algorithm (e.g, RS, BCH, etc.) b. Line-rate
> > > increasing versus MAC-rate reducing approach c. Code-rate and
> > > objective gain values (some of these require collaboration with
> > > PMD specialists.)
> > >
> > > If there are people who are interested in working with me on a
> > > presentation on these topic areas, please let me know.
> > >
> > > Sincerely,
> > > Frank Effenberger
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Glen Kramer [mailto:glen.kramer@teknovus.com]
> > > Sent: Friday, August 11, 2006 5:04 PM
> > > To: STDS-802-3-10GEPON@listserv.ieee.org
> > > Subject: [8023-10GEPON] presentations for September meeting
> > >
> > > Dear colleagues,
> > >
> > > It appears that our next meeting will take place on September 18th
> > > and 19th (Monday and Tuesday) and the High-Speed SG will meet on
> > > 20th and 21st,
> > so
> > > there will be no overlap and interested people will be able to
> > > attend
> > both
> > > meetings.
> > >
> > > The meeting venue has not been finalized yet. A venue should be
> > announced
> > > at
> > > least 30 days before the meeting, so expect the announcement very
soon.
> > >
> > > Meanwhile, it is time to start working on presentations for the
> > > next meeting.
> > >
> > > There are many specific topics/features that we have to reach
> consensus
> > > on:
> > >
> > > Downstream Wavelength
> > > Upstream Wavelength
> > > Power budgets
> > > FEC: Optional or Mandatory
> > > FEC Category: Stream-based vs. Frame-based other topics - anything
> > > that is in scope of our PAR can be discussed.
> > >
> > > If you can think of any other topic not listed here, please
> > > propose it
> > on
> > > the reflector.
> > >
> > >
> > > If you have opinion on any of these or other topics, make a
> presentation
> > > with arguments in favor of it. Remember, a proposal should have >
> > > 75% support to get accepted as a baseline. It is a good idea to
> > > circulate proposals on the reflector and get feedback, and to
> > > enlist additional supporters.
> > >
> > > Regards,
> > > Glen