| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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) ________________________________________________________________________ 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 R01.docx
Description: FEC Transmit for EPoC R01.docx