| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Peter, According to Table 154-10 the maximum inter-channel crosstalk at TP3 is -16 dB.
According to Table 154-9 the receiver maximum average input power is 0 dBm and the minimum is -16 dBm. Since the maximum cross talk is defined (G.698.2) as: “the ratio of total power in all of the disturbing channels to that in the wanted channel, where the wanted
and disturbing channels are at different wavelengths.” Assuming that cross talk is dominated by the two adjacent channels, I assume that any single adjacent channel contributes half of the cross talk, -19 dB. If the adjacent channel receiver input power is
0 dBm then the tested channel will see -19 dBm. We could consider defining a threshold (e.g. -18 dBm for the amplified case) that takes into consideration the maximum crosstalk, and only if the signal is above
this threshold the PMD will indicate signal detected. Obviously this is not an 100% indication that there is valid signal, just that there is probably a signal and that it is not cross talk. If the optical power detected is just noise, then the PCS will not
be able to synchronize and the fail indication will be sent to the upper layers. Note that according to the new synchronization process defined recently, the fail indication generated by the PCS will be stable. To summarize, we could define a threshold THR that: -
If power is <THR: PMD SIGNAL_DETECT = FAIL (regardless of the PCS being able or not to synchronize) -
If power is >THR and PCS cannot synchronize on the signal: PMD SIGNAL_DETECT = OK, PCS SIGNAL = FAIL
-
If power is >THR and PCS is synchronized: PMD SIGNAL_DETECT = OK, PCS SIGNAL = OK Best regards, Leon Best regards, Leon From: Peter Stassar
Hi Leon, Good question. However, if, for the time being forget that we can define a reliable optical threshold detect, how would you want to address this?
The key issue for the comment is can we identify a suitable optical signal detect and associated level. So far, we didn’t see any reliable way. I believe we will need to rely on the fact that the various black link crosstalk requirements in Table 154-10 are sufficient that a potential crosstalk signal
is sufficiently weak that it will not be possible for a receiver to lock onto Kind regards, Peter From: Leon Bruckman
Hi, I have no objection to this approach, but I have a question: Is there a possibility that there is a signal loss (no intended signal in the channel) and still the receiver sees a weak cross talk signal from an adjacent channel
? If this is possible then the receiver may lock (an probably unlock intermittently) to that signal.
A SIGNAL_DETECT optical power threshold would avoid this situation. Is there another mechanism to detect this situation (if this situation is possible at all)? Best regards, Leon From: Peter Stassar [mailto:Peter.Stassar@xxxxxxxxxx]
Hi,
Because I had some thoughts after our call yesterday, I contacted Eric and Steve Trowbridge to get some feedback. Apparently the three of us had independently come to a similar conclusion, that the SIGNAL_DETECT in Clause 154 is so unreliable for the intended applications,
that we doubted the usefulness of it. The three of us jointly feel that it will be impossible to define a suitable optical threshold that is also reliable and furthermore that the “real” signal detection
actually is in the higher layers and not so much in the physical layer. Thus we recommend to the group to remove the allocation/definition of an “exact” optical level for SIGNAL_DETECT. Instead we recommend to assign a fixed OK status to SIGNAL_DETECT, in order to not mess up with the interlayer relationships. Via this email I would like to check if there would be any objections to that approach. If there are then Eric will move forward and set up an ad hoc to further discuss. If there are no objections, then we can use this principle towards a suitable modification of the draft. Before starting to develop appropriate text to describe this I would like to know your views. Please let us know latest coming Monday 22 July. Kind regards, Peter Stassar, Clause 154 editor From: Eric Maniloff [mailto:eric.maniloff.ieee@xxxxxxxxx]
All, I was asked to set up an Ad Hoc call on the Signal Detect issue. I'll be organizing this for late next week or early the following week, please let me know if you are interested in participating by replying to this email. Scheduling is challenging, so please also let me know if you are participating in 802.3ck calls, and where you are located so I can try to accommodate schedules (with no promises). Regards, Eric 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 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 |