Re: [8023-10GEPON] Optical Overload Ad-Hoc announcement
Dear Dr. Effenberger,
I understand your discussion that damage threshold for upstream burst-mode
receiver should remain overload+1 and that for downstream CW-mode receiver
may be assigned -3dBm, because it is technically feasible.
But we are discussing the standard, which specifies technical requirements,
not datasheets, which may describe some product feature.
I think we must not define only feasibility in the standard without technical
requirements.
Best regards,
Hiroshi Hamano
%% Frank Effenberger <feffenberger@HUAWEI.COM>
%% Re: [8023-10GEPON] Optical Overload Ad-Hoc announcement
%% Fri, 4 Apr 2008 09:16:20 -0400
> On the issue of damage threshold:
>
> There is a saving grace for us.
>
> In the downstream, which is continuous mode, the receiver circuit can employ
> passive current-limiting designs to obtain quite robust optical capability.
> By placing a load resistor in the bias supply path, excessive current will
> reduce the bias on the diode, which drastically reduces the APD gain, which
> in turn limits the current. This is a well-known technique, and is very low
> cost. It only works in CW mode, but that is ok. So, I think that for the
> downstream (that is, the ONU Rx), we should be able to set the damage
> thresholds to be at 0 dBm (or at least -3 dBm), and it doesn't burden
> anybody.
>
> In the upstream, which is burst mode, the ONU should not transmit in such a
> configuration. So, in the practical case, the operator-users should not
> have a problem. Therefore, we do not need to set the upstream damage
> threshold (that is, the OLT Rx) higher than the "overload+1" level. Since
> the OLT Rx is the 'trouble-spot', I think this compromise should make both
> sides happy.
>
> No?
>
> Sincerely,
> Frank E.
>
> p.s. To make this system bulletproof, we should mandate that the ONU should
> intentionally stop working at above the overload level. In other words, you
> do not get bonus points for making a really high-overload ONU. In fact, you
> might end up burning out the OLT.
>
>
>
> -----Original Message-----
> From: Hiroshi Hamano [mailto:hamano.hiroshi@JP.FUJITSU.COM]
> Sent: Friday, April 04, 2008 6:34 AM
> To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> Subject: Re: [8023-10GEPON] Optical Overload Ad-Hoc announcement
>
> Dear Dr.Jiang,
>
> > I checked the previous EPON standard (802.3-2005), In
> > table 60-5 for 1000Base-PX10, it uses "Average receiver power (max) + 5
> > dB" to define the Damage threshold, and in table 60-8 for 1000Base-PX20,
> > it uses "Average receiver power (max) + 10 dB" to define the damage
> > threshold.
>
> In my understanding about 802.3ah, Damage threshold does not define
> such a vague margin of 5dB or 10dB from the RX average receive power (max),
> but, I believe, it clearly defines to allow the TX-RX direct connection
> without damage, putting the same TX average launch power (max) value
> into the Damage threshold column, as I have already explained several times
> in my former comments and E-mails.
> I am afraid this is not feasible in most of 10GE-PON classes any more,
> with such a high 10GE-PON TX launch power and sensitive RX components.
> It is sort of an objective change of the Damage threshold specification
> from the standard precedents, and now the notification to the reader
> is quite important.
>
> > Typically, a system will
> > require 3- 5dB system margin. Therefore, it will be no system running
> > above "damage threshold - 3 dB/5dB". Define a damage threshold of 0 dBm
> > almost makes the "average receive power of -1 dBm" useless. There is
> > need to have enough buffer to make system and device robust to use, 3 dB
> > is the minimum, and 5 dB is decent. ( Notes, 3dB down means 50% down, 5
> > dB down means 69% down, while 1 dB down means only 80% down). And in
> > fact, the larger, the better. So, I suggest to use 0 dBm as damage
> > threshold for all type of 10G APD receiver, burst receiver or continuous
> > reciever.
>
> I still cannot understand this technically at all that 1dB is not enough
> and 3dB is OK. And even with 0dBm Damage threshold value, it is still
> the 'useless??' RX average receive power (max) + 1dB in some classes, and
> it is impossible to keep consistency having 3dB margin.
> I do not think either that it is always, 'the larger, the better'.
> Component availability and cost effectiveness should also be counted.
> Even 0dBm Damage level for 10G APD burst receiver still seems quite
> challenging.
> I am asking experts but they are not so sure so far if it is feasible or
> not.
> Reliability test is definitely necessary to guarantee such a high power
> Damage level, which requires tremendous time and money.
> Multi-vendor component supply is the key for the cost, and relaxed
> specification
> will make things much easier, if there is no strong technical reason to
> tighten it.
>
> Best regards,
> Hiroshi Hamano
>
> %% Jessica Jiang <jjiang@SALIRA.COM>
> %% Re: [8023-10GEPON] Optical Overload Ad-Hoc announcement
> %% Thu, 3 Apr 2008 20:30:19 -0700
>
> > Hi,
> >
> > I agree with Frank's comments on the damage threshold setting. If we
> > decide to put the damage value, we need to raise the damage threshold
> > for lower power levels (classes PR20 and 30) to at least -3dBm.
> > Consider the disaster consequence, damage threshold should be set as
> > high as possible. I checked the previous EPON standard (802.3-2005), In
> > table 60-5 for 1000Base-PX10, it uses "Average receiver power (max) + 5
> > dB" to define the Damage threshold, and in table 60-8 for 1000Base-PX20,
> > it uses "Average receiver power (max) + 10 dB" to define the damage
> > threshold. I understand that there is technical difficulty to raise the
> > damage threshold above 0 dBm for 10G receiver, so put the damage
> > threshold to 0 dBm is OK, but it is not justified to use that limitation
> > to define damage threshold using "average receiver power (max)+ 1dB" for
> > 10G case. The purpose of putting damage threshold is to post request on
> > components so that the device would be not so vulnerable to be damaged.
> > No system will work near the damage point. Typically, a system will
> > require 3- 5dB system margin. Therefore, it will be no system running
> > above "damage threshold - 3 dB/5dB". Define a damage threshold of 0 dBm
> > almost makes the "average receive power of -1 dBm" useless. There is
> > need to have enough buffer to make system and device robust to use, 3 dB
> > is the minimum, and 5 dB is decent. ( Notes, 3dB down means 50% down, 5
> > dB down means 69% down, while 1 dB down means only 80% down). And in
> > fact, the larger, the better. So, I suggest to use 0 dBm as damage
> > threshold for all type of 10G APD receiver, burst receiver or continuous
> > reciever.
> >
> > I think it make more sense to ask vendor to take challenge of raising
> > damage power in design than to ask user to be extremely careful of using
> > their system or device.
> >
> > Best Regards,
> >
> > Jessica Jiang
> >
> > -----Original Message-----
> > From: Frank Effenberger [mailto:feffenberger@HUAWEI.COM]
> > Sent: Wednesday, April 02, 2008 1:10 PM
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] Optical Overload Ad-Hoc announcement
> >
> > Dear All,
> >
> > If I can summarize my understanding:
> >
> > 1. The actual fact is that the practical damage threshold of 10G APD
> > receivers is indeed 0 dBm (with some risk because burst mode Rx cannot
> > use
> > the usual 'load resistor' sort of limiting circuit.) So, we should
> > certainly not increase the damage threshold above 0 dBm!
> >
> > 2. The PON optics should never be connected back to back, not even in
> > testing. I don't think this is a practical problem, actually. So, to
> > be
> > complete, the standard should include some language warning the reader
> > that
> > back-to-back connection is potentially damaging.
> >
> > I would also observe that because PON is a single-fiber system, the ONU
> > Rx
> > will be saturated at the same time that the OLT RX is in a dangerous
> > situation. Since the ONU won't transmit without a valid upstream
> > signal,
> > the OLT will likely be 'saved' by this fact. Of course, we still need
> > to
> > worry about saving the ONU Rx from permanent damage, but since that is
> > CW
> > operation, a suitable load resistor / current-limited source should
> > help.
> >
> > What is not clear is the correctness of defining a more lenient damage
> > threshold for the classes that have lower power levels (classes PR20 and
> > 30).
> > The point was made that this is not a necessary specification for the
> > operation of the system. And that is true - after all, a damage
> > specification never is. Even the 0 dBm level is not a 'necessary' spec.
> >
> > But I think that perhaps we should try to put down the level that we
> > think
> > is practically useful and easy to obtain.
> >
> > More discussion is needed on that.
> >
> > Sincerely,
> > Frank E.
> >
> >
> > -----Original Message-----
> > From: Hiroshi Hamano [mailto:hamano.hiroshi@JP.FUJITSU.COM]
> > Sent: Tuesday, April 01, 2008 10:15 AM
> > To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
> > Subject: Re: [8023-10GEPON] Optical Overload Ad-Hoc announcement
> >
> > Dear Dr. Effenberger,
> >
> > I greatly appreciate your effort taking this ad hoc leadership.
> >
> > I have already made my comments on the 'Damage threshold' values,
> > suggesting 'Overload + 1dB' for all classes. But currently an
> > opposition
> > has been made, which suggests that they should be at least
> > 'Overload + 3dB'. I am not sure if this 3dB has any technical meaning,
> > nor if it is technically possible.
> > I would like to show my thoughts and understandings, commenting through
> > your suggestion with regard to 'Damage threshold' values.
> >
> > > For some of our optics, the math would put the Overload+1 level at
> > 0dBm,
> > > which is probably where it should stay.
> >
> > I have asked 10G transceiver experts and they have the feeling that it
> > is
> > not
> > easy to guarantee the 10G APD-RX damage level over 0 dBm, especially for
> >
> > a burst-mode OLT receiver, where simple self-limiting circuitry cannot
> > be
> > implemented in order to catch up 10GE-PON high-speed burst signals.
> > Reliability experiments may also be needed even to confirm that damage
> > level.
> > Continuous-mode RX in ONU may have a little more margin, but anyway
> > in 10GE-PON, it seems difficult to guarantee the TX-RX direct connection
> >
> > without damage, because of higher launch power and sensitive 10G
> > components.
> >
> >
> > > However, for other optics, the formula puts the damage level is
> > > considerably lower. I'd expect that damage would not be a problem
> > > for levels lower than -3dBm (just a seat-of-the-pants sort of
> > judgment).
> >
> > I have suggested that -5dBm and -9dBm values for damage threshold
> > in several classes, and these values may have full of margins, compared
> > to
> > the actual 10G-RX performance, achievable without difficulty.
> > But I think the specification value should not necessarily reflect
> > the possible RX performance. It should specify only the required value,
> >
> > just suitable to achieve the system function. I believe that all the
> > possible margins and flexibilities should not be rejected without
> > reason.
> > especially in the IEEE standard.
> >
> >
> > > If we look at clause 52, this sets the precedent for the damage level
> >
> > > being 1dB over the Maximum Receive level...
> > > (just like the 10G point-to-point clause did.)
> >
> > My understanding about 802.3ae may be a little bit different.
> > Most of the PMD categories in Clause 52 (10GBASE-S, L, LX4) seem
> > to have no 'Damage threshold' columns in their spec. table, but it is
> > because they are supposed to serve very short reach applications,
> > including direct TX-RX back-to-back connections, where
> > 'TX average launch power (max)' equals to 'RX average receive power
> > (max)'.
> > So, 'Damage threshold' here should not necessarily be specified
> > redundantly.
> >
> > The only exception is 10GBASE-E, and there, the column exists.
> >
> >
> > > But, maybe the best approach is to take the damage level
> > > out of the main table, and just put it as a footnote.
> >
> > I understand this feeling. If the direct TX-RX back-to-back connection
> > is not feasible in 10GE-PON, there may be no big meaning for specifying
> > 'Damage threshold'. It can be pushed out into the footnote, if it is
> > not
> > suitable in the main spec. table.
> > It can be described as follows (following 802.3ae);
> > 'The receiver shall be able to tolerate, without damage, continuous
> > exposure to an optical input signal having a power level equal to
> > the Average Receive Power (max) plus at least 1 dB'.
> >
> > But I think this is a sort of an objective change from 802.3 precedents,
> >
> > and all the readers/users should also be warned that direct TX-RX
> > connection on 10GE-PON equipments may make a possible damage, and that
> > if TX-RX back-to-back connection is necessary for some evaluations or
> > tests,
> >
> > optical attenuators and/or equivalent loss components should be inserted
> >
> > to guarantee the damage-free RX input power level.
> >
> > I think this kind of notification or warning should also appear in the
> > main body texts before the RX spec. tables, to draw attention.
> >
> > Best regards,
> > Hiroshi Hamano
> >
> > %% Frank Effenberger <feffenberger@HUAWEI.COM>
> > %% [8023-10GEPON] Optical Overload Ad-Hoc announcement
> > %% Thu, 27 Mar 2008 18:22:29 -0400
> >
> > > Dear All,
> > >
> > > I was tasked with leading the discussion regarding optical damage /
> > overload
> > > issues.
> > >
> > > I think there are three sub-items that all relate to this issue
> > > 1. What values should be used for the optical damage levels for the
> > optics
> > >
> > > 2. What dynamic performance can be expected from strong-to-weak burst
> > > reception (the Treceiver_settling question)?
> > >
> > > 3. What about limiting the rate-of-attack of the burst Tx (Ton/Toff)?
> > >
> > > We don't have much time, since formal comments must be submitted by
> > April
> > > 4th. So, below, I have put down my own initial thoughts on these
> > topics.
> > I
> > > invite all to reply with their comments as soon as possible.
> > >
> > > 1. What values should be used for optical damage levels?
> > > If we look at clause 52, this sets the precedent for the damage level
> > being
> > > 1dB over the Maximum Receive level. If we look at the absolute level
> > for
> > > the 10G LX optics, that is 0dBm, which admittedly is getting pretty
> > strong.
> > >
> > > For some of our optics, the math would put the Overload+1 level at
> > 0dBm,
> > > which is probably where it should stay. However, for other optics,
> > the
> > > formula puts the damage level is considerably lower. I'd expect that
> > damage
> > > would not be a problem for levels lower than -3dBm (just a
> > seat-of-the-pants
> > > sort of judgment).
> > >
> > > But, maybe the best approach is to take the damage level out of the
> > main
> > > table, and just put it as a footnote (just like the 10G point-to-point
> > > clause did.)
> > >
> > > 2. What dynamic performance can be expected from strong-to-weak burst
> > > reception (the Treceiver_settling question)?
> > >
> > > The Nagahori presentation gives us very useful data. Let me
> > illustrate it
> > > in the following way: From Nagahori page 7, we can see that a tau/T
> > of
> > 210
> > > results in an error curve that has zero penalty at the higher bit
> > error
> > > rates that we are working at. (There are signs of an error floor, but
> > it
> > > happens at 1E-10, so we don't care). T, in out case, is 97 ps. So,
> > the
> > > data says that setting tau to be 20ns is OK.
> > >
> > > Suppose we want to tolerate 20 dB of dynamic range burst to burst.
> > This
> > > means that we need to set the time constant of the AC-coupling to be
> > at
> > > least 5 times shorter than the burst-to-burst time. (e^5=148 > 20dB).
> > That
> > > means that the burst to burst time needs to be 100ns. So far, we are
> > not
> > > seeing any problems. (By the way, the value of 100ns is what I put
> > forward
> > > in 3av_0801_effenberger_3-page4.)
> > >
> > > I also think that real circuits will need to allocate time for control
> > of
> > > the pre-amplifier stage (setting of the APD bias and/or the TIA
> > impedance).
> > > This should take no longer than an additional 100ns of time.
> > >
> > > So, this leaves us with a requirement of 200ns, which has a safety
> > margin
> > of
> > > 2x below the 400ns that is the proposed value for Treceiver_settling.
> >
> > >
> > > Thus, I don't see any reason why we should change the value from
> > 400ns,
> > just
> > > like in 1G EPON. While it is true that Treceiver_settling will likely
> > need
> > > to be longer than T_cdr, setting the maximum values of both at 400ns
> > will
> > > not preclude any implementations. I fully expect that real systems
> > will
> > > actually do much better than both of these limits.
> > >
> > > 3. What about limiting the rate-of-attack of the burst Tx (Ton/Toff)?
> > > I went to talk with my optical front-end expert, and he explained the
> > latest
> > > results that we've been seeing. The whole motivation of our concern
> > is
> > the
> > > large 20dB dynamic range that we are targeting in PON systems. The
> > problem
> > > is that the receiver is normally in the maximum gain condition, and
> > then a
> > > strong burst comes in that threatens to overload the circuit.
> > >
> > > Initially, we were concerned that the APD and the TIA would be most
> > > sensitive to high burst transients. However, this seems to be not the
> > case.
> > > The APD gain may be self-limiting (saturating), and this helps to
> > limit
> > the
> > > signal to some extent. So, damage to that part of the circuit seems
> > > unlikely.
> > >
> > > However, there still is a problem, and that is that the second stage
> > > amplifier (the one that is driven by the TIA) tends to get overloaded
> > by
> > the
> > > strong bursts. (This is understandable, since the signal has received
> > more
> > > gain by this point.) This prevents the output signal from being
> > useful
> > (for
> > > control as well as for the actual signal), and the recovery from
> > overload
> > is
> > > not well behaved. So, we'd like to avoid that.
> > >
> > > The simplest way to prevent transient overload is to reduce either the
> > APD
> > > gain (by reducing its bias), or reducing the TIA impedance. Either of
> > these
> > > methods is essentially a control loop, and it will have a
> > characteristic
> > > speed. The setting of the speed is bounded on both directions just
> > like
> > the
> > > AC coupling speed, and a value of 20ns is good. Given that we have a
> > > control speed of 20ns, the loop will respond only that fast to input
> > > transients. We can thereby reduce the excursion of the control system
> > > output by limiting the "time constant" of the input signal to be
> > similar
> > to
> > > that of the control loop. This is why we suggest a 'rise time' on the
> > order
> > > of 20ns.
> > >
> > > I was wrong in extending this to also specifying a 'fall time' - there
> > is
> > no
> > > need for controlling the trailing edge, at least, not strictly. The
> > reason
> > > is that the receiver will 'know' when the burst is over, so it should
> > be
> > > able to manage its withdrawal symptoms. (Note that this implies that
> > the
> > Rx
> > > has certain feedback paths, such as when the CDR declares loss of
> > lock.)
> > >
> > > So, that's the reason why we should consider having a controlled
> > turn-on
> > for
> > > the transmitter.
> > >
> > > As for specifying it, the currently suggested text (a Minimum Ton) is
> > not
> > > good. We should rather specify a maximum rate of power increase.
> > Since we
> > > are ramping from essentially zero to Pmax in about 20ns, I would
> > suggest
> > > setting the maximum rate of power increase to be Pmax(mW)/10ns. This
> > allows
> > > for some non-linear power curve (e.g, exponential decay), since it
> > provides
> > > a margin factor of 2 over the straight line value.
> > >
> > > Regards,
> > > Frank E.
> >
> > ---
> > -----------------------------------------
> > 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
> > -----------------------------------------
> >
> >
>
>
>
>
> ---
> -----------------------------------------
> 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
> -----------------------------------------
>
>
---
-----------------------------------------
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
-----------------------------------------