FR2835370A1 - Equipment interconnection audiovisual domestic network management system having bridge units interconnecting local/remote networks and where both transmitter/destination correspond standard real/ otherwise proxy address destination. - Google Patents

Abstract

The communication management system and process allows communication between a transmitter module and communications module. There are bridge units connecting each bus to a network carrying information supplies. Where the transmitter and destination equipment both conform to the standard, the real address of the destination module from the transmitter is used. If one of the equipment does not conform to the standard, the proxy address of the destination with respect to the transmitter is used.

Description

<Desc / Clms Page number 1>

 System and method for managing a communication between a transmitter module and at least one recipient module, within a home audiovisual network.

 The field of the invention is that of home audiovisual networks allowing the interconnection of a plurality of equipment. In other words, these networks make it possible to interconnect audio and / or video equipment, of analog and / or digital type, so that they exchange audiovisual signals.

 The aforementioned equipment belongs for example to the following list of equipment (which is not exhaustive): television receivers (by satellite, by hertzian way, by cable, xDSL, ...), televisions, video recorders, scanners, cameras digital cameras, digital cameras, DVD players, computers, personal digital assistants (PDAs), printers, etc.

 It is assumed that the home audiovisual network is of the type comprising a plurality of digital buses, to each of which equipment can be connected (direct connection for digital equipment, or via an analog / digital converter for analog equipment).

 The invention applies in particular, but not exclusively, to digital buses of the IEEE 1394 type. It is recalled that the standard IEEE 1394 is described in the following reference documents: IEEE Std 1394-1995, Standard for High Performance Serial Bus and IEEE Std 1394a-2000, Standard for High Performance Serial Bus (Supplement).

 It is also assumed that the buses are interconnected by bridges (also called first specific devices in the following description), in accordance with a first standard relating to the interconnection of devices via digital buses themselves interconnected by bridges.

 Using the example application given above, we connect different IEEE 1394 type buses via bridges, conforming to IEEE P1394.1 Draft Standard for High Performance Serial Bus Bridges (Draft 1. 01 December 6, 2001).

 It is also assumed that the equipment, including the bridges, conforms to a second interoperability standard between equipment, defining an intermediate layer providing the interface between, on the one hand, a set of low layers,

<Desc / Clms Page number 2>

 notably communication and transport, and, on the other hand, a set of upper application layers. In other words, this second standard provides an application programming interface (API, for Application Programming Interface in English), on which services can be developed, independently of the implementations of home audiovisual networks.

 The invention applies in particular, but not exclusively, in the case where the second aforementioned standard is the HAVi standard, described in the reference document HAVi (Home Audio Video interoperability) specifications (version 1. 1 May 15, 2001).

 We now recall, in relation to FIGS. 17 and 18, some characteristics defined in the HAVi standard.

 Figure 17 shows an example of hardware architecture of HAVi equipment. This hardware architecture conventionally comprises: a bus 200 making it possible to interconnect the elements listed below; - a central unit (CPU) 201; - a clock 202; - an internal system 203; - a keyboard 204; - a RAM 205 type memory; - a ROM 206 type memory; - an input / output system 207; - display means (screen) 208; - a network adapter 209.

 Figure 18 shows an example of software architecture for HAVi equipment. This software architecture, stored in the ROM type memory 206 and implemented in the RAM type memory 205 (see FIG. 17) of the HAVi equipment, comprises: - a set 210 of low layers, in particular of communication and transport , forming a specific vendor platform (that is to say specific to the equipment manufacturer) 215 connected to the digital bus 216 of the IEEE 1394 type;

<Desc / Clms Page number 3>

 - a set 211 of upper application layers, comprising application modules (AM) 213 and Havlet modules 214; an intermediate layer (HAVi stack) 212, providing the interface between the set 210 of lower layers and the set 211 of upper layers.

The HAVi stack 212 itself comprises: a manager 217 for 1394 communication media (1394 CMM), responsible for communication aspects of the IEEE 1394 type; - a messaging system 218, making it possible to communicate all the other modules of the HAVi stack; - a registry manager (or management module) 219; - an event manager (or management module) 220 (Event Manager); - a stream manager (or management module) 221 (Stream Manager, SM). It makes it possible to establish a flow connection between two devices; - a resource manager (or management module) 222 (Resource Manager); - a manager (or management module) 223 of command modules (DCM
Manager); - control modules (DCM) 224, each allowing control of HAVi equipment.

 According to the HAVi terminology, all of the aforementioned modules (213,214, 219 to 224), which are hosted by the equipment, are called elementary functional modules (SE, for Software Element in English).

- les équipements BAV ( Base AudioVideo ) et LAV ( Legacy AudioVideo ), qui sont des équipements non-intelligents au sens HAVi. Depending on the modules they implement (in particular among those listed above), we can distinguish four types of HAVi equipment, which can be grouped into two categories: - FAV (Full AudioVideo) and IAV (Intermediate) equipment
AudioVideo), which are intelligent equipment in the HAVi sense;

- BAV (Base AudioVideo) and LAV (Legacy AudioVideo) equipment, which are non-intelligent equipment in the HAVi sense.

 For the sake of simplification, we only consider, in the following description, the case of a home audiovisual network: comprising a plurality of digital buses of the IEEE 1394 type, interconnected by means of bridges, in accordance with the IEEE standard P1394.1 above; and interconnecting

<Desc / Clms Page number 4>

 equipment (including bridges) compliant with the above-mentioned HAVI standard. It is clear, however, that the present invention is not limited to this combination of first and second particular standards.

 It appears that the envisaged combination of the IEEE P1394.1 and HAVi standards has several drawbacks. In general, these drawbacks arise from the fact that the HAVi standard was defined in relation to the concept of digital bus of the IEEE 1394 type, but without taking account of the concept (which occurred later) of interconnection of digital buses according to IEEE P1394.1 standard. In other words, the HAVi standard assumes that all of the equipment concerned is connected to the same IEEE 1394 type bus. However, the IEEE P1394.1 standard specifically aims to allow equipment connected to different buses to communicate with each other .

In particular, a major drawback is that intelligent equipment (of IAV or FAV type), connected to a given bus (called local bus), cannot: - detect, - communicate with, - have knowledge of the elementary functional modules hosted by , another device, connected to another bus (called remote bus)
In other words, an elementary functional module, said transmitter module, hosted by a piece of equipment, said transmitter equipment, connected to a given bus, said local bus, cannot communicate with an elementary functional module, said recipient module, hosted by equipment, called destination equipment, connected to another bus, said remote bus.

 The object of the invention is in particular to overcome these various drawbacks of the state of the art.

 More specifically, one of the objectives of the present invention is to provide a technique allowing any transmitter module, hosted by equipment connected to a local bus, to communicate with any recipient module, hosted by equipment. connected to a remote bus.

 Another objective of the invention is to provide such a technique that works whether the equipment conforms or not to the first standard (IEEE)

<Desc / Clms Page number 5>

 1394.1 in the preferred application), so that all existing equipment can be kept and used.

 A complementary objective of the invention is to provide such a technique which makes it possible to benefit as much as possible from the advantages offered by the IEEE P1394 standard. 1.

 These various objectives, as well as others which will appear subsequently, are achieved according to the invention using a system for managing a home audiovisual network allowing the interconnection of a plurality of equipment, in which: - said network comprises at least two buses, on each of which can be connected at least one of said equipment, and at least one first specific equipment forming a bridge, interconnecting said at least two buses, - said network conforms to a first relative standard to the interconnection of equipment via digital buses themselves interconnected by bridges, - the equipment, including bridges, comply with a second interoperability standard between equipment, defining an intermediate layer ensuring the interface between, on the one hand, a set of lower layers, in particular of communication and transport, and, on the other hand, a set of upper application layers, - a plurality of m elementary functional odules (SE) is hosted by said plurality of devices, - at least one second specific device forming a gateway (HBP) is connected to each bus, each gateway being in accordance with the first standard, - the gateways include: * means communication between gateways and processing of information relating to the network, to the equipment and to the elementary functional modules; * means for managing proxies of elementary functional modules; * means for providing information intended to allow an elementary functional module, called the transmitter module, hosted by an item of equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, says module

<Desc / Clms Page number 6>

 recipient, hosted by a piece of equipment, called recipient equipment, connected to another bus, said remote bus, - the means of supplying information are such as: * if the means of communication and information processing indicate that the equipment both the sender and the recipient equipment comply with the first standard, the means for supplying information supply the sender module, respectively recipient, with the actual address of the recipient module, respectively sender; * if the means of communication and information processing indicate that at least one of the sender and recipient equipment does not comply with the first standard, the means of providing information supply the sender module, respectively recipient, the address of the proxy of the recipient module, respectively sender.

 The general principle of the invention therefore consists in using a set of gateways (at least one per bus), making it possible to manage the connection, at the level of their HAVi stacks, of equipment which is not connected to the same bus.

 As explained in detail below, the gateways manage two types of equipment connections at the level of their HAVi stacks: - those which are made without passing through the gateways (solution based on 1394.1, using the real addresses of the elementary functional modules involved).

- those made via gateways (solution based on proxies of elementary functional modules, with use of the addresses of these proxies),
Walkways (new type of equipment introduced by the present invention) should not be confused with bridges (type of equipment perfectly defined in the IEEE P1394.1 standard). It is recalled that the bridges allow connection, at the level of their lower layers, of equipment which is not connected to the same bus, provided that this equipment complies with the IEEE P1394.1 standard.

<Desc / Clms Page number 7>

 Another essential aspect of the present invention is to favor the solution based on 1394. 1, by implementing it as soon as the corresponding necessary conditions are verified. In other words, the solution based on elementary functional module proxies is only implemented when the solution based on 1394.1 cannot be. This way, you get the maximum benefit from the IEEE P1394 standard. 1, while allowing equipment which does not comply with this standard to be able to be involved in the mechanism according to the present invention.

 Preferably, said second interoperability standard between devices is the HAVi standard (in English Home Audio Video interoperability).

 Preferably, said first standard, relating to the interconnection of equipment via digital buses themselves interconnected by bridges, is standard 1394.1.

 Preferably, at least one of said second specific pieces of equipment forming gateways (HBP) is included in one of said first specific pieces of equipment forming a bridge.

les modules de gestion de flux (Stream Manager) ; les modules de gestion de ressources (Ressource Manager) ; les modules de commande de fonction (FCM) ; les modules de type Havlet . Advantageously, said elementary functional modules belong to the group comprising: equipment control modules (DCM); application modules (AM);

stream management modules; resource management modules (Resource Manager); function control modules (FCM); Havlet-type modules.

 Advantageously, said means of communication between gateways and of information processing comprises means for managing a list of gateways within the network, themselves comprising, in each gateway: means for detecting a connection and / or disconnection of a bridge on the bus, said local bus, to which said gateway is connected, said local gateway;

<Desc / Clms Page number 8>

 means, activated in the event of detection of the connection and / or disconnection of a bridge on the local bus, of broadcasting on the network a request to discover any other gateways, called remote gateways, connected to the others buses, known as remote buses; means for receiving the responses provided by the remote gateways; means for updating a list of gateways, as a function of responses received from the remote gateways; means for sending the updated gateway list to remote gateways so that they also update their own gateway lists.

 Advantageously, said means of communication between gateways and of information processing includes means for managing a registration request, sent by an elementary functional module, said transmitter module, hosted by a device, said transmitter device, connected to the bus, called local bus, to which a gateway, called local gateway, is connected, to all the other gateways, called remote gateways, said means for managing the registration request themselves comprising: in each remote gateway: * means for receiving said registration request; * means for obtaining and transmitting a response containing a list of elementary functional modules, called remote modules, hosted by equipment, called recipient equipment, connected to the bus, said remote bus, to which said remote gateway is connected; in said local gateway: * means for obtaining a list of elementary functional modules, called local modules, hosted by said local gateway; * means for transmitting said registration request to the remote gateways; * means for receiving responses, containing the lists of remote modules, provided by the remote gateways;

<Desc / Clms Page number 9>

 * means for combining the list of local modules with the lists of remote modules, so as to obtain a global list of elementary functional modules; * means for transferring said global list to the means of providing information, so that the latter provide said global list to the sending module, after having carried out a translation of the real address of each remote module into the address of the corresponding proxy , if at least one of the sending and receiving equipment does not comply with the first standard.

 Advantageously, said means of communication between gateways and of information processing includes means for managing an event notification, sent by an elementary functional module, said transmitter module, hosted by a piece of equipment, said transmitter equipment, connected to the bus, called local bus, to which a gateway, called local gateway, is connected to all the other gateways, called remote gateways, said event notification management means themselves comprising: in said local gateway: * means for transmitting said event notification to remote gateways; in each remote gateway: * means for receiving said event notification; * means for transferring the event notification to the means for supplying information, so that the latter distribute it to each of the elementary functional modules, known as remote modules, hosted by equipment, known as recipient equipment, connected to the bus, remote bus, to which said remote gateway is connected, the means for providing information translating the real address of the transmitter module, contained in said event notification, into the address of the corresponding proxy, if one at less of the sending and receiving equipment does not comply with the first standard.

<Desc / Clms Page number 10>

 Advantageously, said local gateway further comprises means for filtering event notifications, in particular so as to prevent the dissemination, via remote gateways, of an event notification relating to the creation or deletion on the local bus of a proxy of a remote module.

 Preferably, at least two gateways are connected to a given bus, and the system comprises means for selecting one of said at least two gateways, called the selected gateway, so that only the selected gateway actually plays the role of gateway on said bus donated.

 According to an advantageous variant, at least two gateways are connected to a given bus, and the system comprises means allowing said at least two gateways to cooperate, so that said at least two gateways together act as a gateway on said given bus .

 Advantageously, said means for managing elementary functional module proxies include means for creating a proxy for elementary functional module themselves comprising: - in a given gateway, called local gateway: * means for receiving a first notification event relating to the creation on the bus, said local bus, to which said local gateway is connected, of a new elementary functional module; * means of broadcasting said first event notification to all the other gateways, called remote gateways; - in each remote gateway: * means for receiving said first event notification; * means for creating a proxy for said new elementary functional module; * means for obtaining and broadcasting on the bus, said remote bus, to which said remote gateway is connected, a second event notification relating to the creation on the remote bus of a proxy of the new elementary functional module, so as to inform all the equipment connected to said remote bus.

<Desc / Clms Page number 11>

 Advantageously, said means for managing elementary functional module proxies include means for creating a proxy for elementary functional module themselves comprising: - in a given gateway, called local gateway: * means for receiving a third notification event relating to the connection on the bus, said local bus, to which said local gateway is connected, of new equipment; * means of obtaining a list of elementary functional modules, called new local modules, hosted by said new equipment; * means for obtaining and broadcasting a fourth event notification, relating to said list of new local modules, to all of the other gateways, called remote gateways; - in each remote gateway: * means for receiving said fourth event notification; * means of creating a proxy for each of said new local modules; * means of broadcasting on the bus, said remote bus, to which said remote gateway is connected, a plurality of fifth event notifications each relating to the creation on the remote bus of a proxy of one of the new local modules , so as to inform all the equipment connected to said remote bus.

 Advantageously, said means for managing elementary functional module proxies include means for creating a proxy for elementary functional module themselves comprising: - in a given gateway, called local gateway: * connection detection means a new remote gateway on the network, and / or means for receiving a sixth event notification relating to the connection of a new remote gateway on the network; * means of transmission to said new remote gateway of a request in order to obtain a list of elementary functional modules, called

<Desc / Clms Page number 12>

 new remote modules, hosted by equipment, called destination equipment, connected to the bus, called remote bus, to which said new remote gateway is connected; - in said new remote gateway: * means for obtaining and transmitting a response, containing said list of new remote modules; - in said local gateway: * means for receiving said response, containing the list of new remote modules, provided by the new remote gateway; * means of creating a proxy for each of said new remote modules; * means of broadcasting on the bus, said local bus, to which said local gateway is connected, a plurality of seventh event notifications each relating to the creation on the local bus of a proxy of one of the new remote modules , so as to inform all the equipment connected to said local bus.

 Advantageously, said means for managing elementary functional module proxies include means for creating a proxy for elementary functional module themselves comprising: - in a given gateway, called local gateway: * means for receiving a eighth event notification relating to the connection of a new remote gateway to the network, said eighth event notification containing a list of elementary functional modules, known as new remote modules, hosted by equipment, known as destination equipment, connected to the bus , said remote bus, to which said new remote gateway is connected; * means of creating a proxy for each of said new remote modules; * means of broadcasting on the bus, said local bus, to which said local gateway is connected, a plurality of ninth event notifications each relating to the creation on the local bus of a proxy of a

<Desc / Clms Page number 13>

 new remote modules, so as to inform all the equipment connected to said local bus.

 Advantageously, said means for creating a proxy for an elementary functional module are activated, for a given elementary functional module, known as the recipient module, if at least one of the following conditions is satisfied: - if said recipient module is hosted by equipment which does not 'does not comply with said first standard; - If at least one piece of equipment, which does not comply with said first standard, is connected to a bus, said local bus, and hosts at least one elementary functional module, said transmitter module, capable of communicating with said recipient module; the recipient module being hosted by an equipment connected to another bus, called a remote bus.

 Advantageously, said means for managing elementary functional module proxies include means for removing a proxy for elementary functional module themselves comprising: - in a given gateway, called local gateway: * means for receiving a tenth event notification relating to the deletion on the bus, said local bus, to which said local gateway is connected, of an elementary functional module; * means of broadcasting said tenth event notification to all the other gateways, known as remote gateways; - in each remote gateway: * means for receiving said tenth event notification; * means for removing, if there is one, from a proxy of said deleted elementary functional module; * means for obtaining and broadcasting on the bus, said remote bus, to which said remote gateway is connected, an eleventh event notification relating to the removal on the remote bus of the proxy of the elementary functional module deleted, so to inform all the equipment connected to said remote bus.

<Desc / Clms Page number 14>

Advantageously, said means for managing elementary functional module proxies include means for removing a proxy for elementary functional module themselves comprising: - in a given gateway, called local gateway: * means for detecting disconnection a remote gateway to the network, and / or means for receiving a twelfth event notification relating to the disconnection of a remote gateway from the network; * means for removing the proxy, if there is one, from each of the remote modules which are no longer accessible because they are hosted by equipment, called recipient equipment, connected to the bus, said remote bus, to which said disconnected remote gateway is connected; * means of broadcasting on the bus, said local bus, to which said local gateway is connected, a plurality of thirteenth event notifications each relating to the removal on the local bus of a proxy from one of the remote modules which are no longer accessible.

Preferably, said remote gateway further comprises: means for detecting the type of the transmitter module: simple elementary functional or system module; means of using an elementary functional module which is specific to the remote gateway and identical to the transmitter module, when the transmitter module is of the elementary system functional module type and therefore cannot have a proxy the representative hosted by the remote gateway.

 In a preferred embodiment, said system is such that: - a pair of gateways, respectively called local gateway and remote gateway, allows said transmitter module to communicate with said at least one destination module, the local and remote gateways being connected to said bus local and to said remote bus respectively, - said local gateway comprises means for managing the proxy representing said recipient module, themselves comprising: * means for receiving and detecting a source message, coming from the sending module and intended for the proxy of the recipient module;

<Desc / CRUD Page number 15>

* des moyens d'obtention d'un second message modifié, par remplacement de l'adresse du module émetteur par l'adresse du proxy du module émetteur ; * des moyens de transmission dudit second message modifié, vers le module destinataire. * means for obtaining a first modified message, by replacing the address of the proxy of the recipient module with the address of the recipient module; * means for encapsulating the first modified message in a carrier message intended for the remote gateway, said message comprising information indicating an encapsulated type; * means for transmitting said carrier message to the remote gateway; - said remote gateway comprises means for managing the proxy representing said transmitter module, themselves comprising: * means for receiving said carrier message; * means for detecting the encapsulated type of said carrier message; * means for extracting said first modified message contained in the carrier message;

* means for obtaining a second modified message, by replacing the address of the sending module with the address of the proxy of the sending module; * means for transmitting said second modified message to the recipient module.

 The invention also relates to a gateway included in a system as mentioned above, said gateway comprising: * means of communication between gateways and of processing information relating to the network, to the equipment and to the elementary functional modules; * means for managing proxies of elementary functional modules; * means for providing information intended to allow an elementary functional module, called the transmitter module, hosted by an item of equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, said recipient module, hosted by a piece of equipment, said recipient equipment, connected to another bus, said remote bus, the means of providing information being such as:

<Desc / Clms Page number 16>

 * if the communication and information processing means indicate that the sending equipment and the receiving equipment both comply with the first standard, the information supply means provide the sending module, respectively recipient, the actual address of the addressee module, respectively sender; * if the means of communication and information processing indicate that at least one of the sender and recipient equipment does not comply with the first standard, the means of providing information supply the sender module, respectively recipient, the address of the proxy of the recipient module, respectively sender.

 The invention also relates to a method for managing a communication between a transmitter module and at least one recipient module, within a system as mentioned above, said method comprising: a step of communication between gateways and of information processing relating to the network, equipment and basic functional modules; a step of providing information intended to allow an elementary functional module, said transmitter module, hosted by an equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, said recipient module, hosted by a piece of equipment, called recipient equipment, connected to another bus, said remote bus, said step of providing information being such that: * if it emerges from the step of communication and processing of information that the sender equipment and the recipient equipment both comply with the first standard, the sender module, respectively recipient, is supplied with the real address of the recipient module, respectively sender; * if it emerges from the step of communication and processing of information that at least one of the sender and recipient equipment does not comply with the first standard, the transmitter module is supplied, respectively

<Desc / Clms Page number 17>

destinataire, l'adresse du proxy du module destinataire, respectivement émetteur.

recipient, the address of the proxy of the recipient module, respectively sender.

The invention also relates to a computer program, comprising sequences of instructions suitable for implementing a method as mentioned above when said program is executed on a computer.

The invention also relates to a computer program product, suitable for managing a communication between a sender module and at least one recipient module, within a system as mentioned above, said computer program product comprising instructions program code recorded on a medium usable in a computer, comprising: - computer-readable programming means for carrying out a step of communication between gateways and of processing information relating to the network, to the equipment and to the elementary functional modules; - computer-readable programming means for performing a step of supplying information intended to enable an elementary functional module, said transmitter module, hosted by equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, called addressee module, hosted by equipment, said addressee equipment, connected to another bus, said remote bus, said step of providing information being such that: * if it emerges from the step of communication and processing of information that the sending equipment and the receiving equipment both comply with the first standard, the sending module, respectively receiving module, is supplied with the real address of the receiving module, respectively sending module; * if it emerges from the step of communication and processing of information that at least one of the sender and recipient equipment does not comply with the first standard, the transmitter module, respectively recipient, is provided with the address of the proxy of the recipient module, respectively sender.

<Desc / Clms Page number 18>

 Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of non-limiting example, and the accompanying drawings, in which: FIG. 1 presents a block diagram of a home audiovisual network in which the communication management method according to the invention can be implemented, combining two solutions called solution based on 1394.1 and solution based on proxies of elementary functional modules; FIG. 2A illustrates the mechanism of the solution based on 1394.1, of the method according to the invention; FIG. 2B illustrates the mechanism of the solution based on proxies of elementary functional modules, of the method according to the invention; Figures 3 and 4 illustrate the routing mechanism, in a local gateway (see fig. 3) and in a remote gateway (see fig. 4) respectively, when the solution based on proxies of elementary functional modules is implemented artwork ; Figures 5 and 6 illustrate the mechanism for managing a registration request, implemented by the gateways appearing in Figure 1; Figures 7 and 8 illustrate the mechanism for managing an event notification, implemented by the gateways appearing in Figure 1; FIG. 9 illustrates the mechanism for selecting a gateway, implemented by the gateways appearing in FIG. 1; FIGS. 10 and 11 illustrate the mechanism for managing a list of gateways within the network, for broadcasting an updated list of gateways and for transmitting a request for obtaining a list of elementary functional modules , implemented by the gateways appearing in FIG. 1; FIG. 12 illustrates the mechanism for processing an updated list of gateways, and for transmitting a request for obtaining a list of elementary functional modules, implemented by the gateways appearing in FIG. 1; FIG. 13 illustrates the mechanism for obtaining information relating to the elementary functional modules, implemented by the gateways appearing in FIG. 1;

<Desc / Clms Page number 19>

FIG. 14 illustrates the mechanism for disseminating information relating to the existence of a new elementary functional module, implemented by the gateways appearing in FIG. 1; FIG. 15 illustrates the mechanism for disseminating information relating to the removal of an elementary functional module, implemented by the gateways appearing in FIG. 1; FIG. 16 illustrates the mechanism for processing information relating to the existence, modification or deletion of an elementary functional module, implemented by the gateways appearing in FIG. 1; FIG. 17 shows an example of hardware architecture of a HAVi equipment; FIG. 18 presents an example of software architecture of a HAVi device.

We present, in relation to r We present, in relation to FIG. 1, an example of a home audiovisual network, in which the method for managing a communication according to the invention can be implemented.

 The network of FIG. 1 comprises three buses, referenced 1 to 3. A first bridge 4, comprising two doors BPla and BPlb, makes it possible to interconnect the buses 1 and 2. A second bridge 5, comprising two doors BP2a and BP2b, makes it possible interconnect buses 2 and 3. All of buses 1,2 and 3 and bridges 4 and 5 conforms to a first standard relating to the interconnection of equipment via digital buses.

For the sake of simplification, we will limit ourselves in the rest of the document to the case where this first standard is the 1394.1 standard mentioned previously in this document.

 A device of the IAV or FAV type, referenced A, and two devices of the BAV and LAV type respectively, referenced B and C respectively, are connected to the bus 1. A device of the BAV type, referenced D, is connected to the bus 2. Two devices of type IAV and FAV, referenced E and F, are connected to bus 3.

 At least one specific piece of equipment, called a gateway, is also connected to each of the buses 1 to 3 and, as equipment, therefore complies with the HAVi 1.1 standard. The gateways make it possible to manage the connection of equipment, at the level of their HAVI stacks, which are not connected to the same bus. Each gateway is

<Desc / Clms Page number 20>

comporte comme un proxy de pont HAVi (HBP, pour HAVi Bridge Proxy en anglais). Elle exécute un module fonctionnel élémentaire (SE, pour Software Element selon la terminologie HAVi) spécifique, appelé par exemple HBPM (pour HBP Manager en anglais), ou encore programme propre à la passerelle. Ce dernier est en charge des fonctions et mécanismes de connexion au niveau HAVi ( HAVi bridging en anglais). Ces fonctions et mécanismes (notamment de communication entre passerelles et de traitement d'informations relatives au réseau, aux équipements et aux modules fonctionnels élémentaires) sont décrits en détail par la suite.

behaves like a HAVi bridge proxy (HBP, for HAVi Bridge Proxy in English). It executes a specific elementary functional module (SE, for Software Element according to the HAVi terminology), called for example HBPM (for HBP Manager in English), or even a program specific to the gateway. The latter is in charge of connection functions and mechanisms at HAVi level (HAVi bridging in English). These functions and mechanisms (in particular for communication between gateways and for processing information relating to the network, the equipment and the elementary functional modules) are described in detail below.

All the mechanisms of the present invention which will be described below are implemented in the form of algorithms, which are stored in the ROM (referenced 206 in FIG. 17) of the HAVi equipment, and in particular the gateways. They are loaded into RAM (referenced 205 in FIG. 17) when each equipment is powered up and the corresponding central unit (CPU) (referenced 201 in FIG. 17) will execute the instructions of these algorithms.

For the sake of simplification, we will limit ourselves throughout the rest of the document to the case where a single gateway is connected to each bus. In FIG. 1, these gateways referenced PI, P2 and P3, are included in bridges 4 and 5. Thus, on bus 1, the gateway PI corresponds to the gate BPla; on bus 2, the gateway P2 corresponds to the gate BPlb; on the bus 3, the gateway P3 corresponds to the gate BP2b of the bridge 5. The invention of course also applies to the case where the gateways are equipment distinct from the doors of the bridges, connected to the buses. For the sake of simplification, however, in the rest of the document, we will limit ourselves to describing the case where each bus comprises a single gateway, included in one of the bridges.

The equipment referenced A, B, C, D, E and F, as well as bridges 4 and 5 (and therefore in particular the gateways PI, P2 and P3), comply with a second standard for interoperability between equipment. For the sake of simplification, we will limit ourselves, throughout the rest of the document, to the case where this second standard is the HAVi standard.

The invention is of course also applicable to any other example of "second standard."

<Desc / Clms Page number 21>

In the example in FIG. 1, the equipment A and F, which are of the IAV or FAV type, comply with standard 1394.1, while the equipment E which is also of the IAV or FAV type, does not comply to this standard 1394.1.

 Each piece of equipment is controlled by a control module (DCM).

The control modules are hosted by IAV or FAV type equipment, which include a control module manager (in English "DCM Manager") as defined by the HAVi standard. By hosting a control module is meant here the hosting and execution of this control module. In other words, we don't mean the mere fact of storing the source code of a command module. For example, a BAV type equipment can store the source code of its own control module, but cannot host it within the meaning of this document, that is to say cannot execute it.

 In the example of Figure 1, the control modules are represented by a circle containing the letter under which is referenced the equipment that this module allows to control. The equipment A hosts its own control module, as well as the control modules for the equipment B and C. The gate BPlb hosts the control module for the equipment D. The equipment E and F each house their own control module.

 It is also assumed, in the example of FIG. 1, that the equipment A hosts an application module (represented by a circle containing AM).

 The general principle of the invention consists in combining two communication solutions between elementary functional modules hosted by equipment. In the following description, these two solutions are called solution based on 1394.1 and solution based on proxies of elementary functional modules, and are presented in detail.

 In general, it is assumed that an elementary functional module, said transmitter module (for example an application module), hosted by an equipment, said transmitter equipment, connected to a given bus, said local bus, wishes to communicate with at least one elementary functional module, called recipient module (for example a control module), hosted by a piece of equipment, said recipient equipment, connected to another bus, said remote bus.

<Desc / Clms Page number 22>

 According to the invention, the (first) solution based on 1394.1 is implemented if the sending equipment and the receiving equipment both comply with the 1394.1 standard.

 In this case, the gateways provide the real address of the destination module to the sender module and, conversely, the real address of the sender module to the destination module. Thus, the sender and recipient modules, because they both comply with the 1394.1 standard, can communicate directly, without having knowledge and without going through the gateways.

 This first solution is for example implemented if the application module (AM) (transmitter module) hosted by the equipment A (transmitter equipment), wants to communicate with the control module (DCM) of the equipment F (module recipient), hosted by the F equipment itself. Indeed, equipment A and F both comply with standard 1394.1.

 We now present in detail, in relation to the example in FIG. 2A, the mechanism of the solution based on 1394.1. A piece of IAV or FAV type equipment, referenced 21, is connected to the local bus B1 and hosts an application module referenced 25. The local bus B1 is connected to a remote bus B2 by a bridge referenced 24, conforming to standard 1394.1. Each gate of this bridge is also a gateway referenced PI, P2 for each of the buses referenced Bl, B2. BAV or LAV type (controlled) equipment, referenced 23, is connected to the remote bus B2. IAV or FAV type equipment, referenced 22, is connected to the remote bus B2 and hosts the control module 29 (which is a specific elementary functional module (SE)) of the controlled equipment 23.

 It is assumed that the application module (AM) 25 wishes to communicate with the control module (SE) 29. It is also assumed that the two items of equipment 21 and 22 which house them comply with standard 1394.1. As a result, the application module (AM) 25 can send directly to the control module (SE) 29, HAVi 210 type messages (encapsulated in packets conforming to the 1394.1 standard). Furthermore, the control module 29 sends a proprietary message 211 to the controlled equipment 23, so as for example to issue an AV / C type command (such as read) to this controlled equipment 23. The

<Desc / Clms Page number 23>

 AV / C type commands are defined in AV / C Digital Interface Command Set, General Specifications, version 3.0; April 15, 1998.

 In this embodiment, based on a solution based on 1394.1, the communication between the transmitter module 25 and the recipient module 29 is therefore done without passing through the gateways PI and P2 (that is to say without using their functionalities) .

 The (second) solution based on proxies of elementary functional modules is implemented if at least one of the sending and receiving equipment does not comply with the 1394.1 standard. In this case, the sender and recipient modules can only communicate via the gateways.

 To this end, the gateways implement a mechanism of proxies of elementary functional modules. Each gateway, connected to a given bus, manages proxies of elementary functional modules hosted by equipment connected to other buses.

 The gateways provide the address of a proxy of the recipient module to the sending module and, conversely, the address of a proxy of the sending module to the recipient module.

 In the example of FIG. 1, the gateway referenced PI (included in the door referenced BPla) hosts three proxies representing respectively the control modules of the equipment D, E and F. The gateway referenced P2 (included in the door referenced BPlb) hosts six proxies representing the application module (AM) and the five equipment control modules A, B, C, E and F respectively. The gateway referenced P3 (included in the door referenced BP2b) hosts five proxies representing respectively the module of application (AM) and the four control modules of the equipment A, B, C and D. The proxies of the control modules are represented by a hexagon containing the letter, followed by an apostrophe, under which the equipment is referenced that this module allows to order. The proxy of the aforementioned application module is represented by a hexagon containing AM '.

<Desc / Clms Page number 24>

 Note that creating a proxy may not be systematic. For example, we can decide to create an elementary functional module proxy, known as the recipient module, only if at least one of the following conditions is satisfied: - if the recipient module (for which the question arises as to whether a proxy should be created) is hosted by equipment that does not comply with standard 1394. 1; - if at least one piece of equipment, which does not comply with standard 1394.1, is connected to a bus, called local bus, and hosts at least one elementary functional module, said transmitter module, capable of communicating with the destination module; the recipient module being hosted by an equipment connected to another bus, called a remote bus.

 It should also be noted that, in a first variant, if the recipient module does not need to respond to the sending module, the proxy mechanism can be implemented in one direction (no proxy of the sending module).

 It is also possible, in certain particular cases, to implement the proxy mechanism in one direction only (no proxy of the sending module), even if the receiving module needs to respond to the sending module. These are cases where the receiver module can keep (in order to find alone) the address of the transmitter module, for example by memorizing the association of a source address (src) included in a 1394 type packet sent by the transmitter module, and a source address (SEIDsrc) included in a HAVi message sent by this same transmitter module.

 This second solution is therefore for example implemented if the application module (AM) (transmitter module) hosted by the equipment A (transmitter equipment), wants to communicate with the control module (DCM) of the equipment E ( recipient module), hosted by equipment E itself. In fact, equipment A complies with standard 1394.1, but equipment E is not.

 We now present in detail, in relation to the example of fi! gure 2B, the mechanism of the solution based on proxies of elementary functional modules. It will be noted that, for the sake of clarity, the same references are used in FIGS. 2A and 2B to designate the same elements.

<Desc / Clms Page number 25>

 Unlike the case of FIG. 2A, it is assumed here that the equipment 21 which hosts the application module 25 does not comply with standard 1394.1.

The equipment 22 which hosts the control module 29 may or may not comply with this standard 1394.1.

 According to this solution based on proxies of elementary functional modules, a proxy pSE 26 (for English "proxy Software Element") of the control module 28 is created on the local bus Bl, so that this proxy 26 is visible for all the HAVi devices of the local bus Bl. In the example of FIG. 2B, the pSE 26 is hosted by the gateway PI of the local bus Bl.

 Likewise, a pAM proxy 27 (for the English "proxy Application Module") of the application module 25 is created on the remote bus B2, so that this proxy 27 is visible for all the HAVi devices on the remote bus. B2. This pAM 27 is hosted by the gateway P2 of the remote bus B2.

 The application module 25 can therefore send to the proxy 26 of the control module 28, HAVi 212 type messages encapsulated in 1394 packets.

These messages are then transmitted from the proxy 26 to the gateway P2 (or more exactly to the program specific to the gateway P2, called HBPM), then from the gateway P2 to the control module 28, in the form of HAVi messages.

 In return, when the control module 28 wishes to respond to the application module 25, it sends a HAVi message 213 to the pAM proxy 27 of the application module 25. This message is transmitted from the proxy 27 to the gateway PI (or more exactly to its LMWH), then transferred by the latter to the application module 25, in the form of a HAVi message.

 The control module 28 can also send a proprietary message 214 to the controlled equipment 23, so as for example to issue a command of the AV / C type (read) to this controlled equipment.

 In this embodiment, based on a solution using elementary functional module proxies, the communication between the application module 25 and the control module 28, which can also be called transmitter module and recipient module respectively, is therefore done through the PI and P2 gateways, which respectively host a proxy 26 of the

<Desc / Clms Page number 26>

Bl. command 28 and a proxy 27 of the application module 25, and thus make visible, on the local bus BI, the control module 28, however hosted on the remote bus B2, and, on the remote bus B2, the application module 25 yet hosted on the local bus

Bl.

 We now present, in relation to FIGS. 3 and 4, the routing mechanism implemented in the gateways PI and P3, hereinafter called local and remote respectively, when the solution based on the proxies of elementary functional modules is applied.

 Assuming, using the above example in the context of FIG. 1, that the transmitter module is the control module of the equipment A (hosted by the equipment A itself), and that the recipient module is the E equipment control module (hosted by E equipment itself).

 Figure 3 presents a flowchart describing the role of the local gateway PI in the aforementioned proxy mechanism.

module émetteur (src~A), et une adresse de destination, qui est celle du proxy du module de commande de l'équipement E (dst~E'). The local gateway PI receives a HAVi message from the transmitter module (step 30). This message includes a source address, which is that of

transmitter module (src ~ A), and a destination address, which is that of the proxy for the control module of the equipment E (dst ~ E ').

The local gateway PI modifies the destination address in the message, replacing the address of the proxy of the equipment control module E (dstE ') with the address of the control module of equipment E (dstE) (step 31).

The local gateway PI encapsulates the message thus modified in a carrier message (which is also a HAVi message) comprising a source address, which is that of the local gateway (src ~ BPla), and a destination address, which is that of the remote gateway (dstBP2b) (step 32).

 The local gateway PI sends the carrier message, using 1394.1 packets, to the remote gateway P3 (step 33).

 FIG. 4 presents a flowchart describing the role of the remote gateway P3 in the aforementioned proxy mechanism.

<Desc / Clms Page number 27>

 The remote gateway P3 receives a HAVi message comprising a destination address which is its own (step 40). Then, it detects the nature of this message, namely encapsulated (that is to say carrier in the aforementioned sense) or not (step 41).

 If it is not an encapsulated message, the remote gateway P3 itself performs (normal) processing of this message (step 42).

 If it is an encapsulated message, the remote gateway P3 extracts the message it contains, namely the modified message obtained at the end of step 31 (which includes a source address, which is that of the transmitter module (src ~ A), and a destination address, which is that of the equipment control module E (dstE) (step 43).

 The remote gateway P3 modifies the source address of the extracted message, by replacing the address of the transmitter module (src ~ A) with the address of the proxy of the transmitter module (src ~ A ') (step 44).

 The remote gateway P3 sends the modified extracted message to the equipment control module E (step 45).

 We now present, in relation to FIG. 5, a mechanism for managing a registration request, implemented by the gateways appearing in FIG. 1.

 It is assumed that an elementary functional module (SE), hosted by an X device connected to a first bus (bus 1, called local bus), sent a registration request (query) to the registration manager (Registry) ( referenced 219 in FIG. 18) hosted by this same equipment X.

 In accordance with the HAVi standard, the recording manager (Registry) of the device X sends the recording request (for example in the form of a GetElement request) to the recording managers of the other devices connected to the local bus, and in particular to the registration manager of the local gateway PI connected to this local bus (step 51).

 The local gateway PI registration manager receives the request and processes it as described in the HAVi standard. In addition, it sends it (step 52) to the remote gateways P2, P3 connected to the remote buses (bus 2, bus 3), in the form of a proprietary message (PROP. GetElement). This shipment implements the

<Desc / Clms Page number 28>

 means of communication between gateways mentioned previously in the document.

 Each remote gateway (as illustrated for example for the P3 gateway) receives the aforementioned proprietary message, then sends the request to the recording managers of the equipment connected to the same remote bus as it (bus 3), and in particular to the recording manager. of a device Y connected to this remote bus. Each equipment questioned returns a response (GetElement Resp (SEID list)) including the list of elementary functional modules it hosts and meeting the criteria of the request (step 53).

GetElement Resp (SEID list) ) au gestionnaire d'enregistrement de la passerelle locale PI. Ce dernier combine (fusionne), en une liste globale de modules fonctionnels élémentaires, sa propre liste (modules fonctionnels élémentaires hébergés par la passerelle locale) avec les listes uniques qu'il a reçues des différentes passerelles (étape 54). Each remote gateway combines, into a single list, the lists it receives from equipment connected to the same bus as it. Each remote gateway sends this unique list in the form of a proprietary message (PROP.

GetElement Resp (SEID list)) to the registration manager of the local PI gateway. The latter combines (merges), into a global list of elementary functional modules, its own list (elementary functional modules hosted by the local gateway) with the unique lists it has received from the different gateways (step 54).

 The local gateway registration manager PI performs a translation (step 55) of the real address (SEID) of each module of the global list, into the address of the corresponding proxy (pSEID), if at least one Sending equipment (X equipment) and recipient equipment (remote equipment hosting the module concerned) does not comply with standard394. 1. This address translation mechanism, as implemented in this step referenced 55, is illustrated by the flowchart in FIG. 6. This possible address translation does not concern the elementary functional modules hosted by the gateway local.

 The registration manager of the local gateway PI returns to the registration manager of the equipment X a response (GetElement Resp (SEID list)) comprising the global list, after possible translation of the address of certain elementary functional modules (step 56).

<Desc / Clms Page number 29>

 We now present, in relation to FIG. 7, a mechanism for managing an event notification, implemented by the gateways appearing in FIG. 1.

 It is assumed that an elementary functional module (SE) (forming a transmitter module), hosted by an X device connected to a first bus (bus 1, called local bus), sent an event notification to the event manager (Event Manager) (referenced 220 in FIG. 18) hosted by this same equipment X.

 In accordance with the HAVi standard, the event manager (Event Manager) of equipment X broadcasts the event notification (Global Event) to event managers of other equipment (of IAV / FAV type) connected to the local bus, and in particular to the event manager of the local gateway PI connected to this local bus (step 71). All the basic functional modules hosted by the local gateway PI receive the event notification, if they have subscribed to a service for receiving such notifications (and in particular the event manager).

 Certain events do not need to be broadcast beyond the local bus. Consequently, filtering of event notifications (step 72) is carried out in the local gateway PI. In particular, the dissemination, via remote gateways, of an event notification relating to the creation or deletion on the local bus of a proxy of a remote module is prevented. Indeed, such a notification conveys local information to a given bus).

 If the event notification can be broadcast on the remote buses, the event manager of the local gateway PI sends it (step 73) to the remote gateways P2, P3 connected to the remote buses (bus 2, bus 3), under form of a proprietary message (PROP. EventForward). This sending implements the means of communication between gateways mentioned previously in the document.

 Each remote gateway (as illustrated for example for the gateway P3) receives the aforementioned proprietary message, containing the event notification which it must broadcast on the remote bus to which it is connected. The event manager of each remote gateway performs a translation (step 74) of

<Desc / Clms Page number 30>

the real address (SEID) of the sending module, in the address of the corresponding proxy (pSEID) on the remote bus to which the remote gateway concerned is connected, if at least one of the sending equipment (equipment X) and recipient (equipment to which the remote gateway sends the event notification) does not comply with standard 1394.1. This address translation mechanism, as implemented in the present step referenced 74, is illustrated by the flow diagram of FIG. 8.

The event manager of each remote gateway (as illustrated for example for the P3 gateway) sends the event manager of the remote device Y the event notification (Global Event), after possible translation of the module address transmitter (step 75).

 The last two steps, referenced 74 and 75, are carried out by each remote gateway P2, P3, for each of the remote devices connected to the same remote bus as it.

 We now present, in relation to FIG. 9, a mechanism for selecting a gateway, implemented by the gateways appearing in FIG. 1.

 The flowchart in Figure 9 describes the actions performed by the specific elementary functional module (LMWH), also called a program, specific to a given gateway, called a local gateway.

 When it is informed of an event on the local bus to which it is connected ("bus reset", change of topology) (affirmative answer to the question in step 91), the local gateway obtains information relating to this event (step 92).

 If the local gateway is the only gateway connected to the local bus (affirmative answer to the question in step 93), it continues (step 97) with processing operations described in detail below in connection with FIG. 10.

 Otherwise (negative answer to the question in step 93), one of the gateways connected to the local bus is selected, according to predetermined rules (step 94). If the local gateway whose operation is described here is the selected gateway (affirmative answer to the question in step 95), it continues

<Desc / Clms Page number 31>

 (step 97) with treatments described in detail below in relation to FIG. 10.

If it is not selected (negative answer to the question in step 95), it goes into standby (step 96).

 We now present, in relation to FIG. 10, a mechanism for managing a list of gateways within the network, for broadcasting an updated list of gateways and for transmitting a request for obtaining a list of basic functional modules. This mechanism is implemented by the walkways appearing in FIG. 1.

The flowchart in Figure 10 describes the actions performed by the specific elementary functional module (LMWH), also called a program, specific to a selected local gateway (see steps 93 to 95 of the gateway selection mechanism discussed above in relationship with Figure 9).

When it is informed of the connection of a new bridge (bridge according to HAVi terminology) on the local bus to which it is connected, and this bridge is not muted (affirmative answers to the questions in steps 101 and 102), the local gateway obtains the addresses of all the other gateways (remote gateways) of the network (step 103).

 Then, it establishes a list of all the gateways, and sends this list to all the remote gateways, in the form of a proprietary message (PROP.

UpdateHBPlist ()) (step 104).

 The processing of this list of gateways in a remote gateway is presented in detail below, in relation to FIG. 12.

 Before describing the following steps (105 to 109) of FIG. 10, we now illustrate, in relation to FIG. 11, an exemplary embodiment of steps 103 and 104 of FIG. 10 (establishment by a local gateway of a list all gateways, and send this list to all remote gateways).

 It is assumed in this example that two remote gateways, referenced P2 and P3, are each connected to a remote bus (bus 2 and bus 3) and know each other.

Thus, each of the remote gateways P2 and P3 have a list of gateways comprising these two gateways P2 and P3 (step 111).

<Desc / Clms Page number 32>

 It is assumed that a new gateway PI, called local gateway, is connected to the local bus (bus 1), and that it detects a bridge connected to this local bus (step 112).

 The local PI gateway broadcasts a keyword discovery request over the network, in order to be aware of any remote gateways. For example, it sends requests according to the DEP (Discovery and Enumeration Protocol) protocol. Each remote gateway P2, P3 returns a response (<<Keyword discovery response) (step 113).

 From these responses, the local gateway PI establishes an updated list of gateways, comprising the local gateway PI and the two remote gateways P2, P3 (step 114).

 The local gateway PI sends the updated gateway list to the remote gateways P2, P3, in the form of a proprietary message (PROP.

 UpdateHBPlistQ) (step 115).

We now return to the description of FIG. 10 (steps 105 to 109)
Via remote gateways, new equipment may be accessible. The local gateway may wish to obtain the list of elementary functional modules hosted by this new equipment. In this case, it sends an owner request to this effect to each remote gateway concerned (PROP. GetNetSEs ()) (step 105).

 The processing of such a request in a remote gateway is presented in detail below, in connection with FIG. 13.

 If the local gateway receives responses (affirmative answer to the question in step 106), in the form of lists of remote elementary functional modules, it creates the proxies of these remote modules, if necessary, and updates (step 107 ) its Registry manager. In the local gateway, this update consists in storing the proxy address of each new remote elementary functional module. This proxy can be stored alone, or in association with the real address of the new remote elementary functional module represented by this proxy.

<Desc / Clms Page number 33>

 If the local gateway does not receive a response (negative response to the question in step 106), either it waits until the expiration of a timer (step 108) before generating an error event (step 109 ), or it renews the sending of the above-mentioned owner request (PROP. getNetSEs ()).

 We now present, in relation to FIG. 12, a mechanism for processing an updated list of gateways, and for transmitting a request for obtaining a list of elementary functional modules. This mechanism is implemented by the gateways appearing in FIG. 1.

 The flowchart in Figure 12 describes the actions performed by the specific elementary functional module (HBPM), also called a program, specific to a gateway playing the role of a remote gateway. In other words, it is assumed that a local gateway has established a list of all the gateways, and has sent this list to the remote gateway whose operation is discussed here. This is done in the form of a proprietary message (PROP. UpdateHBPlistQ). (see discussion above of step 104 of the flow diagram of FIG. 10).

 By receiving the above-mentioned owner message (PROP. UpdateHBPlistQ) (affirmative answer to the question in step 121), the remote gateway can take note of new gateways (these are new at least for it). It is possible that via these, new equipment can be accessed for this remote gateway. The local gateway may wish to obtain the list of elementary functional modules hosted by this new equipment. In this case, steps referenced 126 to 129 are implemented between the present remote gateway and the aforementioned new gateways, which are identical to the steps presented above in relation to FIG. 10 and referenced 106 to 109.

 We now present, in relation to FIG. 13, a mechanism for obtaining information relating to the elementary functional modules. This mechanism is implemented by the gateways appearing in FIG. 1.

 The flowchart in Figure 13 describes the actions performed by the specific elementary functional module (LMWH), also called a program, specific to a gateway playing the role of a remote gateway. In other words, it is assumed that a local gateway has sent to the remote gateway, whose operation is

<Desc / Clms Page number 34>

 discussed here, an owner request (PROP. getNetSEs ())>), in order to obtain the list of elementary functional modules hosted by new equipment. (see discussion above of step 105 of the flow diagram of FIG. 10).

 By receiving the aforementioned proprietary message (PROP. GetNetSEs ()) (affirmative answer to the question in step 131), the remote gateway obtains (step 132) information relating to the basic functional modules from the registry managers (Registry ) hosted by the various devices on the remote bus to which the remote gateway is connected (including from the latter's Registry).

 Then, the remote gateway constructs (step 133) a response message, containing the list of elementary functional modules of the remote bus, and sends it to the local gateway which sent it the owner request (PROP. GetNetSEsQ).

 We now present, in relation to FIG. 14, a mechanism for distributing information relating to the existence of a new elementary functional module. This mechanism is implemented by the gateways appearing in FIG. 1.

 The flowchart in Figure 14 describes the actions performed by the specific elementary functional module (LMWH), also called a program, specific to a selected local gateway (see steps 93 to 95 of the gateway selection mechanism discussed above in relationship with Figure 9).

 When it is informed of an event relating to new equipment of the IAV or FAV type (affirmative answers to the questions in steps 141 and 142), the local gateway sends a registration request (query) to this new equipment, in order to '' obtain a list of elementary functional modules already installed (step 143).

 After receiving this list, the local gateway sends it to all remote gateways, in the form of a proprietary message (PROP.

 UpdateNetSEsQ) (step 144).

 The processing of this list of elementary functional modules in a remote gateway is presented in detail below, in relation to FIG. 16.

<Desc / Clms Page number 35>

 We now present, in relation to FIG. 15, a mechanism for distributing information relating to the removal of an elementary functional module. This mechanism is implemented by the gateways appearing in FIG. 1.

 The flowchart in Figure 15 describes the actions performed by the specific elementary functional module (LMWH), also called a program, specific to a selected local gateway (see steps 93 to 95 of the gateway selection mechanism discussed above in relationship with Figure 9).

When it is informed of an event relating to the disconnection of an item of equipment (affirmative answer to the question of step 151), the local gateway searches for the elementary functional modules which were hosted by this disconnected item of equipment (step 153). Each of these elementary functional modules, if it was registered in the registry manager (Registry) of the local gateway (affirmative answer to the question in step 154), is deleted in this manager. 'recording. The latter then generates, on the local bus, an event relating to the removal of this elementary functional module. (step 155)
When the local gateway is not informed of an event relating to the disconnection of a device (negative answer to the question in step 151), but it receives in return a monitoring request (MsgWatchOnQ) a response (EDEST ~ SEID) signifying that the equipment under surveillance has been disconnected, the steps referenced 153 to 155 are applied. This monitoring mechanism is a variant for detecting the disconnection of equipment.

 If it does not receive a response of the aforementioned type (EDEST ~ SEID), but has received an event relating to the removal of an elementary functional module (positive response to the question in step 156), the local gateway generates a command , so as to inform all remote gateways of this event. It sends this command to all remote gateways, in the form of a proprietary message (PROP. UpdateNetSEsQ) (step 157).

 The processing of this command in a remote gateway is presented below, in relation to Figure 16.

<Desc / Clms Page number 36>

 We now present, in relation to FIG. 16, a mechanism for processing information relating to the existence, modification or deletion of an elementary functional module. This mechanism is implemented by the gateways appearing in FIG. 1.

 The flow diagram of FIG. 16 describes the actions carried out by the specific elementary functional module (HBPM), also called a program, specific to a gateway playing the role of a remote gateway. In other words, it is assumed that a local gateway has sent to the remote gateway, the operation of which is discussed here, a proprietary message (PROP. UpdateNetSEsQ) containing: - either a list of elementary functional modules already installed (see discussion above from step 144 of the flow diagram of FIG. 14); - or an event relating to the deletion of an elementary functional module (see discussion above of step 157 of the flow diagram of FIG. 15).

 By receiving the aforementioned proprietary message (PROP. UpdateNetSEsQ) (affirmative answer to the question in step 161), the remote gateway raises the question of knowing whether at least one new elementary functional module, said new remote module (SE) ci -after, has been installed (step 162).

 If a new remote module (SE) has been installed, and if the equipment hosting it does not comply with standard 1394.1 (negative answer to the question in step 163), the remote gateway instantiates the proxy of the new remote module (pSE) (step 164). Then, it adds the proxy of the new remote module (pSE) in its registry manager (Registry). The latter then generates, on the local bus, an event relating to this proxy of the new remote module (step 165).

 If a new remote module (SE) has been installed, and the equipment hosting it complies with standard 1394.1 (positive answer to question in step 163), but if there is non-compliant equipment to standard 1394.1 on the local bus (positive answer to the question in step 166), the remote gateway performs the steps referenced 164 and 165 discussed above.

 If a new remote module (SE) has been installed, if the equipment hosting it complies with standard 1394.1 (positive answer to question in step 163), and if there is no equipment not compliant with standard 1394.1 on the local bus

<Desc / Clms Page number 37>

 (negative answer to the question in step 166), the remote gateway does not need to add the new remote module (SE) in its registration manager (Registry) (step 167). Optionally, it then generates, on the local bus, an event relating to this new remote module and / or to the new equipment which hosts it (step 168). The generation of this event is optional insofar as it has already been able to be broadcast throughout the network (via the gateways) to equipment conforming to the 1394.1 standard.

 If no new remote module (SE) has been installed, and if there is already a proxy representing the remote module considered, the remote gateway determines whether the remote module considered has been modified (step 170).

 If the remote module considered has been modified, the remote gateway updates the proxy of the remote module considered, in its registration manager (Registry) (step 171).

 If the remote module in question has not been modified, but must be deleted (positive answer to the question in step 172), the remote gateway will uninstall (i.e. delete the instance of) the module's proxy remote considered (step 173). Then, it removes the proxy of the remote module considered in its registry manager (Registry). Optionally, the latter then generates, on the local bus, an event relating to the removal of this proxy (step 174). The generation of this event is optional insofar as it has already been able to be broadcast throughout the network (via the gateways) to equipment conforming to the 1394.1 standard.

Claims (24)

 CLAIMS 1. System for managing a home audiovisual network allowing the interconnection of a plurality of equipment, in which: - said network comprises at least two buses, to each of which at least one of said equipment can be connected, and to at least one first specific piece of equipment forming a bridge, interconnecting said at least two buses, - said network conforms to a first standard relating to the interconnection of equipment via digital buses themselves interconnected by bridges, - the equipment, including the bridges comply with a second interoperability standard between equipment, defining an intermediate layer providing the interface between, on the one hand, a set of low layers, notably of communication and transport, and, on the other hand, a set application upper layers, - a plurality of elementary functional modules (SE) is hosted by said plurality of equipment, - at least one second specific gateway equipment (HBP) is connected to each bus, each gateway conforming to the first standard, - the gateways include: * means of communication between gateways and processing of information relating to the network, the equipment and the modules basic functional; * means for managing proxies of elementary functional modules; * means for providing information intended to allow an elementary functional module, called the transmitter module, hosted by an item of equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, said recipient module, hosted by a piece of equipment, said recipient equipment, connected to another bus, said remote bus, - the means of providing information are such that: * if the means of communication and of processing of information indicate that the both sending and receiving equipment <Desc / Clms Page number 39>  in accordance with the first standard, the means of supplying information supply the sending module, respectively recipient, the actual address of the receiving module, respectively sending; * if the means of communication and information processing indicate that at least one of the sender and recipient equipment does not comply with the first standard, the means of providing information supply the sender module, respectively recipient, the address of the proxy of the recipient module, respectively sender. 2. The system as claimed in claim 1, in which said second interoperability standard between devices is the HAVi standard (in English Home Audio Video interoperability). 3. System according to any one of claims 1 and 2, wherein said first standard, relating to the interconnection of equipment via digital buses themselves interconnected by bridges, is standard 1394.1. 4. System according to any one of claims 1 to 3, wherein at least one of said second specific equipment forming gateways (HBP) is included in one of said first specific equipment forming bridge. 5. System according to any one of claims 1 to 4, in which said elementary functional modules belong to the group comprising: equipment control modules (DCM); application modules (AM);

 stream management modules; resource management modules (Resource Manager); function control modules (FCM); Havlet-type modules. 6. System according to any one of claims 1 to 5, in which said means of communication between gateways and of information processing comprise means of managing a list of gateways within the network, themselves comprising, in each gateway: <Desc / Clms Page number 40>  means for detecting a connection and / or disconnection of a bridge on the bus, said local bus, to which said gateway is connected, said local gateway; means, activated in the event of detection of the connection and / or disconnection of a bridge on the local bus, of broadcasting on the network a request to discover any other gateways, called remote gateways, connected to the others buses, known as remote buses; means for receiving the responses provided by the remote gateways; means for updating a list of gateways, as a function of responses received from the remote gateways; means for sending the updated gateway list to remote gateways so that they also update their own gateway lists. 7. System according to any one of claims 1 to 6, in which said means of communication between gateways and of information processing comprises means for managing a registration request, sent by an elementary functional module, said module. transmitter, hosted by equipment, said transmitter equipment, connected to the bus, said local bus, to which a gateway, called local gateway, is connected to all the other gateways, said remote gateways, said means for managing the request for recording themselves comprising: in each remote gateway: * means for receiving said recording request; * means for obtaining and transmitting a response containing a list of elementary functional modules, called remote modules, hosted by equipment, called recipient equipment, connected to the bus, said remote bus, to which said remote gateway is connected; in said local gateway: * means for obtaining a list of elementary functional modules, called local modules, hosted by said local gateway; <Desc / Clms Page number 41>  * means for transmitting said registration request to the remote gateways; * means for receiving responses, containing the lists of remote modules, provided by the remote gateways; * means for combining the list of local modules with the lists of remote modules, so as to obtain a global list of elementary functional modules; * means for transferring said global list to the means of providing information, so that the latter provide said global list to the sending module, after having carried out a translation of the real address of each remote module into the address of the corresponding proxy , if at least one of the sending and receiving equipment does not comply with the first standard. 8. System according to any one of claims 1 to 7, in which said means of communication between gateways and of information processing comprises means for managing an event notification, emitted by an elementary functional module, said module transmitter, hosted by a piece of equipment, said transmitter equipment, connected to the bus, said local bus, to which is connected a gateway, called local gateway, to all the other gateways, said remote gateways, said means for managing the notification of event comprising themselves: in said local gateway: * means for transmitting said event notification to remote gateways; in each remote gateway: * means for receiving said event notification; * means for transferring the event notification to the means for supplying information, so that the latter distribute it to each of the elementary functional modules, called remote modules, hosted by equipment, called recipient equipment, connected to the bus, remote bus, to which said remote gateway is connected, the means of supply <Desc / Clms Page number 42>  of information performing a translation of the real address of the sending module, contained in said event notification, into the address of the corresponding proxy, if at least one of the sending and receiving equipment does not comply with the first standard. 9. The system of claim 8, wherein said local gateway further comprises means for filtering event notifications, in particular so as to prevent the dissemination, via remote gateways, of an event notification relating to the creation. or removing a proxy from a remote module on the local bus. 10. System according to any one of claims 1 to 9, in which: - at least two gateways are connected to a given bus, - the system comprises means for selecting one of said at least two gateways, called selected gateway , so that only the selected gateway actually plays the role of gateway on said given bus. 11. System according to any one of claims 1 to 9, in which:

 - At least two gateways are connected to a given bus, - the system comprises means allowing said at least two gateways to cooperate, so that said at least two gateways together play the role of gateway on said given bus. 12. System according to any one of claims 1 to 11, in which said means for managing elementary functional module proxies comprises means for creating a proxy for elementary functional module themselves comprising: in a given gateway, said local gateway: * means for receiving a first event notification relating to the creation on the bus, said local bus, to which said local gateway is connected, of a new elementary functional module; * means of broadcasting said first event notification to all the other gateways, called remote gateways; - in each remote gateway: * means for receiving said first event notification; <Desc / Clms Page number 43>  * means for creating a proxy for said new elementary functional module; means for obtaining and broadcasting on the bus, said remote bus, to which said remote gateway is connected, a second event notification relating to the creation on the remote bus of a proxy of the new elementary functional module, so as to inform all the equipment connected to said remote bus. 13. System according to any one of claims 1 to 11, in which said means for managing elementary functional module proxies comprises means for creating a proxy for elementary functional module themselves comprising: in a given gateway, said local gateway: * means for receiving a third event notification relating to the connection on the bus, said local bus, to which said local gateway is connected, of new equipment; * means of obtaining a list of elementary functional modules, called new local modules, hosted by said new equipment; * means for obtaining and broadcasting a fourth event notification, relating to said list of new local modules, to all of the other gateways, called remote gateways; - in each remote gateway: * means for receiving said fourth event notification; * means of creating a proxy for each of said new local modules; * means of broadcasting on the bus, said remote bus, to which said remote gateway is connected, a plurality of fifth event notifications each relating to the creation on the remote bus of a proxy of one of the new local modules , so as to inform all the equipment connected to said remote bus. 14. System according to any one of claims 1 to 11, in which said means for managing elementary functional module proxies comprises <Desc / Clms Page number 44>  means for creating an elementary functional module proxy themselves comprising: - in a given gateway, called local gateway: * means for detecting the connection of a new remote gateway to the network, and / or means for receipt of a sixth event notification relating to the connection of a new remote gateway to the network; * means of transmission to said new remote gateway of a request in order to obtain a list of elementary functional modules, called new remote modules, hosted by equipment, called recipient equipment, connected to the bus, called remote bus, to which is connected said new remote gateway; - in said new remote gateway: * means for obtaining and transmitting a response, containing said list of new remote modules; - in said local gateway: * means for receiving said response, containing the list of new remote modules, provided by the new remote gateway; * means of creating a proxy for each of said new remote modules; * means of broadcasting on the bus, said local bus, to which said local gateway is connected, a plurality of seventh event notifications each relating to the creation on the local bus of a proxy of one of the new remote modules , so as to inform all the equipment connected to said local bus. 15. System according to any one of claims 1 to 11, in which said means for managing elementary functional module proxies comprise means for creating a proxy for elementary functional module themselves comprising: in a given gateway, said local gateway: <Desc / Clms Page number 45>  * means for receiving an eighth event notification relating to the connection of a new remote gateway to the network, said eighth event notification containing a list of elementary functional modules, called new remote modules, hosted by equipment , said destination equipment, connected to the bus, said remote bus, to which said new remote gateway is connected; * means of creating a proxy for each of said new remote modules; * means of broadcasting on the bus, said local bus, to which said local gateway is connected, a plurality of ninth event notifications each relating to the creation on the local bus of a proxy of one of the new remote modules , so as to inform all the equipment connected to said local bus. 16. System according to any one of claims 12 to 15, in which said means for creating an elementary functional module proxy are activated, for a given elementary functional module, known as the recipient module, if at least one of the following conditions is verified: - if said recipient module is hosted by equipment which does not comply with said first standard; - If at least one piece of equipment, which does not comply with said first standard, is connected to a bus, said local bus, and hosts at least one elementary functional module, said transmitter module, capable of communicating with said recipient module; the recipient module being hosted by an equipment connected to another bus, called a remote bus. 17. System according to any one of claims 1 to 16, in which said means for managing elementary functional module proxies comprises means for removing a proxy for elementary functional module themselves comprising: in a given gateway, said local gateway: <Desc / Clms Page number 46>  * means for receiving a tenth event notification relating to the deletion on the bus, said local bus, to which said local gateway is connected, of an elementary functional module; * means of broadcasting said tenth event notification to all the other gateways, known as remote gateways; - in each remote gateway: * means for receiving said tenth event notification; * means for removing, if there is one, from a proxy of said deleted elementary functional module; * means for obtaining and broadcasting on the bus, said remote bus, to which said remote gateway is connected, an eleventh event notification relating to the removal on the remote bus of the proxy of the elementary functional module deleted, so to inform all the equipment connected to said remote bus. 18. System according to any one of claims 1 to 16, in which said means for managing elementary functional module proxies comprises means for removing a proxy for elementary functional module themselves comprising: in a given gateway, said local gateway: * means for detecting the disconnection of a remote gateway from the network, and / or means for receiving a twelfth event notification relating to the disconnection of a remote gateway from the network; * means for removing the proxy, if there is one, from each of the remote modules which are no longer accessible because they are hosted by equipment, called recipient equipment, connected to the bus, said remote bus, to which said disconnected remote gateway is connected; * means of broadcasting on the bus, said local bus, to which said local gateway is connected, a plurality of thirteenth event notifications each relating to the removal on the local bus of a proxy from one of the remote modules which are no longer accessible. <Desc / Clms Page number 47> 19. System according to any one of claims 1 to 18, in which said remote gateway further comprises: means for detecting the type of the transmitter module: simple elementary functional module or system; means of using an elementary functional module which is specific to the remote gateway and identical to the transmitter module, when the transmitter module is of the elementary system functional module type and therefore cannot have a proxy the representative hosted by the remote gateway. 20. System according to any one of claims 1 to 19, in which: a pair of gateways, respectively called local gateway and remote gateway, allows said transmitter module to communicate with said at least one recipient module, the local and remote gateways being connected to said local bus and to said remote bus respectively, - said local gateway comprises means for managing the proxy representing said recipient module, themselves comprising:

 * means for receiving and detecting a source message, originating from the sending module and intended for the proxy of the receiving module; * means for obtaining a first modified message, by replacing the address of the proxy of the recipient module with the address of the recipient module; * means for encapsulating the first modified message in a carrier message intended for the remote gateway, said message comprising information indicating an encapsulated type; * means for transmitting said carrier message to the remote gateway;

 - said remote gateway comprises means for managing the proxy representing said transmitter module, themselves comprising: * means for receiving said carrier message; * means for detecting the encapsulated type of said carrier message; * means for extracting said first modified message contained in the carrier message; <Desc / Clms Page number 48>  * means for obtaining a second modified message, by replacing the address of the sending module with the address of the proxy of the sending module; * means for transmitting said second modified message to the recipient module. 21. Gateway included in a system according to any one of claims 1 to 20, said gateway comprising: * means of communication between gateways and of processing information relating to the network, to the equipment and to the elementary functional modules; * means for managing proxies of elementary functional modules; * means for providing information intended to allow an elementary functional module, called the transmitter module, hosted by an item of equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, said recipient module, hosted by a piece of equipment, said recipient equipment, connected to another bus, said remote bus, the means of providing information being such as: * if the means of communication and of processing of information indicate that the both the sending equipment and the receiving equipment comply with the first standard, the means for supplying information supply the sending module, respectively recipient, with the actual address of the recipient module, respectively transmitter; * if the means of communication and information processing indicate that at least one of the sender and recipient equipment does not comply with the first standard, the means of providing information supply the sender module, respectively recipient, the address of the proxy of the recipient module, respectively sender. 22. Method for managing a communication between a transmitter module and at least one recipient module, within a system according to any one of claims 1 to 20, said method comprising: <Desc / Clms Page number 49>  a step of communication between gateways and processing of information relating to the network, to the equipment and to the elementary functional modules; a step of providing information intended to allow an elementary functional module, said transmitter module, hosted by an equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, said recipient module, hosted by a piece of equipment, called recipient equipment, connected to another bus, said remote bus, said step of providing information being such that: * if it emerges from the step of communication and processing of information that the sender equipment and the recipient equipment both comply with the first standard, the sender module, respectively recipient, is supplied with the real address of the recipient module, respectively sender; * if it emerges from the step of communication and processing of information that at least one of the sender and recipient equipment does not comply with the first standard, the transmitter module, respectively recipient, is provided with the address of the proxy of the recipient module, respectively sender. 23. Computer program, characterized in that said program comprises sequences of instructions suitable for implementing a method according to claim 22 when said program is executed on a computer. 24. computer program product, suitable for managing a communication between a transmitter module and at least one recipient module, within a system according to any one of claims 1 to 20, said computer program product comprising program code instructions recorded on a medium usable in a computer, comprising: - computer-readable programming means for performing a step of communication between gateways and processing of information relating to the network, the equipment and the functional modules elementary; <Desc / Clms Page number 50>  - computer-readable programming means for performing a step of supplying information intended to enable an elementary functional module, said transmitter module, hosted by equipment, said transmitter equipment, connected to a given bus, said local bus, to communicate with at least one elementary functional module, called addressee module, hosted by equipment, said addressee equipment, connected to another bus, said remote bus, said step of providing information being such that: * if it emerges from the step of communication and processing of information that the sending equipment and the receiving equipment both comply with the first standard, the sending module, respectively receiving module, is supplied with the real address of the receiving module, respectively sending module; * if it emerges from the step of communication and processing of information that at least one of the sender and recipient equipment does not comply with the first standard, the transmitter module, respectively recipient, is provided with the address of the proxy of the recipient module, respectively sender.