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

Re: [STDS-802-3-EPOC] EPoC FEC operation writeup



And here is the diff file 

 

Marek

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] 
Sent: Saturday, August 10, 2013 3:57 PM
To: 'STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx'
Subject: RE: [STDS-802-3-EPOC] EPoC FEC operation writeup

 

Dear colleagues, 

 

Attached please find the updated version of the FEC writeup in clean and
diff versions. This version contains the following changes:

 

-          Incorporated text from BZ focusing on the definition of matrices,
LDCP code and extra information on LDCP encoding process

-          Updated figures to show CRC32 as carried within the payload
portion and calculated prior to the LDCP encoding (based on feedback from
the last call)

 

Please note that next week (around 15th of August) I would like to start
converting this text into Framemaker file format, including adding the first
pass through the state diagrams and associated definition of variables, so
that the contribution to the York meeting has a more formal look & feel when
we discuss it at the meeting. 

 

I would also like to bring the following areas into your attention ? these
need further discussion and decisions, likely at the York meeting:

 

-          FEC codeword synchronization mechanism (as discussed at the call)


-          Placement and type of CRC32 used to ensure the bit error
detection capability for the LDPC code

-          Operation of the upstream data path, including encoding and
decoding process. Right now, it is not clear (at best) how we signal the
type of FEC code and switching between individual code types we defined in
Table 101-2

 

Note also that this is the text and description that we will be discussing
and likely voting on, so I would appreciate people who care about FEC design
for EPoC spend 30-40 minutes to examine the proposal in more detail ahead of
the meeting.

 

Regards

 

Marek

 

PS. Diff version will follow in a separate email (email is too big)

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] 
Sent: Thursday, August 01, 2013 6:18 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] EPoC FEC operation writeup

 

Dear colleagues, 

 

Prior to weekend I added the downstream receive function for CNU. A few
items are missing, though, namely:

 

-          FEC codeword synchronization: we had some discussion before, but
as far as I can tell, not even remotely enough for me to write anything into
my document 

-          Data detector for CLT: right now, I am not sure whether it is
enough to reuse concepts from 10G-EPON or we need to do something altogether
different 

-          Scrambler / Interleaver ? I have not touched this topic even
remotely, since we have not even discussed it once ? 

 

Note also that I have not included anything on PLC FEC, since we have not
had any discussion as to where and how we define it. The discussion about
mini-MAC and mini-DBA in PLC in PCS on the call yesterday was a bit
unsettling but I am sure we will work out the details at the next meeting.
In either case, I do not have enough to start working on the PLC portion
within the PCS. 

 

The state diagrams will be added only when we settle on the principle of
operation described in words. 

 

Regards

 

Marek

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx] 
Sent: Wednesday, July 31, 2013 5:46 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: EPoC FEC operation writeup

 

Dear colleagues, 

 

Attached please find R02 of the document, that describes the FEC encoding
process for downstream (taking place within the CLT PHY). Since I have not
received any feedback so far, I am working under the assumption that
technical selection I did at individual stages are correct and I am moving
forward. During the next 7 days or so, I plan to add the associated state
diagram which describes the downstream FEC encoding process. Next on my work
list is the FEC decoding process for the downstream. 

 

I would appreciate any comments, preferably within the attached document. I
would also like to hear opinions for carrying the 32-bit wide CRC32 data, as
proposed in prodan_3bn_02_0713.pdf
<http://www.ieee802.org/3/bn/public/jul13/prodan_3bn_02_0713.pdf> . At this
time, I am inclined to have it carried in the last 65-bit block of parity,
where depending on the code we can have anywhere between 40 and 60 padding
bits, unoccupied by parity information. This information capacity is readily
available and can be used for extra CRC32 data.  I will include this as a
proposal in the next version of the document to be released next week and
then we can discuss it at the meeting in York in more detail. 

 

Regards

 

Marek

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx] 
Sent: Thursday, July 18, 2013 6:49 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: EPoC FEC operation writeup

 

Dear colleagues, 

 

As announced during the meeting on Thursday, 18th of July, I am beginning to
work on the writeup describing the operation of FEC in EPoC to move the
development of our draft forward. Since it is not yet ready for approval as
the baseline, I am sharing the editable version of the document in the
attachment. 

 

Please note that I am using data points adopted so far to drive the writeup.
Specifically, I am relying on
http://www.ieee802.org/3/bn/public/jul13/prodan_3bn_01a_0713.pdf as adopted
during this plenary meeting, for selection of the specific upstream and
downstream FEC codes for active CCDN. The text itself was largely formatted
after 76.3.2.4 in IEEE Std 802.3-2012, with all the necessary changes to
accommodate different FEC types, and providing description clarifications to
better address the specific requirements for EPoC. Moreover, I focus right
now on the downstream direction only. We will tackle the more complex
upstream case when we have all agreed on how the simpler downstream
direction works. I believe the incremental approach here will be better than
?let?s do everything at once? approach. 

 

Furthermore, there are a few questions associated with the bit packaging
into the payload and parity portions of the FEC codewords. 

 

Looking at the new Figure 101-1 in the attached document, you will notice
that 2 consecutive XGMII transfers are aggregated into a 64-bit block, and
then fed into 64B/66B Encoder, which produces a 2-bit sync-header. Each such
66-bit block is then stripped from the first bit of the sync header (bit
<0>), creating 65-bit blocks. A number of such 65-bit blocks (Q of them) is
then aggregated prior to handing them off to the LDCP encoder, together with
the W bits of padding to match the size of the payload section of the FEC
codeword. This information is used to generate the FEC parity. What happens
then is up for us to decide ? we have not discussed it before given that we
have never reached yet this level of detail before. 

 

We have several options to consider (including numeric examples for LDPC
(16200, 14400) code) appropriate for the downstream direction:

 

OPTION 1: do what 10G-EPON did, i.e., calculate the parity over 65-bit
blocks, but construct payload of complete 66-bit blocks. The parity is then
divided into 64-bit blocks and each is pre-pended with 2-bit sync pattern.
Resulting payload and parity information is then transmitted as a series of
66-bit blocks. Note that in this case, we calculate parity over 65-bit
blocks, but transmit actually 66-bit blocks. If we were to go this
particular way we would have the following numbers:

 

LDPC (16200, 14400) code; 16200 bits in codeword, 14400 bits in payload,
1800 bits in parity section

14400 bits / 65-bit/block = 221.54 blocks -> 221 blocks fit into the payload
completely (14365-bits). 35 bits padding will be needed to fill in the
payload of 14400 bits prior to LDCP encoding. 

1800 bits of parity divided into 64-bit blocks produces 28.125 blocks. If we
use 8 of the padding bits from the payload blocks, we can transmit parity
data in 28 blocks. 

Effectively, payload will include 221 blocks of 66 bit data carrying actual
data, 27 bits of padding, and 8 bits of parity. This amounts to 14586 bits
on wire. Parity will include 28 blocks of 66 bit data carrying parity data.
This amounts to 1848 bits on wire. In this process we increase the line rate
by 16434/16200 ~ 1.0144444 which is roughly 1.44%.

The actual data content in this case is (221 * 64)/16434 ~ 86.07%

 

OPTION 2: calculate the parity over 65-bit blocks, and construct payload of
complete 65-bit blocks. The parity in then divided into 64-bit blocks and
each is pre-pended with 1-bit sync pattern. The resulting payload and parity
information is then transmitted as a series of 65-bit blocks. Note that in
this case, we calculate parity over 65-bit blocks, and transmit data in
65-bit blocks. 

 

LDPC (16200, 14400) code; 16200 bits in codeword, 14400 bits in payload,
1800 bits in parity section

14400 bits / 65-bit/block = 221.54 blocks -> 221 blocks can be fit into the
payload completely (14365-bits). 35 bits padding will be needed to fill in
the payload of 14400 bits prior to LDCP encoding.

1800 bits of parity divided into 64-bit blocks produces 28.125 blocks. If we
use 8 of the padding bits from the payload blocks, we can transmit parity
data in 28 blocks. 

Effectively, payload will include 221 blocks of 65-bit data carrying actual
data, 27 bits of padding, and 8 bits of parity. This amounts to 14365-bits
on wire. Parity will include 28 blocks of 65-bit data carrying parity data.
This amounts to 1820 bits on wire. In this process we effectively decrease
the line rate by 16185/16200 ~ 99.91% which is roughly 0.09% data rate
decrease. The actual data content in this case is (221 * 64)/16185 ~ 87.39%

 

OPTION 3: forget about 64B/66B encoding altogether (and reverse one of the
decisions we took before). Receive data directly from XGMII in 32-bit chunks
and aggregate it into FEC codeword accordingly. Since we will have
interleaver developed, and operate over medium different than twisted pair,
or fiber, it is not clear whether 64B/66B encoding is really necessary in
coax environment. In this case, both the payload and parity would be
expressed in units of 32-bit blocks. 

 

LDPC (16200, 14400) code; 16200 bits in codeword, 14400 bits in payload,
1800 bits in parity section

14400 bits / 32-bit/block = 450 blocks even, which fit into the payload
completely (14400 bits are used).There is no padding needed prior to LDPC
encoding.

1800 bits of parity divided into 32-bit blocks produces 56.25 blocks. Since
we have no padding in payload to work on, we have to transmit 57 32-bit
blocks to carry parity correctly. This means we will have 24 bits of padding
in the last block. 

Effectively, payload will include 450 blocks of 32-bit data carrying actual
data with no padding. This amounts to 14400-bits on wire. Parity will
include 57 blocks of 32-bit data carrying parity data. This amounts to 1824
bits on wire. In this process we effectively decrease the line rate by
16224/16200 ~ which is roughly 0.15% data rate decrease. The actual data
content in this case is 14400/16224 ~ 88.76%

 

Performance-wise, seems that OPTION 3 is superior to other approaches, in
that it results in a very minute increase in the effective data rate out of
FEC encoder, and additionally, has the highest data content from three
options. 

 

Note also that in neither of these options I accounted for the extra CRC per
proposal from Rich, though it was intentional and not accidental. We have
not voted on it at this meeting and I will run the numbers again when we do.
Clearly, in Option 1 and 2 we could accommodate that in the payload padding
section (we have 35 bits extra, would need 32 to accommodate CRC32), though
in Option 3 we would need to go with some form of CRC24 to avoid further
increasing the data rate and go beyond the symbol boundries. Let?s examine
that later on, when we agree on the general approach to the downstream FEC. 

 

Regards

 

Marek Hajduczenia, PhD 

ZTE Portugal 
Standard Development and Industry Relations
Edifício Amoreiras Plaza, 
Rua Carlos Alberto da Mota Pinto, nr. 9 - 6 A, 
1070-374 Lisbon, Portugal 
 
Office: +351 213 700 090
Fax: + 351 213 813 349
Mobile: +351 961 121 851 (Portugal)

 

  _____  

<="" p="">


________________________________________________________________________

To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1

Attachment: FEC Transmit for EPoC R04 diff.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document