FR 3077700 A1 20190809 FR 1851058 A 20180208 DOMAINE TECHNIQUE La présente invention concerne un procédé et un dispositif de communication asymétrique sur de longues distances. ETAT DE LA TECHNIQUE Les réseaux sans-fil à faible consommation énergétique sont de plus en plus utilisés pour la remontée de données de capteur embarqués sur de longues distances. L'un des plus utilisés est le LoRaWAN (acronyme de Long Range Wide-area network que l'on peut traduire par « réseau étendu à longue portée », marque déposée) standardisé par la LoRa Alliance (marque déposée). Ce standard couvre les quatre couches les plus basses du modèle OSI (acronyme de Open System Interconection littéralement interconnexion des systèmes ouverts), soit, en partant de la couche la plus basse, couches physique, liaison, réseau et transport. Or il y a un besoin de standardisation aussi au niveau applicatif et donnée (couches supérieures du modèle OSI) afin que des appareils de différents fabricants puissent fonctionner ensemble. Il existe un protocole applicatif défini par l'IETF (acronyme de Internet Engineering Task Force, littéralement traduit de l'anglais en « Détachement d'ingénierie d'Internet ») : le Constrained Application Protocol (abrégé en « CoAP » et traduit en français en protocole applicatif contraint) qui est de plus en plus utilisé dans l'internet des objets. Mais CoAP est conçu pour les réseaux UDP/IP. UDP (acronyme de « User Datagram Protocol », en français protocole de datagramme utilisateur) est un des principaux protocoles de télécommunication utilisés par Internet. Il fait partie de la couche transport du modèle OSI, couche 4. Le rôle de ce protocole est de permettre la transmission de données (sous forme de datagrammes) de manière simple entre deux entités, chacune étant définie par une adresse IF et un numéro de port. Aucune communication préalable n'est requise pour établir la connexion, UDP utilisant un mode de transmission sans connexion. Pour des raisons d'économies d'énergie, la grande majorité des objets 30 LoRaWAN sont de classe A, c'est-à-dire que l'objet ne peut recevoir un message du 2 serveur qu'immédiatement après en avoir lui-même envoyé un, l'objet étant injoignable et habituellement en veille le reste du temps. Une utilisation du mécanisme de retransmission de CoAP sur LoRaWAN n'est donc pas possible. 5 EXPOSE DE L'INVENTION La présente invention vise à remédier à tout ou partie de ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé de communication asymétrique entre un serveur applicatif et un objet, l'un des membres 10 du groupe constitué du serveur applicatif et de l'objet étant un client d'un protocole applicatif contraint et l'autre membre de ce groupe étant un serveur du protocole applicatif, qui comporte : - une première étape d'émission d'un message de requête par le client du protocole applicatif contraint, à destination du serveur du protocole applicatif 15 contraint, - une étape d'attente, par le client du protocole applicatif contraint, d'une réponse de la part du serveur du protocole applicatif contraint, et - à réception d'un message par le serveur du protocole applicatif contraint, une étape d'émission d'une réponse par le serveur du protocole applicatif 20 contraint à destination du client du protocole applicatif contraint, dans lequel l'objet ne peut émettre un message qu'à des intervalles de temps prédéterminés et ne peut recevoir un message que pendant une première durée prédéterminée après que l'objet ait envoyé un message, l'objet ne pouvant recevoir de message en dehors de ces premières durées prédéterminées 25 le procédé comportant, de plus, pour chaque message émis par le serveur applicatif à destination de l'objet en dehors d'une première durée indéterminée, une étape de stockage du message jusqu'à l'émission d'un nouveau message par l'objet. La présente invention permet d'utiliser le protocole CoAP sur un réseau LoRaWAN, ce qui ouvre ce type de réseau initialement destiné à la remontée de données à des protocoles plus complexes tels que le LightweightM2M (que l'on peut traduire, en français, par machine à machine léger) ou Open Connectivity Framework (que l'on peut traduire, en français, par cadre de connectivité ouverte). On peut donc réaliser des opérations plus complexes que ce qui était connu antérieurement, telles que la configuration et le contrôle à distance voire la mise à jour logicielle, pour tous 3 types d'objets connectés, en utilisant des protocoles largement utilisés mais précédemment incompatibles. Dans des modes de réalisation, le procédé comporte, en l'absence d'une réponse de la part du serveur du protocole applicatif contraint, au cours d'une 5 deuxième durée prédéterminée après la première étape d'émission, une deuxième étape d'émission d'un message d'absence de réception de réponse destiné au serveur de protocole applicatif contraint, effectuée par le client du protocole applicatif contraint. La deuxième durée prédéterminée est l'intervalle de temps entre deux fenêtres 10 de réception, dans le cas d'un objet LoRaWAN. Ces modes de réalisation sont particulièrement adaptés à l'utilisation de paquets de données incertains ou à l'utilisation de paquets de données fiables lorsque l'objet LoRaWAN est le client du protocole applicatif contraint et le serveur applicatif, le serveur du protocole applicatif contraint. 15 Dans des modes de réalisation, lorsque l'objet est le client du protocole applicatif contraint et le serveur applicatif est le serveur du protocole applicatif contraint, l'objet et le serveur applicatif utilisant des paquets fiables, si l'objet ne reçoit pas la réponse pendant la première durée prédéterminée associée à la requête envoyée, quand l'objet est de nouveau actif, l'objet transmet un message, 20 éventuellement vide, pour constituer le message d'absence de réception de réponse. Dans des modes de réalisation, l'objet réitère un premier nombre prédéterminé de fois, la transmission d'un message pour constituer un message d'absence de réception de réponse, tant que l'objet ne reçoit pas la réponse pendant la première durée prédéterminée associée à un message envoyé, quand l'objet est de nouveau 25 actif. Dans des modes de réalisation, lorsque l'objet est le client du protocole applicatif contraint et le serveur applicatif est le serveur du protocole applicatif contraint, l'objet et le serveur applicatif utilisant des paquets incertains, si l'objet ne reçoit pas la réponse pendant la première durée prédéterminée associée à la requête 30 envoyée, quand l'objet est de nouveau actif, l'objet transmet un message vide pour constituer le message d'absence de réception de réponse. Dans des modes de réalisation, si l'objet ne reçoit pas la réponse pendant la première durée prédéterminée associée au message vide, quand l'objet est de nouveau actif, l'objet transmet un deuxième message comportant la requête et si 4 l'objet ne reçoit pas la réponse pendant la première durée prédéterminée associée au deuxième message comportant la requête, quand l'objet est de nouveau actif, l'objet transmet un message vide pour constituer le message d'absence de réception de réponse. 5 Dans des modes de réalisation, lorsque le serveur applicatif est le client du protocole applicatif contraint et l'objet est le serveur du protocole applicatif contraint, l'objet et le serveur applicatif utilisant des paquets incertains : - pour la transmission de la requête, le serveur applicatif effectue la transmission de la requête à un serveur de réseau, 10 - puis le serveur de réseau - conserve la requête, - attend une transmission d'un message quelconque par l'objet, - pendant une première durée prédéterminée après la transmission du message quelconque par l'objet, effectue une transmission de la requête à 15 l'objet et - transmet une notification de transmission au serveur applicatif, - quand l'objet a reçu la requête et est de nouveau actif, l'objet émet une réponse à destination du serveur applicatif, - quand le serveur applicatif n'a pas reçu de confirmation de réception de la requête 20 par l'objet à la fin d'une troisième durée prédéterminée, l'émission d'un message comportant la requête à destination de l'objet. Dans des modes de réalisation, la troisième durée prédéterminée est supérieure à la durée entre deux débuts d'intervalles de temps prédéterminés successifs pendant lesquels l'objet peut émettre des messages. 25 Dans des modes de réalisation, lorsque le serveur applicatif est le client du protocole applicatif contraint et l'objet est le serveur du protocole applicatif contraint, l'objet et le serveur applicatif utilisant des paquets fiables : - pour la transmission de la requête, le serveur applicatif transmet la requête à un serveur de réseau, 30 - puis le serveur de réseau : - conserve la requête, - attend une transmission d'un message quelconque par l'objet et, - pendant une première durée prédéterminée après la transmission du message quelconque par l'objet, transmet requête à l'objet et, 5 - quand l'objet est de nouveau actif, il émet une réponse à destination du serveur applicatif. Selon un deuxième aspect, la présente invention vise un dispositif de communication asymétrique entre un serveur applicatif et un objet, l'un des membres 5 du groupe constitué du serveur applicatif et de l'objet étant un client d'un protocole applicatif contraint et l'autre membre de ce groupe étant un serveur du protocole applicatif, dans lequel : - le client du protocole applicatif contraint est configuré pour émettre un message de requête, à destination du serveur du protocole applicatif contraint, 10 - le client du protocole applicatif contraint est configuré pour attendre une réponse de la part du serveur du protocole applicatif contraint, et - le serveur du protocole applicatif contraint est configuré pour, à réception d'un message émettre une réponse à destination du client du protocole applicatif contraint, dans lequel l'objet ne peut émettre un message qu'à des intervalles de temps 15 prédéterminés et ne peut recevoir un message que pendant une première durée prédéterminée après que l'objet ait envoyé un message, l'objet ne pouvant recevoir de message en dehors de ces premières durées prédéterminées le dispositif comportant, de plus, un moyen de stockage de chaque message émis par le serveur applicatif à destination de l'objet en dehors d'une première durée 20 indéterminée, configuré pour conserver ledit message jusqu'à l'émission d'un nouveau message par l'objet. BREVE DESCRIPTION DES FIGURES D'autres avantages, buts et caractéristiques de la présente invention 25 ressortiront de la description qui va suivre faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels : - la figure 1 représente, schématiquement, des serveurs et objets mettant en oeuvre le procédé objet de la présente invention, - la figure 2 représente, sous forme d'un logigramme, des étapes d'un 30 premier mode de réalisation du procédé objet de l'invention, - la figure 3 représente, sous forme d'un logigramme, des étapes d'un premier mode de réalisation du procédé objet de l'invention, 6 - la figure 4 représente des échanges de messages dans le cas où l'objet LoRaWAN est le client CoAP et le serveur applicatif, le serveur CoAP, et où des paquets LoRaWAN fiables sont utilisés, - la figure 5 représente des échanges de messages dans le cas où l'objet 5 LoRaWAN est le client CoAP et le serveur applicatif, le serveur CoAP, et où des paquets LoRaWAN incertains sont utilisés - la figure 6 représente des échanges de messages dans le cas où le serveur applicatif est le client CoAP et l'objet LoRaWAN, le serveur CoAP, et où des paquets LoRaWAN fiables sont utilisés et 10 - la figure 7 représente des échanges de messages dans le cas où le serveur applicatif est le client CoAP et l'objet LoRaWAN, le serveur CoAP, et où des paquets LoRaWAN incertains sont utilisés. DESCRIPTION DE MODES DE REALISATION DE L'INVENTION 15 On note, dès à présent, que les figures en sont pas à l'échelle. On observe, en figure 1, un réseau 10 comportant un serveur applicatif 11, un serveur de réseau 12 et des objets distribués 13. Le serveur applicatif 11 et le serveur de réseau 12 communiquent de manière filaire ou non filaire. Le serveur de réseau 12 et les objets distribués communiquent à 20 longue distance de manière non filaire, par exemple en mettant en oeuvre le réseau sans-fil à faible consommation énergétique LoRaWAN. Les objets distribués 13 sont, par exemple, des capteurs embarqués destinés à réaliser une remontée de données captées vers le serveur de réseau 12. Chacun des objets 13 ne peut émettre un message qu'à des intervalles de 25 temps prédéterminés et ne peut recevoir un message que pendant une première durée prédéterminée après que l'objet ait envoyé un message, l'objet ne pouvant recevoir de message en dehors de ces premières durées prédéterminées. La durée 50 entre deux débuts d'intervalles de temps prédéterminés successifs pendant lesquels l'objet peut émettre des messages est représentée en figures 4 et 7. La durée 30 51 pendant laquelle un objet peut recevoir un message après avoir émis un message est représentée en figure 7. On observe, en figure 2, un procédé de communication asymétrique entre un serveur applicatif et un objet, l'un des membres du groupe constitué du serveur 7 applicatif et de l'objet étant un client d'un protocole applicatif contraint et l'autre membre de ce groupe étant un serveur du protocole applicatif, qui comporte : - une première étape 21 d'émission d'un message de requête par le client du protocole applicatif contraint, à destination du serveur du protocole applicatif 5 contraint, - si la requête est destinée à l'objet et est transmis en dehors d'une première durée prédéterminée pendant laquelle l'objet peut recevoir un message, une étape 22 de stockage de la requête, préférentiellement par un serveur de réseau, jusqu'à émission d'un nouveau message par l'objet, le message 10 étant transmis à l'objet après que l'objet ait transmis un message, vide ou non, - à réception d'un message par le serveur du protocole applicatif contraint, une étape 23 d'émission d'une réponse par le serveur du protocole applicatif contraint à destination du client du protocole applicatif contraint, 15 - si la requête est destinée à l'objet et est transmis en dehors d'une première durée prédéterminée pendant laquelle l'objet peut recevoir un message, une étape 24 de stockage de la réponse, préférentiellement par un serveur de réseau, jusqu'à émission d'un nouveau message par l'objet, le message étant transmis à l'objet après que l'objet ait transmis un message, vide ou 20 non, et - une étape 25 d'attente, par le client du protocole applicatif contraint, d'une réponse de la part du serveur du protocole applicatif contraint ; dans lequel l'objet ne peut émettre un message qu'à des intervalles de temps prédéterminés et ne peut recevoir un message que pendant une première durée 25 prédéterminée après que l'objet ait envoyé un message, l'objet ne pouvant recevoir de message en dehors de ces premières durées prédéterminées. Concernant les étapes 22 et 24, si la requête ou le message est destiné au serveur applicatif, cette requête ou ce message est immédiatement transmis au serveur applicatif. Le procédé comporte ainsi, pour chaque échange de requête et réponse une étape, 22 ou 24. 30 Ces modes de réalisation permettent d'utiliser le protocole CoAP sur un réseau LoRaWAN précédemment incompatibles. On observe, en figure 3, un procédé de communication asymétrique entre un serveur applicatif et un objet, l'un des membres du groupe constitué du serveur 8 applicatif et de l'objet étant un client d'un protocole applicatif contraint et l'autre membre de ce groupe étant un serveur du protocole applicatif, qui comporte : - une première étape 21 d'émission d'un message de requête par le client du protocole applicatif contraint, à destination du serveur du protocole applicatif 5 contraint, - si la requête est destinée à l'objet et est transmis en dehors d'une première durée prédéterminée pendant laquelle l'objet peut recevoir un message, une étape 22 de stockage de la requête, préférentiellement par un serveur de réseau, jusqu'à émission d'un nouveau message par l'objet, le message 10 étant transmis à l'objet après que l'objet ait transmis un message, vide ou non, - à réception d'un message par le serveur du protocole applicatif contraint, une étape 23 d'émission d'une réponse par le serveur du protocole applicatif contraint à destination du client du protocole applicatif contraint, 15 - si la requête est destinée à l'objet et est transmis en dehors d'une première durée prédéterminée pendant laquelle l'objet peut recevoir un message, une étape 24 de stockage de la réponse, préférentiellement par un serveur de réseau, jusqu'à émission d'un nouveau message par l'objet, le message étant transmis à l'objet après que l'objet ait transmis un message, vide ou 20 non, - une étape 25 d'attente, par le client du protocole applicatif contraint, d'une réponse de la part du serveur du protocole applicatif contraint, - en l'absence d'une réponse de la part du serveur du protocole applicatif contraint, au cours d'une deuxième durée prédéterminée après la première 25 étape d'émission, une deuxième étape 26 d'émission d'un message d'absence de réception de réponse, effectuée par le client du protocole applicatif contraint au serveur de protocole applicatif contraint ; dans lequel l'objet ne peut émettre un message qu'à des intervalles de temps prédéterminés et ne peut recevoir un message que pendant une première durée 30 prédéterminée après que l'objet ait envoyé un message, l'objet ne pouvant recevoir de message en dehors de ces premières durées prédéterminées. Concernant les étapes 22 et 24, si la requête ou le message est destiné au serveur applicatif, cette requête ou ce message est immédiatement transmis au serveur applicatif. Le procédé comporte ainsi, pour chaque échange de requête et réponse une étape, 22 ou 24. 9 Ces modes de réalisation sont particulièrement adaptés à l'utilisation de paquets de données incertains ou à l'utilisation de paquets de données fiables lorsque l'objet LoRaWAN est le client du protocole applicatif contraint et le serveur applicatif, le serveur du protocole applicatif contraint. 5 On note que, dans le cas des objets LoRaWAN client CoAP, la première durée prédéterminée est la durée 51 des fenêtres de réception de message succédant à l'émission d'un message par ces objets et la deuxième durée prédéterminée est la durée 50 entre deux débuts de périodes d'activité. Concernant le protocole applicatif contraint, on donne, ci-dessous, une 10 description du Constrained Application Protocol (CoAP). CoAP est un protocole de communication défini par l'IETF (RFC 7252). Il s'agit d'un protocole équivalent à HTTP (acronyme de HyperText Transfer Protocol, littéralement « protocole de transfert hypertexte »), un protocole de communication client-serveur, mais CoAP utilise un encodage binaire. Ce protocole CoAP est conçu pour les réseaux UDP/IP qui n'offrent 15 aucune garantie de délivrance des trames. CoAP comprend donc des fonctionnalités de retransmission et de confirmation de réception des messages. Un message CoAP peut être soit de type non-confirmable, auquel cas l'expéditeur n'a aucune assurance du succès de la transmission, soit de type confirmable. Pour un message CoAP confirmable, l'expéditeur attend un accusé de 20 réception de la part du destinataire. Si cet accusé de réception n'est pas reçu dans les deux secondes, l'expéditeur retransmet son message jusqu'à quatre fois avec un délai d'attente doublé à chaque tentative. Le LoRaWAN est un protocole de communication s'appuyant sur la technologie radio LoRa. Un réseau LoRaWAN est un réseau en étoile où les objets 25 communiquent par radio avec un serveur de réseau central par l'intermédiaire de passerelles. Ce serveur de réseau distribue ensuite les messages au serveur applicatif associé à l'objet. Les objets LoRaWAN peuvent être de trois types en fonction de leur disponibilité : - Classe A : l'objet ne peut recevoir un message du serveur 30 qu'immédiatement après en avoir lui-même envoyé un. Le reste du temps, l'objet ne peut recevoir de message et est habituellement en veille. - Classe B : en plus du fonctionnement de la classe A, l'objet ouvre périodiquement une fenêtre de réception. - Classe C : l'objet est joignable à tout moment. 10 Au niveau LoRaWAN, les paquets peuvent être envoyés soit de façon fiable par demande d'un accusé de réception, soit de façon incertaine. Lorsqu'un paquet est envoyé par un serveur applicatif, il est stocké par le serveur de réseau jusqu'à ce que l'objet destinataire soit susceptible de le recevoir. 5 La grande majorité des objets LoRaWAN sont de classe A pour raison d'économie d'énergie. Une utilisation du mécanisme de retransmission de CoAP sur LoRaWAN n'est donc pas possible. Le mécanisme de retransmission des messages confirmables de CoAP est ignoré. On élimine ainsi les retransmissions superposées qui pourraient rendre la 10 communication impossible dans certaines conditions (éloignement, environnement bruyant, ...). Les quatre cas exposés en regard des figures 4 à 7, le caractère fiable ou incertain des paquets est une caractéristique du réseau, par exemple LoRaWAN. Un émetteur de message ou de requête peut choisir d'utiliser l'un ou l'autre. 15 Le rôle de Client CoAP ou de Serveur CoAP est fixé par l'émetteur de la requête, qui devient client CoAP, le destinataire devenant le serveur CoAP. Le Client envoie la requête, le Serveur y répond. Suivant le cas dans lequel on se trouve, les étapes de procédé de l'une ou l'autre des figures 4 à 7 sont mises en oeuvre. 20 La figure 4 représente l'application de la présente invention, dans le cas où un objet LoRaWAN 40 est le client CoAP et un serveur applicatif 42, le serveur CoAP et où ils utilisent des paquets LoRaWAN fiables. Le protocole utilisé est alors le suivant : A. L'objet 40 envoie une requête CoAP. Si l'objet 40 reçoit la réponse dans la 25 fenêtre de réception associée, la transmission est un succès. B. Si l'objet 40 ne reçoit pas la réponse dans la fenêtre de réception associée à la requête envoyée, quand l'objet 40 est de nouveau actif, l'objet 40 transmet soit un message CoAP, soit un message CoAP vide (lorsqu'il n'a aucune donnée particulière à transmettre) pour ouvrir une nouvelle fenêtre de réception. Si l'objet 40 30 reçoit la réponse dans la nouvelle fenêtre de réception associée, la transmission est un succès. Si l'objet 40 ne reçoit pas la réponse dans la nouvelle fenêtre de réception, l'étape B est répétée un premier nombre prédéterminé de fois, par exemple quatre. Le serveur applicatif doit répondre sans délai aux requêtes CoAP. 11 En figure 4, qui illustre ce protocole, l'objet LoRaWAN 40, client CoAP, envoie une requête CoAP 43 au serveur de réseau 41 qui transmet cette requête CoAP sous forme d'une requête 44 au serveur applicatif 42, serveur CoAP, ce qui correspond à l'étape 21 des figures 2 et 3. 5 La durée entre deux débuts d'intervalles de temps prédéterminés 51 pendant lesquels l'objet devient actif et peut émettre des messages est représentée en 50. L'émission de la requête 43 correspond à l'ouverture d'un intervalle de temps 46 (ou « fenêtre », en anglais « window ») de réception de la part de l'objet 40. A partir de la fin de la fenêtre de réception 46, l'objet 40 ne peut plus recevoir de message 10 jusqu'à l'émission, de sa part, d'un nouveau message. Le serveur applicatif 42 doit répondre sans délai aux requêtes CoAP qu'il reçoit. Le serveur applicatif 42, serveur CoAP, envoie donc un message de confirmation de réception (« acknowledgement » en anglais) 45 au serveur de réseau 41, ce qui correspond à l'étape 23 des figures 2 et 3. Si la fenêtre de réception 46 de 15 l'objet LoRaWAN 40, client CoAP, est encore ouverte (cas non représenté), le serveur de réseau 41 retransmet le message de confirmation à cet objet 40. La transmission de la requête CoAP 43 est alors un succès et l'objet en est informé. L'objet 40 n'ayant pas reçu de réponse dans la fenêtre de réception 46, comme dans le cas représenté en figure 4, quand l'objet 40 est de nouveau actif, 20 l'objet 40 transmet un message 47, qui est soit un message CoAP, soit un message CoAP vide (lorsqu'il n'a aucune donnée particulière à transmettre) au serveur de réseau 41, pour ouvrir sa fenêtre de réception et signaler cette ouverture de fenêtre de réception. Ce qui correspond à l'étape 26 de la figure 3. A réception du message 47, le serveur de réseau 41 adresse à l'objet 40 le 25 message de confirmation de réception 48, qui correspond au message 45. A défaut, c'est-à-dire si le serveur de réseau 41 n'adresse pas le message de confirmation de réception 48 à l'objet 40 ou si l'objet 40 ne reçoit pas ce message 48, préférentiellement l'objet 40 renvoie le message 47 à chaque fois qu'il redevient actif, jusqu'à un premier nombre prédéterminé (par exemple quatre) de transmission du 30 message 47. La figure 5 représente l'application de la présente invention, dans le cas où un objet LoRaWAN 60 est le client CoAP et un serveur applicatif 62, le serveur CoAP et où ils utilisent des paquets LoRaWAN incertains. Le protocole utilisé est alors le suivant : 12 C. L'objet 60 envoie une requête CoAP. S'il reçoit la réponse dans la fenêtre de réception associée, la transmission est un succès. D. Si l'objet 60 ne reçoit pas la réponse dans la fenêtre de réception associée à la requête envoyée, quand l'objet 60 est de nouveau actif, il transmet un message 5 CoAP vide, ce qui ouvre une nouvelle fenêtre de réception. Si l'objet 60 reçoit la réponse dans la nouvelle fenêtre de réception, la transmission est un succès. E. Si l'objet 60 ne reçoit pas la réponse dans la nouvelle fenêtre de réception, quand l'objet est de nouveau actif, l'objet 60 retransmet la requête CoAP. Si l'objet 60 reçoit la réponse dans la fenêtre de réception associée à cette retransmission de la 10 requête CoAP, la transmission est un succès. Si l'objet 60 ne reçoit pas la réponse dans la fenêtre de réception associée à la retransmission de la requête CoAP, les étapes D et E sont répétées un deuxième nombre prédéterminé de fois, par exemple quatre. Le serveur applicatif doit répondre sans délai aux requêtes CoAP. 15 En figure 5, qui illustre ce protocole, l'objet LoRaWAN 60, client CoAP, envoie une requête CoAP 63 au serveur de réseau 61, ce qui correspond à l'étape 21 des figures 2 et 3. L'émission de la requête 63 correspond à l'ouverture d'une fenêtre 64 de réception de la part de l'objet 60. A partir de la fin de la fenêtre de réception 64, l'objet 60 ne peut plus recevoir de message jusqu'à l'émission, de sa part, d'un 20 nouveau message. Le serveur de réseau 61 doit retransmettre la requête CoAP 63 au serveur applicatif 62 et le serveur applicatif 62 doit répondre sans délai aux requêtes CoAP qu'il reçoit, comme exposé en regard de la figure 4. En figure 5, on suppose que le serveur de réseau 61 n'a pas reçu la requête 63. Aucune réponse n'est donc envoyée 25 à l'objet 60. L'objet 60 n'ayant pas reçu de réponse dans la fenêtre de réception 64, l'objet 60 envoie un message CoAP vide 65 au serveur de réseau 61, ce qui ouvre une nouvelle fenêtre de réception 66. Ce qui correspond à l'étape 26 de la figure 3. Si le serveur de réseau 61 avait reçu la requête 63, l'avait retransmise au 30 serveur applicatif 62 et avait reçu la réponse de la part du serveur applicatif 62, le serveur de réseau 61 enverrait à l'objet 60, dans la fenêtre de réception 66, la réponse de confirmation de réception de la requête reçue par le serveur de réseau 61 de la part du serveur applicatif 62, comme expliqué en regard de la figure 4. 13 Dans le cas illustré en figure 5, puisque le serveur de réseau 61 n'a pas reçu la requête 63, il ne peut l'avoir retransmise au serveur applicatif 62. Le serveur de réseau 61 ne répond donc pas à l'objet 60 dans la fenêtre de réception 66. L'objet 60 n'ayant pas reçu de réponse dans la fenêtre de réception 66, l'objet 5 60 renvoie la requête au serveur de réseau 61, sous forme d'un message 67, ce qui ouvre une nouvelle fenêtre de réception 68. Ce qui correspond à l'étape 26 de la figure 3. On suppose que le serveur de réseau 61 reçoit la requête 67. Le serveur de réseau 61 retransmet donc cette requête au serveur applicatif 62, sous forme d'un message 69. 10 Le serveur applicatif 62 répond à la réception du message 69 sous la forme d'un message de confirmation de réception 70, adressé au serveur de réseau 61, ce qui correspond à l'étape 23 des figures 2 et 3. On suppose que le serveur de réseau 61 reçoit cette réponse en dehors de la fenêtre de réception 68 de l'objet 60. A défaut de réception, par l'objet 60 de réponse dans la fenêtre de réception 15 68, l'objet 60 réitère les envois successifs de messages vides et de copies de la requête initiale, jusqu'à un nombre d'itération prédéterminé, par exemple de quatre. Ainsi, dans le cas illustré en figure 5, l'objet 60 n'ayant pas reçu de réponse dans la fenêtre de réception 68, l'objet 60 envoie un message CoAP vide 71 au serveur de réseau 61, ce qui ouvre une nouvelle fenêtre de réception 72 et ce qui 20 correspond à l'étape 26 de la figure 3. Le serveur de réseau 61 envoie alors à l'objet 60, dans la fenêtre de réception 72, la réponse de confirmation de réception de la requête reçue par le serveur de réseau 61 de la part du serveur applicatif 62, sous forme d'un message 73. La figure 6 représente l'application de la présente invention, dans le cas où 25 un serveur applicatif 80 est le client CoAP et un objet LoRaWAN 82, le serveur CoAP et où ils utilisent des paquets LoRaWAN fiables. Le protocole utilisé est alors le suivant : F. Le serveur applicatif 80 envoie une requête CoAP. G. Le serveur de réseau notifie le serveur applicatif 80 lorsque la requête a 30 été transmise à l'objet 82 ou lorsque l'envoi a définitivement échoué au niveau LoRaWAN. H. Si la requête a été transmise à l'objet 80, le serveur applicatif 80 attend une réponse de l'objet 82. 14 En figure 6, qui illustre ce protocole, le serveur applicatif 80, client CoAP, envoie une requête CoAP 83 au serveur de réseau 81, ce qui correspond à l'étape 21 des figures 2 et 3. Lorsque l'objet 82 effectue une transmission quelconque 84, cette émission 5 correspond à l'ouverture d'une fenêtre de réception 85 de la part de l'objet 82. A partir de la fin de la fenêtre de réception 85, l'objet 82 ne peut plus recevoir de message jusqu'à l'émission, de sa part, d'un nouveau message. Le serveur de réseau 81 retransmet la requête 83 à l'objet 82, sous forme d'un message 86. Le serveur de réseau 81 transmet alors une notification de 10 délivrance 87 au serveur applicatif 80. Lorsqu'il redevient actif, l'objet 82 adresse un message 88 de confirmation de réception de la requête 86 au serveur de réseau 81, ce qui ouvre une fenêtre de réception 89, et ce qui correspond à l'étape 23 des figures 2 et 3. Le serveur de réseau 81 retransmet ce message de confirmation de réception 15 au serveur applicatif 80, sous la forme d'un message 90. La figure 7 représente l'application de la présente invention, dans le cas où un serveur applicatif 100 est le client CoAP et un objet LoRaWAN 102, le serveur CoAP et où ils utilisent des paquets LoRaWAN incertains. Le protocole utilisé est alors le suivant : 20 I. Le serveur applicatif 100 envoie une requête CoAP. J. Lorsque le serveur de réseau notifie le serveur applicatif 100 que la requête a été transmise, le serveur applicatif 100 attend une réponse pendant une troisième durée prédéterminée « ACK_TIMEOUT », par exemple 300 secondes. La troisième durée prédéterminée est préférentiellement supérieure à la durée 50 entre deux 25 débuts d'intervalles de temps prédéterminés successifs pendant lesquels l'objet peut émettre des messages et, encore plus préférentiellement, supérieure à somme de la durée 50 et de la première durée prédéterminée pendant laquelle l'objet peut recevoir des messages à la suite de l'émission d'un message par cet objet. K. Si la réponse de l'objet 102 n'a pas été reçue à la fin de la troisième durée 30 prédéterminée, le serveur applicatif 102 retransmet la requête CoAP. Les étapes J et K sont répétées jusqu'à un troisième nombre prédéterminé de fois, par exemple quatre. Lors de la réception d'une requête CoAP dans un paquet LoRaWAN incertain, l'objet doit donc répondre dans la troisième durée prédéterminée. 15 En figure 7, qui illustre ce protocole, le serveur applicatif 100, client CoAP, envoie une requête CoAP 103 au serveur de réseau 101, ce qui correspond à l'étape 21 des figures 2 et 3. Lorsque l'objet 102 effectue une transmission quelconque 104, cette émission 5 correspond à l'ouverture d'une fenêtre de réception 105 de la part de l'objet 102. A partir de la fin de la fenêtre de réception 105, l'objet 102 ne peut plus recevoir de message jusqu'à l'émission, de sa part, d'un nouveau message. Le serveur de réseau 101 retransmet la requête 103 à l'objet 102, sous forme d'un message 106. Le serveur de réseau 101 transmet alors une notification de 10 délivrance 107 au serveur applicatif 100. Le serveur applicatif 100 commence alors le décompte de la troisième durée prédéterminée 108 « ACK_TIMEOUT ». On suppose, dans le cas de la figure 7, que le message 106 n'a pas été reçu par l'objet 102. Lorsqu'il redevient actif, à l'instant 118, l'objet 102 n'envoie donc pas de message de confirmation de réception du message 106. La troisième durée 15 prédéterminée 108 « ACK_TIMEOUT » s'achève donc sans que le serveur applicatif 100 n'ait reçu de confirmation de réception de la requête 103. A la fin de cette durée, le serveur applicatif 100 renvoie la requête 103 au serveur de réseau 101, sous la forme d'un message 109. Ce qui correspond à l'étape 26 de la figure 3. 20 Lorsque l'objet 102 effectue une transmission quelconque 110, cette émission correspond à l'ouverture d'une fenêtre de réception 111 de la part de l'objet 102. Le serveur de réseau 101 retransmet la requête 109 à l'objet 102, sous forme d'un message 112. Le serveur de réseau 101 transmet alors une notification de délivrance 113 au serveur applicatif 100. Le serveur applicatif 100 commence alors le 25 décompte de la troisième durée prédéterminée 114 « ACK_TIMEOUT ». On suppose que le message 112 est reçu par l'objet 102. Lorsqu'il redevient actif, l'objet 102 envoie donc un message 115 de confirmation de réception du message 112, ce qui ouvre une fenêtre de réception 116, et ce qui correspond à l'étape 23 des figures 2 et 3. Le serveur de réseau 101 retransmet le message de 30 confirmation de réception, sous la forme d'un message 117. La troisième durée prédéterminée 114 « ACK_TIMEOUT » n'étant pas achevée, le serveur applicatif 100 ne renvoie pas la requête 103 une nouvelle fois. Comme on le comprend à la lecture de la description qui précède, la mise en oeuvre de la présente invention permet d'utiliser le protocole CoAP sur un réseau 16 LoRaWAN. On peut donc réaliser des opérations plus complexes, telles que la configuration et le contrôle à distance de l'objet, voire sa mise à jour logicielle. On note que, dans ce cas, on adapte le protocole CoAP pour le faire fonctionner sur LoRaWAN. On désactive la retransmission du protocole CoAP et on 5 adapte la durée de TIMEOUT (pour lui faire atteindre la troisième durée prédéterminée), REVENDICATIONS1. Procédé de communication asymétrique entre un serveur applicatif (42, 62, 80, 100) et un objet (40, 60, 82, 102), l'un des membres du groupe constitué du serveur applicatif et de l'objet étant un client d'un protocole applicatif contraint et l'autre membre de ce groupe étant un serveur du protocole applicatif, caractérisé en ce qu'il comporte : - une première étape (43, 63, 83, 103) d'émission d'un message de requête par le client (40, 60, 80, 100) du protocole applicatif contraint, à destination du serveur (42, 62, 82, 102) du protocole applicatif contraint, - une étape d'attente, par le client du protocole applicatif contraint, d'une réponse de la part du serveur du protocole applicatif contraint, et - à réception d'un message (44, 69, 86, 112) par le serveur du protocole applicatif contraint, une étape d'émission d'une réponse (45, 70, 88, 115) par le serveur du protocole applicatif contraint à destination du client du protocole applicatif contraint, dans lequel l'objet (40, 60, 82, 102) ne peut émettre un message qu'à des intervalles de temps prédéterminés et ne peut recevoir un message que pendant une première durée prédéterminée (46, 49, 64, 66, 68, 72, 85, 89, 105, 111, 116) après que l'objet ait envoyé un message, l'objet ne pouvant recevoir de message en dehors de ces premières durées prédéterminées, le procédé comportant, de plus, pour chaque message émis par le serveur applicatif à destination de l'objet en dehors d'une première durée indéterminée, une étape de stockage du message jusqu'à l'émission d'un nouveau message par l'objet. 2. Procédé selon la revendication 1, qui comporte, en l'absence d'une réponse de la part du serveur (42, 62, 82, 102) du protocole applicatif contraint, au cours d'une deuxième durée prédéterminée après la première étape d'émission, une deuxième étape d'émission d'un message (47, 65, 67, 71, 109) d'absence de réception de réponse destiné au serveur de protocole applicatif contraint, effectuée par le client (40, 60, 80, 100) du protocole applicatif contraint. 3. Procédé selon la revendication 2, dans lequel, lorsque l'objet (40) est le client du protocole applicatif contraint et le serveur applicatif (42) est le serveur du protocole 18 applicatif contraint, l'objet et le serveur applicatif utilisant des paquets fiables, si l'objet ne reçoit pas la réponse pendant la première durée prédéterminée (46) associée à la requête envoyée, quand l'objet est de nouveau actif, l'objet transmet un message (47), éventuellement vide, pour constituer le message d'absence de réception de réponse. 5 4. Procédé selon la revendication 3, dans lequel l'objet (40) réitère un premier nombre prédéterminé de fois, la transmission d'un message (47) pour constituer un message d'absence de réception de réponse, tant que l'objet ne reçoit pas la réponse pendant la première durée prédéterminée (46, 49) associée à un message envoyé, quand 10 l'objet est de nouveau actif. 5. Procédé selon l'une des revendications 2 à 4, dans lequel lorsque l'objet (50) est le client du protocole applicatif contraint et le serveur applicatif (52) est le serveur du protocole applicatif contraint, l'objet et le serveur applicatif utilisant des paquets 15 incertains, si l'objet ne reçoit pas la réponse pendant la première durée prédéterminée (54) associée à la requête envoyée, quand l'objet est de nouveau actif, l'objet transmet un message (55) vide pour constituer le message d'absence de réception de réponse. 6. Procédé selon la revendication 5, dans lequel si l'objet (50) ne reçoit pas la réponse 20 pendant la première durée prédéterminée (56) associée au message (55) vide, quand l'objet est de nouveau actif, l'objet transmet un deuxième message (57) comportant la requête et si l'objet ne reçoit pas la réponse pendant la première durée prédéterminée (58) associée au deuxième message comportant la requête, quand l'objet est de nouveau actif, l'objet transmet un message (61) vide pour constituer le message 25 d'absence de réception de réponse. 7. Procédé selon l'une des revendications 2 à 6, dans lequel lorsque le serveur applicatif (90) est le client du protocole applicatif contraint et l'objet (92) est le serveur du protocole applicatif contraint, l'objet et le serveur applicatif utilisant des paquets 30 incertains : - pour la transmission de la requête, le serveur applicatif effectue la transmission de la requête (93) à un serveur de réseau (91), - puis le serveur de réseau - conserve la requête, 19 - attend une transmission d'un message quelconque (94) par l'objet, - pendant une première durée prédéterminée (95) après la transmission du message quelconque par l'objet, effectue une transmission de la requête (96) à l'objet et 5 - transmet une notification de transmission (97) au serveur applicatif, - quand l'objet a reçu la requête et est de nouveau actif, l'objet émet (115) une réponse à destination du serveur applicatif, - quand le serveur applicatif n'a pas reçu de confirmation de réception de la requête par l'objet à la fin d'une troisième durée prédéterminée (98, 114), l'émission d'un 10 message (99) comportant la requête à destination de l'objet. 8. Procédé selon la revendication 7, dans lequel la troisième durée prédéterminée (98, 114) est supérieure à la durée (50) entre deux débuts d'intervalles de temps prédéterminés successifs pendant lesquels l'objet peut émettre des messages. 15 9. Procédé selon l'une des revendications 1 à 8, dans lequel lorsque le serveur applicatif (70) est le client du protocole applicatif contraint et l'objet (72) est le serveur du protocole applicatif contraint, l'objet et le serveur applicatif utilisant des paquets fiables : 20 - pour la transmission de la requête, le serveur applicatif transmet la requête (73) à un serveur de réseau (71), - puis le serveur de réseau : - conserve la requête, - attend une transmission d'un message quelconque (74) par l'objet et, 25 - pendant une première durée prédéterminée (75) après la transmission du message quelconque par l'objet, transmet requête (76) à l'objet et, - quand l'objet est de nouveau actif, il émet (78) une réponse à destination du serveur applicatif. 30 10 . Dispositif de communication asymétrique entre un serveur applicatif (11, 42, 62, 80, 100) et un objet (13, 40, 60, 82, 102), l'un des membres du groupe constitué du serveur applicatif et de l'objet étant un client (40, 60, 80, 100) d'un protocole applicatif contraint et l'autre membre de ce groupe étant un serveur (42, 62, 82, 102) du protocole applicatif, caractérisé en ce que : 20 - le client du protocole applicatif contraint est configuré pour émettre un message de requête, à destination du serveur du protocole applicatif contraint, - le client du protocole applicatif contraint est configuré pour attendre une réponse de la part du serveur du protocole applicatif contraint, et 5 - le serveur du protocole applicatif contraint est configuré pour, à réception d'un message émettre une réponse à destination du client du protocole applicatif contraint, dans lequel l'objet ne peut émettre un message qu'à des intervalles de temps prédéterminés et ne peut recevoir un message que pendant une première durée prédéterminée (46, 49, 64, 66, 68, 72, 85, 89, 105, 111, 116) après que l'objet ait 10 envoyé un message, l'objet ne pouvant recevoir de message en dehors de ces premières durées prédéterminées, le dispositif comportant, de plus, un moyen de stockage de chaque message émis par le serveur applicatif à destination de l'objet en dehors d'une première durée indéterminée, configuré pour conserver ledit message jusqu'à l'émission d'un 15 nouveau message par l'objet.