| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
802.3ct TF members: Regrettably, I will be unable to attend tomorrow’s meeting. As a result, on the off chance any of my comments come up for discussion, I wanted to provide some written feedback for your consideration.
On that last point, as it stands now, the tables in Clause 154A.4 are based around the minimums that a compliant transceiver will support. Specifically, the transmitter is required to output a minimum of -8 dBm, and the receiver is required
to receive down to -27 dBm when the OSNR is high, for a difference of 19 dB. When you subtract the loss due to the mux/demux, patch panel, etc., the remaining power is what’s available to overcome loss in the fiber, and establishes the maximum reach for the
system. In the 40 channel scenario, there’s 5 dB left, which translates into a reach of 20km (based on 0.25 dB of loss per km). However, the specification also permits the transmitter to operate at up to 0 dBm. If you used that number, now you have 13 dB to work with, which translates into a reach of 52 km, a very different number, and one that would make it clear
that this device can be used in far more scenarios than one might assume from looking at the calculations based on the minimum. Now, I am not proposing that we include a separate set of calculations for both the min and the max. And I would tend to agree that there’s value in focusing on the minimums, as you can always assume that’ll work. That said, the reality
is that many (probably most) devices will transmit with more power than -8 dBm, and these are all engineered links: operators will select transceivers for their given scenario to ensure they have sufficient power, not just build based solely on the minimum.
Therefore, I would ideally like to see at least some acknowledgement in the description of the examples that these
are minimum values, and that with devices that exceed those minimums you can get (potentially significantly) longer reach. It may be that doing as I’m suggesting is not appropriate for an 802.3 specification, which would be unfortunate, but something I can accept. That said, given that we’re talking about examples that are meant to show what this technology
is capable of, it seems to me that providing a bit more guidance is entirely appropriate and highly valuable to the reader. I hope that makes sense, and thanks for listening.
From: John D'Ambrosia <jdambrosia@xxxxxxxxx> All, The webpage for the IEEE P802.3ct Task Force meeting on 02 Apr 2021 has been updated. Please note at this time, only the technical material has been uploaded, as Tom Issenhuth and I are working on our respective reports. Please see
https://www.ieee802.org/3/ct/public/tf_interim/21_0402/index.html. Regards, John D’Ambrosia Chair, IEEE P802.3ct Task Force To unsubscribe from the STDS-802-3-DWDM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1 To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1 |