IEEE 1394 drives expand video-storage options

Personal video recorders and similar set-top boxes record digital data to an internal hard-disk drive for playback either seconds later in a time-shifting application or months later in a video archive. However, issues with cost, customer control of upgrades, and reliability arise when using this embedded-storage approach. To address these issues, manufacturers could move the disk drive outside the set-top box with a high-speed interconnection-bus technology, such as IEEE 1394. You can achieve the advantages of external 1394 plug-and-play storage with off-the-shelf asynchronous drives and in the near future with isochronous audio/video drives. Understanding the pros and cons of the two approaches is important to enabling the best external storage and ensuring the best user experience with video-storage applications.

The IEEE in 1995 ratified 1394 as an official standard for a high-performance serial bus. Since then, the organization has added extensions 1394a-2000 and 1394b-2002. The 1394a-2000 standard adds improvements in bus efficiency, such as the short, "arbitrated" bus reset and power management. It uses the same cable and data-strobe-coding technique as the 1394-1995 standard. Industry participants commonly refer to both of these standards as 1394a. The new 1394b-2002 standard, 1394b, adds provisions for higher data rates, longer distances, and support for different media types, such as Category 5 UTP (unshielded twisted pair) and optical-fiber cables. So-called bilingual 1394b devices will support both the 1394/1394a-signaling method and the new 1394b 8b/10b-signaling scheme. Table 1 shows the speeds, distances, and media types that 1394b supports. Higher speeds and longer cabling are key advantages that 1394b brings to plug-and-play storage for consumer-electronics applications. Users need more bandwidth to stream more simultaneous channels of video. Users also want to use a storage unit from multiple locations within their home via a wired home network using 1394 over UTP 5 or optical fiber. The 1394b standard enables both of these applications.

The 1394a and 1394b standards define asynchronous and isochronous transactions as way to transport data. Asynchronous transactions guarantee packet delivery and provide acknowledgment packets. Asynchronous transactions require a command for each transfer over the bus and are ideally suited for data for which confirmation of delivery is more important than delivery time. Isochronous transactions have guaranteed bandwidth slots for each bus cycle. The isochronous transactions do not require a command for each transfer and continue to stream data until a user stops them. They do not receive an acknowledgment for the delivered data. Isochronous transactions are ideally suited for data for which delivery time is critical.

Whereas the IEEE 1394 standards define the bus-level architecture, higher layer protocols define the command and control necessary for transporting data over the 1394 bus. The asynchronous SBP2 (Serial Bus Protocol 2) and the isochronous AVC (audio/video command) are two distinctly different transfer mechanisms for 1394 disc-based storage applications (Reference 1). The industry refers to hard-disk drives implementing the SBP2 protocol and the AVC transport mechanism as 1394 SBP HDDs (hard-disk drives) and 1394 AVHDDs (audio/video hard-disk drives), respectively. You can use either method to implement an external 1394-based personal-video-recorder storage media for a set-top box.

The 1394 hard-disk drives based on the SBP2 protocol that are currently available for the PC market are typically not much more expensive than bare ATA drives. They provide mobility for data and allow for easy upgrades in capacity. Using these off-the-shelf plug-and-play hard-disk drives to add external-storage capabilities to digital-cable and satellite set-top boxes would seem straightforward, but this approach also has pros and cons. Figure 1 shows an example of a 1394 SBP2 HDD implementation for the set-top-box external-storage example.

The developers of the SBP2 standard created it to provide a 1394 serial-bus-interconnection means for ATA/ATAPI devices. The official standard is ANSI NCITS 325-1998, Serial Bus Protocol 2. The SBP2 architecture borrows the concepts of target and initiator from SCSI terminology in which the initiator starts tasks, such as data-read or -write events, and monitors correct completion. The target executes tasks it retrieves from the initiator and responds in accordance with the underlying command set. Once a target completes its task, it alerts the initiator by sending status. The target has no knowledge of the data content other than size and thus views all data transfers as simple block data transfers. SBP2 is inherently a "pull" type of data transport: The host simply queues data to be transferred and leaves the SBP2 target responsible to DMA data between host memory and the target's media. The SBP2 file-transfer mechanism includes no provisions for audio and video control, such as volume control, fast-forward, or rewind. Software at the application layer in the host instead handles this type of control. Figure 2 shows the layer-stack differences between an SBP2 disk drive and an AVHDD.

Although SBP2 drives are widely available and lower in cost, system engineers should understand bus-bandwidth, content-protection, and SBP2-architecture issues before implementing a video-recording application using 1394 SBP2 HDDs. The SBP2 protocol transfers data using only 1394 asynchronous-data-transfer services, which provide guaranteed delivery, but, unlike isochronous services, have no guaranteed bandwidth on the bus. The 1394 architecture lets you reserve as much as 80% of the bus bandwidth resource for isochronous data transfers, which leaves a worst-case maximum asynchronous bandwidth of 20%. System designers should also expect other nodes to require a piece of the asynchronous bandwidth for command and control communication.

Content providers and broadcasters are concerned about copy protection of data, especially data on digital interfaces, such as 1394. The DTCP (Digital Transmission Content Protection) specification provides content protection for premium audio and video data using isochronous services over 1394 (Reference 2). However, no standard exists for audio- and video-content protection for asynchronous data over 1394. If an external 1394 HDD using SBP2 asynchronous services requires content protection, then the method must be a proprietary implementation, and manufacturers must get approval from groups such as the Motion Picture Association of America and content providers for their proprietary implementation. In addition, because the content-protection method for an external 1394 SBP2 HDD is nonstandard, the manufacturer must dedicate the disk drive to the content source. Consumers may not tolerate restrictions on their recorded material because they will have to play a movie back through the same set-top box that originally recorded the content.

According to the SBP2, the set-top box would act as the SBP2 master, and the external SBP2 drive would act as the target. The set-top-box master is responsible for initiating all requests to the target. However, the SBP2 drive would control the pace of the data transfer according to its capabilities. The set-top box must be able to handle large amounts of asynchronous data at the target's pace. This situation is not a natural fit for real-time data movement, such as audio and video streams, in which the model is inherently a push-data model. In this mode, the source "pushes" data to the sink or the receiver. The current architecture of video recorders dictates that the set-top-box CPU must be involved with data transfer for every 1394 packet. The 1394a packet size can vary from 512 bytes to 2 kbytes, and a 1394b packet can reach 4 kbytes, depending on the medium. This extra activity can add up to a lot of CPU bandwidth when transporting audio and video streams.

The set-top-box CPU using SBP2 HDDs must manage the file-allocation system on the external drive, just as a PC would. This involvement adds a burden to the set-top-box processor and adds software complexity to the video recorder. Some set-top-box designs manage the file system for their internal hard-disk drives, so adding an external SBP2 HDD requires mapping the current file system to the external disk.

The SBP2 requires logins between the initiator and the target, so HDD "ownership" and race conditions among multiple initiators can present problems. A user may have multiple 1394 consumer-electronics devices that need to use the SBP2 drive as their archival medium. For example, an audio recorder could store audio tracks along with the set-top box's archived video streams. However, two hosts cannot simultaneously share an SBP2 HDD unless one of them runs a file-server application. Further complicating things, a possible login-race condition can occur when two nodes attempt to log in to the SBP2 drive at power-up. Set-top-box designers who want permanent external storage units can resolve these issues by including a second 1394 port that is physically separate from the other audio- and video-streaming port.

The alternative to the 1394 SBP2 HDD is a 1394 AVHDD, which allows the set-top box to directly send real-time audio and video streams to the storage media using 1394 isochronous streams (Figure 3). The AVHDD system has more capability and autonomy than the SBP2 HDD. AVHDDs act as stand-alone nodes on the 1394 bus and manage their own internal file system. A single host residing elsewhere on the bus does not "own" them, and they appear as digital VCRs to other 1394 nodes. As such, they can record, play back, fast-forward, and rewind many forms of audio and video content.

Unlike their SBP2 counterparts, a 1394 AVHDD can receive isochronous audio or video streams and store these streams on the disc in the form of tracks. The AVHDD uses descriptor information of these tracks to control their organization on the media. Another node on the 1394 bus can request lists from the AVHDD that show all content on the AVHDD and selected parameters of this content. The 1394 AVHDD can offload this disc-content-management function from the software load of the set-top box, thereby freeing up CPU resources. The 1394 AVHDD supports storage for only audio and video data. The 1394 standards defining the form and function of the AVHDD clearly distinguish between such audio and video content and "computer" content, such as a typical operating-system file system. Audio and video content is content you place on the AVHDD using AVC commands. The embedded AVHDD controller and other nodes on the bus that communicate to the AVHDD via AVC can "see" only that content. Accessing any computer content that might exist on the same media within an AVHDD unit requires the use of other protocols, such as SBP2.

When the AVHDD stores the audio or video data, it must preserve the timing relationship between the data. Because it is isochronous, the audio or video stream that an AVHDD plays back must transport at its original rate. The AVHDD can re-create the original stream rate by using presentation time stamps. The AVHDD can play back at the maximum 1394 isochronous-packet allocation of 4 kbytes per isochronous cycle. However, if the AVHDD transmits the stream at that speed, it quickly overflows the receiver's buffers and possibly underflows its own buffers. The presentation time stamp paces how fast the AVHDD transmits the stream to the receiver. Figure 4 shows the differences between using the presentation time stamp to generate the playback rate versus playback at the maximum 1394 rate.

The AVHDD option brings several key advantages to external set-top-box-storage application, including the simplification of the data-transfer model. With a 1394 AVHDD, the source device can "push" audio and video content to the disc, just as it would any other sink device on the 1394 bus. The content simply streams from the source using isochronous services and alleviates the need for a DMA scheme with associated CPU overhead to set up and manage for moving the data between nodes. Another advantage of AVHDDs is their ability to leverage approved copy-protection methods. AVHDDs can transfer protected content and use the standard DTCP, or 5C (for standard supporters Hitachi, Intel, Matsushita, Sony, and Toshiba). The Digital Content Licensing Authority licenses the keys on "reasonable" systems. The DTCP system provides a layer of protection to the data during its transition across the bus and also ensures the authenticity of the AVHDD storage unit itself. Users could encrypt the data before archiving or temporarily storing it on the AVHDD using the standard 4C (for IBM, Intel, Matshushita, and Toshiba) CPRM/CPPM (Content Protection for Recordable Media/Content Protection for Prerecorded Media) standard (Reference 2). AVHDD manufacturers also can use their own proprietary approaches to protecting data stored on disc, or they could extend the broadcast-conditional-access system to include the archived audio and video data on disk.

The AVHDD can also offload some tasks from the source's CPU, which frees resources on the set-top box. Unlike an SBP2 HDD, the AVHDD records and plays back a real-time isochronous video stream. The scheme does not require the set-top-box CPU to parse the data or perform any handshaking such as SBP2 requires. AVHDDs also move the task of file-system management from the set-top box to the drive, again freeing some CPU resources. Because the AVHDD is a stand-alone storage unit on the bus, it suffers none of the SBP2 symptoms of multiple-user access. AVHDDs can feed the same content to multiple targets, assuming that all targets are authenticated per the content-protection protocol that is in use. Some new AVHDDs can support multiple recording and playback streams. This ability means that it can simultaneously record programs for two or more source devices and play content to two or more other target devices.

AVHDD devices do have disadvantages, such as the fact that few off-the-shelf products are now available. Cost is also an issue because these drives are more complex and require more buffer memory than the current SBP2 drives. Another issue is the ability of any AVC node on the bus to connect to and use the AVHDD resources. With no method available to set priorities to AVHDD access, this situation entails the risk that the set-top box could be without storage for some amount of time.