The Digital Living Network Alliance (DLNA) and the High-Definition Audio-Video Network Alliance (HANA) are both working on home networking solutions that can distribute video entertainment. Both recognize that simplicity is the number one goal. However, the definition of 'simple' in the PC world is not the same as it is for watching a TV.

View full size
Figure 1: HANA typical home network

HANA & DLNA: The differences
DLNA approaches home networking from a PC perspective. Though a PC is not required, the DLNA network was created to solve many of the issues a PC deals with. Those issues have roots in the vast array of devices that come not only from different manufacturers and service providers, but also from different industries, each with their own way of doing things. Connecting to these devices requires a set of protocols and device drivers that constantly change with each new generation of devices, processors and operating systems.

Television is a very well defined and unified platform. Cable, satellite and online content providers, as well as CE manufacturers, all come from different industries. However, the rules are already well defined and rarely change.

The second difference comes from the ways in which PCs and TVs move data between devices. The PC has traditionally received a file from some source such as the Internet, CD or DVD, and then either used the file itself or moved it to a printer, MP3 player, or other devices to use. The TV operates in a world of real-time streaming. Whether it's over-the-air broadcast, cable, satellite, DVD or PVR, the TV receives an uninterrupted, real time stream of bits. Any interruption in the stream means an interruption in the viewing or listening experience.

Another difference is in security. We are all aware of PCs' security problems including viruses and hackers. Operating systems and other programs are constantly updated to plug security holes. The potential for a hacked system to allow content theft or illegal copies to be made is a major concern for content owners who zealously protect their products.

Protecting content in a PC environment is extremely difficult and often carries with it many restrictions on usage. The end result has been for most hardware and content providers to use proprietary solutions that only work on their platform, such as Apple TV, TiVo, and NetFlix. On closed systems such as TVs, DVD players, or set top boxes, protecting content is far easier than in a PC environment.

Finally, in a world of software and firmware updates, consumers are never certain that two devices can work together. Even if they are compatible, issues may arise, due to the ever-changing software and device configurations.

By contrast, the TV viewing population can be relatively certain that if something does not work, it's not an incompatibility or missing software issue, but a question of correctly connecting and controlling the devices.

With TV having less complex problems, HANA has been able to focus its efforts on creating a standardized solution with one network connection (FireWire -- the industry name for IEEE 1394), one remote control and one consistent User Interface. (See Why HANA, Why Now for additional information.)

Thus it is the starting point -- PC versus TV -- that defines the problems that HANA and DLNA attempt to solve, and that creates the difference in their definition of 'simple'.

Next: Solutions comparison
Solutions comparison
The PC has evolved to deal with the vast array of different devices and services, by including or downloading the necessary drivers and protocols for each class of device it connects to. In contrast, the TV entertainment system is composed of devices that may never change once they leave the factory. If they are to connect to other devices, the resources needed must be built in from the start.

Both organizations are creating communications methods that will allow devices to communicate over a standard protocol set. However, standardization is, in reality, a negotiation. And since the DLNA's negotiations involved a larger number of companies and industries, each with their own ways of doing things, those negotiations are far more difficult and complex.

In the TV world, the TV and broadcast industries, along with the FCC, have long been the driver for standards. All other devices have been required to accommodate these standards. Although cable has complicated the situation, the cable, TV and broadcast industries have settled on the codecs (MPEG2, MPEG4, H.264) along with HDMI and the FCC-mandated 1394 port for all HD STBs. With the TV-specific end of the connection well defined, that leaves only the networking side to complete.


View full size
Figure 2: DLNA and HANA comparison

HANA and DLNA similarities
HANA and DLNA utilize many of the same protocols above the MAC and PHY layers (layers 1 and 2). Both are based on IP network protocols. HANA and DLNA use TCP/IP, and either DHCP or Link Local addressing in the absence of a DHCP server. Both also use Simple Service Discovery Protocol (SSDP) to discover devices. With common IP addressing and discovery, devices on a DLNA network are discoverable by those on a HANA network. They also both use XML as a description language and HTTP to transfer information. Furthermore, both use xHTML, a version of HTML that uses XML syntax as their mark up language.

Another similarity is that both organizations require that their specifications be based on public standards. While there are differences, bridging the two should be relatively simple using commonly available software. DLNA requires a larger stack due to its need to communicate with a broader set of devices, but much of the protocol stack is reusable by a HANA device. Finally, HANA devices can operate with a FireFox browser and standard web server software. Since most DLNA networks will include a PC, it is clear that the most common device for bridging the two would be the PC itself.

Next: Quality of Service
Quality of Service
Moving files versus streaming content place different requirements on the underlying network. For example, a movie is a large collection of bits. Regardless of how those bits are moved, the network has to provide relatively high throughput. The difference is that when moving a file, if some data packets take longer to get through the network, there is little impact on the end user. However, when streaming, delays on the order of milliseconds can create an interruption in the program being watched. The ability to deliver data packets, in a reliable and predictable manner, is called Quality of Service (QoS). Ensuring on-time delivery is called guaranteed QoS.

DLNA has selected Ethernet as its primary network, while HANA has selected FireWire (IEEE 1394). There are excellent reasons for both choices. Ethernet is the standard network connection for PCs, as well as for broadband modem connections. Ranging from 100 Mbps for 100baseT to 1000 Mbps for gigabit Ethernet, the connection is fast. FireWire has a fast connection as well, with over a billion ports operating at 200 to 800 Mbps today, 1600 Mbps chips now available, and 3200 Mbps on the horizon. While both connections are fast, the basic architecture is very different.

View full size
Figure 2: DLNA and HANA comparison (repeated for clarity)

Ethernet is an asynchronous network while FireWire supports both isochronous and asynchronous traffic. This means that Ethernet is inherently built to move files, while FireWire is built to stream. Also inherent in their architecture, is the overhead needed to communicate. The network and processing overhead, generated by adding more network connections, increases rapidly for Ethernet, whereas connecting more devices to a FireWire network only increases the overhead incrementally.

The difference in architecture also affects the approach to QoS. Ethernet was designed as a best effort network. With traditional Ethernet, all devices on the network simply compete with each other to send their data packets. FireWire was designed to guarantee QoS by providing bandwidth reservation. Devices reserve the amount of bandwidth required for as long as it is needed.

The companies developing DLNA are providing several mechanisms that improve Ethernet's QoS. The first is prioritization. Using IEEE 802.1p/q, and UPnP QoS, devices can decide which applications get priority access to the network. While prioritization still does not enable streaming, it does reduce the amount of buffering required at the end device. However, QoS can suffer both unacceptable delays, caused by too many high priority connections being made, and the possibility of lower priority applications not getting through.

Next: UPnP 3.0
UPnP 3.0
UPnP 3.0 specifies a still better solution: parameterization based on work done in IEEE 802.11e and the UPnP Forum. This allows the QoS Manager and QoS Host, as defined in UPnP 3.0, to determine the parameters a connection requires. Such parameters include traffic class and peak, mean and burst data rates, among others. Once these are known, the QoS Manager can negotiate with the QoS Host and allocate the necessary resources to the traffic for a guaranteed connection. UPnP 3.0 also has ways to measure the network performance periodically to ensure it is performing as expected. If a new connection is requested, the QoS Manager determines if the resources exist, and if not, what connections need to be eliminated or limited to free up resources.

FireWire does all of this automatically and as such there is no need for QoS Managers and QoS Hosts. The network itself handles the reservations and allocates the bandwidth on a first come, first serve basis. Streaming connections are assigned guaranteed bandwidth on the isochronous channel, those that do not use the asynchronous channel. When there is no more reserved bandwidth to allocate, the requesting service is notified, at which point, the user or a higher layer application can decide how to free up the resources.

While these approaches sound similar, there are a few major differences. The first is that all FireWire devices operate by the same rules -- an application requests bandwidth and if the bandwidth is available, it is assigned. If it does not require guaranteed reservations, it is assigned to the asynchronous channel. Ethernet on the other hand cannot truly guarantee a connection. Lower priority applications can be blocked entirely, and even high priority applications can experience non-deterministic latency and jitter.

The network overhead can become particularly problematic. As more data packets are exchanged to provide QoS, the bandwidth available for applications is reduced. There also must be dead time between packets. Therefore as traffic increases, the ability to control latency is reduced. To provide deterministic latency, you must over subscribe bandwidth and limit the size of the packets. This reduces the amount of available bandwidth further. In a typical Ethernet implementation, it is not uncommon to only be able to use 50% of the bandwidth to be assured that video traffic will not suffer delays. For a similarly loaded FireWire network, that number is 90% or more.

Finally, FireWire includes a system wide clock that all devices use. For example, when a video is sent to a TV and the audio to a 5:1 receiver, the two can easily resynchronize to ensure lip sync and maintain surround sound effects. Ethernet has no such clock. Therefore additional protocols (and complication) must be added to resynchronize the data flows.

Ethernet, as the preferred network for the PC, was the logical and obvious network of choice for DLNA. However, that starting point led to a need for additional software and network overhead, in order to support streaming applications. By not worrying about the non-TV applications, HANA is able to specify a simpler protocol stack.

The difference in the choice of MAC/PHY layers and the resulting differences in QoS complicates attempts to bridge the two. However, Pulse~LINK, a fabless semiconductor and HANA member, has developed a technology called CWave that simplifies the task. CWave conforms to the 1394 Trade Association's coax bridging standards, specified by HANA for 1394 over coax. When added to a device or coax bridge, CWave delivers 400 Mbps of isochronous and asynchronous data over the existing coax infrastructure, without affecting cable or satellite signals. Pulse~LINK is also developing a bridging solution that maps UPnP QoS to the guaranteed QoS provided by FireWire. Thus the coax backbone will ensure that content sent over a local, in-room Ethernet link will be guaranteed the bandwidth it requires between rooms. Therefore CWave can form the backbone for both HANA and DLNA networks.

Next: Security
Security
A secure network is critical for high value content. HANA's task is simplified by focusing primarily on closed systems that are inherently difficult to hack. Of course, HANA would like PCs to be able to connect to its network as well. However, the PC is not a central device in a HANA network and most people would forgo connecting it if there are other ways to connect to the Internet.

To secure content, HANA is working with IBM, a HANA member, to develop a new method based on the AACS broadcast encryption used by Blu-ray DVDs. AACS uses AES-128 bit encryption to secure the content. The difference is that AACS is for optical media, not for networks.

To extend it to networks, IBM developed Advanced Secure Content Cluster Technology. ASCCT defines, among other things, a key exchange methodology that allows devices to "bind" to a network to form a cluster of trusted devices.

Content that has been legally obtained is also bound to the network with ASCCT. Any bound device will have the necessary information and keys to decrypt bound content for playback. Even portable devices are supported, since as a member of the network, they will have the keys.

In order to obtain a license for the keys, the manufacturer must prove that the keys, and their use to decrypt the content, will occur in a secure processing module. This is typically within a System on Chip (SOC) or a special purpose processor with a secure processing area that is inaccessible from the outside world. Such processors also include methods to ensure the firmware cannot be or has not been compromised in anyway.

A PC is more difficult to secure in this manner. The data paths within the PC, and the processors used, are open to probing using hardware or software. Although possible, it's far more difficult to prove that the keys and content have been and will remain secure. To date, few content providers have been convinced the PC is secure enough for their highest value content such as HD movies.

Next: THE Box reference design
What's next?
HANA is developing a reference design called The HANA Entertainment Box (or simply THE Box). It connects by Ethernet to any DSL or Cable modem and from there to content service providers. THE Box includes a hard drive to store content and for PVR functionality, the necessary decryption engine and content decoders (MPEG2, MPEG4, H.264) and an HDMI output to a local DTV. It sounds like a DLNA Digital Media Server/Adapter, but that is where the similarities end.

THE Box can also include a FireWire port to connect to cable STBs, which by FCC mandate, must include a FireWire port as well. Most STBs already connect to TVs over HDMI, however. THE Box includes a CWave enabled coax jack that can be connected to existing coax cable infrastructure. The coax connection actually turns every coax jack in the home into a 400 Mbps FireWire network connection. If you want to connect a second DTV in another room, consumers can purchase a HANA Media Client and simply connect it to the coax jack and the HDMI port on the DTV. Thus any DTV can access the Internet, stored content, the cable STB, etc. A single remote control allows you to access and control any connected device using the on-screen graphical user interface.

View full size

Figure 3: A HANA home entertainment network based on THE Box

By using 1394, HANA can utilize the well known and trusted DTCP link protection and localization solution already approved by CableLabs for cable content, the MPAA, and by AACS for Blu-ray DVD. Combined with ASCCT, the home network becomes a completely trusted environment for even the highest valued content. Once THE Box has been connected to a coax jack, any HANA device can be connected to the HANA coax network. A typical HANA network based on THE Box can be seen in Figure 3.

A benefit of ASCCT security is that a PC can be connected to the network even if it is not secure enough to join the cluster. A content provider can send multi-tiered content to the PC. Standard Definition (SD) content using less secure protection can be viewed on either a PC or a DTV. Higher valued content, such as a recently released HD movie, can be stored as an encrypted file on the PC. The PC would not have the keys and therefore could not decrypt it. It would only be able to stream it over the network to a trusted cluster member, which would have the keys.

Two solutions for the home
It's clear that consumers would benefit from a simpler PC experience and a simpler TV experience.

HANA will provide the necessary simplicity and reliability expected by consumers when watching TV, regardless of where that program may originate -- the Internet, cable or even a PC. DLNA will simplify connecting the vast array of devices consumers attach to their PCs. Consumers will get the best of both worlds by having two separate yet connected networks, each of which is optimized for the task at hand, yet able to share files between them through a bridge, and even across the same 400 Mbps coax backbone.

About the author
Bill Rose is the founder of WJR Consulting Inc. advising companies on product and business development, market strategies, and standards relating to CE and entertainment networking. Prior to founding WJR Consulting, Bill was VP of Electronic Products at Leviton with responsibility for a $100MM product line. Other positions have included VP and Co-founder of InfraVision, and Director of Advanced R&D for Coleco. Bill is a member of the 1394 Trade Association's Board of Directors, chairman of the 1394 TA's Marketing Working Group, and also chairs the CEA's Home Networking Committee. He has spoken at over 30 conferences including CES, CEDIA, UPnP Forum, WIFI Planet, Connections, NAB, and SMPTE. He can be reached via info@rapidmind.com.