Auto-configuring of peripheral on host/peripheral computing platform with peer networking-to-host/peripheral adapter for peer networking connectivity

Abstract

A self-installing and configuring peer networking-to-host/peripheral connectivity adapter, such as a set of software modules running on a host, operates to convert between a device control protocol with peer networking connectivity and a host/peripheral connectivity protocol for a set of host-connected peripheral devices. The adapter is automatically installed on the host upon connecting a new peripheral device, such as by a plug-and-play operating system of the host. The adapter operates as a peer-networking addressable controlled device module, which responds to communication in the device control protocol from other peer devices that are networked with the host. The adapter converts the device control protocol communications from the peer devices into a host/peripheral protocol for controlling the peripheral devices. The peripheral devices thereby are controllable as peer networking devices via the peer networking connectivity device control protocol.

Claims

I claim:

1. A distributed computing network having at least one computing device, the distributed computing network comprising:

a plurality of peer networking computing devices communicating according to a peer networking connectivity model;

at least some of said peer networking computing devices being programmed to operate as controlled devices exposing at least one operational function to control from others of said peer networking computing devices;

at least some of said peer networking computing devices being programmed to operate as user control points whereat a user interface is presented for interaction by a user to control said controlled devices; and

at least one of said peer networking computing devices being a host computing device having at least one peripheral device connected therewith according to a host-peripheral computing model, said host computing device being programmed to automatically install and configure an adapter program that operates to expose said at least one peripheral device as a controlled device in said peer networking connectivity model upon connecting said at least one peripheral device to said host computing device, wherein said adapter program acts as a peer networking addressable device to which said at least some peer networking computing devices being programmed to operate as user control points can establish a connection using an address which identifies said peer networking addressable device.

2. The distributed computing network of claim 1 wherein the adapter program operates to convert device control communications from said at least some peer networking computing devices being programmed to operate as user control points into a host/peripheral connectivity protocol for controlling said at least one peripheral device.

3. The distributed computing network of claim 2 wherein the adapter program supports discovery by said at least some peer networking computing devices being programmed to operate as user control points of operational functions of said at least one peripheral device by supplying a structured data message defining control of said operational functions in response to a request according to the peer networking connectivity model from said at least some peer networking computing devices being programmed to operate as user control points.

4. The distributed computing network of claim 3 wherein the adapter supports control of said operational functions by said at least some peer networking computing devices being programmed to operate as user control points by converting communications from said at least some peer networking computing devices being programmed to operate as user control points as defined by the structured data message into communications in a host/peripheral connectivity protocol for controlling said operational functions of said at least one peripheral device.

5. A host computing device comprising:

a processor;

a communications bus for attaching a peripheral device coupled to the processor;

a networking adapter and network operating software module for peer networking with peer devices coupled to the communications bus;

an operating software program for operating the host computing device; and

an auto-installer operating to detect attachment of the peripheral device on the communications bus and to configure the operating software program with a peripheral device driving software module and a peer networking-to-host/peripheral connectivity bridging software module specific to the peripheral device, the peripheral device driving software module controlling said new peripheral device via a host/peripheral device control protocol, the peer networking-to-host/peripheral connectivity bridging software module acting as a peer networking addressable device and converting between communications according to a peer networking connectivity-based device control protocol and communications according to the host/peripheral device control protocol for exposing the peripheral device to control from the peer devices using the peer networking connectivity-based device control protocol.

6. The host computing device of claim 5 wherein said bridging software module further converts between communications according to said protocols for also supporting control by the peripheral device of the peer devices using the peer networking connectivity-based device control protocol.

7. A computer-readable data-carrying medium having a host operating software program encoded thereon and executable on a host computing device in a distributed network of peer computing devices, the host computing device having a communications bus for connecting peripheral devices with host/peripheral connectivity, the host operating software program comprising:

a new peripheral detection module operating to detect that a new peripheral is attached to the host computing device on the communications bus;

a peer networking-to-peripheral bridging module installer operating upon detection of the new peripheral to install an instance of a peer networking-to-peripheral bridging module on the host computing device, the peer networking-to-peripheral bridging module acting as a peer networking addressable device and operating to bridge between a first device control protocol using peer networking connectivity and a second device control protocol using host/peripheral connectivity, the first device control protocol defining communications between user control point nodes and controlled device nodes on the distributed network of computing devices permitting control of operational functions and services of the controlled device nodes from the user control point nodes, the second device control protocol defining peripheral-driving communications between the host computing device and the new peripheral on the communications bus.

8. The computer-readable data-carrying medium of claim 7 further comprising a peripheral driving software module installer also operating upon detection of the new peripheral to install a peripheral driving software module specific to the new peripheral for communicating in the second device control protocol with the new peripheral.

9. On a host of a host/peripheral computing platform, a method of self-configuring an operating software program of the host to provide peer networking connectivity for peripheral devices connected to the host on a peripheral expansion bus, the method comprising:

detecting that a new peripheral is connected to the host;

installing a device driver module specific to the new peripheral onto the host for communicating with the new peripheral according to a host/peripheral connectivity control protocol;

installing a peer networking addressable connectivity adapter onto the host to act as a controlled device module according to a peer networking device control model in which peer networking connected computing devices run user control point modules and controlled device modules, where the user control point modules support user interaction to control operational functions supported by the controlled device modules, and for converting communications from peer networking computing devices networked with the host computer and the controlled device module to communications with the new peripheral via the device driver module.

Description

TECHNICAL FIELD

This invention relates generally to dynamic connectivity among distributed devices and services, and more particularly relates to adapting host-peripheral connectivity devices and services for access in a peer networking connectivity model, such as in a pervasive computing environment.

BACKGROUND AND SUMMARY

The cost of computing and networking technologies have fallen to the point where computing and networking capabilities can be built into the design of many electronic devices in the home, the office and public places. The combination of inexpensive and reliable shared networking media with a new class of small computing devices has created an opportunity for new functionality based mainly on the connectivity among these devices. This connectivity can be used to remotely control devices, to move digital data in the form of audio, video and still images between devices, to share information among devices and with the unconstrained World Wide Web of the Internet (hereafter "Web") and to exchange structured and secure digital data to support things like electronic commerce. The connectivity also enables many new applications for computing devices, such as proximity-based usage scenarios where devices interact based at least in part on geographical or other notions of proximity. A prevalent feature of these connectivity scenarios is to provide remote access and control of connected devices and services from another device with user interface capabilities (e.g., a universal remote controller, handheld computer or digital assistant, cell phones, and the like). These developments are occurring at the same time as more people are becoming connected to the Internet and as connectivity solutions are falling in price and increasing in speed. These trends are leading towards a world of ubiquitous and pervasive networked computing, where all types of devices are able to effortlessly and seamlessly interconnect and interact.

In the above ubiquitous and pervasive networked computing scenarios, the devices desirably can interoperate on an ad hoc peer-to-peer networking connectivity basis. Such a peer networking connectivity model enables any networked device to initiate a communication with any other networked device, without having established a prior relationship or maintaining a persistent relationship between the devices. This peer networking connectivity also allows multiple devices to establish one or more connections with a single device, and it allows for a device to be capable of both initiating and accepting connections to/from other devices.

The prevalent model for device connectivity, however, has been that of host-peripheral connectivity, typified by the personal computer and its many peripheral devices (e.g., data storage drives, user input devices, displays, printers, scanners, etc.) connected via various buses (e.g., PCI, VESA, AGP, Microchannel, ISA, EISA, USB), ports (e.g., serial, parallel), and connectors (e.g., PS/2 connector). This host-peripheral connectivity model is characterized in that the host and peripherals typically have persistent relationships and stable configurations. This persistent relationship is created, by example, through a set-up and configuration process through which appropriate driver software is installed onto the host for use in controlling the peripheral, and updating the host's configuration to include peripheral device settings. Such persistent configured relationships with a user installation/configuration experience are generally inappropriate to the ubiquitous and pervasive computing environment where portable and mobile devices desirably can instantly connect and interact with other computing devices in their environment without having established prior or persistent relationships.

Nevertheless, given the large number of legacy devices that exist in host-peripheral connectivity models, the devices capable of peer networking connectivity in a ubiquitous and pervasive computing environment will desirably also be able to interact on the same peer networking connectivity basis with such legacy peripheral devices. However, these legacy peripheral devices are designed and equipped only to connect with a host on a host-peripheral connectivity basis, and lack the necessary support (e.g., networking hardware and software) for peer networking connectivity.

In accordance with a technology described herein, peripheral devices connected with a host via host/peripheral connectivity are exposed in a device control model as peer devices having peer networking connectivity. A peer networking-to-host/peripheral connectivity adapter, which may be implemented as a set of software modules running on a host, operates to convert between a device control protocol with peer networking connectivity and a host/peripheral connectivity protocol (or protocols) for a set of host-connected peripheral devices. The adapter, in effect, operates virtually as a set of controlled devices in the device control protocol, which respond to communication in the device control protocol from other peer devices that are networked with the host. The adapter converts the device control protocol communications from the peer devices into the peripheral devices' respective host/peripheral protocol for controlling the peripheral devices. The adapter also converts communications in the respective host-peripheral protocol from the peripheral devices into the device control protocol with peer networking connectivity. Accordingly, the peer networking-to-host/peripheral connectivity adapter exposes the operational functionality of the peripheral devices to use from other peer networking devices via the device control protocol. Alternatively, the adapter also may operate for peripheral devices that provide a user interface as a user control point that converts communications from the devices in the respective host/peripheral protocol into the device control protocol with peer networking connectivity to control other peer networking connectivity devices.

In an implementation described herein, the peer networking-to-host/peripheral adapter acts as an addressable device having the operational functions and services of a corresponding peripheral device. The adapter is addressable to establish a connection via a peer networking connectivity, device control protocol by other peer devices that are networked with the adapter. The adapter further supports discovery of the addressable device's operational functions by the other peer devices using the device control protocol, through the exchange of structured data messages (e.g., XML format data). The adapter also supports control of the addressable device's operational functions by the other peer devices, again through structured data messages according to the device control protocol. The adapter provides the controlled operational functions by converting the device control protocol messages into communications with the corresponding peripheral device in a host/peripheral connectivity protocol.

According to a further aspect of the invention, the adapter is automatically installed and configured for a peripheral device by host operating software along with device-specific driver software upon connecting or "plugging" the peripheral device into the host, for example, as part of a "plug-and-play" peripheral device installation sequence. At the time of connecting the peripheral device into the host or during a boot-up sequence of the host operating software, the host operating software detects that a new peripheral device has been connected; and automatically selects or prompts the user to select and then installs an appropriate device driver for the new peripheral device. The host operating software also automatically installs a peer networking-to-host/peripheral adapter, which exposes the peripheral to control from peer networking devices that are networked to the host and optionally permits control of peer networking devices from the peripheral.

Additional features and advantages will be made apparent from the following detailed description of the illustrated embodiment which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 are block diagrams of a device architecture per Universal Plug and Play using user control points, controlled devices and bridges for connectivity between devices.

FIG. 3 is a block diagram of a device model per Universal Plug and Play.

FIG. 4 is a block diagram illustrating example devices conforming to the device model of FIG. 3.

FIG. 5 is a block diagram illustrating device state synchronization using a state table and eventing.

FIG. 6 is a block diagram illustrating device addressing.

FIG. 7 is a block diagram of a programmatic interface-to-network messaging adapter or Rehydrator in the device control model of FIG. 3.

FIG. 8 is a general data flow diagram of the Rehydrator of FIG. 7 in the device control model of FIG. 3.

FIG. 9 is a block diagram of an implementation design of the Rehydrator of FIG. 7.

FIGS. 10 and 11 are block diagrams illustrating an internal software architecture of the user control point and controlled device in the device control model of FIG. 3.

FIG. 12 is a block diagram illustrating an internal software architecture of a combined bridge and user control point in the device control model of FIG. 3.

FIG. 13 is a data flow diagram illustrating a typical browsing protocol sequence in the device control model of FIG. 3.

FIG. 14 is a listing showing a layout of a description document in the device control model of FIG. 3.

FIG. 15 is a listing of an exemplary icon list of a Description Document in the device control model of FIG. 3.

FIG. 16 is a listing of an exemplary service control protocol declaration in a Description Document in the device control model of FIG. 3.

FIGS. 17 and 18 are a listing of an XML schema for a Service Control Protocol Declaration Language used in the device control model of FIG. 3.

FIG. 19 is a block diagram of an eventing model used in the device control model of FIG. 3.

FIG. 20 is a data flow diagram illustrating subscription, notification and unsubscription in the eventing model of FIG. 19.

FIG. 21 is a block diagram of a computer system that may be used in the device control model of FIG. 3.

FIG. 22 is a block diagram of a device having embedded computing and networking capability per universal-plug-and-play (UPnP) standards that may be used in combination with the computer system of FIG. 21 in the device control model of FIG. 3.

FIG. 23 is a block diagram of a software architecture per UPnP standards in the embedded computing device of FIG. 22

FIG. 24 is a data flow diagram of a process for automatic network introduction of the embedded computing device of FIG. 22 into an ad hoc computer network environment per the UPnP protocol.

FIG. 25 is a data flow diagram of a process for automatic network introduction of the embedded computing device of FIG. 22 into a configured computer network environment per the UPnP protocol.

FIG. 26 is a block diagram of a software architecture of a client device per UPnP standards having embedded computing and networking capability that may be used in the device control model of FIG. 3.

FIG. 27 is a block diagram of an exemplary home or office pervasive computing environment having a variety of computers as per FIG. 21 and embedded computing devices as per FIG. 22 interconnected per UPnP standards that may be used in the device control model of FIG. 3.

FIGS. 28 through 40 are program listings of interfaces used in the Rehydrator implementation design of FIG. 9.

FIG. 41 is a flow diagram illustrating automatically installing and configuring a UPnP bridge upon attaching or connecting a peripheral on a host personal computer.

DETAILED DESCRIPTION

The following detailed description is directed toward automatically installing or configuring an adapter for adapting devices operating under a host-peripheral connectivity model for operation within a distributed device control model having peer networking connectivity, upon attaching to the host. In one described implementation, this host/peripheral-to-peer networking connectivity adapter (called a "UPnP bridge" in the described implementation) is used in a device architecture 100 (FIG. 1), connectivity model, and device control protocol proposed by Microsoft Corporation, called Universal Plug and Play ("UPnP").

Universal Plug and Play

Universal Plug and Play (UPnP) is an open network architecture that is designed to enable simple, ad hoc communication among distributed devices and services from many vendors. UPnP leverages Internet technology and can be thought of as an extension of the Web model of mobile Web browsers talking to fixed Web servers to the world of peer-to-peer connectivity among mobile and fixed devices. UPnP embraces the zero configuration mantra of Plug and Play (PnP) but is not a simple extension of the PnP host/peripheral model.

The cost, size and battery consumption of computing technology--including processing, storage and displays--continues to fall. This trend is enabling the evolution of stand-alone, single or limited function computing devices such as digital cameras, audio playback devices, smart mobile phones and handheld computers. Concurrent with this, the economical storage and transmission of digital audio,.video and still images is enabling highly flexible models for managing entertainment content.

While many of these devices are capable of useful stand-alone operation, seamless connectivity with the PC can enhance the value to the customer of both stand-alone devices and the PC. Good examples of this synergy are digital image capture combined with PC image manipulation, storage and email transfer/Web publishing and information synchronization between a PC and a handheld computer or smart mobile phone.

Since many of these devices, and the PC itself, are mobile, a suitable communication architecture must enable a highly dynamic connectivity model and must enable peer-to-peer interoperability among arbitrary combinations of devices.

The Internet has created a widespread awareness of the value of simple, universal communication that is independent of the underlying transmission technology and independent of technology from any single vendor.

UPnP makes it possible to initiate and control the transfer of bulk data (e.g. files) or A/V data streams from any device on the network, to any device on the network, under the control of any device on the network. UPnP enables the ad hoc addition or removal of devices on the network, and it enables multiple controlling devices to remain in sync with each other.

UPnP reuses existing protocols and technology whenever possible. The transition to this highly connected (and connectable) world will not occur overnight. UPnP builds on existing Internet protocols, but accommodates devices that cannot run the complete UPnP protocol suite. UPnP provides an architecture that enables legacy devices to communicate with UPnP devices.

IP internetworking has been chosen as a UPnP baseline due to its proven ability to span different physical media, to enable real world multiple vendor interoperation and to achieve synergy with the Internet and home and office intranets. Internet synergy enables applications such as IP telephony, multiple player games, remote control of home automation and security, Internet based electronic commerce, in addition to simple email and Web browsing. UPnP's scope includes remote control of devices and bulk data transfer, and can be easily extended to specify A/V streaming.

UPnP's media independence enables a great deal of flexibility in the packaging of products. UPnP enables an A/V system to be controlled through an A/C power communications technology, while the transmission of A/V streams among the components is analog or digital. One of the controllers of this system could be on the television, while another is on a PC, and yet another connected via radio or infrared.

Unlike Plug and Play, Universal Plug and Play is built on top of networking and enables ad hoc peer-to-peer connectivity. Networking, in this context, describes a style of connectivity that enables any networked device to initiate a communication with any other networked device, without having established a prior relationship or maintaining a persistent relationship between the devices. Networking also allows multiple devices to establish one or more connections with a single device, and it allows for a device to be capable of both initiating and accepting connections to/from other devices. The PnP, or host/peripheral, model is suitable whenever there is a natural persistent relationship between two devices (e.g. a keyboard, mouse and display maintain a persistent relationship with a host computer). Even though networking does not mandate low level persistent relationships, it provides the needed anchors (addresses) for applications to choose to maintain associations as a convenience for the customer (e.g. remembering commonly used networked printers).

In order to achieve multiple vendor peer-to-peer interoperation among devices, vendors desirably agree on common technology and standards up to the highest level of desired functional interoperation.

UPnP leverages formal protocol contracts to enable peer-to-peer interoperation. Protocols contracts enable real-world multiple-vendor interoperation.

UPnP enables devices to expose a user interface by leveraging browser technology. In this context, the browser can be considered to be a very rich remote terminal. Current browser technology does not maintain a separation of presentation from data, or in the case of devices, control. It is possible to hunt through a page of HTML to extract data values, but it is not convenient or robust. UPnP leverages the separation of presentation and data enabled by the use of XML, and it extends this technology to the device control domain.

UPnP provides a device-driven auto-configuration capability that preserves the experience that customers have on the Web. Today, it is possible to navigate around the Web without loading programs beyond the browser itself. Since UPnP enables the browser to be extended to control devices, and because UPnP devices are controlled with explicit protocols, the browser must somehow learn how to talk to UPnP devices. This learning process is driven entirely from the device itself and is accomplishing entirely by uploading an XML document that describes the capabilities of the device. The architectural component that enables device-driven auto-configuration is called the Rehydrator. The job of the Rehydrator is to convert between APIs and protocols.

Since the auto-configuration process itself is driven only by the exchange of formatted data, there is very little opportunity for a malicious attack from a hostile piece of code.

There are some scenarios where the Web UI model is not sufficient for a rich customer experience. It would not be convenient to have to a separate Web UI for each light switch in a house. To support a rich user interface and to enable the aggregation of devices into a single UI, UPnP enables application control in addition to browser control of devices. This is achieved simply by enabling applications to call the same Rehydrator APIs that the browser does. Applications can also directly generate and consume the raw UPnP control protocols, provided they are not interested in the device-driven auto-configuration enabled by the Rehydrator.

UPnP assumes that there will be more than one device with UI that wants to control other devices in any given network, and it provides a simple mechanism that enables these control points to remain in sync. This mechanism can easily support device front panels and wireless remotes that do not run UPnP protocols. The UPnP control model is third-party control; any device can transfer bulk data (e.g. files) or A/V data streams from any device on the network, to any device on the network, under the control of any device on the network.

Terminology

The detailed description that follows uses the terminology defined below.

Module. A component of a device, software program, or system that implements some "functionality", which can be embodied as software, hardware, firmware, electronic circuitry, or etc.

User Control Point. The set of modules that enable communication with a UPnP Controlled Device. User Control Points initiate discovery and communication with Controlled Devices, and receive Events from Controlled Devices. User Control Points are typically implemented on devices that have a user interface. This user interface is used to interact with Controlled Devices over the network. The modules minimally include a Discovery Client, a Description Client, a Rehydrator, an Event Subscription Client and an Event Sink. User Control Points may also include Visual Navigation, a Web browser and an application execution environment. User Control Points can add value to the network by aggregating the control of multiple Controlled Devices (the universal remote) or they can implement a function as simple as initiating the transfer of data to or from a Controlled Device. Examples of devices that could be User Control Points are the personal computer (PC), digital television (DTV), set-top box (STB), handheld computer and smart mobile phone, and the like. Nothing prevents a single device from implementing the functionality of a User Control Point and one or more Controlled Devices at the same time.

Controlled Device. The set of modules that perform certain tasks (e.g., printing) and communicate with a User Control Point. Controlled Devices respond to discovery requests, accept incoming communications from User Control Points and may send Events to User Control Points. Devices that support Controlled Device functionality may also support local user interfaces such as front panel displays or wireless remotes. The modules minimally include a Discovery Server, a Description Server, a Control Server, an Event Subscription Server and an Event Source. Controlled Devices may also include a Presentation (e.g., Web) Server. Examples of devices that could be Controlled Devices are the VCR, DVD player or recorder, heating/ventilation/air-conditioning equipment (HVAC), lighting controller, audio/video/imaging playback device, handheld computer, smart mobile phone and the PC, and the like. Nothing prevents a single device from implementing the functionality of a User Control Point and one or more Controlled Devices at the same time.

Bridge. A set of modules that enables Bridged and Legacy Devices to interact with native UPnP devices. The bridge itself exposes a collection of UPnP Controlled Devices to User Control Points. The Bridge maps between native UPnP Device Control Protocols and the underlying protocols or other control methods exposed by the Bridged and Legacy Devices. Optionally, such a device could expose UPnP Controlled Devices to Legacy Devices in the manner required by the Legacy Devices. Nothing prevents a single device from implementing the functionality of a User Control Point, one or more Controlled Devices and a Bridge at the same time.

Service Provider. A module used by a UPnP Bridge that translates between UPnP protocols and the protocols used by Bridged and Legacy Devices. No Service Providers are required for communication among native UPnP devices.

Bridged Device. A device that cannot participate in UPnP at the native protocol level, either because the device does not have sufficient resources or because the underlying media is unsuitable to run TCP and HTTP. Examples of devices that could be Bridged Devices are power line-controlled A/V equipment, light switches, thermostats, wristwatches and inexpensive toys. Bridged Devices are UPnP complaint and are exposed to other UPnP devices through a UPnP Bridge.

Legacy Device. Any non-UPnP compliant device that must be exposed to other UPnP devices through a UPnP Bridge.

Device Model. The UPnP model of Controlled Devices. The Device Model includes the addressing schemes, Description Document, Devices and Services hierarchy and the functional description of Services.

Device Control Protocol (DCP). A complete set of UPnP protocols and schemas used to interact with a UPnP Controlled Device.

Device Definition. The formal definition of a Device Type. A Device Definition includes a Device Type Identifier, the fixed elements in the Description Document, the required set of Service Definitions in the Root Device, and the hierarchy of required Devices and Service Definitions.

Service Definition. The formal definition of a Service Type. A Service Definition includes a Service Type Identifier, definition of the Service State Table (SST), definition of the Service Command Set, the Service Control Protocol (SCP) and Service Control Protocol Declaration (SCPD).

Device. In the context of the Device Model, a container for Services. A Device generally models a physical entity such as a VCR, but can also represent a logical entity. A PC emulating the traditional functions of a VCR would be an example of a logical device. Devices can contain other Devices. An example would be a TV/VCR packaged into a single physical unit. UPnP enables the association of user interface (display icon and root Web page) with every Device, including Root Device.

Root Device. The topmost Device in a hierarchy of nested Devices. A Device with no nested Devices is always a Root Device.

Device Type. A relatively high level classification of Devices with common functionality. Device Type is intended to enable Devices to be simply and automatically grouped for search and/or presentation. An example of a Device Type is "VCR". Device Types are formally defined in terms of a required set of Service Definitions of minimum version that a compliant Device must support. UPnP supports searches for all Devices of a specified Device Type.

Device Type Identifier. A unique identifier that identifies a Device Definition. This identifier adheres to the format of a Uniform Resource Identifier (URI). See, T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", which can be found at http://www.ietf.org/rfc/rfc2396.txt.

Device Friendly Name. A human readable string that is usually initialized by vendors at the time of manufacturer of a Device. Every Device, including Root Devices, has a Device Friendly Name. A typical Device Friendly Name will contain manufacturer and model information, and especially when interpreted by humans, can be used to enable a more precise identification of a UPnP Device from the set of discovered Devices. Once identified, the Unique Device Name (UDN) can be used to unambiguously identify the same Device in the future. UPnP enables Device Friendly Names to be changed by User Control Points. The Device Friendly Name should not be used as device identifier.

Unique Device Name (UDN). The fundamental identifier of a Device. Every Device, including Root Devices, has exactly one UDN. The UDN is globally unique and permanent, even across power cycles and physical location changes. The UDN is the only UPnP device identifier guaranteed never to change. UPnP enables searches for devices by UDN.

Description Document. A structured unit of data that is used by a User Control Point or UPnP Bridge to learn the capabilities of a Controlled Device. Description Documents are retrieved from the Description Server on a UPnP Controlled Device. There is one Description Document for every Root Device that describes the Root Device and all non-Root Devices. Description Documents adhere to XML grammar. To support localization, multiple Description Documents can exist. A User Control Point requests the preferred localized Description Document by using the standard HTTP "accept-language" header.

Service. The fundamental UPnP controllable entity (but not the finest level of control). An example of a Service is "Clock". Services are defined with a mandatory common base set of functionality. Vendors can extend the base set with proprietary extensions provided the base functionality is implemented. Service Definitions are versioned and later versions are constrained to be supersets of previous versions. UPnP enables searches for all Devices that contain a specified Service of a minimum version. This search would find all clocks, regardless of their packaging. A search for Device Type "Clock" would be used to find only stand-alone clocks.

Service Type. A classification of Services by their function.

Service Type Identifier. A unique identifier that identifies a Service Definition. This identifier adheres to the format of a Uniform Resource Identifier (URI). See, T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", which can be found at http://www.ietf.org/rfc/rfc2396.txt.

Service State Table (SST). A logical table consisting of rows of [Variable, Type, Legal Values, Default Value, Current Value] that represents the current electrical, mechanical and/or logical state of a Service. SST instances are stored on the Controlled Device itself and are the ultimate authority of the state of the Service. All local user interface, such as front panels or wireless remotes are required to update the SST on UPnP compliant devices.

SST Definition

Service Command Set. A set of Commands that can be invoked on a Service. Commands generally result in changes in the Current Value field of one or more rows of a SST. Commands are logically represented in the format Command (Variable=New Value, Variable=New Value, . . . ). Services must accept or reject the complete set of changes to a SST. There is a mandatory standard Query Command that is used to retrieve the Current Value of any row of a SST.

Service Command Set Definition

Service Control Protocol (SCP). The protocol used to invoke Commands against a Service and to return results. There is exactly one SCP per Service Definition. SCPs adhere to the grammar of SCP XML schema. SCPs can be generated by an automated tool that accepts a SST Definition and a Command Set Definition as input.

Service Control Protocol Declaration (SCPD). A formal representation of the schema of a Service. The SCPD declares the rows of a Service's SST and the associated Command Set. SCPDs are uploaded from Controlling Devices in their Description Documents and enable User Control Points or Bridges to invoke Commands on the Service without any prior or persistent knowledge of the capabilities (or schema) of the Service. There is exactly one SCPD per Service Definition. SCPDs adhere to XML grammar. SCPDs can be generated by an automated tool that accepts a SST Definition and a Command Set Definition as input.

Event. An unsolicited message generated by a Controlled Device and delivered to one or more User Control Points. Events are used to maintain a consistent view of the state of Service across all interested User Control Points. UPnP leverages the GENA event architecture (see "Generic Event Notification") to transport event messages. All events are delivered using TCP/IP for reliability.

Generic Event Notification Architecture (GENA). An event transport protocol. GENA leverages TCP/HTTP as a transport. GENA has been submitted as an Internet Draft to the IETF. See, J. Cohen, S. Aggarwal, Y. Goland, "General Event Notification Architecture Base: Client to Arbiter", which can be found at http://www.ietf.org/internet-drafts/draft-cohen-gena-client-00.txt.

Simple Service Discovery Protocol (SSDP). A simple network device discovery protocol. UPnP uses SSDP to allow User Control Points to find Controlled Devices and Services. SSDP operates in a default, completely automatic multicast UDP/IP based mode in addition to a server-based mode that uses TCP/IP for registrations and query. Transitions between the default dynamic mode and server-based mode are automatic and transparent to upper level software. SSDP enables every Controlled Device to control the lifetime that its Description URL is cached in all User Control Points. This enables a Controlled Device to remain visible to User Control Points for a relatively long time (through power cycles), in addition to enabling a Controlled Device to appear and disappear very quickly, all under the control of the Controlled Device. SSDP and related Multicast and Unicast UDP HTTP Messages specifications have been submitted as Internet Drafts to the IETF. See, Y. Goland, "Multicast and Unicast UDP HTTP Messages", which can be found at http://www.ietf.org/internet-drafts/draft-goland-http-udp-00.txt; and Y. Goland, T. Cai, P. Leach., Y. Gu, S. Albright, "Simple Service Discovery Protocol/1.0", which can be found at http://www.ietf.org/internet-drafts/draft-cai-ssdp-v1-02.txt.

Client. In the context of UPnP, Client refers to a module that initiates a TCP/HTTP connection to a peer HTTP server.

Server. In the context of UPnP, Server refers to an HTTP server. This is a module that accepts incoming TCP/HTTP connections and either returns a Web page or forwards the payload data to another module. Client and Server describe only the direction of initiation of TCP/HTTP connections. There is no relationship between the low level concepts of Client and Server and the high level concepts of User Control Point and Controlled Devices. Logically, User Control Points always discover and initiate communication with Controlled Devices, but this communication requires Client and Server functionality on both sides.

Hostname. A Hostname is the Domain Name System (DNS) or NetBIOS Name Service (NBNS) that, when resolved to an IP address, represents a network interface that can be used to establish TCP/IP level connectivity to User Control Points, Controlled Devices or Bridges. Hostnames can be used to provide persistent network level addressing on a network where IP addresses are dynamically assigned and of unknown lifespan or to integrate with an existing managed network. UPnP provides an algorithm for seeding a device's hostname from its UDN at manufacturing time.

Uniform Resource Locator (URL). A format for expressing Web addresses. URLs minimally contain an identification of the protocol family that the URL is valid for, a Hostname, and a path. UPnP uses URLs as addresses whenever the module accepting the incoming connection is an HTTP server.

Description URL. The URL returned from a Controlled Device or Bridge in response to any UPnP SSDP query. This URL always points to a Description Server on the Controlled Device. An HTTP GET can be issued on this URL to retrieve the Description Document. This URL is valid as an address for the lifetime of the Hostname embedded in the URL.

Discovery Server. The module that runs in a Controlled Device or Bridge that responds to SSDP queries. This Server is unique in that it must support UDP/HTTP in addition to TCP/HTTP.

Discovery Client. The module that runs in a User Control Point that initiates SSDP queries.

Description Server. The module that runs in a Controlled Device or Bridge that responds to HTTP GETs and returns Description Documents. This service consists of a TCP/HTTP server than can retrieve and return a Description Document from persistent storage (like a filesystem).

Visual Navigation. User Control Point functionality that displays the icons of discovered Devices and enables the transfer of control to a browser or application to interact with the Controlled Device. In Windows, Visual Navigation could be implemented as a folder of icons.

Presentation URL. A URL that can be used by a User Control Point to navigate to the Presentation Server of a Controlled Device. This URL is returned in the Description Document and is valid as an address for the lifetime of the Hostname embedded in the URL. All Devices, including non-Root Devices, can have an associated Presentation URL.

Presentation Server. A Web Server in most common cases. The module that runs in a Controlled Device that responds to HTTP GETs or Presentation URLs and returns user interface using Web technologies (JavaScript, Jscript.RTM., ECMAScript, VBScript, ActiveX.RTM., Java Applet, etc.).

Browser. A Presentation Client. A Web browser extended with a Rehydrator.

Control URL. A URL that can be used by a User Control Point to navigate to the Control Server of a Controlled Device or Bridge. This URL is returned in the Description Document and is valid as an address for the lifetime of the Hostname embedded in the URL. All Services have an associated Control URL.

Control Server. The module that runs in a Controlled Device or Bridge that responds to Commands invoked on a Service by a User Control Point. Commands are encoded and sent using the SCP specified in the Service Definition. This service consists of a TCP/HTTP server that passes control to the native control logic of a Service, updates the SST and generates an event if the SST changes.

Rehydrator. In UPnP, a Control Client. A User Control Point module that translates between native operating system APIs and SCPs and events. The Rehydrator uploads SCPDs from Controlled Devices and Bridges and generates appropriate SCPs in response to application API requests to invoke Commands.

Event Subscription URL. A URL that can be used by a User Control Point to navigate to the Event Subscription Server of a Controlled Device or Bridge. This URL is returned in the Description Document and is valid as an address for the lifetime of the Hostname embedded in the URL. All Services have an associated Event Subscription URL.

Event Subscription Server. The module that runs in a Controlled Device or Bridge that responds to GENA SUBSCRIBE requests from User Control Points. A SUBSCRIBE informs the Controlled Device or Bridge of the User Control Point's desire to receive future events. This service consists of a TCP/HTTP server that adds the User Control Point's Event Sink URL to the list of destinations to be NOTIFY'd whenever the SST associated with the Service changes.

Event Subscription Client. The module that runs in a User Control Point that sends GENA SUBSCIBE messages to the Event Subscription Server.

Event Sink URL. A URL, supplied by a User Control Point, that is used as an address to send event NOTIFYs to. This URL is valid as an address for the lifetime of the Hostname embedded in the URL. There is no explicit relationship between Event Sink URLs and Subscription Identifiers.

Subscription Identifier (SID). A header in the GENA NOTIFY message that identifies the source of an event. In UPnP, the SID can be considered as an alias for the Event Source instance.

Event Sink. The module that runs in a User Control Point that accepts incoming GENA event NOTIFYs. This service consists of a TCP/HTTP server that passes the event information to interested applications running on the User Control Point.

Event Source. The module that runs in a Controlled Device or Bridge that sends GENA NOTIFYs to the Event Sink Servers of SUBSCRIBES User Control Points.

Domain Name System (DNS). A distributed system of servers that locates the IP addresses of other computers on a network based on their hierarchical names.

NetBIOS Name Server (NBNS). A server that locates the IP addresses of other computers on a network based on their flat NetBIOS computer names.

Multicast DNS (MDNS). A peer-to-peer translation scheme that does not require involvement of DNS servers.

UPnP Technologies Overview

An overview of technologies utilized in UPnP follows.

Device Discovery: Simple Service Discovery Protocol (SSDP)

TCP/IP provides the ability to initiate a connection with a specified application running on a specific device, provided both the network address of the device (IP address) and the application address (port) are known. Generally, application addresses (ports) are standardized and widely known, but the problem of learning the IP address of a device remains.

Simple Service Discovery Protocol (SSDP) is a protocol that enables devices to learn of the existence of potential peer devices and the required information (an IP address) needed to establish TCP/IP connections to them. The successful result of an SSDP search is a Uniform Resource Locator (URL). The Hostname embedded in the URL can be resolved to an IP address that can be used to make a connection to the discovered device. The name to address resolution is outside of the functionality of SSDP.

SSDP specifies a default, completely automatic, best-effort multicast UDP-based operating mode, in addition to a server mode that uses TCP for registration and query. Fall-forward to server mode and fallback to the default dynamic mode can occur automatically and transparently as a server is added or removed from a network. Server mode can be used to reduce network traffic, to implement searches based on location or policy and to integrate with a directory system.

SSDP requires that all devices specify a maximum lifetime that SSDP level knowledge of the device will remain cached in other network devices. If a device does not refresh the cache of other network devices before this interval expires, the device will be assumed to have disappeared from the network. This interval can be chosen to be larger than a typical power down cycle to enable device visibility to persist for a relatively long time, or a smaller interval can be chosen to enable more dynamic visibility control. In all cases, devices that are abruptly removed from the network will eventually disappear from all networked devices.

In response to an SSDP search, UPnP devices return a Description URL in the SSDP Location and optionally the Alternate Location (AL) SSDP headers.

An example location header is a follows:

Location: http://device.local/description/path/description.xml

In this example, the device.local is the Hostname of the Controlled Device, and the "description/path/description.xml" element of the URL is the path and name of the Description Document on the device.

Eventing: Generic Eventing Notification (GENA)

Eventing, in the context of UPnP, is the ability for a device to initiate a connection at any time to one or more devices that have expressed a desire to receive events from the source device. Events are used to enable synchronization among multiple devices organized into a many to one relationship. UPnP events are mainly used for asynchronous notifications of state changes.

TCP/IP provides the fundamental support for the connections that carry event information reliably. Generic Event Notification (GENA) adds conventions for establishing relationships between interested devices and an addressing scheme to enable the unambiguous delivery of events. GENA leverages HTTP addressing and encapsulation.

User Control Points, Controlled Devices and Bridges

With reference now to FIGS. 1 and 2, UPnP is an application-level distributed network architecture where the logical nodes on the network are User Control Points 104-105, Controlled Devices 106-107 and Bridges 120. These classifications refer to functionality rather than physical entities. The functionality of UPnP User Control Points 104-105, Controlled Devices 106-107 and Bridges 120 can be packaged into physical entities (e.g., multiple function devices 102-103) in any combination.

The primary distinction between a User Control Point 104-105 and a Controlled Device 106-107 is that the User Control Point is always the communication initiator. After the initial communication, User Control Points-can receive events from Controlled Devices.

Controlled Devices 106-107 are responsible for storing and updating the state of Services. User Control Points are required to synchronize to the state on Controlled Devices and to share state directly among themselves.

User Control Points typically have user interface that is used to access one or more Controlled Devices on the network. Controlled Devices typically only have local user interfaces.

Bridges 120 (FIG. 2) expose devices that do not expose native UPnP protocols as native UPnP Controlled Devices. The Bridge itself looks to other UPnP User Control Points like a set of Controlled Devices.

The following table lists the modules in the User Control Points 104-105 and Controlled Devices 106-107, along with their functions.

          User Control Point            Controlled Device
    Function        Module          Function        Module
    Initiate discovery Discovery Client Respond to      Discovery
    of Controlled                   discovery       Server
    Devices.                        requests.
    Retrieve        Description Client Provide         Description
    Description                     Description     Server
    Documents.                      Documents.
    Display a folder Visual Navigation
    of icons per
    discovered
    Device and allow
    transfer of
    control to a
    selected device.
    View user       Web Browser     Provide user    Presentation
    interface exposed                 inteface for    (Web) Server
    by a Controlled                 remote User
    Device.                         Control Points.
    Execute         Application
    applications.   Execution
                    Environment
    Invoke          Rehydrator      Accept incoming Control Server
    Commands on a                   Commands in     plus native
    Controlled Device                 SCPs and        control logic
    by sending                      execute them.
    Service Control
    Protocols in
    response to local
    API calls.
    Inform a        Event           Accept requests Event
    Controlled Device Subscription    for Events and  Subscription
    of a desire to  Client          remember them.  Server
    receive Events.
    Receive an Event. Event Sink      Send an Event.  Event Source

    Type        Description                      Example
    String      A sequence of UNICODE characters.
    Number      A number, with no limit on digits; may 15, 3.14, --
                potentially have a leading sign, 123.456E+10
                fractional digits, and optionally an
                exponent. Punctuation as in US
                English.
    Boolean     TRUE or FALSE.
    DateTime    A date in ISO8601 format, with   19941105T08:1
                optional time and optional zone. 5:5+03
                Fractional seconds may be as precise
                as nanoseconds. See, "Data elements
                and interchange formats - Information
                interchange - Representation of dates
                and times", which can be found at
                http://www.iso.ch/markete/8601.pdf.
    ByteBlock   An unstructured sequence of bytes.

                          UPnP Addresses
    URL         Function
    Description Points to the Description Server and Document path on a
    URL         Root Device. This URL is returned by the Description
                Server as part of the discovery process.
    Presentation Points to a Presentation (Web) Server on a Controlled
    URL         Device. There is one Presentation URL per Device,
                including Root Devices. This URL can be entered into the
                address bar of a Web browser to navigate to the root
                Web page of a Device. This URL is returned in the
                Description Document.
    Control URL Points to the Control Server implementing a Service on a
                Controlled Device. There is one Control URL per instance
                of a Service. This URL is returned in the Description
                Document.
    Event       Points to an Event Subscription Server on a Controlled
    Subscription Device. This URL is returned in the Description Document.
    URL
    Event Sink  Points to an Event Sink (an HTTP Server) on a User
    URL         Control Point. This URL is specified by the User Control
                Point in the GENA SUBSCIBE message.

               UPnP SSDP Level Searches and Results
    Search for      Returns
    A unique Root   A single Description URL pointing to the Description
    Device (by      Server and Document path on the Root Device.
    UDN)
    A unique non-   A single Description URL pointing to the Description
    Root Device (by Server and Document path on the Root Device that
    UDN)            contains the non-Root Device.
    Type of Device  A set of Description URLs pointing to the Description
                    Servers/Document paths of all Root Devices that
                    match the Device Type, or contain a non-Root
                    Device that matches the Device Type.
    Type of Service A set of Description URLs pointing to the Description
                    Servers/Document paths of all Root Devices that
                    contain a matching Service, or contain a non-Root
                    Device that contains a matching Service.

                     UPnP Search Identifiers
                    Format             Example
    all             upnp:all           upnp:all
    Unique Device   upnp:UDN:namespace: upnp:UDN:IEEEMAC:0C009
    Name (UDN)      uniqueid           9123456
    Device Type     upnp:DevType:      upnp:DevType:vcr
                    devicetype
    Service Type    upnp:SrvType:      upnp:SrvType:clock:1
                    servicetype:ver

                     UPnP SSDP Announcements
                    UPnP
                    Notification
    Announcement    Type            SSDP USN
                    "all"           Root Device UDN
    Unique Root     Root Device     Root Device UDN
    Device          UDN
    Unique non-Root Non-Root Device Non-Root Device UDN
    Device          UDN
    Device Type     Device Type     Root Device UDN + Device Type
                    Identifier      Identifier
    Service Type    Service Type    Root Device UDN + Service Type
                    Identifier      Identifier

          HRESULT
          RehydratorQueryStateVariable(
              IN          LPCTSTR           lpcszVerb,
              IN          LPCTSTR           lpcszControlURL,
              IN          LPCTSTR           lpcszSTI,
              IN          LPCTSTR           lpcszVarName,
              OUT         VARIANT           *pValue);

        HRESULT
        RehydratorInvokeServiceAction(
            IN                LPCTSTR         lpcszVerb,
            IN                LPCTSTR         lpcszControlURL,
            IN                LPCTSTR         lpcszSTI,
            IN                LPCTSTR         lpcszActionName,
            IN                SAFEARRAY       saActionArgs,
            OUT     LONG                      *pStatus);

    Root        The XML root element of a UPnP Description Document.
    specVersion- The major version of the UPnP Architectural Reference
    Major       that this Description Document was created against. This
                value must be 1.
    specVersion- The minor version of the UPnP Architectural Reference that
    Major       this Description Document was created against. This value
                must be 0.
    URLBase     An optional element used to construct fully qualified URLs.
                Relative URLS are appended to the value of <URLBase> to
                create fully qualified URLs. If this element is present, it
                must agree with the HTTP Base header.
    manufacturer A required element that contains a textual manufacturer
                name.
    manufacturer An optional element containing a URL that points to the
    URL         Web page of the manufacturer.
    modelName   A required element containing a textual product name.
    model-      A required element containing a textual product description.
    Description
    model-      An optional element containing a textual product model
    Number      number.
    modelURL    An optional element containing a URL that points to the
                Web page of the product.
    UPC         An optional element containing the product Universal
                Product Code (UPC).
    serial-     An optional element containing a textual item serial
    Number      number.

    rootDevice  A required sub element of the root. This element is a
                container for one or more service elements and the elements
                that describe the rootDevice.
    device      An optional sub element of the root or another device
                element. This element contains the same kinds of elements
                as a rootDevice element.
    UDN         A required sub element of every rootDevice or device
                element containing the Unique Device Name.
    friendly-   A required sub element of every rootDevice or device
    Name        element containing a textual friendly name. This element
                can be updated remotely.
    deviceType  A required sub element of every rootDevice or device
                element containing a standardized Device Type Identifier.
    presentation An optional sub element of a rootDevice or device element
    URL         containing a Presentation URL.
    iconList    A required sub element of every rootDevice or device
                element. This element is a container for one or more icon
                elements. UPnP requires a base set of six icons that must
                exist in the iconList. All devices must support PNG icon
                image formals of three sizes, 16 by 16, 32 by 32 and 48 by
                48 pixels in both color and black and white at 8 bit depth.
                Additional formats and sizes, including JPEG, GIF, BMP,
                ICON and VML, may be supported by adding them to the
                list.
    icon        A required sub element of every iconList element. This
                element is a container for the elements that define an icon.
    size        A required sub element of every icon element. There must
                be icon elements with associated size elements with the
                values 16, 32 and 48. Other icons may specify other sizes.
    color       A required sub element of every icon element with value 0
                or 1. Each icon of size 16, 32 or 48 must exist in color and
                black and white.
    depth       A required sub element of every icon element. All required
                icons must exist with a value of 8.
    imageType   A required sub element of every icon element that identifies
                the format of the binary icon: png, jpeg, vml, gif, bmp, or
                ico.
    image       A required sub element of every icon element that
                references a binary icon.

    service       An optional sub element of the rootDevice or another
                  device element. This element is a container for
                  the Service Definition.
    serviceType   A required sub element of every service element
                  containing a standardized Service Type Identifier.
    controlURL    A required sub element of every service containing a
                  Control URL.
    eventSubURL   A required sub element of every service containing an
                  Event Subscription URL.
    SCPD          A required sub element of every service. The SCPD is a
                  container for the standardized Service Control Protocol
                  Declaration associated the Service.