Re: [STDS-802-3-EPOC] Contribution on Data Detector and FEC Encode for FDD CNU (upstream)
Marek,
Comments on Hajduczenia_3bn_05_1113.pdf
Pg 29 ln 4 you state the FIFO_FEC_TX stores 66-bit blocks but in the definition of this FIFO_FEC_TX it states it stores 65b block, which I suspect is correct. This seems to be a pervasive error, please check each instant of 66-bit for correctness.
Pg 29 lin 15 you describe the FIFO_FEC_TX becoming empty as containing only IDLE but this cannot be true because it will always contain IDLE and Parity (depending of course on the size of the FIFO. IT strikes me a counter intuitive that we have moved this block to below the FEC encoding. After all if it were above the FEC you could use it to turn off the FEC encoder and gain some "greenness" (an objective that has yet to be addressed by anyone in the TF despite earlier instance that we include this in our objectives). Perhaps we should rethink this? Also of note is that this is no longer the only source of data to be transmitted, we have a whole other path (the PHY Link) that can source data independent of this MAC data path and the CNU transmitter will need to be turned on by that data source as well.
Was any of the above part of your thoughts in the phrase "and to allow transmission of any additional burst elements, such as TBD"? IF not I have not idea why this is there and would suggest striking it.
Pg 29 ln 33 Where did the phrase "begins with the 65-bit long Start of Burst delimiter (burstStart constant, see TBD)" come from? As far as I recall no one has discussed the actual length of a burst marker yet. If this refers to a burst marker please rephrase the para as follows: "The CNU burst transmission begins with a {TBD}-bit long Start of Burst delimiter (burstStart, see TBD) which facilitates the detection of the start of an incoming data burst. When received at the CLT, this delimiter simplifies in FEC codeword alignment, even in the presence of bit errors. The Start of Burst delimiter is not part of the first FEC codeword." Note that in Orlando we indicated a Burst Marker codes to the profile and can therefore not be a constant.
Pg 29 ln 38 Where did this "65-bit long FEC Selector delimiter" originate? As far as I recall no one has proposed such a beast. Please strike this para. Also remove the field from Fig 101-1.
Pg 29 ln 42 please change the "65-bits long" to "{TBD} long"
Pg 31 ln 1 - Is there really any fundamental difference between the US & DS FEC encoders? It seems to me that it would be much easier to describe the FEC encoder/decoder agnostic of direction and location rather than describe the same encoder twice and the same decoder twice with the inherent risk of more errors. Can these be consolideated into one encoder section and one decoder section? All the constant and variables are the same as those in Hajduczenia_3bn_04_1113.pdf and shouldn't be repeated in this section.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Thursday, September 26, 2013 9:52 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-EPOC] Contribution on Data Detector and FEC Encode for FDD CNU (upstream)
Dear colleagues,
Attached please find a contribution addressing the Data Detector and FEC Encode functions for FDD CNU. There is also an initial contribution to the burst structure for FDD CNU. Note that it is a very rough draft and a lot of questions have not been yet addressed, especially related to the burst structure. Note also that the burst structure is presented from the PCS layer perspective, without going into the physical layer details such as pilots, exclusion bands, etc..
Furthermore, since I do not know what the group's feedback is, I did not prepare the ONU state diagram at this time. Before I spend time on this, I would like us to agree first on the overall burst structure and encoding process, which I can then take over and produce the state diagram on.
I will be submitting this contribution through a comment on draft D0.2, and not as a stand-alone contribution. I am attaching the PDF file and the Visio file ith the burst structure figure for your reference.
Your comments and suggested changes (if any) would be most welcome.
Marek Hajduczenia, PhD
Network Architect, Principal Engineer
Bright House Networks
Office +1-813-295-5644
Cell +1-813-465-0669
________________________________
<="" 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