Re: [8023-10GEPON] [FEC] upstream lock status
All,
There was a question on the hamming distance that the various delimiters
could achieve. I had found delimiters of size 64 with a distance of 29.
Glen had found delimiters of size 66 with a distance of 30. The reason for
the difference is that the larger delimiter has more bits to play with, and
hence it is easier to find a bigger distance.
I have re-run my program with a 66 bit delimiter, and I have found several
patterns with a distance of 30, also. So, it seems the details of the
distance calculation are not critical, just the overall size of the
delimiter.
There was a question on the size, and why should it be so large. My
explanation for the admittedly large 66 bit delimiter comes from two
directions. First of all, I note that Ethernet framing design tends to lean
towards very conservative assumptions. If you look at designs from the
past, you find the objective 'mean time to bad things happening' is the
'lifetime of the universe'. (No joke - check it out.) So, I am just trying
to conform to the general approach in choosing a long delimiter.
Second, let's face it, that 66 bits is a very round number when it comes to
10G Ethernet. So, the two things just fall together nicely.
G-PON was mentioned, and that it works with a 20 bit delimiter. This is
true. The derivation of this is given in the recommendation G.984.2. The
general idea there is that a lost burst is considered to be just another
source of bit errors. So, the lost burst ratio need only be as big as the
acceptable BER, which in G-PON is 1e-10. You can see that 20 bits is just
enough to make this so, if the BER is 1e-4. Of course, the design approach
with G-PON was to minimize the burst overhead as much as possible, so we
went with this minimalist approach. But in Ethernet, we don't have the same
objectives, so I think the 66 bits is just fine.
Sincerely,
Frank E.
-----Original Message-----
From: Frank Chang [mailto:ychang@VITESSE.COM]
Sent: Monday, December 18, 2006 1:23 PM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] [FEC] upstream lock status
jeff; as we prewsent last time, FEC PCS will be in the lowest layer above
PMA. And OLT O/E Rx is receiving 10.3G rates which is already 64b/66b coded,
so I always assume FEC working on 66bit,
did I missing anything?
-----Original Message-----
From: Hajduczenia, Marek [mailto:marek.hajduczenia@siemens.com]
Sent: Monday, December 18, 2006 10:00 AM
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: Re: [8023-10GEPON] [FEC] upstream lock status
Dear Jeff,
I was discussing one discrepancy with Glen last week.
It would be worth while to clarify finally one aspect of the FEC operation -
are we going to operate on 64 or 66 bit code words.
Here I quote part of the email exchange from last week
"(...) it seems that FEC should protect entire 66-bit block, not 64 bits. If
we don't protect the first 2 bits (or at least one of these bits), we are
risking to confuse pure data blocks with control blocks. In other words, we
may not find where frame starts or ends, or think of block representing
idles as a block representing data, etc."
This makes a lot of sense since the FEC subplayer needs to be placed below
PCS which does after all encoding of 64 into 66 bit groups.
The frame transition may be defined therefore as follows:
ONU side
1) 64b -> 66b encoding in the PCS
2) Frame payload scrambler
3) FEC subplayer with codeword encoding + calculating and inserting parity
blocks
4) data detector subplayer
5) PMA -> PMD (Tx) (ONU side)
6) fibre channel (channel)
7) PMD -> PMA (Rx) (OLT side)
OLT side
9) Burst detector at the OLT side (frame synchronization, replace sync
pattern with idles etc.)
10) FEC subplayer - codeword decoding, retrieve useful data
11) Frame payload de-scrambler
12) 66b -> 64b block decoding in the OLT PCS layer
That is I believe compatibile with the discussion on the FEC sub-layer
placement and follows the suggestions put forward in the presentation by
Frank.
Now the big questio is whether the FEC codeword should be 64 or 66 bits. I
believe personally in the light of the discussion I had with Glen, that 64
bit codeword may put us in a situation when bit errors in a noisy channel
will eventually lead to misinterpretation of the initial two bits "10" of
the 66 codeword. This may lead to misinterpretation of the whole 66 bit
block and its effects are less than desirable.
Regarding the points You raise, here are my answers:
~
Issue 1: I think that I would be closer to version B, though what I am most
interested in is obtaining a good lock and have a good background for the
synch pattern. It may prove that 0x55 preamble pattern is also sufficient
properties for the good sync identification properties ...
101010101010101010101010101010101010101010101010101010101010101010 (66 bits)
[0 -> 0]
[1 -> 66]
[2 -> 0]
[3 -> 66]
[4 -> 0]
[5 -> 66]
[6 -> 0]
[7 -> 66]
[8 -> 0]
[9 -> 66]
[10 -> 0]
[11 -> 66]
[12 -> 0]
[13 -> 66]
[14 -> 0]
etc...
As You can see, the pure 0x55 pattern is periodic so there may be a tiny
problem unless we decide to modify it somehow ...
Issue 2: that depends on the answer to my question ...
Issue 3: B. That does not require us to mess with the standard data
transmission from the PCS towards the PMD/PMA
Issue 4: for now, no opinion. Need more time to examine them in more detail.
Best wishes
Marek Hajduczenia (141238)
SIEMENS Networks S.A. - IC COM D1 R
Rua Irmãos Siemens, 1
Ed. 1, Piso 1
Alfragide
2720-093 Amadora
Portugal
* Marek.Hajduczenia@siemens.com
http://marekhaj.easyisp.pl/index.php
(+351.21.416.7472 4+351.21.424.2082
-----Original Message-----
From: Jeff Mandin [mailto:Jeff_Mandin@PMC-SIERRA.COM]
Sent: segunda-feira, 18 de Dezembro de 2006 16:42
To: STDS-802-3-10GEPON@listserv.ieee.org
Subject: [8023-10GEPON] [FEC] upstream lock status
All,
Thanks to everyone for the productive and beneficial efforts in the FEC
framing telecon and reflector discussions last week.
The following seems to be where things stand vis-a-vis upstream lock.
Please let me know if something is mischaracterized:
One point for clarification: we have one proposal which says that finding a
64bit sequence with more than 29bits Hamming Distance is difficult. Another
proposal says finding one with the 30bits is straightforward. Is this
discrepancy due to having a slightly different objective - or perhaps a
different set of assumptions?
- Jeff Mandin
PMC-Sierra
Issue 1. Sync Pattern (for Gain Control and Clock Recovery at OLT):
----------------------------------------------------------------------------
------------------------
option A: Repeated 0x55 (ie. alternating 1s and 0s)
option B: Repeated newly specified 66b control block that will also
be used for aligning OLT receiver to 66b boundary. This codeword is DC
balanced for smooth AGC and scrambling is not employed. The control block
has maximum run length of 3, but CDR is might still in some manner be less
effective than with repeated 0x55. The sync pattern has Hamming distance of
at least 30 from all shifts of itself.
Issue 2. Burst Delimiter
-----------------------------------
option A: 64 bit "golden block" pattern (has Hamming Distance of 31
[or 29 anyway] from any shift of itself)
option B: 66 bit codeword with high Hamming Distance from Sync
pattern (eg. 64bit payload logically inverted)
option C (suggested on reflector): shorter "golden block" pattern
(similar to GPON) to reduce implementation complexity at OLT (if shorter
pattern meets system requirements).
Issue 3. Transport (ie. "framing") of sync pattern and delimiter)
----------------------------------------------------------------------------
---------------
option A: "leader frame" scheme -> pretty much ruled out by the adhoc
option B: sync pattern and delimiter words are carried in a datastream
of 66b blocks in which FEC and scrambling are disabled. FEC and scrambling
are activated in the transmitted datastream following
transmission of the FEC Codeword Delimiter 66b control block.
option C (from "superframe.ppt" proposal): Burst begins with Sync
Pattern and Burst Delimiter transmitted in unadorned manner. FEC and
scrambling
are activated in the transmitted datastream immediately
following transmission of the FEC Codeword Delimiter pattern.
Issue 4. OLT frame synchronization sequence
--------------------------------------------------------------------
option A: One-step locking in the following sequence:
* ONU transmits multiply repeated sync pattern on the upstream
* OLT performs automatic gain control
* OLT performs clock and data recovery sequence
* zero or more bits from the multiply repeated sync pattern are
received by the FEC/PCS layer at the OLT
* OLT PCS layer performs bit-by-bit correlation to compare the
received datastream to the FEC Codeword Delimiter pattern. When the
Hamming Distance between the received datastream and the FEC
Codeword Delimiter is less than "Threshold", then FRAME LOCK is declared.
* OLT expects the next received bit to be the first bit of the
first scrambled 66b block of a FEC Codeword
option B: Two-step locking in the following sequence:
* ONU transmits sync pattern blocks on the upstream
* OLT performs automatic gain control
* OLT performs clock and data recovery sequence
* One or more instances of the entire sync pattern block is
received by the FEC/PCS layer at the OLT
* OLT PCS layer performs bit-by-bit correlation to compare the
received datastream to the sync pattern block. When the
Hamming Distance between the received datastream and the sync
pattern block is less than "Threshold", then BLOCK LOCK is declared.
* OLT expects the next received bit to be the first bit of an
unscrambled 66b block
* OLT PCS layer performs block-by-block correlation to compare
the received datastream to the FEC Codeword Delimiter pattern. When the
Hamming Distance between the received datastream and the FEC
Codeword Delimiter is less than "Threshold", then FRAME LOCK is declared.
* OLT expects the next received bit to be the first bit of the
PCS data (putting aside the scrambler init issue for the moment)