Brevet FR2964520A1 — publié le 20120309

La présente invention concerne un procédé de détection d'erreurs dans un message de données, mis en oeuvre au sein d'un réseau de communication. De manière générale, la présente invention concerne le domaine des Technologies de l'Information et de la Communication. La présente invention se rapporte plus particulièrement au transport de données multimédia dans des réseaux de communication par paquets de type TCP-IP (« Transmission Control Protocol » et « Internat Protocol »), ces réseaux pouvant être locaux ou non. En particulier, la présente invention concerne le domaine de la localisation des erreurs bits dans des paquets corrompus lors de la diffusion de contenus audio-vidéo par le protocole de transport TCP sur un réseau de communication radio. Dans le cadre du protocole de transport TCP, un paquet transportant des données applicatives peut contenir divers champs ayant des fonctions différentes. Les différents champs du paquet peuvent contenir des informations de structure du paquet, des informations de sémantique sur les données du paquet ou des informations de données pures. Ces champs possèdent une importance différente selon la fonction qu'ils remplissent. De même, un paquet peut être plus ou moins important que les paquets qui le précèdent ou que ceux qui le suivent. Un paquet va, lors de sa transmission sur un réseau de communication non fiable tel que des réseaux sans fils utilisant les techniques de transmission par radio, fréquemment subir des modifications indésirables dues à des erreurs de transmission. En cas d'occurrence de telles erreurs sur un ou plusieurs champs du paquet, il peut être utile de réaliser un traitement de détection et de correction de ces erreurs, qui pourra être différencié selon la fonction du champ corrompu. Un moyen connu dans l'état de la technique de mise en oeuvre de ces traitements différenciés par champ d'un paquet est la protection par insertion d'une information de redondance calculée sur le champ du paquet, par exemple de type CRC (Contrôle de Redondance Cyclique ou « Cyclic Redundancy Check »). Ce type de mécanisme permet de détecter la présence d'une erreur dans le champ, puis de pouvoir éventuellement déterminer le traitement adéquat de correction à appliquer à un champ spécifique selon la présence ou l'absence d'erreurs, et différencié selon la fonction du champ spécifique corrompu. Dans le cadre de la transmission de flux multimédia sur Internet ou sur réseaux locaux (LANs ou « Local Area Networks » en anglais), un serveur de contenu, sous forme de données multimédia, fournit un ou plusieurs flux de données (de type vidéo, audio, texte (i.e. sous-titres), ...) vers un ou plusieurs dispositifs clients. Ces derniers reçoivent et consomment ces données au fur et à mesure de leur réception. Par exemple, le dispositif client joue la vidéo et l'audio au fur et à mesure qu'il les reçoit. On parle alors de « multimedia streaming ». Afin de limiter le débit des données et obtenir des débits compatibles avec le débit du réseau sous-jacent, ces différents flux de données sont généralement compressés, par exemple pour la vidéo selon les normes de compression ISO/IEC JTC1 MPEG 2 ou MPEG 4 part2 ou ITU-T H.264/SVC. De plus en plus d'équipements disponibles pour le grand public sont capables d'envoyer de tels flux de données, tels que les caméscopes, appareils photo, caméras de vidéo surveillance, NAS (network Attached Storage), serveurs de vidéo domestique, récepteurs de télévision, ordinateurs, téléphones. Les flux multimédias (vidéo, audio, texte) destinés à être envoyés peuvent être stockés et compressés à l'avance sur l'appareil émetteur ou au contraire être capturés, compressés au fil de l'eau et envoyés sur un réseau de communication à destination d'un appareil récepteur. Ces flux multimédia sont constitués de données (images, portions d'images (« slices ») ou portions de sons (« samples »)) dont la durée de vie utile est limitée, c'est-à-dire que ces données doivent impérativement être reçues et traitées par le périphérique récepteur avant une certaine échéance. Cette échéance correspond à l'instant où la donnée est requise pour être affichée ou jouée par le client. Au-delà de cette échéance, la donnée devient alors inutile et doit simplement être ignorée par le client. En cas d'erreur lors de la transmission détectée après traitement en réception, le client peut utiliser une méthode de correction d'erreur et en cas d'échec, si l'échéance le permet, demander au serveur de données une retransmission du paquet. Ces flux multimédia sont transmis sur des réseaux de communication constitués de noeuds d'interconnexion (routeurs, commutateurs, etc.) afin de router les paquets de données depuis les dispositifs sources jusqu'aux dispositifs destinataires. Dans le cas de réseaux locaux, les réseaux sans fils de type « WI-Fi» basés sur l'ensemble de normes IEEE 802.11 sont de plus en plus prédominants et ont la faveur du grand public de par leur facilité de mise en oeuvre malgré des inconvénients inhérents à la nature du support physique radio pouvant provoquer une variation du débit utile et un taux d'erreur de transmission élevé et variable. Un des problèmes qui se posent est celui consistant à optimiser les performances (vitesse d'exécution) dans le récepteur du traitement de détection d'erreurs globalement dans le paquet et localement dans les champs de plus grande importance de ce paquet, en utilisant les CRC associés, notamment lorsque l'on cherche à localiser les erreurs sur un grand nombre de champs du paquet. Cette optimisation des performances du traitement de détection d'erreurs permet d'optimiser le choix entre plusieurs méthodes de recouvrement d'erreur, par rejet du paquet, par une méthode liée à la méthode de compression d'image, ou bien par une demande de retransmission du paquet. Il est connu par la demande de brevet internationale N° WO 2009/076371 (Qualcomm) « Hierarchical CRC Scheme », un procédé dans lequel un code de type CRC (Contrôle de Redondance Cyclique ou « Cyclic Redundancy Check ») hiérarchique est construit à partir de deux portions de message (une première et une seconde) émis depuis un dispositif émetteur. Le système dans lequel ce code de type CRC hiérarchique est mis en oeuvre comprend un émetteur qui fournit deux informations différentes à une pluralité (deux ou plus) de récepteurs. Ces récepteurs ne connaissent pas la première portion, mais un des récepteurs est déjà informé de la seconde portion. Un CRC est calculé sur les deux portions du message et fournit une protection (détection d'erreur). Le récepteur qui est informé de la seconde portion utilise cette connaissance préalable pour bénéficier d'une détection plus puissante sur la première portion car cette seconde portion est alors utilisée dans le calcul d'un CRC de longueur plus importante. A la différence de la demande de brevet internationale citée ci- dessus, la présente invention vise à optimiser les performances (vitesse d'exécution) du traitement de détection d'erreurs globalement dans le paquet et localement dans les champs de plus grande importance du paquet en utilisant les CRC associés, avec un récepteur de type unique. A cet effet, la présente invention concerne un procédé de détection d'erreurs dans un message de données, mis en oeuvre au sein d'un réseau de communication adapté pour transférer des données et reliant un dispositif client et un dispositif serveur, ledit message de données comprenant une pluralité de champs chacun protégé par un code de type CRC (Contrôle de Redondance Cyclique) individuel, ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes : - construction d'un code CRC global à partir desdits codes CRC individuels ; - vérification de la présence éventuelle d'erreurs dans ledit message de données en utilisant le code CRC global construit ; et - en cas de présence d'erreur, localisation des champs du message comportant une erreur en utilisant lesdits CRC individuels. Le procédé selon la présente invention permet la réutilisation d'un même champ de bits de CRC d'une part pour un usage global permettant la détection d'erreur dans n'importe quelle partie du message sur lequel ce CRC global a été calculé et d'autre part pour un usage local de localisation de ces erreurs dans au moins un des champs de bits de donnée constituant ce message. Ceci est particulièrement avantageux pour un système équipé de moyens matériels pour le calcul de CRC globaux sur l'ensemble d'un message, sur un champ de largeur fixe en nombre de bits, où les calculs de CRC individuels seraient de taille variable et devraient donc être supportés par des moyens de calcul logiciels moins performants Un avantage supplémentaire du procédé selon la présente invention est de rester conforme au protocole TCP. Le procédé selon la présente invention permet la réutilisation d'un champ défini par le standard TCP et sera compatible avec un grand nombre d'équipements existants ignorants de l'invention, tels que des terminaux clients, des passerelles et serveurs proxy et d'autres équipements d'infrastructure de réseau. Seuls certains équipements d'extrémité implémentent le procédé selon la présente invention. Il est possible pour le serveur et le client (récepteur) du message TCP de convenir de l'utilisation d'un algorithme non standard pour le calcul du champ nommé « somme de contrôle TCP » ou « TCP checksum » en terminologie anglo-saxonne, faisant partie de l'entête TCP et d'une longueur de deux octets. Ce champ contient par défaut une valeur de 16 bits correspondant à une somme de contrôle (ou « checksum » en terminologie anglo-saxonne) calculée sur l'ensemble du message TCP (après retrait des champs de niveau 2 et une partie des champs de niveau 3). Selon le procédé selon la présente invention, après un échange entre client et serveur, la somme de contrôle TCP (« checksum TCP ») est remplacée par une pluralité de CRC individuels calculés indépendamment sur des champs individuels de données correspondant à des parties du message TCP. Selon un mode de réalisation, lorsque le format d'au moins un champ du message de données est conforme à un protocole de communication prédéterminé, le procédé comprend en outre une étape de vérification de la conformité du format dudit champ au protocole prédéterminé. Selon un mode de mise en oeuvre, lorsque des erreurs ont été localisées dans un champ du message dont le format est conforme à un protocole de communication prédéterminé, ledit procédé comprend en outre une étape de correction dudit champ sur la base de plages de valeurs possibles définies par ledit protocole prédéterminé La vérification de la conformité du format procure un moyen de détection d'erreurs dans le champ du message. Ce moyen peut être complémentaire lorsque le champ est déjà protégé par le CRC (mais que ce dernier n'a pas détecté d'erreurs). Ce moyen est particulièrement utile lorsque le champ en question n'est pas protégé par un CRC individuel. Selon un mode de mise en oeuvre particulier, ledit procédé comporte en outre les étapes suivantes : - application d'une correction d'erreurs basée sur la connaissance de messages de type NALU (« Network Abstraction Layer Unit ») non corrompus et déjà reçus ; - application d'une correction d'erreurs basée sur la prédiction de messages de type NALU (« Network Abstraction Layer Unit ») ; - application d'essais successifs de correction par remplacement des valeurs corrompus de champs à partir des valeurs des mêmes champs dans les NALU obtenues selon les deux étapes précédentes ; - calcul d'un CRC individuel sur chacune des nouvelles valeurs desdits champs à l'issue de chaque essai ; et - comparaison du nouveau CRC individuel calculé au CRC individuel dans le message reçu. Ainsi, le procédé selon l'invention permet par essais successifs de corriger les corruptions du message reçu et éviter une retransmission par le serveur, diminuant la bande passante utilisée pour ce flux vidéo ainsi que la latence de transmission. Selon un mode de réalisation, lorsque des erreurs ont été localisées dans au moins un champ dudit message de données, ledit procédé comprend en outre les étapes suivantes : - détermination de l'importance d'un champ erroné ; et - demande de retransmission de la totalité du message de données dans le cas où ledit champ erroné est important ou acquittement de la totalité du message de données dans le cas où ledit champ erroné n'est pas important. Le procédé selon l'invention permet ainsi de diminuer les cas dans lesquels un message de données sera retransmis alors que l'application est capable d'utiliser ce message de données. La bande passante consommée sur le réseau entre émetteur et récepteur pour la communication de messages est ainsi diminuée. Un message aura également un délai moyen d'attente en transmission qui sera inférieur, en particulier dans les réseaux sans fils où l'apparition d'erreur bit en transmission est de probabilité plus grande. Dans le cas d'un acquittement de message, le message reçu peut être détruit. Ainsi, selon le protocole de transport du message, celui-ci pourra être automatiquement retransmis par l'émetteur par détection de l'absence d'acquittement sans autre action de la part du récepteur du message. Un autre aspect supplémentaire au procédé précédent correspond à l'application à un message TCP comportant des champs de natures diverses et d'importances diverses, comme par exemple le cas où les données transportées dans la partie utile du message TCP correspondent à des champs de contrôle et de données pour un flux vidéo formaté selon le standard ISO/IEC JTC1 H264/SVC et transporté en paquets selon les principes du document «RTP payload format for SVC video » draft-ietf-avt-rtp-svc-20.txt . Le procédé proposé permet, par une connaissance préalable par le client TCP du formatage de la partie utile du message RTP incluse dans la partie de données du message TCP d'évaluer l'importance relative des différents champs, et d'éviter une retransmission de messages au serveur en cas de détection d'erreurs dans un de ces champs. Selon un mode de mise en oeuvre particulier, l'étape de vérification 25 de la présence éventuelle d'erreurs dans ledit message de données, comprend les étapes de: - calcul d'un CRC à partir de l'ensemble des champs du message réunis; et - comparaison du CRC calculé avec le CRC global construit; 30 la présence d'erreurs étant ainsi détectée lorsqu'il existe une différence entre les deux CRCs. La présente invention se rapporte également à un dispositif de communication apte à détecter des erreurs dans un message de données comprenant une pluralité de champs chacun protégé par un code de type CRC (Contrôle de Redondance Cyclique) individuel, ledit dispositif comprenant des moyens pour : - construire un code CRC global à partir desdits codes CRC individuels; - vérifier la présence éventuelle d'erreurs dans ledit message de données en utilisant le code CRC global construit ; et - en cas de présence d'erreur, localiser des champs du message comportant une erreur en utilisant lesdits CRC individuels. Selon un mode de réalisation, ledit dispositif comporte, lorsque le format d'au moins un champ du message de données est conforme à un protocole de communication prédéterminé, des moyens pour vérifier la conformité du format dudit champ au protocole prédéterminé. Selon un mode de réalisation, ledit dispositif comporte, lorsque des erreurs ont été localisées dans un champ du message dont le format est conforme à un protocole de communication prédéterminé, des moyens pour corriger ledit champ sur la base de plages de valeurs possibles définies par ledit protocole prédéterminé. Selon un aspect de la présente invention, le système de communication entre serveur et client TCP est un réseau sans-fil conforme à la norme IEEE 802.11 et ses variations. Selon cet aspect, la couche MAC des interfaces du serveur et du client sont modifiées de façon à ce que la somme de contrôle (« frame checksum sequence ») couvrant totalement la trame IEEE 802.11 ne couvre plus que les champs entêtes (« header fields ») des protocoles MAC, IP, TCP et RTP, permettant ainsi à des messages partiellement corrompus d'être conservés et transmis aux différentes couches de protocole du client et de mettre en oeuvre le procédé selon la présente invention. La présente invention se rapporte également à un dispositif client d'un réseau de communication comportant des moyens adaptés à mettre en oeuvre ledit procédé. La présente invention se rapporte également à un programme 5 d'ordinateur chargeable dans un système informatique, ledit programme comprenant des instructions permettant la mise en oeuvre du procédé de détection d'erreurs. On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en 10 référence aux figures annexées : - la Figure 1 illustre un système client-serveur de transport de données multimédia dans un réseau de communication sans-fil ; - la Figure 2 représente la structure d'un message SVC RTP/TCP/IP dans une trame IEEE 802.11 ; 15 - la Figure 3 illustre la structure d'un entête de message selon le protocole TCP ; - la Figure 4 représente des GRC individuels dans la somme de contrôle TCP (« checksum TCP ») ; - la Figure 5 illustre le traitement en réception de détection et 20 localisation d'erreur ; - la Figure 6a illustre le traitement de correction de l'entête NALU ; - la Figure 6b illustre le traitement de correction de l'extension d'entête NALU pour SVC ; - la Figure 7 représente le traitement de correction de l'extension 25 d'entête par usage de plusieurs NALU successifs ; - la Figure 8 illustre d'autres traitements de correction de l'extension d'entête NALU pour SVC; et - la Figure 9 représente un dispositif client et un dispositif serveur selon la présente invention. 30 Un réseau local de communications sans-fil par ondes radio, par exemple d'un type conforme au standard IEEE 802.11 et ses variantes, constitue le réseau d'infrastructure physique permettant le transport des messages conformes au protocole TCP/IP échangés entre un serveur et un client tel que représenté Figure 1. Sur la Figure 1, un client 101 reçoit un flux de messages audio-vidéo compressés et formatés pour envoi sur le réseau selon un protocole de type « Real Time Protocol » (RTP) et protocoles de contrôle associés (RTCP/RTSP) par un serveur 102. Ces messages sont, transportés entre le client 101 et le serveur 102 via un réseau local 100 tel que ceux mentionnés dans le paragraphe précédent. Le serveur 102 est par exemple un décodeur de télévision numérique ou tout autre type d'appareil incorporant un moyen de stockage de contenu audio-vidéo tel qu'un ordinateur individuel ou bien encore un appareil électronique tel qu'un caméscope, un appareil photo numérique ou un disque dur multimédia, encore appelé NAS (Network Attached Storage). Ce peut-être également un appareil comportant un moyen de réception de tels contenus transportés en continu via un deuxième réseau par exemple de type distant tel qu'un réseau IPTV (réseau dit de type contrôlé, en anglais « managed network »), un réseau d'accès à Internet, un réseau de télécommunications mobiles, ou bien encore un réseau de diffusion, avec diffusion assurée soit par transmission terrestre hertzienne, par câble ou bien par satellite de contenus audiovisuels. Le serveur 102 est capable de former à partir de ce contenu audio-vidéo compressé par exemple selon la norme ITU-T H.264-AVC avec extension SVC (H.264 SVC est un amendement de H.264 AVC approuvé par le « ITU-T Video Coding Experts Group (VCEG) » et « International Standards Organisation (ISO) MPEG »), un flux de messages conformes au formatage RTP, et capable d'injecter ce flux de messages sur une connexion logique TCP établie au préalable. Le réseau local 100 à transmission par radio fréquence permet la transmission de ce flux de messages RTP. Le client 101 est un appareil connecté au réseau local radio 100, capable de recevoir ce flux RTP/TCP via son interface conforme par exemple au protocole IEEE 802.11 et ses variantes. Cet appareil est par exemple un téléviseur ou un ordinateur personnel avec un écran et des moyens de restitution audio et vidéo permettant de restituer le contenu audiovisuel reçu dans le flux de messages RTP/TCP via l'interface IEEE 802.11 et ses variantes. Ce peut-être également un équipement de transcodage (capable de décompresser le flux reçu et de compresser à nouveau ce flux selon la méthode décrite par un autre standard de compression d'image et d'audio différent de celui utilisé pour le flux reçu) ou bien un équipement de stockage et de mise en flux sur réseau d'un contenu audiovisuel tel qu'un disque dur multimédia, encore appelé NAS (Network Attached Storage), permettant d'archiver un contenu qui est ensuite transmis en un flux RTP/TCP par le serveur 102 et reçu en provenance d'un deuxième réseau, de type distant. La Figure 2 représente une trame IEEE 802.11 contenant un segment TCP selon l'invention. Ainsi, contrairement à ce qui est décrit dans le standard IEEE 802.11 et ses variantes, la trame 200 est terminée par un champ FCS 210 (FOS correspond en anglais à « Prame Checksum Sequence ») protégeant uniquement les champs 201, 202, 203 (incluant les champs 204 et 205) et 206, au lieu de protéger l'intégralité des bits de la trame émise selon le standard IEEE 802.11 et ses variantes. Les champs 204 et 205 dans l'entête TCP 203 correspondent aux 16 bits de la somme de contrôle TCP (« TCP checksum »). Toutes les trames et tous les bits des champs de ces trames lors de la transmission sur le réseau local radio sont susceptibles de subir des erreurs et modifications dues à de multiples causes. Le champ FCS de manière générale contient un nombre calculé par le noeud source sur la base des données contenues dans la trame IEEE 802.11. Ce nombre est par exemple inséré en fin de trame. Lorsque le noeud de destination reçoit cette trame, le nombre FCS est recalculé puis comparé à celui reçu. En cas de différence, une erreur de transmission est supposée s'être produite sans que l'on soit toutefois capable de la localiser, le récepteur IEEE 802.11 va alors ignorer cette trame. Le champ FCS selon le standard IEEE 802.11 est un champ de 32 bits, utilisé pour la détection d'erreurs pendant la transmission et contenant un CRC de 32 bits. Ce CRC suit les règles du standard IEEE et est calculé sur l'ensemble des champs de l'entête MAC et du corps de la trame qui sont dénommés champs de calcul (que l'on dénommera également ici zone protégée). Dans le cadre de la présente invention ; le champ FCS est calculé d'une façon identique à celle décrite plus haut, à la différence que le CRC de 32 bits est calculé seulement sur certains entêtes de la trame. En agissant ainsi, les erreurs bits qui se produiraient dans des champs non protégés par le FCS de la trame IEEE 802.11 ne seront pas détectées par la couche MAC. Ainsi, au lieu d'être ignorées comme elles le seraient dans un cas usuel d'implémentation du standard, ces trames seront dans l'invention, transmises aux couches supérieures, où, notamment, selon un mode particulier de l'invention, on mettra à profit des CRC individuels placés dans les champs 204 et 205 selon les principes décrits ci-dessous. Dans la norme IEEE 802.11, le MAC FCS 210 est calculé en utilisant le polynôme générateur standard G(X) suivant : G(x)=x32+x26+x23+x22+x16+x12+x11 +x10+x8+x7+x5 + x4 + x2 + x + 1 Le FCS est le complément à un de la somme modulo 2 des éléments suivants : a) Le reste de la division modulo 2 de xk(x31 + x3° + x29 +.... + x2+ x + 1) par G(x), ou k est le nombre de bits du champ de calcul b) Le reste après multiplication du contenu de la zone protégée (champ de calcul, traité comme un polynôme) par x32 puis divisé par G(x). Le champ FCS lui-même est transmis en commençant par les coefficients des termes de plus haut rang. Dans une implémentation typique côté émetteur IEEE 802.11, le reste initial est mis à un pour tous les bits puis modifié par la division de la zone protégée (champs de calculs) par le polynôme générateur. Le complément à un du reste est transmis avec le bit de poids fort en premier en tant que champ FCS d'une trame IEEE 802.11. Côté récepteur, le reste initial est initialisé avec tous les bits à un. Les bits reçus en série des champs de la zone protégée puis du FCS, après division par G(x) correspondent en cas d'absence d'erreur de transmission à un reste unique non nul, qui est le polynôme suivant : 31 +X 30 +X 26 +X 25 +X 24 +X 18 +X 15 +X 14 +X 12 +X 11 +X 10 +X$ +X6 X + 5+x 4+X 3 X +X+1. La Figure 3 représente le détail des champs de l'entête TCP 203 de la Figure 2. La présente invention utilise d'une façon particulière la zone correspondant dans le segment TCP à la somme de contrôle TCP (« TCP checksum ») dans le champ 301. Dans le RFC 793 de l'IETF, on trouve la description des principes de base du protocole TCP sur IPv4. Ce RFC donne ainsi les principes de calcul de cette somme de contrôle TCP (« TCP checksum ») avec, dans le cas du transport de TCP sur IPv6 des modifications sur ce mode de calcul décrites par le RFC 2460. Mais il est également indiqué que, selon une méthode classique de signalisation entre le serveur et le client, la somme de contrôle TCP (« TCP checksum ») peut être calculée selon une méthode non standard connue des deux extrémités, connue par les client et serveur liés par cette connexion TOP. L'invention met à profit cette possibilité pour le remplissage du champ 301 de l'entête TCP 203. La Figure 4 représente un ensemble de deux zones de données 400 et 401 à protéger parmi les champs du message 200, qui seront les champs de calculs pour les deux CRC respectivement 204 et 205 qui constituent les bits du champ 301 « TCP checksum » (somme de contrôle TOP) selon l'invention. Selon un mode de réalisation, ces zones 400 et 401 correspondent par exemple au champ 207 « NALU header » d'une part et d'autre part au champ « SVC extension header » 208 joint au champ 209 contenant les macro-blocs de données d'image de cette NALU. Une variante possible pour la zone 401 est de couvrir également le champ 208 mais une partie seulement du champ 209. Dans une représentation polynomiale des zones 400 et 401, on peut écrire pour des messages 400 et 401 comprenant respectivement les bits ao , a1 , ..., ap_1 et les bits bo , b1 , bk-1 A(X) = a°, a1 x +...+ ap-1 xp 1 et B(X) = bo + b1 x +...+ bk-1 x-1 M(x) qui est construit par concaténation des zones 400 et 401 peut s'écrire : - M(X) = xk A(x) + B(X) Le CRC sur la zone complète M(x) est le reste de la division du polynôme M(x) par un polynôme générateur (polynôme CRC) G (x), après décalage vers la gauche avec insertion de bits à 0, pour un nombre de bits correspondant aux 16 bits de la zone « TCP checksum » (somme de contrôle TCP). On écrit alors M(x) xdegré(G(x)) = Q(x)G(x) + R(x) ou bien R(x) = M(x) 10 xdegré(G(x)) + Q(X)G(X) Le CRC sur 16 bits sur le polynôme M(x) vaut - CRC_M(x) = [M(x) xdegré(G(x))] Modulo G(x) car (CRC_M(x)) Modulo G(x) = CRC_M(x) et (Q(x) G(x)) Modulo g(x)=0 15 Le polynôme B(x) est de k bits, CRC_M(X) = [xk + degré (G(x)) A(x)] Modulo G(x) + [xdegré (G(x)) B(x)] Modulo G(x). En utilisant les développements précédents, on peut lier le CRC global sur M(x) aux CRC individuels couvrant respectivement la détection 20 d'erreur dans les deux zones A (x) et B (x) (champ 207 pour A(x) et champs 208, 209 pour B(x). CRC M(x) = [ xk CRC A(x)] Modulo G(x) + CRC B(x) où bien l'expression de degré inférieure plus simple à calculer : CRC_M(x) = [( xk Modulo G(x)) CRC_A(x)] Modulo G(x) + CRC_B(x) 25 Où G(x) est un polynôme générateur de 8 bits utilisé pour le calcul des CRC individuels CRC A et CRC B. Le serveur TCP 102 calcule les CRC individuels 204 et 205 sur la base d'un polynôme générateur selon les principes connus de l'homme du métier, ces CRC sont calculés sur respectivement le champ 207 d'une part et 30 les champs 208, 209 d'autre part. Un nombre de k bits consécutifs de 208, 209 est pris en compte pour le calcul du CRC_A 204. Ce nombre k est connu et fixé pour le serveur TCP 102 et son client 101. Un nombre de bits p est pris en compte pour le calcul du CRC_B 205. Ces deux CRC individuels 204 et 205 sont concaténés et placés dans le champ « checksum TCP » (somme de contrôle TOP) de l'entête TCP 203. Le segment TCP transporte un élément de flux RTP qui lui-même contient un conteneur appelé NALU (« Network Abstraction Layer Unit ») contenant des données vidéo compressées selon le standard H.264/SVC. Le conteneur NALU est composé d'un entête NALH (« Network Abstraction Layer Header ») et d'une partie utile (« payload ») contenant les données vidéo. Ce segment TCP ainsi constitué est transmis sur le réseau radio LAN 100. Pendant le transport, ce segment est susceptible de subir des altérations dues à des phénomènes radio. Sur la Figure 5, sont représentés les traitements effectués au niveau de la réception en vue de la détection et de la localisation d'erreurs. Dans une étape de réception 500, le Client TCP 101 reçoit un segment TCP inclus dans une trame IEEE 802.11. Si une corruption de bits s'est produite au niveau d'un des champs 201, 202, 203, cette corruption est détectée par la couche IEEE 802.11 MAC, la trame est ignorée et sera alors automatiquement retransmise. Dans les cas contraires, soit la trame n'a pas subi de corruption ou celle-ci s'est produite dans un champ non protégé par le champ FCS 210 tels que les champs 207 à 209. La trame est alors propagée au sein de l'interface réseau du client jusqu'à la couche particulière TCP de l'invention. L'invention se propose de traiter dans cette couche, la détection et 25 localisation des erreurs et éventuellement la correction de certains cas de corruption et d'éviter ainsi la retransmission de certains segments. Dans une étape d'évaluation 501, dans un équipement conçu pour une optimisation de performances de détection d'erreurs, le client utilise un moyen matériel connu de l'homme de l'art qui permettra un calcul rapide du 30 CRC global 402 CRC_M(x) mais ne s'appliquant qu'aux calculs sur des champs de taille fixe correspondant à la taille de la zone des champs 207 à 209. Ce CRC est calculé par division de M(x) par le polynôme générateur G(x). A fin de détection globale d'une erreur bit due à la transmission radio, le client effectue une comparaison entre ce calcul et un second résultat obtenu comme suit. Le client 101 de l'invention obtient ce second résultat par calcul selon la formule déterminée précédemment, et implémentée selon des principes connus de l'homme de l'art, ce à partir des valeurs 403 CRC_A(x) et 404 CRC B(X) reçues dans les champs 204 et 205 du segment TCP en cours d'évaluation : CRC M(x) = [( xk Modulo G(x)) CRC A(x)] Modulo G(x) + CRC B(x). Ce second résultat est alors comparé au premier résultat obtenu par un moyen matériel adapté à la dimension en nombre de bits de la zone des champs 207 à 209. On notera ici qu'il existe deux façons de vérifier à la réception qu'un message « M » protégé par un CRC « C » contient ou non des erreurs. Le CRC est le reste de la division du message par un polynôme générateur. Une première façon de vérifier consiste à prendre le message reçu M, refaire la division par le même polynôme générateur et comparer le reste obtenu avec le CRC reçu. En cas d'égalité, on considère qu'il n'y a pas d'erreurs. Une seconde façon de vérifier consiste à prendre le message reçu M et le CRC reçu ensemble (sous forme de représentation polynomiale), faire la division par le polynôme générateur et vérifier si le reste obtenu est nul ou pas. En absence d'erreurs, le reste devrait être nul puisque le reste initial (CRC reçu) a déjà été pris en compte. En cas d'égalité, on peut conclure dans une étape 502 à l'absence d'erreur. Un acquittement tel que défini par le protocole TCP par le biais d'un message ACK est alors envoyé au serveur et le segment TCP est transmis au sein du client à la partie applicative qui traite le formatage RTP puis au décodeur vidéo de façon connue de l'homme du métier. En cas de différence, une erreur existe dans un des champs. Il convient de la localiser et d'évaluer sa criticité selon le champ corrompu. Selon l'invention, on procède à une initialisation d'un compteur de champ individuel en cours d'évaluation par usage de CRC individuel. Puis, dans un mode de réalisation préféré dans une étape 504 on procède au calcul du CRC individuel par division du champ élémentaire correspondant par le polynôme générateur G(x), si dans l'étape 505, le reste est égal à la valeur de GRC individuel reçu, on procède à l'étape 507 où l'on incrémente le compteur de champ individuel. Dans une étape d'évaluation 517, si le compteur désigne l'avant dernier champ protégé par GRC individuel, l'erreur détectée au niveau global se situe donc dans le dernier champ qui n'est pas considéré critique et l'on peut envoyer le segment vers le décodeur H264/SVC pour les traitements correspondants et procéder vers l'étape 516 d'acquittement de ce segment TCP reçu avec une erreur non fatale. Si, à l'étape de vérification 505, le reste est différent, on procède à l'étape de vérification 506 où l'on vérifie que le compteur de champ individuel correspond à un champ NALU header, si c'est le cas on procède vers une étape 508 où l'on applique une méthode de correction décrite ci-dessous. On vérifie ensuite dans une étape de vérification 510 si le compteur de champ correspond à une entête d'extension du standard H264/SVC, auquel cas on procède vers l'étape de correction 509 où l'on applique une méthode de correction décrite plus loin. On vérifie ensuite dans une étape de vérification 511 si le compteur de champ correspond à une entête de slice, auquel cas on considère que cette erreur n'est pas récupérable et on rejette ce segment TCP par élimination dans une étape 513. Puis on procède dans une étape de transmission 514 selon un procédé connu de l'homme de l'art à l'envoi de trois acquittements appelés Duplicated ACK selon le standard TCP. Cela provoque au niveau du serveur une retransmission du segment TCP corrompu dans un délai plus court que l'attente classique de l'échéance d'un temporisateur. Cette mesure bien que connue de l'homme du métier permet de compenser le temps de traitement des différentes étapes parcourues dans la Figure 5. On vérifie ensuite dans une étape de vérification 512 si le compteur de champ désigne une donnée de macro block et s'il s'agit de la dernière donnée dans le segment, si ce n'est pas le cas on considère également qu'il s'agit d'une donnée critique et l'on procède vers l'étape 513 au rejet du segment corrompu. S'il s'agit de la dernière donnée, on peut procéder vers l'étape de transmission 515 au sein du client, où l'on envoie les données au décodeur H264/SVC pour traitement. On procède ensuite à l'étape de transmission 516 à l'envoi d'un acquittement TCP vers le serveur par le biais d'un message ACK en utilisant le numéro de séquence du segment TCP reçu, avant de se remettre en 500 à l'attente de la réception du segment TCP suivant. Les Figures 6a et 6b représentent les traitements des données H264/SVC pour la correction d'erreur mentionnées aux étapes de correction 508 et 509 de la Figure 5. Dans la section suivante, nous supposons que chaque entête (header) testée est associée à un GRC individuel permettant la détection d'erreur. Ces GRC permettent de déterminer pour chaque header s'il est erroné ou pas. Nous décrivons donc plus précisément ici les étapes 506, 508, 509 et 510 correspondant à la tentative de correction d'erreurs dans le « NALU header» et le « SVC extension header ». L'objectif est de tenter de régénérer des entêtes (headers) corrects afin de pouvoir transmettre la NALU correspondante au décodeur du client. Par mesure de simplification, il est supposé dans le cadre de la présente invention que tous les paquets transmis sont reçus soit directement, soit indirectement à la suite de retransmission. Le client n'a donc pas à traiter des pertes de paquets, mais uniquement des erreurs bits. De plus, il est supposé que chaque NALU est transportée dans un seul paquet. Il est donc supposé qu'elles ne seront jamais fragmentées. Enfin, il est supposé que les NALU ont été remises dans leur ordre de transmission par le client avant leur traitement qui est décrit par la suite. La présente description s'appuie sur le document de référence du standard H.264/SVC: « JVT-X201, Joint Draft ITU-T Rec H.264 I ISO/IEC 14496-10/amd. 3, Scalable video coding, Geneva, switzerland, 29 june, 5 July 2007. » La Figure 6a débute par l'étape d'évaluation 601 durant laquelle on teste si le « NALU header » est correct. En cas de réponse négative, on passe à la tentative de correction de ce « NALU header ». La réponse à la question de l'étape de correction 603 sera donc systématiquement oui. Lors de l'étape de vérification 605, on vérifie le champ du NALU header de 1 bit appelé Forbidden_zero_bit. Ce champ doit systématiquement être à 0. Si ce n'est pas le cas, on le corrige lors de l'étape de correction 607, puis on vérifie à l'étape 609 avec le CRC correspondant au NALU header, si cette correction permet d'obtenir un NALU header correct (étape 613). Si cette correction n'est pas suffisante ou si le champ forbidden_zero_bit était égal à 0, on poursuit avec l'étape de vérification 615. Lors de cette étape de vérification, on vérifie la valeur du champ de 5 bits nal_unit_type. Ce champ doit prendre des valeurs spécifiées par la norme H.264/SVC comprises entre 1 et 15 ou les valeurs 19 ou 20. Toute autre valeur est incorrecte. Si une valeur incorrecte est détectée, alors on tente de corriger ce champ en lui affectant toutes les valeurs possibles de nal_unit_type (étape 617). A chaque tentative, on vérifie la qualité de la correction avec le CRC (étapes 619 et 621). Si l'une des valeurs de nal_unit_type permet de corriger le NALU header, la procédure de correction se termine (étape 623). Sinon, si aucune valeur ne permet de corriger le NALU header, alors l'erreur détectée est considérée comme irrécupérable (étape 625) et la NALU sera rejetée et non acquittée, ce qui déclenchera sa retransmission par le serveur. Si le nal_unit_type prend une valeur spécifiée par la norme, on passe à l'étape de vérification 627. On vérifie alors le champ de 2 bits nal_ref idc. Si ce champ est égal à 0, alors on teste la cohérence avec nal_unit_type lors de l'étape d'évaluation 629. Si nal_unit_type =7 ou 8 ou 13 ou 14 ou 15 ou 5 alors ce champ ne devrait pas être à 0. On poursuit alors par la correction de nal_ref idc lors de l'étape de correction 631. On teste alors toutes les valeurs possibles de nal_ref idc. A chaque tentative, on vérifie si la correction permet de corriger le NALU header. Si on obtient un NALU header correct par cette correction, alors on arrête la procédure de correction. Sinon, on estime que l'erreur ne peut être corrigée et que la NALU doit être retransmise. Si lors de l'étape de vérification 627, nal_ref idc est différent de 0, alors on vérifie la cohérence avec la valeur de nal_unit_type. Lorsque nal_ref idc est différent de 0, alors nal_unit_type ne peut pas prendre les valeurs 6, 9, 10, 11, et 12 (étape 639). Si tel est le cas, alors on fixe la valeur de nal_ref idc à 0 (étape 641) et on passe à la vérification du GRC. Si nal_ref idc est différent de 0, et que nal_unit_type est égal à 1, 2, 3, 4, 19, ou 20 (vérification lors des étapes 639 et 629), alors on fixe par défaut nal_ref idc à 0. On poursuit ensuite avec l'étape 633 déjà expliquée ci-dessus. Si le NALU header est correct, on peut passer à l'analyse du « SVC extension header ». Nous poursuivons donc selon la représentation de la Figure 6b, avec l'étape de vérification 645 qui vérifie si le « SVC extension header» est correct. Si c'est le cas, on passe à l'étape 647 qui met fin au processus de correction des header de NALU. Dans ce cas, la NALU concernée ne sera pas rejetée du fait d'erreurs dans son entête. Dans le cas d'erreurs dans le SVC extension header, on poursuit avec l'étape de correction 649 au cours de laquelle on corrige le bit « reserved one bit » si nécessaire. Ce bit doit systématiquement être à 1. Si ce n'est pas le cas, on le corrige (651). On passe ensuite à la vérification par le GRC (653). Si la vérification est positive, on conclut que seul le bit « reserved one bit » était erroné et qu'après correction de ce bit, la valeur du header est correcte. La procédure de correction s'arrête alors à l'étape 657, la NALU ne sera pas rejetée du fait d'erreurs dans son entête. Si la correction de ce bit n'a pas permis de corriger l'entête, ou si le bit était correct, on passe à l'analyse du drapeau « idr_flag ». Si ce drapeau (« flag ») est différent de 0 (659), on vérifie lors de l'étape de vérification 661 que nal_ref idc=0 dans l'entête de NALU. Si oui, alors l'idr_flag aurait du être à 0. On le corrige lors de l'étape de correction 671. Si nal ref idc est différent de 0, on vérifie que la NALU courante est de type filler prefix nalu, cette information étant indiquée par le champ nal unit type de l'entête NALU. Si c'est le cas, alors cette fois encore nal_ref idc aurait du être à 0. On le corrige lors de l'étape de correction 671. Si la NALU n'est pas de type filler prefix nalu, on vérifie qu'elle est de type VCL prefix nalu lors de l'étape de vérification 667. Si c'est le cas, on vérifie que la NALU associée (la NALU qui suit la NALU courante dans l'ordre de réception) est de type 5 (669). Si c'est le cas, alors idr_flag aurait du être à 0. On le corrige lors de l'étape de correction 671. Si idr flag=0, on vérifie que la NALU courante est de type VCL prefix nalu. Si c'est le cas on vérifie que la NALU associée à ce préfixe (la NALU qui suit la NALU courante dans l'ordre de réception) est de type 1 (nal_unit_type=l ) (673). Si c'est le cas, alors l'idr_flag aurait du être à 1. On le corrige lors de l'étape de correction 679. Si les conditions des étapes 663, 661, 665, 667, 669 et 673 ne sont pas vérifiées alors on passe à l'étape de vérification 675. Le standard H.264/SVC spécifie que toutes les NALU d'un même niveau spatial dans une même image doivent avoir le même idr_flag. Lors de l'étape de vérification 675, on vérifie donc que la NALU courante et la NALU précédente appartiennent à la même image dans le même niveau spatial. Pour cela on utilisera le timestamp RTP pour déterminer que l'on est dans la même image et le champ Did pour déterminer que l'on est dans le même niveau spatial. On supposera ici, que le champ Did de la NALU courante est correct. Si la condition d'appartenance à la même image dans le même niveau spatial est vérifiée, alors on copie l'idr_flag de la NALU précédente (677). Si aucune des conditions précédentes ne sont vérifiées, on donne la valeur 0 par défaut à idr_flag. Une fois la tentative de correction de l'idr_flag terminée, on passe à la vérification par le GRC. Si cette vérification est concluante, la procédure de correction s'arrête. Si ce n'est pas le cas on poursuit avec l'étape d'évaluation 687. Lors de l'étape d'évaluation 687, on teste si le champ no_inter layer_prediction_flag=0. Si c'est le cas, on vérifie que la NALU courante est de type VCL prefix nalu (689). Si c'est le cas, alors le bit no_inter_layer_prediction_flag aurait du être à 1. On le corrige lors de l'étape 697. Si no_inter_layer_prediction_flag est différent de 0, on vérifie lors de l'étape de vérification 685 que la NALU courante est de type 20 et que le champ Qid est supérieur à 0. On supposera ici que Qid est correct. Dans ce cas, no_inter_layer_prediction_flag aurait du être à 0. On le corrige lors de l'étape de correction 693. Si aucune des conditions 685 et 689 ne sont vérifiées, on fixe la valeur de no_inter_layer_prediction_flag à 691. Ces étapes sont suivies par la vérification par le CRC. Si celle-ci est concluante, la procédure de correction se termine à l'étape 699. Sinon, on poursuit avec l'étape de vérification 701 dans la Figure 7. Lors de l'étape de vérification 701, on vérifie que le timestamp RTP du paquet courant (noté timestamp dans la Figure 7) est égal au timestamp RTP du paquet précédent (noté timestamp_). Si c'est le cas, les deux NALU appartiennent à la même image. Dans ce cas, on fixe le champ Tid à la valeur du Tid de la NALU précédente (703), le champ Did à la valeur du Did de la NALU précédente et le champ Qid à la valeur du Qid de la NALU précédente. On passe alors à la vérification du CRC. Si cette vérification est positive on arrête la procédure de correction à l'étape 719. Sinon, on passe à l'étape 709 où l'on fixe la valeur de Qid à la valeur de Qid de la NALU précédente + 1. De nouveau, on passe à la vérification par le CRC. Si cette vérification est négative, on passe à l'étape 711 au cours de laquelle on fixe la valeur de Did à la valeur de Did de la NALU précédente + 1. On fixe ensuite Qid à 0 (étape 713). De nouveau on passe à la vérification par le CRC. Si cette vérification est négative on poursuit avec l'étape 801 de la figure 8. Si la NALU courante et la NALU précédente ont des timestamp différents, on passe à l'étape d'évaluation 721. Lors de cette étape on va tester alternativement plusieurs valeurs de Tid (Tid=Tid_, Tid=Tid_+1, Tid=O). Pour chacune de ces valeurs on fixe lors de l'étape 723 Did à la valeur minimale prise par Did dans le niveau temporel Tid. On suppose ici que pour obtenir cette information, le client a reçu et décodé le scalable SEI message (« Supplemental Enhancement Information ») contenant une description de la structure du flux SVC. Lors de l'étape 725, on fixe Qid à 0. On passe ensuite à la vérification par le CRC. Si cette vérification échoue, on poursuit avec l'étape 801 indiquée sur la Figure 8. Lors de l'étape 801, on inverse la valeur du champ use_ref base_pic_flag puis on vérifie l'impact de cette modification avec le CRC. Si cette modification n'est pas concluante, use_ref base_pix_flag reprends sa valeur initiale. De la même manière, on tente de corriger les champs discardable flag et output_flag en les inversant. On remarque que ces trois derniers champs sont totalement indépendants entre eux et de tout autre champ. On ne peut donc leur donner que des valeurs par défaut. On peut noter qu'ici nous avons tenté de corriger successivement les champs use_ref base_pic_flag, discardable flag et output_flag. Nous aurions tout aussi bien pu tenter de les corriger conjointement en testant pour ces trois champs de un bit, toutes les valeurs possibles de trois bits. Si l'une de ces inversions permet d'obtenir un header correct, on arrête la procédure de correction. Si aucune modification précédente ne permet de corriger le header, on vérifie la valeur de reserved_three_2bits. Ce champ devant être systématiquement à 3, si ce n'est pas le cas on le corrige. Si cette dernière vérification ou correction ne permet pas d'obtenir un header correct, le « SVC extension header » est déclaré définitivement incorrigible. Le paquet sera alors rejeté. On peut aussi noter que certaines décisions prises lors de cette procédure de correction sont des décisions fermes motivées par des incohérences de syntaxe alors que d'autres décisions sont des décisions par défaut. Les décisions par défaut sont prises lorsqu'aucun élément de syntaxe ne permet d'assurer qu'un champ donné doit prendre une valeur plutôt qu'une autre. On pourrait imaginer une mise en oeuvre avec une recherche exhaustive qui pourrait être réalisée sur toutes les valeurs possibles des champs pour lesquelles on a donné une valeur par défaut. Les champs ayant fait l'objet d'une décision ferme ne seront alors pas considérés. L'avantage est alors de réduire la complexité d'une recherche exhaustive complète. La Figure 9 représente un dispositif client 101 et un dispositif serveur 102 selon la présente invention. Le dispositif client 101 comporte une mémoire morte ou ROM 903, une mémoire vive ou RAM 904, un processeur ou CPU 902, un disque dur 906, et une interface de communication 905. Ces éléments sont reliés par un bus interne 910. Des périphériques : un écran 912 et un clavier 911 sont reliés au dispositif client 901. Le dispositif client 101 est connecté à un réseau de communication 100 par une interface de communication 905. Le dispositif serveur 102 comporte également une mémoire morte ou ROM 1003, une mémoire vive ou RAM 1004, un processeur ou CPU 1002, un disque dur 1006 reliés par un bus interne 1010. Le dispositif serveur 102 comporte également une interface de communication 1005 connecté au réseau de communication 100. L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet. REVENDICATIONS1. Procédé de détection d'erreurs dans un message de données (200), mis en oeuvre au sein d'un réseau de communication (100) adapté pour transférer des données et reliant un dispositif client (101) et un dispositif serveur (102), ledit message de données (200) comprenant une pluralité de champs (203) chacun protégé par un code de type CRC (Contrôle de Redondance Cyclique) individuel (204, 205), ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes : - construction d'un code CRC global à partir desdits codes CRC individuels (204, 205) ; - vérification de la présence éventuelle d'erreurs dans ledit message de données (200), en utilisant le code CRC global construit ; et - en cas de présence d'erreur, localisation des champs du message (200) comportant une erreur en utilisant lesdits CRC individuels (204, 205). 2. Procédé de détection d'erreurs dans un message de données (200) selon la revendication 1, caractérisé en ce que, lorsque le format d'au moins un champ du message de données (200) est conforme à un protocole de communication prédéterminé, le procédé comprend en outre une étape de vérification de la conformité du format dudit champ au protocole prédéterminé. 3. Procédé de détection d'erreurs dans un message de données (200) selon la revendication 1, caractérisé en ce que, lorsque des erreurs ont été localisées dans un champ du message dont le format est conforme à un protocole de communication prédéterminé, ledit procédé comprend en outre une étape de correction (508, 509) dudit champ sur la base de plages de valeurs possibles définies par ledit protocole prédéterminé. 4. Procédé de détection d'erreurs dans un message de données (200) selon l'une au moins des revendications 1, 2 ou 3, caractérisé en ce qu'il comporte en outre les étapes suivantes :- application d'une correction d'erreurs basée sur la connaissance de messages de type NALU (« Network Abstraction Layer Unit ») non corrompus et déjà reçus ; - application d'une correction d'erreurs basée sur la prédiction de 5 messages de type NALU (« Network Abstraction Layer Unit ») ; - application d'essais successifs de correction par remplacement des valeurs corrompus de champs à partir des valeurs des mêmes champs dans les NALU obtenues selon les deux étapes précédentes ; - calcul d'un CRC individuel sur chacune des nouvelles valeurs 10 desdits champs à l'issue de chaque essai ; et - comparaison du nouveau CRC individuel calculé au CRC individuel dans le message reçu. 5. Procédé de détection d'erreurs dans un message de données 15 (200) selon l'une au moins des revendications 1 à 4, caractérisé en ce que, lorsque des erreurs ont été localisées dans au moins un champ dudit message de données (200), ledit procédé comprend en outre les étapes suivantes : - détermination de l'importance d'un champ erroné ; et - demande de retransmission de la totalité du message de données 20 (200) dans le cas où ledit champ erroné est important ou acquittement de la totalité du message de données (200) dans le cas où ledit champ erroné n'est pas important. 6. Procédé de détection d'erreurs dans un message de données 25 (200) selon l'une au moins des revendications 1 à 5, caractérisé en ce que l'étape de vérification de la présence éventuelle d'erreurs dans ledit message de données (200), comprend les étapes de: - calcul d'un CRC à partir de l'ensemble des champs du message réunis; et 30 - comparaison du CRC calculé avec le CRC global construit; la présence d'erreurs étant ainsi détectée lorsqu'il existe une différence entre les deux CRCs. 7. Dispositif de communication (101) apte à détecter des erreurs dans un message de données (200) comprenant une pluralité de champs (203) chacun protégé par un code de type CRC (Contrôle de Redondance Cyclique) individuel (204, 205), ledit dispositif comprenant des moyens pour : - construire un code CRC global à partir desdits codes CRC individuels (204, 205) ; - vérifier la présence éventuelle d'erreurs dans ledit message de données (200), en utilisant le code CRC global construit ; et - en cas de présence d'erreur, localiser des champs du message (200) comportant une erreur en utilisant lesdits CRC individuels (204, 205). 8. Dispositif de communication (101) apte à détecter des erreurs dans un message de données (200) selon la revendication 7, caractérisé en ce qu'il comporte, lorsque le format d'au moins un champ du message de données (200) est conforme à un protocole de communication prédéterminé, des moyens pour vérifier la conformité du format dudit champ au protocole prédéterminé. 9. Dispositif de communication (101) apte à détecter des erreurs dans un message de données (200) selon la revendication 8, caractérisé en ce qu'il comporte, lorsque des erreurs ont été localisées dans un champ du message dont le format est conforme à un protocole de communication prédéterminé, des moyens pour corriger ledit champ sur la base de plages de valeurs possibles définies par ledit protocole prédéterminé. 10. Dispositif client d'un réseau de communication comportant des moyens adaptés à mettre en oeuvre le procédé conforme à l'une des revendications 1 à 6. 11. Programme d'ordinateur chargeable dans un système informatique, ledit programme comprenant des instructions permettant la mise30en oeuvre du procédé de détection d'erreurs selon l'une des revendications 1 à 6, lorsque ce programme est chargé et exécuté par un système informatique.