HomePNA Blog

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.

QoS part 4: The Control and Data Planes

By Richard Nesin, president, HomePNA

In the first three QoS posts on June 4 , June 15 and June 20,we spoke about why you need QoS and types of QoS.  There’s more and it comes from ITU-T SG13 which has defined the architecture and pieces needed to deliver QoS.

HomePNA 3.0 and 3.1 QoS involves two parts; the control plane, concerned with making connections between network end points, and the data plane, concerned with actually forwarding the user data.

Control Plane functions include admission control and resource reservation. Admission control determines whether a new stream can be added to the network without violating the QoS of streams already traveling over the network.  Resource reservation is related to admission control and does the actual assignment of the train cars (or TXOPs if you must).  As we discussed in QoS part 3, this is the job of the HomePNA Master.

Data Plane functions used by HomePNA 3 include buffer (or queue) management, congestion avoidance, traffic classification, traffic shaping and traffic scheduling. Buffer management makes sure that memory space is available on the device to store the streams coming from or going to the network with first priority given to the streams with QoS. Among other things, the other functions allow the network to gracefully react to situations where the traffic is approaching its maximum, the traffic is “bursty”, or to use “aggregation” to eliminate unneeded packet headers that waste network capacity.

G.hn – Why So Fast?

By Richard Nesin, president, HomePNA

Five years ago, a long time in the world of high tech, we introduced HomePNA 3.0 (a.k.a., HPNA) to equipment vendors. Most thought it was great stuff but couldn’t conceive of applications that needed so much speed and guaranteed QoS. They told us to market it to the service providers, which we did. Then along came IPTV triple play, HDTV and GPON and suddenly nobody was wondering what to do with all that speed.

Fast forward to today and even HomePNA 3.1’s 320 Mbit/sec data rate, providing up to 230 Mbit/sec of user throughput (the real capacity after the overhead is subtracted), doesn’t seem so fast. All right, it does seem really fast. But some, like Verizon’s CTO Mark Wegleitner who is calling for at least 100 Mbps of actual user throughput today and 400 Mbps in less than two years, want more. Why so?

Why has several answers. First is that sales of HDTVs are going up – but it’s not that simple. Digital video is compressed and the type of compression used (MPEG 2, MPEG 4, VC-1, etc.) has a big impact on the amount of network bandwidth – another word for the network capacity - used. Add to that display of multiple IPTV streams on each TV and it becomes more about the number and type of streams family members view than about the number of TVs.

Don’t forget the video streams that originate within the home. With the coming proliferation of IP-enabled whole-home DVRs, every IPTV will have a DVR further increasing the number of streams being recorded and viewed. But there’s another gotcha coming. Fast-forward on the DVR often uses “trick mode”, a technique that can increase the amount of bandwidth used by that stream by three or four times.

And don’t forget Internet access. The home network shouldn’t slow down Internet access. With fiber to the home (FTTH) providing 100 Mb/sec and more, the data part of triple-play service can consume a significant chunk of the home network capacity all by itself. It’s no wonder so much effort is going into speeding G.hn to market.

QoS Part 3: What’s special about HomePNA’s Guaranteed QoS

By Richard Nesin, president, HomePNA

So by now you must be dieing to know more about HomePNA’s guaranteed QoS. First off – HomePNA also supports priority QoS (actually it has since HomePNA 2). Unlike some of other home networking technologies, HomePNA 3 and 3.1 use a “synchronous MAC” which eliminates collisions on the network and guarantees glitch-free delivery of each real-time packet with the required latency, jitter, and error rate parameters.

Like most other home network technologies, HomePNA 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. Every HomePNA device includes a MAC and PHY however one device, the “master,” is special. The master is what makes the HomePNA MAC synchronous and enables its best-in-class QoS. The HomePNA Master breaks up the transmission time into small parts the way a train is broken up into cars (HomePNA calls them Transmission Opportunities or TXOPs if you really want to know). HomePNA devices with data to send contact the master and ask it for reservations to send a data “stream” to another device (the required bandwidth, maximum latency, jitter and error rate it can tolerate).

The master determines which train cars are available, how many are needed, and how far apart they can be spaced. It puts that information into a schedule which, for the sake of simplicity, HomePNA calls a Media Access Plan or MAP. The master sends the schedule to every device on the network at the same time, synchronizing every device on the network together. Every device then knows which train cars (or TXOPs if you want to get technical) are reserved for its sole use.

Devices sending best effort data are welcome to use any unassigned train cars however they must be prepared to vacate at a moments notice if the master assigns the car to a stream requiring QoS. The master regularly updates and sends the schedule to all of the devices on the network allowing it to add and remove streams from the network whenever required. The QoS parameter information itself is determined in a number of ways. It can be extracted from the 802.1p priority bits, gotten from a “TSpec” sent by the stream originator, or by some other means.

QoS part 2: What is Priority QoS

By Richard Nesin, president, HomePNA

In the June 4th post QoS part 1 we jumped into the middle of a discussion on Quality of Service (QoS). If you recall, QoS is a mechanism used to provide reliable and predictable delivery of real-time data such as IPTV and VoIP streams over a home network that is carrying other “best-effort” data like porn (you are enabling those parental controls, right?). To techies, home network Quality of Service (QoS) used to means priority-based QoS, the original QoS provided by Wi-Fi home networks.

So where does the “priority” in Priority QoS come from? It comes from the IEEE

Data sent over a network is broken into same-size pieces called “packets,” which are like the way the words in a book are broken into pages. Information is attached to each packet to tell the network equipment things like the size of the packet, where the packet comes from, and where it’s going – this is called the packet “header.”

Header information helps network equipment to route the packet from its source, say a server at You Tube, to its destination, say your PC. Included in this header are three “priority bits.” (You’ve probably guessed where this is going, right?) Three priority bits enable eight levels of priority although sometimes only four are used. Real-time data such as video is usually given a high priority and non-real-time “best-effort data” is given low priority. Network equipment uses various techniques to insure the delivery of high-priority data over low priority. Priority QoS, also called Class of Service (CoS), will prioritize one type of data over another but typically won’t help when two same-priority data streams are being sent simultaneously.

G.hn: The New Single Standard for Home Networking

Have you noticed the articles about G.hn that have been appearing recently? We have, and as early and strong supporters of the next all-wire global home networking standard, we couldn’t be happier that the work is getting the attention it deserves.

In G.hn, ITU-T members are creating a single standard for home networking over existing wires – coax, phone wires and powerline – with the speed and features needed by tomorrow’s high-performance applications. (Did someone say HD IPTV and whole-home DVR?) G.hn’s goal is to simplify existing-wire home networking. No, G.hn will not replace wireless standards such as Wi-Fi (nobody wants to trade their wireless laptop connection for a wire). It will compliment the wireless technologies. We expect the home of the future to have both.

Considering all the home networking specifications and standards in the world, it’s good to see such a broad section of participants converging on a single standard for existing wire home networking the way it converged on WiFi for wireless.

QoS part 1: HomePNA Guaranteed QoS versus MOCA PQoS

By Richard Nesin, president, HomePNA

Sometimes I am really impressed. MOCA’s Parameterized Quality of Service (PQoS) is one of the things that really impressed me – not the technology, but the marketing spin.

HomePNA 3.0, released in 2003 and standardized by the ITU in 2005 as G.9954, was designed specifically to provide parameter-based QoS. HomePNA 3.1 added important enhancements. MOCA announced PQoS October 2007 and they heavily promoted it and positioned their organization as the “first” to do it. See what I mean? So, the answer is yes! HomePNA 3.0 and 3.1 have featured parameter-based QoS from the very beginning -- only we call it guaranteed QoS and it’s better.

So why have QoS? Real-time data such as voice and video must be delivered on time with low errors. There’s no hiding it – if it’s late or has lots of errors, the customer will know it – clicks and pops, voice drop out, tiling on the screen, and you know the rest. Lots of technology has been developed by standards groups such as the Internet Engineering Task Force (IETF) and Institute of Electrical and Electronic Engineers (IEEE) to implement QoS. You can find QoS in telecommunication core networks, access networks, and cellular networks, however, it’s usually implemented differently depending on the network, application and carrier.

For home networks, guaranteed QoS has come to mean that certain “parameters”, key to the delivery of real-time data, are guaranteed by the home networking technology. These parameters are latency, the amount of time it takes for the data to get from one point to another; jitter, the variation in the time between data arriving; throughput, the amount of data you can send in a given time; and error rate. (See where PQoS gets its name?)

What’s the difference between HomePNA guaranteed QoS and MOCA’s PQoS? HomePNA QoS eliminates data “collisions” on the home network. It provides greater control at a lower level so it is more efficient and enables more data to be transferred.

Why Do TelcoTV Install Times Vary? Part 2

Tens of thousands of telco IPTV installations ago we blog’d about IPTV installation times. In that March 27 post we noted that as much as industry watchers would like draw comparisons about home networking from IPTV installation times, it’s a riddle, wrapped in a mystery, inside an enigma (apologies to Winston Churchill).

The differences between a European telco offering HomePlug and a North American telco installing HomePNA is much more than HomePlug versus HomePNA (or MOCA, UPA, HD-PLC, …). In some cases – especially North America -- most of the stuff done during installation has little to do with home networking and more to do with the IPTV service itself.

So what does the installer do when he gets to the customer’s home, you ask? Several HomePNA members have done ride-alongs on telco IPTV installations so we are able to shed a little light on the process (at least for some North American telcos).

If you have had cable or satellite service installed, you won’t be surprised to learn that the first step is to review the order with the customer. The installer then does a site survey and determines where the passive components, residential gateway and set-top boxes will be installed. For older homes it’s likely that there is old equipment that needs to be disconnected.

Since the new IPTV service may involve upgrading or adding new broadband service, the technician also needs to install, provision (turn on), and test new DSL or fiber service. (In some cases installers use commercial test equipment that can test both the broadband access service and the home networking wires.) If the fiber or DSL is installed on the outside of the house, the technician needs to figure out which wires he will use to bring the service into the house. The remaining equipment is then installed, middleware updated, and the system, including the home network, is tested.

In many cases the installation also includes a wireless LAN which must be configured and tested as well. And don’t forget training the customer on use of the new remote control and DVR features, setting up the customer’s Internet, and so on.

G.hn When?

We’d like to shed light on some industry FUD surrounding the release of the G.hn standard. You may have heard about a G.hn contribution made last month by some of the bigger telephone companies. The contribution, which was adopted by the members, proposed to consent a G.hn Recommendation (ITU speak for “agree on and publish a standard”) by the end of this year. Service providers are the customers and their opinions count in Q4/15 (see the May 5 post “Who is ITU-T, what is Q4/15, and where did the “G” in G.hn come from?” See blog post. So this contribution, which also prioritized the work, carried a lot of weight – not to mention a warm feeling that the service providers are there to help keep the work on track. This standard will allow technology companies to develop G.hn chips.

After a recommendation is consented it goes through a short ITU release process and becomes an open publicly available standard. This doesn’t mean it can’t be enhanced in the future. In the ITU it is common to have addendums added later. For example, the HomePNA 3.0 spec was initially consented and released as Recommendation G.9954 in February 2005. After HomePNA released the enhanced but backward compatible 3.1 specification, Q4/15 updated G.9954 and re-released it as G.9954 Jan 2007 revision.