Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_NGEPON] Upstream Burst Delimiter and Sync Pattern Assignment

Glen, 

In that case, do we rename the field from SP Balanced into something else to avoid implication that a balanced sequence is required?

Marek

On Fri, Mar 23, 2018 at 11:09 PM, Glen Kramer <glen.kramer@xxxxxxxxxxxx> wrote:

I would also like to add couple points here:

 

1)      ONU should not presume that it knows better than the OLT what constitutes a valid combination. If OLT provisions a highly imbalanced pattern, ONU has to oblige anyway. So, no other error checking for SYNC_PATTERN at the ONU besides the usual FCS.

2)      Duane is right. Odd length + balanced still will result in overall unbalanced sequence. That unbalance may be ok by itself. It is also possible that the next pattern (SP2 or SP3) will be unbalanced in the opposite direction, such that the entire sequence is balanced.

3)      Scrambled data does not provide balance guarantees. So, having perfect balance in the burst preamble may not be that critical either. For the default SP values we may try to find something balanced, just because we can, but OLT vendors should be able to select any other patterns that work for them.

 

Thank you,

-Glen

 

From: Marek Hajduczenia [mailto:mxhajduczenia@GMAIL.COM]
Sent: Friday, March 23, 2018 8:34 PM
To: STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: Re: [802.3_NGEPON] Upstream Burst Delimiter and Sync Pattern Assignment

 

Thank you, Duane 

 

Just focusing on the one point that might need some more discussion ... 

 

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.

 

[mh0323] Duane, you're making an assumption that the base 257-bit sequence is almost perfectly balanced. This might not be the case. The ability to transmit SP+!SP sequence provides a chance to send 514-long bit DC balanced sequence always, irrespective of the actual DC balance of the elemental 257-bit sequence. Think of a short example: (SP = 0000000001) + !SP = 0000000001 + 1111111110, which has a perfect DC balance. 

 

Also, the 257-bit sequence we use for SP pattern has nothing to do with data stream - we pick the sequence based on specific mathematical properties, and not its resemblance (or not) to regular data 

 

On Fri, Mar 23, 2018 at 3:36 PM, Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:

Marek, Mostly agree, two additional thoughts in-line. Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@gmail.com]
Sent: Thursday, March 22, 2018 4:44 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: RE: [802.3_NGEPON] Upstream Burst Delimiter and Sync Pattern Assignment

 

Thank you, Duane,

 

I had some expert help with Glen providing feedback.

 

More inline in red

 

Marek

 

From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Sent: Thursday, March 22, 2018 2:24 PM
To: mxhajduczenia@xxxxxxxxx; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Cc: Duane Remein <Duane.Remein@xxxxxxxxxx>
Subject: RE: [802.3_NGEPON] Upstream Burst Delimiter and Sync Pattern Assignment

 

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.


Note the “(see slide 7)” on 3rd sub-bullet might want to be “(see slide 8)”.

 

[mh0322] Fixed, Mark also noticed that and commented directly. Thank you


>16M bits for any sync pattern seems a bit excessive but the message isn’t tight for room so fine, I won’t quibble

 

[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@gmail.com]
Sent: Thursday, March 22, 2018 1:30 PM
To: STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: [802.3_NGEPON] Upstream Burst Delimiter and Sync Pattern Assignment

 

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