The Protocol Layer

The Protocol layer of the stack (Figure 8.6) is concerned with the various protocols which may be found within the home network. The responsibilities of this layer are two-fold. Firstly, this layer allows protocol descriptions which are semantically related to those in the generic layer to be declared so. Secondly, this layer allows the description framework to capture and retain property-specific attributes about devices and services, and allow them to be stored within the description.

Protocol Descriptions

The approach of this work is based upon the assumption that the middleware frame- work managing the home network has the capability to perform cross-protocol dis- covery. As Chapter 3 has shown, many home network solutions already contain their own mechanisms for discovery, which can be utilised by middleware frame- works. Other protocols, such as X.10, require more explicit interaction with the

Figure 8.6: The Protocol Layer of the Stack

home user, but are still largely able to be included in a home network. With this assumption in mind, the protocol layer of the stack is built upon the presumption that the middleware can extract descriptions from the environment. Protocol on- tologies are responsible for capturing classes of descriptions, services and attributes which can found in their own domain.

For example, the UPnP ontology contains classifications of UPnP devices and services, while also capturing the specific attributes defined in the UPnP schema. In this manner, as attributes are parsed by the middleware framework, they can be transfered into their ontology equivalent. At this point, a protocol specific de- scription can be represented in a protocol specific ontology description. If left at this point, the description would remain understandable only to those agents who understood the particular protocol ontology. As stated, the aim of this work is to provide a single querying language for discovering network components.

To alleviate this potential issue, a protocol ontology also includes relationships between protocol specific classes and those within the generic and core layers of the ontology. For example, a UPnP Device is declared to be a subclass of Device, the concept stated within the base ontology. At this point, the usefulness of this work becomes clear.

Suppose an agent simply wanted to discover all devices within the home net- work. The agent is executing within a middleware framework, and has access to the ontology framework. The agent can simply request a list of all instances of the Device class. At this point, assuming the UPnP ontology is being used by the UPnP

Figure 8.7: Architecture of Protocol Devices

domain, all UPnP devices will be returned. For each protocol ontology (and compli- menting description translator) that exists within the network, the query will also return available devices in the instance list. The initial query makes no assumptions about what protocols the agent expects. A single reference is used, without the need to specify the inclusion of any specific protocols. This query covers all matching on- tology classes, as they all share a common root within the Device concept. Figure 8.7 illustrates this query, denoting the relationships with the ontology descriptions. If all UPnP devices are denoted as being a subclass of an UPnP Device, then logically they are all instances of a Device.

This example highlights the potential simplification of discovery when grounding protocol descriptions into abstract concepts. Protocol ontologies also relate devices and services to those described within the core layer of the stack. For example, an UPnP Speaker is a subclass of the Speaker class created within the Device ontology. A UPnP Audio Input Service is a subclass of the Audio Input Service described within the Service ontology. In this manner, if an agent wishes to discover an Audio Input Service, it will discover the UPnP service.

Figure 8.8 illustrates a similar example. Suppose an agent wished to discover available lamps within the home. On searching for instances of the class Lamp, created within the Device ontology, the agent discovers two specific instances:

Figure 8.8: Architecture of Lamp Devices

• uk.ac.cs.lsd.LightInterface - a Jini implementation of a Lamp Device.

These instances can be considered by the agent to be generic instances of a Lamp. The only restrictions on what protocols can be discovered using this generic vocabulary depends on the protocol ontologies available (and their corresponding translators). If an agent wishes to discover devices of a specific protocol, they simply need to specific the classification of the device or service using the protocol specific ontology. For example, suppose an agent could only interact with Jini driven devices. Instead of requesting instances of Lamp, and then querying the protocol of each returned instance, the agent would request instances of the Jini Lamp device. This request would return only Jini devices, ensuring the returned matches are usable.

Protocol Specific Attributes

It is not entirely impossible for a protocol to specify attributes which can find no root within the ontology stack vocabulary. The Service and Device ontologies attempt to provide a set of attributes which are common to home network protocols, without attempting to include every possibility. Rather than discard this information, proto- col ontologies are encouraged to include specific attributes. This may at first seem inefficient, as these attributes will have no generic roots, and are undiscoverable

using generic queries.

The reason for retaining them is this: once a search agent has discovered a suitable component, it is possible to determine what protocol the component is using. Principally, this information would be required to interact with the component. Suppose the protocol specific description approach contained contact information within its description framework. Without the specific attributes within the ontology description, an agent, once locating the component, would have to re-query the component using the protocol specific format. This scenario is in contrast with the aims of this work. To this end, having protocol specific attributes within a protocol ontology does not invalidate the approach, but provides robust support for the interaction part of a home network transaction.