EP1058422A1 - Methods for bridging a HAVi sub-network and a UPnP sub-network and device for implementing said methods - Google Patents

Abstract

The invention concerns methods for bridging a HAVi sub-networkand a UPnP sub-network.

For making UPnP devices available to the HAVi sub-network, thefollowing steps are implemented:

• discovering UPnP devices and/or services on the UPnP sub-networkand corresponding to a selection criterion;
• declaration, by a sub-network bridging device, of each discoveredUPnP device as a HAVi DCM and of each discovered UPnP service as a HAViFCM on the HAVi sub-network.

For making HAVi devices available to the UPnP sub-network, thefollowing steps are implemented:

• discovering HAVi software elements of the HAVi sub-networkcorresponding to a selection criterion;
• representing, in a sub-network bridging device, each of saiddiscovered elements by a UPnP proxy service identified by a port numberattributed by said sub-network bridging device; and
• announcing each said proxy services on the UPnP sub-network.

The invention also concerns a device for implementing the abovesteps.

Description

• The invention concerns methods to bridge HAVi and UPnP sub-networks,a first method addressing the issue of making UPnP objects availableto HAVi objects, a second method addressing the issue of making HAVi objectsavailable to UPnP objects. The invention also concerns a bridge device.
• The invention applies among others to home networks.
• Several sub-networks based on different physical media (wired andwireless) and applications are expected to coexist in a digital home network.Common examples of wired physical media include the coaxial cable, twistedpair wiring, power line and optical fibers. A digital home network also needs tocontend with the technological developments within the computer, consumerelectronics, telephony and home automation industries.
• There have been two recent initiatives within the industry to addressdifferent needs:
• 1. Home Audio-video interactivity (HAVi)
• 2. Universal Plug and Play (UPnP)
• There is a need for harmonization of the two system approaches inorder to ensure coexistence and interoperability of devices within thesedomains. One of the goals of the invention is to accomplish the bridging of thetwo technological approaches.
• The first initiative, Home Audio-Video Interoperability (HAVi), startedwithin the consumer industry is an attempt to accomplish high speedinterconnectivity over an IEEE 1394 serial bus network for transactingaudio/visual data. This initiative was specifically intended to address the needsof the consumer electronics devices to enable interactivity (with userinvolvement in a user-device interaction paradigm) and interoperability (with nouser involvement in a device-device interaction paradigm). Further, within HAVi,there is a strong emphasis on enabling streaming applications in addition tocontrol applications. An example of a streaming application would be an application transferring a video stream from a recording device to a decoder ordisplay, while an example of a control application would be an application forprogramming the behavior of devices. This implies a support for bothisochronous and asynchronous transactions.
• The other key features of HAVi include:
• 1. Hot Plug and Play
• 2. Hardware and Operating System Platform neutrality
• 3. Support for legacy devices (i.e. devices with no HAVi functionality)and a gradual evolution to support new technologies
• The second initiative is Universal Plug and Play (UPnP). While HAViis intended primarily for a high speed IEEE 1394 network for AudioNideotransactions, UPnP is an initiative that is physical layer agnostic and expects towork on a TCP/IP network. The general notions and paradigms are based onthe Internet protocols with additions to support the notions of plug and play.
• The following non-exhaustive list of documents describe the abovearchitectures in their current state of development, at the priority date of thepresent application:
• For HAVi:
• The HAVi 1.0 beta+ specification, dated October 23, 1998
• The UPnP technology comprises a set of protocols based onTCP/IP:
• 'Automatically choosing an IP Address in an Ad-Hoc IPv4 Network'(<draft-ietf-dhc-ipv4-autoconfig-04.txt>)
• 'Simple Service Discovery Protocol 1.0'(^<http ://search. ie. org/internet-drafts/draft-cai-ssd p-v1-01.txt>)
• 'Multicast Discovery of DNS (Domain Name Server) Services'(<draft-manning-multicast-dns-01.txt>).
• 'Extended Markup Language' - XML (1.0 W3C recommendation)
• More information concerning these two architectures is available onthe corresponding websites, ie.www.HAVi.org andwww.UPnP.org.
• The fundamental goal of the interoperability is to ensure that auniform control paradigm, i.e. model, is presented so that devices in both theHAVi sub-network and the UPnP sub-network are able to interact with devicesand perform control functions over their respective sub-network boundary.
• Since HAVi and UPnP based devices are expected to proliferatewithin the home, it would be necessary to ensure the interoperability of deviceswithin these domains. Figure 1 represents an example of a home networkcomposed of a HAVi based home sub-network and a UPnP based home sub-networkthat are bridged together. Nodes A and D are displays where the usercan view the network topology and can control, through an appropriate userinterface, any node on either network. This implies that from node A, the usershould for example be able to detect the connection of node E to the UPnPnetwork and should be able to control it. In a similar manner, a user of node Don the UPnP sub-network should be able to detect the appearance of a newHAVi device within the HAVi sub-network and should be able to control it.
• In Figure 1, the two sub-networks are built over two different media.However, the problem to be solved is the same in the situation where bothnetwork architectures are built over the same media as shown in Figure 2. Thenodes A, B and C are HAVi aware and the nodes C, D and E are UPnP aware.In both configurations, there is a node (node C in both examples) whichimplements the bridge function in order to enable the control of any across theentire network.
• The invention aims at providing an interfacing solution in both of theabove cases.
• The object of the invention is a method for bridging a HAVi sub-networkand a UPnP sub-network comprising the steps of:
• discovering UPnP devices and/or services on the UPnP sub-networkand corresponding to a selection criterion;
• declaration, by a sub-network bridging device, of each discoveredUPnP device as a HAVi DCM and of each discovered UPnP service as a HAViFCM on the HAVi sub-network.
• According to a preferred embodiment, the discovery step is carriedout using Simple Service Discovery Protocol (SSDP) functions.
• Another object of the invention is a method for bridging a HAVi sub-networkand a UPnP sub-network comprising the steps of:
• discovering HAVi software elements of the HAVi sub-networkcorresponding to a selection criterion;
• representing, in a sub-network bridging device, each of saiddiscovered elements by a UPnP proxy service identified by a port numberattributed by said sub-network bridging device; and
• announcing each said proxy services on the UPnP sub-network.
• According to a preferred embodiment, the discovery step comprisesthe step of requesting, by said sub-network bridging device, a list of softwareelements from a HAVi registry.
• According to a preferred embodiment of the inventions above, theselection criterion is HTTP/HTML capability.
• Another object of the invention is a device for bridging a UPnP sub-networkand a HAVi sub-network implementing the above method steps.
• Other characteristics and advantages of the invention will becomeapparent through the description of a non-limiting, preferred embodiment,described with the help of the attached drawings among which:
• figure 1, already described, represents a HAVi network and a UPnPnetwork linked through a bridge device;
• figure 2, already described, represents a single network comprisingboth HAVi and UPnP compliant devices;
• figure 3 represents the networks of figure 1 in which each networkcomprises an HTML browser capable device;
• figure 4 is a schematic diagram of protocol stacks in the bridgedevice.
• In addition to the documents cited in the introduction of the presentapplication, one should also refer to the Hypertext Transfer Protocol ('HTTP')1.1 for further background information.
• Within the context of the UPnP network, it is necessary to detect theentry of a new device into the network, announce its capabilities in a welldefined manner and allow the commencement of interaction with other deviceswithin the network. The SSDP protocol and XML operating over the TCP/IPnetwork are used to accomplish this functionality.
• For user control, HTML may be used instead of XML.
• As described earlier, HAVi is a complete system solution to theinteroperability of devices with a IEEE 1394 interface. HAVi addresses, amongothers, the following issues:
• 1. Registration of devices/functions
• 2. Communication media management (the media being an IEEE1394 serial bus in this case)
• 3. Modeling devices and functions within devices using devicecontrol modules ('DCMs') and function control modules ('FCMs'):
• - the list of services provided by the DCM includes connectionmanagement, status queries for the device and its plugs
• - there is a comprehensive list of FCMs representing the mostcommon consumer electronic functional elements
• 4. Event management (using an event manager)
• 5. Stream management (using a stream manager)
• 6. Resource management
• 7. Support for legacy devices
• 8. Data Driven Interaction (DDI) mechanism
• Some of the services offered within the HAVi paradigm are similar tothose envisioned within the UPnP paradigm. The important additions to HAViinclude specific provisions for stream management, communication media management and resource management. These additions are quite importantin the context of an A/V network based on the IEEE 1394 bus, which imposessevere real time constraints.
• One of the issues regarding the interaction between the HAVi andUPnP sub-networks is the need for a common user control protocol. The DDImechanism, which is standard in HAVI, is not standard within the UPnPnetwork. HTML is standard in an IP based computer network (including UPnP),but is not included in HAVI. In order to solve this problem, the followingfunctionalities are required:
• a user control protocol which can be used across the wholenetwork : HTML
• A bridge function which will allow :
• (a) connection of the two different discovery protocols
• (b) carrying the HTML data over the entire network
• The Hypertext Transfer Protocol (or HTTP) is a request/responseprotocol. This protocol is introduced in the current context since it is theproposed mechanism to accomplish the bridging function alluded to in thepreceding sections.
• The request/response mechanism dictates a client/server model fordevices using HTTP. Two objects are involved in HTTP : the client, whichsends a command, and an origin server that receives the command and sendsback the response.
• The HTTP protocol has a list of well defined methods (or commands)which include the following:
• 1. Option
• 2. Get
• 3. Head
• 4. Post
• 5. Put
• 6. Delete
• 7. Trace
• The most commonly used command isGET < URL> where theUniform Resource Locator (URL) points towards the object to be obtained. Thisreference is composed of two parts : the first points towards the serverequipment and the second points towards the object associated with thecommand. This target object can be an existing object such as a HTML script ora bit-map or other objects. However the object reference can point towardssomething that has a meaning for the WEB server but does not represent anyreal object. This is used, for instance, in an HTML script to signal to the WEBserver that the user just selected an icon. After the user selects the icon, theHTML script associates this icon with a URL which will be sent to the WEBserver (through the GET command).A URL reference can include someparameters as a command from upper layer protocols.
• Basically, a user (application) needs is to be able to detect thenetwork changes (new or removed device/services) and then has to be able tocontrol devices through a User interface (a well known language or protocol).
• We first address the user control interface model of both networks.Then, we apply the recommended solution to bridge other control protocols tooperate UPnP and HAVi services over the entire network.
• Each network technology specifies a way to dynamically discover theappearance or the disappearance of services and devices. The first task of thebridge function is to connect both discovery methods. For that we need:
• a way to represent and to reach a UPnP device/service for a HAViapplication within the bridge device;
• a way to represent and to reach a HAVi device/service for a UPnPapplication within the bridge device.
• The UPnP protocol for this function is the Simple Discovery Protocol(called SSDP) alluded to in an earlier section. The HAVi protocol for thecorresponding function is the Registry.
• Regarding the bridging of the User control interface we need to mapthe HAVi and the UPnP worlds. HAVi specifies two protocols which are differentfrom HTML. To solve the problem we need:
• a user control protocol which can be used across the wholenetwork : HTML/HTTP;
• a way to implement the HTTP protocol within the HAVi paradigm.
• Regarding the bridge of other services (UPnP or HAVi) we need:
• a way, for a HAVi applications to operate the UPnP service/device;
• a way, for a UPnP application to operate the HAVi service/device.
• In Figure 3, the bridge function is included in the device C. Anydevice, irrespective of its functionality, could contain the bridge function. Whatis needed is that the host device gathers the HAVi middleware and the UPnPprotocol stack. For clarity purposes, the C device according to the presentembodiment does not provide any functionality other than the bridge asdescribed below.
• The next section describes all operations necessary to realize thefollowing scenarios:
• Scenario 1: the network topology is the same as shown in theFigure 3 except that the E device is not present. The User application of A (theHTML browser) after power on, is able to give back to the user the network listof the HTML controlled devices (discovery through the HAVi registry). The Edevice is plugged on to the UPnP network. The User application detects thisnew device (through the ANNOUNCE method of SSDP). Then the user will beable to control the E device using HTML.
• Scenario 2: the network topology is the same as shown in the 3except that the B device is not present. The User application of D (the HTMLbrowser) after power on, is able to give back to the user the network list of theHTML controlled devices (discovery by SSDP queries). The B device is pluggedon to the HAVi network. The User application detects this new device(announcement). Then the user will be able to control the B device usingHTML.
• HTML data is transported using the HTTP protocol. However, HTTPis a means to transport any type of hyper text based content. Just as throughHTTP we are able to obtain any User Interface object, such as an icon or abitmap, we are able to transport XML content as well. Today, the most popularMarkup language is HTML. Consequently many product tools already exist.This is the reason we recommend using it within the HAVi network. XML is anemerging standard, and could be used instead of HTML without anymodification to our proposal since XML content can be transported over HTTPas well. According to a variant embodiment, XML and HTML are used jointly.
• This section proposes to add HTTP (HTML) capabilities to the HAVispecification. This protocol is a simple command/response protocol between acontroller and a target (called HTTP server as well). In HAVi, each device isrepresented by a software component called a DCM (Device Control Module).This DCM contains a certain number of well specified entry points (as a set offunctions) which can be used (called) by any other software element of theHAVi network. Like a C function, when a software element calls a function of aDCM (whether remotely or locally, it is transparent for the caller), an associatedprocess is started and the function returns the result of the process. Toimplement the HTTP paradigm, this invention proposes to add a new functionset () within the DCM API to offer the possibility to handle the HTTP protocolbetween two HAVi software elements - for example between an application (abrowser) and a DCM (the HTTP server)-. HAVi uses the IDL (InterfaceDefinition Language) to specify a function. Due the nature of the HTTPprotocol, it is possible that HTTP requests or responses contain a very largepayload. The transport layer of HAVi specifies a limit on the message size thatcan be exchanged between two HAVi software elements. However HAVispecifies a way to handle such large messages by a recommended design ofthe API of the element potentially involved in such communications (see APIsfor Bulk transfer).
• The following code illustrates the proposed API extension for theDCM which would implement an HTTP server.
     enum FileLoc {START, MIDDLE, END};
• Permits to indicate whether the message from a producer to aconsumer is the first one, a middle one the last one. If the stream to be sent fitsinto one message, the END value will be used.
  Status DCM::HttpOpen(
     in short clientBufferSize,
     in OperationCode opCode,
     out long cid,
     out short ServerBufferSize)
     clientBufferSize : indicates the maximum size (in bytes) of amessage accepted by the requester. The DCM will take into account of thatparameter during the sending of the HTTP response to the client.
     opCode : this is the operation code the DCM will use to give back tothe client the HTTP response. The client function identified by this operationcode must be designed according to the prototype named<client>::HttpResponse.
     cid : the identifier of this HTTP connection with the DCM. It allowsseveral connections from the same software element client and also permits tomatch a response with a request.
     ServerBufferSize : indicates the maximum size (in bytes) of amessage accepted by the DCM. The HTTP client will take into account of thatparameter during the sending of the HTTP requests.
• This function allows a software element client (or HTTP client) toopen a HTTP connection with a DCM.
• The error codes for this function are the followings:
     DCM::ENUM_CONN: maximum number of opened connections isreached for this DCM
     DCM::EALLOC: resource allocation error
     Status DCM::HttpClose(in long cid)
• The parameter cid is the identifier of this HTTP connection with theDCM. This function is used to close a connection with a Web proxy FCM. Theerror code is the following:
     DCM::ECID: The cid is unknown.
     Status DCM::HttpRequest(
        in long cid,
        in FileLoc where,
        in sequence<octet> data)
     Parameters
     cid: the identifier of the connection between the HTTP client and theDCM (acting as a HTTP server) obtains by the HTTP client from aDCM::HttpOpen call.
     where: informs the DCM that this message is the first, the last or amiddle one of the request .
     data: contains a part or the entire request according to the HTTPprotocol.
     Description
     This function allows a software element client (or HTTP client) tosend a request to a DCM acting as a HTTP sever according to HTTP.
     Error codes
     DCM:ESIZE: the data exceeds the size of the buffer in the receiver.The receiver has not received or processed the data. It is left to theimplementation how the sender reacts to this status error.
     DCM::EFAILED: the receiver has aborted the transfer of the currentsequence of data transfers. The sender shall abort the transfer of the currentsequence.
     DCM::ECID: The cid is unknown.
     Status <Client>::HttpResponse(
        in long cid,
        in FileLoc where,
        in sequence<octet> data)
     cid: the identifier of the connection between the HTTP client and theDCM.
     where: informs the client that this message is the first, the last or amiddle one of the response .
     webData: contains a part or the entire response according to theHTTP protocol used through the connection identified by the cid parameter.
• This is the prototype of the function to be implemented in the clientwhich allows the DCM (acting as a HTTP server) to give back to the client aHTTP response corresponding to a previously received HTTP request from thatclient through that connection identified by "cid".
• The error codes are the followings:
     WebProxy::ESIZE: the data exceeds the size of the buffer in thereceiver. The receiver has not received or processed the data. It is left to theimplementation how the sender reacts to this status.
     WebProxy::EFAILED: the receiver has aborted the transfer of thecurrent sequence of data transfers. The sender shall abort the transfer of thecurrent sequence.
     WebProxy::ECID: The cid is unknown.
• In HAVi, the designer of a target device can decide which usercontrol protocol (HAVi currently specifies two protocols) to implement. It is noteven necessary to provide some user control capabilities as specified in HAVi.For the controller application, it is necessary to know whether a particular targetis user-control capable or not. This is the goal of an attribute in the HAViregistry. The Registry is a database where all software elements are registered(including DCM and application module). Any software element can query thedatabase. Each time an element is added or removed, a corresponding network event is generated. An element is registered with a set of attributes tocharacterize it. One of these attribute is the GUIREQ attribute. The possiblevalues are:
• NO_NEED
• DDI (the basic Ul protocol in HAVi)
• HAVLET (the Java based Ul protocol in HAVi)
• The invention proposes to add a new value for this attribute as thefollowing:
• HTTP (the HTTP/HTML paradigm in HAVi)
• When a user wants to control a device, its associated clientapplication, typically an HTML browser, exposes the set of network devicesHTTP/HTML capable (by querying the Registry on the corresponding GUIREQattribute value). The user selects one of these and the client application cansend the HTTP GET command towards the DCM of the selected target,according to that protocol. To send the HTTP command, the client applicationfirst establishes an HTTP connection with the target DCM (calling theDCM::HttpOpen method) and then performs one or several calls (depending onthe size of the request and the capabilities of the target DCM in term of theHAVi message size) to the DCM. The DCM then uses DCM: HttpRequest tosend its HTTP request. Once the target receives the command, it sends backthe Home HTML page associated with the device to the client by calling one ormore times the client method called "HttpResponse". The client application (thebrowser) then interprets the HTML script and displays the User Interface.
• The bridge function is implemented in a device (called the bridgedevice or simply the bridge) which is connected to both sub-networks as shownin Figure 3(device C). Thus it has to contain, at least, the protocol stack asshown in the Figure 4 .Since the SSDP protocol requires some multicastcapabilities, the IP layer will be IGMP ('Internet Group Management Protocol')compliant.
• The modelization of a UPnP device or service seen from the HAVisub-network will now be described.
• The UPnP network is composed of devices that offer access to somenetwork services. The SSDP protocol should permit the discovery of theservices available in the network and indirectly the device that hosts theservice. The HAVi network is composed of devices that contain one or morefunctional components (equivalent to services in UPnP). To represent a device,we have to use the DCM representation. To represent a functional componentwe have to use the FCM representation. In HAVi, the User interface protocol ismanaged through the DCM API.
• Consequently :
• A UPnP device will be represented by a DCM in the bridge device.
• This DCM will contain the HTTP extra API.
• A UPnP service (except for the HTTP service) will be representedby a FCM in the bridge device.
• It is mandatory to register these DCMs and FCMs through the HAViREGISTRY service to allow any other HAVi object to discover them and, thus,to be able to operate them. The registration consists in registering the HAViaddresses of these software elements and the mandatory attributes accordingto the HAVi specification:
• Type of software element (either DCM or GENERIC FCM)
• HUID (unique hardware identifier: computed by the bridge device)
• Device class (LAV - meaning Legacy device)
• GUIReq (HTTP)
• DeviceManufacturer (manufacturer of the UPnP device/service)
• SoftwareElementVersion (computed by the bridge device)
• UserPreferredName (computed by the bridge device - based onthe UPnP service/device name)
• Before the bridge device is able to activate and register a DCM/FCMcorresponding to a UPnP device/service, it has to detect its presence within theUPnP sub-network.
• According to the SSDP (Simple Service Discovery Protocol) ofUPnP, the bridge device acts as a SSDP client and server. Once the bridge device is connected to the home network, its SSDP client has to query theUPnP sub-network by sending the multicast OPTIONS message over UDP/IPto query the SSDP servers. The SSDP OPTIONS message will have thefollowing format according to the HTTP specification:
     OPTIONS _*_ HTTP/1 .1 Request-ID: uuid:1313Alt-Locations:<httpu://bridge.com/bar:1111>
• This message contains the type of services concerned by the query(_*_ meaning : all), the version number of HTTP, a unique identifier to matchthe response with the query (the value shall respect a format described in theRFC 2518), and the URL the responder will use to give back its response(s)(the port number 1111 correspond to the SSDP client of the bridge).
• All UPnP devices will send back one or several SDDP OPTIONSresponses (one by service implemented within the device) containing the nameof the service, the network location of the service (the URL used to reach theservice), the protocol to be used to communicate with the service and a set ofdata to describe the device which hosts the service according to the following:
• Device manufacturer name
• Device name
• A URL to obtain an icon representing the device
• The bridge device parses all responses and:
• For each new device detected, it installs and declares a HAVi DCMand registers it with its well specified attributes as described earlier.
• For each new service type, for which the bridge wants to offer theaccess to the HAVi network, it installs and declares a HAVi FCM and registers itwith its well specified attributes as described earlier.
• Consequently the DCM, respectively the FCM shall maintain a set ofconfiguration data to be able to identify and join its associated UPnP device,respectively service.
• For the DCM:
• The URL to join the HTTP server of the UPnP device (if this serviceis implemented in the device)
• The Device manufacturer name
• The Device name
• The URL to get an icon representing the device
• For the FCM:
• The URL to join the UPnP service
• The type of the UPnP service (printer for example)
• The Device manufacturer name of the UPnP host device
• The service name of the UPnP service (PrinterRoom2 for example)
• The URL to get an icon representing the device
• When a UPnP device is plugged into the network, it has to send theSSDP ANNOUNCE message containing the name of the network service itprovides , the network location and protocol to be used to communicate with it.The SSDP server of the bridge is listening to the well known multicast portnumber. Thus for each incoming ANNOUNCE message, the bridge device willparse the message according to the manner described below.
• For each detected UPnP device/service, the bridge device installs aDCM/FCM to control this UPnP device/service as explained in the previoussections. The HAVi sub-network has the knowledge of these new elements.Any application in the HAVi sub-network can then control a UPnP target. In ourexample (cf Figure 3) the A device provides the user with the list of devices inits home network represented by icons. To realize that, the user application ofA (an HTML browser) has previously queried the HAVi registry to get all theidentifiers of DCMs which were able to offer an HTTP API.
• The user would like to control the E device using HTML and selectsits associated icon. The user application in A establishes the HTTP connectionwith the associated DCM. The User application then sends the HTTP request tothe DCM calling the function DCM::HttpRequest. The DCM then establishes theTCP connection according to HTTP between the bridge device (C) and theUPnP target (E) and forwards the HTTP request. To establish the connection,the DCM will use the URL associated with the HTTP server service of the UPnPtarget previously registered as configuration data.
• Once the HTTP command (the HTTP_GET command for instance) isreceived by the UPnP target, it sends back the response (an HTML page) tothe DCM which will forward this response to the source of the request.
• The modelization of a HAVi target seen from the UPnP sub-networkwill now be described.
• The UPnP model is based on the TCP/UDP/IP protocols.Consequently, a UPnP device is a network entity which can be reached throughits IP (Internet Protocol) address. A service is an entity within the applicationlayer (over TCP or UDP) which can be reached through a port number. Theport number identifies the connection path between two UPnP entities (anapplication and a service for example). To represent a HAVi device or a HAVifunctional component within the bridge we basically have two solutions:
• The first solution is based on port numbers and is used for the restof the description, as explained below.
• The second solution is based on multiple IP addresses: local IPaddresses are assigned to each device or functional component within theHAVi network. This assignment can be made to be consistent with the SSDPmechanism. The invoked HAVi component (either a DCM or an FCM) can, oninstantiation, request a unique IP address assignment just as any other UPnPdevice entering the UPnP network.
• The notion of a 'device' in UPnP is used only to reach the networkentity and to obtain data describing the location where the service resides.Consequently there is no need to represent a HAVi device as a UPnP device.What is needed it to represent some HAVi services as the HAVi functionalcomponent APIs (FCM) and the HTTP API (offered by the DCM). According tothe present embodiment, the so-called port number solution consists inrepresenting a HAVi service by a proxy UPnP service (like a HTTP proxyserver) where each proxy is associated with a port number (either TCP or UDP)attributed by the bridge.
• UPnP requires that for any new services the SSDP client of thehosted device announce the service list it owns. The bridge uses the HAViREGISTRY to be able to query or detect the new HAVi targets as FCM or DCMaccording to the appropriate criteria, which is, according to the presentembodiment, the GUIREQ value.
• Consequently, once the bridge detects a HAVi target (either a DCMor a FCM) for which a proxy UPnP service can be activated, it generates theSSDP multicast ANNOUNCE message to the UPnP subnetwork. The followingANNOUNCE message is used to announce a HTTP server service representedby a HTTP proxy within the bridge device:
     ANNOUNCE   server:HTTP   HTTP/1.1   Location:httpu://bridge.com:123
• The URL "server:HTTP" is the type of the service. The location fieldcontains the URL to reach the service. It is composed of the address of thebridge device and a port number chosen by the bridge device and dedicated tothe HTTP proxy associated with the HAVi target.
• Each time a new proxy has to be activated, the bridge devicechooses a new (private) port number related to the transport protocol used toreach that service (either UDP or TCP).
• The entity body of the ANNOUNCE message will contain thefollowing fields which help to identify the device hosting the service:
• Device manufacturer name
• Device name
• A URL to obtain an icon representing the device
• It is possible also that the SSDP server of the bridge device receivesan OPTIONS message from any UPnP device. The bridge will have to respondaccording to the description presented earlier.
• Consequently the proxy service shall maintain a set of configurationdata to be able to identify and join its associated HAVi target (either a DCM or aFCM). This configuration data shall comprise the Software Element Identifier(SEID) of the HAVi target.
• Once a proxy is installed and declared to the UPnP sub-network, anyapplication in the UPnP sub-network can then control these HAVi targets. In ourexample (cf Figure 3) the device D provides to the user the list of devices in itshome network represented by icons. To realize that, the user application ofdevice D (a HTML browser) has previously queried the UPnP sub-networkthrough the SSDP OPTIONS method to get the description of all devices whichimplement a HTTP server service.
• The user would like to control the device B using HTML and selectsits associated icon. The user application in device D establishes the TCPconnection with the HTTP proxy -associated with the HAVi target device B-embeddedin the bridge device. The HTTP proxy then establishes a HTTPconnection with the DCM representing the HAVi target calling theDCM::HttpOpen method as described earlier. The User application then sendsthe HTTP request to the HTTP proxy through the TCP connection. The HTTPproxy then forwards the HTTP request to the HAVi target device B (in fact itsDCM) by calling the function DCM::HttpRequest. The DCM then sends back theHTTP response (its HTML home page for instance) by calling the HTTP proxy(method <client>::HttpResponse) acting as the HTTP client within the HAVisub-network. The HTTP proxy then will forward the response to the userapplication located in device D.
• Although the preferred embodiment concerns the interoperability of aUPnP sub-network and of a HAVi sub-network, the invention is not limited tothese two network types and may also be applied to other types of networks.

Claims (6)

1. Method for bridging a HAVi sub-network and a UPnP sub-networkcomprising the steps of:

   discovering UPnP devices and/or services on the UPnP sub-networkand corresponding to a selection criterion;

   declaration, by a sub-network bridging device, of each discoveredUPnP device as a HAVi DCM and of each discovered UPnP service as a HAViFCM on the HAVi sub-network.
2. Method according to claim 1, wherein the discovery step iscarried out using Simple Service Discovery Protocol (SSDP) functions.
3. Method for bridging a HAVi sub-network and a UPnP sub-networkcomprising the steps of:

   discovering HAVi software elements of the HAVi sub-networkcorresponding to a selection criterion;

   representing, in a sub-network bridging device, each of saiddiscovered elements by a UPnP proxy service identified by a port numberattributed by said sub-network bridging device; and

   announcing each said proxy services on the UPnP sub-network.
4. Method according to claim 3, wherein the discovery stepcomprises the step of requesting, by said sub-network bridging device, a listof software elements from a HAVi registry.
5. Method according to one of the preceding claims, wherein theselection criterion is HTTP/HTML capability.
6. Device for bridging a UPnP sub-network and a HAVi sub-networkimplementing the methods according to one of the claims 1 to 5.

Images