Re: [STDS-802-3-EPOC] EPoC FEC operation writeup
Hi Sanjay,
Thank you for the feedback.
I will be more than happy to rip up anything that is not needed, but right
now my working assumption (given the lack of indication to the contrary) is
that PMA is still a digital interface, i.e., we feed data blocks there and
PMA then deals with conditioning digital signal for OFDM transmission. Since
we are largely missing the infamous ?data flow? chart, and associated
decisions, I do not want to make further dramatic changes into the diagram
without an association decision from the TF.
As for 64/65 bit blocks ? I would suggest that you consult 10G-EPON design.
I tried to explain this on the last call but without understanding how it is
done in 10G-EPON, it is hard to make references to decisions and justify
them. I ?borrowed? the concept from there and I am not doing anything
different (apart from using 65 bit block in place of 66 bit blocks
transmitted in EPON). Note also that RS(255,223) as used in 10G-EPON does
show individual data blocks at the output for proper transmission into PMA.
While we may choose to get rid of PMA altogether, it would be advisable to
leave it as a digital interface for maximum implementation flexibility.
Table 101-1 and 101-2 were already updated accordingly to account for
transmission of CRC32 as part of the payload. If there is something wrong
with them, please indicate and I will be happy to fix / explain the
calculations. For now, the numbers match as far as I can tell and there is
nothing that I believe I need to change. Also, I am not sure why CRC32 would
need to be shown in Table 101-1/2 ? its size is known , and position is
described in the figure and text ? showing a fixed size field of 32 bits is
rather not very productive ?
Regards
Marek
From: Sanjay Goswami [mailto:sanjay.goswami@xxxxxxxxxxxx]
Sent: Monday, August 12, 2013 5:33 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: 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
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="">
_____
<="" 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