RE: [EFM] PHY Kids 2: The (sub) task-force of lost dreams

["Jonathan Thatcher" <Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx>]

Glen,

Good note.

I would like to amplify one point. In my mind, the principal difference between selection "A, C" and "B, D" is one of "technical feasibility." As you are aware, in previous projects, this has become a sticking point when time came to move either into, or out of Working Group Ballot. In 10 Gig, the project almost ground to a halt while PHY manufacturer scrambled to provide evidence.

I, for one, will have no difficulty accepting the ability of existing, mass produced, components operating under loose timing tolerance. But, given the technical information I have seen (or not seen) to date (e.g. testing done by the FEC group), I would be forced to conclude that there no evidence that:

o Rapid Tx off and on
o Rapid AGC (especially without reset)
o Rapid bit synchronization
o Rapid alignment
o 10e-12 BER (during synchronization and after)
o Low jitter (during synchronization and after)
o and other PMA and PMD specifications (during synchronization and after)

can be simultaneously met.

In fact, in many cases, I don't even know how to make the measurements. Example, how does one ensure that a PMD can meet optical spectral width specifications by the end of this startup window when this measurement requires -- as currently specified -- time to find the average? Do we believe that the steady state operation of a laser is the same as when is moving from an off-state equilibrium to an on-state equilibrium? I don't think so.

So, if we accept option A or C, who is going to write the new measurement techniques? Who is going to validate them. Who is going to build the test equipment? Without these, can the document can not be considered "technically complete?" I don't think so.

jonathan

| -----Original Message-----
| From: Glen Kramer [mailto:glen.kramer@xxxxxxxxxxxx]
| Sent: Thursday, November 21, 2002 1:06 PM
| To: stds-802-3-efm@ieee.org
| Cc: wdiab@xxxxxxxxx;
| KIM_AJUNG/sait_breakthrough_stars_grp13@xxxxxxxxxxxxx; Meir@xxxxxxxx;
| wsoto@xxxxxxxxx; eyal@xxxxxxxxxxxxxxxxxxxxxx; raanan@xxxxxxxxxxxxxxx;
| francois.fredricx@xxxxxxxxxx; BDeri@xxxxxxxxxxxx; s-rogers@xxxxxx;
| maurice.reintjes@xxxxxxxxxxxxx
| Subject: [EFM] PHY Kids 2: The (sub) task-force of lost dreams
| 
| 
| 
| Vipul et al,
| 
| Judging by the reflector activity, it seems no progress is 
| being made in
| converging on any PMD timing option. One of the reasons may 
| be the fact
| that P2MP and PMD STF approach this issue from different 
| points of view.
| 
| Perhaps it would help if P2MP and PMD groups would clarify to 
| each other
| the features and limitations of P2MP protocol and transceiver
| technologies.
| 
| Below I list few P2MP effects on timing parameters (to the 
| extent of my
| own (mis)understanding).
|  
| 1. AGC time
| -----------
| 
| Clock resolution (time quanta) in MPCP is 16 bit times (16ns). During
| last meeting the P2MP group decided to allow delay variation 
| in MAC and
| PHY of 2 clocks (32ns). In the round-trip this sums up to 
| 4*32 = 128 ns
| (OLT Tx -> ONU Rx -> ONU Tx -> OLT Rx).
| 
| How that affects PMD timing? If for 'option A' a reset line is needed,
| the AGC interval should be 50 ns plus at least 128 ns (for delay
| variability). (I heard that the reset signal must come in 
| during the AGC
| stage. Please, correct me if this assumption is wrong.)
| 
| Also during the auto-discovery, the OLT cannot predict the value of
| round-trip time to a new ONU and the value of random delay 
| this ONU will
| apply. Therefore, for the OLT it is not possible to generate 
| a hard-wire
| reset signal to the receiver.
| 
| From Frank and Walt I hear that hard-wire reset is not needed 
| for option
| A and should not be specified in the standard. If this is indeed a
| consensus of 'option A' camp, the AGC can remain 50 ns. 
| 
| 2. CDR time
| -----------
| 
| Option A calls for CDR to be 50 ns. It is not clear if this is
| compatible with FEC mechanisms.  It was mentioned during the last
| meeting that pre-FEC BER can be as high as 10^-4. Will the receiver be
| able to synchronize in less than 50 ns with such a BER?
| 
| If not, that means the CDR should be longer (perhaps 400 - 
| 800 ns). But
| for systems that don't use FEC and have low BER of 10^-12, such a long
| CDR may be unnecessary. 
| 
| Starting with long CDR and having ability to reduce it after 
| the initial
| registration would benefit both worlds.
| 
| 3. Laser ON/OFF times
| ---------------------
| The time interval when one ONU starts shutting laser off, and the next
| ONU finishes turning its laser on should be laser_ON_time + 128 ns +
| laser_OFF_time (because of above-mentioned delay variability).
| 
| In case we allow overlapping laser_ON/OFF times, this interval may be
| reduced to 128 ns + max( Laser_ON_time, laser_OFF_time).
| 
| Considering this additional 128 ns, and possibly increased CDR, and
| possibly increased AGC, the reduction of laser_ON/OFF times may make a
| negligible effect on system utilization.  It can make a significant
| effect on system cost though, since we are talking about 
| lasers in ONUs.
| 
| 
| 
| 4. PMD timing "negotiation"
| ---------------------------
| 
| The word "negotiation" used by many is not very accurate. It rather
| should be a "notification" or "exchange". During the registration
| process, OLT informs un-initialized ONUs of what AGC settling time and
| CDR it requires. ONUs would transmit the corresponding number of IDLEs
| at the beginning of each grant.
| 
| When responding to a DISCOVERY message, ONUs send to the OLT 
| their laser
| ON/OFF timing values. OLT would account for these values when 
| assigning
| grants to ONUs.
| 
| The OLT and ONUs treat the received values as constants and do not
| change them dynamically.
| 
| It should be emphasized that the above mechanism is already 
| in the draft
| in clause 56 (since D1.0). Changing (removing) it would require a 75%
| approval, which is highly unlikely given voting results from the last
| meeting.
| 
| 
| Conclusion
| ----------
| 
| To make a progress in PMD timing resolution, I would suggest 
| trying the
| following approach:
| 
| a. There should not be 'option A' vs. 'option D' since D is already in
| the draft.
| 
| b. Let's focus on each of four parameters (laser ON, laser OFF, AGC,
| CDR) separately and find good values for each parameter considering
| inputs from protocol and FEC. 
| 
| c. Our current assumption should be that after the start-up 
| (discovery),
| the timing values can be reduced (using existing MPCP 
| protocol). We can
| have a separate discussion regarding whether we should revise MPCP
| protocol to remove PMD parameters fields or not. 
| 
| 
| Glen
| 
| 
| 
| 
|