Re: [8023-10GEPON] Define TDP values
I thought it might be helpful if I added some comments about TDP and budgeting, as someone who was heavily involved in these issues in Clause 52. Apologies that I'm not referring to the 10GEPON spreadsheet, as I haven't kept up with it's changes.
In addition to the factors listed below quoted from an earlier E-mail the following Tx parameters also have an influence on TDP. Center wavelength, rise time of Tx, Jitter and DCD of the transmitter. Of course the fiber dispersion minimum and slope also affect the result.
> > From the research that I have found so far, three values that have
> > an influence on the TDP value are the laser spectral width, RIN and
> > link distance. A narrower laser spectral width or lower RIN value
> > will trend toward lowering the TDP value, while a longer link will
increase the TDP.
Also from a different earlier E-mail. It is dangerous to say "TDP = TP + DP" as a mathematical equation as the effects are non-linear particularly for large TDP. The effect of some noise (eg RIN) on an open eye (ie measured with little DP) is smaller than on the closed eye. In general TDP >= TP + DP. The IEEE spreadsheets for clauses 52 takes this into account.
Also from yet a different E-mail. It is also somewhat dangerous to say "Tx_OMA_min = Channel_loss + Stressed_Rx_sensitivity_OMA." This is true if the "Stressed_RX_sensitivity_OMA" truly includes all the possible degradations. In practice however the "Stressed_RX_sensitivity_OMA" test may be somewhat simplified (eg doesn't have worst case base-line wander). A "small margin" was included in Clause 52 for these other effects that are not included in the "Stressed_RX_sensitivity_OMA" test.
There is a major benefit to using TDP rather than trying to split it into a path penalty and a Tx penalty. (besides the problem of the difficulty of the mathematical inequality). If the path penalty is a separate item it must be based on a worst case Tx with worst wavelength, spectral width, and chirp. A real Tx probably won't have these and therefore will have more margin for other degradations. Also chirp is not well handled in the spreadsheet. TDP measures it's effect directly, rather than relying on the spreadsheet calculations.
My opinion is that the clause 52 spreadsheet, though complicated, is a good tool to investigate the effect of various system impairments etc. and can be used to estimate what TDP can be. (and if you only know the unstressed sensitivity is to estimate the stressed sensitivity). It also is useful to determine what the standardized "Stressed_RX_sensitivity_OMA" test signal should be that is equivalent to the worst case Tx with the worst case fiber. It is not part of the standard however and with the proper use of TDP it isn't needed for checking link closure, other than to assist with the derivation of the "small margin" discussed above.
The key equation for link closure is
Tx_OMA (min) >= Link attenuation + TDP + "small margin" + Stressed_RX_sensitivity_OMA.
Hope this helps and doesn't cause more confusion.
Regards,
Mike Dudek
SMTS Standards & Technology
JDSU
246 South Taylor Ave.
Louisville
CO 80027
Tel 303 530 3189 x7533.
mike.dudek@jdsu.com
-----Original Message-----
From: Hajduczenia, Marek [mailto:marek.hajduczenia@NSN.COM]
Sent: Friday, December 07, 2007 8:22 AM
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Define TDP values
Dear Hao,
I agree with You. If there is a test method to estimate the TDP for the given transceiver and it is used by vendors, asking them to change it to something else (potentially more complex) might not seem like a good idea. If something works, let's not try to fix it.
Do You have any specic values for TDP for downstream since You seem to be focused on the EML case ?
BR
Marek Hajduczenia (141238)
NOKIA SIEMENS Networks S.A. – COO BBA DSLAM R&D
Rua Irmãos Siemens, 1, Ed. 1, Piso 1
Alfragide, 2720-093 Amadora, Portugal
* marek.hajduczenia@nsn.com
(+351.21.416.7472 4+351.21.424.2082
-----Original Message-----
From: Hao Feng [mailto:h.feng@EUDYNA.COM]
Sent: quinta-feira, 6 de Dezembro de 2007 17:45
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Define TDP values
Hello, All
I support not to separate TDP to TP and DP because in the actual test, it
may not be easy to separate TP and DP. We are used to use the total penalty
(TDP) in component and module testing, such as the difference between B-B
Sensitivity & after-transmission sensitivity. We should make a simple spec
so that it is easy to execute in production.
In addition, the dispersion penalty for EML at 20km is much smaller than in
40km case. The good optical waveform is easy to get due to EML driver
performance significantly improved since 2000. Therefore, we should narrow
down the TDP value with EML-based Tx so that power budget has less pressure.
Regards
Hao Feng
Eudyna Devices
-----Original Message-----
From: Hiroshi Hamano [mailto:hamano.hiroshi@JP.FUJITSU.COM]
Sent: Thursday, December 06, 2007 4:09 AM
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Define TDP values
Dear Sirs,
Thank you very much again for discussing TDP parameters.
I would like to show briefly my opinion.
I think this discussion goal is to define the TDP specification number for
the IEEE 10GE-PON standard. Discussions seem to be made on the Spreadsheet
definitions about dispersion penalties and Pass/Fail conditions accordingly.
But I am not sure, the whole discussions, we have done so far, are going
toward this TDP specification goal.
Separating the TDP into TP and DP in the Spreadsheet seems to me only going
back to ITU-T formalism, if there will be only DP discussions and no TP
considerations.
If ITU-T formalism is OK, it may be simple because the major parameters have
already been fixed in 3av_0711_effenberger_1.pdf. But I think we should
keep the IEEE procedure.
If someone intends to divide the TDP specification itself into DP and TP
specifications in IEEE standard, I do not think it is a good idea, either.
That only leads confusion to component and transceiver suppliers, who are
accustomed to current 10G transceiver productions. Besides, the suppliers
definitely require production margins for both specification numbers
independently, which may destroy Power Budget.
I quite agree with Dr. Effenberger's comment;
> Now: if people want to break up the TDP into "transmitter penalty" and
> "Dispersion penalty" (which is very close to the optical path
> penalty), then fine. This is, in fact, practically the ITU way of
> doing things. But, I thought that the IEEE method was somewhat better for
low-cost reasons.
Apparently, if the TDP specification number is big and loose,
Interoperability and even Power Budget itself will be in danger. If the TDP
specification is too tight, yield problem will heavily result in higher
transmitter cost.
When we decided the Power Budget in ITU-T formalism, I believe that we
counted all the parameters inside the numbers, such as, worst-case
dispersion penalties and also transmitter features. Indeed, my colleague
transmitter experts, who have a number of XFP production experience and TDP
measurement results, carefully made the TDP specification numbers
simultaneously. (My TDP number suggestions have initially appeared in
3av_0707_hamano_1.pdf, along with the Power Budget table in
3av_0707_takizawa_1.pdf.) Maybe it is not always every inch perfect, but
they think the number is most likely to be consistent with the Power Budget
and also with their production feasibility which, they think, most other
suppliers may also agree.
If the Spreadsheet provides us the appropriate TDP specification number, I
want happily to welcome the result. But if it does not, I would rather put
it on component and transceiver suppliers' responsibility.
Best regards,
Hiroshi Hamano
%% "Hajduczenia, Marek" <marek.hajduczenia@NSN.COM> %% Re: [8023-10GEPON]
Define TDP values %% Tue, 4 Dec 2007 16:01:22 -0000
> Dear Hamano-san,
> In a nutshell, do You suggest that we should leave the TDP parameter as a
standalone value and remove the optical path penalty altogether ? Your
conclusions seem to indicate that ...
> In that case, we would still need to make sure that our path dispersion
penalty estimation is smaller than some fraction of the TDP parameter and
not knowing how much the TP /or DP/ component is, such comparison is
pointless.
> Perhaps we should be looking at other test conditions for the power budget
?
>
> Marek Hajduczenia (141238)
> NOKIA SIEMENS Networks S.A. - COO BBA DSLAM R&D Rua Irm竢s Siemens, 1,
> Ed. 1, Piso 1 Alfragide, 2720-093 Amadora, Portugal
> * marek.hajduczenia@nsn.com
> (+351.21.416.7472 4+351.21.424.2082
>
> -----Original Message-----
> From: Hiroshi Hamano [mailto:hamano.hiroshi@JP.FUJITSU.COM]
> Sent: ter艨-feira, 4 de Dezembro de 2007 14:08
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: Re: [8023-10GEPON] Define TDP values
>
> Dear Sirs,
>
> Thank you all for discussing and clarifying TDP definitions.
> I would like to explain some backgrounds of my TDP data in the
> material 3av_0711_hamano_1.pdf. I hope this will not make you all more
confused.
>
> [Dr. Maricondo]
> > From the research that I have found so far, three values that have
> > an influence on the TDP value are the laser spectral width, RIN and
> > link distance. A narrower laser spectral width or lower RIN value
> > will trend toward lowering the TDP value, while a longer link will
increase the TDP.
>
> 10G DML, Direct-Modulated DFB Laser is supposed to be used as a 10G
> upstream transmitter in 10GE-PON ONU, and I think this transmitter
> will be the most controversial for TDP.
> 10G DML suffers an output waveform distortion by its own resonant
> frequency, as I have shown the example waveform in the material
3av_0705_hamano_2.pdf.
> Even after the receiver equalizing filter, it still remains resulting
> eye closure penalty, thus a large portion of TDP.
> The resonant frequency also causes a dynamic chirp, but the dispersion
> penalty may not be dominant, because of the near zero-dispersion
wavelength.
>
> [Dr. Maricondo]
> > I also think that if the 802.3av taskforce uses ITU, Fiber Channel,
> > other standards, etc, then these values and standards should be
> > documented within the draft. Let me be clear, I am not opposed to
> > using other standards as a reference, but it would be a help to the
> > reader of the 802.3av standard in the future to understand where
> > values have come from; I believe that the references can be placed in
the draft as informative notes.
>
> My TDP number suggestion in 3av_0711_hamano_1.pdf is based on some
> amount of current 10G transceiver measurement results and performance,
> such as XFPs, adding some expectations and assumptions by optics and
transceiver experts.
> It does not refer to any other IEEE or ITU-T standards. Because the
> crucial power budget of PR30 allows no big margins for transmitters,
> TDP number may not be discussed in such a simple manner of only referring
other standards.
> The TDP table in my material shows some other standards, 802.3ae, but
> they appear there only to be contrasted with, not to be referred to.
> I apologize if my TDP table makes you confused.
>
> [Dr. Maricondo]
> > In the absence of hard TDP data, I think that this will allow the
> > user to put in a transmitter penalty value, while other users who
> > might think that the TP is overkill can put in a value of zero.
> [Dr. Anslow]
> > If the group wants to call out the two components of TDP separately then
we need:
> > ....
>
> Even though a new high-power 10G DML development is necessary for
> 10GE-PON, component and transceiver suppliers have some TDP production
> data of current 10G transceivers, measured in the manner defined in
> 802.3ae standard, and from that data, 10GE-PON standard assumption can be
derived.
> I am not sure that TP and DP can be clearly separated when they have
> some relationship with each other.
> I am not sure either, that there is such TP production data alone,
> apart from TDP, when the TP should be after all user input number.
>
> Best regards
> Hiroshi Hamano
>
> %% Frank Effenberger <feffenberger@HUAWEI.COM> %% Re: [8023-10GEPON]
> Define TDP values %% Mon, 3 Dec 2007 13:29:30 -0500
>
> >
> > Dear Discussing parties:
> >
> >
> >
> > I would submit that all of this is a huge confusion - and before we
> > change the spreadsheet, I want to make sure that we all are in
> > complete agreement on the definition of terms, and what use they are.
> >
> >
> >
> > For the spreadsheet as it is: we have presented how this spreadsheet
> > and the budget calculations are supposed to work. While there are
> > lots of things in that spreadsheet, the only thing that matters is
> > this: Tx_OMA_min = Channel_loss + Stressed_Rx_sensitivity_OMA.
> >
> > For example, if we launch at +5, and the channel loss is 15, then the
> > stressed sensitivity is -10. This is the simplest budget calculation
> > possible.
> >
> >
> >
> > I believe that the definitions of Tx_OMA_min and channel loss are
> > self-evident.
> >
> > As for the meaning of "stressed RX sensitivity", this is the
> > sensitivity that I would measure with a worst case Rx, worst case
> > Tx, and worst case optical path.
> >
> >
> >
> > So, to the definition of TDP. The value of TDP given here is the
> > difference between the stressed sensitivity (above) and the "ideal
sensitivity".
> >
> > The ideal sensitivity is already in the spreadsheet, named simply
> > "sensitivity".
> >
> > This "ideal sensitivity" is what I would measure with a worst case
> > Rx, but a best case Tx (perfect pulses) and a best case optical path
> > (that is, an attenuator!).
> >
> > Note that a perfect Tx is expressed in terms of OMA, so the ER
> > penalty *is* captured.
> >
> >
> >
> > Currently, TDP is manually entered, and the ideal sensitivity is
calculated
> > to fit. If people want to reverse that, and enter the ideal
sensitivity
> > and calculate the TDP, well, go ahead - it will make no difference
> > at the end of the day.
> >
> >
> >
> > As for what TDP does for us, it is primarily a means of controlling
> > the transmitter imperfections, some of which are 'stand-alone' (like
> > waveform imperfections), and some of which are interactions with the
optical path.
> > The IEEE idea is that we throw all of it into a common bucket, and
> > let the Tx builder optimize his heart out.
> >
> >
> >
> > In contrast, the ITU way keeps them separate. The ITU specifies an
> > optical path penalty, and the "transmitter penalty" is folded into
> > the ITU concept of Rx_sensitivity. The ITU Rx Sensitivity is
> > measured with a worst cast Tx but a best case optical path (i.e., an
> > attenuator). So, it's all there, just re-arranged.
> >
> >
> >
> > In summary, the following table of definitions can be stated:
> >
> > IEEE sensitivity = best-case Tx + best-case path + worst-case Rx
> >
> > ITU sensitivity = worst-case Tx + best-case path + worst-case Rx
> >
> > IEEE stress sens. = worst-case Tx + worst-case path + worst-case Rx
> >
> >
> >
> > Now: if people want to break up the TDP into "transmitter penalty"
> > and "Dispersion penalty" (which is very close to the optical path
> > penalty), then fine. This is, in fact, practically the ITU way of
> > doing things. But, I thought that the IEEE method was somewhat better
for low-cost reasons.
> >
> >
> >
> > Sincerely,
> >
> > Frank Effenberger
> >
> >
> >
> >
> >
> > _____
> >
> > From: Ken Maricondo [mailto:mariconk@GMAIL.COM]
> > Sent: Monday, December 03, 2007 10:39 AM
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] Define TDP values
> >
> >
> >
> > Pete,
> >
> >
> >
> > I think that there is some misunderstanding. I do not disagree with
> > your earlier response to the definition of
> > Transmitter_+_Dispersion_Penalty (TDP), nor am I opposed to having
> > clear definitions of each value in the standard and spreadsheet; but
what I was suggesting was a compromise in the
> > absence of hard data for the TDP. As I understand propose of the
current
> > spreadsheet, the spreadsheet is designed to show a worse case
> > scenario, not every minute value and calculation.
> >
> > In response to your current thread, what you have pointing out is a
> > more refined definition of the TDP value which is not part of the
> > scope of the 802.3av task force, as I understand it. What I have
personally done is
> > modify the spreadsheet to include the values that I feel are pertinent.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Ken
> >
> >
> >
> > On Dec 3, 2007 4:11 AM, Pete Anslow <pja@nortel.com> wrote:
> >
> > Ken,
> >
> >
> >
> > The equation you propose for row 53 still does not make sense. TDP
> > and ITU_Optical_Path_Penalty are not equivalent measures since TDP
> > includes the non-ideality of the transmitter waveform and
> > ITU_Optical_Path_Penalty does not.
> >
> >
> >
> > If the group wants to call out the two components of TDP separately
> > then we
> > need:
> >
> >
> >
> > A user input cell for Maximum Transmitter Penalty TP (penalty due to
> > non-ideal eye shape at the transmitter)
> >
> > A user input cell for Maximum Dispersion Penalty DP (further penalty
> > caused by the link dispersion)
> >
> > A calculated cell for Maximum TDP (TDP = TP + DP)
> >
> > A cell which calculates the actual dispersion penalty (which is
> > already
> > there)
> >
> >
> >
> > I think that it would probably be a good idea to remove the
> > reference to ITU_Optical_Path_Penalty from the DP row as it seems to
> > cause confusion rather than help.
> >
> >
> >
> > The test in row 53 would then become Is Calculated_dispersion_penalty <=
DP?
> >
> >
> >
> > We have no way of calculating an estimate of TP, so there is no way
> > to make this test involve TDP rather than DP alone.
> >
> >
> >
> > As discussed earlier, if an additional cell for achievable receiver
> > sensitivity was to be introduced then a second test for the overall
> > power budget could be added.
> >
> >
> >
> > Is Min_Tx_Pow - TDP - Max_channel_loss > Rx_Sens?
> >
> >
> >
> > The Min_Tx_Pow and Rx_Sens would be in OMA and Rx_Sens would have to
> > be referred to the sensitivity you would get with an ideal
> > transmitter for this to work.
> >
> >
> >
> > Regards,
> >
> > Pete Anslow
> >
> >
> >
> > Nortel Networks UK Limited, London Rd, Harlow, Essex CM17 9NA, UK
> >
> > External +44 1279 402540 ESN 742 2540
> >
> > Fax +44 1279 402543
> >
> >
> >
> > _____
> >
> > From: Ken Maricondo [mailto: kmaricondo@IEEE.ORG]
> > Sent: 30 November 2007 04:17
> >
> >
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] Define TDP values
> >
> >
> >
> > Dear All,
> >
> >
> >
> > Thank you all for the feedback and clarification. In reviewing all
> > of the recent threads, I think that we all can agree that a penalty is a
penalty.
> > Therefore, I suggest that the spreadsheet be change to reflect the
> > following:
> >
> > 1. Change the TDP cell (A39) to only be TP
> >
> > 2. Change the Transmitter Dispersion Penalty cell (D39) to
> > Transmitter Penalty
> >
> > 3. Change Dispersion_Penalty <= ITU_Optical_Path_Penalty cell
(A53)
> > to Transmitter_+_Dispersion_Penalty <= ITU_Optical_Path_Penalty or
> > TDP <= ITU_Optical_Path_Penalty
> >
> > 4. Change cell (D53) formula to
=IF((B38+B39)<=B30,"PASSED","FAILED")
> >
> >
> >
> >
> > In the absence of hard TDP data, I think that this will allow the
> > user to put in a transmitter penalty value, while other users who
> > might think that the TP is overkill can put in a value of zero. At
> > a later date and when TDP data is available, I think that we can
> > readdress this issue. What do you think?
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Ken Maricondo
> >
> >
> >
> >
> >
> > On Nov 29, 2007 3:10 PM, Frank Chang <ychang@vitesse.com> wrote:
> >
> > Hi Pete;
> >
> >
> >
> > I am very happy you chime in to clarify the confusion which exists
> > for a while in the email thread and also associated mtg discussions
> > so far. I also feel the term "TDP" or even "stress RX sens" was
> > misinterpreted in link budget formalism, which is quite inconsistent
> > with what is defined in IEEE
> > 802.3 for the TP2 and TP3 methodology.
> >
> >
> >
> > FYI- In line with what you said, actually I provided a tutorial to
> > elaborate this during July mtg as follows:
> >
> > http://www.ieee802.org/3/av/public/2007_07/3av_0707_chang_1.pdf
> >
> >
> >
> > Best Regards
> >
> > Frank C.
> >
> > -----Original Message-----
> > From: Pete Anslow [mailto: pja@nortel.com <mailto:pja@nortel.com> ]
> > Sent: Thursday, November 29, 2007 3:13 AM
> > To: STDS-802-3-10GEPON@listserv.ieee.org
> > Subject: Re: [8023-10GEPON] Define TDP values
> >
> > Hi,
> >
> > The way the term " TDP" is being discussed in this thread seems to
> > me to be inconsistent with the way it is defined in IEEE 802.3.
> >
> > TDP stands for Transmitter and Dispersion Penalty. It is the penalty
due
> > to the combination of the eye closure of the transmitter and the
> > further eye closure caused by the link dispersion.
> >
> > The TDP measurement procedure for 1000Base PX10 and PX20 is defined
> > in subclause 58.7.9 . The sensitivity of the reference receiver is
> > measured with as near an ideal test transmitter as possible and then
> > this is corrected for any residual transmitter eye closure to give
> > the sensitivity with an ideal transmitter S. Then the receiver
> > sensitivity is measured again using the transmitter under test through
the worst case dispersion .
> > T he TDP value is then the difference between the second measurement and
S.
> >
> > If we label the two penalty components as EP for the transmitter Eye
> > Penalty (penalty due to non-ideal eye shape at the transmitter) and
> > DP for the transmi tter Dispersion Penalty (further eye closure
> > caused by the link dispersion ) then we can say:
> >
> > TDP = EP + DP
> >
> > Now, for most ITU-T power budgets Path Penalty is approximately
> > equal to DP (and the specified receiver sensitivity has to be met
> > using a transmitter with a worst case EP ).
> >
> > Consequently, Dispersion_Penalty <= ITU_Optical_Path_Penalt y makes
> > reasonable sense.
> >
> > The inequality (Dispersion_Penalty+TDP) <= ITU_Optical_Path_Penalt y
> > makes no sense at all as it is roughly equivalent to saying:
> >
> > DP + (EP + DP) < = DP
> >
> > I agree that Dispersion_Penalty <= ITU_Optical_Path_Penalt y is not
> > sufficient to establish that the power budget is feasible with
> > available optics. As I understand the current spreadsheet, it
> > calculates the receiver sensitivity that would be required given the
> > various input parameters. In order to test for the feasibility of
> > this sensitivity value an additional input cell containing the
> > achievable receiver sensitivity with a n ideal transmitter would be
required.
> >
> > Regards,
> >
> > Pete Anslow
> >
> > Nortel Networks UK Limited, London Rd, Harlow, Essex CM17 9NA, UK
> >
> > External +44 1279 402540 ESN 742 2540
> >
> > Fax +44 1279 402543
> >
> > _____________________________________________
> > From: Hiroshi Hamano [ <mailto:hamano.hiroshi@JP.FUJITSU.COM>
> > mailto:hamano.hiroshi@JP.FUJITSU.COM]
> > Sent: 29 November 2007 02:55
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] Define TDP values
> >
> > Dear Dr. Maricondo,
> >
> > Thank you very much for your explanations, and I apologize for my
> > late reply.
> >
> > Now, I understand that, in your E-mail, (Dispersion_Penalty+TDP)
> > means the dispersion penalty value using a realistic transmitter
> > with worst case TDP, in contrast to that using an ideal or perfect
> > transmitter with small or no TDP.
> >
> > I am not sure, whether (Dispersion_Penalty), in the Spreadsheet, is
> > figured out based on such an ideal transmitter or not, but I agree
> > that the result should indicate the worst case value in order to d
> > ecide the fail/pass condition.
> >
> > But I am not sure either, how TDP should be counted into such
> > transmitter parameters for calculating (Dispersion_Penalty+TDP), in
> > the Spreadsheet, and how big its impact will be. If you have any
> > suggestions, that will be qu ite helpful.
> >
> > If TDP value should be derived from the measurement results, not
> > from Spreadsheet calculations, some penalty value may remain only
> > assumed and uncalculated, unless the relationship between the
> > measured TDP and Dispersion_Penalty is justified.
> >
> > Any comments or discussions will be highly appreciated.
> >
> > Best regards,
> >
> > Hiroshi Hamano
> >
> > %% "Ken Maricondo" <kmaricondo@ieee.org> %% Re: [8023-10GEPON]
> > Define TDP values %% Fri, 23 Nov 2007 17:07:53 -0500
> >
> > >
> >
> > > Dear Hamano-san and Hajduczenia,
> >
> > >
> >
> > > I agree (from all that I have read) that the
> > > ITU_optical_path_penalty
> >
> > > basically includes no transmitter penalty and that receiver
> >
> > > sensitivity value in ITU formalism should share the TDP within the
> >
> > > margin. The rationale as to why I suggested adding the TDP to
> >
> > > *Dispersion_Penalty <=
> >
> > > ITU_Optical_Path_Penalty* is as follows:
> >
> > >
> >
> > > 1. Any penalty such as chirp, extinction ratio, MPN, etc., will
require
> >
> > > that the photodiode receiver to receive an increased proportional
> >
> > > optical receive level in order to maintain the same BER verse a
> > > system
> >
> > > without the same penalties. The *Dispersion_Penalty <=
> >
> > > ITU_Optical_Path_Penalty* from what I can tell assumes an ideal
> >
> > > transmitter and receiver over a given optical path and that only
> > > if
> >
> > > the dispersion penalty exceeds the optical path penalty then the
> > > link
> >
> > > fails. If I use only dispersion penalty in a network calculation
> >
> > > without the TDP, then I am not truly taking into account worse
> >
> > > case/end of life network performance. In my point of view, a
> > > network
> >
> > > designed with a TDP of 3dB for example will have a shorter
> > > operational
> >
> > > lifetime or be performance limited then an identical network with
> > > an
> >
> > > ideal transmitter with no TDP or lower value of TDP. So to
> > > compensate for
> > the TDP a more robust FEC scheme or higher quality receiver might be
> > in order.
> >
> > >
> >
> > > 2. I do not discount or object to the TDP value from being
subtracted
> >
> > > from the *IEEE_Rx_Stressed_Sensitivity_OMA* to get
> > > *IEEE_Rx_Sen_OMA*,
> >
> > > but I think that TDP should show up in the system margin as worse
> >
> > > case/end of life calculation within the spreadsheet. The fact
> > > that
> >
> > > the receiver sensitivity has to go lower to compensate for the TDP
> >
> > > only points out that I have to have a higher quality ideal
> > > receiver at
> > first glance.
> >
> > >
> >
> > > I am acutely aware of the fact that 10GEPON standard will allow
> > > for
> >
> > > degree of flexibility in the network design to compensate for
> > > network
> >
> > > design short comings. My suggestion for *(Dispersion_Penalty+TDP)
> > > <=
> >
> > > ITU_Optical_Path_Penalty* to be changed is to make sure that there
> > > is
> >
> > > no ambiguity in the standard (spreadsheet) and to point out to the
> >
> > > adopter of the 10GEPON standard that *all* penalties have been
> >
> > > accounted for, analyzed and documented. At the end of the day it
> > > is
> >
> > > up to task force as whole to adopt what they feel is appropriate
> > > for the
> > standard.
> >
> > >
> >
> > > Best regards,
> >
> > >
> >
> > > Ken Maricondo
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > On Nov 22, 2007 5:27 AM, Hiroshi Hamano
> >
> > > <hamano.hiroshi@jp.fujitsu.com>
> >
> > > wrote:
> >
> > >
> >
> > > > Dear Dr. Maricondo and Dr. Hajduczenia,
> >
> > > >
> >
> > > > Thank you for your quick response and discussion.
> >
> > > > I am not sure how TDP values have been defined in the previous
> >
> > > > specifications such as IEEE 802.3ae and 802.3ah. If they have
> > > > also
> >
> > > > reflected the vendor data based on the transmitter measurement
> >
> > > > results, vendor feedbacks may be quite important similarly for
> >
> > > > 10GE-PON.
> >
> > > >
> >
> > > > > but should read *(Dispersion_Penalty+TDP) <=
> >
> > > > > ITU_Optical_Path_Penalty* to insure all possible noise and
> >
> > > > > penalties
> >
> > > > are
> >
> > > > > accounted for.
> >
> > > >
> >
> > > > Perhaps, I misunderstand the last sentence of Dr. Maricondo's
E-mail.
> >
> > > > But my understanding is that ITU_optical_path_penalty basically
> >
> > > > includes no transmitter penalty. Receiver sensitivity value in
> > > > ITU
> >
> > > > formalism should share the margin, instead, for possible
> > > > transmitter
> >
> > > > penalty compared to the ideal one.
> >
> > > > Would you please explain again your intension about the sentence??
> >
> > > >
> >
> > > > Best regards,
> >
> > > > Hiroshi Hamano
> >
> > > > Fujitsu Labs. Ltd.
> >
> > > >
> >
> > > > %% "Ken Maricondo" <kmaricondo@ieee.org> %% Re: [8023-10GEPON]
> >
> > > > Define TDP values %% Wed, 21 Nov 2007 19:15:31 -0500
> >
> > > >
> >
> > > > >
> >
> > > > > Dear Hamano-san,
> >
> > > > >
> >
> > > > > Although the TDP is a controversial value to be added to the
> >
> > > > > 10GEPON standard, I have to agree with the previous committee
> > > > > (
> >
> > > > > 802.3ah) for assigning a TDP value; albeit not an apparent
> >
> > > > > benefit, the TDP does set
> >
> > > > a
> >
> > > > > reference value/point for determining transmitter quality
> > > > > which
> >
> > > > > does
> >
> > > > impacts
> >
> > > > > system performance. I agree with your assessment that the
> > > > > lack of
> >
> > > > > high power reference transmitter to make a TDP measurement at
> > > > > this
> >
> > > > > time is a problem. In the absence of such a reference
> >
> > > > > transmitter/s, I think that
> >
> > > > the
> >
> > > > > TDP values you have chosen are a good reference point to start
> >
> > > > > with and
> >
> > > > I
> >
> > > > > support you on this issue.
> >
> > > > >
> >
> > > > > I also think that the spreadsheet should reflect the impact of
> > > > > TDP
> >
> > > > > on
> >
> > > > the
> >
> > > > > systems' overall performance. From what I have been able to
> > determine,
> >
> > > > the
> >
> > > > > TDP value is subtracted from the
> >
> > > > > *IEEE_Rx_Stressed_Sensitivity_OMA* to
> >
> > > > get *
> >
> > > > > IEEE_Rx_Sen_OMA*, which does not readily translate into a
> > > > > system
> >
> > > > performance
> >
> > > > > impact/limitation. The system pass/fail calculation is based
> > > > > on
> >
> > > > > *Dispersion_Penalty <= ITU_Optical_Path_Penalty* only, but
> > > > > should
> >
> > > > > read
> >
> > > > *(Dispersion_Penalty+TDP)
> >
> > > > > <= ITU_Optical_Path_Penalty* to insure all possible noise and
> >
> > > > > penalties
> >
> > > > are
> >
> > > > > accounted for.
> >
> > > > >
> >
> > > > > Best regards,
> >
> > > > >
> >
> > > > > Ken Maricondo
---
-----------------------------------------
Hiroshi Hamano
Network Systems Labs., Fujitsu Labs. Ltd.
Phone:+81-44-754-2641 Fax.+81-44-754-2640
E-mail:hamano.hiroshi@jp.fujitsu.com
-----------------------------------------