Home Connectivity Summary

Executive Summary

When I wrote the first version of this essay, the term "home networking" was often being confused with "home automation". Since then "home networking" in the sense of traditional computer networking has become a hot topic. There is still much confusion among the concepts of home automation, home networking and, in general, how to connect and control the devices within a home and how to connect them to the outside world.

I've chosen the term "home connectivity" for this version since my emphasis is on the connectivity among the devices.

It is not surprising that the focus in the consumer electronics industry is still on building a solution for a particular set of applications, namely, how to get all those remote controls unified so one can coordinate the VCR, the Cable TV signal and the new fancy TVs. The HVAC (Heating Ventilation and Air Conditioning) industry is focused on its own set of devices for controlling the lights and the temperature.

We also have an interest in "home automation" among the hobbyists and high-end home builders and buyers. Unfortunately the term "home automation" represents a fundamentally flawed view that has a house on autopilot. A more reasonable view is a house that is responsive and which allows the occupants to control the behavior by specifying policies rather than rebuilding.

Each constituency is trying to solve real problems but we've made very little headway in the last twenty years. The primitive "X-10" protocol still dominates more because of the plethora of new protocols rather than the lack. There is little or no synergy between these protocols because each define their own infrastructure including their own wiring. Not only does entail a separate investment for each approach but the approaches themselves are hostage to the assumptions built into their own infrastructure. Thus Firewire (IEEE-1394) limits the home entertainments systems to about 6 meters.

The advantage goes to those who can leverage existing devices and infrastructure. And it goes to those who can learn and improve their solution. If we have common connectivity, we can then experiment with application protocols as software and evolve them in light of experience.

The central themes of this essay are:

  • Connectivity is fundamental and it is based on the Internet Protocol. It is the logical "wiring" that allows any device anywhere in the world to be connected simply and cheaply to any other. This doesn't mean that the performance is uniform everywhere, but the protocols can be tolerant of these variations. Within the home, buying capacity is simple since it is a commodity. And, because it is a commodity, pricing is very competitive. Control services themselves need little capacity. If there really is a market for streaming video around the house, it is just a matter of installing appropriate connectivity either wired or wireless. My assertion is that IP is suitable for a range of functions ranging from control protocols to streaming protocols.
  • The whole notion of automation is flawed. Instead, we must have protocols to allow devices (and services) to co-exist. They can cooperate using appropriate protocols. Some protocols can be fairly generic and span sets of devices. Others are more narrowly focused. All of the protocols must be simple so that they can evolve. They must be resilient so they are tolerant of normal errors and even maliciousness.
  • The IP infrastructure needs to be improved with the larger addresses of V6 (128 bits vs 32 bits) and pervasive authentication to make it safe to create simple connections.

By sharing the IP infrastructure we can separate the investment in "wiring" from the challenges of making the devices cooperate. Even better, it makes sense to have a large investment in technology so that we can use existing wiring. One example is the Home Phonewire Networking Association. Wireless connectivity is also very attractive.

Once we can assume connectivity at a low cost, we are ready to start innovating in creating applications and protocols. Since they represent a software investment rather than hardware, it is feasible to experiment and evolve them. As long as the protocols are "well-designed", it is feasible to maintain a large degree of backward compatibility. I will address the issue of what constitutes a well-designed protocol in a later section (or separate essay). The design must address not only the technical issues but must also allow for the marketplace to improve them rather than waiting on committees for approval. The IETF is a good example as it serves to ratify practice rather than invent new rules.

Perhaps we'll continue to use the term "home automation" but the real focus is on how the devices interact and on how we can give the user (AKA human) a reasonable ability to understand and control her environment. This is a very difficult problem. Even if we could understand all the interactions among devices and the implications of the rules, we still need to resolve the disputes between each persons requirements and expectations. If we give up the notion that there is a single well-defined solution we are ready to look at the issues in more detail.

I explore some of these issues in more details in the next essay.

You might also look at Internet and Consumer Electronics which focuses more on explaining the potential for the Internet to the Consumer Electronics industry.

Bob Frankston
Copyright � 1997 Bob Frankston. All rights reserved.