| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Duane, Please find my answer inline. R02 with changes as discussed below is attached for further discussion Marek Hajduczenia, PhD Network Architect, Principal Engineer Bright House Networks Office +1-813-295-5644 Cell +1-813-465-0669 From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx] Sent: Thursday, September 26, 2013 3:27 PM To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx Cc: Duane Remein Subject: RE: [STDS-802-3-EPOC] Contribution on Data Detector and FEC Encode for FDD CNU (upstream) Marek, The table references in this do not match those in the draft and are not marked as changed. Please fix this. [mh0926] I would welcome specific details here - as far as I can tell, they do match content of P802d3bn_d02.pdf that was published as the official draft. If I missed any, please provide page / line information. I'll be more than happy to fix these. There appears to be a struck space before FEC Encode pg34 ln 45 that is needed. [mh0926] Duane, you responded to the email on CNU-focused contribution, which came with the file "hajduczenia_3bn_05_1113 R01.pdf". However, you comment on "hajduczenia_3bn_04_1113 R01.pdf" instead which covers the Data Detector and FEC Encode for CLT downstream. For the future, please reference which file your comments are on - it is hard to figure that one out. In that file, I am not sure why Frame shows the space as struck - after accepting all changes, text reads OK in frame. I made sure it will not show as modified in the future. I would suggest the following rewording on pg 34 ln 47; Change from: "... the redundant first bit (i.e., sync header bit <0>) in each 66-bit ..." to: "... the redundant sync header bit <0> in each 66-bit ..." [mh0926] This text comes from published draft and I would suggest you comment on draft on this one. I prefer personally the text as it is. On pg 34 line 52 you have "(see )", You have a header for this section please provide the xref. [mh0926] inserted as suggested - the problem is related to the missing level 6 cross-reference definition I have been asking for some time . Pg 35 Ln4 would probably read better if you struck the first "resulting" in the 1st sentence in that para. [mh0926] Alternative edit was made. In the 2nd sentence of this same para you end with ", complementing it." Personally I have no idea what this is supposed to mean and it needs to wither be clarified to removed. [mh0926] If you follow the logic of what is happening carefully, you'll see that a 65-bit block is filled with 40 bits of CRC40 first and the remaining 25 bits come from FEC parity. The FEC parity bits in this case complement the 65-bit block. Pg 35 ln 13 you say "are then transferred towards PMA", this would be better stated as "are then transferred to the PMA" (also in line 14 & 16). [mh0926] I do not see a difference in here - seems like a personal preference to me. I would suggest a comment on D0.2 to have it modified in published D0.2 version. You also end this sentence with "one 65-bit block at a time". Which implies if someone does this two blocks (or any other number) it is not compliant. Please strike this as we really don't care about the number that are transferred at a time. [mh0926] Actually we do, once we get to define the interface into PMA in more detail. The working assumption out of the York meeting is that the PMA interface will be 65-bit block-oriented, in which case my statement is correct. In Figure 101-1 There are some stray bits in the 65b block overlapping the FEC parity, I'm assuming these are the padding mentioned in the text but it is not clear. If my assumption is correct please add an indication that this is padding. [mh0926] please read the text on page 35 lines 5-7 which I believe explains what these are and what their purpose is. I think it leaves no place for assumptions . Pg 37 Ln 10 Constants - I don't see how these can be constants when you have 3 or four FEC codewords to choose from. At some point before encoding you will need to decide which FEC is to be used and at that point you need to "set" these constants, Hence in the math I was taught they are variables. This may be too big to fix completely in this submission but we will need to address this. I suggest moving these to the Variables sub-clause with an editor's note that we need a state diagram to set these when a FEC encoding is selected. [mh0926] They are constant as far as the operation of the state diagram is concerned, i.e., we do not modify their values once the SD operation has started. In that respect, these are constants as opposed to variables, which represent calculated values, counters, etc. Pg 38 ln 13 SH_CTRL & SH_DATA are listed as constants in CL 76 here you have them as variables. We probably need a new name for these if they are variables. [mh0926] Fixed, you're correct here. Pg 38 ln 29 another "towards" that should be "to". [mh0926] Here I am OK changing it as suggested. Pg 38 ln 34 I don't see a definition of ARRAY_IN, please add. [mh0926] It is a parameter for a function. Defining it would be at best redundant . 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
Attachment:
hajduczenia_3bn_04_1113 R02.pdf
Description: Adobe PDF document