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

Re: [STDS-802-3-EPOC] PLC FEC presentation



Avi, 

 

Taking all of this into account, which of the options you showed on slide 3
would you then recommend to use for PLC ?

 

Marek

 

From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx] 
Sent: Thursday, 07 March, 2013 5:49 PM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] PLC FEC presentation

 

Marek,

 

Short codes provide very good margins for frequency notches. If we want
margins for burst noise we should have longer codes. They would span, I
would assume, over eight symbols (need to verify with simulations, could be
less), that is ~ 100 uSec latency. Depending on the nature of the PLC
traffic we may decide that it doesn't need be protected against burst noise
(I think 10 Hz is a burst noise rate assumed in some documents).    

 

Avi

 

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx] 
Sent: Thursday, March 07, 2013 7:42 PM
To: Avi Kliger; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: 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