| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Ã? [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.  We should specify in the draft that SYNC_PATTERN MPCPDUs should be sent before DISCOVERY GATE. The reason is that we have a fixed minimal delay to process the MPCPDUs (see the definition of MpcpProcessingDly). For a GATE MPCPDU, it is very easy for the ONU to see if the message is late and to reject a late message  (StartTime â?? LocalTime < MpcpProcessingDly, see Fig 144-15). For the SYNC_PATTERN, there is no way for the ONIU to know that it is late (or even what â??lateâ?? means for this message) , and no way for the OLT to determine whether the ONU had enough time to process and store the new patterns, as there is no (and cannot be any) confirmation from the ONU.  If we require that SYNC_PATTERN is sent before the DISC. GATE, that would also imply that the ONU has even more time to process the SYNC_PATTERN MPCPDU than the minimum time it has for processing the DISC. GATE.   I donâ??t think we should require that all 2 or 3 SP messages are sent back to back, just like we donâ??t require that multiple GATEs for the same burst are sent back to back. This is up to the OLTâ??s downstream scheduler.  Thank you, -Glen  From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]  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 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 |