[8023-10GEPON] Burst mode ad-hoc - Summary comments
Dear All,
Our little discussion on burst mode timing has been rather brief. However,
I think I can summarize with the following statements:
1. There is support for the policy wherein we specify a loose upper bound
for Treceiver_settling and Tcdr, and informatively suggest that implementers
can do better.
2. The current MPCP discovery process in fact already supports this optional
tightening behavior. So, we need not do anything extra on that account.
3. The "slow start" behavior may or may not be desired, because it depends
on the OLT implementation. Some OLTs may overload if the average power
increases too suddenly, while other OLTs may not.
In light of this, I had submitted two comments that are related.
The first suggests to fill in the OLT response time specifications with the
old values of 400ns each, and to expand the corresponding note, explaining
that implementers should do better than this. (It does not say how much
better, which was fortunate, since it seems there will be debates on how
good we can get.)
The second suggests to add an ONT Ton and Toff *min* of 0 or 18 ns. The "0"
value corresponds to no slow start, and the "18" corresponds to about three
blocks of turn-on/turn-off time. A note is added that the OLT would set the
mode of the ONT using a new feature of the discovery gate, which would be a
binary indication for using slow-start or not.
I think that with these two small comments, we have captured the extent of
all the discussions so far. We can have further discussions at the meeting
when we come to these comments.
Sincerely,
Frank Effenberger
-----Original Message-----
From: t-nagahori@ah.jp.nec.com [mailto:t-nagahori@ah.jp.nec.com]
Sent: Wednesday, March 05, 2008 10:04 PM
To: Frank Effenberger
Cc: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] Burst mode ad-hoc Starting presentation
Dear Dr. Effenberger,
This is Takeshi Nagahori, NEC, a member of Burst Mode Timing Adhoc.
I agree with your Initial Discussion Document in general, but I have some
comment.
I agree with Historical Perspective on ITU side.
On Suggested path forward, I agree the importance of reference design on
both loose timing and tight timing, but the proposed timing value example
is tight referred to the presentation on January meeting.
Following is my alternative proposal.
loose timing: treceiver_settling + tcdr = 800ns (without any reset signal,
LIM-CDR AC coupling)
tight timing: treceiver_settling + tcdr = 200ns (with burst enable/reset
signal from other layer)
On broadcast of burst-mode overhead requirements, the same function
is already defined at 802.3ah in GATE MPCPDU (Clause 64.3.6.1), as you know.
So we need no change, unless rise-time control is newly defined.
On rise-time control, anyone believes that the faster the better on
envelope of upstream optical waveform. The reason why rise-time control
is needed will be explained in detail.
Finally I must apologies for my delayed reply.
Best Regards,
Takeshi Nagahori
NEC
t-nagahori@ah.jp.nec.com
>Dear All,
>
>
>
>I was supposed to get a discussion going on burst mode timing.
>
>As I¡¯ve done in the past, I¡¯ve put together my initial thoughts on paper,
>just to stimulate things.
>
>See the attached slides.
>
>
>
>If anybody has any comments, please let us hear them.
>
>Thank you.
>
>
>
>Sincerely,
>
>Dr. Frank J. Effenberger ¸¥À¼¿Ë °£·Ò²©¸ñ
>
>Huawei Technologies USA
>
>1700 Alma Drive, Plano TX 75075
>
>Cell (908) 670 3889
>
>Office/Home (732) 625 3001
>
>
>
>
-----------------------------------------------------
’·–x@„
t-nagahori@ah.jp.nec.com
“ú–{“d‹C(Š”) ŒõƒfƒoƒCƒXŽ–‹Æ•” ‘æ“ñ¤•iŠJ”ƒOƒ‹[ƒv
§270-1198 ç—tŒ§‰ä‘·ŽqŽs“ú‚Ìo1131
ŽÐ“àƒ[ƒ‹: 26-52801
TEL: 04-7181-8738i“àü8-26-76324j
FAX: 04-7185-7926i“àü8-26-57926j
-----------------------------------------------------