How To Save The Home Networking Industry

All: It will be interesting to see what this technology does to over-the-air FM and TV signals, once IM products are created in the wiring and all the devices on the wiring. In this case I suspect powerline transmission will be the most problematic, by the time the real-world condition of the switchmode power supplies on the line is taken into account. Those power supplies will be missing critical interference-suppression components, and the HDMI signals will mix in the rectifiers and other first-stage components of those supplies. The result will be effective radiated bandwidths considerably larger than what the device manufacturers claim. I am well aware that "the law" requires that such components to be installed; however, based on visual inspection, I can certainly assure folks that they are often left out of production units (after the test units are duly submitted to FCC testing labs for testing, and are duly certified as meeting the FCC's rules).

@Drew: Some numbers on the performance we can expect from G.hn at blog.ds2.es/ds2blog/2009/04/how-fast.html

Chano, When digital guys push their limits, let the analog-guys help clear the powerline and smoothen the paths for higher throughput. For example, with a little help from a patent-pending noise-isolator+lightning isolator technology, a connection-rate for HomePlug-AV-200Mbps at less than 30Mbps can be improved to more than 150Mbps (in simulation-tests) Google search with key words: cal-lab lightning isolator then go to BPL-PLC page or ask for email attachments as proof of latency and connection-rate screen shots.

@Drew, as you know, there are only two ways to increase the throughput of a communications system: a) increasing the frequency band or b) increasing the spectral efficiency. Any system that wants to increase performance vs existing technologies has to use option (a) or option (b) or both. G.hn allows you to use both. The good thing about the G.hn spec is that it does not force silicon vendors to increase complexity in both directions at the same time. Somebody can decide to use a wider bandwidth without increasing spectral efficiency, while other vendor can decide to focus on higher efficiency (bit/Hz) without extending the band beyond, for example, 50 MHz. G.hn defines common bands that have to be used to ensure interoperability is not compromised, while giving some room to vendors to optimize their designs. Finally, I don''t share your opinion that OFDM systems always have low efficiency. Compared to what? I don''t think you can find any modulation scheme that would operate more efficiently than OFDM over a heavily frequency-selective channel such as powerline, phoneline and coax.

Back to the performance question. One thing OFDM based technologies all share is very low throughput efficiencies. Look at HPNA with 320 Mbps PHY rate and 85 Mbps real-world data rates, and MoCA with 270 Mbps PHY rate and 110 Mbps data rates. G.hn only gets to higher PHY rates by specifying higher speed data converters, 500 Mbps PHY will require 14+ bit, 100 Mspl converters and the gigabaud PHY rate will require 200 Mspl converters. These converter speeds are pushing beyond today''s state of the art cost effective analog silicon technology. But even if you grant that the converters can be produced then what is significantly different with the G.hn PHY that will yield significantly higher throughout efficiencies? My guess is that we are going to end up with very expensive silicon that vastly underperforms.

@Solid Gold Suleyman: You are right that you cannot implement 100% of the MAC in software (my statement of "PHY is hardware, MAC is software" was an oversimplification). But typically, when implementing the MAC you can divide task in two "functional areas": the data path and the control path. The data path specifies how to do the encapsulation, fragmentation, reassembly, retransmission and encryption of MSDUs. This needs to be done at wire speeds, so it usually has to be implemented in silicon if you want to reach very high speeds. The data path is rather stable in G.hn. The control path is responsible for sending control messages between devices, deciding when each device has to start/stop transmission, etc. That part can usually be implemented in software, and this is the part that still needs to be specified in G.hn (although I don't anticipate that part to be very contentions).

Gomez - He was saying that the rates achievable in practice with G.hn will be far lower than the advertised speed; While the MAC can be implemented in an FPGA for high-throughput designs, this is only good for engineering samples (cost is too high). While you can implement a 1Gbps-rate MAC in software, you can't do it at a price point that is competitive for home networking. While he was probably a MOCAman, I think his points are valid. Let's see what happens when the MAC layer is frozen.

I am still trying out how to interface a Windows 98se, two Windows WP (through a router) and a printer with a USB connection. I am all for standards; however, I will not hold my breath for relief.

@SpareUsTheHype: I can tell you that "addressing the PHY" is not "the easy part". PHY layer is usually implemented in silicon, which means that any changes in the PHY require re-spinning new chips. That's why silicon vendors have a hard time agreeing on the PHY, and that's one of the reason why the powerline industry has been fragmented during the last 9 years. The MAC layer, on the other hand, is usually implemented in software, so new products can change their MAC to accommodate a new standard without silicon changes. Don't underestimate the effort required to agree on a common PHY. Not all members of G.hn were in favor of using FFT OFDM (some preferred Wavelet OFDM), in the same way that not all members favored using LDPC FEC (some preferred Convolutional Turbo Codes). It took more than a year for the group to agree on those decisions. It's not a small achievement: other groups in which I'm involved have been INCAPABLE of agreeing on a single PHY, and have instead a mix of several incompatible modulation schemes (both OFDM and Wavelet) and several incompatible FEC schemes (Turbo Codes, Reed-Solomon + Convolution, LDPC) plus several different MAC and security schemes. Finally, nobody expects to use QAM-16384 over powerlines (the SNR is not high enough on powerlines), so I don't quite understand your point there...

I hate to rain on the G.HN parade but the G.HN specification recently released only addresses the PHY layer. This was the easy part, all the PHY layer proposals were already 80% common between them being based on OFDM. The MAC is the contentious portion as each power-line networking company has their own unique implementation. G.HN is a marketing driven specification and not Engineering driven specification with specified performance not truly achievable in the real world. QAM-16,384 on power-line anyone?