| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Glen,
The "Framing and integration ..." presentation is "related" in the sense that it focuses on some of the issues of the joint ppt and takes a position on them.
So it probably makes sense to do the 2 ppts (as well as any other FEC ppts) in the same session. And also maybe to think about how to best structure the subsequent discussion.
- Jeff
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@teknovus.com]
Sent: Thu 9/14/2006 9:02 PM
To: 'Frank Effenberger'; Jeff Mandin; 'Ryan Hirth'; 'Roger Merel'; 'Frank Chang'
Subject: RE: [8023-10GEPON] FEC call details
Gents,
It is OK to continue updating the slides, but I need to know ASAP who will
present, exact title, and time requested.
I don't believe I have seen a request for agenda time, so the slides are
considered post-deadline.
Also, if you plan to split these slides into separate coding gain and
framing parts, I will need two separate requests.
Jeff- I don't think your request for "Framing and integration for
Stream-based FEC" is related to this set of slides. Please, advice.
Thanks,
Glen
> -----Original Message-----
> From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
> Sent: Thursday, September 14, 2006 9:29 AM
> To: STDS-802-3-10GEPON@listserv.ieee.org
> Subject: 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