Re: WG: OMA Rec spec and verification of interface
Hi Rahn
Few years back when OMA was first introduced in FC my primary concern
was what simple method can you use to verify optical levels. From
the measurement OMA introduces significant variability making DC power
almost useless. But the argument for OMA was you can't tell much about
a multi-gig system by measuring Dc power anyway.
My primary concern is specifying very low ER 4 dB.
The transmitter is over optimized by burdening the receiver.
At 4 dB ER significant amount of DC offset is introduced in
the receiver. I would suggest keeping the min ER to 6 dB.
Thanks,
Ali
"Rahn, Juergen (Juergen)" wrote:
>
> > Hi,
> > The issue in the subject I brought forward at the last meeting is not
> > resolved in my view. In the current Draft the Transmitter as well as the
> > receiver is specified in OMA. This is done in order to allow bigger
> > variance in the transmitter signal in terms of ER and power variation.
> > This, in this case leads to the following situation for e.g. the 1300nm
> > interface:
> > Transmitter power may be vary from: - 6. 22 dBm (coming from calculation)
> > in case of very high ER
> > to +1dBm as value for the 4 dB ER (in contras to former 3 dB we now have
> > complete match).
> > This means under an assumption of a compliant path of maximum attenuation
> > we can measure either :
> > - 13 dBm for high ER signals or up to -6 dBm as max power low ER signal (I
> > leave the decimals as this is not suited for verification anyway)
> > In case of lowest attenuation, the power may vary between the -6 dBm for
> > the high ER signals and +1 dBm for the 4 dB ER signal. This means that
> > receive power levels measured with a power- meter do not at all help to
> > determine if a receiver power is in spec or not as there is absolutely no
> > overlap between the two cases. All the power levels between it cannot be
> > verified with a simple power meter as at all power levels between 6 and
> > -13 dBm the power may either be correct or too low as function of the ER.
> > In such cases the OMA has to be measured at the receiver. This however has
> > to be done with an oscilloscope and has further reduced precision in
> > comparison to a power meter.
> > This means: The verification of the correct receiver power level requires
> > specific measurement equipment for verifying the optical amplitude on the
> > normal Eye or some means have to be in place to switch the transmitter
> > into Test pattern mode (Where I have the question what a test that has
> > nothing to do with a normal pattern tells a about the real ER). All this
> > is not simple and special complicated measurement means are contradicting
> > the idea of a simple interface for compatibility between different
> > vendors. This by the way was the reason for specifying the ITU interfaces
> > the way this is done, as complicated validation is a direct interface cost
> > driver.
> >
> > The validation of the 1550 nm interface is principally suffering from
> > this effect also however if taken the values of the previous draft an
> > overlap is present where you can judge that the power is correct in any
> > case due to the smaller allowed variation (+4 to ~-1.5 dBm). Under this
> > condition the optional attenuators (looking at the values of the former
> > draft could solve the problem and make verification of the receiver side
> > of the path possible by easy means. (By the way here I have some
> > difficulties with the power levels as
> > (Here I want to note that there are changes in the draft I do not
> > understand as the dB value in the line of minimum OMA is kept but the
> > description that these are the dBm of OMA/2 has gone. It this a mistake or
> > intentionally?
> >
> > The situation described is however further complicated due to the fact the
> > minimum power (or OMA) is also a function of the dispersion penalty,
> > (formerly only for 850nm and 1310nm but also now for the 1550 range). This
> > means to verify if the power of an interface is correct you have to
> > measure the wavelength and spectral characteristic, which requires
> > definitely more that simple low cost equipment. In case of the chirp for a
> > 1550nm interface I see the only real chance to use a reference fiber as
> > the chirp factor is not specified (which I would not criticizes as the
> > behavior and dependencies of the dynamic chirp is really difficult to be
> > specified easily). Any way the result is the same, a reference fiber or a
> > measurement set for time resolved spectral measurement is contradicting
> > the verification of a low cost mass deployed interface.
> >
> > This may be sufficient to start the discussion on the issues I see on the
> > short hand.
> > In this context I got a couple of questions in relation to the new draft
> > not understanding the we (doubling) and content of the tables.
> > I have the assumption that simply some change-marks and strikeouts are
> > missing bout do not know if this is true.
> > Regards Juergen Rahn
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ----------
> > Von: DAWE,PIERS (A-England,ex1)[SMTP:piers_dawe@xxxxxxxxxxx]
> > Gesendet: Montag, 9. April 2001 17:06
> > An: '802.3ae Serial'
> > Betreff: From serial PMD call, 3 April
> >
> >
> > We built a new open issue list; in no particular order:
> >
> > Trade off jitter and risetime
> > -----------------------------
> > Proposal to rely more on eye mask, allowing trade off between risetime and
> > deterministic jitter. This would simplify testing at 1310 serial and
> > maybe
> > 1550 serial, avoiding an unsatisfactory rise time test involving four
> > histograms. It may allow a good old fashioned performance improvement at
> > 1550 where faster rise times can be associated with greater dispersion
> > penalty. There may be technical issues between this and the
> > wavelength/spectral width/power trade-off, and a highly multi-dimensional
> > trade-off would become unmanageable.
> >
> > Specification of optical transmitter spectral width
> > ---------------------------------------------------
> > Relation between full width, -20 dB criterion and link model.
> >
> > Double counting of receiver eye opening penalty
> > -----------------------------------------------
> > Spreadsheet allows an unretimed receiver sensitivity and then an eye
> > opening
> > penalty (~0.4 dB). Measured sensitivity of a retimed receiver would
> > include
> > its own eye opening penalty. Need to at least note the issue in the
> > standard.
> >
> > Other issues raised by the shift to a box level spec
> > ----------------------------------------------------
> > Perhaps without noticing it, we have moved from a component level standard
> > (Gigabit Ethernet) to a box level standard (10 Gigabit Ethernet). We need
> > to check that we have made the transition correctly. One known issue is
> > that of some components which try to appropriate the whole box's allowance
> > to themselves (e.g. jitter).
> >
> > Interworking between 1310 and 1550 equipment
> > --------------------------------------------
> > It may be that some 1310 and 1550 equipment could interwork, within
> > certain
> > loss and dispersion parameters, "by coincidence". Should this get
> > mentioned
> > or encouraged in the standard? Does it have "broad market potential"?
> >
> > Bit ordering in clause 51
> > -------------------------
> > Alignment with SFI-4 vs. Ethernet customs (see reflector traffic). Needs
> > joint session of clauses 51, 52. Also involves clauses 49, 50.
> >
> > Meaning of signal detect
> > ------------------------
> > Needs joint session of clauses 51, 52 and more.
> >
> > Measurement filter for RIN
> > --------------------------
> > Serial ad hoc to find if the filter for RIN should/must be the G.691 (7.5
> > GHz) one, i.e. what is built into test equipment?
> >
> > Delay through PMA/PMD/medium
> > ----------------------------
> > This delay maximum is defined in clause 44. We need to discuss it in the
> > PMD tracks and add
> > cross-references in clauses 51, 52 and 54.
> >
> > Ordering of text in new jitter section
> > --------------------------------------
> > Other tests have test method and required values in separate sections:
> > shouldn't this one too?
> >
> > Do we prefer dB(OMA) or dB(OMA/2)?
> > ----------------------------------
> > Argument for dB(OMA): More straightforward relation between OMA
> > and dB(OMA)
> > Argument for dB(OMA/2): Allows traditional thinking with dB(OMA/2) ~
> > "optical power"
> > We just need to take a poll on this: there weren't enough people on the
> > call
> > this week.
> > (My own view is that if Fibre Channel had said "Modulated Optical Power =
> > (P(1)-P(0))/2" then we wouldn't be having any discussion.)
> >
> > Topics that don't need to be in weekly call
> > -------------------------------------------
> > Adding interferometric noise to link model
> > Updating link model to reflect [what change?] at 1550 nm
> > Possible effect of sinusoidal jitter on link model
> > Test patterns - separate call for these
> >
> > NEXT MEETING
> > ------------
> > Agenda
> > ------
> > I thought we might put on the agenda some items which don't need so much
> > research:
> > Delay maximum
> > RIN measurement filter
> > Interworking 1310 <>1550
> > Other ramifications of shift to a box level spec?
> > Transmitter spectral width
> > What values of RMS width and full width, -20 dB down, are
> > anticipated? What dispersion penalties are anticipated in the 1310 band?
> > Any other issues to add?
> >
> > Time and place
> > --------------
> > At the usual phone number and new usual time:
> > 15:15 GMT = 4:15 pm BST = 8:15 am PDT, Tuesday 10 April 2001, for an
> > hour and a half -ish, to finish by 17:00 GMT
> > +1(816)650-0631 Access code 39209
> >
> > People are having difficulty attaching to these calls; apparently the
> > issue
> > is congestion not number of ports, so persistence is required. I shall
> > try
> > to open the call five minutes before time to give people a better chance.
> >
> > Piers
> >
> >
begin:vcard
n:Ghiasi;Ali
tel;work:(408)922-7423
x-mozilla-html:FALSE
org:Broadcom;Optical Transport
adr:;;3151 Zanker Rd ;San Jose;CA;95134;
version:2.1
email;internet:aghiasi@xxxxxxxxxxxxx
x-mozilla-cpt:;-3776
fn:Ali Ghiasi
end:vcard