| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Marek, Mostly agree, two additional
thoughts in-line.
Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Thank you, Duane, I had some expert help with Glen providing feedback. More inline in red Marek From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Marek, Excellent presentation, thanks for the good work.
I probably will not be able to be on next week’s call so here are a few comments/questions.
1)
Slide 5/1st bullet states “Each parameter is announced once, following the Discovery GATE” whereas slide 9/1st bullet states “OLT announces … before issuing DISCOVERY GATE MPCPDU”.
Please clarify. [mh0322] The way I originally envisioned is that SYNC_PATTERN would be send after DISCOVERY GATE, but in reality, these can be independent processes, i.e., OLT might announce the SYNC_PATTERN at any time and just
broadcast it to all ONUs. OLT may elect to send it before DISCOVERY GATE as well.
I will align the deck for consistency right now, but we can change it down the road if there is TF preference for one or the other.
2)
Slide 7 – So my understanding is that if SP Index is set to 1 the message applies to the AGC, 2 indicates CDR and 3 is for Burst Delimiter. So if SP Count = 2 (ACG+CDR & BD) then you would see SP Index
of 1 and 3 only. Is this understanding correct? [mh0322] Correct, apart from the fact that index is 0-based, i.e., it is 0, 1 for SP Count =2, and 0, 1, 2 for SP Count = 3. At the end, either option works really, but it is more consistent with all of our indexes
running from 0 to N-1.
[mh0322] Fixed, Mark also noticed that and commented directly. Thank you
[mh0322] The idea here is that we have space so we do not need to optimize for size. This gives us plenty of space should it be ever needed for any reason.
3)
Slide 8 – So if SP Balanced = 1 and Repeat is odd the pattern becomes (SP + !SP + SP… + SP) and the pattern has a very minor imbalance. Is that correct? [mh0322] Correct. I assume the MAC Client would be smart enough to avoid such situations, and we can always add a requirement for Repeat to be even when balanced pattern is expected. I can also add a condition check
into SD for SYNC_PATTERN MPCPDU processing to check for invalid values on receive side and discard known wrong combinations.
[drr] Correct me if I’m wrong but I suspect that the 1/257 bit imbalance is not an issue, otherwise we would need to scramble bit 0 of the 257b block. Given that the 64B/66B stream will be mostly all data there
will be a built in tendency to have more “1” bits than “0” bits. At least that’s how I read Cl 91.
4)
Slide 9/4th bullet – I see this answers my Q2. It seems odd to me that SP Index meaning should change for BD, you might want to consider always using SP Index = 3 for BD. [mh0322] I will document whatever TF agrees to at the end of the day, but math works simpler in this case.
5)
Slide 10/3rd bullet – definition of “a full set” is weak (will any 2 or 3 messages be OK regardless of how far apart they occur in the transmission stream?). I would suggest adding a requirement
that the SP messages be transmitted in order and in immediate succession. That way the ONU can avoid accidentally picking up SP1 from one message and SP2 or SP3 from a different definition set. This should be added to Slides 9 & 10. Another option would
be to add an SP_ID of 2-3 bits to the SP Info field to clearly id a full message set. [mh0322] “immediate” succession is hard to define, i.e., we might have corner cases where multiple messages are sent by the client down to the ONUs. I believe it is a more resilient design where ONUs wait to see
all expected SYNC_PATTERN MPCPDUs and do not try to register without them. More, we will actually make it impossible by not defining default values for the ONU side, i.e., ONU will not know what values to use for SP1/2/3 without receiving announcement from
the OLT first. Note that the transmission of individual SYNC_PATTERN messages is driven by the MAC Control Client, i.e., we would do not prescribe how quickly individual messages are sent, or how often.
[drr] I can agree with the idea that specific transmission time/order shouldn’t really matter, and certainly bit number of the index is insignificant. What’s important is that there is a way to ID which messages
form a set. I suggest we add a 2 or 3-bit field to do just that. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Dear colleagues, Attached please find the first pass at the at the Upstream Burst Delimiter and Sync Pattern Assignment proposal for the next TF meeting, including the format of the new SYNC_PATTERN MPCPDU, individual fields within the said message, as
well as a number of ONU and OLT behavior details expected. Please note that this is work in progress and comments / feedback are more than welcome. I would like to request a time slot during the next conference call we have scheduled so that I can go over
the deck as is, and address any questions and comments. When reviewing the deck, you will notice that the default values for SP1, SP2, and SP3 are currently marked as TBD on slide 3 and need a specific proposal. The remainder of the contribution does not change, irrespective of the actual values
assigned to SP1/2/3 elements. Regards Marek 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 |