The Home Audio/Video Interoperability (HAVi) architecture is concerned with in- corporating typical home entertainment devices, such as televisions, stereos, and digital television receivers, into a home network [50]. The HAVi specification can be applied to a range of existing and emerging devices, being designed to be both future proof and incorporate legacy devices. HAVi is independent of any platform or ven- dor specific implementations, instead defining a set of Application Programmable
Interfaces (APIs) which devices may offer to other devices. Such APIs allows de- vices to interoperate with any resources available in the network, allowing late device binding (i.e. devices can use any available instance of a particular device category, rather than a specific implementation). This section will describe the descriptive and discovery approaches specified by the HAVi protocol.
3.3.1 Controllers, Devices, DCMs and FCMs
The HAVi architecture distinguishes between two main components within a Home Network, Controllers and Controlled Devices.
• A Controlled Device is a device which provides functionality, such as a Visual Display
• A Controller is an interface into a Controlled Device, for example a Control Panel on front of the Visual Display
Controllers and Controlled Devices may be part of the same logical device, or they may exist on separate devices (e.g. a Remote Control and a Television). A Controller may be responsible for one or more Controlled Devices. A Controller hosts a Device Control Module (DCM) for each Controlled Device. A DCM is a set of APIs which other devices or applications use to control the Controlled Device.
In order to be portable DCMs need to be independent of the platform of the using device or application. DCMs are generally sets of Java code complied into bytecode. The Java language is used because of its ‘Write Once, Run Anywhere’ properties. The bytecode is able to be run on any platform which contains a Java Virtual Machine (JVM).
Devices and applications download DCMs from the Controller in order to dis- cover the functions of the device. The DCM acts as a proxy between the user and the Controlled Device. DCMs may contain a standard set of functions, defined by the HAVi specification, or a mixed set of standard and specialised functions. Spe- cialised functions may be particular to a set of devices, for example vendor-specific devices, which may limit the range of users of the particular device (as users require to know the interface of the DCM in advance).
Figure 3.5: Relationship of the Device, DCM and FCM
Each DCM owns one or more Function Control Modules (FCMs), with one FCM for each function or service offered by the device. An FCM is an abstract represen- tation of a service, and is used by service users to interact with the service. As the DCM acts as a proxy to a Controlled Device, a FCM acts as a proxy to a service on that Controlled Device. The relationship between a Controlled Device, DCM and FCM is shown in Figure 3.5.
3.3.2 Device Classification
HAVi specifications contain scope for four main groups of Audio/Visual (AV) de- vices:
• Full AV devices (FAV) - These devices are rich in terms of resources and capabilities. FAV devices contain a JVM, and so can control any device which adheres to the HAVi architecture (Those which offer a DCM). FAV devices can act as co-ordinators for a HAVi network, offering the functionality of other devices to the network (through use of DCMs).
• Intermediate AV devices (IAV) - These devices do not contain a JVM, and so cannot download and utilise DCM code. IAV devices may, however, contain predefined code which allows them to use a set range of devices. IAV devices may also offer the functionality of these devices to the network
• Base AV devices (BAV) - These devices are the most basic HAVi devices available. They have no capabilities for using other HAVi devices, but still offer a DCM, which allows them to be used by FAV devices
• Legacy AV devices (LAV) - These devices are not HAVi enabled, and are largely independent from the Home Network. FAV and IAV devices may work
on behalf of LAV devices, bringing them into the HAVi network. In such cases, the HAVi component translates HAVi commands into those understood by the LAV device
3.3.3 HAVi Networks
As mention in section 3.3.2, FAV and IAV devices can offer the functionality of other BAVs and LAVs to the network. The HAVi specifications suggest that Home Networks will, in general, consist of clusters of devices, with one main device acting as co-ordinator for all other devices and services within the cluster. A cluster may represent devices in a single room, or per housing level. FAV and IAV devices act as the co-ordinator for clusters, corresponding with other co-ordinators within the network. (It should be mentioned that the HAVi architecture can also support cluster-free networks). An example cluster may be the Living Room cluster. In this cluster, the Digital Television Receiver is a FAV device, and offers its own services to the network. The co-ordinator of a cluster is responsible for providing the services within the cluster to the rest of the network. As coordinator for the Living Room, the Digital Television Receiver may also offer the services of the BAV Television and BAV stereo system to the network. The co-ordinator is responsible for managing the DCMs for all devices within its cluster. Figure 3.6 depicts a example HAVi network, containing two clusters of devices.
3.3.4 Descriptions and Discovery
Discovery with HAVi networks relies on Registry components. Each FAV or IAV device contains its own Registry, which maintains a list of services which the co- ordinating device can provide. Services within the registry may be explicitly owned by the device, or implicitly offered, on behalf of BAV or LAV devices in the cluster. In this manner, each cluster will have a registry, responsible for providing consistent and relevant information about the services within the cluster.
Each service in the cluster is represented by a Software Element within the Registry, along with a list of system attributes. A Software Element contains a
Figure 3.6: An Example HAVi Network of Clusters
well-defined interface for users to interact with the service, with the service being an implementation of that interface. The HAVi specification defines a set of sys- tem attributes which can be attached to a Software Element. Having a defined list increases the continuity between devices of differing developers and vendors. A Soft- ware Element contains a list of system attributes and a Software Element Identifier (SEID), which uniquely represents the element with the network.
Applications can query the Registry of a device to discover desired services, and then retrieve the associated DCM and FCM from the Controller. Querying requires the application to construct a template of a desired Software Element, complete with a set of required attributes. This template is then submitted to the Registry, with the SEID of any matching services being returned to the application. The application can then identify the relevant device and download the DCM from the device.
3.3.5 Communication
The main transport protocol used within HAVi networks is the IEEE 1394 interface, commonly known as FireWire. This protocol is well suited to high speed communi- cation and data transfer. Some clusters, such as those managed by IAVs, may use
specific protocols for communicating with LAV devices, which may not support the IEEE 1394 interface.
All messages sent within the HAVi network contain a SEID, which acts as an recipient address for the message. Messaging within the network is managed by one or more Message Systems, a component present on all FAV and IAV devices. A FAV or IAV therefore also acts as the message co-ordinator for the cluster it is a member of. The Message System is responsible for assigning SEIDs to software elements within its domain (cluster). This SEID is the same attribute used within the registry process.
The Message System also contains functions for removing SEIDs from the net- work (i.e. unregistering the element from the network), validating elements for trust purposes, and co-ordinating ‘call backs’, which are responses to messages from Soft- ware Elements containing any success or error messages.
3.3.6 The Suitability of HAVi
HAVi presents an interesting choice for a home network environment. Like UPnP, the HAVi architecture contains properties which can be applied to network compo- nents which are not native to the protocol [71]. FAV devices are able to act as proxies for other devices which do not offer the architecture. In this manner, HAVi clusters may be composed of many non-HAVi components with FAV devices propagating HAVi commands from the network into commands understood by a non-HAVi de- vice. While this is undoubtedly a useful and unique approach to providing a common protocol for a home network, it may be difficult to include existing home appliances to the protocol. High-speed communication is crucial for communication between multimedia devices. It would be difficult for this communication to take place be- tween HAVi and non-HAVi devices, such as between a HAVi compliant DVD player and a standard television.
Figure 3.7: An X.10 Appliance Module