Re: [8023-10GEPON] Define TDP values
Dear Hamano-san and all,
Basically, I would like to support Hamano-san's proposal as well.
And I was using that value to confirm the possible dual-rate receiver
technology in my power budget proposal for PRX30.
http://www.ieee802.org/3/10GEPON_study/email/msg00887.html
Best regards,
Ken-Ichi
At 2007/12/20 8:50 Toshiaki Mukojima wrote:
> Dear Hamano-san and All,
>
> I supprot your proposed TDP values (3av_07711_hamano_1.pdf).
>
> Sincerely yours,
> Toshiaki Mukojima
>
>
> Sincerely yours,
> ----- Original Message ----- From: "Hiroshi Hamano"
> <hamano.hiroshi@JP.FUJITSU.COM>
> To: <STDS-802-3-10GEPON@LISTSERV.IEEE.ORG>
> Sent: Wednesday, December 19, 2007 3:04 PM
> Subject: Re: [8023-10GEPON] Define TDP values
>
>
>> Dear Sirs,
>>
>> Thank you for all of your discussions and comments for
>> TDP definitions and values.
>> Since there seems to be no strong arguments so far,
>> I made comments on Draft1.0 yesterday to take the TDP values,
>> described in the presentation 3av_0711_hamano_1.pdf,
>> as a baseline proposal.
>> But still I would like to hear more opinions if there will be,
>> until next Portland meeting.
>> Further discussions, comments, and suggestions will be highly
>> appreciated.
>>
>> Best regards,
>> Hiroshi Hamano
>>
>> %% Runjian Lin <rujianlin@hotmail.com>
>> %% RE: [8023-10GEPON] Define TDP values
>> %% Mon, 17 Dec 2007 20:03:14 +0000
>>
>>>
>>>
>>> Dear All,
>>>
>>> Hi, This is Rujian Lin from Shanghai Luster Teraband Photonics. I
>>> have read through all the discussions taken on the web during the
>>> past two weeks with interest.
>>> To clarify the TDP definition and values for IEEE802.3av draft,
>>> the discussions have focuses on whether to separate TDP into TP
>>> (transmitter penalty) and DP( dispersion penalty) or not. In physical
>>> principle there are a lot of factors in the optical transmitter,
>>> optical fiber link and optical receiver degrading the eye opening at
>>> optical receiver output. The degradation factors include driving
>>> waveform to laser, laser step response, optical delay, laser
>>> line-width, chirp, relative intensity noise, laser resonant
>>> phenomenon ( at the transmitter side), fiber chromatic dispersion,
>>> PMD, optical reflection (in the fiber link), thermal noise, shot
>>> noise, baseline wander, timing jitter (at the receiver side) and so
>>> on. It is possible to separate TP and fiber dispersion related
>>> penalty, but as to the factors causing the transmitter penalty, the
>>> wavelength related properties, such as laser spectral width and
>>> chirp, interacting with fiber dispersion will cause some amount of eye !
>> clo
>>> sure at receiver output. This kind of penalty in receiver
>>> sensitivity can be considered as a part of TP or a part of DP. This
>>> is an option for the standard developer to take.
>>> For easier measurement, I agree with Dr. Hiroshi Hamano, Dr. Frank
>>> Efferberger and Dr. Pete Anslow on that it is better to take TDP as a
>>> parameter and not to split it into two parameters, even for the
>>> mathematic calculation on the Spreadsheet TP and DP could be dealt as
>>> two parameters which are calculated separately first and then added
>>> together to be TDP.
>>> In measurement on TDP, it is important, but difficult to define an
>>> ideal transmitter which in theoretic concept is a transmitter with
>>> perfect driving waveform, perfect laser response, no optical delay,
>>> minimum line-width, no chirp and minimum relative intensity noise,
>>> because
>>> TDP = Receiver sensitivity in the case of test Tx with the worst
>>> fiber link,
>>> Receiver sensitivity in the case of ideal Tx with pure attenuation
>>> (without fiber chromatic dispersion, PMD and optical reflection)
>>> So I think that in the Draft we need to set up a definition on ideal
>>> Tx for TDP test.
>>> For the TDP values I think that the data proposed by Dr. Hiroshi
>>> Hamano- 1.5dB for 1574-1580nm downstream and 3.0dB for 1260-1360nm
>>> upstream- is reasonable and a good start point for further
>>> investigation.
>>>
>>> Best regards
>>>
>>> Rujian Lin
>>> Shanghai Luster Teraband Photonics Co., Ltd, China
>>> Tel: 86 21 56332287
>>> Fax: 86 21 56332269
>>> Email: rujianlin@hotmail.com
>>>
>>> Date: Thu, 6 Dec 2007 21:08:44 +0900
>>> From: hamano.hiroshi@JP.FUJITSU.COM
>>> Subject: Re: [8023-10GEPON] Define TDP values
>>> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
>>>
>>> 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 m e
>>> 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?ds 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: tere?-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,
>>> >
>>> > Tha nk 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 w aveform 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 num ber 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 T P 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>
>> &g t; > %% 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
>>> & gt; > 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 R > > x, 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
>>> &g t; >
>>> > >
>>> > >
>>> > > 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. W hat 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
>>> > > nee d:
>>> > >
>>> > >
>>> > >
>>> > > 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_penalt > > y <= 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
>>> pen > > alty.
>>> > > 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 p ut 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 > > IE EE
>>> > > 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
>>> > >< BR>> > > _____________________________________________
>>> > > 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.
>>> > >< BR>> > > 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 int o 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
>> &g t; > >
>>> > > > > > 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
>>> > >
>>> > > > > > re ference 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.
>>> > >
>>> > > > > &g t;
>>> > >
>>> > > > > > 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
>>> > >
>>> > > > > > *Dispersi on_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
>> -----------------------------------------
>
>
>
--
Ken-Ichi Suzuki
NTT Access Network Service Systems Labs.
E-mail:kenyichi@ansl.ntt.co.jp
Tel:+81-43-211-3189/Fax:+81-43-211-8250