| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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
From: mariconk@gmail.com [mailto:mariconk@gmail.com] On Behalf Of ext Ken Maricondo
Sent: quinta-feira, 29 de Novembro de 2007 5:47
To: Hiroshi Hamano
Cc: STDS-802-3-10GEPON@listserv.ieee.org; Hajduczenia, Marek
Subject: Re: [8023-10GEPON] Define TDP valuesDear Hamano-san and Hajduczenia,
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.
[Marek Hajduczenia] Indeed these observations are correct. That is also the reason why in the DS channel we were assuming utilization of an EML LD with very narrow laser spectral width. We cannot do anything about the link length since that value is "given" to us and the resulting dispersion will affect the signal propagating towards the ONU. In the US channel, since we are in the negative side of the SMF dispersion curve, the dispersion is actually narrowing the bits, thus the dispersion penalty is not critical. Thus DML can be used and should be sufficient to assure proper signal detection at the OLT.The TDP values (as pointed out already) have not been entered into the draft that is currently posted; but the extinction ratio has been entered into the draft (9dB, min for the DS and 6dB, min for the US), but I am not sure of these values.
[Marek Hajduczenia] They are correct. Higher ER for DS channel is again motivated by the prospective application of EMLs, which have high ER by definition. 6 dB for US channel is a compromise allowing for the application of lower grade DMLs.I would like to see an extinction ratio formula in the spreadsheet, such as the one I found in the optical fiber telecommunications IIIB on page 75 (see attached PDF for the formula). The formula takes into account the laser slope efficiency and can allow the user to calculate different values of non-zero values.
[Marek Hajduczenia] If You check the old spreadsheet model, that is what we had and that is what was almost unanimously considered overly complex by the group. Very few people apart from LD manufacturers have the idea about the parameters You refer to. Most system integrators purchase ready components which have specific ER value. End of the story. That is why the spreadsheet is modelled in a specific way to allow for system integrators to use the parameters they know and have available rather than force them to use questionable formulas (there is more than one formula to describe the same parameter and we can argue long which one is more correct) and request technical specifications from component vendors, some of which may be confidential. I like maths and good engineering should not go along without maths but at some point we have to stop otherwise we are risking getting into overly complex models that serve little purpose IMHO.I feel that the use of this formula will not omit the OMA value, but enhance the integrity of the OMA. Just as a point of clarification, the laser spectral width, RIN, and link distance will ultimately have an effect on the IEEE_Rx_Sen_OMA. I will be happy to send you links to OMA and extinction ratio application notes I found so far. I'm not sure if I can post links on this thread.
At this point, I think that a discussion of what should be included in the TDP and the dispersion penalty value is in order. I found a word document that started this task (doc00008, also attached), but did not seem to be completed.
[Marek Hajduczenia] It was merely an indicator which way to go rather than anything official. It was created at the time when we were still not certain how to approach the power budget problem and needed to have a look at the IEEE and ITU formalism. Table based collection of data seemed more readable ...I also think that if the 802.3av taskforce uses ITU, Fiber Channel, other standards,
[Marek Hajduczenia] Call is Ethernet legacy - Ethernet engineering is mainly based on using existing and proven technologies instead of reinventing the wheel. If something works fine, why fix it ? Have a look at 1GE specs and compare them with FibreChannel specs. You might notice a lot of similarities.etc, then these values and standards should be documented within the draft.
[Marek Hajduczenia] I disagree. The appropriate references are included in Clause 1 of 802.3 we are set to extend. There is no point to repeat references since following the IEEE 802.3 policy, references should be collected in a single section, as currently done. Unless that is not what You mean by "documenting the values and standards" ...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;
[Marek Hajduczenia] Again, the purpose of the standard is not explaining how the values are obtained (unless measurement process is defined, and that is what we will set out to do eventually for most critical Rx/Tx parameters - see 1G EPON specs) but providing them. Motivation for particular selection (e.g. why 5 and not 7 etc.) is irrelevant from the point of view of standards and serves no purpose in such documents. When developing standard compliant equipment one is supposed to use the values given (or exceed them if technology allows) and not meditate whether they were obtained for EML or DML. Additionally, the standard does not specify the implementation options - You are free to do whatever You want as long as it stays within the defined boundaries or is better than them.I believe that the references can be placed in the draft as informative notes.
[Marek Hajduczenia] That would need further clarification. We may always include the reference to a specific value provided it is taken directly from another specification, though I wonder what purpose that serves apart from referencing another document? IEEE standards are not interchangable with FibreChannel of ITU-T specs. Please clarify what would be the purpose of cross referencing other specifications in this case.Hajduczenia - can you please clarify how TDP field includes conditional formatting to check the TDP value against ITU_Optical_Path_Penalty under the Version 2.2 section in the Revision notes Tab on the excel spreadsheet 3av_0711_hajduczenia_5 is calculated and where?
[Marek Hajduczenia] Version 2.2 does not exist. Version 2.1 is the last available spreadsheet version ... see http://www.ieee802.org/3/av/public/tools/index.htmlI tried to use the link next to the revision note, but it points me to cell B36 in the Version 2.2 Tab, Dispersion_D_Max. Also (FYI), some of the other link values in the Version 2.1 section are not valid.
[Marek Hajduczenia] Which ones precisely ? I would appreciate exact feedback ...ThanksBest regards,
Ken Maricondo
On Nov 28, 2007 9:55 PM, Hiroshi Hamano <hamano.hiroshi@jp.fujitsu.com> wrote:
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 decide 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 quite 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
%% 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
-----------------------------------------