| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
[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.
[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.
[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.
[mh0322] I will document whatever TF agrees to at the end of the day, but math works simpler in this case.
[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. 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 |