Re: [STDS-802-3-EPOC] PLC FEC presentation
Avi,
And I assume the proposal is to use short code-words? I saw that in your
analysis you indicate that the short codeword is insufficient to guarantee
proper margins
Marek
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Thursday, 07 March, 2013 5:35 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] PLC FEC presentation
Marek,
This is easy. The latency is mainly determined by the number of symbols a
codeword take. The short code (48,24) would span over one and a half symbol
of 20 uSec, so latency would be about 40 uSec. A long code that would span
over 100 symbols, would have a latency of ~ 2 mSec.
Avi
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, March 07, 2013 4:39 PM
To: Avi Kliger; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] PLC FEC presentation
Avi,
Do you have any estimates on how much of a delay FEC would cause, given that
right now we would have to perform both code word and FEC word
synchronization?
Marek
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Thursday, 07 March, 2013 12:50 PM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] PLC FEC presentation
Marek,
The short code proposed or even the "midsize" code are very simple to
implement. I do not think that they are by any means comparable to the
complexity of the data FEC and interleaver.
As I indicated on the call yesterday, the guidelines for the PLC design were
higher layers requirements: minimal jitter, minimal limitations on the
frequency usage, and automatic downstream signal detection by the first time
connecting CNU. I believe that the proposed PLC provided these requirements
with a very little complexity.
Avi
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, March 07, 2013 12:43 PM
To: Avi Kliger; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] PLC FEC presentation
Avi,
Just one general comment - when we started the PLC discussions, the whole
concept was focused on a low-latency, low complexity channel that requires
no FEC, no interleaver and no fireworks to make it work under the worst
conditions. As we go along the path, I see more and more often FEC being
added to the mix. I understand we need margins to work effectively, but now
we are talking about a data link channel that is becoming increasingly
complex just to guarantee that we can exchange the ~1 Mbit/s worth of data.
The question then becomes. Can we come up with something different, that
does not require bidirectional communication prior to establishment of MAC
link and skip all the inherent complexity of adding FEC into PLC?
I am concerned that at the end we will have a similar level of complexity in
the PLC link as well as the main MAC link, making the whole idea of PLC just
unattractive to start with. Then it is just simpler to start the whole MAC
at a lower rate to begin with and forget about PLC altogether.
Marek
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Thursday, 07 March, 2013 7:29 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-EPOC] PLC FEC presentation
Attached.
Thanks
Avi
_____
_____
<="" 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