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/283—Processing of data at an internetworking point of a home automation network
  • H04L12/2832—Interconnection of the control functionalities between home networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/16—Arrangements for providing special services to substations
• • 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
• • 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/46—Interconnection of networks
  • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
  • H04L12/462—LAN interconnection over a bridge based backbone
• • 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

Definitions

• the invention relates to the bridging of multiple networks based on different software architectures.
• the invention relates in particular to home networking.
• a bridge serves to transparently represent a device, complying with a first standard in a network cluster of a first type, as a device complying with a second standard in a network cluster of a second type.
• the result is a single unified view of the home network available to software applications written for the first standard and as well those written for the second standard.
• a device on a network is controlled through a set of messages complying with the interface of the device. Interoperability between devices and software applications depends upon standard interfaces with a unique identification. Once an application knows the unique identification of the device, it knows the interface of the device and it can control the device by sending it messages. To the application it makes no difference whether it is sending standard messages directly to the device itself, or indirectly via a software component that translates these messages into a different set of message that (eventually) achieve the same desired effect or state change at the controlled device. Hence, a bridge between networks of multiple different standards can be considered a multi-standard device.
• the bridge complies with each of these multiple standards, and hosts software components that translate device interfaces from a first to a second standard and vice versa.
• a bridge is used between a cluster of five devices complying with a standard A and three devices complying with a standard B, different from A.
• the bridge hosts three translation modules for translating from A to B and five translation modules for translating from B to A. Accordingly, a software application capable of interacting with only standard A devices can now control all eight devices.
• software representation i.e., the representation in software of a physical device or of a service on a network or a sub-set thereof so as to make the device or service accessible to the relevant messaging or controlling software.
• a bridge performs the following functions: detection of the addition of a device in either of the bridged networks; identification of the type of the added device; locating the translation module for the identified device type if the device is likely to be of interest to the other network; and installing the translation module on the other network according to the procedure required by the standard used by that network.
• a bridge is unable to contain all embedded translation modules for all possible, relevant devices that become available in the future.
• the inventors propose a solution wherein a bridge is connected to a server, e.g., on the Internet.
• This server offers a lookup service for some set of standards, and allows a bridge to locate and download the appropriate translation modules for use in the home network.
• the invention relates to a method of providing a service to a user of a home network.
• the method comprises enabling a component of a first cluster in the network to interact with a second cluster of the home network.
• the first cluster has a first software architecture
• the second cluster has a second software architectures different from the first one.
• the first and second clusters are coupled through a bridge.
• the method comprises enabling a server external to the clusters, e.g., on the Internet, to receive a reference of a component having a first software representation in the first cluster.
• the bridge may provide this reference.
• the method further comprises enabling to provide to the bridge a translation module, associated with the reference, for at least partially representing the component on the second cluster upon the module being installed on the bridge.
• a service provider thus can maintain and update a data base of translation modules for any multiple standards being used in home networks. This partitioning and delegation of functionalities has many advantages as discussed below.
• the invention allows the bridge to be fairly "light-weight” or low-cost, as it does not need to have embedded translation modules for all possible devices of all standards that it could be connected to in the home. Storage and computation power is only needed for the devices that are actually bridged (i.e., storage is not needed for the ones that are potentially bridged), and only when they are bridged (e.g., "just-in-time”-bridging, i.e., at the time of connecting the new device to the network). Further, the invention renders the home network as a whole extensible and future-proof.
• the bridge-server operator is able to obtain information about the configuration of the individual user's home network. This information can be used to the advance of both the user and the manufacturers and service providers. See, for example, U.S. Serial No. 09/160,490 (attorney docket PHA 23,500) filed 9/25/1998 for Adrian Turner et al., for CUSTOMIZED UPGRADING OF INTERNET-ENABLED
• the server determines if the synergy of the apparatus present on the user's network can be enhanced based on the listing of the inventory and on the user's profile. If there are features that are relevant to the synergy, based on these criteria, the user gets notified. In this sense, U.S. serial no. 09/189,535 relates to the concept of an "application suggestor".
• a further advantage of the invention resides in the fact that the server operator is enabled to measure market demands for particular devices to be bridged to a specific standard. The device manufacturer or another relevant third party can be notified of the emerging demand. When the new translation modules become available on the server, bridges that have sent requests for translation modules in the past with which the server could not comply, can now be notified of an upgrade.
• the bridge can be implemented as a software component on a device of a specific cluster on the home network in order to provide a bridge to another cluster.
• a HAVi set top box can have a software component for bridging the HAVi cluster to, e.g., a UPnP cluster on the network.
• a PC that controls the UPnP cluster can have a software component that serves to bridge the UPnP cluster of the home network to the HAVi cluster.
• Fig.l is a block diagram illustrating the principle of the bridging between two networks according to the invention.
• Fig.2 is a block diagram illustrating bridging HAVi to UPnP
• Fig.3 is a block diagram illustrating bridging UPnP to HAVi.
• same reference numerals indicate similar or corresponding features.
• an aspect of the invention relates to connecting a bridge to a server, e.g., on the Internet.
• This server offers a lookup service for some set of standards, and allows a bridge to locate and download the appropriate translation modules in the home network that eventually enables a device on a sub-network of a first architecture to work with devices on a sub-network of a second architecture.
• Fig.l is a diagram of a home network system 100 with a first cluster 102 of devices 104, 106 and 108 that comply with a first software architecture standard, herein-after called standard A.
• System 100 comprises a second cluster 110 of devices 112, 114 and 116 that comply with a second software architecture standard, herein-after called standard B.
• Clusters 102 and 110 are interconnected through a bridge 118.
• translation modules are introduced. These modules need to participate in both clusters 102 and 110.
• the modules typically need components local to the clusters, such as lower-level communication software, in order to be capable of this participating. Rather than having each translation module comprising its own communication software it is more efficient to provide this software as an element of platform components 120 of bridge 118.
• the process of the invention is now illustrated with an example wherein B- device 116 is going to be added to system 100.
• the first step comprises physically connecting B-device 116 to B-cluster 110, or "booting" B-device 116.
• bridge 118 detects B-device 116 as a new addition, either because bridge 118 scans B-cluster 110 or its registry/directory/look-up service (not shown) periodically or because B-cluster 110 actively notifies bridge 118.
• Bridge 118 comprises a software component 122, referred to as Installation Manager, that handles the installation of further software components needed to integrate B-device 116 into system 100.
• Installation Manager a software component 122, referred to as Installation Manager, that handles the installation of further software components needed to integrate B-device 116 into system 100.
• An aspect hereof is discussed in, e.g., U.S. serial no. 09/340,272 (attorney docket PHA 23,634).
• a software component referred to as the Reference Factory, is capable of extracting information from any of the software representations of devices registered.
• This Reference Factory is capable of querying the inventory of services or of getting notified of a new software representation according to the methods of the relevant software architecture.
• Installation Manager 122 receives or retrieves information descriptive of newly added B-device 116.
• the descriptive information is possibly reformatted before being sent to a bridge server 124 via the Internet 126.
• bridge 118 preferably provides information about the local execution environment of home network 100. This information is relevant to the software components that server 124 downloads onto bridge 118.
• the relevant information regarding the environment relates to the software architectures present, in this case the A-standard cluster 102 and the B-standard cluster 110.
• the information may also relate to the memory available, the type of operating system(s) being used, virtual machines present, platform libraries, etc., on bridge 118.
• server 124 is able to select the proper translation module or modules that fits or fit in best with the network environment of system 100.
• server 124 Upon receipt of the descriptive and environment information, server 124 uses a look-up service that needs to match the information, descriptive of B-device 116, with a translation module for representing B-device 116 in A-cluster 102.
• server 124 has a plurality of look-up services available: one for each ordered pair (X,Y), wherein X and Y are the standards supported by server 124.
• two look-up services are needed: (X,Y) and (Y,X).
• server 124 may only support uni-directional bridging.
• Devices such as devices 104-108 and 112-116, are often composite objects.
• a TV set typically comprises Display, Amplifier and Tuner components.
• Server 124 could first try to translate the composite object as a whole into a new composite device with an equivalent functionality. If that does not succeed server 124 could translate as much subsidiary components as possible on a one-to-one basis. This then would result in a partial, but still useful, mapping. For example, if A-cluster 102 has not available a definition of a
• a B-type TV could still be bridged to A-cluster 102 as a monitor-like display/amplifier device. If a one-to-one relationship does not exist between particular subsidiary components in standard A and standard B, then a one-to-many or many-to-many mapping could be used.
• standard A might define volume control and equalizer effects as a single subsidiary component, whereas standard B distinguishes them as separate subsidiary components. In this case, a device in B-cluster 110 that contains just the volume control component, but not the equalizer component, cannot be bridged to A-cluster 102.
• a device in A-cluster 102 that contains a single amplifier component can be bridged to network B by applying a one-to-two mapping of the subsidiary components.
• a particular set of subsidiary components in A-cluster 102 matches with another set of subsidiary components in B-cluster 110 under a many-to-many mapping.
• a matching translation module 128 is downloaded to the bridge, installed on platform 120 and registered in accordance with the protocol of standard A. This enables other applications and devices of A-cluster 102 to discover and use device 116 through module 128. The installation and registering of module 128 may be postponed until after it has been run on the execution environment of bridge 118.
• the invention is explained below with an example illustrating the bridging of HAVi and Universal Plug and Play (UPnP) home networks with reference to Figs.2 and 3.
• the HAVi, Home API, and Jini standards for software architectures in the home networking field have been discussed to some detail in U.S. serial no.
• a DCM Device Control Module
• the DCM exposes the HAVi defined APIs for that device.
• DCMs are dynamic in nature: if a device is inserted or removed from the network, a DCM for that device needs to be installed or removed, respectively, in the network. DCMs are central to the HAVi concept and the source of flexibility in accommodating new devices and features into the HAVi network.
• Universal Plug and Play UPF is an open network architecture that is designed to enable simple, ad hoc communication among distributed devices and software applications from multiple vendors.
• UPnP leverages Internet technology and extends it for use in non-supervised home networks.
• UPnP aims at controlling home appliances, including home automation, audio/video, printers, smart phones, etc.
• UPnP distinguishes between Control Points (CPs) and controlled devices (CDs).
• CPs comprise, e.g., browsers running on PCs, wireless pads, etc., that enable a user to access the functionality provided by controlled devices.
• UPnP defines protocols for discovery and control of devices by CPs.
• UPnP does not define a streaming mechanism for use by Audio/Video devices.
• Some of the discovery and control protocols are part of the UPnP specification while others are separately standardized by the IETF (Internet Engineering Taks Force). Interaction between CPs and devices is based on the Internet protocol (IP).
• IP Internet protocol
• UPnP allows non-IP devices to be proxied by a software component running on IP-compliant devices. Such a component, called Controlled Device (CD) proxy, is responsible for translation and forwarding of UPnP interactions to the proxied device.
• CD Controlled Device
• a UPnP device has a hierarchy of sub-devices with at the lowest level services. Both devices and services have standardized types.
• a device type determines the sub-devices or services that it is allowed to contain.
• a service type defines the actions and state variables that a service is allowed to contain. State variables model the state of the device, actions can be invoked by a CP in order to change that state. The description of the state variables and the action is called the SCP (Service Control Protocol).
• SCP Service Control Protocol
• a UPnP device provides a description of itself in the form of an XML document. This document contains, among other things, the service types that it supports.
• a device may have a presentation server for direct UI control by a CP.
• UPnP relies on AutoIP, which provides a means for an IP device to get a unique address in the absence of a DHCP server.
• UPnP defines a discovery protocol, based on UDP multicast, called SSDP (Simple Service Discovery Protocol). SSDP is based on devices periodically multicasting announcements of the services that they provide. An announcement contains a URL to which service actions are to be sent: the control server.
• CPs may query the UPnP network for particular device or services types or instances.
• UPnP relies on GENA (Generic Event Notification Architecture) to define a state variable subscription and change notification mechanism based on TCP.
• GENA Generic Event Notification Architecture
• a CP After a CP has detected a service it wants to use (via SSDP), it controls the service by sending SCP actions to the control server URL or querying for state variables. Actions are sent using HTTP POST messages. The body of these messages are defined by the SOAP (Simple Object Access Protocol) standard. SOAP defines a remote procedure call mechanism based on XML.
• the translation modules, or software representations, of HAVi devices in UPnP are called Controlled Device (CD) proxies, while the software representations of UPnP devices in HAVi are called Device Control Modules (DCMs).
• CD Controlled Device
• DCMs Device Control Modules
• HAVi to UPnP bridging Fig 2 is a block diagram of a home network system 200 illustrating the bridging from HAVi to UPnP, and shows in bold arrows the sequence of steps to bridge a HAVi device, here a digital camera, to UPnP.
• System 200 has a UPnP cluster formed by devices 202, 204, and 206.
• Device 202 comprises a light
• device 204 comprises an MP3 player
• device 206 comprises a printer.
• System 200 has a HAVi network cluster formed by a TV 208, and a digital video recorder 210. The clusters are connected through bridge 118.
• a HAVi Camera 214 is physically plugged into the HAVi's 1394 network, thus making Camera device 214 an active HAVi node.
• this addition is discovered by the HAVi Event Manager, residing on platform components group 218.
• the HAVi platform listens and reacts to the HAVi NewSoftwareElement event, or listens to a HAVi NetworkReset event to discover Camera 214 as new device.
• a step 220 the registration attributes of the DCM of Camera 214 and its FCM components are retrieved from the HAVi Registry on platform 218, and are encoded in some format understood by a bridge server 222, for example XML, and are sent to bridge server 222 using HTTP POST.
• Bridge 118 may use a HAVi Webproxy FCM to implement this.
• a look-up component maps a HAVi device description, in the form of DCM/FCM registration attributes, to a UPnP CD proxy 226 for that device. Since UPnP CD proxies and HAVi DCMs are composite objects, the location process might be implemented on the sub device (component) level, as described earlier.
• a device software representation is DCM
• FCM functional components
• a device In UPnP, a device is a hierarchical structure of sub devices with at the lowest level services. FCMs serve the same purpose as services.
• the mapping of HAVi device to UPnP CD proxy 226 might be from complete DCM to complete CD proxy, or partially from FCMs to proxy services.
• the mapping of FCM to service might be 1 -to- 1 , 1 -to-many or many-to-many.
• CD proxy 226 is run on the execution environment of bridge 118. This involves installing an http server for the unique URL of CD proxy 226.
• CD proxy 226 sends out periodic announcement messages, and responds to discover messages. This enables the other UPnP applications and devices to discover and use the HAVi Camera 214 through the CD proxy 226.
• Fig.3 illustrates the steps to bridge a UPnP device, here printer 206 to HAVi cluster 208, 210, 214 in system 200.
• printer 206 is physically plugged into the UPnP network, and 'powering-up' the UPnP device.
• a next step 304 involves listening and reacting on the UPnP device announcement message.
• the device description document of printer 206 is retrieved from the URL embodied in the announcement message, and the document is sent to bridge server 222 using HTTP POST.
• a step 308 involves a look-up component that maps a UPnP device description, in the form of a description document (in XML), to a HAVi DCM for that device, here printer 206. Since UPnP CD proxies and HAVi DCMs are composite objects, the location process might be implemented on the sub device (component) level, as described earlier.
• a device software representation is DCM
• FCM functional components
• UPnP a device is a hierarchical structure of sub devices with, at the lowest level, services. Services that are part of a UPnP device can be found in the device description document.
• FCMs serve the same purpose as services.
• the mapping of HAVi device to UPnP CD proxy might be from complete DCM to complete CD proxy, or partially from FCMs to services.
• the mapping of FCM to service might be 1-to-l, 1 -to-many or many-to-many.
• a step 310 involves running a downloaded Printer DCM 312 in the execution environment of bridge 118. This involves calling the DCM's Install method.
• a step 314 involves DCM 312 and its FCMs to create HAVi software elements, and using those to register with the HAVi registry component (which is part of platform components 218 available on bridge 118).
• a step 316 the HAVi registry posts global NewSoftwareElement events for DCM 312 and all FCMs that are part of it. This enables the other HAVi applications and devices to discover and use UPnP Printer 206 through Printer DCM 312.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Automation & Control Theory (AREA)
• Computing Systems (AREA)
• Multimedia (AREA)
• Small-Scale Networks (AREA)
• Information Transfer Between Computers (AREA)
• Stored Programmes (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (2)

Family

ID=24470330

Family Applications (1)

Country Status (5)

Cited By (20)

Families Citing this family (8)

Citations (4)

Family Cites Families (1)

• 2001
  • 2001-07-20 CN CN01802165A patent/CN1398469A/zh active Pending
  • 2001-07-20 WO PCT/EP2001/008552 patent/WO2002009350A2/en not_active Application Discontinuation
  • 2001-07-20 EP EP01958011A patent/EP1307998A2/en not_active Ceased
  • 2001-07-20 KR KR1020027003864A patent/KR20020035645A/ko not_active Application Discontinuation
  • 2001-07-20 JP JP2002514949A patent/JP2004505499A/ja active Pending

Patent Citations (4)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events