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

[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