Re: [8023-10GEPON] Revised 10G budget
Dear Frank,
Sorry for my too late response.
Thank you for explaining the reason of increasing the PR20 Tx
power. I see what your point is. Then I think the range of 4dB
is acceptable to me.
If someone wants to change it back to a 3dB range, It wouldn't
matter for me.
Best regards,
Motoyuki Takizawa
On Tue, 23 Oct 2007 10:28:54 -0400
Frank Effenberger <feffenberger@HUAWEI.COM> wrote:
> Dear All,
>
> Whether the "FEC gain text" is enacted in a separate motion, or as part of the same motion as the optical baseline, is not a problem for me.
>
> I offered these words as a way to assuage the members who had such concerns. It is my hope that Hamano-san and Takizawa-san can provide us their feedback, so that we can better serve their needs and gain their support.
>
> Sincerely,
> Frank Effenberger
>
> -----Original Message-----
> From: Hajduczenia, Marek [mailto:marek.hajduczenia@NSN.COM]
> Sent: Tuesday, October 23, 2007 2:45 AM
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: 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 Irmaos 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
> ---------------------------------------------
--
Motoyuki Takizawa
Fujitsu Access Ltd. R&D Center