MXPA00012219A - Communication method in a home network, network and device for implementing such a method - Google Patents

Abstract

The invention concerns a communication method in a home network comprising at least two devices connected to a communication bus, characterized in that, a first device including an internet application and a second device including means for connecting to the internet, said second device being able to manage at least one internet application protocol, said method comprises the steps of:sending a request from said first device to said second device for opening a connection between said first and second devices, wherein said request contains an internet application protocol identifier to identify the internet application protocol to be used over said connection;sending an internet protocol request under the format of said internet application protocol from said first device to said second device;forwarding said internet protocol request from said second device to an internet server;upon receipt, transferring a response from said internet server to said first device through said second device over said communication bus. The invention also concerns a network and a device for implementing the method above.

Description

METHOD OF COMMUNICATION IN A DOMESTIC NETWORK .. THE NETWORK AND DEVICE TO IMPLEMENT THAT METHOD DESCRIPTION OF THE INVENTION The invention relates to a communication method in a home network, in particular a network that complies with HAVi. It is also related to the network itself and to a device used in the implementation of the method. The invention applies, inter alia, to communication between an internet application running on a network device which may not necessarily have direct access to the internet, and a network device which does not have such access. Figure 1 is a diagram of the different devices and software layers needed to access internet services from a personal computer 1. This computer 1 comprises an application that includes a user interface to interact with the user, for example a " RED browser ", qualified in figure 1 by the more general term" RED application ". The RED application is located above an application protocol layer (such as an HTTP (hypertext transfer protocol) or FTP (file transfer protocol) or another type of protocol). The text layers, according to the example of figure 1, are the TCP / UDP layer (transmission control protocol, respectively protocols). ^^^^ j ^ | tfMM --- of user data), the IP layer (internet protocol) and the PPP layer. The combined TCP / UDP and IP layers are referred to as the "IP stack". The connection with an Internet access provider 2 is made through modems and the public switched telephone network. The internet access provider connects to the internet which includes server 3, the latter includes globally similar layers according to the computer l. A user may possess several devices such as television receivers and personal computers which have internet access functionality provided by device 1 of figure 1. In such a case, in hardware and software required to provide the ability to access the internet is filter on each device. The object of the invention is a communication method in a home network comprising at least two devices connected to a common communication link, characterized in that a first device includes an internet application and a second device includes a means to connect to the internet , the second device is capable of handling at least one internet application protocol, the method comprises the steps of: sending a request from the first device to the second device to open a connection between the first and second devices, wherein the request contains an internet application protocol identifier for • «^ --- l --------- U -------------? identify an internet application protocol that will be used over the connection; send an internet protocol request under the application protocol format from the first device to the second device; send the internet protocol request from the second device to an internet server; before reception, transfer a response from the internet server to the first device through the second device over the common communication link. By including within the network a device which has the means to connect to the internet and which at the same time has the means to communicate with devices (or software elements such as applications) in the network, only one device is required. such capacity for the entire network, regardless of the number of Internet-related applications running on the devices of this network. In addition, an internet application that establishes an internet connection through the second specific device in itself the internet application protocol that you want to use. This provides a very flexible way to use different internet application protocols within the same network. According to one embodiment of the invention, the method of the invention includes the step of sending, by the first device to the second device, a request for a list of internet application protocols that can be carried out by the second device. The invention also relates to a home communication network comprising devices connected by a common communication link, the network comprises at least one device that includes a RED interface, the device comprises an IP stacking and a connection to the internet, at least one device comprises a programmable application interface for realizing such a NETWORK interface accessible to the customers of the software element of other devices in the network. The invention also relates to a device in a home communication network characterized in that it comprises a RED interface, the device also comprises an IP stack and a connection to the internet, at least one device comprises a programmable application interface for performing the interface of the NETWORK accessible to the clients of the software element of other devices in the NETWORK. Other features and advantages of the invention will appear through the description of a non-limiting mode of the invention, the description of which is made with reference to the following figures: Figure 1 is a schematic diagram of the devices and connections for accessing a Internet server from a home computer, - ..- Figure 2 is a diagram of a home network according to the present invention, - Figure 3 is a diagram of the messages exchanged between the NETWORK client and the NETWORK managing agent; Figure 4 is a diagram of the communication between the software elements to establish a communication between the RED client software element and a RED server via the RED managing agent. The following description uses a terminology defined in the following document, to which one can refer for additional details: "The HAVi Architecture -Specification of the Home Audio / Video Interoperability (HAVi) Architecture" of May 11, 1998, Version 0.8 and publicly described on May 15, 1998 on RED sites by at least the following companies: Sony, Philips, Toshiba, Sharp and Hitachi. Explanations and definitions regarding the terminology are also provided at the end of the present description. For additional information regarding HTTP, which will be taken as an example as the protocol used by the RED application of the present modality, the document "Hypertext Transfer Protocol / 1.1 RFC 2068" can be used as a reference. You can use other protocols other than HTTP: FTP, SMTP, POP, IMAP and NNTP are some examples.

An introduction to the architecture to the network that complies with HAVi will first be provided, in order to define various concepts necessary for the description of the embodiment of the invention. A HAVi network comprises devices which can be of four types, these devices are linked by a common communications link. The different types of devices are ordered according to their network-related capabilities: complete audio / video devices (FAV devices), intermediate audio / video devices (IAV devices), basic audio / video devices (BAV devices) , and devices prior to audio / video (LAV devices). Except for LAV type devices, all other devices have at least the ability to communicate with each other. The FAV devices contain a runtime environment for the HAVi octet code. The HAVi octet code is a programming language in which you can write device control modules (DCM) or applications. An FAV device must therefore lower the DCMs of other devices which do not include this runtime environment, for example for cost reasons. IAV devices do not have the ability to run the HAVi octet code, but can include resident DCMs for the control of other devices.

The BAV devices are devices which contain a DCM code that can be downloaded by a FAV device, or which are controlled by a native DCM that runs through an IAV device. LAV devices are devices which do not have any HAVi capability. These devices have their own instruction protocol and require that a FAV or an IAV device act as a gateway to the HAVi network and perform the necessary translation of the control instructions. Each device contains several objects, called "software elements" in the HAVi terminology. A control manager of a given function (called FCM) of a device, that is, a software element provides an interface to control a specific functional component (eg tuner, display, mass storage ...) of a device is one of such objects. A DCM, as mentioned before, is another. Typically, a FAV device may contain several applications and device control applications which interact with the following software elements through corresponding application programmable interfaces: A 1394 media manager which allows other software elements to perform communications asynchronous over the IEEE 1394 common link; - a message passing system, to exchange messages with other software elements; a process manager to manage object state changes; a current manager to manage audio / video data streams between functional components, such as a tuner and a recording device; a registry, which maintains a list of local software elements and their identifiers and manages communication with distant registries; a device control module manager, for loading or deleting device control modules; a number of any resident or uploaded device control module; a runtime environment of HAVi octet code to execute the DCMs. The message passing system assigns unique identifiers to software elements which use these identifiers to register themselves in the Registry. These identifiers are also referred to as "SEID", which means identifiers of software elements, and comprise a device identifier and a software element handler within this device. A first software item that wishes to send a message to a second software item will pass the SEID of this second software item as a parameter in its instruction to the message passing system. You get this SEID when you make an appropriate request in the Local Registry service. Depending on whether the software item to be called is local or remote (that is, on another device than the calling software element), the software calling element will use the entire SEID or only its handling part. software element. The mapping of function calls into messages of the Message Passing System is described in detail in Chapter 3.2.3 of the HAVi 0.8 document. The message passing system described in this version of the HAVi document can handle messages up to 64 Kb long. The French patent application FR 9805110 filed on April 23, 1998 in the name of THOMSON multimedia provides additional information about the registration and message passing system. Figure 2 represents a home network in accordance with HAVi comprising the devices 20, 21 and 22 connected to a common communication link 23. In the common link 23 is, for example, an IEEE 1394 serial common link. The device 20 is a digital television receiver, compatible with the digital video broadcast (DVB) standard in use in Europe or the Direct Satellite System. (DSS) in use in the United States. It comprises a network application, that is, a software application capable of sending or requesting, or both, data through the Internet using the HTTP protocol. For the purpose of the present example, the RED application of the device 20 is an electronic program guide (EPG) that exchanges information with a .1 it server given of internet. Device 22 is a personal computer, whose RED application is an internet browser. None of the devices 20 and 22 possess an IP stack, the PPP protocol layer or a modem connected to a public switched telephone network. The device 21 comprises an application program interface for accessing the NETWORK (API for access to the NETWORK), as well as IP stacking, the PPP protocol and a modem. The device 21 can be a FAV, IAV or BAV device. The functional component module (FCM) provides access to the IP stacking operation by the different RED applications if it is called "Internet managing agent" or "RED managing agent". It provides the programmable interface of the access application to the NETWORK, which is the layer above the IP stack. According to the present example, the device 21 is a digital television decoder comprising a modem. The FCM managing RED offers compatible access to the internet. It is recorded when it is restarted or when it is directly connected to the Local Registry of the device 21, if this device is a FAV or IAV, or to the local register of the FAV or IAV device which executes the Control Module of the device corresponding to the managing FCM of RED if the device 21 is of type BAV. * x * ? *? . *.

The RED application, which can also be called the "RED client", is capable of detecting the network management FCM in the network when sending a request to its local registry service. The local Registry sends the request to the distant Registries and collects the answers. In the case of the present embodiment, only the identifier ("SEID") of the network management FCM of device 21 will be detected. The network management FCM preferably supports, at least several internet protocols, commonly used, such as HTTP, FTP, NNTP, SMTP, POP or IMAP. The RED client uses the programmable protocol of the FCM application for managing the network through the message passing system. The programmable application interface includes the following functions: Open, Close, Send, Receive and Acquire capacity. These different functions will now be described in detail. The following data structures are used by the functions of the network management FCM: (a) enum FileLoc. { START, NEXT, END}; This data structure indicates whether the message from a producer to a consumer is the first message, an intermediate message or the last (or only) message in a message sequence. It is used together with the notion of buffer size in the NETWORK client or in the NETWORK MANAGEMENT FCM, since this buffer size, as explained below, can cause a function call to be divided over several messages. (b) enum ProtocolType. { HTTP, FTP, SMTP, P0P3, IMAP4, NNTP, WAIS}; This data structure indicates the view of the network application protocols that the network management FCM can support. The functions in the list below are implemented in the present system. (a) "Open" function This function allows the network client to open a connection with a network management FCM. The prototype function is defined as follows: Status WEBProxy:: Ope (in ProtocolType protocol in short client_buffer_size, in OperationCode opCode, out long cid, out short proxy_buffer_size,) "Status" is the function return value type. The following parameters are used: protocol: this parameter, established by the NETWORK client, defines the protocol (HTTP ...) dedicated to the session that the NETWORK client wishes to open. client_buffer_size: this parameter, established by the NETWORK client, provides the maximum size of a message accepted by the NETWORK client, in other words, the size of its message buffer. The network management FCM will use this parameter to define the size of the messages sent to the client. The data that will be sent by the FCM managing RED will be divided into several blocks of data, depending on this parameter. opCode: this parameter is a code that the network's FCM will use to direct a response that comes from the internet to the RED's client. This operation code identifies a function of the NETWORK client to which the FCM managing REDM must request to direct a response to the client. This parameter is established by the NETWORK client. In the present case, the opCode value identifies the "receive" function. The operation code uniquely identifies a function within a software element. The unique address of a function in the network therefore comprises the identifier "SEID" and the operation code. cid: this parameter is an identifier of the connection between the network client and the network management FCM. It is defined by the FCM managing RED. Allows multiple connections to be opened in parallel from the same software component of the ----- i ----- ¿-i ---- tt ---_? client (with the same FCM managing RED or with other FCM managing RED) and also allows to match a response from the Internet with a request. proxy_buffer_size: this parameter, returned by the network management FCM, indicates the maximum size (in octets) of a message accepted by the network management FCM. The RED client will use this parameter to determine the size of the messages, for example the requests, sent by the RED client to the REDM managing FCM. After receiving the "Open" function from a NETWORK client, the NETWORK MANAGEMENT FCM will return, together with the previous parameters, one of the following status values: "0" in the case of a successful session opening, "1" in the case of a resource allocation error, "2" if the type of protocol is not supported by the NETWORK client. (b) "Close" function This function allows the network client to close a connection previously opened with a network management FCM, identified by the "cid" parameter. The function prototype is defined as follows: Status WEBProxy:: Open (in long cid) The only parameter is the "cid" parameter, that is, the identifier of this connection with the network management FCM. The network management FCM recognizes one of the following status values: 0: The connection has been successfully closed, l: The transmitted value of the "CID" parameter is unknown. (c) "Send" function This function is requested by a NETWORK client to send a request to a NETWORK server using the protocol (previously defined by the "open" function request.) The function prototype is defined as follows: Status WEBProxy:: Send ( in long cid, in FileLoc where, in sequence < byte > web_data,) In addition to the "cid" parameter defined in advance, the function parameters are as follows: - where: this parameter, determined by the software element that performs the request, indicates whether the message is the ..... -yy-. xs.x ,. first message, an intermediate message or the last message in a message sequence. More than one message may be required to request this function, since the amount of data transmitted in the function request may be too large for the network managing FCM buffer to handle in a single message. web_data: this parameter contains a part of the total request according to the "application" protocol of the RED used through the connection identified by the "cid" parameter. Upon receiving the function call, the network management FCM recognizes one of the following status values: "0" if the message has been processed successfully, "1" if the size of "web_data" exceeds a fixed maximum size, "2"if it is impossible to process this message," 3"if the transmitted value of the" cid "parameter is unknown to the network management FCM. In the case of error, the RED client decides whether or not to close the connection or if he sends the previous message again. (d) "Receive" function This is the prototype of the function implemented in the NETWORK client, which allows the REDM managing FCM to send the NETWORK client an incoming response, according to the RED's application protocol. The function prototype is defined as follows: Status WEBProxy :: Receive (in long cid, in FileLoc where, in sequence < byte > web_data,) In addition to the parameters defined in the above, the following parameter is used hereby function: we _data: contains a part of the totality of the response according to the "application" protocol of RED used through the connection identified by the parameter "cid". After the call by the management server of NETWORK, the NETWORK client recognizes one of the following status values: "0" if the message has been processed successfully, "1" if the data size exceeds a fixed maximum size, "2" if it is impossible to The RED client will process this message, "3" if the RED client does not recognize the value of the "cid" parameter.

In the case of error, the FCM managing RED does not react. It is until the client of the NETWORK decides whether to maintain the connection or not. (e) "Acquire capacity" function This function, which can be requested by the NETWORK client, returns the list of protocols which can be executed by the network management FCM. The function prototype is as follows: Void WEBProxy:: GetCapability (out sequence <ProtocolType> ProtocolList) The only parameter of the function is "ProtocolList", which is the list of the network application protocols which are available through the FCM. More than one protocol can be executed by the network management FCM. Figure 3 provides an example of a typical message exchange between a NETWORK client and a NETWORK managing FCM. At the level of the message passing system, a function call can activate messages in two directions: a first message from the software element calling, the software element called in parameters "in union" sent to this called software element, and a second message in the reverse direction , to push back "united outside" parameters, if required. -------? ------------- £ i ------ The "open" function, as illustrated in figure 3, generates a first message from the client of the NETWORK to the FCM managing RED. This message informs the managing FCM of NETWORK of the protocol which will be used on the connection which is going to be opened, and the size of the buffer memory which is assigned to the NETWORK client for the return messages for that particular connection. The buffer sizes may be different from one connection to another. The RED client also transmits the operation code of the Receive function, which must be used by the network managing FCM to call or request the "receive" function in the RED client. At the message passing system level, the RED client also transmits its own identifier "SEID". Assuming correct reception and processing, the network management FCM responds to the return code "0" to indicate successful processing, sends a "cid" value to identify the connection, and also transmits its own buffer size for additional communication. Once the connection is opened, the RED client continues to send a request to the NETWORK server using the HTTP protocol. In accordance with the Example of Figure 4, this request is maintained in a single message, which contains the cid connection identifier, the request under the HTTP format and the "End" parameter. The FCM managing RED recognizes its own receiver, and sends the request over the internet via IP stacking and modem. ,. ^. t _--- «,, .---- ..

The RED server will respond with the requested data and will transmit it to the network managing FCM since, in the present example, the amount of data is much higher than the capacity of the network client buffer, the REDM managing FCM divides the data into messages of appropriate size. The network management FCM sends a first block of data as a parameter within the Receive merge call, using the operation code previously obtained from the NETWORK client, attached to the "SEID" identifier of the NETWORK client. Use "START" as a parameter. The additional messages are only sent after acknowledgment of reception by the NETWORK client, to provide the time to process the received data and to empty its buffer. After receiving the last data block, the RED client closes the connection using the Close function. The managing FCM of RED responds with a last acknowledgment of reception. Finally, according to the present modality, the configuration of the network management FCM, for example of the modem connection, is carried out directly by the user through a graphical interface provided by the device control module which manages the FCM managing RED. There is no programmable application-specific interface for this task, which can be carried out using a data driven interaction mechanism (DDI) provided by the HAVi specification.

Glossary AV base device (BAV) A device that complies with HAVi, which contains data HAVi SDD, but that does not run any of the software elements of the HAVi architecture.

Controller A device which controls other devices. An IAV or FAV.

Data Driven Interaction (DDI) A HAVi mechanism that allows the control of software elements, for example DCMs, via user interface elements such as buttons and icons.

DDI controller A software entity which returns to the DDI elements the user interaction without handling.

DDI element The DDI that encodes a user interface element.

DDI protocol HAVi messages that support data-driven interaction.

Device A physical entity linked to the home network, the examples are video players, recorders, cameras, CD and DVD players, top boxes, DTV and PC receivers.

Device control application A HAVi software element that allows the user to control a specific device (and its functional components). Installed on request and possibly in a controller different from the one in which the DCM is installed.

Device control module (DCM) A HAVi software element that provides an interface to control general functions of a device.

DCM code unit A HAVi byte code unit that is to be loaded and installed in an FAV, or a proprietary code unit to be installed in a FAV or IAV. The installation of a DCM code unit results in a DCM and one or more FCM, and possibly a device control application.

Embedded DCM A DCM implemented in a native code (ie, platform dependent). Embedded DCMs typically run on IAV devices.

Complete AV device (FAV) A device that complies with HAVi which runs software elements of the HAVi architecture that include a HAVi byte code execution time. ^^? y ^ Functional component An abstraction within the HAVi architecture that represents a group of related functions associated with a device. For example, a DTV receiver may consist of several functional components: tuner, decoder, audio amplifier, etc.

Functional component module (FCM) A HAVi software element that provides an interface to control a specific functional component of a device.

Global unique ID (GUID) An amount of 64 bits used to uniquely identify an IEEE 1394 device. It consists of a 24-bit company ID (obtained from the Registration Authority Committee 1394) and a 40-bit serial number assigned by the manufacturer of the device. The GUID is stored in a device configuration ROM and is persistent over 1394 network restarts.

HAVi Architecture The HAVi architecture includes the message sending model, control model, device model and execution environment defined in this document.

HAVi octet code A representation of portable code used when uploading the DCM and possibly by applications. The FAV devices contain a runtime environment to load and execute the HAVi octet code. The HAVi octet code has not yet been specified but will be selected from the existing candidates.

Device in accordance with HAVi A device that supports IEEE 1394, IEC 61883 and in accordance with the HAVi architecture specification for a FAV, IAV or BAV device.

Inability to HAVi level 1 It refers to the characteristics provided by the BTIs and the embedded DCMs.

----------- HAVi level 2 inoperability It refers to the characteristics provided by the AVFs and the DCMs uploaded.

HAVi SDD data Data from self-describing devices (SDD) that are stored in the IEEE 1212 configuration ROM that is found on 1394 devices. HAVi specifies SD data items that can be used for DDI items or uploaded MCDs.

Unique ID of HAVi (HUID) A unique identification of devices and their functional components. Persistent about changes in network configuration (ie, connection and disconnection of the device).

Home network The home network is the generic name used to define the communications infrastructure within a house.

This name is used as an abstraction of the physical media and associated protocols. A home network supports both exchange and control information and the exchange of AV content.

Intermediate AV device (IAV) A HAVi compliant device, which executes the software elements in the HAVi architecture but does not include a HAVi octet code runtime environment.

Device prior to AV (LAV) A device that is not in compliance with HAVi.

Software element A HAVi object. A software element responds to a set of messages specified by the API for that element.

Software item ID (SEID) A value of 80 bits used to identify software elements. It is not guaranteed to be persistent about changes in network configuration (ie, connection or disconnection of the device).

DCM uploaded A DCM implemented in a HAVi octet code. Uploaded DCMs are only executed on FAV devices.

Claims (10)

1. A communication method in a home network, comprising at least two devices connected to a common communication link, in which a first device includes an internet application and a second device includes a means to connect to the internet, the second device is capable of handling at least one internet application protocol, the method comprises the steps of: sending a request from the first device to the second device to open a connection between the first and second devices, wherein the request contains a Internet application protocol identifier to apply the internet application protocol to be used over the connection; - send a request for internet protocol under the format of the internet application protocol from the first device to the second device; - send the internet protocol request from the second device to an internet server; - before reception, transfer a response from the internet server to the first device through the second device over the communication common link. • • ** "> -.

2. The method as described in claim 1, wherein the request includes the message buffer size assigned to the connection by the first device.

3. The method as described in claim 1 or 2, wherein the recognition of the reception includes the message buffer size assigned to the connection by the second device.

4. The method as described in one of claims 2 or 3, wherein the sending device divides the data to be sent to a receiving device into messages of a size which is smaller than the size of the buffering memory. message from the receiving device.

5. The method as described in one of claims 1 to 4, which further includes the step of sending, by the first device to the second device, a request for a list of internet application protocols that can be carried out by the second device.

6. The method as described in one of claims 1 to 5, further comprising the step of sending, by the first device to the second device, an address of a first device function, the second device sends internet responses to the first device as parameter of a call of such a function.

7. The method as described in one of claims 1 to 6, wherein the second device allocates a connection identifier to a connection requested by the first device, the connection identifier is sent from the first device to the second device in recognition of reception of such request to open the connection.

8. The method as described in claim 7, wherein the first and second devices systematically use the connection identifier as a parameter for function calls by the first device to the second device or vice versa.

9. A home communication network, comprising devices connected by a common communication link, the network is characterized in that it comprises at least one device that includes a RED interface, the device comprises an IP stack and a connection to the Internet, so less a device comprises a programmable application interface to make the interface accessible to the NETWORK with the software elements of the clients of other devices in the network.

10. The device in a home communication network, characterized in that it comprises an interface with the network, the device also comprises an IP stack and a connection to the internet, at least one device comprises a programmable application interface to make the RED interface accessible to customers of software elements of other devices in the network.