HomePNA Blog

Is G.hn a Home Networking Standard Yet?

By Rich Nesin, General Manager and Resident Philosopher, HomePNA

So is G.hn a Home Networking Standard Yet?  You betcha.  Can you download it from the ITU's website yet?  Not quite but soon.

If you missed it don’t feel too badly but definitely pay attention. After about two years the ITU Q4/15 has Consented (I believe that’s with a big “C”) the remainder of G.hn. If you recall, the ITU Consented the PHY, G.9960, in December 2008. After Consent, the ITU kept itself busy with their finalization process which, for the PHY, resulted in Approval last October. Approval means they can print it and you and I can download it directly from the ITU’s website. Last week the ITU Consented the Data Link Layer (DLL) Recommendation G.9961, the remaining big piece of the pie.

Will we see another press release announcing Approval of G.9961 in June as planned? Could be. Either way it’s an impressive piece of work done in a comparatively short amount of time and the authors deserve a lot of credit.

So what exactly is G.hn? (Yes, I know it’s the greatest home networking standard ever written.) In the ITU, G.hn is a group of people representing companies that paid money to participate in the ITU standards development process and an editor. The G.hn group is actually the same one that developed the HomePNA 3.1 standard Recommendation G.9954 1-07.  Going forward, I'd wager that a G.hn product will be one that is designed in compliance with the four recommendations (G.9960 G.9960 Amendment 1, G.9960 Corrigendum 1 and G.9961) which, when taken together, comprise the G.hn standard today. As with other standards like the IEEE's 802.11 a, b, g, n, ..., I expect it will continue to evolve and be known by equally incomprehensible taxonomy.

G.hn Home Network Standard – Not Quite Smooth Sailing

By Rich Nesin, General Manager and Resident Philosopher, HomePNA

Well fun times for all you ITU G.hn watchers. As I wrote back in June, G.hn has settled on some "Baseline Text" for most of the protocol pieces that lie upstream of the G.9960 G.hn PHY (which anybody that follows G.hn can tell you was consented last December). So … here’s to more smooth sailing in the standards body. Did I hear a “not quite”? True, the group is moving briskly toward consent at the September 28 to October 9 meeting in Geneva , however it seems everyone isn’t running in the same direction.

So what’s happening? It’s gotten more contentious, that's what. At the G.hn meeting in Concord, Ca last week, some of the attendees (guess who) introduced a contribution to add compatibility between HomePlug and G.hn. If you’ve been following the evolution of the standard, you probably remember the decision made long-ago to work for co-existence with existing technologies, not compatibility. That decision was pragmatic and probably prevented a HomePlug-UPA-HD-PLC-MOCA-HomePNA (did I leave anyone out?) shootout that could have killed, or at least maimed, the new G.hn all-wire standard effort. The changes proposed last week would have affected both the MAC and PHY in fairly significant ways and may have posed a problem for the one chip-all wire goal.

Anyway, to make a long story short, the group’s historical reticence to require compatibility with other home networking technologies combined with major angst over anything that could delay completion of the final drafts caused even some participants who planned to stay neutral at the meeting to dissent. The contribution was presented, debated, dissected, debated some more and, in the end, fell far short of consensus for technical and practical reasons. Is it smooth sailing from here on? Can’t say for sure as all eyes (or at least the ones that care enough to read this blog) turn to Geneva. It’s not over till it’s over and then the market will decide.

ITU's G.hn Keeps Sailing

By Rich Nesin, General Manager and Resident Philosopher, HomePNA

It was easier to get a scoop in the old days when I could count the number of G.hn evangelists on no hands. Now-a-days it’s hard – what with friends and colleagues at other companies and forums issuing PRs and blogging enthusiastically about the great progress.

So, if I can’t be first … here’s my take on the latest milestone. As you probably heard, G.hn has settled on some "Baseline Text" for most of the protocol pieces that lie upstream of the G.9960 G.hn PHY standard finalized last December. These pieces, collectively called the Data Link Layer or DLL, together with the PHY make the existing wire home network appear to the outside world like a common Ethernet LAN. The beauty of this approach is that the processor in the consumer premises equipment (service provider talk for the set-top boxes, residential gateway, and other equipment they install in the home) uses standard proven Ethernet software to communicate over the G.hn home network.

This isn’t a new idea – HomePNA and others already do it and the devil is, as always, in the details. The clean slate approach taken by G.hn developers – which at this point are largely engineers from companies with extensive experience developing existing wire home networking technology - allowed them to take advantage best-of-breed approaches and implementations as well as new technology.

Pretty sentiments and noteworthy progress but there is still a lot of work to be done to get Consent in the two to three meetings planned between now and September. There are still multiple approaches to be resolved, decisions to be made on what is required and what is optional, politics to be played (more than before, much less than expected), and new technology decisions to be made to get from here to there. The participants I talk to are uniformly positive that they will get to Consent on the complete standard at the SG15 meeting in Geneva this September.

ITU G.hn Stays On Track

By Rich Nesin, General Manager and Resident Philosopher, HomePNA

Time to get back to work. The G.hn crowd wrapped up another meeting last week – the first meeting of the year and the first since releasing the G.9960 standard last December. The group is continuing to move at the fast pace they set last year with lots of technical contributions, monthly meetings, a goal of closing comments on the next standard before the summer, and wrapping up this phase by Sept. Although I don’t expect products this year or early next, I wouldn’t be surprised if there were some very limited field trials of the technology around this time next year.

With G.9960 released last December as promised, G.hn is building an enviable track record. Remember, it’s only been two years since the same group released the world’s first two wire home networking standard (that’s right, I mean HomePNA 3.1/G.9954) -- which was only two years after they released the HomePNA 3.0 standard which set the bar for this generation of high performance triple-play-ready multimedia home networking standards (or in less self-indulgent terms, HomePNA 3.0 was released before MoCA 1 or HomePlug AV). A major release every two years. Not too shabby for a standards group.

People that follow this blog know that HomePNA members support the G.hn effort and that some have been working on it since the HomePNA 3.1 standardization wrapped up. We feel that the more cooperation and support the work has the better the end result will be and that the advantages of a single standard will increase the revenue opportunity for everyone. In that spirit, HomePNA and HomeGrid announced a liaison agreement making it easier for our organizations to cooperate more closely to better support the great work.

IEEE P1901 – Is the Opera Truly Over?

By Rich Nesin, General Manager and Resident Philosopher, HomePNA

Well the season finale of my favorite soap, how the IEEE turns, has aired. And what a season it was! Now it’s time for everyone to live happily ever after (at least they would if I wrote the script, three years to get to a draft spec is enough).

If you’re familiar with how the IEEE developed the elegant two PHY P1901 proposal, then you may not be surprised that the approved version includes not two but three PHYs. That’s right. Despite defeating a previous bid to use the ITU’s G.hn PHY for P1901, the final compromise proposal includes G.hn in addition to Intellon’s HomePlug AV Panasonic’s HD-PLC PHYs.

The inside story is that the P1901 proposals squeaked by and may well have been headed for another defeat. The addition of the G.hn PHY saved the day by drawing new supporters (including G.hn pioneer Coppergate Communications who voted yes for the first time).

So this is great for everyone, right, a real win-win? I certainly hope so but there are nasty rumors circulating about it being a political ruse and behind the scenes efforts taking place to remove G.hn from the IEEE P1901 draft standard. The industry took a giant step forward when G.hn was added to P1901 and now it’s time for the IEEE to walk the walk and do the right thing for everyone.

G.hn, a PHY For All Seasons

By Rich Nesin, General Manager and Resident Philosopher, HomePNA 

Back last May we bloged a bit about what makes G.hn different. One caveat, set down at the time by the service providers, required G.hn to start with a clean slate.  They were told to choose the technology based on best of breed rather than interoperability with existing technologies. With evangelical zeal and no existing triple-wire home networking industry specification, it seemed like a good idea at the time.  I think this decision more than anything else helped G.hn stay the course and finish on time

So it wasn't a huge surprise that G.hn didn't pick one of the dominant wired home networking codes used by HomePNA 3.1, HomePlug AV or MOCA. Instead, G.hn used a Low-Density Parity-Check code (LDPC code) which Wikipedia correctly notes is an error correcting code used to transmit messages over a "noisy" transmission channel. Wikipedia goes on to say that that it wasn't practical to implement an LDPC code when it was developed in 1963 however in theory it is the most effective code developed to date.  This doesn't mean the other codes are bad even over noisy channels.  It only means that after evaluating the alternatives, LDPC was the best match to their requirements.

So G.hn selected a code for all seasons, allowing technologists to design one universal wired home networking chip. Selecting the code type was just part of the job (although a fairly contentious part). G.hn standardized a complete PHY specification; in addition to the LDPC coding scheme they selected modulation parameters and other specifications required to actually make it work. The three media types – powerline, coax and phone wires – are not the same. Far from it. G.hn developed different modulation parameters to provide robust operation over each medium.

The result is a PHY standard ready for the chip designers. A PHY standard is not the same as a chip specification so expect different implementations from different vendors. For example, there is no physical interface to the PHY defined; just a logical interface allowing each vendor to design its own optimized product. Should you expect to see stand-alone G.hn PHY chips? I don’t -- any more than I expect to see stand-alone 802.11 WiFi PHY chips. Integrated PHY/MAC products make a lot of sense for a number of reasons (not the least being cost). Should you expect chip vendors to be hard at work putting the finishing touches on their G.hn PHY designs now that the standard is complete? You betcha.

ITU G.hn Delivers a Spec

By Rich Nesin, General Manager and Resident Philosopher, HomePNA

Have you noticed the press coverage that high performance home networking over existing wires is getting? It makes me nostalgic for the days when analysts dismissed us with a quick ‘the world is going wireless”. It probably is, but installations in millions of IPTV homes over the last couple years say that it isn’t always the best solution. Last week’s ITU announcement about completing the first G.hn standard seems to have gotten the most coverage yet (possibly due to how extraordinarily rare it is for a standards group to deliver a standard on time). So you may be wondering what actually happened and how?

If you have been following my ramblings about home networking standardization in the IEEE P1901; and ITU Q4/15 you may already have a good idea of what happened. If you’re not familiar with the ITU, standards can only be approved during special ITU “plenary” meetings. A plenary is a formal two week meeting of the entire SG 15 (not just the Q4/15 group that is part of SG 15 or the even smaller G.hn group that is part of Q4/15 and has been meeting every couple weeks for the last year to get the work done on time). Like the other meetings, the plenary was very technical with lots of informal working meetings during the evenings to refine the contributions and achieve consensus on the contributions (or in the words of one engineer, “lots of real work was done”). This is the “how”. This and a lot of hands-on direction from some of the world’s largest telcos.  Being the customer has its advantages and these customers see the advantages of a single open world-wide existing-wire home networking standard.

So what happened? I wrote a little about MACs and PHYs back in a June post about HomePNA's guaranteed QoS. Like most other home networking technologies, G.hn is built of two components; a MAC and a PHY. The MAC part, short for medium access control, manages the communication between devices on the home network. The PHY part, short for physical interface, encodes and decodes the data from the MAC – encoding it so that it can be carried efficiently over the media (which in the case of G.hn can be powerlines, phone wires or coax) and decoding the data that is received from the media so it can be processed by the MAC. Every product featuring a G.hn interface will have a MAC and PHY. So what is G.hn’s new G.9960 standard? It’s the new G.hn PHY. The companion G.hn MAC spec is scheduled to be completed in September.

More soon …

Why DOCSIS isn't the first choice worldwide

By Richard Nesin, president, HomePNA

The big HomePNA news this week (and I hope you read Monday’s blog so you know what I am talking about) was CopperGate’s announcement about the Shanghai Engineering Research Center for Broadband Technologies & Application (B-STAR) selecting HomePNA-based technology as its primary solution for its Multi Dwelling Unit (MDU) interactive Digital TV test program in Shanghai. Why didn’t they select DOCSIS like so many other cablecos? In a word, cost. HomePNA technology combined with fiber to the premises (FTTP) gave them the right mix of performance and features without the large price tag.

First, a little background on DOCSIS. The Data Over Cable Service Interface Specification or DOCSIS is an international standard developed by CableLabs, the cablecos’ R&D consortium. DOCSIS, like HomePNA, is an ITU standard although the work is done in Study Group 9 (SG 9) and is completely independent of the G.hn and HomePNA home networking standardization work being done in SG15.

DOCSIS defines the protocol for high-speed data transfer over an existing Cable TV system. The killer application, needless to say, is Internet access and there are a large number of DOCSIS cable modems sold worldwide (especially in North America). The first DOCSIS specification was released over 10 years ago. The most recent version, DOCSIS 3, adds support for IP – that is to say Internet Protocol version 6 (IPv6) - to the standard. Multiple versions of DOCSIS exist around the globe such as EuroDOCSIS to comply with differences in regional standards. CableLabs and other organizations perform DOCSIS equipment certification testing on a regular basis.

DOCSIS equipment consists of the cable modem installed in your home and a cable modem termination system (CMTS) located at the cableco’s “headend”. It’s not cheap for an MDU. A DOCSIS cable modem has to be installed in each apartment and connected to it’s corresponding port on the CMTS over the cableco’s coax/fiber (called HFC for hybrid fiber-coax) cabling. The CMTS connects the customer’s DOCSIS modem to the Internet.

For those of you who (like me) had early DOCSIS 1.0 modems that required a phone line connection in addition to the coax connection to operate, you've probably guessed this isn’t the entire story. When I first got broadband the only option was this DOCSIS kluge (kluge is an engineering term for a less than elegant system). I had to get a second dedicated phone line (remember phone lines? They are what DSL modems use today for Internet access, VoIP and IPTV) from the phone company in order for my cable modem to work. Cablecos had to upgrade their HFC network to provide a return path for upstream traffic – data sent from your PC to the Internet – over the coax. This also costs money. While many cableco’s HFC networks have been upgraded, there are parts of the world where the technology lags.

What's it all mean?  Stay tuned for the next post.

What the Big Dig and Chunnel can teach us about IEEE P1901 and ITU G.hn

By Richard Nesin, president, HomePNA

As can probably guess we spend a lot of time discussing P1901 and G.hn. My colleague Michael Weissman, a source of really good marketing anecdotes, has a favorite one about the time he heard marketing guru Clayton Christensen, Harvard Business School professor and author of “The Innovator’s Dilemma”, speak at conference. The talk compared two major construction projects, Boston’s “Big Dig” and the “Chunnel” under the English Channel.

The story goes that the Chunnel took about 7 years to complete, is about 30 miles long, and cost around $15B in today’s dollars or $500M/mile. The Big Dig took about 15 years to complete, spans 3.5 miles (about half in tunnels), and cost around $15B in today’s dollars or about $4.3B/mile. As Christensen tells it, the moral of the story is that infrastructure made the difference. The Big Dig had to replace and connect to a very complex and heavily traveled transportation infrastructure. The Chunnel was green field – nothing existed previously so it was all new construction.

A great anecdote but what does it have to do with P1901 or G.hn? When G.hn began it was understood and agreed that no attempt would be made to make it interoperable with existing standards. This was painful for HomePNA members since we have always successfully standardized our technology under the ITU but we agreed for the greater good. G.hn is a green field standard, free to select the best and newest technology available. IEEE P1901 started with several existing standards (the infrastructure) and has evolved into an awkward multi-MAC, multi-PHY architecture with several implementation options. The result is slow progress and the probability that a consumer will buy two IEEE P1901 devices that won’t be any faster than today’s products or work together. We’re not sure that is progress.

Comparing IEEE 1901 and ITU G.hn

By Richard Nesin, president, HomePNA

I just returned from my first IEEE P1901 meeting. If you follow home networking (and who doesn’t?) you probably recognize the IEEE as the group that developed and continues to evolve the Wi-Fi 802.11 and Ethernet 802.3 standards. They do a lot of other things and some of those things are being done in P1901. The P1901 group was formed a couple of years ago to standardize networking over powerlines. The group started with three non-compatible industry technologies: HomePlug, UPA and HD-PLC.  According to the project authorization request or “PAR” approved by the IEEE, P1901 is working on a standard to enable coexistence and interoperability over powerlines for both home networking and broadband over powerline (BPL) applications.

The meeting was well attended with representatives of over 40 “entities” present. I counted at least one copy of Robert’s Rules of Order for every three attendees; a very respectable ratio. (An exaggeration but not far from the truth). The meeting was very formal and Robert’s Rules were quoted frequently.  There were several conflicting agendas being pursued and a good deal of the meeting was spent discussing what motions were and were not allowed.  Almost all of the technical work seems to have been done behind the scenes. Having attended G.hn meetings, where most of the time is spent presenting and discussing technical contributions, this surprised me.

I was also struck by the very different policies and procedures followed by the IEEE P1901 and ITU-T G.hn – or for that matter between P1901 and other IEEE groups. Unlike some IEEE groups, P1901 only allows one vote per entity (which is a good thing).  An entity can be a company, industry SIG, university, etc. As discussed back in the March blog about the differences between Special Interest Groups or SIGs and standards organizations like the ITU-T and IEEE, SIGs are usually run by the “privileged” members.  Allowing SIGs equal voting rights can provide companies or groups of companies with additional influence on votes potentially making the process more political. The ITU-T is more selective and doesn’t allow SIGs to be members. Now that you know more than you ever wanted to know about entities, we’ll just call them members.

Members must join the P1901 group and attend a number of meetings to be entitled to vote (they lose voting privileges if they miss too many consecutive meetings). It’s not possible for a company to send a lot of employees to a given meeting to force through a favorite motion (although I’ve seen this done in other IEEE groups operating under different rules).

As far as the work itself, it’s taken a while and will take a while longer. The current voting isn’t on a draft standard, it’s on three individual “clusters”; one for home networking called “IH” for in home, one for BPL called access and one for coexistence called coexistence. The clusters must each be approved by over 75% of the groups members. They will then be combined into one working document that follows the IEEE style rules and voted on again. After 75% of the members approve, the document will be considered mature enough to be a draft standard. Another 75% vote will put the draft before the sponsor (ie the IEEE Communication Society) where it will undergo an new iterative review and approval voting process by that group per their own policies and procedures to make sure it meets the PAR objectives and IEEE requirements before it is released as a standard. As you know if you have been following this blog, ITU-T is a consensus process.  When a draft standard achieves consensus, it is released. 

Two standards groups, two very different operating modes.