The setting sun is a pleasant sight while driving home. I’m listening to satellite radio and a call comes in. At my verbal request, the car’s media system switches off the music and answers the phone. I continue the conversation as I pull into the garage and switch the call to my home line as I exit the car. Continuing to chat, I move into a room with an HDTV and switch to video conferencing. The call ends and the radio program resumes from the point of interruption. Finally, I use a graphic control panel to turn off the audio, open the shades, and check my e-mail.
This sci-fi scenario isn’t too farfetched. But while the industry moves in this direction, the coordination and standards necessary for such a level of support are lacking. We currently have a Tower of Babel when it comes to device communication within the home and car. Pockets of devices can communicate with each other, but they tend to be isolated islands, such as security systems or multimedia rooms.
The problem arises because of the many issues involved, such as bandwidth requirements, quality of service (QoS), digital rights management, security, authentication, and authorization. Groups and standards are growing and emerging, but there’s still a long way to go before a truly seamless multimedia communications network becomes reality, especially when it involves multiple vendors.
Established standards have set the groundwork for much of the standardization. TCP/IP and Ethernet are critical parts of the equation, though consumers typically are isolated from these details. For example, Ethernet ports are common on Blu-ray players, but IEEE-1394b links are found on HDTV set-top boxes. Both support TCP/IP protocols.
HDTVs such as Samsung’s large-screen HL-T5687 DLP model use HDMI (High-Definition Multimedia Interface) connections (Figure 1 and Figure 2). This high-speed serial interconnect can be found in all electronic entertainment stores, but most consumers don’t know that highspeed switching is occurring in devices such as HDMI audio amplifier/receivers.
Interestingly enough, HDTVs like Sony’s Bravia tie together the high-speed communication via HDMI and low-speed control with an 802.15.4 remote-control protocol based on Freescale’s 802.15.4 entertainment control platform (ECP) (see “Remote Controls Go From IR To IF” at www.electronicdesign.com, ED Online 16523).
The advantage we have today is that the acceptable limits have been reached. For example, HDMI and HDTV standards set an acceptable limit for most devices that will enter the market over the next 10 years. They aren’t the absolute limit, though, because HDMI and HDTV are defined past the 1080p standard commonly accepted as the high end for consumer video.
Much of the standardization work has centered around the hardware, usually pushing performance to the limits. Wi-Fi, Ethernet, and HDMI are joined by phoneline links from the 320-Mbit/s HomePNA Alliance to the 200-Mbit/s Homeplug Powerline Alliance. The Multimedia over Coax Alliance (MoCA) targets existing in-home cable networks with 175-Mbit/s throughput.
These high-speed links can deliver highquality video and often HD video in uncompressed form. The primary limitations occur when they’re dealing with multiple streams of HD video, but they usually utilize compression to handle those streams.
The new HomeGrid Forum was formed to unify this fragmented hardware market with a common physical-layer/media-accesscontrol (PHY/MAC) approach. It supports the work of the International Telecommunication Union (ITU-T) G.hn committee. Concentrating on the hardware and low-end software levels is useful and can simplify the job significantly, but it doesn’t force interoperability at the application level. Of course, resolving currently inconsistent networking platforms and protocols will be a challenge.
Essentially, the homemultimedia data plane doesn’t address the control or management plane. This is where infrared control units such as Logitech’s Harmony 1000 attempt to control multiple devices, albeit at a very local and limited level (see “Logitech Harmony 1000,” ED Online 17953). The result is quite useful, but it’s a far cry from an integrated system.
Likewise, the standardization of profiles in the ZigBee Alliance is enabling interoperability among control and status devices in a range of environments, such as lighting control. As with many other networks, interoperability among devices within the homogeneous network is possible and sometimes automatic. However, transitioning this control and information to or through other networks generally isn’t possible.
Continue on Page 2
The integration of all types of networks and control systems will be required to combine the islands of devices, allowing for more general solutions. A basket of incompatible remote controls is only the tip if the electronics iceberg as networked devices within homes and autos become more common. Solving this problem requires cooperation at a higher level.
MOVING UP THE FOOD CHAIN
The Universal Plug and Play (UPnP) Forum addresses device control protocols. Its UPnP extensions are utilized in a range of standards, including Microsoft’s Windows and the Digital Living Network Alliance’s (DLNA’s) protocols (Fig. 3).
UPnP addresses the discovery, description, and control of devices on a network without specifying the hardware interconnect. It rides on top of protocols like TCP/IP and UDP, using formats such as XML. Authentication tends to be a problem, though. And while UPnP incorporates audio/video standards, DLNA takes these standards even further with more detailed support for multimedia devices and controls.
Like the HomeGrid Forum, DLNA wants to give devices a common playing field. It targets the home, primarily entertainment, incorporating mobile devices into the environment. This is reflective of the DLNA membership list, as well as the initial crop of standards coming out of the organization. Of course, getting these details requires DLNA membership, which can be restrictive but not difficult to achieve.
Open-source support for basic DLNA features is available, but DLNA definitely targets entertainment and communication vendors. It appears to be one alternative that can provide an overarching link between devices. The competition, or complementary platforms depending upon your view, comes from the High-Definition Audio/Video Networking Alliance (HANA) and Microsoft.
HANA is an entertainment platform initially based on IEEE-1394b, with HDTV as its target. The synchronous nature of IEEE-1394b enables the delivery of multiple HDTV streams. Supporters point to this ability to deliver QoS at HDTV speeds when they compare HANA to DLNA, which is typically found on Wi-Fi and Ethernet platforms. While Wi-Fi and Ethernet are now gaining QoS support, they don’t enjoy widespread availability.
It’s interesting to note that set-top boxes require IEEE-1394b support. No one really uses this feature yet. But like DLNA, HANA-based devices will start showing up soon. The big question is whether any approach will reach broad distribution.
Microsoft supports DLNA, but the company also has a host of technologies that it would rather have developers use, such as Rally (formerly “Windows Connect Now”), Web Services on Devices (WSD), and Device Profile for Web Services (DPWS). Of course, all of these technologies require .NET, which in turn requires a Windows operating system. Adoption is great for Microsoft, though these protocols probably won’t wind up on other platforms.
As noted, all of these standards can coexist and will likely do so. The big question is if any of them will dominate the market or if a new platform will emerge.
DLNA NETWORKING DEVICES
The potential flood of devices using standards such as DLNA is just beginning. File services are the easiest to implement. They generally include platforms such as NAS (network attached storage), which store software (music, video, and other media versus programs) for streaming to playback devices.
NAS devices are already available, though you might miss the DLNA logo if you aren’t looking for it. As with all similar approaches, products only make sense when they’re used in conjunction with other devices. A single device is akin to a network with a single node—not much to talk to.
This means that most initial devices will provide services that can be delivered independently of the DLNA feature. For example, Nokia’s N95 8GB is a certified DLNA mobile phone. It has 8 Gbytes of storage and is a multimedia playback device. The phone includes a 5-Mpixel camera and can operate in standalone mode from a multimedia perspective, but it gets more interesting when DLNA is brought into the equation. It can play back content from other DLNA devices, as well as deliver stored content to other DLNA devices.
Continue on Page 3
Buffalo Technology’s LinkTheater High Definition Digital Media Player offers HDTV via HDMI outputs (Fig. 4). It supports 720p and 1080i video output in addition to 480i and 480p video modes. The unit includes USB and 10/100 Ethernet ports. Of course, it has audio and video outputs, too. It can handle a range of audio, image, video, and multimedia formats, including JPG, BMP, PNG, and GIF file display plus MP3, WAV, WMA, Dolby Digital (AC-3), AACLC, and AAC-HE audio.
Of course, the LinkTheater High Definition Digital Media Player requires a data source. Buffalo Technology offers a number of DLNA options. The technology additionally works with other DLNA-certified sources, including many PCs that run the Linux or Microsoft Windows operating systems.
People will want DLNA-compatible DVRs, which dredges up some issues that have slowed down agreements on the standards and long-term adoption of the technology. At the top of the list is copy protection, or, depending on your point of view, customer management. Digital rights management (DRM) is the watchword and as much a sticking point as the multiple protocols and hardware interfaces, if not more so.
There’s some commonality in certain areas, such as HDTV HDMI links that employ highbandwidth digital content protection (HDCP), but this isn’t something used across streaming video standards or storage standards. DRM won’t disappear completely, even though many designers wish it would. Hopefully, the trend of decreasing DRM on the audio side will trickle down to the video arena.
The problem is that DRM uses encryption, but it has absolutely nothing to do with system security and authentication from a user’s perspective. In addition, a tremendous amount of time and effort has been spent on DRM, with comparatively little on user management of system security and authentication. An overarching system design should really start with security and management, including making it easy to use.
The number of remote access links into a home is increasing, and using only firewall/ gateway-style protection is a sure path to botnets that are even more massive than those infesting PCs already. Most standards haven’t overlooked security, but it should be a unifying— instead of a secondary—design issue.
Expect the emergence of DLNA devices and the appearance of HANA devices this year, as well as the adoption of ZigBee control units and similar control platforms. Likewise, HDTVs will be mandatory, leading to a range of potentially networkable products available to consumers and as targets for developers.
Unifying this disparate collection of devices remains a long-term goal using common protocols and applications. Still, it’s likely to remain a challenge to developers and consumers for a number of years to come.