Internet appliances demand new dynamic network capabilities for ad hoc resource sharing and communication. HAVi, Jini, and Universal Plug and Play are possible solutions.
What is the difference between an Internet device and an embedded system or a desktop PC? That question is at the core of a struggle that is raging between those who would define Internet devices as simply an extension of the PC-based Internet to other devices and those who would define them as embedded systems with networking capability. The reality that neither of these camps recognizes is that Internet devices will define a totally new class that is derived from both and truly belongs to neither.
One of the reasons for this differentiation is a set of basic changes to the usage model for Internet devices. Desktop PCs utilize networked-based resources, but they expect a reasonably stable and well-controlled definition of that network and those resources. Printers do not change on a minute-by-minute basis, so it is reasonable in this environment to expect users to preconfigure and map access and drivers for a preselected set of network printers.
This mindset must change for Internet devices. The Internet started out in a very controllable environment under the management of engineers who were quite comfortable with tweaking it by hand. From there it went into a corporate environment where MIS departments could manage the gateways and resources that defined it using sophisticated tools that made it easier to perform this configuration.
The next step is for resources to manage themselves. This step is necessary for Internet devices, since communications between them will be numerous and dynamic, and users will be less willing and capable of serving the device than they have been in the past. The device must be willing to serve the user instead.
The problem can be summarized in a simple phrase: service discovery and utilization. Internet devices will both provide and use services on a local and global network and a way must be found to match these services with entities on the network that require them.
Traditional computer networks have solved this problem through a relatively hardwired process. Typical services such as print and network storage reside at fixed addresses on the network and are relatively few in number, so each PC that requires access to them is configured by the user to be aware of the location and particulars of the resource. This is done by mapping the resource and installing a device driver that can define the data in such a way that it can be used by the device. But a new model is needed.
Consider a device that displays images on the wall of a home. The consumer also owns a digital camera, which they have used to take vacation pictures. They want to display one or more of these pictures on the device in question.
The idea is simple. The digital picture frame displays images, the camera has images to display. The two devices can be connected through a Bluetooth network, so they are quite capable of communicating at the data level. Everything should just work.
It is not that simple, of course. The default image format each device expects may not match. How does the user indicate that a picture is to be displayed on the wall of the den, rather than the one hanging in the kitchen? For that matter, how does the user know the devices are compatible at all, given that different companies might have manufactured them?
The requirement is that devices must be able to automatically discover compatible resources on the network and use those resources with a minimum of user intervention. The model that has been defined and lived with in the desktop world is much too complex to survive in a consumer environment. This means that new standards must be developed and utilized for Internet devices to thrive.
A solution to this problem must include a way for devices to discover what resources are available and learn how to use them automatically. There are at least three possible general algorithms for doing this.
Solution #1: Assumed knowledge
The first way is to design each device to be aware of the characteristics and availability of each class of device with which they might interact and have a way of knowing if such a device is available on the network. This approach has the virtue of simplicity, since the only dynamic portion of the knowledge required is whether or not a device of a certain class is present and, if so, where it is. The interfaces to each such device will be well-known and thus can be easily utilized.
This approach works well when you have relatively few device classes and very localized connectivity. It is possible that a gateway can be utilized to create interfaces to wider connectivity, but such a gateway would not have the advantage of being able to publicize all of the resources available on the Internet. At that level, the user or some other agent would have to decide which resources are of interest.
This is the approach being used for HAVi (Home Audio/Video Interoper-ability), the specification defined primarily for home entertainment systems. It makes a lot of sense if the configuration is assumed to be a local network of devices passing high data rate information like video over an IEEE 1394/Firewire/i.Link bus. It would be quite possible to gateway this network onto the wider Internet to download non-realtime video or program schedules, but the HAVi standard is not really set up to link to remote resources. The information gained would have to be front-ended by a device that would be more acceptable to the network. For example, it could be the equivalent of a set-top box that would store and forward video on demand. The Internet would not be visible to the local network, but the information and content gleaned from it could still be utilized.
The discovery of new devices is quite simple in this scenario. Firewire causes a bus reset whenever a new device is plugged in or powered up. The underlying bus protocol makes writing the device-tracking software almost trivial. In a sense this is cheating, however, since it makes the specification dependent upon the underlying network implementation. It would be difficult, for example, to implement HAVi over an Ethernet link that did not provide such hardware support.
In some ways this standard is not directly appropriate for discussion in terms of Internet devices. As I said, it does not support wider connectivity directly to the Internet. It could be an important component in the home entertainment space, however, and the devices that it will support will certainly be connected to create new capabilities for the user.
Solution #2: Centralized knowledge
The second way to perform this discovery process is to centralize the knowledge of the network. In this scenario, a locally available computing resource is tasked with the job of resource manager. Any new device on the network is required to register with this manager, and the manager must also detect when devices are no longer present.
This approach is much more generic. It could be used to handle any network architecture up to (and possibly including) two tin cans and a string. This central manager can also arbitrate access to resources on the Internet, making it at least no worse than the options in Solution #1.
Jini, Sun's Java-based answer to this problem, takes this approach. One major advantage is that driver code can also be stored on the server under the same entry. This code can contain the access classes that will interface to the device. That code can be run on whatever Java Virtual Machine (JVM) is available, making the interface specifications much more flexible.
This solution is very appealing. Centralization of the information minimizes the load on each of the devices in the system, since they are simply required to query the server to line up resources. The server can also allocate these resources in an orderly fashion.
One potential problem with this architecture is stale resource handles. If the information on the server is not up to date it can cause available resources to be invisible or mistaken attempts to use unavailable resources. This is a generic problem whenever a separation exists between dynamic data and its ultimate source.
Jini does recognize this problem. Resources are required to check in regularly with the server. If they do not do so they are dropped from the active list. This does not eliminate the problem of stale data, but it minimize its effects. The database should be coherent within a minute or so of any change. This is not ideal, but it is not too onerous.
One other advantage of this architecture is that relatively little needs to be preconfigured. HAVi requires a fairly rigorous definition of the devices, because access to the devices occurs through a well-known interface specification. Jini, on the other hand, only requires that the devices be put in a general classification such as “video source,” for example. Any device that can source video might show up in this category, be it a video camera or an Internet link to streaming video. The only thing that needs to be preconfigured under Jini is how to find and interact with the central manager.
Solution #3: Decentralized knowledge
Yet another solution to this problem is to distribute the information of available resources directly to the devices that are interested in that information. In this scenario, a new device advertises the details of the services it needs periodically on the network. Any device that is interested in using that service retains the information and uses it to connect with the resource server.
The major advantage of this architecture is that it does not require a central server. This is not inconsequential, because the maintenance of such a device can quickly complicate the lives of users. Central servers are too much like real computers.
The network software that utilizes this method is Universal Plug and Play, Microsoft's entry into this arena. The interesting thing about the press reports I have read about this software is that it is being chided for being too “PC-centric.” This is incomprehensible, given that there is no assumption anywhere in the specification that is dependent on Windows or PCs of any flavor. In fact, the decentralized architecture removes the requirement for any PC-like device from the system, unlike Jini, which depends on the presence of at least one “computer” in the network.
The key under this architecture is the capability to advertise services in a reasonably efficient manner. If this does not happen the network can quickly become clogged with service advertisements, making actual transactions impossible. The resemblance between this scenario and the current state of network television does not exactly minimize concern about it either.
The mechanism Microsoft chose to pass this information is XML. This is an excellent choice, given that it is an open standard for the structured exchange of information. It is not as efficient as the binary exchange of preconfigured messages, but that approach would have locked in the definition of the message structures at too early a phase. XML allows new device types to be released without having to upgrade old systems.
One thing that does have to be defined is the message schema for each of these devices. Microsoft is generally leaving this up to each industry, following the model of most other uses of XML. They are providing a central clearinghouse function to allow these definitions to be exchanged, but they are not enforcing particular definitions.
This has the weakness that the resource provider and the resource user devices must agree on the interface, at least to some degree. This is less flexible than the Jini definition, but it is not an unacceptable compromise. It is certainly possible for companies to add specific value to the devices beyond the generic interfaces to differentiate their offerings.
Mediation of device discovery and utilization is not the only service offered by these suites of software, but it is in many ways the defining one for the genre. As usual, it is quite possible to ignore such standards completely and create proprietary interfaces within Internet devices to lock in users. This approach is very risky, though. Device interoperation is becoming an expected feature in consumer electronics. People are becoming impatient with remote controls that are unique to each device in a rack of systems, for example. These days, it is very rare for a home entertainment system to be built uniquely out of the offerings of a single company.
Internet devices must follow and extend the heritage of consumer electronics. People have made a certain amount of allowance for home computers, but that coin is very nearly spent. Wide acceptance by these devices depends on them taking care of themselves rather than requiring training investment from the customer.
One key to doing this is to use the interfaces I have discussed here. There is confusion because they aren't compatible, some of them may not survive, and they can be restrictive and bothersome. The end result of their use is a device that can leverage the capabilities of the entire network instead of what it provides on its own. That is worth considering.
Larry Mittag is head of the Embedded Systems Division of Stellcom. He has been a contributing editor of Embedded Systems Programming for longer than anyone can remember. He can be reached at .
- Figure 1: Universal Plug and Play client components
- Figure 2: Universal Plug and Play
- Figure 3: Jini
- Figure 4: HAVi
Return to Internet Appliance Design Home Page
Return to February 2001 ESP Index