Re: [8023-10GEPON] Define TDP values

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

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.

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
>
>
> On Nov 21, 2007 6:34 AM, Hiroshi Hamano <hamano.hiroshi@jp.fujitsu.com >
> wrote:
>
> > Dear Madam and Sirs,
> >
> > I am Hiroshi Hamano, Fujitsu Labs., participating in IEEE 802.3av 10GE-PON
> > Task Force
> > meeting.
> >
> > The Task Force chair has already announced that IEEE 802.3av 10GE-PON
> > Draft 1.0 has
> > approved. You can find it in the IEEE task force Web site.
> >
> > http://www.ieee802.org/3/av/index.html
> >
> > But in the specification table in Clause 91, describing PHY layer, several
> > columns
> > still remain as TBD, and continuous efforts are necessary to fill them up.
> >
> > Transmitter and Dispersion Penalty, TDP, is one of such parameters which
> > defines
> > transmitter features. To determine the parameter, it seems that the
> > spread sheet
> > tool does not fully describe the parameter and it should be defined
> > reflecting
> > the transmitter production results.
> >
> > I have submitted a presentation material 3av_0711_hamano_1.pdf about TDP
> > numbers,
> > which may be used in the table, estimated from the current 10G transmitter
> > production
> > results. They are 1.5dB for Downstream EML, in OLT and 3.0dB for Upstream
> > DML in ONU.
> >
> > http://www.ieee802.org/3/av/public/2007_11/3av_0711_hamano_1.pdf
> >
> > Some system vendor engineers support my TDP numbers, but I would like to
> > ask more
> > opinions widely for TDP specification and numbers to be adopted for
> > 10GE-PON standard.
> > Especially opinions from optics experts and transceiver manufacturers are
> > highly
> > appreciated.
> >
> > To overcome PR30; 29dB channel insertion loss, a high-power transmitter
> > should be
> > deployed. But such a high-power uncooled DML for Upstream, with minimum
> > output power
> > of +4dBm, does not exist yet and may take years to be developed for
> > mass-production,
> > and its performance estimation is not easy today. But I believe that at
> > least equal
> > or better TDP feature, than current 10G DML with up to 0dBm power, should
> > be available
> > to achieve the PR30 crucial power budget.
> >
> > If you agree my TDP numbers, would you please show your approval for my
> > material??
> > If you have any other suggestion, not only for numbers, but for
> > definitions or
> > procedures, would you please show your preference??
> > Since the draft comment deadline is settled 17. Dec., I would like to have
> > your
> > quick response by the end of November.
> > Thank you in advance for your kind cooperation.
> >
> > Best regards,
> > Hiroshi Hamano
> > Fujitsu Labs. Ltd.
> >
> > %% Glen Kramer < glen.kramer@TEKNOVUS.COM>
> > %% [8023-10GEPON] November 2007 meeting report
> > %% Fri, 16 Nov 2007 22:24:10 -0800
> >
> > > Dear Colleagues,
> > >
> > > All November meeting materials have been updated and uploaded to the
> > web. Please see http://www.ieee802.org/3/av/public/2007_11/index.html .
> > >
> > > Below is a short overview of the main achievements.
> > >
> > > 1) We accepted several important baseline proposals (refer to minutes in
> > http://www.ieee802.org/3/av/public/2007_11/3av_0711_minutes_unapproved.pdf
> > )
> > > a) Adopted power budgets (see Motion 3)
> > > b) Selected remaining wavelength bands (see Motion 4)
> > > c) Selected FEC based on RS(255,223,8) (see Motion 7)
> > > d) Adopted MPCP-based handshake to allow adjustable laser on/off
> > times (see Motion 10)
> > >
> > > 2) We approved the updated version (v2.1) of our Link Model spreadsheet
> > (see Motion 9). The spreadsheet is located at
> > http://www.ieee802.org/3/av/public/tools/3av_0711_linkmodel_v2_1.xls.
> > >
> > > 3) We adopted power budget and PMD names (see Motions 5 and 6)
> > > 4) We approved draft 1.0 (!)(see Motion 11)
> > > 5) We approved project timeline (see Motion 12)
> > >
> > > As a group exercise, on Thursday the task force has spent several hours
> > commenting on draft 1.0 and resolving submitted comments. A total of 6
> > comments were submitted and reviewed. Reports on proposed responses and on
> > accepted responses are published here:
> > >
> > >
> > http://www.ieee802.org/3/av/public/2007_11/3av_0711_responses_proposed.pdf
> > >
> > http://www.ieee802.org/3/av/public/2007_11/3av_0711_responses_accepted.pdf
> > >
> > > These changes will be incorporated in draft 1.1 after the January
> > meeting. The editors continue to accept comments against D1.0 . Comment
> > submission period ends December 17th, 2007 (a separate e-mail on this will
> > follow).
> > >
> > > The following action items were identified for the January meeting:
> > >
> > > 1) Burst mode timing study (AGC, CDR) (contact Haim Ben-Amram)
> > > 2) Define TDP values (contact Hiroshi Hamano)
> > > 3) Jitter Budgets Reference Model (contact Vijay Pathak)
> > > 4) PRX30 Upstream power budget (contact Marek Hajduczenia)
> > > 5) Synchronization FSM (contact Frank Effenberger)
> > > 6) BER monitoring (contact Jeff Mandin)
> > > 7) Link fault Signaling (contact Jeff Mandin)
> > > 8) PCS diagnostic modes (contact Jeff Mandin)
> > > 9) Coexistence clause/annex (model description, layering diagram,
> > dual-rate burst-mode receiver) (ad hoc leader wanted)
> > >
> > > The individuals noted as contacts agreed to coordinate the corresponding
> > ad hoc activities. If you are interested in participating in any of these ad
> > hoc groups, please contact corresponding coordinator.
> > >
> > > I would like to thank all TF members who attended the November meeting
> > and made it a very productive event. Authors, please remember to check the
> > uploaded presentations to make sure that the final (as presented) version
> > was uploaded.
> > >
> > >
> > >
> > > Thanks you,
> > > Glen Kramer, P802.3av task force chair
> > >
> > >

---
-----------------------------------------
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
-----------------------------------------