Network Protocols for the Home -

Network Protocols for the Home


To read original PDF of the print article, click here.

Internet Appliance Design

Network Protocols for the Home

John Canosa

With always-on high-bandwidth Internet connections comes the possibility for multiple devices within the home to share this resource. And, of course, they'll also be doing a lot of internal communication over home-area networks.

We have all become very comfortable with networks. Local area networks (LANs) and wide area networks (WANs) have become ubiquitous. Originally, only the “big iron” computing facilities had networking capability. But the network hierarchy has been rapidly moving lower in the food chain towards smaller and more personal devices. These days, home area networks (HANs) and personal area networks (PANs) are joining their larger brethren as ever-present communications channels.

The current impetus for the home network is that many consumers have more than one PC and would like to share data and peripherals. Also, as high-speed, always-on Internet connections become more available, this pipe is likely to be shared as well. In fact, the estimated number of multi-PC households is at 15 million and is growing at a 30% annual rate-faster than the growth rate of single PC households (Source: Jupiter Communications). Several contenders are vying for the consumer dollars in the home networking area. This article looks at the contending technologies in the home networking arena, focusing on connectivity to the Internet. It also examines the multimedia and imaging market, since this is the area likely to be most affected by the expansion of home networking.

Fatter pipes
Electronic imaging tends to consume tremendous amounts of data and bandwidth. Current connections to the home consist mainly of modems running at 33.6Kbps or 56Kbps. These connection speeds are unacceptable to end users dealing with still images, let alone video. Fatter pipes into the home are essential to proliferate any type of imaging services or to sell any type of imaging appliances that intend to make use of the Internet infrastructure.The current model calls for the home user to contract with an Internet service provider (ISP) for a flat-rate monthly fee. The ISP typically provides a dial-up line that the consumer uses with a standard (V.90 or V.34) modem that provides a maximum 56Kbps download speed and 33Kbps upload speed. Typical cost is approximately $20 per month. Many new technologies have been developed in an effort to increase the amount of bandwidth available to the home consumer.

As the bandwidth to the home increases, Internet appliances will begin to proliferate. This in turn will drive the adoption of home networks. It is not necessary that the channel into the home uses the same media and interfaces as the devices residing within the home. Most homes will have a gateway device to provide Internet access on one side and home network access on the other side. This mirrors the situation in an office environment, where most users connect via 10/100 BaseT to a central location that provides a T1 or other WAN-style connection to the Internet. Figure 1 shows what a typical consumer may have for a home networking solution.

Establishing wider pipes into the home does not solve all problems of imaging and multimedia devices. The packet-switched nature of the TCP/IP protocol stack provides no guarantee of arrival time of data. In fact, it is quite possible that data packets will arrive out of order. Streaming applications, such as video and audio, require a more consistent throughput. Hence, several efforts are underway to define and request a certain quality of service (QoS) for Internet traffic.

In-home networking
In-home networking is where a significant amount of activity is occurring. Because the typical home will have one gateway device and many networked appliances, sheer volume potential drives companies and organizations to expend a lot of effort in this area.

In-home networking really consists of two components-data transport and interoperability. Back when networks were administered by the white robed high priests of System Administration, system complexity was not much of a problem. Networking protocols were designed using the OSI seven-layer reference model and details such as netmasks, gateways, and IP and name server addresses were controlled by these gurus. As digital networks start finding their way into the normal consumer environment, things change quite drastically. Grandma and Grandpa may likely be able to plug in the ubiquitous RCA connector cable from the video-out jack of their VCR to the video-in jack of their television, but they still haven't learned how to program the clock on the VCR. Connecting devices to a home network can be no more complicated than plugging in cables and operating a remote control, otherwise they will not be widely accepted in the marketplace.

Interoperability is the ability to connect two different devices from two different manufacturers and have them perform their intended function. Grandma can hook her Panasonic VCR up to her Sony television and they will work together because both are designed to meet the NTSC analog video standard. Unfortunately, such interoperability hasn't been the case in digital networks. Many of the current networking standards are based on the OSI seven-layer reference model as shown in Figure 2.

Not only do devices need to be able share ones and zeros across one or more media, they need to know what devices are out there to share with (discovery) and they need to know what type of information is being transmitted (format), and what is the intent of the sending device (context). The last item can be somewhat involved. The trivial case would be a single function device, such as a printer, as a receiver. If something is sending data to a printer, the obvious intent is to generate a print. But what about a multifunctional device such as a PC? When it receives data what should it do? Display? Store to disk? Print to an attached printer?

Obviously, the OSI reference model has some holes that need to be addressed for the home network. In order to provide true interoperability, some of the OSI layers take a more prominent role in data exchanges than they may have in the past. In addition, some new functionality needs to be supplied that allows devices to identify themselves and advertise the services they provide.

A suggested modification to the OSI model for an interoperability protocol stack is shown in Figure 3. The stack has grown in complexity, but that is the typical result of trying to make things easier and more flexible for the end user. Of the many contending protocols and transport mechanisms vying for the top spot in the home networking arena, none of them provide a complete top to bottom stack definition. The focus of each protocol seems to be in one of two areas. Some focus on the lower layers involved in data transport while others concentrate on the services and data representation layers.

Data transport-focused standards
Table 1 captures some of the competing technologies vying to be the dominant data transport provider in the home network. These technologies are best grouped by media type.

The Home Phoneline Network Association (HomePNA) has adopted Tut Systems' technology to provide a 1Mbps data rate over existing phone lines in the home. The system uses the spectrum in the 5MHz to 10MHz range, well above analog phones, modems, and xDSL. This allows the systems to co-exist on the same wiring. Phoneline networking is an attractive option because it does not require any new cabling within the home and operates like the familiar Ethernet system. While 1Mbps is not a tremendous amount of bandwidth, the HomePNA has adopted Epigram's 10Mbps solution as their version 2.0 standard, which will be backward compatible to the Tut Systems solution. In addition, 100Mbps is planned for a future version.

Another significant advantage to the HomePNA is the support within the industry. There is no fragmentation because no other proprietary protocols are vying for market share. Backwards compatibility is also a big plus for the faster versions of the protocol. HomePNA addresses only the physical layer of the interoperability protocol stack. In fact, HomePNA simply sends standard Ethernet packets over their physical layer.

RF technology is attractive because it allows mobility and requires no cabling. Three potential candidates are the IEEE 802.11b protocol, Bluetooth, and the HomeRF. IEEE 802.11b is a standard for RF LANs that provides up to 11Mbps throughput, with extensions to 50Mbps and beyond in the works. The standard is still relatively new and there are interoperability problems with many of the implementations because the standard originally let developers choose between two different physical layers. The interoperability issues have been recently addressed and 802.11b is starting to come down in cost, making it more attractive to home users.

Bluetooth is the name of an industry consortium backed by Intel, IBM, and others. The goal of Bluetooth is to provide low cost (less than $10) “personal area networks” (or piconets). At its current 780Kbps, the data rate of Bluetooth is likely too low for most imaging applications, but adequate for file sharing and printing. Most troubling from a home networking standpoint is the limited range of 10 meters. There is the ability to extend the range to over 100 meters by upping the power levels of the transmitters, but this will have an impact on power consumption that significantly impacts the mobile device market-the prime target for Bluetooth.

The HomeRF Working Group has the support of Hewlett-Packard, Intel, and others. It is based on a subset of 802.11b and provides a 2Mbps throughput. It also specifies the Shared Wireless Access Protocol (SWAP), which provides interoperability with other devices and supports several voice channels as well as data.

Each of these technologies have certain features in common. They all operate in the unlicensed 2.4GHz ISM band, perform frequency hopping (so they don't step all over each other since they operate in the same band), and trace some of their heritage to the 802.11b specification. In addition, each of them specifies only the media access and link layer portion of the protocol stack, so existing upper layer protocols such as TCP/IP can run on top of them.

Somewhat to the consternation of its two main competitors, HomeRF has defined the Shared Wireless Access Protocol (SWAP). SWAP includes support for Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) similar to the 802.11 standard for high speed data and a Time Division Multiple Access (TDMA) portion similar to the DECT standard to support voice and other streaming data. At a 50 hop per second rate, SWAP has a 20ms frame as shown in Figure 5.

Bluetooth uses a much faster hopping rate (1,600 hops/second) at its MAC layer and also provides the link layer functionality. In addition, Bluetooth provides an RFCOMM layer, similar to the IrDA's IrCOMM layer which provides a legacy serial interface. See Figure 6.

Bluetooth allows ad hoc networks called piconets. The Logical Link Control portion of the stack provides for discovery of other nodes within range. This allows nodes to form a point-to-point or point-to-multipoint connection with each other. The details of the services provided and the format and context of the transmitted data is left to the application using the Bluetooth stack.

Although the portability and wireless nature of RF is very attractive, none of the RF solutions currently provides the bandwidth required for high performance imaging or multimedia systems. These solutions will likely be relegated to devices that are truly encumbered by cables, such as cell phones, digital still cameras, and personal organizers.

Twisted pair
All other things being equal, running 10/100 Base-T Ethernet over Category 5 Untwisted pair (UTP) is an attractive solution. Standard Ethernet chipsets can be had for under $10 in volume. In addition, many off-the-shelf protocol stacks are available and TCP/IP is well understood. Unfortunately, all things are not equal. Existing homes do not have the cabling infrastructure and it is quite expensive to install this after the fact. In addition, Ethernet may still suffer from QoS issues when loaded with several multimedia channels.

Most everyone is familiar with the Ethernet protocol, including the ubiquitous IEEE 802.3 twisted pair incarnation also known as 10Base-T and 100Base-T. It should be noted that 10/100 Base-T only specifies up through the link layer, with the network layers defined elsewhere. One drawback from a multimedia standpoint is the lack of isochronous capability in a 10/100 Base-T physical layer. Guaranteed bandwidth is preferable for audio and video applications.IEEE 1394 (also known as Firewire) seems destined to be a major player in the consumer electronics and multimedia spaces. The current implementation and next generation provide up to 400Mbps asynchronous and isochronous data transfer. In addition, work is well underway in defining the standard for sending IP packets over 1394. From a home networking perspective, the current standard has one major drawback-a 5m cable length limitation. This situation will be resolved when 1394B is completed. 1394B will allow data transfers over UTP up to 100 meters. This will allow 1394 to be used as the home network backbone, assuming, of course, that the home has Category 5 cabling installed.

IEEE 1394, shown in Figure 7, is a bus that provides physical layer, link layer, transaction layer, and discovery capabilities. Up to 64 devices can be connected on a single bus, and up to 1,024 individual buses can be connected. The network provides automatic address assignment and peer-to-peer communications. Refer to Reference 1 for detailed information on IEEE 1394.

Many upper layer protocols can run on top of the 1394 stack. This is both a blessing and a curse. It is a blessing because it means that the entire industry recognizes the potential of the bus; the curse is that too many protocols can become very confusing to both designers and end users alike. The leading contenders to ride on top of 1394 in a home networking scenario are TCP/IP and the Home Audio/Video Interoperability (HAVi) specification.

Powerline carrier systems provide the most convenient wired access, requiring no new wiring and multiple ports in every room. Powerline carrier systems must deal with the harsh environment mentioned earlier and getting fast reliable throughput requires a tremendous amount of sophistication.

Technical challenges aside, systems are currently available with 1Mbps throughput. Products and components supporting 10Mbps are supposed to be available this year.

The biggest issue with the powerline systems has been that they all involve proprietary protocols and fairly large amounts of protective circuitry. The proprietary issue is being addressed by the recently formed HomePlug Alliance. The alliance has adopted the Intellon COFDM technique for version 1.0 of the standard. However, even 10Mbps may not be adequate for some of the more demanding imaging applications, and it is questionable whether any kind of QoS guarantees can made with powerline carrier systems.

Advanced powerline systems use the same spread spectrum or frequency shift keying techniques that are used in RF systems. The big hurdle with powerline communications is that while they have to deal with the same microvolt signals as their RF brethren, they also have to deal with hundreds of AC volts, thousand-volt spikes, and power transformers within a home. Clearly not an environment for the faint of heart.

All of the currently announced powerline systems are proprietary and consequently very little technical information on their operation is available publicly. (There are quite a few more than those listed in Table 1.) To make matters worse, many of these companies have proprietary layers that extend far above the data link layer in the protocol stack. This is a major drawback for any protocol wishing to become a force in home Internet appliance networking and the chances of any success are slim until one of these companies opens up the kimono a little bit or HomePlug gets them all to agree.

Service and discovery-focused standards
As mentioned previously, moving data bits from one place to another is only half the battle. Knowing the format of the data (an image, an audio stream, or data to be printed?), what devices exist on the network, and what should be done with the data are all essential parts of true interoperability.

Table 2 lists the upper level protocols that are vying for dominance in the home (and elsewhere). One thing is apparent in examining any of these protocols: if information is to be shared with devices on the Internet, ultimately the Internet Protocol comes into play. Many of these protocols rely on IP being part of the protocol stack. That does not mean that all devices will speak IP, but if they don't, there must be some sort of proxy or gateway device that will allow communications with devices that do use IP. In addition, many of these protocols and APIs are complementary, rather than competitive. In many cases however, the complementary schemes overlap somewhat. It is currently a very muddled situation and only time will tell who the winners and losers will be.

Jini has received a tremendous amount of press coverage. It's a middleware layer that resides on top of a Java Virtual Machine and uses Java's Remote Method Invocation (RMI) to make use of a remote device's services. Jini technology has a lookup service with which devices and services register.

When a device plugs in, it goes through an add-in protocol, called discovery and join-in. The device first locates the lookup service (discovery) and then uploads a Java object that implements all of its services' interfaces (join). Afterwards, devices that want to make use of that service will be given the object to use as an API.

As an example, a digital camera that wants to find a color printer would first query the lookup service. If a color printer has registered with the lookup service, the printer's methods for accessing the printing capability will be downloaded to the digital camera. The digital camera will then communicate directly with the printer using RMI and the downloaded methods or RMI stubs. See Figure 8.

Jini devices must have access to a Java Virtual Machine to participate. The device may either have the JVM built into it or use a proxy device that does. Jini uses multicast packets for discovering the lookup service provider. This is not likely a problem in the home environment, but it may be an issue in an office or larger space where routers and firewalls come in to play.

JetSend is a technology introduced by Hewlett-Packard that is focused on the session, format, and context layers of the interoperability protocol stack. The protocol stack is shown in Figure 9.

The most enticing feature of JetSend is its definition of what it terms e-material. E-material provides both a description of the data as well as the data itself. A negotiation mechanism is provided that lets devices find a common representation of the data to be transmitted. For example, a digital camera may be able to present its image in a 24 bit per pixel (bpp) color format, an 8 bpp grayscale format or in a 1 bpp, 300dpi monochrome format. A printer engaged in a JetSend session with this camera could then choose the format in which it would like to receive the data. The JetSend specification defines a base format that all devices must support so the negotiation will never fail to find a common format.

JetSend does not specify any particular transport mechanism and can use any reliable transport. Any discovery services are provided by the transport itself, such as IrDA. JetSend itself does not provide any discovery mechanism.

Universal Plug and Play
Universal Plug and Play is an initiative driven by Microsoft to provide for the discovery and service APIs for a dynamic environment as might be found in the home.

UPnP uses IP and many other existing protocols. Included in those protocols are three that provide for the configuration and discovery portion of the protocol stack. These three protocols are the automatic private IP addressing (APIPA), which provides configuration services where DHCP servers do not exist; multicast name resolution, which provides name-to-address translation in networks without DNS; and simple service discovery protocol (SSDP), which allows devices to find services provided by other devices on the network. See Figure 10.

After a device discovers a service it wishes to use, it receives both a URL and possibly a piece of XML code that provides the device with specific information needed to make use of the provided services. As with Jini, the success of UPnP depends on the various industries getting together and defining a common and extensible API. This has not always been a trivial exercise because it is often difficult to develop a one-size-fits-all interface even for similar products.

Open Systems Gateway Initiative
The Open Systems Gateway Initiative is the brainchild of a consortium driven by IBM, Ericsson, Lucent, and others. It attempts to provide a mechanism for non-IP protocols to communicate with the rest of the world via the Internet. The OSGi is based on Java and has three required services and several optional services. The required services are the equipment manager, which interfaces to other IP or non-IP networks such as LONWorks, 1394, or HomeRF and provides virtual IP addresses to these devices; the resource manager, which controls threads and connections; and the remote service administrator, which allows new services to be downloaded.

As with the other standards that are defining APIs, the OSGi must also define a set of services and interfaces for specific vertical markets. The services currently being addressed include Energy Management Service, Security Service, Health Care Service, Home Automation Service, and Entertainment Services that provide pay-as-you-play advanced Internet-based entertainment services.

HAVi is the Home Audio/Video interoperability specification. HAVi is being sponsored by Sony, Hitachi, Grundig, Philips, and others. As Figure 11 shows, HAVi was designed to ride on top of IEEE1394-no surprise considering its consumer electronics heritage.HAVi defines a set of protocols/APIs that include device abstraction/device control models, an addressing scheme/lookup service, an open execution environment, Plug-n-Play capability (through 1394), and management of isochronous data streams.

The HAVi specification contains a number of distinct software elements that each provide a certain functionality. The software elements that are needed for interoperability between HAVi devices are the Messaging System, the Registry, the Event Manager, the Resource Manager, the Stream Manager, and the DCM Manager. Software elements called device control modules (DCMs) provide control over device-specific functionality such as a VCR or a camera. DCMs are loaded onto HAVi compliant devices and are used to control other devices-in other words, a downloadable user interface. HAVi does not define data formats; it relies on a stream manager to move data from one device to another, but the data format could be anything. The specification does allow for the creation of true transcoder devices that can turn one format into the other.

HAVi defines four levels of specification compliance. They are defined as Full AV (FAV), Interoperable AV (IAV), Base AV (BAV), and Legacy AV (LAV). The compliance levels are shown in Table 3. The only difference between FAV and IAV devices is the support for Java by the device. This allows devices to be fully HAVi functional without incurring the cost and overhead associated with a JVM.

Imaging and multimedia applications, such as multi-user games, videophones, remote Windows terminals, information tablets and digital video will burden all but the highest-speed networks. A single channel of HDTV will consume 19Mbps by itself. Aside from the data transfer issues, other items must be addressed. Home networking must be truly Plug and Play. It can be no more complicated than plugging a modem into a phone line and dialing up an ISP. The entire protocol stack must be re-examined and addressed in order to provide true interoperability amongst the various types of devices.

If all of the technology pieces come together and home networking is widely accepted by customers, the consequences could be far reaching. This technology, along with high speed Internet access will truly drive the computer/communications/consumer electronics convergence. Voice over IP, Internet radio, news, security, and a plethora of imaging applications will all be enhanced. Imaging applications stand to benefit the most from all of this new bandwidth-the Internet is all about sharing information, and images are one of the best methods of conveying information.

One of the more far reaching implications will be the role of the PC in this scenario. The PC will most likely play a less visible role in the networked home. It will probably not disappear entirely, but be relegated to more of a server/gateway role. The combined computing power of all of the Internet imaging and information appliances in a home will far outstrip that of even the most powerful PC.

John Canosa is chief scientist at Questra. He has over 20 years of experience in the embedded industry, including analog and digital hardware and software design. Prior to joining Questra, he was manager of the Electronics Design group for the University of Rochester's Laboratory for Laser Energetics, a large inertial confinement fusion laser system. John has a BS in electrical engineering from Clarkson University and an MS in electrical engineering from Rochester Institute of Technology. His e-mail address is

References and Resources
“Fundamentals of Firewire”, John Canosa, Embedded Systems Programming Magazine, June 1999



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.