Concurrent Control of IEEE-1394 Devices Using Universal Plug and Play and Audio Video Control Protocols David Siebörger and Richard Foss Department of Computer Science Rhodes University Grahamstown, 6140, South Africa Phone: +27 (46) 603 8291 Fax: +27 (46) 636 1915 E-mail: [email protected], [email protected] Abstract – Universal Plug and Play (UPnP) is a standard developed to allow configuration-less connection and control of networked devices. The Audio Video Control Digital Interface Command Set (AV/C) is a specification for control of audio-visual equipment on an IEEE-1394 bus. This paper examines these protocols and how an audio visual device on an IEEE-1394 bus might be controlled using both control protocols simultaneously. Keywords – home networks, IEEE-1394, Universal Plug and Play, Audio Visual Control protocol* I. INTRODUCTION Home entertainment systems today are a collection of audio visual devices connected with many different types of cables. This is difficult to install, can result in poor quality connections, and is incompatible with future digital entertainment media. An IEEE-1394 network can replace those cables with a single digital network. A control protocol is needed to allow devices from different vendors to interoperate on the network. Two potential control protocols are Universal Plug and Play and AV/C. However, market factors and the nature of these protocols have caused the combination of the two to be an attractive option. In this paper, we shall explore these two protocols, their relative advantages and disadvantages, and the implementation difficulties posed by their combination. II. IEEE-1394 NETWORKS IN HOME ENTERTAINMENT SYSTEMS The IEEE-1394 standard [1], known as “FireWire” or “i.LINK”, defines a high-speed ergonomic peripheral bus. The original 1995 standard has been amended by the 1394a2000 standard [2] and by the 1394b standard [3]. The bus is capable of transferring asynchronous data packets, and isochronous digital media streams with guaranteed bandwidth. Data is transmitted serially at speeds ranging from 100 Mbps to 3.2 Gbps on a variety of physical media including STP, UTP, plastic and glass optic fibre. Standardised four-, six- and nine-contact connectors are used to connect devices to the FireWire bus, with most *

This work was undertaken in the Distributed Multimedia CoE at Rhodes University, with financial support from Telkom, Comparex Africa, Letlapa Mobile Solutions and THRIP.

devices having between one and three connectors. The bus topology is unstructured, allowing devices to be connected to each other in any way. Loops are forbidden by the 13941995 standard, but can be automatically eliminated in 1394b-compliant buses. The bus can provide power for low-current devices, eliminating the need for separate power supplies. FireWire-compatible devices available now include camcorders, digital cameras and component hi-fi systems such as the LISSA from Sony, and external hard disk drives from Western Digital. Low-cost PCI interfaces are available for PCs and are starting to appear as standard equipment on the motherboard, while most recent Apple computers have an integrated FireWire interface. Operating systems that support FireWire include Microsoft Windows ME and XP, MacOS, Linux, NetBSD and FreeBSD. In future, a home entertainment system could have all devices connected together to form a FireWire bus. Instead of using an analogue RCA connection between a CD player and an amplifier, both devices would be connected to the 1394 bus and the audio would be transferred digitally using an isochronous stream on the FireWire bus. Once all the devices in a home entertainment system are networked, it becomes possible for one device to control another device. A device in the system could use a PC, palmtop computer, or digital TV to display a far richer interface to the user than is possible with a small LED display. FireWire’s asynchronous data packets are able to carry commands and responses between a control point and the device being controlled. Universal Plug and Play (UPnP) and the Audio Visual Control (AV/C) protocols are two control standards suitable for use on a home entertainment network. III. UNIVERSAL PLUG AND PLAY Universal Plug and Play is a standard developed by the UPnP Forum, which is led by Microsoft, but has nearly 600 members. It aims to make connecting, configuring and controlling networked devices easy. The UPnP Device Architecture [4] defines a protocol stack that is based upon and advances open Internet standards such as HTTP and XML (Extensible Markup Language). UPnP implementations can be network-, language- and vendorindependent.

Microsoft leads the UPnP Forum, and authored the device architecture (though royalty-free licences are available to forum members). Microsoft envisages that UPnP-compliant devices will form the networks that will be the foundation for the delivery of .NET web services. XML-based protocols such as SOAP are fundamental to both. For example, a UPnP control point might use a SOAP method to start a DVD player playing, while a .NET web service might use a SOAP method to perform an online shopping transaction. The area that has seen the most UPnP product development is that of the Internet Gateway Device (IGD). Products such as the D-Link DI-804 and Linksys BEFSR41 broadband routers use UPnP to allow a home network to be connected to the Internet without any user configuration. Microsoft Windows XP’s Internet Connection Sharing also implements the IGD specification. Devices of other types are still under development by member companies of the UPnP forum. The UPnP Protocol Stack The UPnP Device Architecture is specified by six chapters which describe a protocol stack shown in Figure 1. Chapter 0 concerns addressing of devices on the network. A UPnP-compliant device will attempt to lease an IP address from a DHCP server on the network. However, DHCP servers often require central management by a network administrator, which UPnP attempts to reduce. In the absence of a DHCP server, the device will pick an address from the IP range reserved for AutoIP configuration [5]. Chapter 1 describes how devices announce their presence to other devices on the network using the Simple Service Discovery Protocol (SSDP) [6]. SSDP is implemented using the multicast HTTPU and HTTPMU protocols, which are lightweight versions of HTTP for passing simple messages. Unlike traditional HTTP over TCP, HTTPU and HTTPMU have no bodies – all information is conveyed in the HTTP headers [7]. An SSDP-compatible device announces itself and its sub-devices on power-up, at regular intervals thereafter, and when a new device joins the network. SSDP allows a control point to maintain a complete list of devices available on the network.

Device manufacturer’s Device and Service Descriptions UPnP Forum Device Templates UPnP Device Architecture HTTPU GENA

HTTPMU SSDP

SSDP

UDP

SOAP

HTTP

HTTP

GENA

TCP

IP

Figure 1. The UPnP Protocol Stack, from [4]. Chapter 4 specifies how the Generic Event Notification Architecture (GENA) is used to report events on a UPnP device. The device descriptions list the device’s variables and control points may subscribe to a publication URL on the device. When the variable’s value changes, all control points that have subscribed to receive that variable’s the status are notified at the HTTP URLs they specified when subscribing [9]. Chapter 5 details how UPnP devices may provide presentation information to the control point. Device descriptions include URLs to the presentation pages, which are provided as HTML pages over HTTP. HTML is chosen for presentation as it can be rendered on devices of varying text or graphical capabilities. Future developments in the protocol are likely to include the adoption of the Web Services Description Language (WSDL) [10] instead of the current chapter 2 device description templates, and the development of more specifications for classes of devices. The current device description templates only allow for a fairly simplistic modelling of devices and sub-devices, but WSDL promises more flexible descriptions. It will also bring UPnP in line with the industry standards for web services, where WSDL is a broadly-accepted standard. IV. AV/C – AUDIO VIDEO CONTROL The 1394 Trade Association, an association of companies developing FireWire products, has published the Audio Video Control Digital Interface Command Set [11]. AV/C uses the Function Control Protocol to transport command and response packets between a device and a control point.

Chapter 2 concerns the device descriptions which UPnP devices contain. These descriptions are made available to devices and control points by HTTP over TCP. The descriptions are marked up in an XML schema and include information about the device such as its manufacturer, model number and links to the descriptions of each of its sub-devices and services.

The AV/C General specification defines a device model

Chapter 3 describes how devices are controlled with the Simple Object Access Protocol (SOAP). SOAP makes use of XML to format function calls and responses. In UPnP, SOAP envelopes are passed between control point and controlled device via HTTP. A control-point uses the POST and M-POST methods to send a function call to the device, which will return a SOAP envelope in the body of the HTTP response [8].

function block

external output plugs

subunit

function block

external input plugs

Figure 2. The AV/C model of units, subunits and function blocks, adapted from [11].

internal output plugs

internal input plugs

unit

composed of units, subunits and function blocks, represented diagrammatically in Figure 2. Each physical device is considered a unit, may have input and output plugs (which can be internal or external) and may contain a number of subunits. Each plug either sources or sinks a stream of media. An external plug on a unit is a non-1394 connection to a media stream (e.g. an RCA connector receiving an audio signal); while an internal plug on a unit is a virtual plug which sources or sinks a 1394 isochronous stream of digital media. Similarly, each subunit may have a number of plugs (all considered internal) and may contain a number of function blocks. A function block may sink a stream from one of its subunit’s input plugs, source a stream to an output plug, or process and pass a stream from an input plug to an output plug. The AV/C General standard also defines a number of command types: control, status, specific inquiry, notify and general inquiry. Commands to fetch the status of units and subunits, establish and break connections between plugs and initiate other operations are specified. A large number of sub-unit standards have been defined to describe various types of devices that can be controlled with AV/C. For example, the disc subunit specification [12] defines a conceptual model, commands and data structures for disc players of various types. There are further specifications for the different types of discs – such as CD, SACD (Super Audio CD) and DVD – which specify the details of each media type. A product available on the market is the Sony LISSA hi-fi system, which consists of CD, MiniDisc and amplifier components connected by 1394 cables. The AV/C audio subunit has been implemented in the components, and commands received from the remote control and front panels are passed between the components. Digital Harmony have created a subunit embedded in their DHIVA development system for the possibility of control over devices from a variety of manufacturers. V. UPNP AND AV/C COMPARED While the design details of the two specifications are very different, their broader implications on can be identified. Packet size AV/C commands and responses are simpler and more compact than those of UPnP. The AV/C standards define packet formats by the byte, whereas UPnP uses free text XML-formatted packets. As a consequence of this, UPnP uses HTTP to carry SOAP envelopes, which means a TCP connection must be created for each command and its response. More memory and a faster CPU are required to process the XML documents than AV/C packets. These factors means that AV/C commands are executed with far lower latency than UPnP, although the effects of Moore’s Law on embedded processors means that the latencies will improve over time. Within the Audio Engineering Society (AES), a body of professional audio engineers and equipment manufacturers, AV/C and the MIDI protocol are favoured and the latency of SOAP commands is unacceptable. SOAP control is likely to be confined to consumer products at present.

Maturity The AV/C standard has been developed further than UPnP has. A large number of subunits have been standardised by the 1394 Trade Association, including Audio, Disc, Tape and Panel subunits [13], and they have been implemented and revised. The AV/C subunit and function block standards map the functionality of each device type very closely. At present, the only device type that has a complete UPnP standard is the Internet Gateway Device. A number of standards for device types are being developed by working committees of the UPnP Forum. Different backgrounds UPnP’s development has been driven primarily by Microsoft and other computer companies. The 1394 Trade Association is dominated by consumer and audio-visual electronics companies. Even though many companies are members of both organisations, this has influenced both of the standards. For instance, UPnP often has a PC-centric view (whereas a common example of an AV/C control point is a digital TV), and UPnP presentations require an HTML renderer to be displayed. Network independence UPnP can be implemented on any network that supports IPv4, including Ethernet, HomePNA (phone line networking), Wi-Fi (wireless Ethernet) and 1394, all of which are being deployed in networked homes. The universality of the standard makes it attractive to manufacturers. In contrast, the AV/C protocol is tightly bound to the 1394 bus. The advantages of this are that it is aware of the isochronous services available only on the 1394 bus, and the automatic device identification that is performed on 1394 busses whenever a device is added or removed. Serious concerns have been raised about the bandwidth used by the SSDP device discovery algorithms employed by UPnP – a device announcing itself on the network will send a series of at least six packets and repeat them at regular intervals. 1394’s native device enumeration is quicker and has been refined by the amendments to the original standard. Internet standards UPnP is based on existing standards such as HTTP and XML. All the standards that it utilises are standards or draft standards of the IETF or W3C. Existing implementations of HTTP servers and XML parsers can be adapted for use in a UPnP-compliant device. As they are specific to 1394, AV/C protocols are unique. VI. THE NEED FOR CONCURRENT CONTROL The AV/C standard has been developed by member companies of the 1394 Trade Association since 1996. These companies have made substantial investments in AV/C compatible devices and software implementations. UPnP is a younger standard and does have disadvantages, but has attracted much attention and its universal applicability makes it compelling to manufacturers. At present, the markets for both AV/C and UPnP compatible devices are still quite young and the numbers of products available are small, so the eventual winner is far from clear.

EL/IX-compliant API [16] which implements many of the APIs which Linux provides, and uses the same GNU C compiler.

Thus it is desirable for manufacturers to produce devices that can be controlled concurrently by means of AV/C and UPnP, maintaining their investments in AV/C but looking forward to UPnP.

Implementing UPnP As an initial proof-of-concept, an HTTP server was implemented for the Digital Harmony DHIVA. This is a prototype embedded computer developed by Digital Harmony. It integrates an ARM processor, RAM and Flash memories with a three-port 1394 interface and RS-232 interfaces in a package intended for integration into electronic devices. The HTTP server was able to receive standard HTTP POST requests from a web browser and adjust settings on the AVR via the RS-232 control port.

VII. DESIGN AND IMPLEMENTATION OF A TEST DEVICE Work is in progress to allow an off-the-shelf Yamaha RX-V1000 A/V receiver to be controlled by both protocols simultaneously. While this AVR has neither an IEEE-1394 interface nor a powerful CPU, it does have an RS-232 serial port. This port was intended to allow the AVR to be controlled remotely by custom devices in a multi-room installation, and allows control of all the settings of the AVR using a set of binary command strings. This makes it suitable for the development of the prototype system shown in Figure 3.

Owing to memory limitations and a lack of multicast support in the IP stack on the DHIVA, development was switched to the Linux PC. An SSDP daemon was implemented, and the light-weight HTTP server was ported from the DHIVA to serve the device description and presentation pages. XML parsing functions from the Open Source expat XML toolkit were used to implement SOAP control and GENA event notification services.

Current development uses a PC running Linux to control the AVR, and some work has been done using an evaluation board of a small embedded computer to do the same. The PC functions as a translator between the complex network control protocols and the simple command strings that the AVR understands. The PC appears to both AV/C and UPnP control points to be an AVR device. It is envisaged that, when complete, the software developed on the PC could be ported to an embedded computer which would be integrated within the AVR. This would make the AVR fully UPnP and AV/C compatible.

Implementing AV/C At the time of writing, the AV/C controller is still in development. libraw1394 is used to handle FCP, and an audio subunit is being implemented above it.

Linux provides an ideal platform for development of this nature. The Linux 2.4 kernel includes support for IEEE-1394 PCI interfaces. For AV/C applications, the libraw1394 library provides access to the transaction layer of the FireWire protocol stack from user programs. It also provides an abstraction from the kernel interface which shields applications from changes in the kernel interface. An RFC 2734-compliant IP-over-1394 [14] IP stack is under development for Linux, which provides the foundations for the UPnP implementation. Further, Linux makes a good base for porting to embedded systems. Many modern embedded operating systems are based on Linux, or provide Unix-like C programming environments. For example, RedHat’s eCos embedded operating system [15] provides an

UPnP Control Point UDP

AV/C Control Point

TCP FCP

WDM 1394 drivers

WDM 1394 drivers

OHCI PCI 1394 interface Windows UPnP control point

OHCI PCI 1394 interface Windows AV/C control point

1394 bus

Figure 3 Components in the test system

The simplest way to share the port would be to have each process open the port and send commands as necessary, then poll for the status of the AVR while holding a mutex on the serial port. This is inefficient as each connection would

UPnP

UDP

IP-over-1394

Sharing control of the AVR For parallel control by UPnP and AV/C, both protocol implementations need to be able to send commands to the AVR and receive status notifications. But the AVR only has a single RS-232 serial port, and expects to have only one controller attached to it. Furthermore, two processes on the Linux PC are not able to access the PC’s serial port at once. Thus access to the serial port has to be shared.

AV/C

TCP

IP-over-1394

FCP

AVR abstraction/ serial port access arbitrator

AVR CPU

libraw

Linux 1394 drivers

Linux SIO drivers

OHCI PCI 1394 interface

RS232 serial port

RS232 serial port Yamaha AVR

Linux PC or embedded device

RS232 serial

send the reset command to establish synchronisation with the AVR, and there are many variables on the AVR to be read. A polled model would introduce delays in updating the status of the AVR. If a change in status were to occur, there would be a delay between the event and the controlling process learning about it, as well as a delay as a notification is transmitted across the network to the control point. These delays could result in inconsistent data being displayed by UPnP and AV/C control points. The polled model is even less attractive given that the AVR sends notification of status changes when they occur, and it needs to be borne in mind that status changes can also occur from the user adjusting settings on the front panel of the AVR.

[2]

IEEE Standard for a High Performance Serial Bus Amendment 1. IEEE Standard IEEE 1394a-2000.

[3]

IEEE Standard for a High Performance Serial Bus – High Speed Supplement. IEEE Standard IEEE 1394b-2002.

[4]

Microsoft Corporation. 2000. Universal Plug and Play Device Architecture. http://www.upnp.org/download/UPnPDA10_200006 13.htm

[5]

Cheshire, S. 2000. Dynamic Configuration of IPv4 link-local addresses. http://www.upnp.org/download/draft-ietf-zeroconfipv4-linklocal-01-Apr.txt

[6]

Goland, Y., Cai, T., et al. 2000. Simple Service Discovery Protocol/1.0. http://www.upnp.org/download/draft_cai_ssdp_v1_0 3.txt

[7]

Goland, Y. and Schlimmer, J. 2000. Multicast and Unicast UDP HTTP Messages. http://www.upnp.org/download/draft-goland-httpudp-04.txt

[8]

Box, D., Ehnebuske, D., et al. 2000. Simple Object Access Protocol (SOAP) 1.1. http://www.w3.org/TR/SOAP/

[9]

Cohen, J., Aggarwal, S. and Goland, Y. 2000. General Event Notification Architecture Base: Client to Arbiter. http://www.upnp.org/download/draftcohen-gena-client-01.txt

[10]

Christensen, E., Curbera, F., Meredith, G., and Weerawarana, S. 2001. Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl/

[11]

1394 Trade Association. 2001. AV/C Digital Interface Command Set General Specification Version 4.0. http://www.1394ta.org/Download/Technology/Specif ications/2000/AVC_General4.0Final_1.PDF

[12]

1394 Trade Association. 1999. AV/C Disc Subunit General Specification. http://www.1394ta.com/Download/Technology/Speci fications/AVC_Disc10.pdf

[13]

1394 Trade Association. 2002. Technology Specifications. http://www.1394ta.org/Technology/Specifications/sp ecifications.htm

[14]

Johansson, P. 1999. IPv4 over IEEE 1394. RFC 2734.

IX. REFERENCES

[15]

RedHat, Inc. 2002. eCos home page. http://sources.redhat.com/ecos/

IEEE Standard for a High Performance Serial Bus. IEEE Standard 1394-1995.

[16]

RedHat, Inc. 2002. EL/IX home page. http://sources.redhat.com/elix/

A second way to share control would be to implement a sharing process, which presents a simulation of the AVR’s binary command channel to each of the controlling processes while communicating with the AVR itself. Status notifications from the AVR could be repeated to both processes without the need for polling. If a command were issued by one process while a command from the other process was in progress, the sharing process could buffer until the current command was completed. An advantage of this approach is that either the AV/C or the UPnP implementation could control the AVR on its own without modification. This is the approach currently in use in this research. A third option is to implement a layer of abstraction. This could provide a higher-level interface to the AVR to the controlling processes. This layer would translate from the AVR’s native binary commands to higher-level functions. The advantage of this approach is that the AV/C and UPnP implementations could be more readily adapted to other devices, but it could require more processing. So far, the development of the AV/C and UPnP controllers has been separate, so a final decision has not been made. VIII. CONCLUSION The need for control protocols within IEEE-1394 networks in entertainment systems is clear. The details of two such protocols, UPnP and AV/C, have been examined. Device manufacturers and their customers should find the combination of UPnP and AV/C attractive. This combination is technically feasible, and three means of allowing concurrent control by multiple protocols of a single device have been discussed.

David Siebörger is reading for an M.Sc. in the Department of Computer Science at Rhodes University. Richard Foss is an Associate Professor in the Department of Computer Science at Rhodes University.

[1]