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

Re: [STDS-802-3-NGBIDI] Contribution to the 3cp 12/19 conference call 



Thank you, Frank, for the additional explanation.

 

It would certainly be ideal to have the same style of specs in both groups. Given the target consent timeline for G.9806, the editors and the Rapporteur will have to discuss the best path forward.

 

Many thanks again.

 

Happy Holidays to All.

Shan

 

From: Frank J Effenberger <frank.effenberger@xxxxxxxxxxxxx>
Date: Friday, December 20, 2019 at 12:29
To: Shan Wey <shan.wey@xxxxxxxxxxx>, "STDS-802-3-NGBIDI@xxxxxxxxxxxxxxxxx" <STDS-802-3-NGBIDI@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-3-NGBIDI] Contribution to the 3cp 12/19 conference call 

 

I wish it was so easy, but no, unfortunately we can’t directly use the “TxMinPower”. 

The reason is that the IEEE spec is defining a somewhat complex operating area. 

There is a limit on minimum power.  There is a limit on OMA.  There is a limit on ER. 

In general, all three of these limits do not intersect at a single point.

In the TxPower, ER coordinate system, this defines a pentagonal shape.  And we haven’t even mentioned TDP. 

 

Typically, the ITU spec defines a single point on that boundary that in some sense maximizes the operating area (which for ITU style is a rectangle).

Viewed in this way, since we cannot make a rectangle completely match a pentagon, it is impossible to write a set of ITU-style specs that exactly match that of IEEE. 

All we can do is make them close. 

 

I would suggest that we consider just adopting the IEEE-style of specs into G.9806, but then also give an informative set of numbers that give the best approximation to the ITU style of specs.  Once we settle on the values in .3cp, it should be an easy matter to copy things over.

 

Sincerely,

Frank E.

 

 

 

 

From: Shan Wey <shan.wey@xxxxxxxxxxx>
Sent: Friday, December 20, 2019 1:41 PM
To: Frank J Effenberger <frank.effenberger@xxxxxxxxxxxxx>; STDS-802-3-NGBIDI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-NGBIDI] Contribution to the 3cp 12/19 conference call 

 

Thank you very much, Professor Frank. Your summary has made things very clear.

 

Now, if I may, here’s a follow-up question hopefully not to incur too much more consulting fees 😊

 

IEEE also includes the “Average Launch Power” spec, see rows 7 and 8 in the specs worksheet prepared by you and Yuanqiu. I always view the “Average Launch Power” spec as a reference and equivalent to the ITU-T TxPower spec. In other words, we can plug this value into the ITU equation to find the ITUrxSensitivity.

TxPower – PathLoss – PathPenalty =  (Rxsensitivity + TxPenalty) = ITUrxSensitivity. 

 

Is this correct?

 

Best regards,

Shan

 

From: David Lewis <David.Lewis@xxxxxxxxxxxx>
Reply-To: David Lewis <David.Lewis@xxxxxxxxxxxx>
Date: Friday, December 20, 2019 at 08:48
To: "STDS-802-3-NGBIDI@xxxxxxxxxxxxxxxxx" <STDS-802-3-NGBIDI@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-NGBIDI] Contribution to the 3cp 12/19 conference call 

 

Hi Frank,

That is a very good summary.  Many of us try to explain these things to colleagues and what you have now given us is a written version of what for me has involved a lot of white board writing and hand waving.

 

One point that has crept in with PAM4 PMDs is that not all of the path penalty is captured by TDECQ.  There are additional penalties for MPI (multipath interference) and DGD penalty.  So in the link budget for the 100Gbps per wavelength PMDs we have allocated additional link budget of 0.3 to 0.5 dB for these impairments.

 

Regards,

David Lewis

 

 

From: Frank J Effenberger <frank.effenberger@xxxxxxxxxxxxx>
Sent: Friday, December 20, 2019 8:35 AM
To: STDS-802-3-NGBIDI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-NGBIDI] Contribution to the 3cp 12/19 conference call 

 

Hi Shan, and All,

 

In a perfect world, the equation would be:

TxPower – PathLoss = Rxsensitivity. 

 

However, both transmitters and the optical path have associated penalties.  The full equation is thus:

TxPower – TxPenalty – PathLoss – PathPenalty = RxSensitivity. 

 

In the ITU specification scheme, this is rearranged as:

TxPower – PathLoss – PathPenalty =  (Rxsensitivity + TxPenalty) = ITUrxSensitivity. 

In other words, the specified Rx sensitivity is that observed with the worst Tx possible.  This has practical issues because it is making a parameter of the Rx dependent on the character of the Tx, and these are manufactured by different companies in some cases.  Also, building yourself a “worst possible transmitter” is not so easy.  One might ask why this method remains popular with network operators.  The answer is that it is easy to measure with simple equipment (power meters), and the path loss is separately specified and therefore the clear responsibility of the operator.  In cases where both transceivers are sourced from the same vendor, the linkage of Tx and Rx is not an issue, and even in the other case, most optical components behave the same (we don’t expect large deviations of transmitter penalty).  Bottom line, it works most of the time, and it is simple.

 

In the IEEE (10G) specification scheme, this is rearranged as:

(TxPower – TxPenalty – PathPenalty) – PathLoss = RxSensitivity. 

Here, all the penalties are lumped into the transmitter spec (you may know it as OMA – TDP).  This means that the RxSensitivity needs to be measured with a very nearly “perfect” Tx signal; for higher signaling speeds this becomes problematic.  This also has the issue that it make the Tx performance dependent on the optical path, and these are certainly manufactured by different companies.  On the other hand, optical fiber is pretty consistent and well characterized.  It is relatively easy to build yourself a “worst case optical channel”.  This method has the good characteristic that it allows the tradeoff between Tx power and its signal quality. 

 

At this point, we have an aside on OMA.  OMA, ER, and AveragePower are related by a simple equation:

OMA = 2*(ER-1)/(ER+1)*AveragePower. 

Note that is ER>>1, then OMA = 2*AveragePower, and if ER=1 (i.e., no modulation), then OMA = 0.  For Johnson-noise limited receivers (PIN-detectors), the OMA is the primary signal strength indicator.  This means that by specifying the Tx OMA, we allow the tradeoff between minimum power and ER.  For shot-noise limited receivers (APDs or SOA-preamp types), this is not exactly true; however, the deviations from this tradeoff are fairly small (less than a dB). 

 

Lastly, let’s discuss TDEC (Transmitter and Dispersion Eye Closure).  As mentioned above, the golden Tx needed to measure the sensitivity in the IEEE method is hard to come by for higher speeds.  The TDEC method allows the measurement of the TDP of a given transmitter by measuring its waveform digitally, and then calculating how much noise could be added until the BER limit is reached.  In a sense, it is using a digital oscilloscope to simulate a “perfect receiver”.  Once the Tx is characterized (calibrated, effectively), it can then be used to measure the RxSensitivity.  So, TDEC and TDECQ are really just measurement method improvements, and they do not change the basic method of OMA – TDP. 

 

I hope that gives you an idea of the complexities involved in the specification of optical links. 

 

A bill for my consulting services will be in the mail.  😊

 

Sincerely,

Frank Effenberger 

 

 

 

From: wey.junshan@xxxxxxxxx <wey.junshan@xxxxxxxxx>
Sent: Thursday, December 19, 2019 5:05 PM
To: Frank J Effenberger <frank.effenberger@xxxxxxxxxxxxx>
Subject: Re:Con tribution to the 3cp 12/19 conference call 

 

Hi Frank,

Yuanqiu said you would be willing to help me sort out the G.9806 vs 3cp PMD numbers. That's great. 

Do you have any formula used by the two groups in the past? We can have a call to discuss if it's easier. Please let me know. 

 

Thank you.

Shan

 


To unsubscribe from the STDS-802-3-NGBIDI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGBIDI&A=1


To unsubscribe from the STDS-802-3-NGBIDI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGBIDI&A=1


To unsubscribe from the STDS-802-3-NGBIDI list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGBIDI&A=1