Internet appliances differ from many embedded products because Internet appliances require connectivity. But it takes more than network hardware and TCP/IP stacks to make a successful Internet appliance. Application connectivity provided by software frameworks is the key.
Service location and identification standards like Jini and Universal Plug and Play (UPNP) are needed to automate connections between Internet appliances. Gateways are needed to provide firewall and management support (see the figure). Data exchange using standardized formats like Extended Markup Language (XML) is needed for cross-platform and cross-vendor support.
These new protocols and frameworks are quickly moving into Internet appliances. Putting a Web server or a Web browser on a device is only the first step in the evolution and provides a limited interaction between devices. A device having only Web-page support will seem trivial in a year or two.
There also is some confusion about what an Internet appliance is. Internet appliances include client-oriented devices such as Web pads, cell phones, and even PCs. Internet-appliance servers tend to provide information or perform a service.
Part of the problem is that only some Internet appliances are strictly clients or servers. Most run a collection of applications that provide or use services. For example, an MP3 storage device with a hard disk may receive streaming audio from the Internet and store it on the hard disk so it can be streamed to an MP3 player or portable unit. The MP3 storage device may be configured remotely, in which case it provides a remote configuration service.
Remote configuration and service location is the reason for Jini and UPNP. Jini is part of Sun's collection of Java specifications. The Universal Plug and Play Forum handles UPNP, which also is part of Microsoft's .NET architecture. Both provide a mechanism for a device to locate devices and services when the device is connected to the network or Internet. Jini goes a step further and locates services. It also can start services on remote devices (see "Service Identification And Location," p. 76).
Operating-system and framework developers are just starting to deliver features like Jini and UPNP. One reason for the slow incorporation of these features is that they are useful only when multiple devices are employed. This includes at least one device that serves as a coordinator.
Typically, a gateway serves as a coordinator. A gateway also can act as a buffer between a standards-based interface and a set of devices where communication is through a proprietary protocol. The Open Systems Gateway Initiative (OSGi) is a Java-based architecture that can fill its void.
OSGi gateways can service any type of device, but they often are used to service small 8- and 16-bit devices that have minimal computing power or memory resources. Such devices were never considered for Internet-appliance designs, but this has proven to be incorrect. This class of processor obviously cannot outperform a 32- or 64-bit solution, but the smaller processors cannot be beat for price.
Products like Rabbit Semiconductors' RCM 2100 series, Microchip Technology's PIC series, and ZiLOG's eZ80 Webserver not only come with TCP/IP support, they also can run TCP/IP-based applications like a Web server or Telnet client (see "TCP/IP For 8- And 16-Bit Devices," p. 78). Products like Ubicom's IP2000 family of Internet processors are specifically designed as a single-chip solution for Internet appliances, including gateways.
Application functionality tends to be limited but more than sufficient for a variety of environments. For example, the number of concurrent sessions a smaller processor can support tends to be low. A single session may be the limit. This is of little consequence if a device will only be controlled using a single session.
Eight- and 16-bit solutions make a lot of sense for controlling or monitoring a limited number of peripherals or peripherals that do not require high-performance applications. These less-powerful processors also can be more economical for modem-based connections.
One area where 8- and 16-bit solutions tend to fall short is security. Encryption algorithms are computationally expensive. Adding hardware encryption support to a design often brings the bill of materials (BOM) in line with or above higher-performance processor solutions. This is where 32- and 64-bit processors are needed.
NetSilicon's Net+50 is a 32-bit, ARM-based, single-chip solution that costs $16.95. The BOM, including 2 Mbytes of flash memory and 4 Mbytes of RAM, is $53 in quantity. This cost is significantly higher than many of the 8- and 16-bit solutions that incorporate RAM and other peripherals onto the chip.
On the other hand, Internet appliances based on 32- and 64-bit processors have the power and memory capacity to run protected-memory operating systems like Linux and a Java Virtual Machine (JVM). JVM support is needed for services like Jini. TCP/IP stacks and services are standard fare. HTML support is not a problem. These processors have no trouble handling newer data formats and protocols like XML and Simple Object Access Protocol (SOAP) where support for these—which is just beginning to appear—is available.
While HTML and direct TCP/IP port communication is the mainstay for current Internet appliances, XML and SOAP will be the basis for communication for the next generation of products (see "The New Language Of Embedded Devices," p. 78). SOAP is based on XML and Hypertext Transport Protocol (HTTP). SOAP is used by the Universal Description, Discovery & Integration (UDDI) protocol.
XML, SOAP, and UDDI are needed to address cross-platform communication issues that arise with Internet appliances. A typical environment will have Internet appliances from a host of vendors and proprietary protocols, and data-exchange formats will make a complex system completely unsupportable.
Moving to new standards like UPNP, XML, and SOAP will be easier as vendors deliver the frameworks to support them. Most developers will not want to build up this support, such as XML parsers, from scratch. This is a substantial job, and developers need to concentrate on application development.
Support for these communication standards from vendors becomes increasingly important as Internet appliances more forward from the current Internet Protocol (IP) to IP version 6 (IPv6).
IP uses a 32-bit address to identify a device. This represents a huge number of addresses, but over half have been allocated. The growth of Internet appliances will hasten the use of IP addresses.
An End To The Address Problem
The 128-bit IPv6 addressing scheme promises to end the address problem and incorporate features that the current IP protocol (IPv4) lacks, such as autoconfiguration and advanced security. IPv6 supports authentication headers and encrypted security payloads.
The big problem for Internet-appliance developers is that IPv6 support is significantly different from IP, requiring at least a change in protocol stacks (see "The Evolving Internet Protocol," p. below). Such a change is a major issue with Internet appliances, even though many are capable of automatic field upgrades.
Part of the problem is that mixing IPv4 and IPv6 on the same network is difficult at best, making it imperative that the switch to IPv6 occur at the same time for all devices on a network. Likewise, it makes it difficult to add new IPv6 devices to an IPv4 network.
One approach to the problem is to isolate an IPv4 network by using a gateway. Network address translation (NAT) is used by the gateway from IPv4 to IPv6. Most gateways already support NAT and use it to hide LAN devices behind a single IPv4 address assigned to the gateway for connection to the Internet.
The change to IPv6 is coming, but it isn't imminent. It will most likely occur on the Internet backbone. Internet appliances most likely to be affected first will be smart cell phones supported by service providers that start using IPv6 and gateways like those mentioned above.
It's clear that the Internet-appliance space must address significant software issues, such as the use of IPv6 and protocols such as SOAP. Available hardware can handle these features, and the hardware will continue to get smaller, cheaper, and faster. The difficult job for developers is to create Internet appliances that won't be logically isolated because their data formats and communication protocols are unique or incomplete.
Internet appliances are attached to local-area networks (LANs) or directly to the Internet through service providers. Although many devices use and provide services, it's easy to see devices in a client-server relationship, such as an MP3 player that gets its data from an MP3 server.
|Companies Mentioned In This Report|
CMX Systems Inc.
Microchip Technology Inc.
Open Systems Gateway Initiative
Rabbit Semiconductor Inc.
Sun Microsystems Inc.
Universal Plug and Play Forum