| 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 5:05 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Contribution on Data Detector and FEC Encode
for FDD CNU (upstream)
Marek,
Comments on Hajduczenia_3bn_05_1113.pdf
[mh0926] Thanks, that helps to set the frame of reference for which file
we're discussing .
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.
[mh0926] Fixed to 65-bit blocks. If you find any other issue with 66-bit
versus 65-bit, please let me know. I do not think it is a "pervasive error"
of any sort.
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.
[mh0926] I did not move this block under FEC encoding, so the whole argument
above does not hold. Data Detector and FEC Encoding are operated together
much as they were in 10G-EPON. We discussed an approach to moving it below
the FEC, but it does not mean that that is what the working assumption is.
Now, regarding the wording in line 15, I do not recall any concerns about
similar wording in published 802.3-2012, 76.3.2.5.1, third para, first
sentence. If there are concerns, we can clarify it to read "empty of data",
but it is only likely to attract more questions and concerns.
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.
[mh0926] Since we do not know the details of the burst as of yet, these are
TBD. This is an early draft of the text and it is only natural that some
aspects of the functionality are TBD.
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.
[mh0926] Let me try to deconstruct this aggregate of comments.
As a first order approximation, I think it is only fair to assume that burst
markers will be multiples of 65-bit or else we'd have to deal with
additional PCS jitter without any need. If you're concerned that we have not
agreed whether it is 1x65, 2x65 or how many blocks we need, I'd suggest we
look into what 10G-EPON selected (length-wise) which was proven to work fine
at 10^-3 BER pre-FEC. Only if evidence is collected that 65-bit marker is
insufficient, we should go and extend its size.
The notion of profiles remains pretty much in the air, and my focus right
now is on bring first draft text for further development.
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.
[mh0926] You're welcome to treat this "beast" then as a proposal. Given that
this contribution will come with a comment on D0.2, it carries the same
weight as a technical proposal of any sort. If the need for it is unclear, I
will be happy to prepare one slide with 2 sentences on it to explain why we
need it.
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.
[mh0926] These will become one and the same, essentially. For now, I will
remove all SDs and associated variables / constants to avoid from further
confusing you. My hope was that just following the subclause numbers it was
clear to see that these are the same SDs and definitions and that these will
be shared between CNU and CLT.
As for making FEC Encoder universal . it is a tempting notion, but I'd
rather have these separate for the time being and only merge them (making
them universal) when and if the group agrees to details included in this
proposal.
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="">
_____
<="" 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_05_1113 R02.pdf
Description: Adobe PDF document