| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I don’t recall the discussion to which you refer. How would an ONU know what the worst case is for the entire PON? This is really what is important, not what an ONU is capable of. Certainly the ONUI doesn’t
need this to adjust its own on/off times but how does it calculate the minimum inter-burst time if it has no idea what the worst case is? Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Duane, Page numbers were added. As far as the laser on/off discussion goes, I do recall we had a rather lengthy discussion at the last meeting with conclusion that we would not need the OLT “confirm” ONU laser on/off capabilities, but rather let the ONU announce them
in the REGISTER_REQ MPCPDU and OLT take them as they are. After all, the ONU knows what it can do and would not (likely) announce larger values than absolutely needed only to have the OLT trim these down in the REGISTER MPCPDU Marek From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Marek, On slide 11 (please add slide numbers) you indicate that the laser_on/off times are no longer needed but I think if you look at the new MPCP strategy these will still need to be communicated. The MPCP needs these to determine if a burst can be concatenated into one burst or needs to be split into two bursts. The PCS determines the end of a burst by looking for an empty INPUT_FIFO. This condition
occurs when the MPCP does not issue a new envelope to the MPRS for a given amount of time equal to the minimum inter-burst time. The minimum inter-burst time is determine by end of burst time, laser on time, and laser off time. This also determines the size
of the INPUT_FIFO. Please reinstate laser_on time and laser_off time. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Here is the updated version of the deck + associated set of changes for Clause 144 – note that all changes are tracked for simpler verification. I tried included only changes needed to address the delimiter announcement, excluding any other
editorial changes (I will be submitting a number of comments on D1.1 to address other naming discrepancies, etc., in Clause 144). Regards Marek From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Curtis, et al., I would like to revisit the delimiter announcement, with the specific focus on recording any corner cases and specific scenarios that need to be addressed to make it viable for adoption at the next meeting.
Thank you Marek From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Dear Colleagues, We have an 802.3ca consensus-building meeting this Thursday, June 21, 11:30 am MST. Please let me know by 5:00 pm MST Wednesday if you have any contributions for this meeting. Curtis Curtis Knittle VP Wired Technologies – R&D CableLabs desk: +1-303-661-3851 mobile: +1-303-589-6869 Stay up to date with CableLabs: Read the blog and
follow us on Twitter To unsubscribe from the STDS-802-3-NGEPON list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1 |