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

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



Well this is what I would like to hear from the group. Personally I think that the mid size code exhibits the best trade off between simplicity and burst noise protection. It may change depending on the characteristics of the traffic we envision for the PLC. If we are not concerned with higher packet loss due to burst noise, short code can be compelling for it's very low complexity.

ב-7 במרץ 2013, בשעה 20:47, "Marek Hajduczenia" <marek.hajduczenia@xxxxxx<mailto:marek.hajduczenia@xxxxxx>> כתב/ה:

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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