On the issue of G.hn's FEC

On March 25th, Rick Merritt at EE Times published a story about how some members of the home networking industry are not happy with the decision taken by G.hn to use Low-Density Parity-Check (LDPC) Codes as the Forward Error Correction (FEC) scheme for the standard.

The fact is that, for every single piece of the G.hn standard, you can always find somebody unhappy with the specific option chosen by G.hn. Anywhere you look at, from the modulation scheme (why OFDM and not Wavelet or UWB?), the frequency bands (why 0-100 MHz and not 50-250 MHz?), some OFDM parameters (why a carrier spacing of 24 kHz and not 19.5 kHz?), etc... you can find at least one member who thinks that G.hn didn't make the right choice (which is another way of saying that G.hn didn't choose what that specific member wanted).

G.hn, as all ITU-T standards, takes decisions based on consensus (but not always unanimity). When a G.hn member thinks that a decision is incorrect, then they come to the next G.hn meeting with dozens of pages of detailed simulations and performance analysis showing where the mistake was made. The group analyzes it and if they are convinced by the evidence, then they implement the change.

The G.hn group has spent months discussing the issue of which was the best FEC scheme for G.hn. Considerations included issues like:

• Performance in a "clean medium" vs a "noisy medium".
• Minimum Signal-to-Noise Ratio (SNR) required to provide a Block Error Rate (BLER) of 10^-6 or 10^-8 (which is key for services like IPTV which are sensitive to jitter caused by retransmissions)
• Ability to operate at very high data rates: a FEC that works well at 100 Mbps may not scale well to 1 Gbps (unless one is willing to increase system clock frequency and power consumption significantly)
• Capability to work well with both small and large block sizes
• Capability to provide different "code rates" (for example: 1/2, 3/4, 5/6, 20/21, etc) so that the network can increase or decrease the error protection capabilities of the FEC depending on channel conditions.

After considering all these factors and having multiple companies running simulations for months (you need dozens of computers running 24h/day for several weeks to simulate performance with a BLER of 10^-8), the G.hn group made a final decision on the FEC scheme, and included it in the consented Recommendation G.9960.

The same basic FEC scheme is also used in other well-known standards such as 802.11n (Wi-Fi), 802.16e (WiMax) and 10G Ethernet.

Another issue raised in the EE Times story is that fact that the FEC scheme used in G.hn is not compatible with one specific powerline technology. Although the story didn't mention it, the fact is G.hn FEC is not compatible with any of the other four existing wired networking technologies. So what?  If G.hn tried to be compatible with all of the existing wired technologies that have shipped millions of devices into the market, then it would have 5 different modulation schemes, 5 FEC schemes, 5 security schemes, 5 MACs, 5 of everything. That would be the best way to make it the most complex standard ever designed. But G.hn is about simplicity (one PHY and one MAC that works anywere) so the group decided early on that they didn't want to follow that path.

After being involved in G.hn meetings for more than a year, I'm convinced that the experts working on G.hn have made the right choices, not only regarding the FEC scheme, but also in the rest of the standard.

UPDATE: The HomePNA blog also has a very interesting post on this very same issue.

Comments

[Ken Krechmer]

I appreciate Mr. Gomez's, vantage point (it helps that he attended the meetings) explanation and position. But...

When systems are microprocessor based and storage is very low cost, the concern that there is only one variation of a standard seems small, relative to obsoleting millions of existing implementations. Of course, individual manufacturers who have implemented different variations of home networking will likely design new equipment that supports their version as well as G.hn. But it would be more forward looking if G.hn provided such a capability for all manufacturers.

[Chano Gomez]

Dear Mr. Krechmer:

In fact G.hn gives any manufacturer the capability of implementing a device that supports G.hn in addition to any other variation of home networking spec.

But it's up to each specific manufacturer to decide which version they want to implement (in addition to G.hn). The reason is that different vendors address different markets with different needs. A silicon vendor may decide to do a dual mode G.hn/UPA chip, another may do a G.hn/HomePNA chip, another a G.hn/HD-PLC chip. G.hn has mechanisms to ensure both networks (G.hn and the legacy network) can operate in parallel over the same medium.