To read original PDF of the print article, click here.
Internet Appliance Design
Network Protocols for the Home
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.
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 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.
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
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.
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.
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.
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
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.
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.
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
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
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.
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.
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