Brevet FR2924887A1 — publié le 20090612

PROCEDE ET DISPOSITIF DE TRANSMISSION ROBUSTE D'EN-TETES RESEAU COMPRESSES L'invention concerne un procédé et un dispositif permettant de protéger des données contre les erreurs, dans un système de transmission. Elle est utilisée notamment dans la transmission de données multimédia. Elle 5 s'applique aussi dans la transmission de données par paquets ayant un en-tête compressé. Dans le domaine des transmissions de données, ces dernières peuvent être entachées d'erreurs dues au canal de transmission lui-même. La 10 transmission dans les canaux sans fils, comme par exemple l'usage de l'UMTS (Universal Mobile Telcommunication System), la technologie WiFi, ou encore WiMAX, ou les solutions employées sur les canaux Haute fréquence (HF) ... engendre des erreurs qui peuvent venir perturber le décodage des données à la réception. 15 Pour combattre le risque que ces erreurs perturbent la transmission, il est connu de l'Homme du métier d'utiliser des solutions de type retransmission des données, par exemple la technique de retransmission de données automatique plus connue sous l'abréviation anglo-saxonne ARQ (Automatic Request), ou sa déclinaison hybrid-ARQ. Ces solutions sont en général 20 appliquées au niveau réseau. Il existe aussi des solutions reposant sur l'introduction de redondance (FEC : Forward Error Correction) au niveau accès radio c'est-à-dire au niveau de la couche physique du système de transmission directement. Il est aussi connu d'employer des en-têtes compressés standard avec un 25 codage correcteur d'erreur plus important au niveau de la couche physique ou l'utilisation de retransmissions. L'inconvénient principal des solutions présentes dans l'état de l'art est qu'en général, la protection se porte au niveau de l'ensemble en-tête et données, sans différentiation et avec suppression du paquet en cas de corruption, alors que l'on pourrait souhaiter recevoir des charges utiles partiellement corrompues si leur en-tête reste elle correcte. Un inconvénient supplémentaire aux techniques de retransmission est qu'elles supposent la présence d'un lien duplex, ce qui n'est pas toujours 5 possible, notamment dans le cas des applications de diffusion. Un autre inconvénient des techniques de l'art antérieur est qu'elles engendrent un fort niveau de redondance au niveau physique, sous la couche réseau. Ceci peut entraîner d'une part une incompatibilité avec le standard utilisé (s'il n'a pas prévu un tel niveau de protection, ou l'emploi des 10 codes que l'on souhaite employer) et d'autre part amène en général à augmenter le niveau de protection sur l'ensemble du paquet de manière indifférencié ce qui se révèle plus coûteux en terme de bande passante. L'idée de l'invention repose sur une nouvelle approche qui consiste notamment à protéger l'en-tête du paquet à transmettre sans que cela 15 implique de protéger également les données utiles en cas de fonctionnement normal de la transmission de données. L'objet concerne un procédé de transmission de données dans un système de transmission, les données étant transmises sous la forme de paquets 20 comprenant au moins un champ en-tête et un champ de données et selon un format adapté au système de transmission caractérisé en ce qu'il comporte au moins les étapes suivantes : - récupérer le paquet de données à transmettre qui comprend un en-tête et des données utiles, identifier la partie en-tête de la partie 25 données utiles, appliquer un codage correcteur sélectionné au niveau de l'en-tête, et fournir le nouveau paquet résultant à la couche liaison, en communiquant aussi le mode protection utilisé, générer l'en-tête liaison selon le format de transmission du système 30 de transmission considéré intégrant le mode de protection utilisé, et l'adaptation de la somme de contrôle CRC de la couche liaison. D'autres caractéristiques et avantages apparaîtront à la lecture de la description détaillée donnée à titre d'exemple et non limitative qui suit faite en regard de dessins annexés qui représentent : o La figure 1, la protection de paquet ECR (en-tête compressé robuste), o La figure 2, un exemple de chaîne de communication mettant en oeuvre des modules ECR selon l'invention, o Les figures 3 et 4 des courbes de gain en terme de débit utilisé et de rendu final au niveau applicatif, et o La figure 5 présente les étapes typiques de la transmission de données multimédia sur un réseau sans fil au travers des couches application, session, transport, réseau, liaison, et physique. Afin de mieux faire comprendre le procédé selon l'invention, la description qui suit est donnée dans le cadre d'une application de protection des en- têtes IP, en particulier lorsqu'ils ont été compressés, par exemple au moyen du standard ROHC (Robust Header Compression) normalisé par le comité IETF dans les RFC 3095 et afférentes. L'idée consiste notamment à appliquer à un en-tête compressé considéré un mécanisme de protection par application d'un code correcteur d'erreurs, afin de protéger l'en-tête du paquet. En effet, la perte de l'en-tête entraîne généralement la perte du paquet. Or, dans l'exemple donné, la réception des données sources (c'est-à-dire les données utiles au niveau applicatif) même partiellement corrompues au niveau transport ou applicatif est préférable à une perte des paquets correspondants. II s'agit typiquement des transmissions pour lesquelles des mécanismes de protection, de correction ou de masquage ont pu être mis en place au niveau applicatif ou transport, comme par exemple des transmissions audio ou vidéo : dans ce cas, l'élimination d'un paquet dans la pile protocolaire (par exemple au niveau liaison ou réseau) du fait de la corruption de son en-tête est dommageable. La figure 1 schématise les étapes permettant le changement du contenu ou du format du paquet de données à transmettre en appliquant les procédés selon l'invention. Le procédé met en oeuvre par exemple les étapes suivantes : Etape 1 : récupérer le paquet réseau de la couche IP, 1, et identifier la partie en-tête compressé, 2, de la partie données sources ; d'un point de vue réseau, la charge utile = les données à transmettre du point de vue de la couche considérée, donc notamment les données sources, mais aussi les en-têtes des couches au-dessus. Etape 2 : appliquer un codage correcteur sélectionné, qu'il s'agisse d'un code par défaut ou d'un code sélectionné en fonction des informations disponibles sur l'état de la liaison de transmission considérée, et fournir le nouveau paquet réseau résultant 4 à la couche liaison, avec identification des informations de codage d'erreur ECR (en-tête compressé robuste) : mode de protection utilisé, et le cas échéant de la longueur de l'en-tête compressé protégé. Etape 3 : générer l'en-tête liaison selon le standard de transmission considéré intégrant les informations ECR (mode de protection utilisé, et le cas échéant la longueur de l'en-tête compressé protégé), et adaptation de la somme de contrôle (CRC) de la couche liaison. Le mécanisme ECR (en-tête compressé robuste) s'applique naturellement également dans le cas où l'en-tête n'est en fait pas compressé, ce qui est par exemple le cas avec l'emploi du mode non compressé � UNCOMPRESSED � du protocole ROHC, sachant qu'il se révèle alors plus coûteux à mettre en pratique puisque la partie du paquet de données à protéger est plus conséquente. Le mécanisme ECR peut être directement intégré à l'application du mécanisme classique de compression d'en-tête, ce qui simplifie la transmission de l'identification de la partie en-tête compressée de la partie données utiles au module ECR dans la première étape. Le mécanisme ECR peut aussi être étendu à la protection de tout ou partie des données utiles, en adaptant le mécanisme de codage correcteur d'erreur pour le faire porter sur tout ou partie des données utiles, ce qui impliquera la nécessité d'ajouter également les informations correspondantes ECR dans l'en-tête liaison. En pratique, ceci sera intéressant uniquement si les en-têtes sont mieux protégés que la partie données utiles. Les données à transmettre sont par exemple de type multimédia. La figure 2 montre un exemple de chaîne de communication mettant en oeuvre des modules ECR, qui sont positionnés en pratique sous la couche réseau (IP) à la place (ou à l'intérieur) des modules classiques de compression d'en-tête de type ROHC. Au niveau de l'émetteur 1, les données ECR sont soit connues, soit introduites par un module ECR 2 selon des modes décrits ci-après. Au niveau du récepteur 3, soit le récepteur connaît les paramètres utilisés pour la correction d'éventuelles erreurs, soit il comporte un module ECR 4 adapté à trouver ces paramètres (mode de protection utilisé, et le cas échéant longueur de l'en-tête compressé protégé). Les données sont transmises par un lien sans fil 5. La mise en oeuvre de l'ECR, qui s'appuie sur les trois étapes explicitées précédemment est illustrée ci-après dans le cas de l'application sur un accès 20 radio de type 802.11. En pratique, le standard 802.11 [1] définit le format des trames échangées comme suit : FC D/ID Adresse 1 Adresse 2 Adresse 3 SC Adresse 4 (2) (2) (6 octets) (6 octets) (6 octets) (2) (6 octets) Corps de la trame (0 à 2312 octets) IFCS(4) Tableau 1 25 Avec : FC : contrôle de trame (frame control) D/ID : Durée / Identificateur (ID) SC : contrôle de séquence (sequence control) FCS : somme de contrôle d'intégrité dit aussi CRC (frame check sequence) où l'on trouve pour chaque trame un en-tête (dit MAC header pour en-tête medium access), un corps de trame (de longueur variable, véhiculant les en-têtes des couches protocolaires supérieures et les données utiles du paquet), et un champ de contrôle (dit FCS pour Frame Sequence Check) permettant la détection d'erreur. Plus précisément, l'en-tête se découpe notamment selon les champs suivants : ^ Champ de contrôle de trame (dit FC pour Frame Control), sur deux octets, qui se décompose comme suit : Version de Type Sous-Type protocole (2 bits) (4 bits) (2 bits) de DS vers Plus Retry Puissance Plus de WEP ordre (1 bit) DS de (1 bit) Mgt données (1 bit) (1 bit) (1 bit) Frag (1 bit) (1 bit) (1 bit) Tableau 2 Avec : DS : distribution service Frag : fragments Retry : retransmission WEP : mode de chiffrement WEP (Wired Equivalent Privacy) où sont en particulier indiqués le � type � et le � sous-type � de la trame considérée, les champs qui permettent de séparer les types gestion (correspondant aux demandes d'association et aux messages d'annonce du point d'accès), contrôle (qui identifie les demandes d'autorisation d'accès au média pour émettre du trafic) et données (qui correspond aux trames de données). Le sous-type permet de distinguer parmi les différents types la nature exacte de la trame considérée. ^ Corps de la trame, qui contient la charge utile pour la couche liaison, c'est-à-dire le paquet IP complet (en-tête, compressé ou non et données source), ^ Champs somme de contrôle (également appelée CRC pour Cyclic 5 Redundancy check) qui permet de détecter les erreurs par contrôle de l'intégrité du bloc de données sur lequel il porte. La solution ECR selon l'invention correspondant à introduire du codage correcteur d'erreur sur l'en-tête IP compressé, mais aussi à laisser transiter 10 des paquets dont les données utiles peuvent être corrompues, il est nécessaire de réduire la portée du champ somme de contrôle et de ne le faire porter que sur l'en-tête, et non plus sur l'en-tête et le corps de la trame comme il est fait classiquement. Un exemple de définition de nouveaux sous-types, parmi les valeurs 15 réservées, pour identifier les flux ECR (et éventuellement le flux ROHC) est donné dans le tableau 3 suivant : Valeur Description Valeur Description sous-type type sous-type 10 données 0000 Données (Data) 10 données 0001 Données + CF-Ack (Data) 10 données 0010 Données + CF-Poli (Data) 10 données 0011 Données + CF-Ack + CF-Poil (Data) 10 données 0100 NuII (Data) 10 données 0110 CF-Poli (pas de données) (Data) 10 données 0111 CF-Ack + CF-Poli (pas de (Data) données) 10 données 1000 ROHC Données (Data) 10 données 1001 ECR Données mode 1 (Data) 10 données 1010 ECR Données mode 2 (Data) 10 données 1011 ECR Données mode 3 (Data) 10 données 1100 - 1111 réservé (Reserved) (Data) 11 données 0000 - 1111 réservé (Reserved) (Data) Tableau 3 Les valeurs utilisées dans cet exemple pour la protection ECR selon l'invention sont 1001 pour le mode 1, 1010 pour le mode 2 et 1011 pour le mode 3. A titre illustratif, trois cas peuvent être proposés pour véhiculer les trames de données ECR : o le � mode 1 �, le plus simple, correspond à un type entièrement prédéfini, par exemple en fonction de l'application, pour lesquels les paramètres ECR ne sont pas fournis par la trame, car ils sont supposés connus de l'émetteur et du récepteur. Dans ce cas, le champ de contrôle de trame est inchangé par rapport à la norme, et seule la portée du champ somme de contrôle doit être modifiée, pour porter sur l'en-tête uniquement (30 octets dans l'exemple considéré). o le � mode 2 � permet l'introduction d'informations ECR dans les valeurs utilisées pour identifier un flux de données. Ces informations ne sont donc plus prédéfinies, et peuvent donc soit varier au cours du temps, par exemple en fonction de l'état de la liaison, soit être simplement redéfinies par l'émetteur pour chaque nouvelle transmission. Dans ce mode, on propose donc d'étendre le champ FC d'un octet ou deux octets dédiés à l'identification du code considéré pour la protection ECR et à l'information de taille de l'en-tête initiale compressée. En pratique, l'index de code considéré sera ainsi donné sur deux à huit bits faisant référence à une table pré-définie connue de l'émetteur et du récepteur et contenant les informations nécessaire aux opérations de codage et décodage correcteur d'erreurs (type de code, polynôme(s) générateur(s), rendement, .). L'information de taille de l'en-tête initiale compressée t sera codée sur six à huit bits, la valeur transmise étant en pratique soit la taille elle-même soit étant inférée de la taille par une règle simple : ainsi, dans le cas d'une compression d'en-tête RTP/UDP(-Lite)/IPv6, la taille de l'en-tête compressée ROHC peut atteindre une longueur $=65 octets, ce qui permet de coder f-1 sur 6 bits seulement. Le nouveau champ FC résultant est illustré ci-dessous. Dans ce cas, la portée du champ somme de contrôle est là aussi modifiée, sur la nouvelle en-tête uniquement (de taille 31 ou 32 octets dans ce cas pour l'exemple considéré). Version de protocole Type Sous-Type (2 bits) (2 bits) (4 bits) To DSFrom DS More Retry Power More WEP Order Frag (1 bit) Mgt Data (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) Code considéré (2 bits) Longueur de l'en-tête (6 bits)25 Version de Type Sous-Type protocole (2 bits) (2 bits) (4 bits) To DSFrom DS More Retry Power More WEP Order Frag (1 bit) Mgt Data (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) Code considéré (8 bits) Longueur de l'en-tête (8 bits) Tableau 4 - le � mode 3 � se rapproche du mode 2 au sens où il permet lui aussi l'introduction d'informations ECR, qui sont dans ce cas limitées au code considéré, l'information de longueur de l'en-tête compressée à laquelle la protection a été appliquée étant déduite de l'en-tête compressée elle-même. En pratique, ceci suppose donc un démarrage du décodage correcteur d'erreur sur le début de l'en-tête ECR, permettant l'extraction de l'information de taille de l'en-tête compressée initiale, et donc la déduction de la taille de l'en-tête en fonction du code qui a été appliqué. Version de Type Sous-Type protocole (2 bits) (2 bits) (4 bits) To DSFrom DS More Retry Power More WEP Order Frag (1 bit) Mgt Data (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) (1 bit) Code considéré (8 bits) Tableau 5 Les extensions proposées sont données à titre d'exemple, et que le mécanisme reste le même si l'on choisissait une répartition différente des 15 bits d'extension entre code considéré et longueur d'en-tête. Les figures 3 et 4 permettent d'illustrer le gain obtenu en application du procédé selon l'invention. Les tests ont été réalisés dans le cadre d'une transmission vidéo H.264/AVC, avec comme codeur une version rendue robuste aux plantages logiciels (� crash � en anglo-saxon) du logiciel de référence JM 10.1 [3] du standard. En pratique, c'est la séquence de référence 'Foreman' de l'ITU-T, utilisée au format Qcif, 15 Hz qui a été employée, en mode multi-slices c'est-à-dire avec découpage possible de chaque image en plusieurs tranches ou sous-images avec une taille maximale de paquets NAL (Network Abstraction Layer) de 192 octets et des groupes de 15 images (11P14). Afin de pallier à la forte sensibilité aux erreurs du codeur source, ces données sources a été protégée au niveau applicatif par l'application d'un code correcteur d'erreur convolutif (code convolutif poinçonné à rendement compatible (RCPC) de code mère rendement 1/3 et de mémoire 6 défini dans [2]. Deux cas sont présentés, correspondant à un débit sans codage correcteur de 164 kbps en mode ROHC et 155 kbps en mode ECR pour obtenir un débit transmis sur le canal identique de 328 kbps dans le premier cas (figure 3) et 210 kbps dans le second cas (figure 4)... DTD: Chaque NAL codée a ensuite été encapsulée séparément dans une trame RTP (protocole transport temps réel Real Time Protocol) selon les recommandations de la RFC IETF 3984, puis transmise à une pile protocolaire standard UDP-Lite/lPv6 avant envoi soit vers un module de compression ROHC classique, soit vers le module ECR de compression puis protection selon l'invention. Dans les deux cas, les paramètres de compression ROHC employés ont été : L=2, FO TIMEOUT=50, IR TIMEOUT=1000. Le mode ECR a été employé en 'mode 1' avec emploi du codeur RCPC susmentionné, utilisé au rendement mère 1/3. Les données ont ensuite été transmises sur un pseudo-lien radio, simulé par 25 l'ajout d'un bruit additif blanc gaussien dont le rapport signal à bruit Eb/No est l'abscisse des courbes présentées. La figure 5 présente les étapes typiques de la transmission de données multimédia sur un réseau sans fil au travers des couches application, 30 session, transport, réseau, liaison, et physique. Sur la partie gauche de la figure 5, une application incluant le codage source 10, transmet les données à une étape d'encapsulation 11. Les données encapsulées sont ensuite transmises par la couche transport 12 à une couche réseau 13. La couche réseau transmet les données à une étape de compression ECR 14, selon le procédé décrit en relation aux figures précédentes. Les données avec en-têtes compressés sont transmises à la couche accès radio 15 comprenant les couches liaison et physique. Cette dernière couche accès radio va transmettre les données ayant un en-tête compressé vers un récepteur (partie droite de la figure). Ce récepteur reçoit les données au niveau de sa couche accès radio 16, puis les transmet à une étape de décompression d'en-tête selon l'invention, 17. Les données avec en-tête décompressés sont ensuite transmises vers la couche réseau IP 18, puis vers la couche de transport 19. Les données sont ensuite désencapsulées (étape 20) avant d'être transmises à la couche applicative 21. L'invention permet notamment d'améliorer la transmission des paquets de type en-tête avant transmission sur un réseau sans fil. Elle n'oblige pas à modifier la solution accès radio retenue qu'au niveau de l'en-tête, insertion des informations ECR, modification de la somme de contrôle, ce qui peut être autorisé dans le cade d'un standard, et qu'elle est moins coûteuse en terme de débit utilisé que de la retransmission. En s'insérant dans l'en-tête liaison, la solution sera clairement identifiée, ce qui pourra permettre à un récepteur n'implémentant pas l'invention de détecter les trames qui l'emploient et de les rejeter non pertinentes, sans risquer de décoder des choses fausses. En modifiant la portée de la somme de contrôle pour la faire porter uniquement sur l'en-tête liaison, on évite la perte de la trame pour une charge utile erronée, tout en assurant que l'en-tête liaison est correcte (validée par sa somme de contrôle), et que l'en-tête du paquet réseau est protégé (par le code correcteur d'erreur et éventuellement la somme de contrôle du mécanisme de compression d'en-tête). Ainsi, on évite le recours systématique à de l'ARQ ou du FEC sur tout le paquet, et on gagne en débit, et on peut appliquer la solution sur des liens 5 mono et bi-directionnels. Références [1] M. Gast, 802.11 wireless networks, the definitive guide. Ed. O'Reilly. [2] J. Hagenauer, "Rate-compatible punctured convolutional codes and their 10 application," in IEEE Trans. on Communications, vol. 36, n. 4, pp. 389-400, April 1988. [3] Joint verification mode) for H.264 (JM 10.1), http://iphome.hhi.de/suehring/tml, July 2006. 15 REVENDICATIONS 1 û Procédé de transmission de données dans un système de transmission, les données étant transmises sous la forme de paquets comprenant au moins un champ en-tête et un champ de données et selon un format adapté au système de transmission caractérisé en ce qu'il comporte au moins les étapes suivantes : - récupérer le paquet de données à transmettre qui comprend un en-tête et des données utiles, identifier la partie en-tête de la partie 10 données utiles, - appliquer un codage correcteur sélectionné au niveau de l'en-tête, et fournir le nouveau paquet résultant à la couche liaison, en communiquant aussi le mode protection utilisé, générer l'en-tête liaison selon le format de transmission du système 15 de transmission considéré intégrant le mode de protection utilisé, et l'adaptation de la somme de contrôle CRC de la couche liaison. 2 û Procédé selon la revendication 1 caractérisé en ce que l'en-tête est un en-tête compressé et le codage correcteur d'erreur est introduit sur l'en-tête 20 compressé. 3 û Procédé selon la revendication 1 caractérisé en ce que l'information sur la longueur de l'en-tête compressé est elle aussi transmise. 25 4 û Procédé selon l'une des revendications précédentes caractérisé en ce que la transmission des données utilise le standard IEEE 802.11 et en ce que le codage correcteur d'erreur est introduit sur l'en-tête IP compressé. 5 û Procédé selon la revendication 1, 2 ou 4 caractérisé en ce que les 30 paramètres du codage correcteur d'erreur sont supposés connus del'émetteur et du récepteur et les paramètres sont fournis par un processus externe à la trame de données. 6 û Procédé selon la revendication 1, 2 ou 4 caractérisé en ce que les paramètres du code correcteur d'erreur sont introduits dans la trame au niveau d'un champ de contrôle de trame dont le nombre d'octets est étendu d'un ou de plusieurs octets dédiés à l'identification du code considéré pour la protection ECR et aussi à l'information de taille de l'en-tête initial compressé. 7 û Procédé selon la revendication 1, 2 ou 4 caractérisé en ce que l'information de longueur d'en-tête compressé à laquelle la protection a été appliquée est déduite de l'en-tête compressé elle-même, ce qui suppose un démarrage du décodage correcteur d'erreur sur le début de l'en-tête compressé ECR, permettant l'extraction de l'information de taille de l'en-tête 15 compressé initial. 8 û Procédé selon la revendication 1 ou 2 caractérisé en ce que le codage correcteur est appliqué sur tout ou partie de la charge utile. 20 9 û Procédé selon l'une des revendications précédentes caractérisé en ce que les données à transmettre sont des données multimédia. û Procédé selon l'une des revendications précédentes caractérisé en ce que le système est un système de transmission vidéo H.264. 11 û Système de transmission de données comportant un émetteur et un récepteur décodeur caractérisé en ce que ledit émetteur comporte des moyens pour exécuter au moins les étapes du procédé selon l'une des revendications 1 à 10. 25 30