Re: [8023-10GEPON] Revised 10G budget
Dear Frank,
I was planning to voice similar concerns to Yours. The whole story with the FEC and power budget selection is a perfect example of the term "vicious circle". I am afraid though that we need to start from somewhere and power budget is the place of choice here - we can discuss the selection of the FEC code (whether standard or enhanced) and the exact values of the FEC gain for PIN and APD later on, adjusting the power budget values when necessary. I do not believe that blocking the development process is advisable, especially since we have already suffered from a setback.
Please rest assured that the Editors will pay special attention to the numbers that do find their way into the draft and cross check them to make sure they add up. Moreover, we have our Excel spreadsheet, which can easily tell us whether the power budget is fine or not. I think we have the tools and know-how to complete this process following all the basic engineering principles.
Regarding the note You propose Frank - I do not think that such a note needs to be included in the draft since the standard does not need to specify anything about the background for the selection of the particular values. When we say that the LD will output +3 dBm, we do not define what the test results were or what the expected value is. We just say it is +3 dBm, which we know is OK with the manufacturers. Such a note could potentially find its way to a motion though, where the group would decide on the initial FEC gain value, cutting this discussion once and for all for the time being. I believe the values which You adopted in Your proposal are reasonable as a first-order approximation and can be accepted for drafting purposes. If during the revision process we do find out strong evidence that the FEC will give us less gain, we can always revisit the tables, change values etc. as long as there is strong evidence to do so.
The motion could go as follows: "IEEE 802.3av adopts tentatively the FEC code optical gain of approximately 4dB for PINs and 5dB for APDs for the purpose of producing draft D1.0. The selected FEC code optical gain values can be revised at any time, with the power budget values adjusted appropriately to compensate".
This would perhaps tell the group what values we are talking about for now and where we start. Feel free to reshape the form and contents of the motion or not use it at all.
I am in favour of moving forward with the power budget and letting the FEC group focus on their task in parallel rather than trying to do them one thing at a time. We have resources to run these efforts simultaneously and perhaps that will allow us to make up the lost time.
I would welcome any comments on this topic.
Thank You Frank for Your contribution
Marek Hajduczenia (141238)
NOKIA SIEMENS Networks S.A., Portugal - R
Rua Irmãos Siemens, 1
Ed. 1, Piso 1
Alfragide
2720-093 Amadora
Portugal
* Marek.Hajduczenia@siemens.com
http://www.marekhajduczenia.info/index.php
(+351.21.416.7472 4+351.21.424.2082
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg." - Bjarne Stroustrup
-----Original Message-----
From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
Sent: segunda-feira, 22 de Outubro de 2007 17:47
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Revised 10G budget
Dear All,
I think we've been around this discussion cycle several times already...
The FEC people would like to have an optical budget decision before they
choose the code, and the optical budget people would like a FEC code
decision before they make their choices. Unfortunately, it is a circular
request.
As it has been, the optics folks have been using the RS family of codes as a
surrogate. But, to be clear: these are only examples. I do hope that we
can do better than this code family. Indeed, we've seen many presentations
showing us all sorts of codes. There is a strong possibility that the final
code we select may not be a RS code after all.
So, it seems to me that the ball has been in the optical court already. The
next step is to set forward an optical baseline that puts down our best
approximation of what the optics can be.
But, I'm gathering the impression from these last two comments that there is
a fear that if the baseline is based on an enhanced FEC, and then a regular
FEC is selected, then somehow we might get stuck. Personally, I don't think
that this would happen, because the group as a whole will act as responsible
engineers. But, I'd like to make everybody feel comfortable.
I think there is a solution for this. We can add as part of the proposed
baseline document a statement such as:
"The values chosen assume a FEC code with an optical gain of approximately
4dB for PINs and 5dB for APDs, and if the selected FEC code gains are
significantly less that these values, then the budget values must be
adjusted upward to compensate."
Would that statement satisfy everybody? Please let me know.
Sincerely,
Frank E.
-----Original Message-----
From: Hiroshi HAMANO [mailto:hamano.hiroshi@JP.FUJITSU.COM]
Sent: Monday, October 22, 2007 5:32 AM
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Revised 10G budget
Dear Dr. Effenberger,
I am afraid I have a little different understanding about FEC.
For the MAC chip suppliers, FEC code selection seems urgent,
which directly affects the chip design, size and power.
Even with a small sensitivity difference up to 1dB between
RS(255,239) and RS(255,223), it is still critical for the
crucial PR30-Upstream power budget. Otherwise, there could be
no E-FEC discussion at all.
If FEC code is different, budget baseline or 'global average'
should also be different.
At least, we definitely need to choose FEC code, whether
RS(255,239) or RS(255,223).
Best regards,
Hiroshi Hamano
%% Frank Effenberger <feffenberger@HUAWEI.COM>
%% Re: [8023-10GEPON] Revised 10G budget
%% Thu, 18 Oct 2007 10:42:48 -0400
> Dear All,
>
> Regarding the FEC selection - I agree that the FEC aspect is more of a
> target than a fixed value. However, we also can consider that the bare Rx
> sensitivity is a 'soft value'. It depends on a wide range of practical
> concerns, such as yield, cost-effectiveness, technical innovation, etc.
So,
> in the end, all of these numbers are based on our best judgment at the
> present time, integrating over all the variables in our minds.
>
> So, for the purposes of this baseline, I'd like the group to consider
these
> values as a 'global average,' and that they don't individually isolate
each
> element of technical risk. Instead, by averaging, we can reduce the total
> risk since it is unlikely that all the risks will line up against us.
>
> Also keep in mind that we can change them in future, if we really come up
> against a hard problem. The purpose of a baseline is to have a default
> answer that everybody can really concentrate on, and effectively 'try to
> shoot down'. If it survives the onslaught, well then it must be good.
>
> For example, once we get this optical baseline set, the group's work will
> turn towards the study of FEC codes and their realistic *optical* gain.
> That will take some time, and in the end we will get our answer of how
many
> dB's we get. We will likely then need to come back to the optical budget
> and make some small adjustments based on our better understanding.
>
> On the issue of the PR20-D, I raised the maximum output power of the Tx
> primarily to make the overload of the PR20 and PR10 receivers line up.
The
> fact that this loosens the Tx spec seems harmless. If manufacturers want
to
> make their Tx with better controls, then that is fine. But, for purposes
of
> specification, this set of numbers just comes out with fewer 'loose ends'.
>
> If folks want to change that back to a 3dB range, I would not object too
> much. However, (in the spreadsheet) we will have to modify the Rx
overload
> to maintain commonality between the PR10 and PR20 classes of ONU (which I
do
> want to maintain). Alternatively, we can decrease the minimum path loss
in
> the PR20 case by 1dB, which would also bring things in line.
>
> Sincerely,
> Frank Effenberger
>
>
> -----Original Message-----
> From: Motoyuki TAKIZAWA [mailto:mtaki@ACCESS.FUJITSU.COM]
> Sent: Thursday, October 18, 2007 7:15 AM
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: Re: [8023-10GEPON] Revised 10G budget
>
> Dear Frank,
>
> Thank you for the modification.
> On the whole, it seems very sensible proposal except for some
> items such as FEC selection etc.
> Some questions on the PR20-D;
>
> Could you explain why you've widened the launch power range from
> 3dB to 4dB only for PR20-D?
> I just guess the reason like the following assumption.
> - Margin
> If we assume a cooled EML, 3dB would be safe enough.
> Or maybe is it a margin for additional SOA variation?
> - uncooled EML
> Since EML+AMP is supposed to be the PR20-D basic transmitter,
> EDFA output stabilization feedback can be utilized to reduce
> variation range.
> It is not clear whether 4dB range is sufficient or not for
> an uncooled-EML with SOA. And I am not sure the combination
> of cooled SOA and uncooled EML makes sense.
>
> Having 4dB range will be more comfortable but if there's no
> special intention for that, 3dB range in line with other classes
> may make sense.
>
>
> Best regards,
> Motoyuki Takizawa
>
>
> On Mon, 8 Oct 2007 16:47:43 -0400
> Frank Effenberger <feffenberger@HUAWEI.COM> wrote:
>
> > Dear All,
> >
> >
> >
> > I have taken some of the comments I received on my last Email, and
> modified
> > the slides to come to the attached version.
> >
> >
> >
> > What I¨ve done is:
> >
> > 1. Reduce the PR10 OLT downstream transmitter Max and Min by 1 dB.
> > (This reverts to the values presented in Takizawa¨s slides in
September)
> > 2. Reduce the PR10 ONU Rx overload number by 1 dB. (Following the Tx
> > change)
> > 3. Increate the PR20 OLT max power by 1 dB (Makes the Tx range 4 dB,
> > which is more comfortable)
> > 4. Increase the PR20 ONU Rx overload number by 1 dB. (Following the Tx
> > change)
> >
> >
> >
> > Taken together, these changes then make the PR10 and PR20 ONUs identical
> in
> > every respect. One less PMD!
> >
> > This is re-capped on the last slide.
> >
> >
> >
> > Sincerely,
> >
> > Dr. Frank J. Effenberger 献声針 娃繋鴬鯉
> >
> > Huawei Technologies USA
> >
> > 1700 Alma Drive, Plano TX 75075
> >
> > Office (732) 625 3002
> >
> > Cell (908) 670 3889
>
>
---
---------------------------------------------
HIROSHI HAMANO Network Systems Labs.
FUJITSU Labs. Ltd., Kawasaki, 211-8588 JAPAN
TEL: +81-44-754-2641 FAX: +81-44-754-2640
E-mail: hhlsi@flab.fujitsu.co.jp
---------------------------------------------