WO2002001833A1 - Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau - Google Patents

Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau Download PDF

Info

Publication number
WO2002001833A1
WO2002001833A1 PCT/US2000/017844 US0017844W WO0201833A1 WO 2002001833 A1 WO2002001833 A1 WO 2002001833A1 US 0017844 W US0017844 W US 0017844W WO 0201833 A1 WO0201833 A1 WO 0201833A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
peer
upnp
devices
networking
Prior art date
Application number
PCT/US2000/017844
Other languages
English (en)
Inventor
William Michael Zintel
Original Assignee
Microsoft Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corporation filed Critical Microsoft Corporation
Priority to PCT/US2000/017844 priority Critical patent/WO2002001833A1/fr
Priority to AU2000256423A priority patent/AU2000256423A1/en
Publication of WO2002001833A1 publication Critical patent/WO2002001833A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2805—Home Audio Video Interoperability [HAVI] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/46—Indexing scheme relating to G06F9/46
    • G06F2209/462—Lookup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention relates generally to remote access to and control of general purpose operating system services, and more particularly to remoting such services via a peer networking device control protocol.
  • An operating system is software that generally controls the allocation and usage of hardware resources on a computer, such as memory, central processing unit (CPU) time, disk space, and peripheral devices.
  • General purpose operating systems provide an operating platform or environment on which application software for a wide variety of purposes can be run. Examples of popular general purpose operating systems include Microsoft Windows operating systems (e.g., Windows 95, 98, NT, 2000); the Mac OS of Apple Computer, Inc.; UNIX or Linux available from various vendors; and BeOS from Be, Inc.
  • a service has generally been defined to be a program, routine, or process that performs a specific system function to support other programs, particularly at a low (close to the hardware) level.
  • the services do not provide a user interface (UI) or interact directly with the user (e.g., display messages in a window or dialog box, or receive input from keyboard or mouse) during normal processing (except error messages and like interaction when exceptions occur, and administration or configuration of the service), but instead typically operate under programmatic control of an application program with which the user directly interacts.
  • UI user interface
  • Examples of services provided in the Microsoft Windows ® operating systems include date and time clock, file and printer sharing, print spooling, electronic mail, fax, telephony, file synchronization (e.g., with mobile devices), file backup and archiving, audio and video file streaming (e.g., to a peripheral play-back device, such as speakers or a monitor), audio and video codecs, file compression/decompression, problem diagnosis and support, event logging, user and software configuration administration, security and access control, remote access (RAS), networking (Internet socket, FTP, HTTP,
  • TCP/IP, NetBIOS, etc. TCP/IP, NetBIOS, etc.
  • name and address DHCP, DNS
  • remote procedure call RPC
  • named pipe dynamic peripheral configuration
  • Plug and Play application scheduling
  • application scheduling e.g., Windows 95 system agent
  • some operating systems e.g., Microsoft Windows NT
  • an extendible services architecture that permits plugging in or installing later-developed services (e.g., Windows NT Services, Unix Daemon).
  • Operating system services typically are exposed for programmatic control and use by locally executing application programs through an application programming interface (API) of the operating system.
  • the application program typically provides a user interface with which the user interacts to effect application-specific task work.
  • the application program may utilize the operating system services, and programmatically controls the services through the APIs.
  • a "music jukebox" application program could provide a user interface having a "graphics equalizer” and “playlist” display, and start, stop and pause controls with which the user interacts to play music audio files.
  • the application program utilizes audio streaming services of the operating system, which the application program controls via an API.
  • the operating system API typically operates using a local procedure call, software interrupt, or like mechanism.
  • 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.
  • proximity-based usage scenarios where devices interact based at least in part on geographical or other notions of proximity.
  • the general use scenario changes from one where the user interacts directly with a device that performs some work (e.g., by pressing buttons on a control panel), to one where the user interacts with one device that provides user interactivity and remotely controls another device doing the work.
  • a device that performs some work e.g., by pressing buttons on a control panel
  • the user directly interacts with a universal remote controller, cell phone or handheld/palm top/tablet computer to operationally control other devices in their immediate environment, such as a vending machine, video monitor, printer, door opener, or etc.
  • HAVi Home Audio Video Interoperability
  • Havi Organization formed by Grundig AG, Hitachi, Ltd., Matsushita Electric Industrial Co., Ltd. (Panasonic), Royal Philips Electronics, Sharp Corp., Sony Corp., Thomson Multimedia and Toshiba Corp
  • JINI the Joint Philips Electronics
  • UPD Universal Plug and Play
  • these peer networking device control protocols are designed to allow devices to expose their operational functionality to remote control from devices directly operated by a user.
  • general purpose operating systems provide a rich set of services to application programs running on the operating system via locally accessible APIs.
  • peer networking device control protocols allow remote control of operational functionality of typically specific purpose devices. It would generally be advantageous to also remotely control the general purpose operating system services in pervasive computing environments. However, because the services are programmed to be exposed through the operating system APIs and not via peer networking device control protocols, the services are not available to user control devices through these protocols.
  • legacy peripheral devices e.g., scanner, printers, data storage drives, etc.
  • UPnP bridge acts as a converter or adapter between the UPnP peer networking connectivity protocol and a host-peripheral connectivity protocol.
  • the UPnP bridge generally runs on the host computer acting as a controlled device in place of a "bridged peripheral device” to respond to addressing, discovery, description, and control messaging in the UPnP protocol from user control point devices, and in turn interacts accordingly with the bridged peripheral device using the bridged peripheral's host- peripheral connectivity protocol.
  • general purpose operating system services are programmed to be exposed through operating system APIs, the services are not available to remote control via a UPnP bridge to a host-peripheral connectivity protocol.
  • the present invention provides a way to expose general purpose operating system services to remote control via a peer networking device control protocol, which allows reuse of the operating system service without reprogramming the service as a "controlled device" per the peer networking device control protocol.
  • an adapter runs on the general purpose operating system and converts between the peer networking device control protocol and operating system APIs, so as to remote the general purpose operating system's services.
  • the adapter includes a publishing service and a service remoter.
  • the service remoter operates to remote operational functionality of general purpose operating system services through the publishing service.
  • the publishing service supports a publishing API via which application programs running on the operating system as well as the service remoter can interact with the publishing service.
  • the publishing service operates to expose operational functionality of the application programs and the services that interact with the publishing service through the publishing API as "controlled devices" under the peer networking device control protocol.
  • the publishing service acts as the "controlled devices" per the peer networking device control protocol by appropriately responding on behalf of the remoted applications and services to addressing, discovery, description and control requests made by user control point devices in the peer networking device control protocol.
  • the publishing service further converts these peer networking device control protocol requests to cause appropriate controlled operation of the services through the service remoter, which in turn interacts directly with the services through their APIs to effect the controlled operation.
  • Figures 1 and 2 are block diagrams of a device architecture per
  • Figure 3 is a block diagram of a general purpose operating system architecture with service remoter/publisher for remoting operating system services per Universal Plug and Play in accordance with an implementation of the invention.
  • Figure 4 is a block diagram of an implementation of the service remoter/publisher of Figure 3 in the Microsoft Windows operating system architecture.
  • Figure 5 is a block diagram of a device model per Universal Plug and
  • Figure 6 is a block diagram illustrating example devices conforming to the device model of Figure 5.
  • Figure 7 is a block diagram illustrating device state synchronization using a state table and eventing.
  • Figure 8 is a block diagram illustrating device addressing.
  • Figure 9 is a block diagram of a programmatic interface-to-network messaging adapter or Rehydrator in the device control model of Figure 5.
  • Figure 10 is a general data flow diagram of the Rehydrator of Figure 9 in the device control model of Figure 5.
  • Figure 1 1 is a block diagram of an implementation design of the Rehydrator of Figure 9.
  • Figures 12 and 13 are block diagrams illustrating an internal software architecture of the user control point and controlled device in the device control model of Figure 5.
  • Figure 14 is a block diagram illustrating an internal software architecture of a combined bridge and user control point in the device control model of Figure 5.
  • Figure 15 is a data flow diagram illustrating a typical browsing protocol sequence in the device control model of Figure 5.
  • Figure 16 is a listing showing a layout of a description document in the device control model of Figure 5.
  • Figure 17 is a listing of an exemplary icon list of a Description Document in the device control model of Figure 5.
  • Figure 18 is a listing of an exemplary service control protocol declaration in a Description Document in the device control model of Figure 5.
  • Figures 19 and 20 are a listing of an XML schema for a Service Control Protocol Declaration Language used in the device control model of Figure 5.
  • Figure 21 is a block diagram of an eventing model used in the device control model of Figure 5.
  • Figure 22 is a data flow diagram illustrating subscription, notification and unsubscription in the eventing model of Figure 21 .
  • Figure 23 is a block diagram of a computer system that may be used in the device control model of Figure 5.
  • Figure 24 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 Figure 23 in the device control model of Figure 5.
  • UnP universal-plug-and-play
  • Figure 25 is a block diagram of a software architecture per UPnP standards in the embedded computing device of Figure 24
  • Figure 26 is a data flow diagram of a process for automatic network introduction of the embedded computing device of Figure 24 into an ad hoc computer network environment per the UPnP protocol.
  • Figure 27 is a data flow diagram of a process for automatic network introduction of the embedded computing device of Figure 24 into a configured computer network environment per the UPnP protocol.
  • Figure 28 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 Figure 5.
  • Figure 29 is a block diagram of an exemplary home or office pervasive computing environment having a variety of computers as per Figure 23 and embedded computing devices as per Figure 24 interconnected per UPnP standards that may be used in the device control model of Figure 5.
  • Figures 30 through 40 are program listings of interfaces used in the
  • Figure 41 is a flow diagram illustrating automatically installing and configuring a UPnP bridge upon attaching or connecting a peripheral on a host personal computer.
  • OS operating system
  • this OS service-to-peer networking control protocol adapter is used in a device architecture 100 ( Figure 1 ), connectivity model, and device control protocol proposed by Microsoft Corporation, called Universal Plug and Play (“UPnP").
  • UnP Universal Plug and Play
  • PnP Plug and Play
  • 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 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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. None 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.
  • Controlled Devices examples include 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. None 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.
  • such a device could expose UPnP Controlled Devices to Legacy Devices in the manner required by the Legacy Devices.
  • 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.
  • 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 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).
  • SST Service State Table
  • SCP Service Control Protocol
  • SCPD Service Control Protocol Declaration
  • a 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.
  • URI Uniform Resource Identifier
  • URI Resource Identifiers
  • 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.
  • UDN Unique Device Name
  • 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.
  • URI Uniform Resource Identifier
  • SST Service State Table
  • 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.
  • SCP Service Control Protocol
  • SCP Service Control Protocol
  • SST Definition The protocol used to invoke Commands against a Service and to return results.
  • 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.
  • SCPD Service Control Protocol Declaration
  • 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.
  • 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 GEN A event architecture (see "Generic Event Notification") to transport event messages. All events are delivered using TCP/IP for reliability.
  • GAA Generic Event Notification Architecture
  • SSDP Simple Service 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
  • Client refers to a module that initiates a TCP/HTTP connection to a peer HTTP server.
  • Server refers to an HTTP server.
  • 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 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.
  • DNS Domain Name System
  • NBNS NetBIOS Name Service
  • 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.
  • URL Uniform Resource Locator
  • 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.
  • This 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.
  • 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.
  • 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 ® , ECMAScript, VBScript, ActiveX ® , Java Applet, etc.). Browser. A Presentation Client. A Web browser extended with a
  • 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.
  • a Control Client 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
  • 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 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.
  • DNS Domain Name System
  • NBNS NetBIOS Name Server
  • MDNS Multicast DNS
  • Simple Service Discovery Protocol 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
  • SSDP Simple Service Discovery Protocol
  • the successful result of an SSDP search is a Uniform Resource Locator (URL).
  • URL Uniform Resource Locator
  • 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.
  • 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.
  • 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.
  • UPnP 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:
  • the device. local is the Hostname of the Controlled
  • 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 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.
  • 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, Bridges 120, and OS Service Remoter/Publisher 150. 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.
  • Controlled Device 106-107 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 ( Figure 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.
  • Service Remoter/Publisher 150 ( Figure 2) exposes services 156-157 of a general purpose operating system 152 (e.g., services provided in the Microsoft Windows operating system), hereafter referred to as OS services.
  • the Service Remoter/Publisher 150 emulates a set of Controlled Devices providing the operational functionality of the OS services, and thus appears as a set of such Controlled Devices to the UPnP User Control Points 104- 105.
  • the Service Remoter/Publisher 150 then interacts with the OS services through the conventional OS API exposed by the OS services in response to the UPnP User Control Points 104-105 to effect remote control of the OS services from the UPnP User Control Points via the UPnP protocol.
  • Figure 2 is implemented in an exemplary general purpose operating system 152, which may be for example the Microsoft Windows operating system, as a UPnP Publishing Service 160 and a Service Remoter 162.
  • the general purpose operating system 152 provides a variety of OS services 156 that perform specific system functions to support other programs, including application programs run on the operating system.
  • the illustrated OS services 156 include date and time clock, file and printer sharing, print spooling, electronic mail, fax, telephony, file synchronization (e.g., with mobile devices), file backup and archiving, audio and video file streaming (e.g., from local or remote storage, and to a peripheral play-back device, such as speakers or a monitor), audio and video codecs, file compression/decompression, problem diagnosis and support, event logging, user and software configuration administration, security and access control, remote access (RAS), networking (Internet socket, FTP, HTTP, TCP/IP, NetBIOS, etc.), name and address (DHCP, DNS), remote procedure call (RPC) and named pipe, dynamic peripheral configuration (Plug and Play), and application scheduling (e.g., Windows 95 system agent), among others.
  • RAS remote access
  • networking Internet socket, FTP, HTTP, TCP/IP, NetBIOS, etc.
  • DHCP, DNS remote procedure call
  • RPC remote procedure call
  • pipe dynamic peripheral configuration
  • the OS services can include extended services that plug into an extendible services architecture of the operating system, such as using the Microsoft Windows NT Services programming model (see, for example, J. Richter, Design A Windows NT Service To Exploit Special Operating System Facilities, Microsoft Systems Journal (October 1997).
  • the OS services 156 are exposed to programmatic control by applications and other programs running on the operating system through a set of OS APIs 166 (e.g., the Microsoft Win32 API, which is described in Microsoft Win32 Programmer's Reference, Microsoft Press (1993).)
  • the UPnP Publishing Service 160 in the illustrated general purpose operating system 152 is a program structured as a service of that operating system (e.g., as a Windows NT Service), and provides a publishing API 164.
  • the UPnP Publishing Service 160 operates as a general mechanism for publishing the information necessary to emulate the functionality of devices and services running under the general purpose operating system as Controlled Devices per the UPnP protocol for devices and services that do not themselves support the UPnP protocol.
  • the Service Remoter 162, the Bridge 120, as well as Applications 170-171 use the publishing API 164 to establish a Controlled Device emulation of their functionality by the UPnP Publishing Service 160, and provide the communications (such as of the service state and Commands from User Control Points) between the programs and the UPnP Publishing Service to effect the emulation as Controlled Devices.
  • the UPnP Publishing Service 160 operates to publish information such as discovery responses, service description, and service state, as well as direct responses to UPnP requests, to User Control Points 104 for the set of Controlled Devices that it emulates.
  • the UPnP Publishing Service 160 also passes information back to the devices and services running under the general purpose operating system (e.g., via a callback registered with the UPnP Publishing Service through the publishing API) to effect the Commands from the User Control Point 104 to the emulated Controlled Devices.
  • the UPnP Publishing Service appears as the set of emulated Controlled Devices.
  • the UPnP Publishing Service and publishing API allows the Service Remoter 162, the Bridge 120 and applications 170-171 to expose their functionality for remote control though the UPnP protocol without having to individually implement all the various components (described below and illustrated in Figure 5) of a Controlled Device per the UPnP protocol. Instead, the UPnP Publishing Service implements the components of a Controlled Device collectively for the set of emulated Controlled Devices.
  • the Service Remoter 162, the Bridge 120 and applications 170-171 need only be programmed to use the publishing API.
  • the Service Remoter 162 is a program module that operates to convert between the specific OS API of the particular OS services, and the publishing API of the UPnP Publishing Service 160.
  • the Service Remoter 162 uses the publishing API to effect emulation of the particular OS Services as UPnP Controlled Devices by the UPnP Publishing Service 160, which exposes the OS services' operational functionality to remote control by User Control Points via the UPnP protocol.
  • the Service Remoter 162 uses the regular OS API of the OS services to effect control of the OS services. This avoids having to restructure or reprogram the OS services as UPnP Controlled Devices, or even to themselves use the publishing API of the UPnP Publishing Service 160.
  • Figure 4 illustrates an exemplary implementation of the UPnP Publisher/Remoter 150 ( Figure 2) in the Microsoft Windows operating system.
  • the UPnP Publishing Service 160 includes an instance of the Service Remoter 162 per each OS service 156 that is to be exposed as a UPnP Controlled Device, and a single SSDP Service 186 shared by all remoted operating system services 156 on the system.
  • the Service Remoter 162 in this exemplary implementation fully implements a UPnP controlled device that remotely exposes the functionality of the respective OS service 156.
  • the Service Remoter 162 includes a set of library modules 190-198 that implement the various discovery, description, eventing and control protocols of UPnP, as well as mapping code for converting communications with UPnP user control points per the UPnP protocol into interactions via the OS API with the OS service 156.
  • These protocol modules includes a UPnP Publishing API library 190, a SSDP server library 191 , an HTTP server library 192, a
  • the SSDP service 186 provides support for the SSDP discovery protocol for each OS service remoted through the UPnP Publishing Service 160.
  • the SSDP service 186 includes a separate instance of the Sockets library module 189 and a publish list 188.
  • Each OS service 156 to be remoted through the UPnP Publishing Service 160 is added to the publish list 188 of the SSDP service 186 via a call to the UPnP Publishing API library 190 and SSDP server library 191 .
  • the SSDP Service 186 then provides appropriate responses to SSDP discovery requests per the UPnP protocol for the remoted OS service 156.
  • the Service Remoter 162 handles incoming UPnP description requests and responses for the remoted OS service 156 via the Sockets library 193, the HTTP server library 192, and the UPnP Publishing API library 190 modules.
  • the Service Remoter 162 handles incoming event subscribe requests for the remoted OS service 156 via the Sockets library 193, the HTTP server library 192, and the UPnP Publishing API library 190 modules.
  • Data for out-going event publishing for the remoted OS service 156 (e.g., the service's state) is handled in the Service Remoter 162 through the UPnP Publishing API library 190, the GENA publish library 196, the HTTP client library 198 and the Sockets library 193 modules.
  • the Service Remoter 162 further handles control commands of UPnP User Control Points to the remoted OS service 156 via the Sockets library 193, the HTTP library 192, the SOAP server library 195, and the UPnP Publishing API library 190 modules.
  • Event Sink Send an Event.
  • the UPnP Device Model 200 shown in Figure 5 is the model of a
  • the Device Model includes the addressing scheme, eventing scheme, Description Document schema, Devices and Services schema and hierarchy, and the functional description of modules.
  • the UPnP Device Model extends beyond simple API or a command and control protocol definitions to enable multiple User Control Points to have a consistent view of Controlled Devices. This requires that the state of running services be formally modeled and that all state changes be visible to User Control Points. Central to the distributed UPnP architecture is the rule that Controlled Devices are the ultimate authority for the state of Services running on them.
  • the fundamental controllable entity in UPnP is a UPnP Service 210-
  • Every running instance of a UPnP Service includes:
  • a Service State Table (SST) 230 which represents the current state of the UPnP Service.
  • the SST 230 can be used to represent the operational mode of device or to act as an information source or sink for structured data or simple files.
  • the SST of a VCR 254 ( Figure 6) could represent the current transport mode, tuner channel selection, input and output switch selections, audio and video decoding format and current timer program.
  • the SST of clock 251 ( Figure 6) would likely represent the current time.
  • the SST of an image rendering device could implement a video frame-buffer that can accept raw pixel information or formatted JPG files.
  • the SST of an audio or video playback device could implement a transfer buffer or queue of material to be played.
  • the SST of PDA could implement a collection of formatted data that has changed and needed to be synchronized with another device, in addition to a transfer buffer for accepting incoming formatted data.
  • a Control Server 232 which accepts incoming Commands expressed in the UPnP Service's Service Control Protocol (SCP).
  • SCP UPnP Service's Service Control Protocol
  • the Control Server passes the command to the UPnP Service's native command processing logic and waits for command completion.
  • the SST is updated, an event is generated, and a successful response is returned to the User Control Point.
  • no changes are made to the SST and a failure response is returned.
  • the Command and response sequence is payload to a TCP/HTTP request/response.
  • the Event Subscription Server accepts incoming GENA SUBSCRIBE messages from User Control Points and adds them to a list of User Control Points interested in SST change events from the UPnP Service.
  • the Event Source initiates a TCP/HTTP connection to each interested User Control
  • the NOTIFY payload includes the changed contents of the DST.
  • Control URL that identifies the Control Server.
  • Event URL that identifies the Event Subscription Server.
  • the formal definition of a UPnP Service includes: • The definition of the SST. SST layouts are logically specified in terms of rows of [ Variable, Type, Legal Values, Default Value ]. The actual instance of a SST would also include a Current Value field in every row.
  • SCPD Service Control Protocol Declaration
  • the SCP can be generated from the SCPD.
  • the Rehydrator's job is to convert SCPDs into SCPs.
  • the reason for a formal SCP specification is to enable the implementation of the Control Server itself and to enable simple peer-to-peer device interoperation using only published protocols.
  • An identifier, called the Service Type Identifier that identifies a unique Service Definition. Service Definitions are versioned in controlled manner. Every later version of a UPnP Service must be proper superset of the previous version.
  • Device 202-205 (e.g., multiple function devices 102-103 of Figure 1 and bridged devices 122-123 of Figure 2) is a logical container of one or more
  • UPnP Services 210-217 Generally a Device represents a physical entity such as a VCR. Typical UPnP Services in the VCR Device example might be "TRANSPORT”, “TUNER”, “TIMER” and “CLOCK”. While Devices are often physical entities, a PC emulating the traditional functions of a VCR could also be modeled in the same way as the stand-alone VCR. Devices can contain other Devices. An example would be a TV/VCR 250 ( Figure 6) packaged into a single physical unit. A Device (e.g., devices 202-203) may also be a logical container of other Devices. The top-most Device in a hierarchy of nested Devices 203-205 is called the Root Device 202. A Device with no nested Devices is always a Root Device.
  • the UPnP Device Model was designed to be general and flexible. It should be possible to model an entire Nuclear Power Plant as a single UPnP Service or as a deeply nested hierarchy of Devices and UPnP Services. In general, a UPnP Service 210-217 is cohesive set of functions that enables flexible packaging into a variety of Devices. UPnP Services can be versioned independently of Devices. All Devices, including Root Devices belong to one or more Device
  • Device Types are intended to enable instances of Devices to be simply and automatically grouped for presentation.
  • An example of a Device Type is "VCR" 254 ( Figure 6).
  • Device Types are formally defined in terms of a minimal set of versioned UPnP Services that a Device of Device Type must support.
  • Device Types are not formally versioned.
  • Device Type is a relatively high level grouping. A Device of Device Type only ensures that minimal set of UPnP Services of a minimal version is present. There can be other UPnP Services, higher versioned UPnP Services and UPnP Services with vendor extensions present on such a Device.
  • UPnP enables SSDP level searches for a unique instance of a Device (by UDN), all Devices of type Device Type and all Devices that contain at least one Service Type of minimum version.
  • the result of an SSDP search is always a URL that points to the Description Document contained in the Root Device.
  • the Description Document has a tree of nested Devices that can be traversed to find the matching Device. Every Device includes:
  • a Presentation (Web) Server 220-223 that can be used to expose Device user interface. Every Presentation Server has an associated Presentation URL.
  • UDN Unique Device Name
  • the formal definition of a Device includes:
  • Device Types The formal definition of a Device Type includes:
  • Service State Table A Service State Table (SST) logically consists of rows of:
  • entries of the Service State Table in UPnP consist of these five items, the state table alternatively can contain fewer or additional items.
  • each entry will minimally consist of a Variable name or identifier, and its current value.
  • DateTime A date in ISO8601 format, with 19941 105T08: 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, International Standard, ISO 8601 , First Edition 1988-06-15.
  • the ByteBlock is essentially a data buffer.
  • a variable of this type can be used to effect transfer of a file from the Controlled Device to the User Control Point.
  • the file to be transferred is kept in the Service State Table as the current value of this variable.
  • the file is transferred to any subscribing User Control Point in an event notification.
  • An SST can be used to represent to current operational mode of device, act as an information source or sink and/or simply be a repository for commands.
  • the SST of a VCR UPnP Service could represent the current transport mode, tuner channel selection, input and output switch selections, audio and video decoding format and current timer program.
  • the VCR 254 could be represented as a Transport UPnP Service 260, Tuner UPnP Service, I/O Switch UPnP Service, A/V Decoding Configuration UPnP Service and Programmable Timer UPnP Service 261 .
  • the SST of a clock 251 would likely represent the current time. Additionally an alarm clock could include Service Variables to configure the clock.
  • the SST of an image rendering device could implement a video frame-buffer that can accept raw pixel information or formatted JPG files.
  • the SST of an audio or video playback device could implement a transfer buffer or queue of material to be played.
  • the SST of PDA could implement a collection of formatted data that has changed and needed to be synchronized with another device, in addition to a transfer buffer for accepting incoming formatted data.
  • UPnP is built on top of HTTP and leverages the native address format of the Web, Uniform Resource
  • Locators URLs minimally contain an identification of the application protocol family ("http") that the URL is valid for, a Hostname and a path.
  • http application protocol family
  • the path part of a URL can represent either a filesystem path or simply an identifier of the local system module and context that can process incoming messages.
  • UPnP modules are described as HTTP servers, there is no requirement that implementations be based on actual Web servers. In most cases, the job of the HTTP server is simply to accept the incoming connection, look at the local destination part of the address (the path) and forward the payload to another module.
  • UPnP enables, but does not require, that all HTTP Servers be based on a common software implementation or runtime instance.
  • Controlled Devices and Bridges can include a TCP port specification as part of a URL to override the default value of 80.
  • the successful result of a SSDP level search in UPnP is always one or more Description URLs. These URLs can be used to navigate to the Description Document of a Controlled Device or Bridge.
  • a User Control Point uploads the Description Document and extracts the URLs of the Servers running on the Controlled Device or Bridge. All URLs returned in the Description Document have a lifetime equal to the lifetime of the Hostname embedded in them. User Control Points can store these URLs as addresses without going through a search sequence first. Once they have been advertised in a Description Document, Controlled Device and Bridges cannot arbitrarily change Server URLs. Whenever a Hostname changes, all URLs associated with all Devices addressed by that Hostname are invalidated. The UDN is the only UPnP identifier guaranteed never to change. Any persistent associations maintained by applications should at least store the UDN to able to unambiguously identify the target Device. The lifetime of a Description URL is determined by Controlled Device or Bridge that advertises it.
  • a Controlled Device or Bridge allows an SSDP advertisement of a Description URL to expire, the URL is invalidated.
  • User Control Points use the Event Subscription URL returned by the Controlled Device or Bridge to connect to the Event Subscription Server. This server does the housekeeping of remembering all User Control Points that are interested in receiving Events on a UPnP Service.
  • the Event Subscription Server needs an address to send the events back to. This address is called the Event Sink URL, and is supplied to the Controlled Device or Bridge in the GENA SUBSCRIBE message.
  • the lifetime of an event subscription, and the Event Sink URL is determined by the timeout on the SUBSCRIBE message.
  • 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 UPnP Service on a Controlled Device. There is one Control URL per instance of a UPnP Service. This URL is returned in the Description Document.
  • Event Sink URL Points to an Event Sink (an HTTP Server) on a User
  • This URL is specified by the User Control Point in the GENA SUBSCIBE message.
  • UPnP enables SSDP searches for a unique Root or non-Root Device by UDN, devices of a specified Device Type and devices containing a UPnP
  • a unique Root A single Description URL pointing to the Description Device (by Server and Document path on the Root Device.
  • 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
  • Type of Service A set of Description URLs pointing to the Description
  • SSDP specifies Service Type (ST), Notification type (NT), and Unique Service Name (USN) header fields for queries and for announcements.
  • ST Service Type
  • NT Notification type
  • USN Unique Service Name
  • UPnP search identifiers are used during the discovery process.
  • the result of a successful discovery is one or more Description URLs.
  • the format for search identifiers is:
  • all ] allformat all
  • SSDP specifies that SSDP announcements must be made for all SSDP searchable values.
  • the SSDP announcements with "all" as the notification header value must carry the Root Device UDN as the USN header value.
  • SSDP announcements for Device Types must carry the UDN of the Root Device concatenated with the Device Type URI as the USN header value.
  • SSDP announcements for a Service Type will carry the UDN of the Root Device concatenated with the Service Type URI value as the USN header value.
  • SSDP announcements of UDNs will repeat the UDN value as the USN header.
  • Identifier Identifier UPnP Bridges 120 announce Bridged Devices 122-123 and associated UPnP Services using SSDP.
  • the identifiers associated with the Bridged Devices are unique for the device, and they do not duplicate identifiers for Controlled Devices and UPnP Services directly available on the Bridge itself. This means that a Bridge that is also a Controlled Device must announce Bridged Devices and local Controlled Devices independently, with appropriate unique identifiers, Description Documents and associated URLs.
  • the UPnP Description Document 226 ( Figure 5) provides the information necessary to identify, describe, connect and control a UPnP
  • the Description Document is an XML document.
  • UPnP defines the use of HTTP and XML for the Description Document and wire protocols.
  • UPnP adheres to the schema declaration rules of XML-Data and Y, Goland,
  • top level XML elements are separated into three categories: per
  • Services involves a message exchange between a User Control Point 104 and the device 106. This message exchange happens according to a specific Service Control Protocol (SCP) 402, which specifies the content and sequence of the messages exchanged.
  • SCP Service Control Protocol
  • User Control Points 104 are not required to have any prior knowledge of the SCPs 402 required to control the UPnP Services on the various devices. Therefore, a Controlled Device or Bridge must be able to describe to a User Control Point the protocols required to control its UPnP Services, such that the User Control Point will be able to implement these protocols dynamically. This requires a standard way of declaring Service Control Protocols in a concise and unambiguous fashion. UPnP introduces a technique for declaring Service Control Protocols using a series of XML documents.
  • a Rehydrator 410 is a module that exposes a suitable API to applications and either invokes Commands on a UPnP Service or queries the state of that UPnP Service, or receives and responds to events.
  • the primary job of the Rehydrator is to map between API calls and the Service Control Protocol sequence that invokes the Command.
  • a Service State Table 230 and Command Set 408 are defined. These things can be combined in a deterministic way defined by UPnP to produce a Service Control Protocol Definition (SCPD) 406, which includes a Service Control Declaration 404 and a Service Control Protocol 402.
  • SCPD 406 is a representation of the schema of a UPnP Service. It is possible to reconstruct the SST, Command Set and SCP from the SCPD.
  • the SCPD is directly embedded into the Description Document 226 of a Controlled Device.
  • the Rehydrator 410 can extract the SCPD from it.
  • the Rehydrator has enough information to issue UPnP Service specific SCPs 402.
  • the Rehydrator 410 operates as a universal adapter to provide a programmatic interface to any service-specific protocol of a remote computing device.
  • this data description takes the form of the Description Document 226, which contains a Contract 412,
  • the Contract defines network data packets 413 (e.g., XML data), request/response patterns, and protocol (e.g., GENA, HTTP, SSDP) via which the packets are exchanged.
  • This information is sufficient for the Rehydrator to exchange the appropriate network data packets to interact with the Controlled Device Service, including to invoke commands, query and set properties, and receive and respond to events, without download of any executable code to the User Control Point 104 device and with a zero installation or configuration experience.
  • the Description Document 226 also includes a declaration of the methods, properties and events for the UPnP Service. Based on this declaration, the Rehydrator produces a corresponding programmatic interface for use by applications at the User Control Point.
  • the programmatic interface is an application programming interface that can be in the form of an object integration interface of an object-oriented programming model, such as Microsoft COM, CORBA, Java classes, and scripting engine name extensions.
  • the Rehydrator 410 exposes a COM object integration interface ("ICIock" interface 414), with methods getTimeO and setTime(), for a Controlled Device having a "Clock" UPnP Service with GetTime and SetTime commands.
  • the Rehydrator 410 converts calls of an application program 416 to the ICIock interface 414 into the network data messages specified in the Contract to invoke the corresponding commands of the Clock UPnP Service.
  • the Rehydrator 410 likewise creates suitable further programmatic interfaces for other UPnP Services (e.g., UPnP Services 210- 217 of Figure 5) based on the Description Document of their respective Controlled Devices.
  • the Rehydrator operates as a universal proxy object with data-driven conversion of programmatic interfaces to network data messages. Further, the Rehydrator produces the programmatic interface at the User Control Point based solely on an XML data description. This operation allows the Rehydrator to produce just-in-time transient interfaces to remote device UPnP Services without the complexity of code downloads and installation or configuration. Upon a later release of the interface by the application, the Rehydrator destroys the interface without need to deinstall or clean up persistent configuration data in a registry or configuration file of the operating system or object execution run-time.
  • a preferred implementation 440 of the Rehydrator 410 is as an internal Microsoft Windows component that routes service control requests from the UPnP API to devices.
  • Applications wishing to control a UPnP Service on a UPnP device obtain a
  • Rehydrator performs a mapping between API calls and network protocols.
  • Basic Functionality The preferred implementation of the Rehydrator is able to translate a service control call to the UPnP API into the appropriate network messages defined by the Service Control Protocol.
  • Asynchronous Event Notification The preferred implementation of the Rehydrator is able to notify UPnP API clients of any asynchronous events generated by the devices they are controlling. Event notification is done by means of the event interfaces defined below.
  • Rehydrator is able to provide a way to communicate the success or failure status of such operations to the parties initiating them.
  • Rehydrator Implementation Design As illustrated in Figure 1 1 , the preferred implementation of the Rehydrator is used in two ways. First, the Device Finder 450 uses it to create Service objects 460. Then, these
  • Service objects use it to carry out service control operations (querying state variables and invoking actions).
  • Each service instance supports a particular Service Control Protocol and the Rehydrator needs a description of this protocol in order to create a properly hydrated Service object.
  • the Service Control Protocol is declared in two separate XML documents: the DCPD and the Contract.
  • the Rehydrator needs the information in both documents. These two documents are passed to the Rehydrator as IXMLDOMDocument interface pointers in the RehydratorCreateServiceObjecW API call.
  • This API returns a pointer to an IUPnPService interface on a newly created Service object.
  • the Rehydrator sets up its internal data structures so that it can properly handle requests to control the UPnP Service. Specifically, it creates a list of the properties and actions exported by the UPnP Service. Since all service instances of the same service type export the same properties and the same actions, this information is kept only once for each service type and is indexed by Service Type Identifier.
  • the Rehydrator stores the information that is specific to a particular service instance as private data within the Service object itself. This includes the control URL and information about the control server 232 (such as the HTTP verbs it supports).
  • the Service Type Identifier is the link between the Service object that represents one instance of a service type and the Rehydrator internal data structures that contain information common to all instances of that service type.
  • the Service Type Identifier is stored as a private data member in the Service object.
  • the first two in parameters to this function supply the service instance specific information: the HTTP verb to use and the control URL to which the network messages will be targeted.
  • the third parameter is the
  • the Service Type Identifier that will be used to locate the Service Control Protocol information in the Rehydrator's internal data structures.
  • the fourth parameter is the name of the variable that is being queried (the Rehydrator will validate this against is internal list of state variables exported by the UPnP Service) and the final parameter is the address of a VARIANT structure in which the Rehydrator will place the variable's value.
  • This function will generate an HTTP request to the control server on the device.
  • the body of this request will be an XML fragment containing a XOAP-encoded request for the variable's value.
  • the following is an example of such a request (the exact header and payload format of this message is defined in the service contract): M-POST /clockService HTTP/1.1
  • User-Agent Mozilla/4.0 (compatible; MSIE 5.01;
  • the control server will respond to this message with another XML fragment: the XOAP-encoded method response.
  • Service action is very similar to querying a state variable.
  • An application calls lUPnPServicer.lnvokeAction on a Service object, passing it the name of an action to invoke, and an array of arguments to the action.
  • lUPnPServicer.lnvokeActionO calls RehydratorlnvokeServiceActionO , declared as shown below.
  • the service instance specific information is passed in the first two parameters, followed by the
  • RehydratorlnvokeServiceActionO will send an HTTP request to the control server identified by the second parameter.
  • the body of this message will be an XML fragment containing a XOAP-encoded method call.
  • An example HTTP request to invoke an action is shown below.
  • M-POST /clockService HTTP/1.1 Host: spather-xeon: 8586 Content-Type: text/xml Man: "http : //www.microsoft . com/protocols/ext/XOAP" ; ns 01
  • the encoding of the body of this message is again specified in the service contract.
  • the Rehydrator will wait for the HTTP response to this request, which would look something like the example below.
  • Figures 30 through 40 are program listings defining various interfaces used in the preferred implementation of the Rehydrator, including an lUPNPDevice Interface, an lUPNPPropertyBag Interface, an lUPNPService Interface, an lUPNPDevices Interface, and an lUPNPServices Interface.
  • User Control Points 104 can retrieve a
  • Description Document 226 by issuing an HTTP GET on a Description URL.
  • This URL is returned in the location header of either an SSDP announcement or an SSDP query response.
  • the HTTP GET must include an accept-language header that is used to request the preferred language of the response. If the requested language is not supported, a Description Document in the default language supported by the Controlled Device or Bridge may be returned.
  • An HTTP GET is used to retrieve sub elements of a Description Document that are expressed as URLs.
  • URLs embedded in Description Documents 226 take one of 3 forms: a fully qualified URL or a relative URL.
  • Fully qualified URLs take the form: http : //devicename/pathname
  • the devicename part of the URL is a Hostname or IP address and the pathname is a filesystem path or equivalent.
  • a fully qualified URL is used "as is" to establish an HTTP connection to a device.
  • a relative URL does not contain the ":" character and is of the form: pathname
  • /pathname Relative URLS are a compact representation of the location of a resource relative to an absolute base URL. All relative URLs in a Description
  • a Description Document Some elements of a Description Document are binary. XML does not directly support the embedding of binary data. In order to include binary data directly in a Description Document, one must convert the data to text using the Base 64 encoding scheme. This tends to increase the size of the data by 25% on the average. Much of this overhead can be eliminated if the binary data is passed by reference instead of by value.
  • a URL to the data is provided in a Description Document. The binary data can be retrieved by doing a HTTP GET with that URL. As an example, consider the ⁇ image > element in the following
  • the icon would be retrieved with an HTTP GET of the following format:
  • the HTTP response would look like:
  • Root The XML root element of a UPnP Description Document.
  • 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 A optional element containing a URL that points to the Web page of the manufacturer.
  • URL modelName required element containing a textual product name URL modelName required element containing a textual product name.
  • modelDescrip A required element containing a textual product description, tion
  • modelNumber An optional element containing a textual product model number.
  • modelURL An optional element containing a URL that points to the Web page of the product.
  • serialNumber An optional element containing a textual item serial 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.
  • friendlyName A required sub element of every rootDevice or device 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.
  • 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 formats of three sizes, 16 by 1 6, 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.
  • 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.
  • Each icon of size 16, 32 or 48 must exist in color and black and white.
  • imageType A required sub element of every icon element that identifies the format of the binary icon: png, jpeg, vml, gif, bmp, or ico.
  • serviceTyp A required sub element of every service element containing a e standardized Service Type Identifier.
  • controlUR A required sub element of every service containing a Control L URL.
  • eventSubU A required sub element of every service containing an Event RL 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.
  • Figure 17 shows an exemplary icon list in a Description Document
  • the SCPD 406 is a representation of the schema of a UPnP Service. It is possible to reconstruct the SST 230, Command Set 408 and SCP 402 from the SCPD deterministically. The declaration of such a protocol must specify the list of Variables that can be queried, the set of Commands that can be invoked, as well as the wire protocol (the content and sequence of network messages) required to carry out these operations. SCPD is specified in two XML documents. The first or Service Control Definition document 404, written in a language called Service Control Protocol Declaration Language
  • SCPDL Service Control Protocol
  • the second or Service Control Protocol document 402 declares the wire protocol that will be used to query the values of the state variables and invoke the actions associated with the UPnP Service.
  • a SCPDL document 404 is used to specify the list of state Variables that a SCP can query and the set of Commands that it can invoke.
  • SCPDL is an XML schema, a set of rules for writing XML documents (Service Control Protocol Declarations).
  • Figure 18 shows an exemplary SCPDL document.
  • This XML document consists of a root ⁇ scpd> element containing two sub- elements, ⁇ serviceStateTable> and ⁇ action List > .
  • Within the ⁇ serviceStateTab/e> element is a ⁇ stateVariab/e> element for each state variable associated with the UPnP Service.
  • the UPnP Service in this example is a TV tuner with has only one state variable, currentChannel.
  • the elements within the ⁇ state Variable > element specify the name, data type and allowed values for the state variable. Had the UPnP Service more state variables, they would be represented by additional ⁇ stateVariab/e> elements within the ⁇ deviceStateTable> element.
  • the ⁇ actionList> element contains an ⁇ action > element for every action associated with the UPnP Service.
  • the elements within an ⁇ action > element specify the name of the action and any arguments the action may take.
  • the UPnP Service supports two actions that do not take arguments, ChannelUp and ChannelDown, and another, SetChannel, that takes a new channel number as an argument.
  • the ⁇ argument> element and the elements nested within it define the argument.
  • the ⁇ relatedStateVariable> element within ⁇ argument > specifies the name of one of the state variables to which the argument is related. In the UPnP Device Model, all arguments to actions must correspond directly to some state variable.
  • Figures 19 and 20 show an XML schema for the SCPDL.
  • the UPnP architecture 200 ( Figure 5) requires that clients of the UPnP API be enabled to receive notifications reliably from UPnP services 210-217 as their states change. Since state changes are relatively common, the eventing subsystem's efficiency and performance is a major consideration in this design.
  • Figure 21 and the following discussion describe the Basic UPnP Eventing Architecture 600, which encompasses both the controlled device (CD) 106 and user control point (UCP) 104 sides of the eventing UPnP Service. It also includes the support APIs for both a low-level UPnP Service interaction and a higher level COM-based wrapper of those APIs. The latter enables automation controllers like Visual Basic and JScript 602 to receive event notifications.
  • Property change events are defined as any change in the value of a row of the Device State Table (DST) 230 ( Figure 5) for a UPnP Service
  • UPnP Service For example, if a "VCR" device has a "VCR Transport" UPnP Service, one row in that UPnP Service's DST may be TapeState and the value could be TapePresent. If the tape is ejected, the new value would be TapeAbsent.
  • This state change would be reflected as a notification sent to all subscribers.
  • a UPnP event notification is an XML message sent over HTTP/TCP to each and every subscriber to a particular UPnP service.
  • the content of the XML is defined below.
  • the important contents of this message are the unique identifier for the subscription, the property name, new value, and property type.
  • SSDP already listens on another multicast address for "alive” and "byebye” messages sent by UPnP devices. The same listener will listen on a TCP port for notifications sent. All subscriptions sent from that UCP contain the same callback URL and so all notifications will be directed to that URL.
  • the SSDP service When a notification arrives the SSDP service will examine the NT header of the message and determine if it is an event notification. If so, the message is parsed further to determine if it should be forwarded on to subscribers (which must exist).
  • GENA defines the format of the HTTP message, what headers can be used, and what they can be used for.
  • GENA is the protocol of communication that, in a preferred embodiment, UPnP devices use to send event notifications. Therefore, UPnP devices that wish to notify UCPs of state changes are recommended to use GENA. Notification subscribers will never be required to interact with a UPnP device directly and so they are not required to use GENA.
  • the eventing API will encapsulate this complexity. Other appropriate event transport protocols may be used, such as publish/subscribe systems.
  • C Application 604 Applications written in C (C Application 604) will be able to utilize the SSDP C API 610 to receive callbacks when notifications are processed by the SSDP service.
  • This is analogous to SSDP clients registering for notifications that services have become available.
  • a UCP registers for a notification, it passes as a parameter the URL of the UPnP Service for which it is interested in receiving notifications. This URL is obtained from the description document for that UPnP Service. (When a UPnP Service is registered on a UPnP device, it uses this same URL to listen for subscription requests).
  • the SID header is checked against the list of subscribers it maintains. If a subscriber is found, the callback function for that subscriber is invoked, with one of the parameters being the contents of the notification message.
  • the notification client that implements the callback function can process this message in any appropriate way.
  • the UPnP API 410 is a consumer of the basic C interface provided by the SSDP C API 610 component. In order to integrate seamlessly, the registration of notifications is handled by the Service Object 612 inside the
  • UPnP Object Model Service objects will register for notifications when they are created. This ensures that the DST is maintained by the UPnP API and is kept up to date. They will implement the callback function required by the registration function. If this callback function is invoked, it will pass on that notification to UCPs.
  • the UCPs can be written in C, C + + , VB, or script code, so the mechanism for passing on notifications can be different.
  • a feature of the illustrated eventing system is that it supports script languages such as VBScript and JavaScript 602.
  • VBScript this is made possible by providing a property on the Service object that, when set, contains the IDispatch pointer for a VBScript function or subroutine that will be the event handler.
  • the Service object's notification callback is invoked, it checks to see if this IDispatch pointer was set, and if so, it calls IDispatch::lnvoke on DISPID 0 of that interface to call the VBScript subroutine.
  • An equivalent mechanism is implemented for JScript.
  • UCP - User control point Any piece of software that searches for devices and controls them.
  • CD - controlled device A hardware or software device that announces its availability thru SSDP and allows control by UCPs.
  • Notifying Resource (or simply "Resource") - For the purposes of this document, this will always be a UPnP Service contained within a UPnP CD 106.
  • Event Source - a UPnP Service that provides events.
  • UPnP services are event sources. All notifying resources are event sources and vice versa.
  • Property - a single entry in the UPnP Service's state table whose DefaultValue can change. Properties and events always have a one to one correspondence.
  • the UPnP API 410 exposes several interfaces with which a consumer can find and enumerate devices, control UPnP Services, and get properties on devices and UPnP Services.
  • EventHandler a new property to the IUPnPService interface called EventHandler.
  • RegisterNotificationO API is called when the Service object is created so that it can maintain a local copy of the DST for that UPnP Service.
  • the Service object knows the URL of the UPnP Service and therefore it can provide this as a parameter to RegisterNotificationO.
  • RegisterNotificationO is also provided a callback function which is a static member of the Service object class. This function will be invoked for each and every notification sent by that particular UPnP service.
  • the Service object 612 includes a static member function called
  • EventNotif y Callback 0 which is invoked for each notification sent by the
  • the callback is passed the entire HTTP message contents in a structure which is a parameter to the function.
  • the prototype looks like this:
  • CUPnPService EventNotif yCallback ( SSDP_CALLBACK _ TYPE ssdpType, SSDP_MESSAGE *pssdpMsg,
  • the ssdpType parameter should always be SSDP PROPCHANGE.
  • the pssdpMsg parameter contains the relevant information about the event.
  • the key piece of information is the body of the XML message.
  • the body contains information about what property changed, what its new value is and what type it is, among other information.
  • the pContext parameter will always be the this pointer of the Service object. This allows the code to call a method to fire the event to the UCP.
  • the callback will parse the XML body using the XML DOM services. Property changes are iterated and the local DST is updated to reflect these changes. After this processing is done, an event notification may be fired for each property that was changed to the owner of the subscription if one exists. Depending on what environment the owner is written in (C + + or script, etc.), a different mechanism for firing the event may be employed.
  • a special case for this process is the very first notification received after a subscription is established. This notification contains the entire set of properties and their values and is used to locally sync up the DST. Events will not be fired to clients of the UPnP API in this case.
  • EventNotifyCallbackO When the EventNotifyCallbackO function is called, the local copy of the DST for the UPnP Service is updated. After this, an event needs to be fired if a subscriber exists. A subscriber exists if the put_EventHandler() method was called, either from VBScript, C + + code, or another source. To abstract away this complexity, a new interface called lUPnPEvents is needed.
  • NotifyEventO This interface currently has one method called NotifyEventO which takes several parameters.
  • EventHandlerO function When put EventHandlerO function is called, its argument is an lUnknown. This pointer is Querylnterface'dO for IDispatch first, and if it succeeds, then IDispatch::lnvoke() is called with DISPID 0 to invoke the default method. This allows VBScript 602 to be called. If that fails, however, it is Queried for lUPnPEvents, and if that succeeds, the NotifyEventO method is called with the same parameters as for InvokeO. The handles C + + UCPs effectively. Subscribing with C + + +
  • a UCP To subscribe to a UPnP service from C + + , a UCP instantiates a
  • UPnP service object issues QuerylnterfaceO to it for lUPnPEvents, and calls the IUPnPEvents::SetEventCallback() function.
  • This function takes 2 parameters, a callback function pointer and a context pointer.
  • Devices UPnPAPI . FindDevices ( . . . ) For each device in Devices
  • the script enumerates all devices, looking for any device that supports the "Clock” interface. When it finds a device that supports that interface, it enumerates that device's UPnP Services looking for the one that has the "clock.v! " interface. Once it finds that UPnP Service, it sets that service's EventHandler property to the VBScript subroutine called "clock PropertyChanged". This name is arbitrary.
  • GENA clients are actually UPnP services.
  • a GENA client creates a new event source when it is initialized.
  • the GENA client API 620 facilitates this. It also provides a way for GENA clients to send their notification messages. It is also important to note that the HTTP server that lives on the UPnP device is also a client of this API.
  • the GENA client API consists of the following functions:
  • the RegisterUpnpEventSourceO API gives a GENA client the ability to register itself as an event source.
  • the prototype is as follows:
  • szRequestUri [in] an arbitrary Request-Uri that SUBSCRIBE requests will be sent to.
  • a SUBSCRIBE request arrives at the given URI, it is acknowledged and the subscriber is added to the list of notification recipients.
  • this URI should match the URI provided in the description for this service.
  • CProps [in] the number of properties that this event source provides.
  • RgProps [in] Array of UPNP PROPERTY structures which contain information about each property. The property information is derived from the DST for the event source.
  • Return Value The function returns a TRUE if successful. If the given URL has already been registered as an event source, the return value is FALSE and GetLastErrorO returns ERROR_ALREADY_EXISTS.
  • the initial state of the event source needs to be given to the API so that it can effectively maintain the up-to-date state of the event source.
  • the DeRegisterUpnpEventSourceO API gives a GENA client the ability to deregister itself as an event source.
  • the prototype is as follows: VOID DeRegisterUpnpEventSource (
  • szRequestUri [in] an arbitrary Request-Uri that SUBSCRIBE requests will be sent to.
  • a SUBSCRIBE request arrives at the given URI, it is acknowledged and the subscriber is added to the list of notification recipients. Note that this URI should match the URI provided in the description for this UPnP Service.
  • the SubmitUpnpPropertyEventO API allows the GENA client to submit a UPnP property change event to be sent to subscribers as a notification.
  • the prototype is as follows: BOOL SubmitUpnpPropertyEvent (
  • SubmitUpnpPropertyEventO calls SubmitEventj) after it has generated an XML body.
  • SubmitEventO API allows the GENA client to submit an unstructured event to be sent to subscribers as a notification.
  • the prototype is as follows:
  • SzRequestUri [in] identifies the event source to which this event belongs. This is the same Request-Uri passed to
  • every UPnP service 210-21 1 that supports property change event notifications is to be a GENA client. Therefore, when the UPnP
  • RegisterUpnpEventSourceO takes a URL and an array of properties as parameters. Inside the API, an entry in an array of structures is initialized and the index is returned as the handle. The structure contains the source URL as one of the members. A second member of the structure, an array of destination URLs, is left uninitialized. This is filled in each time as subscriber is added for that event source. Another member of the structure is the list of properties that this event source provides. This is effectively a cached copy of the DST for the event source. As events are submitted, the local properties are updated.
  • each property submitted replaces the corresponding property already maintained by the API. If no subscribers exist, the request to submit an event is ignored. If one or more subscribers exist, their callback URLs are looked up in the list of subscribers for the given event source and a NOTIFY message is constructed and sent to each URL, one at a time, in order of subscription. If an event is submitted and no response is received (or a CD-side error occurs), the CD continues to attempt to send to the UCP. If the subscription timeout expires, then the subscription is removed. If the UCP becomes available again, it will re-subscribe because it will notice the sequence numbers are not contiguous.
  • HTTP server 626 When an HTTP server 626 receives a SUBSCRIBE message, it passes it along to a function which parses the message for the necessary information.
  • the Request-URI identifies the UPnP Service that is to be subscribed to.
  • the callback URL is obtained from the "Callback" header.
  • the HTTP server should return "404 Not Found".
  • the local copy of the DST is sent as a
  • This special NOTIFY message contains sequence number 0 which informs the UCP that this is an initial state population event and not a notification where every event has changed.
  • a CD When a CD receives an UNSUBSCRIBE message, it checks the "SID" header to obtain the subscription identifier. It looks up the subscriber ID in the list of subscribers for that event source and removes the destination URL entry associated with it.
  • GENA servers 630 are generally going to be UPnP UCPs.
  • a GENA server is anything that receives and processes NOTIFY messages to handle notifications from resources and sends SUBSCRIBE and UNSUBSCRIBE messages to receive notifications from resources.
  • These APIs leverage the already existing SSDP APIs. The following are the changes to the APIs:
  • the RegisterNotificationO allows a UPnP UCP to request notification when an event occurs for a given UPnP service.
  • the prototype is as follows:
  • Nt An enumeration that determines the type of notification requested. The values are: SSDP ALIVE - a UPnP Service has become available, and SSDP PROPCHANGE - a property has changed on the UPnP Service.
  • SzResourceType A null-terminated string specifying the resource type desired. For SSDP ALIVE, this is the service type, for SSDP PROPCHANGE this is unused.
  • SzEventUrl [in] A null-terminated string specifying the URL that a subscription request should be sent to.
  • FnCallback [in] A pointer to a function that will be called each time a notification is received. The function pointer is defined in the SSDP spec.
  • PContext [in] This parameter is included as a parameter when invoking the client-supplied callback function.
  • Return Value If the function succeeds, the return value is a handle used in a subsequent call to the DeregisterEventNotificationO function. If the function fails, the return value is INVALID HANDLE VALUE error code. To get extended error information, call GetLastError.
  • SSDP_D0NE 3
  • SSDP_PROPCHANGE 4
  • RegisterNotificationO When a UPnP UCP wishes to subscribe to notifications for a particular UPnP service, it calls the RegisterNotificationO API. It passes to this API a notification type that identifies the type of notification being requested, a URL to which a subscription should be sent, and a callback function and context for use when the notification is received. RegisterNotificationO will compose a SUBSCRIBE message, using the data passed in, and send that to the URL specified by the caller. The Callback header of the SUBSCRIBE message will be composed on the fly, as an arbitrary URL for notifications to be sent to for this subscription. This callback URL will likely be a constant since the server API will always know how to handle requests sent to this URL. It will then send the SUBSCRIBE message and await a response.
  • RegisterNotificationO in the SSDP API does not currently send HTTP requests, but it can be modified to do so. It also needs to await a response which it will also be modified to do so.
  • the Subscription-ID header contains a SID which is associated with the callback function specified by the caller.
  • the UCP should expect an initial NOTIFY message that contains the complete set of properties maintained by the CD. This becomes the local cached DST on the UCP side. From this point on, all modifications to the table are made via NOTIFY messages.
  • This initial NOTIFY message will have sequence number 0 that indicates it is an initial property set and not an update. The UCP can use this information in any way it sees fit. This ensures the UCP's state table is always in sync with the one on the CD.
  • each subscription request includes an arbitrary timeout value which indicates to the CD that the UCP will be re-subscribing every n seconds indicated in the timeout header of the subscription request. If the timeout expires on the CD, the subscription is removed. The UCP is required to re- subscribe before the timeout period has elapsed. If it fails to do so, the subscription will be terminated by the CD.
  • a re-subscribe message should be sent.
  • the re-subscribe message is similar to the subscribe message, but it does not contain an NT or Callback header. If the UCP is unable to re-subscribe within the timeout period, the subscription will be terminated by the CD. If the UCP sends a re-subscribe after the CD has terminated the subscription, the CD will return "412 Precondition Failed".
  • each event notification message will contain a 32-bit sequence number that starts at 0 and increments for each message sent to a subscriber. If a subscriber receives a notification with a sequence number that is not exactly one more than the previous notification, it will know that it has lost events and will ignore all future notifications until it receives one with sequence number 0 again. Events with sequence number 0 indicate that the event is an "initial state" event.
  • the UCP will send an UNSUBSCRIBE message, followed by a SUBSCRIBE message. This is not the same as a re-subscription because re-subscriptions do not cause the CD to start the sequence over at 0. In this case, the active unsubscribe/subscribe will cause the CD to restart the sequence at 0 and send the entire state table with the first notification message.
  • This example of a GENA SUBSCRIBE request and response demonstrates a subscription to event notifications for "servicel .”
  • the host is "vcr.local.” All notifications for this UPnP Service will be sent to the callback URL http: //remotel .local:923/upnp.
  • the "Subscription-ID" header provides the subscriber with an identifier to use when it wants to unsubscribe to this resource.
  • the "Timeout" header indicates that the subscriber will send a re-subscription request before 10 minutes have elapsed. If the device does not receive this request within that period of time, it will remove the subscription.
  • the response would be as follows:: HTTP/1. 1 200 O . K.
  • the NT and Callback headers are absent, but the SID header exists. This tells the CD 106 which subscription is being renewed and restarts the timeout. When the CD receives this message, it will persist the subscriptions to disk (or other persistent data storage medium), updating the absolute timeout based on the current time and a new timeout sent by the UCP (if it was different).
  • a property named "foo” is of type “string” and has a value of "goodbye” and a property named “bar” has a type of "integer” and has a value of 27.
  • the XML will be contains a list of multiple properties that have changed, along with a count to make it easy to determine this.
  • UNSUBSCRIBE service it will form an UNSUBSCRIBE message of the following format: UNSUBSCRIBE servicel HTTP/1.1 Host: vcr. local: 200 SID: uuid:kj9d4fae-7dec-lld0-a765-00a0c91e6bf ⁇
  • the response would be as follows:: HTTP/1.1 200 O.k.
  • a UPnP device called “vcr” initializes. a. It sets itself up to be an HTTP server by doing the following: i. It binds to a TCP socket using its IP address and an arbitrary port number. This address/port pair will be referenced by all incoming URL requests. ii. It listens for incoming connection requests on that socket and sets itself up to accept any incoming connections. b. It sets itself up to be an HTTP client by doing the following: i. Calls InternetOpenO to get a handle to the internet session c. For each UPnP Service it exposes, it does the following: i. It calls the SSDP API RegisterUpnpEventSourceO to let the SSDP server know that it will be accepting subscriptions and sending event notifications.
  • RegisterUpnpEventSourceO sends no network traffic on the wire. It is a local initialization only. RegisterUpnpEventSourceO does the following:
  • a UPnP UCP initializes. a. It initializes its HTTP server, passively listening on a TCP port. b. If the UCP started up before the UPnP device initialized, it won't see any services become available. When the device finally starts, the UCP will be notified, c. Once the UPnP services have been announced the UCP will be able to access one or more of them. d. The UCP drives the UPnP API to instantiate a UPnP Service Object, e. The UPnP Service Object does the following when it is instantiated: i. It obtains the event subscription URL from the description for that service. ii. It calls the SSDP API RegisterNotificationO specifying
  • SSDP PROPCHANGE as the event type, the event subscription URL, a callback function pointer (which is a static member function of the class), and a context pointer (which is the "this" pointer of the class).
  • RegisterNotificationO does the following:
  • RegisterNotificationO will call InternetOpenO to get a handle to an internet session. This handle is shared among all local UPnP UCPs. 3. It calls IntemetConnectO passing the server name given in the URL it was passed.
  • Callback header of the SUBSCRIBE message will be composed on the fly, as an arbitrary URL for notifications to be sent to for this subscription.
  • the server name is the local IP address, and the port is the same one referred to by step 2a above.
  • CD This is a synchronous function that will return when the request has been responded to by the CD.
  • a timer is started for re-subscription based on the 25 timeout value returned in the response. When the timer goes off, the re-subscription will be sent. 1 1 .
  • the SID, callback function pointer, and timeout values are stored in a structure that maintains the list of local subscriptions. 3.
  • the subscription request is received by the HTTP server. The following occurs: a. The request is parsed into URI, NT, Callback, and Timeout fields. b. The NT field must match "upnp.-event”. If it doesn't, the CD responds with "412 Precondition Failed.” c.
  • the URI identifies the event source. The URI is converted into a URL and matched with the list of event sources registered on the
  • the Callback URL is added to a list of subscriber URLs, ii.
  • the Timeout value is processed and an absolute time is stored with the event source data. If this time expires and a re- subscribe message has not been received, the subscription is removed, iii. A new SID is created, and stored with the subscriber in the event source. iv. A sequence number is initialized to 0. v.
  • a subscription response is composed, including an echo of the
  • Timeout header and the SID just created vi.
  • the response is sent.
  • vii. If the response is sent successfully, the list of event sources is persisted to disk for recovery purposes.
  • viii. A timer is started using the same timeout value as the header echoed to the UCP. When this timer elapses, the subscription is removed. If the CD receives a re-subscribe request, this timer will be reset. In an ideal world, the timer will never elapse, ix.
  • An initial event notification is sent to initialize the UCP's state table. The following describes that process:
  • InternetOpenO is called if an existing internet session handle does not exist.
  • NTS header will always be "UPnP:propertychange”.
  • the SID header contains the SID stored in the event source structure c.
  • the Seq header will always be 0.
  • the Content-Length header will be the number of bytes in the XML body.
  • the Content-Type header will always be "text/xml”.
  • the body of the message is composed from the list of properties stored within the event source structure: i. Write the ⁇ propertyset> opening tag. ii. Write the ⁇ propc ⁇ unt>/7 ⁇ /propcount> tag.
  • n is the number of total properties, iii. For each property:
  • the response is ignored except for debugging purposes. 4.
  • the UPnP CD now is ready to send an event notification. It does this by calling the SubmitUpnpPropertyEventO API. The following occurs inside that API: a. The event source handle is converted to an event source structure. b. The properties that have changed as a result of the event are passed into the function and updated in the local list of properties stored with the event source. c. For each subscriber, the following occurs: i. IntemetConnectO is called, passing the server name specified in the callback URL for this subscription. ii. HttpOpenRequestO is called, passing in the rest of the callback
  • a NOTIFY message is composed, using the data passed in, by calling HttpAddRequestHeadersO. It adds the "NT”, “NTS”, “SID”, “Seq”, "Content-Length”, and "Content-Type” headers.
  • the NT header will always be "upnp:event”.
  • the NTS header will always be "UPnP:propertychange”.
  • the SID header contains the SID stored in the event source structure 3.
  • the sequence number for the event source is incremented and the Seq header is created with this value.
  • the Content-Length header will be the number of bytes in the XML body. 5.
  • the Content-Type header will always be "text/xml”.
  • the body of the message is composed from the list of properties stored within the event source structure: a. Write the ⁇ propertyset> opening tag. b. Write the ⁇ propcount>r/ ⁇ /propcount> tag. Where n is the number of total properties. c.For each property that has been submitted: i. Write the ⁇ property> opening tag. ii. Write the ⁇ prop> opening tag, where prop is the name of the property. iii. Write the ⁇ type > type ⁇ /type > tag, where type is the stringized type name of the property type. iv. Write the property value, v. Write the ⁇ lprop> closing tag. vi. Write the ⁇ /property> closing tag d.
  • SubmitEventO does the following:
  • HttpSendRequestExO It calls HttpSendRequestExO, then InternetWriteFileO on the body, then HttpEndRequestO to send the request to the CD.
  • the UPnP UCP receives the notification message.
  • the message is processed as follows: a.
  • the HTTP server receives a NOTIFY message with a Request-URI and several other headers, b.
  • the NOTIFY message is parsed, looking at the "NT" header first. If this header contains "upnp:event", then the message is further processed for event notifications as follows: i.
  • the message is parsed for the NTS header. If that contains
  • the message is parsed for the SID header.
  • the SID indicates to the UPnP control point which subscription this message applies to.
  • the message is parsed for the "Seq" header. If this header contains a value of 0, the UCP knows this is an initial state populate request. If the local sequence number is exactly one less than the Seq header, the local sequence number. is updated (incremented), and the message is processed further. 5 3.
  • the Request-URI can be ignored, since the HTTP server knows all NOTIFY messages with an NT header of "upnp:event" are sent to the same Request-URI.
  • the SID is matched against the list of subscriptions maintained on the UCP. When the SID is matched, its
  • the callback function is passed an SSDP MESSAGE structure which contains all the relevant headers and the body of the XML message received.
  • the callback function is implemented by the UPnP API, 20 as a static member of the Service object. When this function is called, the following occurs: a. The body of the message is parsed using the XML
  • DOM services b. As properties are enumerated, their values are 25 stored in the local state table for the UPnP Service. c.An event is fired to all high-level clients of the UPnP API. This event contains the list of properties that have changed and their new values. 6.
  • the re-subscription timer for one of the UCPs subscriptions expires. The following occurs: a. A re-subscribe message is composed. This message is very similar to a subscribe message except in doesn't include an NT or Callback header, but it does have a SID header. b. The request is sent to the CD. c. The response contains the new timeout value, d. The timer is reset with this timeout.
  • This method begins with the CD sending its initial state to the subscriber the first time an event is submitted by the UPnP Service.
  • UCPs will subscribe to the UPnP Service first, then receive notifications for events as they occur. The first event will happen to be the initial state of the UPnP Service.
  • the UCP state table will always be in sync with this method.
  • the CD sends a notification to a subscriber and receives an error. In this case, it marks the subscriber as "NeedsSync" and the next time an event is submitted, all events are sent to the subscriber.
  • the problem with this is that the API needs to keep track of which subscribers need syncing and which ones don't.
  • the client of this API (the UPnP service) would need to send separate messages to each subscriber and know which ones needed all events and which ones just wanted the ones that changed.
  • This method states that the UCP should subscribe to event notifications, then call a function that obtained the state from the UPnP
  • UCP may receive events that are newer but when it queries for the state, it gets an older view of the table. This requires using sequence numbers to determine which information is newer. If the view of the table received by the query is too old, it has to be discarded. Alternatively, the properties that were not received by event notification would not be overwritten, but all other properties would be. Using sequence numbers make this more complicated.
  • This conventional computer 820 (such as personal computers, laptops, palmtops or handheld-PCs, set- tops, servers, mainframes, and other variety computers) includes a processing unit 821 , a system memory 822, and a system bus 823 that couples various system components including the system memory to the processing unit 821.
  • the processing unit may be any of various commercially available processors, including Intel x86, Pentium and compatible microprocessors from Intel and others, including Cyrix, AMD and Nexgen; Alpha from Digital; MIPS from MIPS Technology, NEC, IDT, Siemens, and others; and the PowerPC from IBM and Motorola. Dual microprocessors and other multi-processor architectures also can be used as the processing unit 821 .
  • the system bus may be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of conventional bus architectures such as PCI, VESA, AGP, MicroChannel, ISA and EISA, to name a few.
  • the system memory includes read only memory (ROM) 824 and random access memory (RAM) 825.
  • ROM read only memory
  • RAM random access memory
  • BIOS basic input/output system
  • BIOS basic routines that help to transfer information between elements within the computer 820, such as during start-up, is stored in ROM 824.
  • the computer 820 further includes a hard disk drive 827, a magnetic disk drive 828, e.g., to read from or write to a removable disk 829, and an optical disk drive 830, e.g., for reading a CD-ROM disk 831 or to read from or write to other optical media.
  • the hard disk drive 827, magnetic disk drive 828, and optical disk drive 830 are connected to the system bus 823 by a hard disk drive interface 832, a magnetic disk drive interface 833, and an optical drive interface 834, respectively.
  • the drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, etc. for the computer 820.
  • a number of program modules may be stored in the drives and RAM 825, including an operating system 835, one or more application programs 836, other program modules 837, and program data 838.
  • a user may enter commands and information into the computer 820 through a keyboard 840 and pointing device, such as a mouse 842.
  • Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
  • These and other input devices are often connected to the processing unit 821 through a serial port interface 846 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB).
  • a monitor 847 or other type of display device is also connected to the system bus 823 via an interface, such as a video adapter 848.
  • computers typically include other peripheral output devices (not shown), such as speakers and printers.
  • the computer 820 operates in a networked environment using logical connections to one or more remote computers, such as a remote computer 849.
  • the remote computer 849 may be a server, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 820, although only a memory storage device 850 has been illustrated in Figure 23.
  • the logical connections depicted in Figure 23 include a local area network (LAN) 851 and a wide area network (WAN) 852.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
  • the computer 820 When used in a LAN networking environment, the computer 820 is connected to the local network 851 through a network interface or adapter
  • the computer 820 When used in a WAN networking environment, the computer 820 typically includes a modem 854 or other means for establishing communications (e.g., via the LAN 851 and a gateway or proxy server 855) over the wide area network 852, such as the Internet.
  • the modem 854 or other means for establishing communications (e.g., via the LAN 851 and a gateway or proxy server 855) over the wide area network 852, such as the Internet.
  • the present invention is described below with reference to acts and symbolic representations of operations that are performed by the computer 820, unless indicated otherwise. Such acts and operations are sometimes referred to as being computer-executed. It will be appreciated that the acts and symbolically represented operations include the manipulation by the processing unit 821 of electrical signals representing data bits which causes a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in the memory system (including the system memory 822, hard drive 827, floppy disks 829, and CD-ROM 831 ) to thereby reconfigure or otherwise alter the computer system's operation, as well as other processing of signals.
  • the memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, or optical properties corresponding to the data bits.
  • FIGS 24 and 25 are intended to provide a brief, general description of a suitable embedded computing device 900 which may be used in the illustrated implementation of the invention.
  • the embedded computing device 900 can be any variety of device incorporating electronics to control operational functions (operational circuitry 906), and in which computing and networking capabilities are embedded.
  • devices in which computing and networking functions can be embedded include communications devices (e.g., telephones, cell phones, audio and video conferencing systems, 2-way radios, etc.), office equipment (printers, fax machines, copiers, dictation, etc.), audio-video equipment (audio and video recorders and players, including televisions, radio receivers, compact disk (CD), digital video disk (DVD), camcorders, etc.), entertainment devices (set-top boxes, game consoles, etc.), environment control equipment
  • communications devices e.g., telephones, cell phones, audio and video conferencing systems, 2-way radios, etc.
  • office equipment printers, fax machines, copiers, dictation, etc.
  • audio-video equipment audio and video recorders and players, including televisions, radio receivers, compact disk (CD), digital video disk (DVD), camcorders, etc.
  • entertainment devices set-top boxes, game consoles, etc.
  • thermostats thermostats, heating/ventilation/air-conditioning equipment, light switches, etc.
  • security systems home appliances (coffee makers, dishwashers, clothes washer/dryer), automobiles, public facilities equipment (signs, traffic signals, etc.), manufacturing equipment, and many others.
  • the device 900 includes a processing unit 902, and a memory 904 to provide embedded computing capability.
  • the processing unit 902 has hardware interfaces to the operational circuitry 906 that operates devices functions.
  • the processing unit 902 can be a microprocessor or micro-controller, such as are available from Intel, Motorola, IBM, and others.
  • the memory 904 preferably incorporates RAM and ROM to hold software and data for basic operating code as well as for user applications.
  • the device 900 also includes a network adapter 908 for connecting with a network media 910 that is interconnected with the computer network in which the authoritative names registry (described below) is implemented in accordance with the invention.
  • the network adapter 908 can be a network interface card (or chip set integrated on a single board with the processing unit 902) appropriate to the particular network media 910.
  • the network media can be any of various wired or wireless network media, including Ethernet, IEEE 1394 (a.k.a. firewire), radio frequency (including satellite, cell, pager, commercial signal sideband, etc.), power line carrier (PLC), phone line, and television cable, among others.
  • the embedded computing device 100 has a software architecture 120 that conforms to the above described UPnP device control model.
  • UPnP provides a mechanism for the embedded computing device to operate in the Internet, as well as networks that have no administrator and no connection to the Internet, and hence no access to configuration services like the Dynamic Host Configuration Protocol (DHCP).
  • DHCP is a mechanism for providing devices with configuration information needed to access the Internet. The mechanism functions through the use of a multicast request for configuration information that is generally responded to with an IP address and DNS server location. Additional information can only be returned in the response.
  • UPnP uses the AutolP protocol
  • AutolP is an enhancement to DHCP that allows devices to claim IP addresses in the absence of a DHCP server or similar IP configuration authority
  • IP addresses are claimed from a reserved range that is not allowed to be transmitted on the open Internet; thus they are only good for the local network.
  • the embedded computing device 100 claims an address by randomly generating an address in the reserved range and then making an ARP request to see if anyone else has already claimed that address.
  • AutolP systems will continually check for the presence of a DHCP server so that if one should ever come online, all the AutolP devices will attempt to switch their IP addresses to one provided by the DHCP server. This allows a network to operate in isolation, be connected to the Internet with DHCP support and then to be returned to isolation. This type of scenario will be common in homes that use dial-up access.
  • UPnP implements a peer discovery mechanism that uses the Simple
  • SSDP Service Discovery Protocol
  • a single identifier specifies a profile that defines a contract between the client and UPnP Service (e.g., operational functions provided by the embedded computing device). By identifying itself with the profile, the UPnP Service advertises compliance with the associated contract. Using a single identifier makes it possible to implement an extremely simple discovery system.
  • Clients send out a User Datagram Protocol (UDP) multicast packet containing the identifier of the desired UPnP Service on some standard channel.
  • UDP Services listen on the standard channel, read the request, see whether they provide the UPnP Service, and respond if so.
  • UPnP also provides a Directories mechanism to allow discovery to scale - to the entire Internet if needed. When present, a directory will read all incoming service requests and respond to them itself. This requires that all UPnP Services (e.g., the embedded computing device 900) register with the directory so that the directory is able to properly answer on their behalf.
  • the directory is also responsible for communicating with other directories in order to determine whether the UPnP Service is available within the local network, the WAN and potentially the Internet. To simplify the discovery protocol, directories are treated as proxies.
  • a proxy is a service that accepts requests and takes responsibility for finding the proper response. When a client comes online, it will perform discovery for the proxy. If the proxy is present, then the client will send all future discovery requests to the proxy. If the proxy isn't present, then the client will send all discovery requests to the reserved discovery multicast channel. Regardless of the presence of a proxy, the client's request format and procedures will always be the same. The only difference will be the address to which the client sends its requests. For UPnP Services, the difference between a proxied and unproxied network is their need to answer discovery requests. On a proxied network, UPnP Services need do nothing once they have registered with the proxy. On an unproxied network, they answer discovery requests directly.
  • SSDP uses the UDP- and Transmission Control Protocol (TCP)-based Hyptertext Transport Protocol (HTTP) to provide for service discovery.
  • TCP Transmission Control Protocol
  • HTTP Hyptertext Transport Protocol
  • SSDP uses a Uniform Resource Identifier (URI) to represent the service and the OPTIONS method to provide for discovery.
  • SSDP also will provide support for proxies. These proxies, which are really just fronts for directories, redirect discovery requests to themselves. It is the proxy's job to collect announce requests in order to determine what UPnP Services are available as well as to communicate with other proxies in order to provide for scalable service discovery.
  • the discovery process returns only the basic information needed to connect to the embedded computing device. Once a UPnP Service has discovered its peers, the UPnP Service often needs to find out more information in order to work best with them.
  • a schema is a structured data definition that defines a set of structured values that provide descriptive information about a UPnP Service.
  • UPnP uses the Extensible Markup Language (XML) for schema, because XML's self-describing structured data format provides the level of expressiveness and extensibility needed by a universal schema and data format.
  • XML Extensible Markup Language
  • UPnP supports automatic network introduction, meaning that devices and their related UPnP Services have the ability to be self-describing and allow automatic configuration.
  • the device When a device is plugged into the computer network, the device automatically configures itself and acquires a TCP/IP address. The device then announces its presence to other devices already on the network using a simple discovery protocol based on the Internet HTTP protocol and is immediately ready to share its UPnP Services with any device that requests them.
  • UPnP Devices support automatic discovery, identification, and configuration to achieve interoperability in the home environment, but must also operate correctly in a managed corporate network. Devices can be networked instead of being attached directly to a PC, and devices are all autonomous citizens on the network, able to talk with each other and exchange information. UPnP provides a unified way of performing directory services with automatic configuration. Capability for simple discovery mechanism used in the home environment provides the ability for any device to become a node on the global Internet. Additionally, directory services can be leveraged if they are available in the corporate environment. UPnP provides a common set of interfaces for accessing devices and
  • the software architecture 920 of the embedded computing device 900 includes the following software code modules that implement UPnP: device functions 922, simple discovery 924, Hypertext Transport Protocol (HTTP) 925, Transmission Control Protocol/Internet Protocol (TCP/IP) stack 926, Dynamic Host Configuration Protocol (DHCP) with AutolP extension 928, Domain Name System (DNS) with Multicast DNS extension 930, and physical media 910 (also shown in Figure 24).
  • the device functions 922 is a software code module to implement the device's functionality.
  • the embedded computing device is a VCR
  • the device functions code can include code to implement start, stop, pause, record and other functions that the VCR can perform.
  • the simple discovery 924 is a software code module (about 4 Kbytes) that implements a simple discovery procedure (described below) for automatic network introduction under the UPnP protocol.
  • the simple discovery procedure additionally provides an Extensible Markup Language (XML) format device description, which is downloaded to clients that access the device to allow activation of device functionality from the client.
  • XML is a textual, tag-based markup language. It was originally designed to be the "Webby" simplification of SGML (Standard Generalized Markup Language), and is therefore intended to be used to create "vocabularies" of tags that can be used to apply semantic markup to documents, such as who the author was, what constitutes a paragraph (semantically, not from a display point of view), when the author last had breakfast, and so on.
  • XML is used to provide the description of UPnP Services and capabilities of the embedded computing device.
  • the embedded computing device makes its features visible to clients by providing its XML device description, which the client can use to activate device functions 922. For example, if the device is a camera, the client's browser can direct the camera to zoom in/out or adjust contrast using the mechanism of XML.
  • the XML device description can provide links (via a uniform resource locator or URL address) to an accompanying XSL format style sheet.
  • the XSL style sheets are used to present the data in different ways, i.e., the style sheets are applied to present different views of the same data. For example, if the device contains a file system, one style sheet can show the file selections; another shows the file sizes in some sort of diagram; yet another style sheet could make thumbnails of these image files.
  • the HTTP 925 is a software code modules (about 20 Kbytes) that implements the standard HTTP protocol, which is an open standard mechanism for client/server message-based communication. HTTP provides for proxying, content negotiation and security. (For more information, see R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners- Lee, Hypertext Transfer Protocol - HTTP/1.1 , IETF RFC 2068 (January 1997).)
  • the TCP/IP stack 926 implements the standard TCP/IP networking protocols for communication on the computer network.
  • the Internet
  • IP Internet Protocol
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • IGMP Internet Group Management Protocol
  • the AutolP 928 is a software code module also used for automatic network introduction via AutolP in the UPnP protocol.
  • AutolP uses a predefined set of IP addresses and, when a device is connected to the network, it pings an address in this address space. If it gets no replies, the device assumes that the address is available and assigns it to itself.
  • An IP Multicast is a mechanism for sending a single message to multiple recipients. IP multicasting is especially useful for discovery operations where one does not know exactly who has the information one seeks. In such cases, one can send a request to a reserved IP multicast address. Any UPnP Services that can provide the requested information will also subscribe to the multicast request and thus be able to hear the information request and properly respond.
  • the DHCP 930 is a software code module that implements the
  • DHCP Dynamic Host Configuration Protocol
  • FIGS 26 and 27 show processes 934, 940 per the UPnP protocol for automatic network introduction of the embedded computing device 900 ( Figure 24) into an ad hoc (where the device does not have a configured IP address) and a configured computer network environment, respectively.
  • the automatic network introduction process establishes an appropriate configuration (e.g., with an IP address) of the embedded computing device upon connection to a server computer on a computer network, so as to enable access to the device from a client.
  • the processes 934, 940 involve five phases: AutolP, announce, discovery, response to discovery, and device description.
  • the embedded computing device 900 sends out a small multicast packet so that other devices can find it on the network.
  • the multicast message packet essentially says, "I am here, I am, (say), a camera, and you can reach me at this IP address or URL.”
  • the embedded computing device 900 listens for a discovery packet coming from a simple discovery client, i.e., the device announces itself, then listens for discovery.
  • the discovery packet also is sent out by multicast.
  • the embedded computing device 900 listens to the multicast address and then parses the information from a Simple Discovery request to decide if the request is for its kind of device. If so, the device 100 then sends back a response packet containing the following information: the IP address or URL where it can be reached; identification of its own device type; and the discovery packet ID so the requesting client knows which request is being answered.
  • the AutolP module 928 of the embedded computing device 900 uses a predefined set of IP addresses and, when the device is connected to the network, it pings an address in this address space. If no reply is received, the device 900 assumes that the address is available and assigns it to itself. Both the Announce and Discovery packets also contain a link or a
  • XML XML
  • This XML data contains all the facts about the device.
  • XML can also have URLs that point to appropriate style sheets (XSL files) that are used for optimal presentation.
  • the XSL style sheets are used to present the data in different ways, i.e., the style sheets are applied to present different views of the same data. For example, if the device contains a file system, one style sheet can show the file selections; another shows the file sizes in some sort of diagram; yet another style sheet could make thumbnails of these image files.
  • a client that accesses and uses the embedded computing device 900 over the computer network has an exemplary client software architecture 950, which includes software code modules for applications 952, simple discovery 954, XML 955, LDAP 956, TCP/IP stack 958 and a network interface card (NIC) 960 that provides a physical connection to the computer network.
  • the applications 952 is a software code module that provides a user interface features for locating desired devices (e.g., embedded computing device 900) and UPnP Services on the computer network, and also user interface features to interact with the located device or UPnP Service.
  • the applications 952 can include an Internet browser, such as the Microsoft Internet Explorer, that can present the XML device description in accordance with an associated XSL style sheet for interaction with the embedded computing device and activation of its operational functionality.
  • the simple discovery 954 is a module that implements the above- described simple discovery per the UPnP protocol.
  • the XML 955 is a module that processes the XML device description and XSL style sheets for presentation in the application's user interface.
  • the LDAP 956 implements the standard LDAP directory protocol for name look-up.
  • the TCP/IP stack 958 implements the TCP/IP protocol for communications over the computer network.
  • FIG 29 illustrates a pervasive computing environment 1000, such as may be installed in a home, office or public place, which includes a large number of embedded computing devices, such as the illustrated device 900 ( Figure 24).
  • the pervasive computing environment 1000 includes personal computers 1002, 1004 (e.g., of the type shown in Figure 23) connected via a local area network (LAN) 1006.
  • the PC 1002 is connected via a universal serial bus 1016 to a telephone modem 1010, XDSL interface 101 1 or a cable modem 1012, which in turn provide a connection with the computer network, e.g., the Internet.
  • Various embedded computing devices also connect to the computer network via various network connections to the PCs 1002, 1004. These include an audio device 1014 (e.g., speakers, radio tuner, microphone), and printer 1015 which connect to the PC 1004 through a USB 1017. Also, a digital camera 1020, a handheld PC (H/PC) 1021 and another personal computing device 1022 connect via an infrared port (IRDA) 1024, which also attaches to the PC 1004 through the USB 1017. Also, lighting switches 1030 and like home appliances are connected via an A/C power line-based networking 1032 to the PC 1002.
  • IRDA infrared port
  • a chain of IEEE 1394 cables 1048 connect a digital TV 1040, DVD player 1041 , digital video camcorder (DV/DVC) 1042, an audio device 1043 (e.g., CD player/recorder, radio receiver, amplifier, and like audio system component), and a game console 1044.
  • Devices such as a portable telephone 1050 and remote control 1051 , have a radio frequency network connection with the PC 1004.
  • the embedded computing devices are "visible” and accessible from a client device 950 ( Figure 29) also connected to the computer network.
  • an instance of the UPnP bridge 120 ( Figure 2) is automatically installed and configured for a peripheral device by operating system software of a host computing platform in accordance with a process 1 100 upon attaching or connecting the peripheral to the host.
  • this UPnP Bridge self-install and configure process 1 100 is implemented as an enhancement of the plug-and-play process of the Microsoft Windows operating system running on a personal computer. As per the conventional plug-and-play feature of the Microsoft
  • the host computer's operating system detects at action 1 102 as part of it boot-up routine that any new peripheral devices have been attached to a peripheral device bus (e.g., the ISA, EISA, PCI, USB, serial or parallel ports, etc.) of the host computer.
  • a peripheral device bus e.g., the ISA, EISA, PCI, USB, serial or parallel ports, etc.
  • this detecting of new peripheral devices can be done at any time during normal operation of the host computer so as to detect "hot-plugging" peripheral devices that can be attached to the host computer while running.
  • the host computer's operating system proceeds to identify and install an appropriate device driver software for the host operating system to interact with and/or control the peripheral device as indicated at action 1 103.
  • the operating system prompts the user to insert a disk or like storage medium containing the device driver.
  • the operating system can download the device driver from a server computer on a network. If unable to identify the appropriate device driver for the new peripheral, the operating system prompts the user to select or provide the device driver (e.g., from a disk provided by the peripheral manufacturer).
  • the enhanced plug-and-play feature of the operating system additionally automatically installs an instance of a UPnP Bridge 120 ( Figure 2) on the host computer at action 1 104 for use in adapting the peripheral for peer networking connectivity via the UPnP device control model over any networks connected to the host computer.
  • the operating system configures this UPnP Bridge instance to expose the operational functions of the peripheral with an appropriate XML discovery and description data.
  • any UPnP User Control Point thereafter can obtain the XML discovery and description data from the UPnP Bridge, and interact through the UPnP Bridge with the peripheral device as specified by the XML data.
  • the operating system can prompt the user to select and/or provide such from a peripheral manufacturer-provided disk or download.
  • the host's operating system then continues to repeat the actions 1 102-1 104 for any other new peripheral devices that have been attached to the host computer.
  • this self-install and configuring of a peer networking-to-host/peripheral adapter also can be implemented on various other host/peripheral computing platforms (such as in a video game consoles, television set-top boxes, audio-video consoles, etc., which are structured as host computers which are extensible by connecting peripheral devices) so as to automatically provide peer networking upon attaching a new peripheral to such computing platforms.
  • host/peripheral computing platforms such as in a video game consoles, television set-top boxes, audio-video consoles, etc., which are structured as host computers which are extensible by connecting peripheral devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un adaptateur de connectivité de réseau homologue avec des services de système d'exploitation (OS) exposant des services de système d'exploitation universel à une commande à distance via un protocole de commande de dispositif de réseau homologue, qui permet de réutiliser les services du système d'exploitation sans les reprogrammer sous forme de dispositif télécommandé par le protocole de commande de dispositif de réseau homologue. L'adapteur comprend un service de publication qui met en oeuvre des composants d'un service commandé et fonctionne de façon à émuler un ensemble de dispositifs commandés présentant la fonctionnalité des services OS. Une commande de services à distance effectue une conversion entre une interface de programmation d'application (API) de publication du service de publication et l'API du système d'exploitation établi des services OS.
PCT/US2000/017844 2000-06-28 2000-06-28 Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau WO2002001833A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2000/017844 WO2002001833A1 (fr) 2000-06-28 2000-06-28 Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau
AU2000256423A AU2000256423A1 (en) 2000-06-28 2000-06-28 Remoting general purpose operating system services via a peer networking device control protocol

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2000/017844 WO2002001833A1 (fr) 2000-06-28 2000-06-28 Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau

Publications (1)

Publication Number Publication Date
WO2002001833A1 true WO2002001833A1 (fr) 2002-01-03

Family

ID=21741544

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/017844 WO2002001833A1 (fr) 2000-06-28 2000-06-28 Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau

Country Status (2)

Country Link
AU (1) AU2000256423A1 (fr)
WO (1) WO2002001833A1 (fr)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2837045A1 (fr) * 2002-03-08 2003-09-12 Canon Res Ct France Sa SYSTEME ET PROCEDE DE GESTION DE TRANSFERT D'INFORMATIONS SUR UN RESEAU CONFORME A UNE NORME DE TRANSMISSION DE DONNEES, NOTAMMENT LA NORME UPnP, MACHINE D'INTERFACAGE ET D'EMULATION ET PROGRAMME D'ORDINATEUR CORRESPONDANTS
FR2844414A1 (fr) * 2002-09-05 2004-03-12 Canon Kk Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service.
FR2848051A1 (fr) * 2002-12-03 2004-06-04 Canon Res Ct France Sa PASSERELLE ET PROCEDE POUR L'INTERCONNEXION DE DEUX RESEAUX, NOTAMMENT UN RESEAU HAVI ET UN RESEAU UPnP
US6779004B1 (en) 1999-06-11 2004-08-17 Microsoft Corporation Auto-configuring of peripheral on host/peripheral computing platform with peer networking-to-host/peripheral adapter for peer networking connectivity
EP1484860A1 (fr) * 2003-06-06 2004-12-08 Microsoft Corporation Découverte automatique et configuration des dispositifs de réseau externes
WO2005001617A2 (fr) 2003-06-02 2005-01-06 Infocus Corporation Dispositif d'affichage d'image et procede de communication avec le dispositif d'affichage d'image sur un reseau
US6892230B1 (en) 1999-06-11 2005-05-10 Microsoft Corporation Dynamic self-configuration for ad hoc peer networking using mark-up language formated description messages
EP1585240A2 (fr) * 2004-03-26 2005-10-12 Harman International Industries, Incorporated Méthode et système pour la communication entre dispositifs relatifs au traitement de signaux sonores
EP1603047A1 (fr) * 2003-03-10 2005-12-07 Sony Corporation Dispositif et procede de traitement d'informations, et programme informatique
EP1665632A1 (fr) * 2003-09-23 2006-06-07 Lg Electronics Inc. Systeme de reproduction de contenus de medias a base upnp et procede associe
US7082200B2 (en) 2001-09-06 2006-07-25 Microsoft Corporation Establishing secure peer networking in trust webs on open networks using shared secret device key
DE102005011333A1 (de) * 2005-03-11 2006-09-14 Deutsche Thomson-Brandt Gmbh Verfahren zum Übertragen von Daten in einem Netzwerk verteilter Stationen sowie Netzwerkstation
EP2062391A1 (fr) * 2006-08-25 2009-05-27 Samsung Electronics Co., Ltd. Appareil et procédé permettant de mettre en correspondance des protocoles de contenus audio/vidéo intégrés
US7676562B2 (en) 2004-01-20 2010-03-09 Microsoft Corporation Computer system for accessing instrumentation information
US7865622B2 (en) 2003-01-23 2011-01-04 Thomson Licensing Updating parameters in a bridged multistandard home network
US7870495B2 (en) 2003-03-03 2011-01-11 Canon Kabushiki Kaisha Method of offering a service provided by a server computer in a communication network
US8014768B2 (en) 2003-04-30 2011-09-06 Disney Enterprises, Inc. Mobile phone multimedia controller
US8051188B2 (en) 2002-09-05 2011-11-01 Canon Kabushiki Kaisha Method of proposing a service via a description document of such a service
EP2538617A1 (fr) * 2010-05-18 2012-12-26 ZTE Corporation Procédé et système permettant de réaliser une interaction entre un boîtier décodeur (stb) et une passerelle domestique
US8392601B2 (en) 2002-08-06 2013-03-05 Koninklijke Philips Electronics N.V. Network establishment and management protocol
US20150296182A1 (en) * 2014-04-14 2015-10-15 Wistron Corporation Method and system for providing video service

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5491800A (en) * 1993-12-20 1996-02-13 Taligent, Inc. Object-oriented remote procedure call networking system
WO1999035856A2 (fr) * 1998-01-06 1999-07-15 Sony Electronics, Inc. Reseau audio-video

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5491800A (en) * 1993-12-20 1996-02-13 Taligent, Inc. Object-oriented remote procedure call networking system
WO1999035856A2 (fr) * 1998-01-06 1999-07-15 Sony Electronics, Inc. Reseau audio-video

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"The HAVi Specification: Specification of the Home Audio/Video Interoperabilty (HAVi) Architecture", HAVI SPECIFICATION,XX,XX, 19 November 1998 (1998-11-19), pages 1 - 384, XP002116332 *
VERSION 1,0: "Home Plug & Play: CAL-based Interoperability for Home Systems", HOME PNP SPECIFICATION, 9 April 1998 (1998-04-09), pages 1 - 111, XP002162756 *

Cited By (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7558846B2 (en) 1999-06-11 2009-07-07 Microsoft Corporation Dynamic self-configuration for ad hoc peer networking
US7089307B2 (en) 1999-06-11 2006-08-08 Microsoft Corporation Synchronization of controlled device state using state table and eventing in data-driven remote device control model
US6779004B1 (en) 1999-06-11 2004-08-17 Microsoft Corporation Auto-configuring of peripheral on host/peripheral computing platform with peer networking-to-host/peripheral adapter for peer networking connectivity
US7602756B2 (en) 1999-06-11 2009-10-13 Microsoft Corporation Dynamic self-configuration for ad hoc peer networking
US6892230B1 (en) 1999-06-11 2005-05-10 Microsoft Corporation Dynamic self-configuration for ad hoc peer networking using mark-up language formated description messages
US7290132B2 (en) 2001-09-06 2007-10-30 Microsoft Corporation Establishing secure peer networking in trust webs on open networks using shared secret device key
US7082200B2 (en) 2001-09-06 2006-07-25 Microsoft Corporation Establishing secure peer networking in trust webs on open networks using shared secret device key
FR2837045A1 (fr) * 2002-03-08 2003-09-12 Canon Res Ct France Sa SYSTEME ET PROCEDE DE GESTION DE TRANSFERT D'INFORMATIONS SUR UN RESEAU CONFORME A UNE NORME DE TRANSMISSION DE DONNEES, NOTAMMENT LA NORME UPnP, MACHINE D'INTERFACAGE ET D'EMULATION ET PROGRAMME D'ORDINATEUR CORRESPONDANTS
US8874689B2 (en) 2002-08-06 2014-10-28 Koninklijke Philips N.V. Network establishment and management protocol
US8392601B2 (en) 2002-08-06 2013-03-05 Koninklijke Philips Electronics N.V. Network establishment and management protocol
US8051188B2 (en) 2002-09-05 2011-11-01 Canon Kabushiki Kaisha Method of proposing a service via a description document of such a service
FR2844414A1 (fr) * 2002-09-05 2004-03-12 Canon Kk Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service.
FR2848051A1 (fr) * 2002-12-03 2004-06-04 Canon Res Ct France Sa PASSERELLE ET PROCEDE POUR L'INTERCONNEXION DE DEUX RESEAUX, NOTAMMENT UN RESEAU HAVI ET UN RESEAU UPnP
US7865622B2 (en) 2003-01-23 2011-01-04 Thomson Licensing Updating parameters in a bridged multistandard home network
US7984191B2 (en) 2003-01-23 2011-07-19 Thomson Licensing Updating parameters in a bridged multistandard home network
US7870495B2 (en) 2003-03-03 2011-01-11 Canon Kabushiki Kaisha Method of offering a service provided by a server computer in a communication network
EP1603047A4 (fr) * 2003-03-10 2011-06-15 Sony Corp Dispositif et procede de traitement d'informations, et programme informatique
EP1603047A1 (fr) * 2003-03-10 2005-12-07 Sony Corporation Dispositif et procede de traitement d'informations, et programme informatique
US8014768B2 (en) 2003-04-30 2011-09-06 Disney Enterprises, Inc. Mobile phone multimedia controller
US8892087B2 (en) 2003-04-30 2014-11-18 Disney Enterprises, Inc. Cell phone multimedia controller
EP1636713A2 (fr) * 2003-06-02 2006-03-22 Infocus Corporation Dispositif d'affichage d'image et procede de communication avec le dispositif d'affichage d'image sur un reseau
EP1631882A2 (fr) * 2003-06-02 2006-03-08 Infocus Corporation Dispositif d'affichage d'images et procede pour en annoncer la presence sur un reseau
WO2005001617A2 (fr) 2003-06-02 2005-01-06 Infocus Corporation Dispositif d'affichage d'image et procede de communication avec le dispositif d'affichage d'image sur un reseau
US8429227B2 (en) 2003-06-02 2013-04-23 Seiko Epson Corporation Image display device and method of announcing a presence of an image display device over a network
EP1636713A4 (fr) * 2003-06-02 2011-10-05 Seiko Epson Corp Dispositif d'affichage d'image et procede de communication avec le dispositif d'affichage d'image sur un reseau
EP1631882A4 (fr) * 2003-06-02 2011-10-05 Seiko Epson Corp Dispositif d'affichage d'images et procede pour en annoncer la presence sur un reseau
CN1574763B (zh) * 2003-06-06 2010-05-26 微软公司 外部网络装置的自动发现和配置方法
US7418486B2 (en) 2003-06-06 2008-08-26 Microsoft Corporation Automatic discovery and configuration of external network devices
EP1484860A1 (fr) * 2003-06-06 2004-12-08 Microsoft Corporation Découverte automatique et configuration des dispositifs de réseau externes
EP1665632A4 (fr) * 2003-09-23 2010-06-02 Lg Electronics Inc Systeme de reproduction de contenus de medias a base upnp et procede associe
EP1665632A1 (fr) * 2003-09-23 2006-06-07 Lg Electronics Inc. Systeme de reproduction de contenus de medias a base upnp et procede associe
EP1746777A2 (fr) 2003-09-23 2007-01-24 LG Electronics Inc. Système de reproduction de données de média basées sur UPnP et procédé correspondant
EP1746777A3 (fr) * 2003-09-23 2010-06-02 LG Electronics Inc. Système de reproduction de données de média basées sur UPnP et procédé correspondant
US7676562B2 (en) 2004-01-20 2010-03-09 Microsoft Corporation Computer system for accessing instrumentation information
EP1587230A2 (fr) * 2004-03-26 2005-10-19 Harman International Industries, Incorporated Système et méthode pour la gestion et le contrôle d'appareils liés au traitement de signaux audiophoniques
EP1585240A2 (fr) * 2004-03-26 2005-10-12 Harman International Industries, Incorporated Méthode et système pour la communication entre dispositifs relatifs au traitement de signaux sonores
US8473844B2 (en) 2004-03-26 2013-06-25 Harman International Industries, Incorporated Audio related system link management
EP1585240B1 (fr) * 2004-03-26 2024-02-21 Harman International Industries, Incorporated Méthode et système pour la communication dans un dispositif relatif au traitement de signaux audiophoniques
US8200777B2 (en) 2005-03-11 2012-06-12 Thomson Licensing Method for transmitting data in a network of distributed stations, and network station
DE102005011333A1 (de) * 2005-03-11 2006-09-14 Deutsche Thomson-Brandt Gmbh Verfahren zum Übertragen von Daten in einem Netzwerk verteilter Stationen sowie Netzwerkstation
EP2062391A4 (fr) * 2006-08-25 2013-06-12 Samsung Electronics Co Ltd Appareil et procédé permettant de mettre en correspondance des protocoles de contenus audio/vidéo intégrés
EP2062391A1 (fr) * 2006-08-25 2009-05-27 Samsung Electronics Co., Ltd. Appareil et procédé permettant de mettre en correspondance des protocoles de contenus audio/vidéo intégrés
EP3094046A1 (fr) * 2006-08-25 2016-11-16 Samsung Electronics Co., Ltd. Appareil et procédé permettant de mettre en correspondance des protocoles de contenus audio/vidéo intégrés
EP2538617A1 (fr) * 2010-05-18 2012-12-26 ZTE Corporation Procédé et système permettant de réaliser une interaction entre un boîtier décodeur (stb) et une passerelle domestique
EP2538617A4 (fr) * 2010-05-18 2014-01-08 Zte Corp Procédé et système permettant de réaliser une interaction entre un boîtier décodeur (stb) et une passerelle domestique
US20150296182A1 (en) * 2014-04-14 2015-10-15 Wistron Corporation Method and system for providing video service
US9350948B2 (en) 2014-04-14 2016-05-24 Wistron Corporation Method and system for providing video service

Also Published As

Publication number Publication date
AU2000256423A1 (en) 2002-01-08

Similar Documents

Publication Publication Date Title
US6779004B1 (en) Auto-configuring of peripheral on host/peripheral computing platform with peer networking-to-host/peripheral adapter for peer networking connectivity
US7130895B2 (en) XML-based language description for controlled devices
EP1188291B1 (fr) Modele de commande de dispositif distant guide par donnees, avec adaptateur general de messagerie entre interface de programmation et reseau
US6910068B2 (en) XML-based template language for devices and services
US7171475B2 (en) Peer networking host framework and hosting API
WO2002001833A1 (fr) Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau
US8423671B2 (en) Middleware device and method of supporting compatibility of devices in home network
EP1058422A1 (fr) Méthodes pour le pontage entre un sous-réseau de HAVi et un sous-réseau UPnP et le dispositif d'UPnP pour appliquer lesdites méthodes
US20050055352A1 (en) Content directory and synchronization bridge
US20040133896A1 (en) Network device application interface
JP2001290724A (ja) プラグアンドプレイ機能を有するフレームワークおよびその再構成方法
WO2002009350A2 (fr) Liaison par pont entre reseaux locaux multistandards avec serveur
Tranmanh et al. Implementation and Validation of UPnP for Embedded Systems in a Home Networking Environment.
Kristell et al. Interoperability between PalCom and external protocols
KR20050078547A (ko) 댁내에 설치되는 주거 게이트웨이의 재부팅을 원격으로제어하는 방법
Zeadally et al. PLUG AND PLAY ARCHITECTURES IN PROXIMITY NETWORKS
Fischer Service Discovery in Home Environments

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP