How fast can G.hn be?

"How fast is G.hn?" That's a question I usually get from people interested in the standard promoted by HomeGrid Forum, and until recently it was difficult to provide an exact response. The reason is that the actual throughput provided by any communications technology is heavily dependent on both the PHY (Physical Layer) and DLL (Data Link Layer) design. A system can have a very high speed PHY, but if the MAC is not efficient, a significant part of the network capacity will be lost to protocol overhead.

Although the PHY for G.hn is described in Recommendation G.9960, which received consent in December 2008, the most important aspects of the DLL have not become stable (ie, become "baseline", using ITU-T terminology) until April 2009.

With both PHY and DLL in place, we can now work out some numbers to estimate how fast a G.hn implementation could run in theory.

Although in "real life" performance will be reduced by signal attenuation and background noise, having an upper bound on the maximum throughput that might be required from a G.hn transceiver is an important metric for system architects designing a G.hn-enabled device, as this has an impact on the choice of microprocessors, system interfaces, memory, etc. The purpose of this post is to provide a "worst case" for system architects (the "worst case" for a system architect is actually the "best case" for the user...)

Specifically, we'll focus on a G.hn transceiver operating over coaxial cable, in base-band, and using the 100 MHz band-plan (which in reality uses OFDM 450 carriers from 2 to 90 MHz). We assume that the Signal-to-Noise Ratio (SNR) is such that we can use the maximum allowed modulation (12 bits/carrier, or 4096-QAM). The LDPC FEC rate is 20/21 (the highest available), the FEC block size is 540 bytes (the largest available) and the payload OFDM Guard Interval is 1.28μs (the default value). (For an introduction to the G.hn PHY, see the HomeGrid Forum Webinar "G.hn Technology Overview")

We'll assume that we are flooding the transceiver with maximum-length Ethernet frames (1518 bytes including CRC), and that the transceiver is aggregating up to 100 Ethernet frames in a single G.hn MPDU (as we'll see later, this produces a 1.5872ms PHY Frame in the line).

Factors we are ignoring (and which will reduce throughput a bit): the time spent sending ACK messages from the destination to the source, the Inter-Frame Gap between any two transmissions, the time devoted to control messages, etc. Estimating this effect will be the subject of a future post.

This is how a first-order estimation can be made:

1. We start with an Ethernet frame (1518 bytes)
2. We add the MAC Frame Header (3 bytes), and we get a 1521-byte MAC Frame.
3. We encrypt the MAC Frame, which requires adding a 6-byte CCMP header and a 4-byte MIC, and we get a 1531-byte encrypted MAC Frame.
4. We put 100 encrypted MAC Frames together and get a 153100-byte MAC Frame block.
5. We divide this into 532-byte segments, for a total of 288 segments. (We'll ignore that the last one is not really full-size.)
6. We add a 4-byte header and a 4-byte Castagnoli CRC to each segment and we get 288 PHY Blocks of 540 bytes each.
7. We encode each PHY Block with the 20/21 LDPC FEC to get 567-byte coded PHY Blocks.
8. We now have 288 coded PHY Blocks of 567 bytes each, for a total of 163296 bytes, or 1306368 bits.
9. We map these bits into the 450 active carriers, putting 12 bits/symbol in each. We need a total of 242 OFDM symbols.
10. We now add a preamble (which has an equivalent length of 6 OFDM symbols in coax) and a PHY header (1 OFDM symbol), and we get a PHY Frame with a total length of 249 OFDM symbols.
11. Each OFDM symbol has a "payload duration" of 5.12μs and a Guard Interval of 1.28μ, for a total duration of 6.4μs.
12. Then, transmitting the 249-symbol PHY Frame takes 1.5936 ms.
13. If we stop at this point, we can see that we have effectively transmitted 100 Ethernet Frames, at 1518 bytes each, for a total of 151800 bytes, in 1.5936 ms. This gives an Ethernet-level data rate of 762.05 Mbits/s.

Another interesting figure is the maximum line data rate, which in this case we define as the number of bits transmitted in the line in the duration of an OFDM symbol. This represents the data rate at which bits are input to the LDPC decoder and is thus an important metric for system designers. This can be easily calculated as follows:

1. In each OFDM symbol, we have 450 active carriers, and each one can carry 12 bits/symbol.
2. The OFDM symbol has a total duration of 6.4μs
3. This gives a line data rate of 450*12/[6.4μs] = 843.75 Mbit/s

And now the disclaimers...

The numbers above estimate how fast a theoretical implementation could run, and not how any specific device will run. In reality, it's common in any standard that the first generation of products performs below the maximum allowed by the specification, and subsequent generations improve performance. Also, device vendors may decide to reduce data rate in order to improve other metrics like silicon complexity or power consumption.

Things that will reduce the data rate from the numbers given above:

• Using narrower band-plans: For example, a G.hn device may use a 50MHz band-plan, instead of a 100MHz band-plan, reducing data-rate roughly by 50%. Use of even narrower frequencies is also possible (and in some cases, mandatory due to regulation - this is the case in Japan for powerline).
• Operating at lower Signal-to-Noise Ratio (SNR): the number of bits-per-carrier is directly dependent on this parameter, so a system with a lower SNR (either because the communications channel is noisy or because of imperfect transmitter/receiver design) will achieve a lower data-rate. This is common in media with more noise than coaxial cable, such as power lines. When operating over power lines, systems usually operate with low SNR.
• Operating with lower FEC rate: in the example we have used rate 20/21, but G.hn also includes 16/18, 5/6, 2/3 and 1/2. For example, using a 1/2 rate would reduce data rate roughly by half.
• Operating with reduced power levels: this is related to the previous point on SNR. G.hn devices may have to operate with different power levels depending on local regulations. For example, power levels allowed in power lines by FCC Part 15 below and above 30 MHz are different, so it's expected that in power lines the SNR obtained above 30 MHz will be lower than below 30 MHz.
• Notches: although not required for operation over coaxial cable (as the cable is shielded), for operation over power lines and phone lines G.hn specifies that amateur-radio frequencies must be notched out. This reduces the amount of carriers available to G.hn.
• Line noise: although in general the FEC is responsible for correcting bit errors created by line noise, in some cases the disturbance created by noise is so strong that the FEC cannot correct all errors, and a segment has to be retransmitted using an ARQ protocol, thus reducing  the effective data rate.
• Limits on channel usage time: in the example above, the PHY Frame took 1.5936ms. If that time is too long for certain applications that may require shorter latency, then the PHY Frame would have to be shorter, and the relative overhead introduced by the preamble and header will be more significant.

And now, things that could increase the data rate:

• Using a shorter Guard Interval instead of the default value (G.hn permits a Guard Interval as short as 0.16μs over coaxial cable) would increase the data rate by up to 20%.
• • Note: In fact, using a 0.16μs Guard Interval is how G.hn can achieve a line data rate of 1 Gbit/s (more exactly: 450*12/[5.12μs + 0.16μs] = 1.02 Gbit/s).
• Aggregating more than 100 Ethernet frames per PHY frame would increase the data rate slightly.
• Optimizing the number of transmitted PHY Blocks based on the amount of bits that fit in one OFDM sysmbol would increase performance slightly by minimizing padding.
• Using a wider band-plan: G.hn includes a 200MHz-wide bandplan for RF coaxial to be used in Japan only.
• Using different media in parallel: for example, sending different data streams over power lines and coaxial cable at the same time.

Even if a vendor produces a perfect G.hn implementation, with all the bells and whistles, there are application-level parameters that will affect the performance experienced from the point of view of the user. For example, in a file-sharing application, multiple bottlenecks can be created by the host Operating Systems, network drivers, hard-drives, TCP/IP protocol, Application-layer protocols, etc.

Given the numbers above, should we expect to see +700 Mbit/s G.hn products soon? Looking at other extensible standards with optional features can provide some perspective on what is likely to happen with G.hn:

• 802.11n, the proposed amendment to IEEE 802.11-2007 wireless standard, includes multiple streams and wide frequency channels to achieve increased throughput. 802.11n has not been officially approved, but multiple products based on stable drafts of 802.11n are available in the market.
• Although the 802.11n amendment supports up to 600 Mbit/s with a 4x4:4 configuration (ie: 4 transmit antennas, 4 receive antennas, 4 simultaneous data streams), most common configurations for 802.11n devices are 2x2:2 (2 TX antennas, 2 RX antennas, 2 streams), 2x3:2 (2 TX, 3 RX, 2 streams) or 3x3:2 (3 TX, 3 RX, 2 streams). Any of those 2-stream configurations will provide a maximum data rate of 300 Mbit/s. As technology improves, configurations with 3 or 4 data streams will appear in commercial products. These configurations improve performance without having to update the standard itself. See "How does 802.11n get to 600Mbps?" for an overview of the different options available to 802.11n.
• Although 2 streams are mandatory for most 802.11n devices, handsets are not required to have more than 1 stream in order to save battery life.

Something similar is likely to happen with G.hn products: first generation products may not implement all the band-plans and all the options included in the standard but as technology improves, vendors will come up with faster products that will include more options, all without having to update the G.hn standard itself and without creating interoperability problems.

Also, vendors may come up with G.hn products (for example, home automation devices) for which low power operation is more important than maximum performance. Those devices will operate with reduced data rate, similarly to how hand-held 802.11n devices only support only data stream.

This scalability is one of the reason why G.hn is a future-proof standard that will be capable of supporting the needs of the wired home networking industry for many years.

Related blog posts on G.hn:

• HomeGrid Forum publishes white paper on G.hn compatibility with existing home networking technologies
• DS2: Driving Industry Standards
• G.hn keeps making progress

Request more information on DS2's G.hn products for next generation home networking over power lines, phone lines and coaxial cables