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)