Re: [STDS-802-3-EPOC] EPoC FEC operation writeup
Hello Marek,
Thank you for putting all this together. I will be on a flight back home on Wednesday and will not be able to attend this week's call. I am providing my feedback through this email.
As I mentioned in last week's call, it is not clear to me why the 65 blocks need to show up after the data has been passed on to LDPC encoder. After the LDPC encoder we should have code words only. Each code word has payload and parity. e.g. when we show 64/65 blocks we don't show Ethernet frames. It is assumed that the Ethernet frames are part of these 64/65 blocks.
If we agree, then Table 101-1 and Table 101-2 will only show parity bits and no further division of those parity bits. Also Figure 101-1 will not show 65 bit blocks after the LDPC encoder. Similarly, Figure 101-2 doesn't need to show 65-bit blocks and padding bits prior to LDPC decoder. Also Figure 101-2 has a typo after the LDPC decoder. It should indicate Output from FEC decoder, right now its saying Input for FEC decoder. The corresponding text describing the process will also change accordingly.
You might also want to show the CRC-32 as a separate column in the Table 101-1 and Table 101-2. The remaining padding bits in the payload might need to be corrected accordingly.
Regards
Sanjay
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Saturday, August 10, 2013 8:03 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: 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<mailto: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<mailto: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<mailto: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="">
________________________________
<="" 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