EP3238384A1 - Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique - Google Patents

Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique

Info

Publication number
EP3238384A1
EP3238384A1 EP15823713.1A EP15823713A EP3238384A1 EP 3238384 A1 EP3238384 A1 EP 3238384A1 EP 15823713 A EP15823713 A EP 15823713A EP 3238384 A1 EP3238384 A1 EP 3238384A1
Authority
EP
European Patent Office
Prior art keywords
server
electronic control
control unit
message
communication protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP15823713.1A
Other languages
German (de)
English (en)
Inventor
Sylvain POGNANT
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Overkiz SAS
Original Assignee
Overkiz SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Overkiz SAS filed Critical Overkiz SAS
Publication of EP3238384A1 publication Critical patent/EP3238384A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/255—Maintenance or indexing of mapping tables
    • H04L61/2553—Binding renewal aspects, e.g. using keep-alive messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/256—NAT traversal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage

Definitions

  • the present invention relates to a method of data transmission between a server and an electronic control unit of a home automation system.
  • Each electronic control unit of a home automation system is disposed on a private network, whose access is usually protected by a firewall. It may be desirable to carry out these data exchanges in particular to operate a remote control of the installations by the server, for example in the case where the server receives instructions from a user interface allowing the user to remotely control his installation.
  • a specific configuration of the firewall can be made to allow connection establishment at the initiative of the server.
  • this requires an intervention on each firewall and an authorization to perform the intervention.
  • connection mechanism at the initiative of the electronic unit can be used, the connections thus established being maintained by the server in order to route the data from the server to the electronic control unit. It appears, however, that this second possibility leads to a significant use of resources on the server which must maintain the data relating to all the connections corresponding to each electronic unit.
  • the present invention aims to solve all or part of the disadvantages mentioned above.
  • the present invention relates to a method for transmitting data between a server and an electronic control unit of a home automation installation comprising the following steps:
  • the first protocol being a protocol in non-connected mode
  • the second protocol corresponding to a communication in connected mode
  • the establishment of the connection according to the second communication protocol is carried out at the initiative of the electronic control unit to the server, following the request for connection opening formulated by the server according to the first protocol.
  • connection will be authorized by the firewall because it is the initiative of the electronic control unit.
  • the server can then use the connection according to the second protocol to communicate the useful data corresponding to its request to open a connection in the message down.
  • the use of two communication protocols makes it possible to use a simpler first protocol involving a low use of resources on the server, and a second connected protocol involving a greater use of resources only when information must be communicated by the server.
  • the first protocol is a non-connected mode protocol.
  • the second protocol corresponds to a communication in connected mode.
  • the first protocol used may be of various types so as not to be subject to the constraints imposed by the firewall.
  • the first communication protocol is a protocol comprising sending a message from the server to the electronic control unit, in particular an SMS message.
  • the first protocol corresponds to data provided in an audio and / or video stream, for example an MPEG stream.
  • the term amount relates to the messages transmitted by the electronic control unit to the server and that the term descendant concerns the messages transmitted by the server to the electronic control unit.
  • the method comprises a first step of periodically transmitting an uplink message according to the first communication protocol by the electronic control unit to the server; the first step of receiving a connection opening request message comprising a reception step according to the first protocol of at least one descending message subsequent to the first transmission step.
  • the sending of a rising message enables the server to respond to this message with a message that can reach the message.
  • electronic unit as it will be considered as a response to the message amount.
  • the periodic sending of the amount message offers windows of time to the server to communicate connection opening requests.
  • a periodicity of the messages below the window of time allowed by the firewall to respond to a rising message it is possible to permanently maintain a possibility of communication from the server to the electronic control unit, ie ie an open communication channel.
  • a periodic sending makes it possible to know the state of the network link between the electronic control unit and the server.
  • the method comprises, prior to the first step of receiving a connection opening request, a reception step according to the first protocol of communication by the electronic control unit of a downlink message from the server corresponding to an accessibility response;
  • the preliminary step and the second step can be simultaneous, successive and / or have a time recovery period.
  • the prior reception step corresponds to the reception of an accessibility response according to a first delay after the transmission step, in order to maintain the possibility of receiving a second frame according to a second delay.
  • the second step corresponds to receiving a connection request during said second delay.
  • the method comprises a step of monitoring at least a delay of reception of a downlink message from the server following the first transmission step, the triggering of a new first transmission step. being triggered if the reception time is exceeded.
  • the method comprises a step of transmitting an upstream message to the server according to the second communication protocol following the connection establishment step and previously to the second reception step of a descending message;
  • the server may in a downlink response according to the second protocol communicate the useful data corresponding to its request to open connection.
  • the method comprises a step of releasing and / or accepting the release of the connection according to the second communication protocol after a determined number of transmissions of upstream messages and / or of receiving downstream messages. according to the second communication protocol or after a delay determined after the communication establishment step.
  • This communication mode is suitable for home automation applications in which a large number of electronic control units are connected to a server with a small volume of data to exchange with it.
  • the release of the connection can be made according to the case on the initiative of the server or the electronic control unit.
  • a single exchange according to the second protocol comprising an upstream application message and a downward application message is provided before releasing the connection.
  • a single downstream application message is received before the connection is released.
  • the method comprises a step of transmitting an encryption key by the electronic control unit to the server, so as to enable a signature of the upstream and / or downstream messages according to the first communication protocol and / or according to the second communication protocol.
  • the method comprises a step of receiving an invalid or expired key indication from the server, and in response a new step of transmitting an encryption key.
  • the present invention also relates to a method for transmitting data between a server and an electronic control unit of a home automation installation comprising the following steps:
  • the method comprises a first step of periodically receiving a rising message according to the first communication protocol by the server from the electronic control unit; the first step of transmitting a connection opening request message comprising a step of transmitting at least one subsequent downlink message to the first reception step.
  • the method comprises, prior to the first step of transmitting a connection opening request, a prior step of transmission by the server to the electronic control unit of a message descendant corresponding to an accessibility response.
  • the method comprises a step of receiving a message originating from the server from the electronic control unit according to the second communication protocol following the connection establishment acceptance step and previously to the second transmission step of a downlink message;
  • the method comprises a step of releasing and / or accepting the release of the connection according to the second communication protocol after a given number of reception of sender messages and / or messages transmission according to the second communication protocol or after a delay determined after the communication establishment acceptance step.
  • the first communication protocol is the UDP protocol.
  • the second communication protocol is the TCP protocol.
  • the first and / or the second protocol may be of the Raw IP or other protocol type above IP.
  • the present invention also relates to a computer program product comprising portions of program code for executing the steps of a method of data transmission by an electronic control unit as described above.
  • the present invention also relates to an electronic control unit of a home automation installation comprising a processing unit arranged to contain and execute the computer program product according to the preceding claim, the electronic control unit further comprising at least one interface of communication intended for the control and / or the control of at least one actuator, in particular of a mobile element of a building, or of another equipment that can be controlled or controlled electrically or electronically, such as for example an alarm system, or at least one sensor, and a communication interface for communication according to the first communication protocol or the second communication protocol with a server.
  • the present invention also relates to a computer program product comprising portions of program code for executing the steps of a method of data transmission by a server as described above.
  • the present invention also relates to a server for controlling and / or remote control of at least one electronic control unit of a home automation installation comprising a processing unit arranged to contain and execute the computer program product according to the preceding claim, the server further comprising at least one communication interface for communication according to the first communication protocol or the second communication protocol with at least one control unit electronic.
  • the server may also include a communication interface for communication with a user interface.
  • the user interface may for example be formed by a web server communicating with a user terminal, for example a computer, a mobile phone or a tablet.
  • the present invention also relates to a distributed system comprising at least one server and a plurality of electronic control units arranged to communicate with the server so as to implement the method as described above.
  • Figure 1 is a diagram illustrating the structure of a system for implementing a method of data transmission between a server and a set of electronic control units home automation systems.
  • Figure 2 is a diagram illustrating a mode of implementation of a data transmission method.
  • Figure 3 is a diagram illustrating an additional step of the method of Figure 2.
  • Figure 4 is a diagram illustrating the structure of a second system for implementing a method of data transmission between a server and a set of electronic control units home automation systems.
  • a distributed system comprises at least one server S and a plurality of electronic control units U of home automation systems arranged to communicate with the server S so as to implement a transmission method of data.
  • Each electronic control unit of a home automation installation is disposed on a private network PN, PN ', whose access is generally protected by a firewall FW.
  • the server S is also arranged on a private network NS.
  • the private networks PN, PN ', SN are connected to an extended network N, for example the Internet.
  • an electronic control unit U of a home automation installation comprises a processing unit 2 arranged to contain and execute a first computer program.
  • the processing unit 2 comprises a processor, a storage flash memory and a random access memory, and an Ethernet chip PHY.
  • the electronic control unit U furthermore comprises at least one communication interface 3 intended for the control / control of movable element actuators of a building, sensors, or other equipment with electrical or electronic control such as an alarm system.
  • the communication interface 3 allows the control and the control of at least one actuator 5, 5 'of a movable element of a building, for example a roller shutter 6 or a sunshade 6'or still the reception of information of a sensor 7 providing information of a user's presence or values of surrounding parameters such as temperature, humidity, brightness.
  • the interface can allow the control / command of an alarm system 8.
  • the communication interface 3 may comprise a radio frequency chip lo-homecontrol and / or Zwave and / or WM-Bus communicating at a frequency of 868 MHz, and / or a radio frequency chip RTS / RTD / RTD + communicating at a frequency of 433 Mhz.
  • the electronic control unit U furthermore comprises a battery and / or a mains power supply, as well as physical connection ports such as, for example, USB host, RJ45 and micro-USB.
  • the electronic control unit U also comprises interface elements such as reset buttons, configuration buttons, touch screen launch buttons, and / or operating indicator lights, such as LEDs.
  • the electronic control unit U furthermore comprises a communication interface 4 intended for communication according to the first communication protocol P1 or the second communication protocol P2 with a server S.
  • the server S which allows remote control and / or control of the plurality of electronic control units U of a home automation installation comprises a processing unit 102 arranged to contain and execute a second program.
  • the server S further comprises at least one communication interface 104 intended for communication according to the first communication protocol P1 or the second communication protocol P2 with the plurality of electronic control units U.
  • the server S may also comprise a communication interface 106 intended for communication with a user interface 107.
  • the user interface 107 may for example be formed by a web server communicating with a user terminal 108 via the network N, for example a computer. , a cell phone or a tablet.
  • FIG. 2 represents an implementation diagram of the data transmission methods executed on the server S and on an electronic control unit U of a home automation system I.
  • the method comprises a first phase PhO for negotiating a secret key, a second phase Ph1 produced according to the first communication protocol intended to collect a connection request from the client. server S and a third phase Ph2 data transmission following the establishment of a connection according to the second communication protocol at the initiative of the electronic control unit.
  • the negotiation phase of a secret key PhO includes a step E0 transmission of an encryption key in a message Mkey by the electronic control unit U to the server S which receives it during a step E0 ', so as to enable a signature of the upstream and / or downstream messages according to the first communication protocol P1 and / or according to the second communication protocol P2.
  • the encryption key may in particular be chosen randomly by the electronic control unit U.
  • the server acknowledges receipt of the key and validates that it has taken into account the new key by a MkeyAck downlink message transmitted in a step E1 'which is received by the electronic control unit U during a reception step E1 .
  • the exchanges between the electronic control unit U during the negotiation phase can be carried out according to a communication protocol different from or similar to the first communication protocol and the second communication protocol P1 and P2.
  • a communication protocol different from or similar to the first communication protocol and the second communication protocol P1 and P2.
  • HTTPS type protocol can be chosen which makes it possible to communicate the key in a secure manner.
  • this exchange is not carried out frequently, and therefore does not represent a significant consumption of resources. For example, a periodicity of several days can be provided for the validity of the keys.
  • the second communication phase Ph1 according to the first protocol P1 comprises a first step E2 periodic transmission of a message Mping up according to the first communication protocol P1 by the electronic control unit U to the server S which receives it in a step E2 '.
  • a periodicity of the order of ten seconds can be provided for the periodicity of the transmission, and in particular of the order of 20s.
  • the server S transmits in a step E4 'a Mpong downlink message to the electronic control unit U which is received in a prior receiving step E4 within a first delay Dr1 short after transmission of the Mping amount message.
  • the delay Dr1 can be of the order of a few seconds, and in particular of the order of 5 s.
  • This first message Mpong down keeps the communication channel open for a second delay Dr2 greater than the first delay Dr1. It appears that the operation of a firewall Usual can prevent the passage of a descending message to the extent that it is received beyond a first time after sending a rising message. Also in the usual way, since a first descendant message is received, a second, larger delay is allowed to receive one or more other descendant messages. In particular, it is possible to choose to trigger a new transmission of the message Mping before the expiry of the delay Dr2.
  • the server S has useful data DU to be transmitted to the electronic control unit U, it transmits according to the first communication protocol P1 during a step E5 'a request message D Mopen connection opening, which is received by the electronic control unit U during a step E5.
  • the second communication phase Ph1 according to the first protocol P1 comprises a monitoring step E3 of a reception delay Dr of a downlink message from the server S following the first transmission step Mping, the triggering of a new first E2 transmission step being performed in case of exceeding the reception time.
  • the server can perform a transmission step ERO 'of an invalid or expired key indication Minvalidkey from the server S, and in response a new step of transmission of a key of E0 encryption.
  • this situation can occur during the transmission of a message amount MPing, the server having found that the message has a correct format but is not signed with a valid key. It should be noted that in case of restart of the electronic control unit, the first phase of communication PhO with communication of the key is carried out again.
  • the first communication protocol may in particular be the UDP protocol.
  • the third phase Ph2 of the method is performed following the reception of the connection opening request received by the electronic control unit in the second phase in step E5.
  • an E6 establishment step of a Cnx connection to the server S which accepts this connection in a step corresponding E6 ' is performed, at the initiative of the electronic control unit U according to a second connection protocol P2.
  • the communication protocol may be the TCP protocol.
  • the establishment step E6 may comprise several exchanges between the server and the unit U, and in particular exchanges of connection management messages, such as the TCP SYN, SYN / ACK, ACK protocol messages.
  • a transmission step E7 of an amount message MRq is carried out according to the second communication protocol P2 intended for the server S which receives this message in an AND step.
  • the MRq message may be a message without useful data but constituting an amount message to which a response may be sent by the server.
  • the server transmits a MRp downlink message in a transmission step E8 'to the electronic control unit U.
  • This downlink message contains the useful data DU that the server was to transmit to the electronic control unit.
  • the second communication protocol used may be in particular the TCP protocol.
  • the exchanges of the steps E7 / E7 'and E8 / E8' can in particular be made in the form of a request and a response according to the HTTPS protocol that uses TCP.
  • the release of the connection can take place after several exchanges of uplink messages and / or messages receiving messages according to the second communication protocol or after a specified delay after the step of establishing the connection. E6 communication.
  • the first communication protocol is an SMS-type protocol comprising sending a message from the server to the electronic unit.
  • U control identified in this case by a telephone number.
  • This second protocol is used on a N2 type telephone network, for example a GSM network or wired telephony over the Internet, with a digital message management function.
  • the server S comprises a communication interface 107 on the network N2, for example a GSM card, just like the electronic control unit, which also comprises a communication interface 7 on the network N2, such as a GSM card. or an internet telephony hardware and software module that can be integrated into the firewall or the electronic control unit U.
  • the exchange according to the first protocol and the step of receiving a connection opening request corresponds to a simple sending of SMS between the server S and the electronic control unit U.
  • FIG. 4 represents only an electronic control unit, but this second embodiment naturally applies to communication with a multitude of electronic control units.
  • the first protocol used may be of various types making it possible not to be subject to the constraints imposed by the firewall.
  • the first protocol corresponds to data provided in an audio and / or video stream, for example an MPEG stream.
  • the electronic control unit U comprises or is associated with a decoding interface of the corresponding audio and / or video stream.
  • the first and / or the second protocol may be Raw IP type or other protocol above IP.
  • the application exchanges may follow the transaction model, comprising a request and a response. Queries are sent as upstream messages, and responses as descendant messages. Thus, in a request and answer exchange in the form of a rising or falling message, only the response or only the request may contain useful data. A rising message and the downlink message sent back may contain useful data that does not necessarily correspond to the same transaction. For example, a request in progress requiring an application processing is transmitted as a rising message, and may trigger the transmission of a downlink message without useful data, or containing useful data relating to a previous request. In the same way, the application response corresponding to the current request can be sent during an exchange subsequent amount / message message. This exchange may include a rising message without useful data.
  • the transmission of data in the sense of the electronic control unit to the server can be achieved for example according to the second communication protocol without difficulty since it is possible to establish a connection directly at the initiative of the electronic control unit.
  • a request and a response according to the HTTPS protocol can be performed, then the established connection released to limit the use of server resources.
  • the first protocol is the protocol
  • the messages are transmitted in UDP datagrams.
  • a message may correspond to a UDP datagram.
  • the body of the UDP datagram consists of a single frame encoded in UTF-8.
  • the general form of the format of the frames comprises a first block called BODY, a second block SEQUENCE and a last BLOCK of SIGNATURE, these blocks being separated by separators / and% as is represented below:
  • the BODY block has the following general form:
  • the TYPE field includes message type information that can be: PING (for a Mping message), PONG (for a Mpong message), OPEN (for a Mopen message), INVALIDKEY (for a Minvalidkey message).
  • the field SERIAL includes the serial number of the electronic control unit U.
  • the TIMESTAMP field includes a time stamp, for example a UNIX Timestamp corresponding to the number of seconds since EPOCH, calculated by the sender of the message.
  • the block BODY has the following structure:
  • the field ACTIVITYJNTERVAL corresponds to the maximum number of seconds between two activities of the electronic control unit U, that is to say a transmission to the server according to the first or the second communication protocol.
  • the electronic control unit U must send a Mping message immediately after it has been started, then must then regularly: either issue a new Mping message or establish a Cnx connection to confirm its presence with the server.
  • the BODY block has the following structure:
  • the NEW_ACTIVITY_INTERVAL field includes a new value (in seconds) for the desired activity period.
  • the server must return a Mpong message for each Mping message received.
  • the electronic control unit U must update its value accordingly.
  • the BODY block has the following structure:
  • the server sends a message Mopen to the electronic control unit U when it wants it to connect to the server as soon as possible through the HTTPs channel.
  • the block BODY has the following structure:
  • the server sends a Minvalidkey message when it receives a valid Mping message but the signature is incorrect or when it has exhausted its sequence number source.
  • the electronic control unit U shall verify that
  • REJECTED_SIGNATURE is the signature of the last Mping message sent, otherwise it can silently ignore the message.
  • the SEQUENCE block corresponds to an integer value (32 bits) representing the sequence number of the transmitted frame.
  • Each transmitted message must contain a strictly increasing sequence number in order to avoid REPLAY attacks.
  • Each actor of the communication (electronic control units and server) has his own sequence counter which he uses to number the message he sends.
  • the first message transmitted must have a sequence number equal to 1.
  • Sequence counters must be reset each time a new secret key is negotiated.
  • control of the sequence number must use a sliding window mechanism, applying in particular the following control algorithm:
  • Control windows must be reset each time a new secret key is negotiated.
  • the SIGNATURE block corresponds to a signature of the message, arranged at the end of the message after the% separator in hexadecimal notation.
  • Each transmitted message must have a signature
  • the signature covers all the content of the message before the% non-included separator.
  • the algorithm and the secret signature key must be negotiated beforehand via an HTTPS channel.
  • the invention is not limited to the sole embodiment of this method and the system, described above as an example, it encompasses all the variants.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique L'invention concerne un procédé de transmission de données entre un serveur (S)et une unité électronique de contrôle(U) d'une installation domotique (I) comprenant les étapes suivantes: -Une première étape de réception (E5) par l'unité électronique de contrôle (U) d'un message de demande d'ouverture de connexion (Mopen) en provenance du serveur(S) selon un premier protocole de communication (P1); -une étape d'établissement (E6) d'une connexion (Cnx) vers le serveur (S) à l'initiative de l'unité électronique de contrôle (U) selon un deuxième protocole de connexion (P2); -Une deuxième étape de réception (E8) par l'unité électronique de contrôle (U) d'un message descendant (MRp) en provenance du serveur (S) selon le deuxième protocole de communication (P2). L'invention concerne également un serveur et une unité électronique de contrôle mettant en œuvre le procédé.

Description

Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique
La présente invention concerne un procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique.
Il est connu de procéder à des échanges de données entre un serveur et une pluralité d'unités électroniques de contrôle d'installations domotiques. Chaque unité de contrôle électronique d'une installation domotique est disposée sur un réseau privé, dont l'accès est en général protégé par un pare-feu. Il peut être souhaitable de procéder à ces échanges de données notamment pour opérer un contrôle à distance des installations par le serveur, par exemple dans le cas où le serveur reçoit des instructions d'une interface utilisateur permettant à l'utilisateur de contrôler à distance son installation.
En conséquence, l'échange de données entre le serveur et l'ensemble des unités électroniques de contrôle doit prendre en compte la présence de ce pare-feu. En particulier, l'établissement d'une connexion à l'initiative d'un serveur extérieur au réseau privé est de façon usuelle interdite par un pare-feu ou peut être rendue difficile par l'utilisation de mécanisme de traduction d'adresse (NAT).
Selon une première possibilité, une configuration spécifique du pare-feu peut être réalisée pour permettre l'établissement de connexion à l'initiative du serveur. Il apparaît toutefois que cela impose une intervention sur chaque pare-feu et une autorisation pour réaliser ladite intervention.
Selon une deuxième possibilité, un mécanisme de connexion à l'initiative de l'unité électronique peut être utilisé, les connexions ainsi établies étant maintenues par le serveur afin d'acheminer les données du serveur à l'unité électronique de contrôle. Il apparaît toutefois que cette deuxième possibilité conduit à une utilisation importante de ressources sur le serveur qui doit maintenir les données relatives à l'ensemble des connexions correspondant à chaque unité électronique.
La présente invention a pour but de résoudre tout ou partie des inconvénients mentionnés ci-dessus. A cet effet, la présente invention concerne un procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique comprenant les étapes suivantes :
- Une première étape de réception selon un premier protocole de communication par l'unité électronique de contrôle d'un message de demande d'ouverture de connexion en provenance du serveur ;
- une étape d'établissement d'une connexion vers le serveur à l'initiative de l'unité électronique de contrôle selon un deuxième protocole de connexion ;
- Une deuxième étape de réception par l'unité électronique de contrôle d'un message descendant en provenance du serveur selon le deuxième protocole de communication ;
le premier protocole étant un protocole en mode non connecté, et le deuxième protocole correspondant à une communication en mode connecté
Grâce aux dispositions selon l'invention, l'établissement de la connexion selon le deuxième protocole de communication est réalisé à l'initiative de l'unité électronique de contrôle vers le serveur, suite à la demande d'ouverture de connexion formulée par le serveur selon le premier protocole.
Ainsi, l'établissement de la connexion sera autorisé par le pare-feu, car elle est à l'initiative de l'unité électronique de contrôle. Le serveur pourra ensuite utiliser la connexion selon le deuxième protocole pour communiquer les données utiles correspondant à sa demande d'ouverture de connexion dans le message descendant.
Ces dispositions permettent de réaliser la communication d'informations entre le serveur et l'unité électronique de façon descendante en utilisant uniquement un établissement de connexion à l'initiative de l'unité électronique de contrôle.
Par ailleurs, l'utilisation de deux protocoles de communication permet d'utiliser un premier protocole plus simple impliquant une utilisation de ressources faible sur le serveur, et un deuxième protocole connecté impliquant une utilisation plus importante de ressources uniquement lorsque des informations doivent être communiquées par le serveur.
En particulier, le premier protocole est un protocole en mode non connecté. Le deuxième protocole correspond à une communication en mode connecté. Le premier protocole utilisé peut être de divers types permettant de ne pas être soumis aux contraintes imposées par le pare-feu.
Selon un mode de réalisation, le premier protocole de communication est un protocole comprenant l'envoi d'un message du serveur vers l'unité électronique de contrôle, notamment un message SMS.
Selon un autre mode de réalisation, le premier protocole correspond à une donnée fournie dans un flux audio et/ou vidéo, par exemple un flux MPEG.
Il est à noter que le terme montant concerne les messages transmis par l'unité électronique de contrôle vers le serveur et que le terme descendant concerne les messages transmis par le serveur vers l'unité électronique de contrôle.
Selon un aspect de l'invention, le procédé comprend une première étape de transmission périodique d'un message montant selon le premier protocole de communication par l'unité électronique de contrôle à destination du serveur ; la première étape de réception d'un message de demande d'ouverture de connexion comprenant une étape de réception selon le premier protocole d'au moins un message descendant ultérieure à la première étape de transmission.
L'unité électronique étant disposée sur un réseau privé dont l'accès est de façon usuelle protégé par un pare-feu, l'émission d'un message montant permet au serveur de répondre à ce message par un message descendant qui pourra atteindre l'unité électronique car il sera considéré comme une réponse au message montant.
Ainsi, l'envoi périodique de message montant offre des fenêtres de temps au serveur pour communiquer des demandes d'ouverture de connexion. En choisissant une périodicité des messages inférieurs à la fenêtre de temps autorisée par le pare-feu pour répondre à un message montant, il est possible de maintenir en permanence une possibilité de communication du serveur vers l'unité de contrôle électronique, c'est-à-dire un canal de communication ouvert.
Par ailleurs, un envoi périodique permet de connaître l'état du lien réseau entre l'unité électronique de contrôle et le serveur.
Selon un aspect de l'invention, le procédé comprend, préalablement à la première étape de réception d'une demande d'ouverture de connexion, une étape de réception selon le premier protocole de communication par l'unité électronique de contrôle d'un message descendant en provenance du serveur correspondant à une réponse d'accessibilité ;
L'étape préalable et la deuxième peuvent être simultanées, successives et/ou présenter une période de recouvrement temporel. En particulier, l'étape préalable de réception correspond à la réception d'une réponse d'accessibilité selon un premier délai après l'étape de transmission, afin de maintenir la possibilité de réception d'une deuxième trame selon un deuxième délai. La deuxième étape correspond à la réception d'une demande de connexion pendant ledit deuxième délai.
II apparaît en effet que le fonctionnement d'un pare-feu usuel peut empêcher le passage d'un message descendant dans la mesure où celui-ci est reçu au-delà d'un premier délai après l'envoi d'un message montant. Egalement de façon usuelle, dans la mesure où un premier message descendant est reçu, un deuxième délai plus important est accordé pour recevoir un ou plusieurs autres messages descendants.
Selon un aspect de l'invention, le procédé comprend une étape de surveillance d'au moins un délai de réception d'un message descendant en provenance du serveur suite à la première étape de transmission, le déclenchement d'une nouvelle première étape de transmission étant déclenchée en cas de dépassement de l'au moins un délai de réception.
Ces dispositions permettent de maintenir des fenêtres de communication ouvertes afin que le serveur puisse communiquer
Selon un aspect de l'invention, le procédé comprend une étape de transmission d'un message montant à destination du serveur selon le deuxième protocole de communication suite à l'étape d'établissement de connexion et précédemment à la deuxième étape de réception d'un message descendant ;
En réponse au message montant de l'unité de contrôle électronique, le serveur pourra dans une réponse sous forme de message descendant selon le deuxième protocole communiquer les données utiles correspondant à sa demande d'ouverture de connexion.
Ces dispositions permettent de réaliser la communication d'informations entre le serveur et l'unité électronique de façon descendante en utilisant un mode de requêtes et réponses sous formes de messages montants et descendants à l'initiative de l'unité électronique de contrôle. A titre d'exemple, une communication de type HTTP ou HTTPS peut être mise en œuvre.
Il est à noter que les messages montants et descendants ne contiennent pas tous nécessairement des données utiles. Ainsi, dans un échange de requête et réponse sous forme d'un message montant ou descendant, seule la réponse ou seule la requête peut contenir des données utiles
Selon un aspect de l'invention, le procédé comprend une étape de libération et/ou d'acceptation de la libération de la connexion selon le deuxième protocole de communication après un nombre déterminé de transmissions de messages montants et/ou de réception de messages descendants selon le deuxième protocole de communication ou après un délai déterminé après l'étape d'établissement de la communication.
Grâce à ces dispositions, les ressources utilisées sur le serveur pour maintenir les données de sessions sont limitées, car le nombre de connexions concurrentes est faible étant donné que les connexions sont fermées après échange de quelques informations.
Ce mode de communication est adapté aux applications domotiques dans lesquelles un grand nombre d'unités électroniques de contrôle sont connectées à un serveur avec un faible volume de données à échanger avec celui-ci.
La libération de la connexion peut être réalisée selon les cas à l'initiative du serveur ou de l'unité électronique de contrôle.
Selon un mode de réalisation, un seul échange selon le deuxième protocole comprenant un message applicatif montant et un message applicatif descendant est prévu avant libération de la connexion.
Selon un autre mode de réalisation, un seul message applicatif descendant est reçu avant libération de la connexion.
Selon un aspect de l'invention, le procédé comprend une étape de transmission d'une clé de chiffrement par l'unité électronique de contrôle au serveur, de façon à permettre une signature des messages montants et/ou descendants selon le premier protocole de communication et/ou selon le deuxième protocole de communication.
Ces dispositions permettent de réaliser une signature des échanges entre le serveur et l'unité électronique de contrôle afin d'authentifier les deux entités en présence, à savoir le serveur et l'unité électronique de contrôle.
Selon un aspect de l'invention, le procédé comprend une étape de réception d'une indication de clef invalide ou expirée en provenance du serveur, et en réponse une nouvelle étape de transmission d'une clef de chiffrement.
Ces dispositions permettent de rétablir une communication par le premier mode de communication en cas d'expiration de la clé de chiffrement.
La présente invention concerne également un procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique comprenant les étapes suivantes :
- Une première étape de transmission selon un premier protocole de communication par le serveur d'un message de demande d'ouverture de connexion à destination de unité électronique de contrôle ;
- une étape d'acceptation de l'établissement d'une connexion par le serveur à l'initiative de l'unité électronique de contrôle selon un deuxième protocole de connexion ;
- Une deuxième étape de transmission selon le deuxième protocole de communication par le serveur d'un message descendant à destination de l'unité électronique de contrôle selon le deuxième protocole de communication.
Selon un aspect de l'invention, le procédé comprend une première étape de réception périodique d'un message montant selon le premier protocole de communication par le serveur en provenance de l'unité électronique de contrôle ; la première étape de transmission d'un message de demande d'ouverture de connexion comprenant une étape de transmission d'au moins un message descendant ultérieure à la première étape de réception.
Selon un aspect de l'invention, le procédé comprend, préalablement à la première étape de transmission d'une demande d'ouverture de connexion, une étape préalable de transmission par le serveur à destination de l'unité électronique de contrôle d'un message descendant correspondant à une réponse d'accessibilité.
Selon un aspect de l'invention, le procédé comprend une étape de réception d'un message montant par le serveur en provenance de l'unité électronique de contrôle selon le deuxième protocole de communication suite à l'étape d'acceptation d'établissement de connexion et précédemment à la deuxième étape de transmission d'un message descendant ;
Selon un aspect de l'invention, le procédé comprend une étape de libération et/ou d'acceptation de libération de la connexion selon le deuxième protocole de communication après un nombre déterminé de réception de messages montants et/ou de transmission de messages descendants selon le deuxième protocole de communication ou après un délai déterminé après l'étape d'acceptation d'établissement de la communication.
Selon un aspect de l'invention, le premier protocole de communication est le protocole UDP.
Selon un aspect de l'invention, le deuxième protocole de communication est le protocole TCP.
Selon un autre aspect de l'invention, le premier et/ou le deuxième protocole peuvent être de type Raw IP ou autre protocole au dessus d'IP.
La présente invention concerne également un produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission de données par une unité électronique de contrôle tel que décrit précédemment.
La présente invention concerne également une unité électronique de contrôle d'une installation domotique comprenant une unité de traitement agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication précédente, l'unité électronique de contrôle comprenant en outre au moins une interface de communication destinée à la commande et/ou au contrôle d'au moins un actionneur, notamment d'un élément mobile d'un bâtiment, ou d'un autre équipement commandable ou contrôlable électriquement ou électroniquement, comme par exemple un système d'alarme, ou d'au moins un capteur, et une interface de communication destinée à la communication selon le premier protocole de communication ou le deuxième protocole de communication avec un serveur.
La présente invention concerne également un produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission de données par un serveur tel que décrit précédemment.
La présente invention concerne également un serveur de commande et ou de contrôle à distance d'au moins une unité électronique de contrôle d'une installation domotique comprenant une unité de traitement agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication précédente, le serveur comprenant en outre au moins une interface de communication destinée à la communication selon le premier protocole de communication ou le deuxième protocole de communication avec au moins une unité de commande électronique.
Selon un aspect de l'invention, le serveur peut comprendre également une interface de communication destiné à la communication avec une interface utilisateur.
Ces dispositions permettent un contrôle à distance de l'installation domotique par l'utilisateur, et l'envoi d'ordres par l'intermédiaire du serveur vers l'unité électronique de contrôle, ou l'obtention de données sur l'état de l'installation.
L'interface utilisateur peut par exemple être formée par un serveur web communiquant avec un terminal utilisateur, par exemple un ordinateur, un téléphone portable ou une tablette.
La présente invention concerne également un système distribué comprenant au moins un serveur et une pluralité d'unités électroniques de contrôle agencées pour communiquer avec le serveur de façon à mettre en œuvre le procédé tel que décrit précédemment.
L'invention sera mieux comprise à l'aide de la description détaillée qui est exposée ci-dessous en regard du dessin annexé dans lequel :
La figure 1 est un schéma illustrant la structure d'un système destiné à la mise en œuvre d'un procédé de transmission de données entre un serveur et un ensemble d'unités électroniques de contrôle d'installations domotiques.
La figure 2 est un schéma illustrant un mode de mise en œuvre d'un procédé de transmission de données.
La figure 3 est un schéma illustrant une étape additionnelle du procédé de figure 2.
La figure 4 est un schéma illustrant la structure d'un deuxième système destiné à la mise en œuvre d'un procédé de transmission de données entre un serveur et un ensemble d'unités électroniques de contrôle d'installations domotiques.
Dans la description détaillée qui va suivre des figures définies ci- dessus, les mêmes éléments ou les éléments remplissant des fonctions identiques pourront conserver les mêmes références de manière à simplifier la compréhension de l'invention.
Comme cela est représenté sur la figure 1 , un système distribué comprend au moins un serveur S et une pluralité d'unités électroniques de contrôle U d'installations domotiques agencées pour communiquer avec le serveur S de façon à mettre en œuvre un procédé de transmission de données.
Chaque unité de contrôle électronique d'une installation domotique est disposée sur un réseau privé PN, PN', dont l'accès est en général protégé par un pare-feu FW. Le serveur S est également disposé sur un réseau privé NS.
Les réseaux privés PN, PN', SN sont reliés à un réseau étendu N, par exemple Internet.
En particulier, une unité électronique de contrôle U d'une installation domotique comprend une unité de traitement 2 agencée pour contenir et exécuter un premier programme d'ordinateur.
A titre d'exemple, l'unité de traitement 2 comprend un processeur, une mémoire flash de stockage ainsi d'un mémoire vive, et d'une puce Ethernet PHY.
L'unité électronique de contrôle U comprend en outre au moins une interface de communication 3 destinée au contrôle/commande d'actionneurs d'éléments mobiles d'un bâtiment, de capteurs, ou encore d'autres équipements à commande électrique ou électronique tels qu'un système d'alarme.
A titre d'exemple, comme cela est représenté sur la figure 1 , l'interface de communication 3 permet le contrôle et la commande d'au moins un actionneur 5, 5' d'un élément mobile d'un bâtiment, comme par exemple un volet roulant 6 ou un brise-soleil orientable 6'ou encore la réception d'informations d'un capteur 7 fournissant des informations de présence d'un utilisateur ou des valeurs des paramètres environnants comme la température, l'humidité, la luminosité. De la même, façon l'interface peut permettre le contrôle/commande d'un système d'alarme 8.
En particulier, l'interface de communication 3 peut comprendre une puce radiofréquence lo-homecontrol et/ou Zwave et/ou WM-Bus communiquant à une fréquence de 868Mhz, et/ou une puce radiofréquence RTS/RTD/RTD+ communiquant à une fréquence de 433 Mhz. L'unité électronique de contrôle U comprend par ailleurs une batterie et/ou une alimentation secteur, ainsi que des ports de connexion physique tels que par exemple USB host, RJ45 et micro-USB.
L'unité électronique de contrôle U comprend également des éléments d'interface comme des boutons de réinitialisation, de configuration, des boutons tactiles de lancement de scenarii, et/ou des indicateurs lumineux de fonctionnement, comme par exemple des LED.
L'unité électronique de contrôle U comprend par ailleurs une interface de communication 4 destinée à la communication selon le premier protocole de communication P1 ou le deuxième protocole de communication P2 avec un serveur S.
Le serveur S qui permet la commande et/ou le contrôle à distance de la pluralité d'unités électroniques de contrôle U d'une installation domotique comprend une unité de traitement 102 agencée pour contenir et exécuter un deuxième programme.
Le serveur S comprend en outre au moins une interface de communication 104 destinée à la communication selon le premier protocole de communication P1 ou le deuxième protocole de communication P2 avec la pluralité d'unités électroniques de contrôle U.
Le serveur S peut comprendre également une interface de communication 106 destiné à la communication avec une interface utilisateur 107. L'interface utilisateur 107 peut par exemple être formée par un serveur web communiquant avec un terminal utilisateur 108 par le réseau N, par exemple un ordinateur, un téléphone portable ou une tablette.
La figure 2 représente un schéma de mise en œuvre des procédés de transmission de données exécutés sur le serveur S et sur une unité électronique de contrôle U d'une installation domotique I.
Selon le mode de mise en œuvre décrit sur la figure 2, le procédé comprend une première phase PhO de négociation d'une clef secrète, une deuxième phase Ph1 réalisée selon le premier protocole de communication destiné à recueillir une demande de connexion de la part du serveur S et une troisième phase Ph2 de transmission de données suite à l'établissement d'une connexion selon le deuxième protocole de communication à l'initiative de l'unité électronique de contrôle.
La phase de négociation d'une clef secrète PhO comprend une étape de transmission E0 d'une clé de chiffrement dans un message Mkey par l'unité de contrôle électronique U au serveur S qui le reçoit lors d'une étape E0', de façon à permettre une signature des messages montants et/ou descendants selon le premier protocole de communication P1 et/ou selon le deuxième protocole de communication P2. La clef de chiffrement peut notamment être choisie de façon aléatoire par l'unité électronique de contrôle U.
Le serveur accuse réception de la clé et valide qu'il a bien pris en compte la nouvelle clef par un message descendant MkeyAck transmis dans une étape E1 ' qui est reçu par l'unité électronique de contrôle U lors d'une étape de réception E1 .
Les échanges entre l'unité électronique de contrôle U lors de la phase de négociation peuvent être réalisées selon un protocole de communication distinct ou similaire au premier protocole de communication et au deuxième protocole de communication P1 et P2. A titre d'exemple, un protocole de type HTTPS peut être choisi qui permet de communiquer la clef de façon sécurisée.
Il est à noter que cet échange n'est pas réalisé fréquemment, et en conséquence ne représente pas une consommation de ressources significative. A titre d'exemple, une périodicité de plusieurs jours peut être prévue pour la validité des clefs.
La deuxième phase de communication Ph1 selon le premier protocole P1 comprend une première étape de transmission E2 périodique d'un message montant Mping selon le premier protocole de communication P1 par l'unité électronique de contrôle U à destination du serveur S qui le reçoit dans une étape E2'. A titre d'exemple, une périodicité de l'ordre d'une dizaine de secondes peut être prévue pour la périodicité de la transmission, et notamment de l'ordre de 20s.
En réponse à ce message montant, le serveur S transmet dans une étape E4' un message descendant Mpong à destination de l'unité électronique de contrôle U qui est reçu dans une étape préalable de réception E4 dans un premier délai Dr1 court après la transmission du message montant Mping. A titre d'exemple, le délai Dr1 peut être de l'ordre de quelques secondes, et notamment de l'ordre de 5 s.
Ce premier message Mpong descendant permet de maintenir le canal de communication ouvert pendant un deuxième délai Dr2 supérieur au premier délai Dr1 . Il apparaît en effet que le fonctionnement d'un pare-feu usuel peut empêcher le passage d'un message descendant dans la mesure où celui-ci est reçu au-delà d'un premier délai après l'envoi d'un message montant. Egalement de façon usuelle, dans la mesure où un premier message descendant est reçu, un deuxième délai plus important est accordé pour recevoir un ou plusieurs autres messages descendants. Il est notamment possible de choisir de déclencher une nouvelle transmission du message Mping avant l'expiration du délai Dr2.
Par la suite, dans le cas où le serveur S a des données utiles DU à transmettre à l'unité électronique de contrôle U, celui-ci transmet selon le premier protocole de communication P1 lors d'une étape E5' un message de demande d'ouverture de connexion Mopen, qui est reçu par l'unité électronique de contrôle U lors d'une étape E5.
La deuxième phase Ph1 de communication selon le premier protocole P1 comprend une étape de surveillance E3 d'un délai de réception Dr d'un message descendant en provenance du serveur S suite à la première étape de transmission Mping, le déclenchement d'une nouvelle première étape de transmission E2 étant réalisé en cas de dépassement du délai de réception.
Lors de cette phase, les échanges sont signés avec la clé secrète communiquée lors de la première phase de communication PhO.
Comme cela est illustré sur la figure 3, lors de la deuxième phase
Ph1 de communication selon le premier protocole de communication P1 , le serveur peut réaliser une étape de transmission ERO' d'une indication de clef invalide ou expirée Minvalidkey en provenance du serveur S, et en réponse une nouvelle étape de transmission d'une clef de chiffrement E0. Typiquement, cette situation peut intervenir lors de la transmission d'un message montant MPing, le serveur ayant constaté que le message présente un format correct mais n'est pas signé avec une clé valide. Il est à noter qu'en cas de redémarrage de l'unité électronique de contrôle, la première phase de communication PhO avec communication de la clé est réalisée à nouveau.
Lors de la deuxième phase de communication Ph1 , Le premier protocole de communication peut notamment être le protocole UDP.
La troisième phase Ph2 du procédé est réalisée suite à la réception de la demande d'ouverture de connexion reçue par l'unité électronique de contrôle dans la deuxième phase à l'étape E5.
Dans un premier temps, une étape d'établissement E6 d'une connexion Cnx vers le serveur S qui accepte cette connexion dans une étape correspondante E6' est réalisée, à l'initiative de l'unité électronique de contrôle U selon un deuxième protocole de connexion P2. En particulier, le protocole de communication peut être le protocole TCP. Dans ce cas, l'étape d'établissement E6 peut comprendre plusieurs échanges entre le serveur et l'unité U, et en particulier des échanges de messages de gestion de connexion, comme les messages du protocole TCP SYN, SYN/ACK, ACK.
Une fois la connexion Cnx établie, une étape de transmission E7 d'un message montant MRq est réalisée selon le deuxième protocole de communication P2 à destination du serveur S qui reçoit ce message dans un étape ET.
En particulier, le message MRq peut être un message sans données utiles mais constituant un message montant auquel une réponse pourra être envoyée par le serveur.
Ainsi, le serveur transmet un message descendant MRp dans une étape de transmission E8' à destination de l'unité électronique de contrôle U. Ce message descendant contient les données utiles DU que le serveur devait transmettre à l'unité électronique de contrôle.
Suite à cet échange, une étape de libération ou d'acceptation de la libération E9, E9' de la connexion Cnx est réalisée.
Le deuxième protocole de communication utilisé peut être en particulier le protocole TCP. Les échanges des étapes E7/E7' et E8/E8' peuvent notamment être réalisés sous forme d'une requête et d'une réponse selon le protocole HTTPS qui utilise TCP.
Selon des variantes de mise en œuvre, la libération de la connexion peut intervenir après plusieurs échanges de messages montants et/ou de réception de messages descendantes selon le deuxième protocole de communication ou encore après un délai déterminé après l'étape d'établissement de la communication E6.
Selon un deuxième mode de mise en œuvre d'un système mettant en œuvre l'invention représenté sur la figure 4, le premier protocole de communication est un protocole de type SMS comprenant l'envoi d'un message du serveur vers l'unité électronique de contrôle U identifiée dans ce cas par un numéro téléphonique. Ce deuxième protocole est utilisé sur un réseau de type téléphonique N2, par exemple un réseau GSM ou téléphonie filaire sur Internet, avec une fonction de gestion de messages numériques. Le serveur S comprend à cet effet une interface de communication 107 sur le réseau N2, comme par exemple une carte GSM, tout comme l'unité électronique de contrôle, qui comprend également une interface de communication 7 sur le réseau N2, comme une carte GSM ou un module matériel et logiciel de téléphonie sur Internet, pouvant être intégré au pare-feu ou à l'unité électronique de contrôle U.
Ainsi, l'échange selon le premier protocole et l'étape de réception d'une demande d'ouverture de connexion correspond à un simple envoi de SMS entre le serveur S et l'unité électronique de contrôle U.
La figure 4 ne représente qu'une unité électronique de contrôle, mais ce deuxième mode de réalisation s'applique bien entendu à la communication avec une multitude d'unités électroniques de contrôles.
Selon des variantes de mise en œuvre, le premier protocole utilisé peut être de divers types permettant de ne pas être soumis aux contraintes imposées par le pare-feu.
Selon une deuxième variante, le premier protocole correspond à une donnée fournie dans un flux audio et/ou vidéo, par exemple un flux MPEG. Selon cette variante, l'unité électronique de contrôle U comprend ou est associée à une interface de décodage du flux audio et/ou vidéo correspondant.
Selon une autre variante, le premier et/ou le deuxième protocole peuvent être de type Raw IP ou autre protocole au dessus d'IP.
Selon des variantes de la troisième phase de communication Ph2, il est possible que les échanges applicatifs suivent le modèle des transactions, comprenant une requête et une réponse. Les requêtes sont envoyées sous forme de messages montants, et les réponses sous forme de messages descendants. Ainsi, dans un échange de requête et réponse sous forme d'un message montant, respectivement descendant, seule la réponse ou seule la requête peut contenir des données utiles. Un message montant et le message descendant transmis en retour peuvent contenir des données utiles qui ne correspondent pas nécessairement à la même transaction. Par exemple une requête en cours nécessitant un traitement applicatif est transmise sous forme de message montant, et peut déclencher la transmission d'un message descendant sans données utiles, ou contenant des données utiles relatives à une requête antérieure. De la même manière, la réponse applicative correspondant à la requête en cours peut être envoyée lors d'un échange message montant/message descendant ultérieur. Cet échange peut comprendre un message montant sans données utiles.
Selon une variante de la troisième phase de communication Ph2, il est possible que suite à l'établissement de la connexion E6, seul un message descendant soit transmis par le serveur S, sans transmission d'un message montant par l'unité de contrôle électronique. Dans ce cas, un protocole distinct de HTTPS peut être utilisé, tout en s'appuyant sur les services fiables fournis par un protocole transport fonctionnant en mode connecté, comme TCP
Il est à noter que la description ci-dessus décrit des procédés permettant la transmission de données du serveur S vers l'unité électronique de contrôle U.
La transmission de données dans le sens de l'unité électronique de contrôle vers le serveur peut être réalisée par exemple selon le deuxième protocole de communication sans difficulté étant donné qu'il est possible d'établir directement une connexion à l'initiative de l'unité électronique de contrôle.
A titre d'exemple une requête et une réponse selon le protocole HTTPS peuvent être réalisée, puis la connexion établie libérée afin de limiter l'utilisation de ressources du serveur.
Exemple
Nous allons à présent décrire à titre d'exemple un format des messages utilisés dans le procédé tel que décrit précédemment selon le premier mode de réalisation dans la configuration du système présenté sur la figure 1 .
Dans l'exemple considéré, le premier protocole est le protocole
UDP.
Les messages sont transmis dans des datagrammes UDP. En particulier, un message peut correspondre à un datagramme UDP. Le corps du datagramme UDP est constitué d'une unique trame encodée en UTF-8.
La forme générale du format des trames comprend un premier bloc appelé BODY, un deuxième bloc SEQUENCE et un dernier BLOC de SIGNATURE, ces blocs étant séparés par des séparateurs / et % comme cela est représenté ci-dessous :
<BODY>/<SEQUENCE>%<SIGNATURE> Il est à noter toutefois que le message ou la trame Minvalidkey ou INVALIDKEY ne possède ni séquence ni signature, et donc seulement le bloc BODY.
Nous détaillons ci-dessous les différents blocs identifiés.
Le bloc BODY présente la forme générale suivante :
<TYPE>#<SERIAL>#<TIM ESTAM P>#....
Le champ TYPE comprend une information de type de message qui peut être: PING (pour un message Mping), PONG (pour un message Mpong), OPEN (pour un message Mopen), INVALIDKEY (pour un message Minvalidkey).
Le champ SERIAL comprend le numéro de série du l'unité électronique de contrôle U.
Le champ TIMESTAMP comprend un horodatage, par exemple un Timestamp UNIX correspondant au nombre de secondes depuis EPOCH, calculé par l'émetteur du message.
D'autres champs peuvent être présents en fonction du type de message comme décrit ci-dessous.
En particulier, dans le cas d'un message Mping, transmis de l'unité électronique de contrôle U vers le serveur S, le bloc BODY présente la structure suivante :
PING#<SERIAL>#<TIMESTAMP>#<ACTIVITY_INTERVAL>
Le champ ACTIVITYJNTERVAL correspond au nombre de secondes maximum entre deux activités de l'unité électronique de contrôle U, c'est-à-dire une transmission vers le serveur selon le premier ou le deuxième protocole de communication.
L'unité électronique de contrôle U doit envoyer un message Mping immédiatement après son démarrage puis doit ensuite régulièrement : soit émettre un nouveau message Mping, soit établir une connexion Cnx pour affirmer sa présence auprès du serveur.
La durée maximum entre une de ces deux activités est :
- Récupérée par l'unité électronique de contrôle U dans sa configuration au démarrage ;
- Transmise par l'unité électronique de contrôle U dans chaque message Mping pour préciser au serveur qu'elle est sa période d'activité actuelle. - Peut être modifiée par un message Mpong renvoyée par le serveur comme cela est décrit ci-après.
Dans le cas d'un message Mpong transmis du serveur S vers l'unité électronique de contrôle U, le bloc BODY présente la structure suivante :
PONG#<SERIAL>#<TIMESTAMP>#<NEW_ACTIVITY_INTERVAL >
Le champ NEW_ACTIVITY_INTERVAL comprend une nouvelle valeur (en secondes) de la période d'activité souhaitée.
Le serveur doit renvoyer un message Mpong pour chaque message Mping reçue.
Si la valeur de période d'activité de l'unité électronique de contrôle U est différente de celle fournie dans le message Mpong, l'unité électronique de contrôle U doit mettre à jour sa valeur en conséquence.
Dans le cas d'un message Mopen transmis du serveur S vers l'unité électronique de contrôle U, le bloc BODY présente la structure suivante :
OPEN#<SERIAL>#<TIMESTAMP>
Le serveur envoie un message Mopen à l'unité électronique de contrôle U lorsqu'il désire que celle-ci se connecte au plus tôt au serveur par le canal HTTPs.
Dans le cas d'un message Minvalidkey transmis du serveur S vers l'unité électronique de contrôle U, le bloc BODY présente la structure suivante :
INVALIDKEY#<SERIAL>#<TIMESTAMP>#<REJECTED_SIGNAT
URE>
Le serveur envoie un message Minvalidkey lorsqu'il reçoit un message Mping au format valide mais dont la signature est incorrecte ou lorsqu'il a épuisé sa source de numéro de séquence.
Lorsque l'unité électronique de contrôle U reçoit un message Minvalidkey, une phase de renégocier d'une nouvelle clef secrète est réalisée avec le serveur S.
L'unité électronique de contrôle U doit vérifier que
REJECTED_SIGNATURE correspond bien à la signature du dernier message Mping envoyé, sinon il peut ignorer silencieusement le message.
Le bloc SEQUENCE correspond à une valeur entière (32bits) représentant le numéro de séquence de la trame transmise. Chaque message transmis doit contenir un numéro de séquence strictement croissant afin d'éviter les attaques de type REPLAY.
Chaque acteur de la communication (unités électroniques de contrôle et serveur) possède son propre compteur de séquence qu'il utilise pour numéroter le message qu'il envoie.
Le premier message transmis doit avoir un numéro de séquence égal à 1 .
Les messages suivants doivent avoir un numéro de séquence strictement croissant, incrémenté de 1 à chaque message (soit 2, 3, 4,5,...)
Les compteurs de séquence doivent être remis à zéro à chaque fois qu'une nouvelle clef secrète est négociée.
Comme le protocole UDP ne garantit pas l'ordre d'arrivée des paquets transmis, le contrôle du numéro de séquence doit faire appel à un mécanisme de fenêtre glissante, en appliquant en particulier l'algorithme de contrôle suivant:
- Si le numéro de séquence reçu est égal au dernier numéro reçu, il est considéré comme invalide ;
- Si le numéro de séquence reçu est strictement supérieur au dernier numéro reçu, il est considéré comme valide ; Ce numéro remplace alors la dernière valeur reçue et la fenêtre glissante se décale pour faire une place à cette nouvelle valeur ;
Si le numéro de séquence reçu est strictement inférieur au dernier numéro reçu :
o Si la différence entre les deux valeurs est strictement inférieure à la taille de la fenêtre
■ Si la nouvelle valeur n'apparait pas déjà dans la fenêtre, le numéro de séquence est considéré comme valide ; la fenêtre glissante se décale pour faire une place à cette nouvelle valeur ;
■ Si la nouvelle valeur apparaît déjà dans la fenêtre, le numéro de séquence est considéré comme invalide ;
o Si la différence entre les deux valeurs est supérieure ou égale à la taille de la fenêtre ; le numéro de séquence est considéré comme invalide. Les fenêtres de contrôle doivent être remises à zéro à chaque fois qu'une nouvelle clef secrète est négociée.
Tout message possédant un numéro de séquence invalide doit être ignorée silencieusement.
Le bloc SIGNATURE correspond à une signature du message, disposée à la fin du message après le séparateur % en notation hexadécimale.
Chaque message transmis doit posséder une signature
La signature porte sur tout le contenu du message avant le séparateur % non-inclus. L'algorithme et la clef secrète de signature doivent être négociés au préalable par un canal HTTPS.
La signature des messages est systématiquement vérifiée, sauf pour les messages Minvalidkey. Tout message possédant une signature invalide est ignoré silencieusement. La signature d'une trame doit être vérifiée avant de vérifier le numéro de séquence.
Comme il va de soi, l'invention ne se limite pas à la seule forme d'exécution de ce procédé et du système, décrit ci-dessus à titre d'exemple, elle en embrasse au contraire toutes les variantes de réalisation.

Claims

REVENDICATIONS
Procédé de transmission de données entre un serveur (S) et une unité électronique de contrôle (U) d'une installation domotique (I) comprenant les étapes suivantes :
- Une première étape de réception (E5) selon un premier protocole de communication (P1 ) par l'unité électronique de contrôle (U) d'un message de demande d'ouverture de connexion (Mopen) en provenance du serveur (S) ;
- une étape d'établissement (E6) d'une connexion (Cnx) vers le serveur (S) à l'initiative de l'unité électronique de contrôle (U) selon un deuxième protocole de connexion (P2) ;
- Une deuxième étape de réception (E8) par l'unité électronique de contrôle (U) d'un message descendant (MRp) en provenance du serveur (S) selon le deuxième protocole de communication (P2) ; le premier protocole (P1 ) étant un protocole en mode non connecté, et le deuxième protocole (P2) correspondant à une communication en mode connecté. 2. Procédé selon la revendication 1 , comprenant :
- Une première étape de transmission (E2) périodique d'un message montant (Mping) selon le premier protocole de communication (P1 ) par l'unité électronique de contrôle (U) à destination du serveur (S) ; et dans lequel la première étape de réception (E5) d'un message de demande d'ouverture de connexion (Mopen) comprend une étape de réception selon le premier protocole (P1 ) d'au moins un message descendant (Mopen) ultérieure à la première étape de transmission (E2).
Procédé selon l'une des revendications précédentes, comprenant, préalablement à la première étape de réception (E5) d'une demande d'ouverture de connexion (Mopen) :
- Une étape préalable de réception (E4) selon le premier protocole de communication (P1 ) par l'unité électronique de contrôle (U) d'un message descendant en provenance du serveur (S) correspondant à une réponse d'accessibilité (Mpong) ; Procédé selon l'une des revendications 2 ou 3, comprenant une étape de surveillance (E3) d'au moins un délai de réception (Dr) d'un message descendant en provenance du serveur (S) suite à la première étape de transmission (Mping), le déclenchement d'une nouvelle première étape de transmission (E2) étant déclenchée en cas de dépassement de l'au moins un délai de réception.
Procédé selon l'une des revendications précédentes, comprenant :
une étape de transmission (E7) d'un message montant (MRq) à destination du serveur (S) selon le deuxième protocole de communication (P2) suite à l'étape d'établissement de connexion (E6) et précédemment à la deuxième étape de réception (E8) d'un message descendant ;
Procédé selon l'une des revendications précédentes, comprenant une étape de libération et/ou d'acceptation de la libération (E9) de la connexion (Cnx) selon le deuxième protocole de communication (P2) après un nombre déterminé de transmissions de messages montants et/ou de réception de messages descendants selon le deuxième protocole de communication (P2) ou après un délai déterminé après l'étape d'établissement de la communication (E6).
7. Procédé de transmission de données entre un serveur (S) et une unité électronique de contrôle (U) d'une installation domotique (I) comprenant les étapes suivantes :
- Une première étape de transmission (Ε5') selon un premier protocole de communication (P1 ) par le serveur (S) d'un message de demande d'ouverture de connexion (Mopen) à destination de l'unité électronique de contrôle (U) ;
- une étape d'acceptation de l'établissement (Ε6') d'une connexion (Cnx) par le serveur (S) à l'initiative de l'unité électronique de contrôle (U) selon un deuxième protocole de connexion (P2) ;
- Une deuxième étape de transmission (Ε8') selon le deuxième protocole de communication (P2) par le serveur (S) d'un message descendant (Mrp) à destination de l'unité électronique de contrôle (U) selon le deuxième protocole de communication (P2).
8. Procédé selon la revendication 7, comprenant :
- Une première étape de réception (Ε2') périodique d'un message montant (Mping) selon le premier protocole de communication (P1 ) par le serveur (S) en provenance de l'unité électronique de contrôle (U) ;
et dans lequel la première étape de transmission (Ε5') d'un message de demande d'ouverture de connexion (Mopen) comprend une étape de transmission d'au moins un message descendant (Mopen) ultérieure à la première étape de réception (Ε2').
9. Procédé selon l'une quelconque des revendications 7 ou 8, comprenant, préalablement à la première étape de transmission (Ε5') d'une demande d'ouverture de connexion (Mopen) :
- Une étape préalable de transmission (Ε4') par le serveur (S) à destination de l'unité électronique de contrôle (U) d'un message descendant correspondant à une réponse d'accessibilité (Mpong) ;
10. Procédé selon l'une quelconque des revendications 7 à 9, comprenant : une étape de réception (Ε7') d'un message montant (MRq) par le serveur (S) en provenance de l'unité électronique de contrôle (U) selon le deuxième protocole de communication (P2) suite à l'étape d'acceptation d'établissement de connexion (Ε6') et précédemment à la deuxième étape de transmission (Ε8') d'un message descendant (Mrp) ;
1 1 . Procédé selon l'une quelconque des revendications 7 à 10, comprenant une étape de libération ou d'acceptation de libération (Ε9') de la connexion (Cnx) selon le deuxième protocole de communication (P2) après un nombre déterminé de réception de messages montants et/ou de transmission de messages descendants selon le deuxième protocole de communication (P2) ou après un délai déterminé après l'étape d'acceptation d'établissement de la communication (Ε6').
12. Produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission de données selon l'une des revendications 1 à 6 lorsque ledit programme est exécuté par un ordinateur.
13. Unité électronique de contrôle (U) d'une installation domotique comprenant une unité de traitement (2) agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication précédente, l'unité électronique de contrôle comprenant en outre au moins une interface de communication (3) destinée à la commande et/ou au contrôle d'au moins un actionneur, notamment d'un élément mobile d'un bâtiment, ou d'un autre équipement commandable ou contrôlable électriquement ou électroniquement, comme par exemple un système d'alarme, ou d'au moins un capteur, et une interface de communication (4) destinée à la communication selon le premier protocole de communication (P1 ) ou le deuxième protocole de communication (P2) avec un serveur (S).
14. Produit programme d'ordinateur comprenant des portions de code de programme pour l'exécution des étapes d'un procédé de transmission de données selon l'une des revendications 7 à 1 1 lorsque ledit programme est exécuté par un ordinateur.
15. Serveur (S) de commande et ou de contrôle à distance d'au moins une unité électronique de contrôle (U) d'une installation domotique comprenant une unité de traitement (102) agencée pour contenir et exécuter le produit programme d'ordinateur selon la revendication précédente, le serveur comprenant en outre au moins une interface de communication (104) destinée à la communication selon le premier protocole de communication (P1 ) ou le deuxième protocole de communication (P2) avec au moins une unité de commande électronique (U).
EP15823713.1A 2014-12-24 2015-12-23 Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique Withdrawn EP3238384A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1463300A FR3031260B1 (fr) 2014-12-24 2014-12-24 Procede de transmission de donnees entre un serveur et une unite electronique de controle d’une installation domotique
PCT/FR2015/053740 WO2016102903A1 (fr) 2014-12-24 2015-12-23 Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique

Publications (1)

Publication Number Publication Date
EP3238384A1 true EP3238384A1 (fr) 2017-11-01

Family

ID=52737280

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15823713.1A Withdrawn EP3238384A1 (fr) 2014-12-24 2015-12-23 Procédé de transmission de données entre un serveur et une unité électronique de contrôle d'une installation domotique

Country Status (4)

Country Link
US (1) US20170346905A1 (fr)
EP (1) EP3238384A1 (fr)
FR (1) FR3031260B1 (fr)
WO (1) WO2016102903A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3047374B1 (fr) * 2016-01-28 2018-07-27 Overkiz Procede de configuration, de controle ou de supervision d’une installation domotique
FR3061400A1 (fr) 2016-12-28 2018-06-29 Overkiz Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique
FR3061399B1 (fr) 2016-12-28 2023-04-21 Overkiz Procede de configuration d’acces, de commande et de supervision a distance d’au moins un dispositif domotique appartenant a une installation domotique
FR3061390B1 (fr) * 2016-12-28 2022-12-16 Overkiz Procede de configuration, de controle ou de supervision d’une installation domotique
EP3451606A1 (fr) * 2017-08-30 2019-03-06 Siemens Aktiengesellschaft Procédé de vérification de datagrammes transmis à l'intérieur d'un système d'automatisation industrielle et appareil d'automatisation et/ou de communication
US10834306B2 (en) 2019-01-15 2020-11-10 International Business Machines Corporation Method for a remote control of a radiation detection apparatus

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200408242A (en) * 2002-09-06 2004-05-16 Matsushita Electric Ind Co Ltd Home terminal apparatus and communication system
JP3445986B1 (ja) * 2002-09-27 2003-09-16 松下電器産業株式会社 インターネットに接続するサーバ、機器および通信システム
JP2004227121A (ja) * 2003-01-21 2004-08-12 Toshiba Corp サーバ装置、通信制御システム、通信方法及びサーバプログラム
DE102007016416A1 (de) * 2007-04-05 2008-10-09 Deutsche Telekom Ag Externer Zugriff auf lokales Netzwerk mit nichtpermanenter Internet-Anbindung
DE102011109678A1 (de) * 2011-08-08 2013-02-14 Rwe Effizienz Gmbh Kommunikationssystem
DE102012105698A1 (de) * 2012-06-28 2013-10-31 Deutsche Telekom Ag Externer Zugriff auf IP-basierte Haussteuereinheit in lokalem Netzwerk

Also Published As

Publication number Publication date
US20170346905A1 (en) 2017-11-30
FR3031260A1 (fr) 2016-07-01
FR3031260B1 (fr) 2018-02-09
WO2016102903A1 (fr) 2016-06-30

Similar Documents

Publication Publication Date Title
WO2016102903A1 (fr) Procédé de transmission de données entre un serveur et une unité électronique de contrôle d&#39;une installation domotique
EP3409054B1 (fr) Procede de synchronisation pour un noeud dans un réseau cellulaire
US7085937B1 (en) Adaptive method for amortizing authentication overhead
EP3503618A1 (fr) Procédé de régulation de débit
EP3809388B1 (fr) Compteur de fluide communiquant avec une vanne électromécanique
WO2019185552A1 (fr) Procede de communication
EP3622688A1 (fr) Singularisation de trames à émettre par un objet connecté et blocage de trames réémises sur un réseau de communication sans-fil basse consommation
EP3777308A1 (fr) Procede de communication
WO2016102902A1 (fr) Procédé de traitement de messages montants ou descendants applicatifs en provenance ou à destination d&#39;une unité électronique de contrôle d&#39;une installation domotique par un serveur
WO2020089565A1 (fr) Systeme de supervision ameliore de capteurs connectes
WO2023078995A2 (fr) Procédé de vérification de la fiabilité d&#39;une première valeur d&#39;un paramètre de contrôle de flux relatif à une connexion destinée à être établie entre un premier équipement de communication et un deuxième équipement de communication reliés par un chemin comprenant au moins un nœud intermédiaire au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par le nœud intermédiaire
WO2023078993A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire
FR3087981A1 (fr) Procede securise de transmission de donnees au sein d&#39;un systeme de supervision
WO2023169938A1 (fr) Procédé de gestion d&#39;une retransmission de données échangées sur un chemin établi entre un premier équipement de communication et un deuxième équipement de communication au moyen d&#39;une valeur d&#39;un paramètre de performance intermédiaire déterminée par un nœud intermédiaire appartenant audit chemin
EP2805310A1 (fr) Reveil a distance d&#39;un equipement connecte a un reseau a liens multiples
FR2848042A1 (fr) Dispositif de mesures de bout en bout, d&#39;informations de reseau
FR2813151A1 (fr) Communication securisee dans un equipement d&#39;automatisme
WO2012032248A1 (fr) Traitement de donnees pour la notification d&#39;un equipement
FR3079643A1 (fr) Procede de gestion d&#39;un dispositif electronique.
EP2525525B1 (fr) Procédé, programme d&#39;ordinateur et dispositif de cooptation permettant à un abonné d&#39;un service de partager ce service avec un autre utilisateur
WO2017060624A1 (fr) Moyens de gestion d&#39;accès à des données
EP2553900B1 (fr) Transmission de flux de données adaptable
FR3097666A1 (fr) Procédé de stockage de données d’authentification de documents
FR2935576A1 (fr) Procede de gestion d&#39;une transmission de flux de donnees sur un tunnel multi-canal, tete de tunnel, produit programme d&#39;ordinateur et moyen de stockage correspondants.
FR2898447A1 (fr) Procede pour l&#39;appairage securise de deux systemes prealablement a leur mise en communication

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20170621

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/08 20060101AFI20180404BHEP

Ipc: H04L 29/06 20060101ALI20180404BHEP

Ipc: H04L 9/08 20060101ALN20180404BHEP

Ipc: H04L 12/28 20060101ALI20180404BHEP

Ipc: H04L 29/12 20060101ALI20180404BHEP

INTG Intention to grant announced

Effective date: 20180420

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

INTC Intention to grant announced (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/08 20060101AFI20180816BHEP

Ipc: H04L 12/28 20060101ALI20180816BHEP

Ipc: H04L 29/06 20060101ALI20180816BHEP

Ipc: H04L 29/12 20060101ALI20180816BHEP

Ipc: H04L 9/08 20060101ALN20180816BHEP

INTG Intention to grant announced

Effective date: 20180912

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190123