Maurice Reintjes
MindspeedTM
Hillsboro, Oregon,USA
Office Phone (503)-403-5370
Mobile (503)-701-0797
Frank Effenberger <feffenberger@HUAWEI.COM>
10/23/2007 07:15 AM
Please respond to
Frank Effenberger <feffenberger@HUAWEI.COM>
To
STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
cc
Subject
Re: [8023-10GEPON] Revised 10G budget
All,
Regarding the PIN sensitivity, the budget as presented assumed a non-FEC
sensitivity of -16 dBm. This is already a very conservative value.
We have seen contributions regarding the fact that PIN sensitivities
even today are considerably better than this - there are large margins
for manufacturing imperfections already included in the -16 dBm number.
Therefore, I question reducing the PIN sensitivity any further.
Sincerely,
Frank E.
-----Original Message-----
From: Hajduczenia, Marek [mailto:marek.hajduczenia@NSN.COM]
Sent: Tuesday, October 23, 2007 3:46 AM
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Revised 10G budget
Dear Mukojima-san,
Thank You for the answer. I think we are making progress here.
Frank, do You have any comments on these numbers ?
BR
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: ext Toshiaki Mukojima [mailto:mukoujima380@oki.com]
Sent: terça-feira, 23 de Outubro de 2007 8:44
To: Hajduczenia, Marek; STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Revised 10G budget
Dear Marek-san
I think there is a possibility of increasing 1dB Tx output to save one
PMD.
(to make same overload value for PR10 and PR20)
Best Regards,
Toshiaki Mukojima
Oki Electric Industry Co., Ltd.
----- Original Message -----
From: "Hajduczenia, Marek" <marek.hajduczenia@NSN.COM>
To: <STDS-802-3-10GEPON@LISTSERV.IEEE.ORG>
Sent: Tuesday, October 23, 2007 3:47 PM
Subject: Re: [8023-10GEPON] Revised 10G budget
> Dear Mukojima-san,
> I would like to ask You only one question - is there any possibility
of
> uniforming the ONU Rx overload value to make PR10 and PR20 ONU Rx
exactly
> the same ? That would save us one PMD ... And from what I see, the
rest is
> exactly the same.
> Best wishes
>
> 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: ext 蜷大ウカ縲?菫頑・ [mailto:mukoujima380@OKI.COM]
> Sent: terテァa-feira, 23 de Outubro de 2007 0:58
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: Re: [8023-10GEPON] Revised 10G budget
>
> Dear Dr.Frank and All,
>
> This is Mukojima of Oki Electric.
> Thank you for great work regarding 10G Power Budget specification.
> I support U/S Power Budget table(PR10/20/30-U) and D/S PR30
of your
> proposal(8 oct 2007 version).
> (I consider based on E-FEC(RS(255,223) for all classes budget
to decrease
> load of optical component)
>
> Regarding PR10-D/PR20-D, I propose new Tx/Rx value for cost
effective ONU
> as follows.
>
> If considering mass volume production of optical transceiver, the
yield
> may
> be improved when both RX(PIN)
> sensitivity and TX launch power are increased by 1dB because of enough
> margin of RX sensitivity.
> In this case, high power TX may increases the cost of OLT transceiver
a
> little but, we believe that this is the
> most cost effective solution when total cost of optics is taken
into
> account.
>
> -PR10-D
> OLT Tx max/min(dBm) = +5/+2
> ONU Sensitivity(dBm) = -19
> ONU Rx Technology = PIN w/E-FEC(RS(255,223))
> ONU Rx Overload(dBm)= 0
>
> -PR20-D
> OLT Tx max/min(dBm) = +9/+6
> ONU Sensitivity(dBm) = -19
> ONU Rx Technology = PIN w/E-FEC(RS(255,223))
> ONU Rx Overload(dBm)= -1
>
> Best Regards,
>
> Toshiaki mukojima
> Oki Electric Industry Co., Ltd.
>
> ----- Original Message -----
> From: "Frank Effenberger" <feffenberger@HUAWEI.COM>
> To: <STDS-802-3-10GEPON@LISTSERV.IEEE.ORG>
> Sent: Tuesday, October 23, 2007 1:46 AM
> 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
>> ---------------------------------------------