Re: [8023-10GEPON] Define TDP values
Dear Hamano-san,
I will comment inline as always (marked with <MH> tags)
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: Hiroshi Hamano [mailto:hamano.hiroshi@JP.FUJITSU.COM]
Sent: quinta-feira, 6 de Dezembro de 2007 12:09
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.
<MH>Ineed, it is true though it is hard to specify the value of TDP when there are so many interpretations of this parameters and how it should be used in the model. Before attaching a number to the parameter, we should understand what it stands for, thus the whole discussion.
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.
<MH>IMHO at the end of the day what matters is to keep the parameter values realistic and understand thei meaning. The conversion between ITU and IEEE formalism is feasible - our power budget spreadsheet is a good example of this fact. It is also my opinion that we should avoid slicing the TDP into parts, mainly bacause of added complexity and little added gain. The component vendors will keep on using TDP for evaluation of the equipment and I do not honestly see a point dividing it into separate components.
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.
<MH>Agreed. That is also what I hear from the people in my company with some background in transciever manufacturing designed on IEEE specs.
Besides, the suppliers definitely require production margins for both
specification numbers independently, which may destroy Power Budget.
<MH> IMHO we could potentially make it work with two components but the number of degress of freedom increases which is never a good thing. The fewer the better. If we can keep the TDP intact, let's keep it and only specify the value based on vendor input.
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.
<MH> ... And as always in engineering we have to stick the number somewhere in between. IMHO we could at least establish the boundries by looking at average and best available devices and their specs. We should have then a good idea as to what will become average grade device in 2-3 years from now.
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.
<MH> It does not and it never did. The numbers obtained for TDP from the previous version of the spreadsheet were "massaged" to come inline with was was technically achievable.
But if it does not, I would rather put it on component and
transceiver suppliers' responsibility.
<MH> I personally believe that it is the only reasonable approach, since any attempt to calculate such penalty theoretically will always come ashore when cross-checking the obtained value with real equipment. Let's skip the construction of complicated models leading nowehere and get straight to the point of getting the values from vendor feedback.
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
-----------------------------------------