FR 3132812 A1 20230818 FR 2201212 A 20220211 L’invention concerne un procédé (100) de communication entre un dispositif émetteur et un dispositif récepteur. Le procédé (100) comporte les étapes suivantes au niveau du dispositif émetteur : formation (101) d’un paquet de transport comportant plusieurs paquets applicatifs, fragmentation (102) du paquet de transport en plusieurs fragments ordonnées, chaque paquet applicatif correspondant à un ou plusieurs fragments, transmission (103) desdits fragments. Le procédé (100) comporte les étapes suivantes au niveau du dispositif récepteur : réception (104) de fragments du paquet de transport, pour chaque nouveau fragment reçu d’un paquet applicatif : vérification (105) si un critère de transmission est satisfait en fonction des fragments déjà reçus, si oui, transmission (106) d’au moins un fragment du paquet applicatif, même si tous les fragments du paquet de transport n’ont pas encore été reçus. Figure pour l’abrégé : Fig. 7 Procédé et dispositif pour communiquer des données de façon fiable, efficace et continue Domaine de l’invention La présente invention appartient au domaine de la communication de données entre un dispositif émetteur et un dispositif récepteur d’un système de communication. L’invention concerne notamment la couche de transport d’un protocole de communication. L’invention s’applique particulièrement bien à un système de communication s’appuyant sur un réseau d’accès sans fil de type LPWAN (acronyme anglais de « Low-Power Wide Area Network », en français « réseau étendu à basse consommation d’énergie »). Etat de la technique L'IETF (acronyme anglais de « Internet Engineering Task Force », en français « groupe de travail sur l’ingénierie Internet ») a récemment normalisé le protocole SCHC (acronyme anglais de « Static Context Header Compression », en français « compression d’en-tête à partir d’un contexte statique ») également connu sous l’identifiant « RFC 8724 ». Cette norme vise notamment à standardiser la communication de paquets de taille relativement grande, par exemple des paquets IPv6 (acronyme anglais de « Internet Protocol version 6 », en français « version 6 du protocole Internet ») entre deux entités d’un réseau LPWAN. Les technologies LPWAN imposent des contraintes assez fortes au trafic. Par exemple, les appareils sont en veille la plupart du temps et ne peuvent recevoir des données que pendant de courtes périodes après la transmission, afin de préserver la batterie. Les technologies LPWAN se caractérisent généralement par une taille réduite des paquets de données échangés. Le protocole SCHC présente un cadre générique proposant des mécanismes de compression d’en-tête, de fragmentation de paquet et de retransmission de fragments perdus. Le protocole SCHC a notamment été conçu pour permettre le transport de paquets de taille relativement grande dans un réseau LPWAN. Le protocole SCHC définit une fonctionnalité générique et offre une certaine souplesse en ce qui concerne le paramétrage et le choix de ces mécanismes. En particulier, des profils spécialisés peuvent définir les paramètres et les mécanismes spécifiques à des technologies LPWAN particulières. Dans le protocole SCHC, une couche d’adaptation (couche SCHC) est implémentée par un dispositif émetteur et par un dispositif récepteur. La couche d’adaptation est située entre une couche de liaison de niveau inférieur et une couche applicative de niveau supérieur. Lorsque le mécanisme de fragmentation/réassemblage est mis en œuvre, la couche d’adaptation du dispositif émetteur est configurée pour former un paquet de transport (paquet SCHC) à partir de données en provenance de la couche applicative, pour fragmenter ledit paquet de transport en plusieurs fragments ordonnées, et pour transmettre lesdits fragments vers la couche de liaison du dispositif émetteur. La couche d’adaptation du dispositif récepteur est configurée pour recevoir des fragments du paquet de transport en provenance de la couche de liaison du dispositif récepteur, pour réassembler lesdits fragments, et pour transmettre le paquet de transport ainsi réassemblé vers la couche applicative. Cependant, toutes les applications d’un système de communication LPWAN ne requièrent pas nécessairement l'utilisation de paquets de grande taille. Certaines applications nécessitent l'envoi de petites quantités de données mais exigent des mécanismes de transport plus fiables que ceux fournis nativement par les différentes technologies LPWAN. Ces applications ont en outre souvent des contraintes sur la surcharge protocolaire requise pour la fiabilisation du transport de données de chaque paquet applicatif (un paquet applicatif pouvant potentiellement être de petite taille), ainsi que des exigences de latence sur le traitement de chaque paquet applicatif. Le protocole SCHC n’offre pas, dans sa version actuelle, une solution satisfaisante pour répondre à ce genre d’exigences. La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant des améliorations au protocole SCHC pour permettre la communication de paquets de données de façon fiable, efficace et continue. A cet effet, et selon un premier aspect, il est proposé par la présente invention, un procédé de communication d’un paquet de transport entre un dispositif émetteur et un dispositif récepteur d’un système de communication sans fil. Le procédé est implémenté par le dispositif émetteur et par le dispositif récepteur au niveau d’une couche d’adaptation entre une couche de liaison de niveau inférieur et une couche applicative de niveau supérieur. Au niveau de la couche d’adaptation du dispositif émetteur, le procédé comporte : - une formation du paquet de transport à partir de données en provenance de la couche applicative, le paquet de transport comportant plusieurs paquets applicatifs, - une fragmentation du paquet de transport en plusieurs fragments ordonnées, chaque paquet applicatif correspondant à un ou plusieurs fragments, - une transmission desdits fragments vers la couche de liaison du dispositif émetteur. Au niveau de la couche d’adaptation du dispositif récepteur, le procédé comporte : - une réception, en provenance de la couche de liaison du dispositif récepteur, des fragments du paquet de transport, pour chaque nouveau fragment d’un paquet applicatif reçu la couche d’adaptation du dispositif récepteur : - une vérification si un critère de transmission est satisfait pour ledit paquet applicatif en fonction des fragments déjà reçus pour ledit paquet applicatif, - si le critère de transmission est satisfait, une transmission vers la couche applicative du dispositif récepteur d’au moins un fragment déjà reçu pour ledit paquet applicatif, même si tous les fragments du paquet de transport n’ont pas encore été reçus. Le fait de regrouper plusieurs paquets applicatifs dans un même paquet de transport (c’est-à-dire dans une même session de transport) plutôt que d’associer chaque paquet applicatif à un paquet de transport (ou à une session de transport), comme cela est préconisé dans la version actuelle du protocole SCHC, permet de réduire la surcharge protocolaire par paquet applicatif. En effet, dans le procédé selon l’invention, et contrairement à la version actuelle du protocole SCHC, il n’est plus nécessaire d’émettre un message d’acquittement pour chaque paquet applicatif. Un seul message d’acquittement pour l’ensemble des paquets applicatifs formant le paquet de transport peut être suffisant dans certaines conditions, notamment lorsqu’il n’y a pas de pertes de fragments. Même si certains fragments sont perdus, le nombre de messages d’acquittement nécessaire est généralement moindre que si chaque paquet applicatif était associé à un paquet de transport. En outre, le fait qu’un paquet applicatif puisse être au moins partiellement transmis à la couche applicative du dispositif récepteur même si les autres paquets applicatifs du paquet de transport n’ont pas tous été reçus permet un traitement au plus tôt du paquet applicatif par la couche applicative du dispositif récepteur. Ainsi, dans certaines conditions, les paquets applicatifs peuvent être transmis à la couche applicative du dispositif récepteur au fur et à mesure de leur réception par la couche d’adaptation du dispositif récepteur. On peut alors parler de « streaming » au niveau de la couche d’adaptation du dispositif récepteur. Cela permet de réduire la latence et d’accéder aux informations transmises le plus tôt possible. Dans des modes particuliers de mise en œuvre, l’invention peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, le procédé comporte au niveau de la couche d’adaptation du dispositif récepteur, en réponse à la réception du dernier fragment du paquet de transport, une émission d’au moins un message d’acquittement renseignant sur des fragments correctement reçus et des fragments manquants du paquet de transport. Dans des modes particuliers de mise en œuvre, au niveau de la couche d’adaptation du dispositif émetteur, les étapes de formation du paquet de transport, de fragmentation du paquet de transport et de transmission des fragments sont exécutées de façon simultanée. Ainsi, les paquets applicatifs sont fragmentés et transmis au fur et à mesure de leur réception par la couche d’adaptation du dispositif récepteur avant que toutes les données formant le paquet de transport n’aient été reçues de la couche applicative du dispositif émetteur. On peut alors parler de « streaming » au niveau de la couche d’adaptation du dispositif émetteur. Dans des modes particuliers de mise en œuvre, la couche d’adaptation du dispositif émetteur et la couche d’adaptation du dispositif récepteur sont des couches SCHC. Dans des modes particuliers de mise en œuvre, le critère de transmission est vérifié si tous les fragments dudit paquet applicatif ont été reçus par la couche d’adaptation du dispositif récepteur. Dans des modes particuliers de mise en œuvre, un paquet applicatif comporte plusieurs fragments, et le critère de transmission est vérifié si le nombre de fragments reçus pour ledit paquet applicatif est au moins égal à un nombre prédéterminé et si une différence entre un instant de réception d’un premier fragment pour ledit paquet applicatif et un instant courant est au moins égale à une durée prédéterminée. Dans des modes particuliers de mise en œuvre, un paquet applicatif comporte plusieurs fragments, et le critère de transmission est vérifié si au moins un sous-ensemble prédéterminé des fragments dudit paquet applicatif ont été reçus et si une différence entre un instant de réception d’un premier fragment pour ledit paquet applicatif et un instant courant est au moins égale à une durée prédéterminée. Dans des modes particuliers de mise en œuvre, la vérification si le critère de transmission est satisfait est effectuée en fonction des autres paquets applicatifs déjà reçus pour le paquet de transport. Dans des modes particuliers de mise en œuvre, le procédé comporte : au niveau de la couche d’adaptation du dispositif émetteur : - pour chaque fragment initialement transmis vers la couche de liaison du dispositif émetteur, une mémorisation d’un instant de transmission initiale dudit fragment, - pour chaque fragment indiqué comme manquant dans le message d’acquittement : o un calcul d’un délai de retransmission correspondant à une différence entre l’instant de transmission initiale dudit fragment et un instant de retransmission dudit fragment, o une retransmission dudit fragment en incluant une information relative audit délai de retransmission, au niveau de la couche d’adaptation du dispositif récepteur : - une estimation de l’instant de transmission initiale dudit fragment à partir d’un instant de réception dudit fragment et de l’information relative au délai de retransmission incluse dans ledit fragment. De telles dispositions permettent au dispositif récepteur de savoir à quel instant un fragment a été transmis par le dispositif émetteur pour la première fois, même si le fragment a dû être retransmis par le dispositif émetteur, tout en limitant la quantité de données à transmettre. Selon un deuxième aspect, la présente invention concerne un dispositif récepteur d'un système de communication sans fil comportant un processeur implémentant une couche d’adaptation entre une couche de liaison de niveau inférieur et une couche applicative de niveau supérieur. Le processeur est configuré au niveau de la couche d’adaptation pour recevoir, en provenance de la couche de liaison, des fragments d’un paquet de transport émis par un dispositif émetteur du système de communication sans fil. Le paquet de transport comporte plusieurs paquets applicatifs, chaque paquet applicatif correspondant à un ou plusieurs fragments. Le processeur est configuré au niveau de la couche d’adaptation, pour chaque nouveau fragment reçu d’un paquet applicatif, pour : vérifier si un critère de transmission est satisfait pour ledit paquet applicatif en fonction des fragments déjà reçus pour ledit paquet applicatif, et si le critère de transmission est satisfait, transmettre vers la couche applicative au moins un fragment déjà reçu pour ledit paquet applicatif, même si tous les fragments du paquet de transport n’ont pas encore été reçus. Dans des modes particuliers de réalisation, l’invention peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles. Dans des modes particuliers de mise en œuvre, le processeur est en outre configuré au niveau de la couche d’adaptation pour émettre, en réponse à la réception du dernier fragment du paquet de transport, au moins un message d’acquittement renseignant sur des fragments correctement reçus et des fragments manquants du paquet de transport. Dans des modes particuliers de réalisation, la couche d’adaptation est une couche SCHC. Dans des modes particuliers de mise en œuvre, le critère de transmission est vérifié si tous les fragments dudit paquet applicatif ont été reçus. Dans des modes particuliers de réalisation, un paquet applicatif comporte plusieurs fragments, et le critère de transmission est vérifié si le nombre de fragments reçus pour ledit paquet applicatif est au moins égal à un nombre prédéterminé et si une différence entre un instant de réception d’un premier fragment pour ledit paquet applicatif et un instant courant est au moins égale à une durée prédéterminée. Dans des modes particuliers de réalisation, un paquet applicatif comporte plusieurs fragments, et le critère de transmission est vérifié si au moins un sous-ensemble prédéterminé des fragments dudit paquet applicatif ont été reçus et si une différence entre un instant de réception d’un premier fragment pour ledit paquet applicatif et un instant courant est au moins égale à une durée prédéterminée. Dans des modes particuliers de réalisation, la vérification si le critère de transmission est satisfait est effectuée en fonction des autres paquets applicatifs déjà reçus pour le paquet de transport. Dans des modes particuliers de réalisation, le processeur est configuré, au niveau de la couche d’adaptation, pour : recevoir une retransmission d’un fragment indiqué comme manquant dans le message d’acquittement, et estimer un instant de transmission initiale du fragment manquant par le dispositif émetteur à partir d’un instant de réception du fragment retransmis et d’une information relative à un délai de retransmission correspondant à une différence entre l’instant de transmission initiale dudit fragment et un instant de retransmission dudit fragment par le dispositif émetteur, ladite information étant incluse dans le fragment retransmis. Présentation des figures L’invention sera mieux comprise à la lecture de la description suivante, donnée à titre d’exemple nullement limitatif, et faite en se référant aux figures 1 à 7 qui représentent : une représentation schématique d’un exemple d’un système de communication comportant un terminal et un serveur applicatif pouvant s’échanger des données via un réseau d’accès sans fil, une représentation schématique d’un paquet de transport comportant plusieurs paquets applicatifs, chaque paquet applicatif étant fragmenté en un ou plusieurs fragments, une représentation schématique du format d’un fragment selon le protocole SCHC, une illustration d’un premier exemple de transmission d’un paquet de transport depuis un dispositif émetteur vers un dispositif récepteur selon le protocole SCHC, une illustration d’un deuxième exemple de transmission d’un paquet de transport depuis un dispositif émetteur vers un dispositif récepteur selon le protocole SCHC, une illustration d’un exemple de transmission d’un paquet de transport depuis un dispositif émetteur vers un dispositif récepteur selon le procédé de communication selon l’invention, une représentation schématique des principales étapes du procédé de communication selon l’invention. Dans ces figures, des références identiques d’une figure à une autre désignent des éléments identiques ou analogues. Pour des raisons de clarté, les éléments représentés ne sont pas nécessairement à une même échelle, sauf mention contraire. Description détaillée d’un mode de réalisation de l’invention La représente schématiquement un exemple d’un système 10 de communication sans fil comportant au moins un terminal 20, un réseau d’accès 30, et un serveur applicatif 40. Le réseau d’accès 30 comporte plusieurs stations de base 31 et un serveur passerelle 32 relié auxdites stations de base 31. Les terminaux 20 sont adaptés à émettre des messages sur un lien montant à destination du réseau d’accès 30. Chaque station de base 31 est adaptée à recevoir les messages d’un terminal 20 lorsque ledit terminal se trouve à sa portée. De manière conventionnelle, un message émis par un terminal 20 comporte un identifiant du terminal 20. Chaque message reçu par une station de base 31 est par exemple transmis au serveur passerelle 32, éventuellement accompagné d’autres informations comme un identifiant de la station de base 31 qui l’a reçu, le niveau de puissance de réception dudit message reçu, l’instant d’arrivée dudit message, la fréquence à laquelle le message a été reçu, etc. Le serveur passerelle 32 traite par exemple l’ensemble des messages reçus des différentes stations de base 31. Le système 10 de communication sans fil peut être monodirectionnel, c'est-à-dire qu’il ne permet des échanges de messages que sur le lien montant des terminaux 20 vers le réseau d’accès 30. Rien n’exclut cependant, suivant d’autres exemples, de permettre des échanges bidirectionnels. Le cas échéant, le réseau d’accès 30 est également adapté à émettre, par l’intermédiaire des stations de base 31, des messages sur un lien descendant à destination des terminaux 20, lesquels sont adaptés à les recevoir. Dans l’exemple considéré, le réseau d’accès 30 est un réseau LPWAN. Un tel système de communication sans fil est un réseau d’accès à longue portée (supérieure à un kilomètre, voire même supérieure à quelques dizaines de kilomètres), à faible consommation énergétique (par exemple une consommation énergétique lors de la transmission ou de la réception d’un message inférieure à 100 mW, voire inférieure à 50 mW, voire même inférieure à 25 mW), et dont les débits sont généralement inférieurs à 1 Mbits/s. De tels systèmes de communication sans fil sont particulièrement adaptés pour des applications de type IoT (acronyme anglais pour « Internet Of Things », en français « Internet des objets ») ou M2M (acronyme anglais pour « Machine-to-Machine », en français « machine-à-machine »). Dans un système de communication de type IoT ou M2M, les échanges de données sont essentiellement monodirectionnels, en l’occurrence sur un lien montant des terminaux 20 vers le réseau d’accès 30 du système 10 de communication sans fil. Afin de minimiser les risques de perdre un message émis par un terminal 20, la planification du réseau d’accès est souvent réalisée de telle sorte qu’une zone géographique donnée est couverte simultanément par plusieurs stations de base 31, de telle manière qu’un message émis par un dispositif émetteur 20 peut être reçu par plusieurs stations de base 31. Dans la suite de la description, on considère à titre d’exemple nullement limitatif que le réseau d’accès 30 est un réseau LPWAN à bande ultra étroite. Par « bande ultra étroite » (« Ultra Narrow Band » ou UNB dans la littérature anglo-saxonne), on entend que le spectre fréquentiel instantané des signaux radioélectriques émis par les terminaux est de largeur fréquentielle inférieure à deux kilohertz, voire inférieure à un kilohertz. Dans la suite de la description, on s’intéresse à une communication depuis un terminal 20 vers le serveur applicatif 40 via le réseau d’accès 30. Le terminal 20 joue donc le rôle de dispositif émetteur, alors que le serveur applicatif 40 joue le rôle de dispositif récepteur. La référence 20 de la se rapporte donc aussi bien à un terminal qu’à un dispositif émetteur ; et la référence 40 de la se rapporte aussi bien à un serveur applicatif qu’à un dispositif récepteur. Rien n’empêcherait toutefois que l’invention s’applique à une communication depuis le serveur applicatif vers un terminal, auquel cas le serveur applicatif jouerait le rôle de dispositif émetteur et le terminal jouerait le rôle de dispositif récepteur. Tel qu’illustré schématiquement sur la , le dispositif émetteur 20 comporte un processeur qui implémente une couche d’adaptation 22 entre une couche de liaison de niveau inférieur 21 et une couche applicative de niveau supérieur 23. La couche d’adaptation 22 est configurée pour former un paquet de transport à partir de données en provenance de la couche applicative 23, pour fragmenter ledit paquet de transport en plusieurs fragments ordonnées, et pour transmettre lesdits fragments 52 vers la couche de liaison 21. La couche de liaison 21 peut s’appuyer sur une couche physique pour transmettre sur un lien radio lesdits fragments du paquet de transport à destination du réseau d’accès 30. Le dispositif récepteur 40 comporte également un processeur qui implémente une couche d’adaptation 42 entre une couche de liaison de niveau inférieur 41 et une couche applicative de niveau supérieur 43. La couche de liaison 41 peut s’appuyer sur une couche physique pour recevoir sur un lien de communication les fragments du paquet de transport émis par le dispositif émetteur 20. Le lien de communication reliant le dispositif récepteur 40 au réseau d’accès 30 peut être un lien filaire ou un lien radio. La couche d’adaptation 42 est configurée pour traiter les fragments du paquet de transport reçus en provenance de la couche de liaison 41. La représente schématiquement un paquet de transport 50. Le paquet de transport 50 est formé par la couche d’adaptation 22 du dispositif émetteur 20 à partir de données applicatives reçues en provenance de la couche applicative 23 du dispositif émetteur 20. Le paquet de transport 50 est destiné à être transmis au dispositif récepteur 40. Avantageusement, le paquet de transport 50 est formé à partir de plusieurs paquets applicatifs 51. Dans l’exemple considéré et illustré à la , le paquet de transport 50 comporte sept paquets applicatifs 51 concaténés les uns à la suite des autres. Comme cela sera détaillé par la suite, de telles dispositions permettent d’une part de limiter la surcharge protocolaire liée à la fiabilisation du transport des données, et d’autre part de pouvoir traiter les paquets applicatifs au fur et à mesure de leur réception au niveau du dispositif récepteur 40. Un paquet applicatif 51 correspond à un paquet de données pouvant potentiellement être traité par la couche applicative 43 du dispositif récepteur 40 sans qu’il ne soit nécessaire que tous les autres paquets applicatifs 51 du paquet de transport 50 soient également à la disposition de la couche applicative 43. Par exemple, un paquet applicatif 51 peut être traité indépendamment des autres paquets applicatifs 51 transportés dans le même paquet de transport 50. Selon un autre exemple, un paquet applicatif 51 contenu dans un paquet de transport 50 et qui n’est pas le premier paquet applicatif du paquet de transport 50 peut être traité par la couche applicative 43 du dispositif récepteur 40 dès lors que le premier paquet applicatif 51 du paquet de transport a également été reçu par la couche applicative 43, sans qu’il ne soit nécessaire que les autres paquets applicatifs 51 soient également à la disposition de la couche applicative 43. Comme on le verra par la suite, dans des modes particuliers de mise en œuvre, un paquet applicatif 51 peut être traité par la couche applicative 43 du dispositif récepteur 40 même si seulement certains des fragments 52 composant le paquet applicatif 51 ont été reçus par le dispositif récepteur 40. Il convient de noter que les paquets applicatifs peuvent éventuellement être transmis à la couche applicative 43 du dispositif récepteur 40 dans un ordre différent de l’ordre dans lequel les paquets applicatifs sont émis par le dispositif émetteur 20. Tel qu'illustré sur la , le paquet de transport 50 est fragmenté par la couche d’adaptation 22 du dispositif émetteur 20 en plusieurs fragments 52. Chaque paquet applicatif 51 correspond à un ou plusieurs fragments 52. Dans l’exemple considéré et illustré à la , chaque paquet applicatif 51 comporte deux fragments 52. Le paquet de transport 50 est ainsi fragmenté en quatorze fragments 52. Les fragments 52 sont ordonnés. On entend par là que le rang de chaque fragment dans la séquence des fragments composant le paquet de transport 50 peut être identifié, par exemple par un numéro de séquence. Les fragments 52 sont ensuite transmis vers la couche de liaison 21 du dispositif émetteur pour être émis sur un lien radio à destination du dispositif récepteur 40 via le réseau d’accès 30. Il convient de noter, comme cela sera d’ailleurs détaillé par la suite, qu’au niveau du dispositif émetteur 20, les étapes de formation du paquet de transport 50, de fragmentation du paquet de transport et de transmission des fragments ne sont pas nécessairement mises en œuvre de façon séquentielle. Ainsi, dans des modes particuliers de mise en œuvre, ces étapes sont exécutées de façon simultanée, de telle sorte qu’un fragment 52 du paquet de transport 50 peut être formé et transmis avant que toutes les données formant le paquet de transport 50 n’aient été reçues par la couche d’adaptation 42 du dispositif récepteur 43. Dans un tel cas, la formation du paquet de transport 50 doit être vue comme un groupement des paquets applicatifs 51 au sein d’une session de transport (ou une association des paquets applicatifs 51 à une session de transport). Il y a alors une correspondance entre un paquet de transport 50 et une session de transport (dans la version actuelle du protocole SCHC, il y a déjà cette correspondance entre un paquet de transport et une session de transport, mais un paquet de transport ne comporte qu’un seul paquet applicatif). La fragmentation du paquet de transport 50 doit alors être vue comme la fragmentation de chaque paquet applicatif 51 appartenant à la session de transport en un ou plusieurs fragments 52. Un tel mode de mise en œuvre correspond à un scénario où les paquets applicatifs 51 sont fragmentés et transmis par la couche d’adaptation 22 du dispositif émetteur 20 dans la session de transport au fur et à mesure de leur réception (c’est-à-dire en « streaming »). Dans la suite de la description, on se place dans le cas où la couche d’adaptation 22 du dispositif émetteur 20 et la couche d’adaptation 42 du dispositif récepteur 40 s’appuient sur le protocole SCHC défini par le standard IETF RFC 8724. Il convient toutefois de noter que l’invention pourrait également s’appliquer à des cas où la couche d’adaptation 22 du dispositif émetteur 20 et la couche d’adaptation 42 du dispositif récepteur 40 s’appuient sur un protocole différent du protocole SCHC. En effet, l’invention peut s’appliquer dès lors que la couche d’adaptation 22 du dispositif émetteur 20 implémente un mécanisme de fragmentation d’un paquet de transport 50 comportant plusieurs paquets applicatifs 51, et que la couche d’adaptation 42 du dispositif récepteur 40 traite les fragments 52 reçus conformément aux étapes de traitement décrites ci-après. Le protocole SCHC présente un cadre générique fournissant différents mécanismes facultatifs permettant le transport de paquets de taille relativement grande dans un réseau d’accès LPWAN. Le protocole SCHC propose notamment un mécanisme de fragmentation pour fragmenter un paquet de transport 50 en plusieurs fragments 52 de plus petite taille. Cela permet d’émettre le paquet de transport 50 via la technologie radio mise en œuvre par le réseau d’accès 30 considéré même si la taille maximale d’un paquet supporté par cette technologie radio est inférieure à la taille du paquet de transport 50. Le protocole SCHC propose également un mécanisme de compression/décompression d’un en-tête du paquet de transport sur la base d’un contexte statique partagé entre le dispositif émetteur 20 et le dispositif récepteur 40. Ce mécanisme de compression/décompression est toutefois facultatif et n’a pas d’impact sur l’invention discutée dans la présente demande. Pour le mécanisme de fragmentation, le protocole SCHC propose trois modes différents. Les trois modes sont les suivants : No-ACK, ACK-Always et ACK-on-Error. Le mode No-ACK est conçu pour les liaisons unidirectionnelles, sans retour d'information du dispositif récepteur 40 vers le dispositif émetteur 20. Les modes ACK-Always et ACK-on-Error apportent une fiabilité supplémentaire dans la communication établie entre le dispositif émetteur 20 et le dispositif récepteur 40. ACK-Always et ACK-on-Error nécessitent toutefois un lien bidirectionnel entre le dispositif émetteur 20 et le dispositif récepteur 40. Dans le mode ACK-Always, un message d’acquittement (SCHC ACK) est émis par le dispositif récepteur 40 à destination du dispositif émetteur 20 après la réception d'un groupe de fragments 52 appelés une fenêtre, qu'il y ait ou non des pertes de fragments 52 à l’intérieur de la fenêtre. Un fragment peut en effet être perdu lors de sa transmission sur le lien radio entre le dispositif émetteur 20 et le réseau d’accès 30 lorsque la qualité du lien radio est mauvaise. Selon un autre exemple, un fragment peut être perdu entre le réseau d’accès 30 et le dispositif récepteur 40 en cas de défaillance d’un de ces éléments. Le message d’acquittement renseigne sur des fragments 52 correctement reçus et des fragments 52 manquants (perdus) du paquet de transport 50. En réponse au message d’acquittement, le dispositif émetteur 20 peut retransmettre les fragments 52 qui n’ont pas été reçus par le dispositif récepteur 40. Dans le mode ACK-on-Error, un message d’acquittement n'est généralement émis par le dispositif récepteur 40 que s'il y a au moins un fragment 52 manquant dans une fenêtre. Dans les deux modes ACK-Always et ACK-on-Error, un message d’acquittement est inconditionnellement envoyé à la fin de la dernière fenêtre pour confirmer l'état de statut de réception du paquet de transport 50. Dans l’exemple considéré et illustré à la , les fragments 52 du paquet de transport 50 sont groupés dans trois fenêtres. Chaque fenêtre sauf la dernière comporte six fragments 52. La dernière fenêtre ne comporte que deux fragments 52. Les fenêtres sont identifiées par un numéro de fenêtre encodé par un champ W de taille M bits (M = 2 dans l’exemple considéré). Les numéros de fenêtres sont ordonnés par ordre croissant en partant de zéro. Au sein de chaque fenêtre, les fragments 52 sont identifiés par un numéro de fragment encodé par un champ FCN de taille N bits (N = 3 dans l’exemple considéré). Au sein d’une fenêtre qui n’est pas la dernière, les numéros de fragment sont ordonnés par ordre décroissant jusqu’à zéro. Le dernier fragment de la dernière fenêtre porte un numéro de fragment FCN égal à (2 N – 1). Autrement dit, pour le dernier fragment de la dernière fenêtre, tous les bits du champ FCN prennent la valeur ‘1’. Cela permet d’indiquer qu’il s’agit du dernier fragment du paquet de transport. Chaque fragment 52 du paquet de transport 50 est donc identifié et ordonné selon une combinaison unique d’un numéro de fenêtre W et d’un numéro de fragment FCN. Le premier fragment 52 du paquet de transport 50 est identifié par la combinaison (W = 0, FCN = 5), le deuxième fragment 52 du paquet de transport 50 est identifié par la combinaison (W = 0, FCN = 4), …, le sixième fragment 52 du paquet de transport 50 est identifié par la combinaison (W = 0, FCN = 0), le septième fragment 52 du paquet de transport 50 est identifié par la combinaison (W = 1, FCN = 5), …, le treizième fragment 52 du paquet de transport 50 est identifié par la combinaison (W = 2, FCN = 5), le quatorzième et dernier fragment 52 du paquet de transport 50 est identifié par la combinaison (W = 2, FCN = 7). Dans l’exemple considéré et illustré à la , le premier paquet applicatif 51 du paquet de transport 50 est composé par les deux fragments (W = 0, FCN = 5) et (W = 0, FCN = 4), le deuxième paquet applicatif 51 du paquet de transport 50 est composé par les deux fragments (W = 0, FCN = 3) et (W = 0, FCN = 2), …, le septième et dernier paquet applicatif 51 du paquet de transport 50 est composé par les deux fragments (W = 2, FCN = 5) et (W = 2, FCN = 7). La représente le format d’un fragment 52 selon le protocole SCHC. Le fragment 52 comporte un en-tête de fragment SCHC, des données utiles du fragment, et éventuellement des bits de bourrage. L’en-tête de fragment SCHC comporte notamment les champs W et FCN encodant respectivement le numéro de fenêtre et le numéro de fragment au sein de la fenêtre. La taille du champ W est de M bits. La taille du champ FCN est de N bits. En outre, l’en-tête de fragment SCHC comporte un champ RuleID représentant un identifiant d’une règle utilisée pour la fragmentation du paquet de transport 50. Une règle est notamment associée à un mode de fragmentation (No-ACK, ACK-Always ou ACK-on-Error) et à une taille de fenêtre (c’est-à-dire un nombre de fragments par fenêtre). Plusieurs règles peuvent être prédéterminées et partagées entre le dispositif émetteur 20 et le dispositif récepteur 40. Le champ RuleID permet d’identifier quelle règle s’applique pour le fragment 52 considéré. Une même règle s’applique pour tous les fragments 52 d’un paquet de transport 50. La règle peut également spécifier la manière dont un paquet applicatif 51 est fragmenté (la règle peut définir l'organisation des données au sein des fragments composant un paquet applicatif). L’ensemble des paramètres définis pour une règle donnée correspond à un contexte statique partagé entre le dispositif émetteur 20 et le dispositif récepteur 40. Le champ DTag peut être utilisé pour identifier des fragments 52 correspondant à des paquets de transport 50 différents, par exemple si une même règle est utilisée pour la transmission d’au moins deux paquets de transport différents et si la transmission du deuxième paquet de transport commence avant que la transmission du premier paquet de transport ne soit complètement terminée. Les données utiles d’un fragment 52 correspondent à une partie au moins des données utiles d’un paquet applicatif 51. Le fragment 52 peut également comporter des bits de bourrage pour que la taille du fragment 52 soit alignée sur un nombre entier d’octets. La illustre un exemple de transmission du paquet de transport 50 représenté à la depuis le dispositif émetteur 20 vers le dispositif récepteur 40 selon le protocole SCHC. Tel qu’illustré sur la , les six premiers fragments 52 du paquet de transport 50 sont transmis successivement dans la première fenêtre (W = 0). Ensuite, les six fragments 52 suivants sont transmis successivement dans la deuxième fenêtre (W = 1). Enfin, les deux derniers fragments 52 du paquet de transport 50 sont transmis dans la troisième et dernière fenêtre (W = 2). Le dernier fragment 52 du paquet de transport 50 est identifié par le fait que tous les bits du champ FCN de ce fragment 52 sont à ‘1’ (FCN = 7). En réponse à la réception du dernier fragment 52 du paquet de transport 50, le dispositif récepteur 40 émet un message d’acquittement ACK indiquant que tous les fragments 52 du paquet de transport 50 ont été reçus. Le message d’acquittement indique le numéro de fenêtre W qui a déclenché l’envoi du message d’acquittement ainsi qu’un champ C dont la valeur à ‘1’ indique que tous les fragments 52 du paquet de transport 50 ont été reçus (une valeur à ‘0’ du champ C indique qu’au moins un fragment 52 est manquant). Dans l’exemple illustré à la , le mode ACK-on-Error est utilisé, et aucun fragment 52 n’a été perdu. Ainsi, dans cet exemple, un seul message d’acquittement est émis en réponse à la réception du dernier fragment 52 du paquet de transport 50. Si le mode ACK-Always avait été utilisé, alors un message d’acquittement supplémentaire aurait été émis par le dispositif récepteur 40 à destination du dispositif émetteur 20 à la fin de chaque fenêtre. Ainsi, un message d’acquittement aurait été émis en réponse à la réception du fragment (W = 0, FCN = 0) et un autre message d’acquittement aurait été émis en réponse à la réception du fragment (W = 1, FCN = 0). Chacun de ces messages d’acquittement aurait indiqué que tous les fragments 52 du paquet de transport 50 ont été reçus respectivement pour la première fenêtre (W = 0) et pour la dernière fenêtre (W = 1). Si le mode No-ACK avait été utilisé, alors il n’y aurait eu aucun message d’acquittement. Tel qu’illustré sur la , lorsque tous les fragments 52 du paquet de transport 50 sont reçus, le paquet de transport 50 est réassemblé par la couche d’adaptation 42 et transmis à la couche applicative 43. La illustre un autre exemple de transmission du paquet de transport 50 représenté à la depuis le dispositif émetteur 20 vers le dispositif récepteur 40 selon le protocole SCHC. Dans cet exemple, le mode ACK-on-Error est utilisé, et plusieurs fragment 52 sont perdus lors de leur première transmission. C’est le cas notamment pour le quatrième (FCN = 2) et le cinquième (FCN = 1) fragments 52 de la première fenêtre (W = 0). C’est le cas également pour le premier (FCN = 5) fragment 52 de la troisième et dernière fenêtre (W = 2). En revanche aucun fragment 52 n’est perdu pour la deuxième fenêtre (W = 1). Un premier message d’acquittement est émis par le dispositif récepteur 40 à destination du dispositif émetteur 20 en réponse à la réception du dernier fragment (FCN = 0) de la première fenêtre (W = 0) pour indiquer que certains fragments de la première fenêtre (W = 0) sont manquants. Le message d’acquittement indique le numéro de fenêtre (W = 0) à laquelle il se rapporte. Le message d’acquittement comporte également un champ C dont la valeur à ‘0’ indique qu’au moins un fragment 52 n’a pas été reçu pour cette fenêtre. Enfin, un champ de bit (« Bitmap ») indique quels sont les fragments 52 manquants pour cette fenêtre. Chaque bit du bitmap correspond à un fragment 52 de la fenêtre considérée. Une valeur du bit à ‘0’ indique que le fragment est manquant (il n’a pas été reçu). Une valeur du bit à ‘1’ indique que le fragment a été correctement reçu. Dans l’exemple considéré, le quatrième bit et le cinquième bit du bitmap sont mis à zéro pour indiquer que le quatrième fragment et le cinquième fragment de la première fenêtre sont manquants. En réponse au premier message d’acquittement, et avant de transmettre les fragments 52 de la deuxième fenêtre (W = 1), le dispositif émetteur 20 retransmet les fragments manquants (W = 0, FCN = 2) et (W = 0, FCN = 1). Dans l’exemple considéré, ces fragments retransmis sont correctement reçus. Un deuxième message d’acquittement est émis par le dispositif récepteur 40 à destination du dispositif émetteur 20 en réponse à la réception du dernier fragment (FCN = 7) de la dernière fenêtre (W = 2) pour indiquer qu’au moins un fragment de la dernière fenêtre (W = 2) est manquant. Le message d’acquittement indique le numéro de fenêtre (W = 2) à laquelle il se rapporte. Le message d’acquittement comporte également un champ C dont la valeur à ‘0’ indique qu’au moins un fragment 52 n’a pas été reçu. Enfin, le champ Bitmap indique quels sont les fragments 52 manquants pour cette fenêtre. Le premier bit du Bitmap est mis à ‘0’ pour indiquer que le premier fragment (FCN = 5) de cette fenêtre n’a pas été reçu. Le dernier bit du Bitmap est mis à ‘1’ pour indiquer que le dernier fragment de cette fenêtre a été reçu. Les valeurs des autres bits du Bitmap n’ont pas d’importance dans l’exemple considéré. En réponse au deuxième message d’acquittement, le dispositif émetteur 20 retransmet le fragment manquant (W = 2, FCN = 5). Dans l’exemple considéré, ce fragment retransmis est correctement reçu. Lorsqu'il y a retransmission d'un fragment de la dernière fenêtre, le dernier fragment, pour lequel tous les bits du champ FCN mis à la valeur ‘1’ (FCN=7), est également répété suite à la retransmission du ou des fragments manquants. C'est la répétition de ce dernier fragment (FCN = 7) qui déclenche l'émission d’un dernier message d’acquittement indiquant que tous les fragments ont été reçus. Tel qu’illustré sur la , lorsque tous les fragments 52 du paquet de transport 50 sont reçus, le paquet de transport 50 est réassemblé par la couche d’adaptation 42 et transmis à la couche applicative 43. On peut noter que comme il n’y a pas eu de perte de fragment 52 dans la deuxième fenêtre (W = 1), et comme le mode ACK-on-Error est utilisé, aucun message d’acquittement n’est émis en réponse à la réception du dernier fragment de cette fenêtre. Si le mode ACK-Always avait été utilisé, un message d’acquittement indiquant que tous les fragments de la fenêtre ont été reçus (C = 1) aurait été émis en réponse à la réception du dernier fragment de la fenêtre (W = 1). Si le mode No-ACK avait été utilisé, alors il n’y aurait eu aucun message d’acquittement. Aussi, comme certains fragments 52 du paquet de transport 50 n’ont pas été reçus, aucun fragment du paquet de transport 50 n’aurait été transmis à la couche applicative 43. Il est à noter que le protocole SCHC définit le comportement à suivre au niveau de la couche d’adaptation 22 du dispositif émetteur 20 et/ou au niveau de la couche d’adaptation 42 du dispositif récepteur 40 dans différents scénarios particuliers, comme par exemple si le dernier fragment (FCN = 0) d’une fenêtre n’est pas reçu après un certain temps, si le dernier fragment (FCN = 7) de la dernière fenêtre n’est pas reçu, si des fragments sont reçus dans ordre inattendu, etc. Dans les exemples illustrés aux figures 4 et 5, les paquets applicatifs 51 contenus dans le paquet de transport 50 ne sont transmis à la couche applicative 43 qu’une fois que tous les fragments 52 du paquet de transport 50 ont été reçus au niveau de la couche d’adaptation 42 du dispositif récepteur 40. Or, comme on l’a vu précédemment, un paquet applicatif 51 contenu dans le paquet de transport 50 peut potentiellement être traité par la couche applicative 43 du dispositif récepteur 40 même si les autres paquets applicatifs 51 du paquet de transport 50 n’ont pas tous été reçus. Aussi, dans certains cas, un paquet applicatif 51 peut être traité par la couche applicative 43 du dispositif récepteur 40 même si seulement certains des fragments 52 composant le paquet applicatif 51 ont été reçus par le dispositif récepteur 40. C’est pourquoi le processeur du dispositif récepteur 40 est configuré, au niveau de la couche d’adaptation 42, pour transmettre dans certaines conditions un paquet applicatif 51, ou une partie au moins d’un paquet applicatif 51 (c’est-à-dire au moins un fragment 52 du paquet applicatif 51), même si tous les fragments 52 du paquet de transport 50 n’ont pas encore été reçus. Plus particulièrement, le processeur du dispositif récepteur 40 est configuré, au niveau de la couche d’adaptation 42, pour chaque nouveau fragment 52 reçu d’un paquet applicatif 51, pour vérifier si un critère de transmission est satisfait pour ledit paquet applicatif 51 et, si le critère de transmission est satisfait, pour transmettre vers la couche applicative 43 au moins un fragment 52 déjà reçu pour ledit paquet applicatif 51, et ce même si tous les fragments 52 du paquet de transport 50 n’ont pas encore été reçus. Le critère de transmission peut être vérifié en fonction des fragments 52 déjà reçus pour ledit paquet applicatif 51. Selon un premier exemple, le critère de transmission peut être vérifié dès lors que tous les fragments 52 dudit paquet applicatif 51 ont été reçus par la couche d’adaptation 42 du dispositif récepteur 40. Selon un deuxième exemple, le critère de transmission peut être vérifié si le nombre de fragments 52 reçus pour ledit paquet applicatif 51 est supérieur ou égal à un nombre prédéterminé et si une différence entre un instant de réception d’un premier fragment 52 pour ledit paquet applicatif 51 et un instant courant est supérieure ou égale à une durée prédéterminée. Selon un troisième exemple, le critère de transmission peut être vérifié si au moins un sous-ensemble prédéterminé des fragments 52 dudit paquet applicatif 51 ont été reçus et si une différence entre un instant de réception d’un premier fragment 52 pour ledit paquet applicatif 51 et un instant courant est supérieure ou égale à une durée prédéterminée. Le critère de transmission peut également correspondre à une combinaison des critères précédemment cités en exemple. Par exemple, le critère de transmission peut être vérifié si la condition prévue par le premier exemple est satisfaite, ou si la condition prévue par le deuxième exemple est satisfaite, ou si la condition prévue par le troisième exemple est satisfaite. Selon un autre exemple, le critère de transmission peut être vérifié si à la fois la condition prévue par le deuxième exemple et la condition prévue par le troisième exemple sont satisfaites. Alternativement ou en complément, le critère de transmission peut être vérifié en fonction des autres paquets applicatifs 51 déjà reçus pour le paquet de transport 50. Par exemple, le critère de transmission n’est vérifié pour un paquet applicatif 51 du paquet de transport 50 que si au moins le premier paquet applicatif 51 dudit paquet de transport 50 a déjà été transmis à la couche applicative 43. Les conditions satisfaisant le critère de transmission peuvent être définie pour une règle donnée et donc être associées avec un identifiant de cette règle (RuleID). Les figures 4 et 5 illustrent des exemples de transmission du paquet de transport qui sont conformes au protocole SCHC. La illustre un exemple de transmission du paquet de transport 50 représenté à la depuis le dispositif émetteur 20 vers le dispositif récepteur 40 selon un procédé de communication selon l’invention. Le procédé de communication selon l’invention propose des améliorations au protocole SCHC afin de permettre un traitement au plus tôt d’un paquet applicatif 51 contenu dans le paquet de transport 50 par la couche applicative 43 du dispositif récepteur 40. En effet, dans le procédé selon l’invention, un paquet applicatif 51 contenu dans le paquet de transport 50 peut, dans certaines conditions, être traité par la couche applicative 43 du dispositif récepteur 40 même si les autres paquets applicatifs 51 du paquet de transport 50 n’ont pas tous été reçus. Dans cet exemple, similairement à l’exemple illustré à la , le mode ACK-on-Error est utilisé et plusieurs fragment 52 sont perdus lors de leur première transmission. C’est le cas notamment pour le quatrième (FCN = 2) et le cinquième (FCN = 1) fragments 52 de la première fenêtre (W = 0). C’est le cas également pour le premier (FCN = 5) fragment 52 de la troisième et dernière fenêtre (W = 2). En revanche aucun fragment 52 n’est perdu pour la deuxième fenêtre (W = 1). Dans l’exemple considéré et illustré à la , le critère de transmission est satisfait pour un paquet applicatif 51 dès lors que tous les fragments 52 dudit paquet applicatif 51 ont été reçus par la couche d’adaptation 42 du dispositif récepteur 40. Le critère de transmission est également satisfait si au moins le premier fragment 52 dudit paquet applicatif 51 a été reçu et si une différence entre un instant de réception dudit premier fragment 52 pour ledit paquet applicatif 51 et un instant courant est supérieure ou égale à une durée T C prédéterminée. Les fragments 52 disponibles au niveau de la couche d’adaptation 42 lorsque le critère de transmission est satisfait sont alors transmis à la couche applicative 43. Ainsi, les deux fragments (W = 0, FCN = 5) et (W = 0, FCN = 4) composant le premier paquet applicatif 51 sont transmis par la couche d’adaptation 42 à la couche applicative 43 dès que ces deux fragments 52 ont été reçus par la couche d’adaptation 42. Le premier fragment (W = 0, FCN = 3) du deuxième paquet applicatif 51 est correctement reçu par la couche d’adaptation 42. En revanche, le deuxième fragment (W = 0, FCN = 2) du deuxième paquet applicatif 51 est perdu. Le premier fragment (W = 0, FCN = 3) du deuxième paquet applicatif 51 est alors transmis à la couche applicative 43 dès que le temps écoulé depuis l’instant de réception du premier fragment (W = 0, FCN = 3) du deuxième paquet applicatif 51 est supérieur ou égal à T C . Le premier fragment (W = 0, FCN = 1) du troisième paquet applicatif 51 est perdu. Le deuxième fragment (W = 0, FCN = 0) du troisième paquet applicatif 51 est quant à lui correctement reçu. Le critère de transmission du troisième paquet applicatif 51 n’est pas satisfait. Un premier message d’acquittement est émis par le dispositif récepteur 40 à destination du dispositif émetteur 20 en réponse à la réception du dernier fragment (FCN = 0) de la première fenêtre (W = 0) pour indiquer que certains fragments de la première fenêtre (W = 0) sont manquants. Le message d’acquittement indique le numéro de fenêtre (W = 0) à laquelle il se rapporte. Le message d’acquittement comporte également un champ C dont la valeur à ‘0’ indique qu’au moins un fragment 52 n’a pas été reçu pour cette fenêtre. Le message d’acquittement comporte également un champ de bit (« Bitmap ») indiquant quels sont les fragments 52 manquants pour cette fenêtre. Le quatrième bit et le cinquième bit du bitmap sont mis à zéro pour indiquer que le quatrième fragment et le cinquième fragment de la première fenêtre sont manquants. En réponse au premier message d’acquittement, et avant de transmettre les fragments 52 de la deuxième fenêtre (W = 1), le dispositif émetteur 20 retransmet les fragments manquants (W = 0, FCN = 2) et (W = 0, FCN = 1). Dans l’exemple considéré, ces fragments retransmis sont correctement reçus. Le fragment (W = 0, FCN = 2) correspondant au deuxième fragment du deuxième paquet applicatif 51 du paquet de transport 50 peut être transmis à la couche applicative 43. Aussi, à la réception du fragment (W = 0, FCN = 1) correspondant au premier fragment du troisième paquet applicatif 51 du paquet de transport 50, le critère de transmission est satisfait et les deux fragments (W = 0, FCN = 1) et (W = 0, FCN = 0) composant le troisième paquet applicatif 51 du paquet de transport 50 sont transmis à la couche applicative 43. On peut noter qu’à la réception du fragment (W = 0, FCN = 2) correspondant au deuxième fragment du deuxième paquet applicatif 51, il serait envisageable de transmettre à la couche applicative 43 l’ensemble des deux fragments (W = 0, FCN = 2) et (W = 0, FCN = 3) formant le deuxième paquet applicatif 51. De cette façon, une information partielle est livrée au plus tôt (contenu applicatif transporté par le fragment (W = 0, FCN=3)) et une information complète (contenu applicatif transporté par les deux fragments (W = 0, FCN = 2) et (W = 0, FCN = 3)) est livrée ultérieurement dès que possible. Il n’y a pas eu de perte de fragment 52 dans la deuxième fenêtre (W = 1). Les deux fragments (W = 1, FCN = 5) et (W = 1, FCN = 4) composant le quatrième paquet applicatif 51 du paquet de transport 50 sont transmis par la couche d’adaptation 42 à la couche applicative 43 dès que ces deux fragments 52 ont été reçus par la couche d’adaptation 42. Il en va de même pour les deux fragments (W = 1, FCN = 3) et (W = 1, FCN = 2) composant le cinquième paquet applicatif 51 du paquet de transport 50 et pour les deux fragments (W = 1, FCN = 1) et (W = 1, FCN = 0) composant le sixième paquet applicatif 51 du paquet de transport 50. On peut noter que comme il n’y a pas eu de perte de fragment 52 dans la deuxième fenêtre (W = 1), et comme le mode ACK-on-Error est utilisé, aucun message d’acquittement n’est émis en réponse à la réception du dernier fragment de cette fenêtre. Si le mode ACK-Always avait été utilisé, un message d’acquittement indiquant que tous les fragments de la fenêtre ont été reçus (C = 1) aurait été émis en réponse à la réception du dernier fragment (FCN = 0) de la deuxième fenêtre (W = 1). Le premier fragment (W = 2, FCN = 5) du septième paquet applicatif 51 du paquet de transport 50 est perdu. Le deuxième fragment (W = 2, FCN = 7) du septième paquet applicatif 51 est quant à lui correctement reçu. Le critère de transmission du septième paquet applicatif 51 n’est pas satisfait. Un deuxième message d’acquittement est émis par le dispositif récepteur 40 à destination du dispositif émetteur 20 en réponse à la réception du dernier fragment de la dernière fenêtre (W = 2, FCN = 7) pour indiquer qu’au moins un fragment de la dernière fenêtre (W = 2) est manquant. Le message d’acquittement indique le numéro de fenêtre (W = 2) à laquelle il se rapporte. Le message d’acquittement comporte également un champ C dont la valeur à ‘0’ indique qu’au moins un fragment 52 n’a pas été reçu. Enfin, le champ Bitmap indique quels sont les fragments 52 manquants pour cette fenêtre. Le premier bit du Bitmap est mis à ‘0’ pour indiquer que le premier fragment (FCN = 5) de cette fenêtre n’a pas été reçu. Le dernier bit du Bitmap est mis à ‘1’ pour indiquer que le dernier fragment de cette fenêtre a été reçu. Les valeurs des autres bits du Bitmap n’ont pas d’importance dans l’exemple considéré. En réponse au deuxième message d’acquittement, le dispositif émetteur 20 retransmet le fragment manquant (W = 2, FCN = 5), suivi de la répétition du dernier fragment (W = 2, FCN = 7). Dans l’exemple considéré, ces fragments retransmis sont correctement reçu. A la réception du fragment (W = 2, FCN = 5) correspondant au premier fragment du septième paquet applicatif 51 du paquet de transport 50, le critère de transmission est satisfait et les deux fragments (W = 2, FCN = 5) et (W = 2, FCN = 7) composant le septième paquet applicatif 51 du paquet de transport 50 sont transmis à la couche applicative 43. On peut noter que si le mode No-ACK avait été utilisé, alors il n’y aurait eu aucun message d’acquittement. Dans ce cas, le troisième paquet applicatif 51 et le septième paquet applicatif 51 du paquet de transport 50 n’auraient pas été transmis à la couche applicative 43. Les autres paquets applicatifs 51 du paquet de transport 50 auraient en revanche été au moins partiellement transmis à la couche applicative 43. Le fait de regrouper plusieurs paquets applicatifs 51 dans un même paquet de transport 50 (c’est-à-dire dans une même session de transport) plutôt que d’associer chaque paquet applicatif 51 à un paquet de transport 50 (ou à une session de transport), comme cela est préconisé dans la version actuelle du protocole SCHC, permet de réduire la surcharge protocolaire par paquet applicatif 51. En effet, dans le procédé selon l’invention, il n’est plus nécessaire d’émettre un message d’acquittement pour chaque paquet applicatif 51. Un seul message d’acquittement pour l’ensemble des paquets applicatifs 51 formant le paquet de transport 50 peut être suffisant lorsque le mode ACK-on-Error est utilisé et qu’il n’y a pas de pertes de fragments 52. Même si certains fragments 52 sont perdus, le nombre de messages d’acquittement nécessaire est généralement moindre que si chaque paquet applicatif 51 était associé à un paquet de transport 50. En outre, un paquet applicatif 51 peut être transmis à la couche applicative 43 du dispositif récepteur 40 même si les autres paquets applicatifs 51 du paquet de transport 50 n’ont pas tous été reçus. Cela permet un traitement au plus tôt d’un paquet applicatif 51 contenu dans le paquet de transport 50 par la couche applicative 43 du dispositif récepteur 40. Ainsi, dans certaines conditions, les paquets applicatifs 51 peuvent être transmis à la couche applicative 43 du dispositif récepteur 40 au fur et à mesure de leur réception par la couche d’adaptation 42 du dispositif récepteur 40 (c’est-à-dire en « streaming »). Dans des modes particuliers de réalisation, il est possible de réassembler une partie ou l’ensemble des fragments 52 appartenant à un même paquet applicatif 51 avant de le transmettre à la couche applicative 43 du dispositif récepteur 40. Le résultat issu du réassemblage des fragments 52 peut alors suivre un format particulier. Cela peut être avantageux par exemple pour avoir une seule interface applicative associée à différentes règles (RuleIDs) correspondant à une même application fonctionnelle. La représente schématiquement les principales étapes du procédé 100 de communication selon l’invention présenté ci-avant. Le procédé 100 comporte les étapes suivantes qui sont mises en œuvre par un processeur du dispositif émetteur 20 au niveau de sa couche d’adaptation 22 : une formation 101 d’un paquet de transport 50 comportant plusieurs paquets applicatifs 51 formés à partir de données en provenance de la couche applicative 23, une fragmentation 102 du paquet de transport en plusieurs fragments 52 ordonnées, chaque paquet applicatif 51 correspondant à un ou plusieurs fragments 52, une transmission 103 desdits fragments 52 vers la couche de liaison 21 du dispositif émetteur 21. Le procédé 100 comporte également les étapes suivantes qui sont mises en œuvre par un processeur du dispositif récepteur 40 au niveau de sa couche d’adaptation 42 : une réception 104, en provenance de la couche de liaison 41 du dispositif récepteur 40, de fragments 52 du paquet de transport 50, pour chaque nouveau fragment 52 reçu d’un paquet applicatif 51 : une vérification 105 si un critère de transmission est satisfait pour ledit paquet applicatif 51 en fonction des fragments 52 déjà reçus pour ledit paquet applicatif 51, si le critère de transmission est satisfait, une transmission 106 vers la couche applicative 43 du dispositif récepteur 40 d’au moins un fragment 52 déjà reçu pour ledit paquet applicatif 51, même si tous les fragments 52 du paquet de transport 50 n’ont pas encore été reçus. Ainsi, dans certaines conditions, les paquets applicatifs 51 peuvent être transmis à la couche applicative 43 du dispositif récepteur 40 au fur et à mesure de leur réception par la couche d’adaptation 42 du dispositif récepteur 40. On peut alors parler de « streaming » au niveau de la couche d’adaptation 42 du dispositif récepteur 40. Comme cela a été expliqué précédemment, les étapes de formation 101 du paquet de transport 50, de fragmentation 102 du paquet de transport 50 et de transmission 103 des fragments 52 ne sont pas nécessairement mises en œuvre de façon séquentielle. Ainsi, dans des modes particuliers de mise en œuvre, ces étapes sont exécutées de façon simultanée, de telle sorte qu’un fragment 52 du paquet applicatif 51 peut être formé et transmis avant que toutes les données formant le paquet de transport 50 n’aient été reçues. Dans un tel mode de mise en œuvre, les paquets applicatifs 51 sont fragmentés et transmis par la couche d’adaptation 22 du dispositif émetteur 20 dans la session de transport au fur et à mesure de leur réception. On peut alors parler de « streaming » au niveau de la couche d’adaptation 22 du dispositif émetteur 20. A titre d’exemple nullement limitatif, les données à transmettre par le dispositif émetteur 20 correspondent à des identifiants de points d’accès Wi-Fi. Un identifiant de point d’accès correspond par exemple à un identifiant BSSID (acronyme anglais de « Basic Service Set Identification », en français « identification d’un ensemble de services de base ») ou à une adresse MAC (acronyme anglais de « Media Access Control », en français « contrôle d’accès au média »). Un tel identifiant est généralement codé sur six octets (quarante-huit bits). Un ou plusieurs identifiants de points d’accès détectés à instant donné par le dispositif émetteur 20 sont par exemple transmis au dispositif récepteur 40 dans le but de géolocaliser le dispositif émetteur 20. Le dispositif récepteur 40 peut en effet être un serveur de géolocalisation ayant accès à une base de données associant chaque identifiant de point d’accès à une position géographique connue. Il peut alors être possible pour le dispositif récepteur 40 d’estimer une position géographique du dispositif émetteur 20 à partir des positions géographiques des points d’accès détectés par le dispositif émetteur 20. Dans l’exemple considéré, les identifiants de points d’accès détectés sont ordonnés selon un niveau de qualité de lien radio avec lequel le point d’accès est détecté par le dispositif émetteur 20. Plus le niveau de qualité de lien radio avec lequel le point d’accès est détecté par le dispositif émetteur 20 est grand, et plus ledit point d’accès est pertinent pour la géolocalisation du dispositif émetteur 20. Ainsi, le premier et le deuxième identifiants de point d’accès sont généralement plus pertinents pour géolocaliser le dispositif émetteur 20 que le troisième point d’accès. Selon un premier exemple, la couche applicative 23 du dispositif émetteur 20 est configurée pour détecter jusqu’à trois identifiants de point d’accès à un instant donné, et pour fournir les identifiants détectés à la couche d’adaptation 22 du dispositif émetteur 20. Un paquet de transport 50 comportant jusqu’à dix-huit octets de données peut alors être formé par la couche d’adaptation 22 pour encapsuler le ou les identifiants détectés. La couche d’adaptation 22 est configuré pour découper les données en autant de paquet applicatifs 51 que le nombre d’identifiants de points d’accès contenus dans le paquet de transport 50. Ainsi, chaque paquet applicatif 51 comporte un identifiant de point d’accès codé sur six octets. Un paquet applicatif 51 correspond à un fragment 52. Le paquet de transport 50 est transmis dans une session de transport comportant une seule fenêtre pouvant comporter jusqu’à trois fragments 52. Dans ce cas le champ W est codé sur un seul bit (M = 1) et le champ FCN est codé sur deux bits (N = 2). Dans ce premier exemple, il n’y a pas de « streaming » au niveau de la couche d’adaptation 22 du dispositif émetteur 20 car tous les identifiants de points d’accès devant être transmis dans un paquet de transport 50 sont reçus en une seule fois par la couche d’adaptation 22 du dispositif émetteur 20. Dans ce premier exemple, au niveau de la couche d’adaptation 42 du dispositif récepteur 40, lorsqu’un nouveau fragment 52 correspondant à un paquet applicatif 51 du paquet de transport 50 est reçu, le critère de transmission est vérifié dans chacun des cas suivants : si tous les paquets applicatifs 51 formant le paquet de transport 50 ont été reçus et n’ont pas encore été transmis à la couche applicative 43, alors ils sont transmis ; si au moins le premier ou le deuxième paquet applicatif 51 a été reçu après un temps T C depuis la réception du premier fragment 52 reçu, alors les paquets applicatifs qui ont été reçus sont transmis à la couche applicative 43. En revanche, si seul le troisième paquet applicatif 51 est reçu, le critère de transmission n’est pas satisfait et le paquet applicatif 51 n’est pas transmis à la couche applicative 43. Ainsi, dans ce premier exemple, Il peut y avoir du « streaming » au niveau de la couche d’adaptation 42 du dispositif récepteur 40 dans la mesure où dans certaines conditions un paquet applicatif 51 peut être transmis par la couche d’adaptation 42 à la couche applicative 43 avant que tous les paquets applicatifs 51 du paquet de transport 50 n’aient été reçus. De telles dispositions permettent, lorsque certains fragments 52 sont perdus, de transmettre au plus vite à la couche applicative 43 une partie au moins des identifiants de point d’accès qui ont déjà été reçus. Cela peut permettre une première estimation rapide de la position géographique du dispositif émetteur 20 sur la base des identifiants déjà disponibles. Même si cette estimation est moins précise que si elle avait été faite sur la base de tous les identifiants, elle peut néanmoins rester pertinente. On peut d’ailleurs noter que le critère de transmission est défini de telle sorte que l’estimation est basée au moins sur le premier ou le deuxième identifiant, et ces identifiants présentent une pertinence relativement grande. Lorsque les fragments 52 perdus sont retransmis puis reçus par la couche d’adaptation 42, ils peuvent être transmis à la couche applicative 43 pour permettre une deuxième estimation plus précise de la position du dispositif émetteur 20 (plus le nombre d’identifiants utilisés est grand et plus la précision de l’estimation de la position est élevée). Selon un deuxième exemple, il peut y avoir du « streaming » à la fois au niveau de la couche d’adaptation 22 du dispositif émetteur 20 et au niveau de la couche d’adaptation 43 du dispositif récepteur 40. Dans ce deuxième exemple, la couche applicative 23 du dispositif émetteur 20 est configurée pour détecter trois identifiants de point d’accès, et pour fournir les identifiants détectés à la couche d’adaptation 22 du dispositif émetteur 20. Cette opération se répète de façon récurrente. Un paquet de transport 50 correspond à une session de transport comportant trois fenêtres comportant chacune six fragments 52. Dans ce cas le champ W est codé sur un deux bits (M = 2) et le champ FCN est codé sur trois bits (N = 3). La couche d’adaptation 22 est configurée pour former un paquet applicatif 51 à partir de trois identifiants de points d’accès fournis par la couche applicative 23. Chaque paquet applicatif 51 est fragmenté en deux fragments 52. Le premier fragment 52 d’un paquet applicatif 51 comporte neuf octets correspondant aux six octets du premier identifiant de point d’accès et aux trois premiers octets du deuxième identifiant de point d’accès. Le deuxième fragment 52 d’un paquet applicatif 51 comporte neuf octets correspondant aux trois derniers octets du deuxième identifiant de point d’accès et aux six octets du troisième identifiant de point d’accès. Ainsi, un paquet de transport 50 comporte neuf paquets applicatifs et permet de transmettre neuf triplets d’identifiants de points d’accès détectés respectivement à neuf instants différents. Un paquet applicatif 51 peut toutefois être transmis sous la forme de deux fragments 52 dans la session de transport avant que toutes les données formant le paquet de transport 50 n’aient été reçues par la couche d’adaptation 22 du dispositif émetteur 20. Dans ce deuxième exemple, au niveau de la couche d’adaptation 42 du dispositif récepteur 40, lorsqu’un nouveau fragment 52 correspondant à un paquet applicatif 51 du paquet de transport 50 est reçu, le critère de transmission est vérifié dans chacun des cas suivants : si les deux fragments 52 du paquet applicatif 51 ont été reçus et n’ont pas encore été transmis à la couche applicative 43, alors ils sont transmis ; si seul le premier fragment 52 du paquet applicatif 51 a été reçu après un temps T C depuis la réception dudit premier fragment 52, alors le premier fragment 52 est transmis à la couche applicative 43. En revanche, si seul le deuxième fragment 52 du paquet applicatif 51 est reçu, le critère de transmission n’est pas satisfait et ledit deuxième fragment 52 n’est pas transmis à la couche applicative 43. De telles dispositions permettent, lorsque seul le deuxième fragment 52 d’un paquet applicatif 51 est perdu, de transmettre au plus vite à la couche applicative 43 le premier identifiant de point d’accès contenu dans le premier fragment 52 dudit paquet applicatif 51. Cela peut permettre une première estimation rapide de la position géographique du dispositif émetteur 20 sur la base du premier identifiant. Même si cette estimation est moins précise que si elle avait été faite sur la base de l’ensemble des trois identifiants, elle peut néanmoins rester pertinente. On peut d’ailleurs noter que le critère de transmission est défini de telle sorte que l’estimation est basée au moins sur le premier identifiant, et cet identifiant est celui présentant la plus grande pertinence parmi les trois identifiants du triplet. Si le fragment 52 du paquet applicatif est retransmis ultérieurement puis reçu par la couche d’adaptation 42, il peut être transmis à la couche applicative 43 pour permettre une deuxième estimation plus précise de la position du dispositif émetteur 20 sur la base de l’ensemble des trois identifiants du triplet. Il peut être intéressant pour le dispositif récepteur 40 de savoir à quel instant un fragment 52 a été transmis par le dispositif émetteur 20 (par exemple pour savoir à quel instant un paquet applicatif 51 comportant ledit fragment 52 a été transmis par le dispositif émetteur 20). Lorsqu’un fragment 52 est reçu par le dispositif récepteur 40 lors de sa première transmission par le dispositif émetteur 20, alors l’instant auquel le fragment 52 est reçu par le dispositif récepteur 40 correspond sensiblement à l’instant auquel le fragment 52 a été transmis par le dispositif émetteur 20. En revanche, lorsqu’un fragment 52 est perdu et qu’il doit être retransmis par le dispositif émetteur 20, alors le dispositif récepteur 40 n’a plus moyen de savoir à quel instant ledit fragment avait été initialement transmis pour la première fois par le dispositif émetteur 20. Pour résoudre ce problème, il est envisageable d’inclure, dans chaque fragment 52, une indication sur l’instant auquel ledit fragment a été transmis pour la première fois par le dispositif émetteur 20. Une telle solution conduit toutefois à augmenter considérablement la quantité de données à transmettre. Pour résoudre ce problème de façon plus avantageuse, dans un mode particulier de mise en œuvre le procédé 100 de communication selon l’invention comporte, au niveau de la couche d’adaptation 22 du dispositif émetteur 20, pour chaque fragment 52 initialement transmis vers la couche de liaison 21 du dispositif émetteur 21, une mémorisation d’un instant de transmission initiale dudit fragment 52. Pour chaque fragment 52 indiqué comme manquant dans un message d’acquittement, le procédé comporte un calcul d’un délai de retransmission correspondant à une différence entre l’instant de transmission initiale dudit fragment 52 et un instant de retransmission dudit fragment 52. Enfin, le procédé comporte une retransmission dudit fragment 52 en y incluant une information relative audit délai de retransmission. En outre, au niveau de la couche d’adaptation 42 du dispositif récepteur 40, le procédé comporte une étape d’estimation de l’instant de transmission initiale dudit fragment 52 à partir d’un instant de réception dudit fragment 52 et de l’information relative au délai de retransmission incluse dans ledit fragment 52. De telles dispositions permettent au dispositif récepteur 40 de savoir à quel instant un fragment 52 a été transmis par le dispositif émetteur 20 pour la première fois, même si le fragment a dû être retransmis par le dispositif émetteur 20, tout en limitant la quantité de données à transmettre. En effet, l’information relative au délai de retransmission présente une taille plus petite qu’une information indiquant directement l’instant auquel le fragment a été transmis pour la première fois (le délai de retransmission peut être encodé avec un nombre de bits plus petit que la date de transmission initiale du fragment). En outre, l’information relative au délai de retransmission peut n’être transmise que si un fragment 52 a été perdu et doit être retransmis. La description ci-avant illustre clairement que, par ses différentes caractéristiques et leurs avantages, la présente invention atteint les objectifs fixés. En particulier, l’invention propose des améliorations au protocole SCHC pour permettre la communication de paquets applicatifs de façon fiable, efficace et continue. La fiabilité peut notamment être garantie par le mécanisme d’acquittement et de retransmission des fragments. L’efficacité de la communication repose sur le fait que la surcharge protocolaire nécessaire pour transmettre un paquet applicatif est plus faible que celle proposée par la version actuelle du protocole SCHC. La continuité de la communication est relative à la possibilité de faire du « streaming » à l’émission et/ou à la réception des paquets applicatifs. De manière plus générale, il est à noter que les modes de mise en œuvre et de réalisation considérés ci-dessus ont été décrits à titre d’exemples non limitatifs, et que d’autres variantes sont par conséquent envisageables. Notamment, les paramètres utilisés dans les exemples (nombre de fenêtres dans une session de transport, nombre de fragments dans une fenêtre, nombre de paquets applicatifs formant un paquet de transport, nombre de fragments formant un paquet applicatif, les conditions satisfaisant le critère de transmission, etc.) ne sont aucunement limitatifs. Des choix différents pour ces paramètres ne constituent que des variantes de l’invention. L’invention a été décrite en considérant l’utilisation du protocole SCHC dans un système de communication basé sur un réseau d’accès LPWAN. Rien n’exclut cependant, suivant d’autres exemples, d’appliquer l’invention à d’autres protocoles de transport pour d’autres systèmes de communication. Procédé (100) de communication d’un paquet de transport (50) entre un dispositif émetteur (20) et un dispositif récepteur (40) d’un système (10) de communication sans fil, ledit procédé (100) étant implémenté par le dispositif émetteur (20) et par le dispositif récepteur (40) au niveau d’une couche d’adaptation (22, 42) entre une couche de liaison de niveau inférieur (21, 41) et une couche applicative de niveau supérieur (23, 43), ledit procédé (100) comportant : au niveau de la couche d’adaptation (22) du dispositif émetteur (20) : une formation (101) du paquet de transport (50) à partir de données en provenance de la couche applicative (23), une fragmentation (102) du paquet de transport en plusieurs fragments (52) ordonnées, une transmission (103) desdits fragments (52) vers la couche de liaison (21) du dispositif émetteur (21), au niveau de la couche d’adaptation (42) du dispositif récepteur (40) : une réception (104), en provenance de la couche de liaison (41) du dispositif récepteur (40), des fragments (52) du paquet de transport (50), caractérisé en ce que : le paquet de transport (50) comporte plusieurs paquets applicatifs (51), chaque paquet applicatif (51) correspondant à un ou plusieurs fragments (52), et le procédé (100) comporte, au niveau de la couche d’adaptation (42) du dispositif récepteur (40), pour chaque nouveau fragment (52) reçu d’un paquet applicatif (51) : une vérification (105) si un critère de transmission est satisfait pour ledit paquet applicatif (51) en fonction des fragments (52) déjà reçus pour ledit paquet applicatif (51), si le critère de transmission est satisfait, une transmission (106) vers la couche applicative (43) du dispositif récepteur (40) d’au moins un fragment (52) déjà reçu pour ledit paquet applicatif (51), même si tous les fragments (52) du paquet de transport (50) n’ont pas encore été reçus. Procédé (100) selon la revendication 1 comportant au niveau de la couche d’adaptation (42) du dispositif récepteur (40), en réponse à la réception (104) du dernier fragment (52) du paquet de transport (50), une émission d’au moins un message d’acquittement renseignant sur des fragments (52) correctement reçus et des fragments (52) manquants du paquet de transport (50). Procédé (100) selon l’une quelconque des revendications 1 à 2 dans lequel, au niveau de la couche d’adaptation (22) du dispositif émetteur (20), les étapes de formation (101) du paquet de transport, de fragmentation (102) du paquet de transport (50) et de transmission (103) des fragments (52) sont exécutées de façon simultanée, de telle sorte que les paquets applicatifs (51) sont fragmentés et transmis en streaming, c’est-à-dire au fur et à mesure de leur réception par la couche d’adaptation (22) du dispositif récepteur(20) avant que toutes les données formant le paquet de transport (50) n’aient été reçues de la couche applicative (23) du dispositif émetteur (20). Procédé (100) selon l’une quelconque des revendications 1 à 3 dans lequel la couche d’adaptation (22) du dispositif émetteur (20) et la couche d’adaptation (42) du dispositif récepteur (40) sont des couches SCHC. Procédé (100) selon l’une quelconque des revendications 1 à 4 dans lequel le critère de transmission est vérifié si tous les fragments (52) dudit paquet applicatif (51) ont été reçus par la couche d’adaptation (42) du dispositif récepteur (40). Procédé (100) selon l’une quelconque des revendications 1 à 5 dans lequel un paquet applicatif (51) comporte plusieurs fragments (52), et le critère de transmission est vérifié si le nombre de fragments (52) reçus pour ledit paquet applicatif (51) est au moins égal à un nombre prédéterminé et si une différence entre un instant de réception d’un premier fragment (52) pour ledit paquet applicatif (51) et un instant courant est au moins égale à une durée prédéterminée. Procédé (100) selon l’une quelconque des revendications 1 à 6 dans lequel un paquet applicatif (51) comporte plusieurs fragments (52), et le critère de transmission est vérifié si au moins un sous-ensemble prédéterminé des fragments (52) dudit paquet applicatif (51) ont été reçus et si une différence entre un instant de réception d’un premier fragment (52) pour ledit paquet applicatif (51) et un instant courant est au moins égale à une durée prédéterminée. Procédé (100) selon l’une quelconque des revendications 1 à 7 dans lequel la vérification si le critère de transmission est satisfait est effectuée en fonction des autres paquets applicatifs (51) déjà reçus pour le paquet de transport (50). Procédé (100) selon la revendication 2 ou selon l’une quelconque des revendications 3 à 8 en combinaison avec la revendication 2, comportant : au niveau de la couche d’adaptation (22) du dispositif émetteur (20) : pour chaque fragment (52) initialement transmis vers la couche de liaison (21) du dispositif émetteur (21), une mémorisation d’un instant de transmission initiale dudit fragment (52), pour chaque fragment (52) indiqué comme manquant dans le message d’acquittement : un calcul d’un délai de retransmission correspondant à une différence entre l’instant de transmission initiale dudit fragment (52) et un instant de retransmission dudit fragment (52), une retransmission dudit fragment (52) en incluant une information relative audit délai de retransmission, au niveau de la couche d’adaptation (42) du dispositif récepteur (40) : une estimation de l’instant de transmission initiale dudit fragment (52) à partir d’un instant de réception dudit fragment (52) et de l’information relative au délai de retransmission incluse dans ledit fragment (52). Dispositif récepteur (40) d’un système (10) de communication sans fil, comportant un processeur implémentant une couche d’adaptation (42) entre une couche de liaison (41) de niveau inférieur et une couche applicative (43) de niveau supérieur, ledit processeur étant configuré au niveau de la couche d’adaptation (42) pour recevoir, en provenance de la couche de liaison (42), des fragments (52) d’un paquet de transport (50) émis par un dispositif émetteur (20) du système (10) de communication sans fil, caractérisé en ce que : le paquet de transport (50) comporte plusieurs paquets applicatifs (51), chaque paquet applicatif (51) correspondant à un ou plusieurs fragments (52), et le processeur est configuré au niveau de la couche d’adaptation (42), pour chaque nouveau fragment (52) reçu d’un paquet applicatif (51), pour : vérifier si un critère de transmission est satisfait pour ledit paquet applicatif (51) en fonction des fragments (52) déjà reçus pour ledit paquet applicatif (51), et si le critère de transmission est satisfait, transmettre vers la couche applicative (43) au moins un fragment (52) déjà reçu pour ledit paquet applicatif (51), même si tous les fragments (52) du paquet de transport (50) n’ont pas encore été reçus. Dispositif récepteur (40) selon la revendication 10 dans lequel le processeur est en outre configuré au niveau de la couche d’adaptation (42) pour émettre, en réponse à la réception du dernier fragment (52) du paquet de transport (50), au moins un message d’acquittement renseignant sur des fragments (52) correctement reçus et des fragments (52) manquants du paquet de transport (50). Dispositif récepteur (40) selon l’une quelconque des revendications 10 à 11 dans lequel la couche d’adaptation (42) est une couche SCHC. Dispositif récepteur (40) selon l’une quelconque des revendications 10 à 12 dans lequel le critère de transmission est vérifié si tous les fragments (52) dudit paquet applicatif (51) ont été reçus. Dispositif récepteur (40) selon l’une quelconque des revendications 10 à 13 dans lequel un paquet applicatif (51) comporte plusieurs fragments (52), et le critère de transmission est vérifié si le nombre de fragments (52) reçus pour ledit paquet applicatif (51) est au moins égal à un nombre prédéterminé et si une différence entre un instant de réception d’un premier fragment (52) pour ledit paquet applicatif (51) et un instant courant est au moins égale à une durée prédéterminée. Dispositif récepteur (40) selon l’une quelconque des revendications 10 à 14 dans lequel un paquet applicatif (51) comporte plusieurs fragments (52), et le critère de transmission est vérifié si au moins un sous-ensemble prédéterminé des fragments (52) dudit paquet applicatif (51) ont été reçus et si une différence entre un instant de réception d’un premier fragment (52) pour ledit paquet applicatif (51) et un instant courant est au moins égale à une durée prédéterminée. Dispositif récepteur (40) selon l’une quelconque des revendications 10 à 15 dans lequel la vérification si le critère de transmission est satisfait est effectuée en fonction des autres paquets applicatifs (51) déjà reçus pour le paquet de transport (50). Dispositif récepteur (40) selon la revendication 11 ou selon l’une quelconque des revendications 12 à 16 en combinaison avec la revendication 11 dans lequel le processeur est configuré, au niveau de la couche d’adaptation (42), pour : recevoir une retransmission d’un fragment (52) indiqué comme manquant dans le message d’acquittement, et estimer un instant de transmission initiale du fragment (52) manquant par le dispositif émetteur (20) à partir d’un instant de réception du fragment (52) retransmis et d’une information relative à un délai de retransmission correspondant à une différence entre l’instant de transmission initiale dudit fragment (52) et un instant de retransmission dudit fragment (52) par le dispositif émetteur (20), ladite information étant incluse dans le fragment (52) retransmis.