Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-3-EPOC] Contribution on Data Detector and FEC Encode for FDD CNU (upstream)



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