FR2964520A1 - Method for detecting errors in data message within communication network, involves verifying presence of errors in data message and locating message fields comprising error by using individual CRC codes in case of presence of error - Google Patents

Abstract

The method involves constructing a global cyclic redundancy check (CRC) code from individual CRC codes (204, 205), and verifying presence of errors in a data message by using the constructed global CRC code. Message fields (200) with error are located by using the individual CRC codes in case of presence of error. Conformity of format of one of the fields to preset protocol is verified when the format of the data message field is conformed to a preset communication protocol. Independent claims are also included for the following: (1) a communication device for detecting errors in a data message (2) a client device of a communication network, comprising units for implementing a method of detecting errors in a data message (3) a computer program downloadable in a computer system, comprising instructions for implementing a method of detecting errors in data message.

Description

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. The present invention relates to a method for detecting errors in a data message, implemented within a communication network. In general, the present invention relates to the field of Information and Communication Technologies.

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. The present invention relates more particularly to the transport of multimedia data in TCP-IP ("Transmission Control Protocol" and "Internat Protocol") type packet communication networks, these networks possibly being local or not. In particular, the present invention relates to the field of locating bit errors in corrupted packets when broadcasting audio-video contents by the TCP transport protocol over a radio communication network. As part of the TCP transport protocol, a packet carrying application data may contain various fields having different functions. The different fields of the packet may contain packet structure information, semantics information on the packet data, or pure data information. These fields have different importance depending on the function they perform. Similarly, a packet may be more or less important than the packets that precede it or those that follow it. A packet will, when transmitted over an untrusted communication network such as wireless networks using radio transmission techniques, frequently suffer unwanted changes due to transmission errors. In case of occurrence of such errors on one or more fields of the packet, it may be useful to perform a detection and correction process for these errors, which may be differentiated according to the function of the corrupted field.

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. One known means in the state of the art for implementing these field-differentiated treatments of a packet is the insertion protection of a redundancy information item calculated on the packet field, for example of the CRC type. Cyclic Redundancy or Cyclic Redundancy Check). This type of mechanism makes it possible to detect the presence of an error in the field, then to possibly be able to determine the correct correction treatment to be applied to a specific field according to the presence or absence of errors, and differentiated according to the function of the specific corrupted field.

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. In the context of the transmission of multimedia streams over the Internet or over local area networks (LANs), a content server, in the form of multimedia data, provides one or more data streams (of video type, audio, text (ie subtitles), ...) to one or more client devices. The latter receive and consume these data as and when they are received. For example, the client device plays video and audio as it receives them. This is called "multimedia streaming". In order to limit the data rate and obtain data rates compatible with the underlying network speed, these different data streams are generally compressed, for example for video according to ISO / IEC JTC1 MPEG 2 or MPEG 4 compression standards. or ITU-T H.264 / SVC. More and more equipment available to the general public is able to send such data streams, such as camcorders, cameras, video surveillance cameras, NAS (Network Attached Storage), home video servers, video receivers, television, computers, phones. Multimedia streams (video, audio, text) intended to be sent can be stored and compressed in advance on the transmitting device or, on the contrary, be captured, compressed in the water and sent to a communication network at destination. of a receiving device.

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. These multimedia streams consist of data (images, portions of images ("slices") or portions of sounds ("samples")) whose useful life is limited, that is to say that these data must imperatively received and processed by the receiving device before a certain deadline. This deadline corresponds to the moment when the data is required to be displayed or played by the customer. Beyond this deadline, the data becomes useless and must simply be ignored by the customer. In the event of an error during the transmission detected after receiving processing, the client may use an error correction method and in case of failure, if the deadline permits, ask the data server for retransmission of the packet. These multimedia streams are transmitted over communication networks consisting of interconnection nodes (routers, switches, etc.) in order to route the data packets from the source devices to the recipient devices. In the case of local networks, wireless networks of the "WI-Fi" type based on the IEEE 802.11 standard set are increasingly predominant and are favored by the general public because of their ease of implementation despite disadvantages inherent to the nature of the radio physical medium that can cause a variation in the useful rate and a high and variable transmission error rate. One of the problems is that of optimizing the performance (execution speed) in the receiver of the error detection process globally in the packet and locally in the larger fields of this packet, using the CRCs associated, especially when trying to locate errors on a large number of fields of the package. This optimization of the performance of the error detection process makes it possible to optimize the choice between several error recovery methods, by rejection of the packet, by a method related to the image compression method, or by a request of retransmission of the packet. It is known from International Patent Application No. WO 2009/076371 (Qualcomm) "Hierarchical CRC Scheme", a method in which a hierarchical CRC (Cyclic Redundancy Check) type code is constructed from two message portions (a first and a second) sent from a transmitting device. The system in which this hierarchical CRC code is implemented includes a transmitter that provides two different information to a plurality (two or more) of receivers. These receivers do not know the first portion, but one of the receivers is already informed of the second portion. A CRC is calculated on both portions of the message and provides protection (error detection). The receiver which is informed of the second portion uses this prior knowledge to benefit from a more powerful detection on the first portion because this second portion is then used in the calculation of a CRC of greater length. Unlike the above-mentioned international patent application, the present invention aims to optimize the performance (execution speed) of the error detection process globally in the packet and locally in the larger fields of the packet. using the associated CRCs, with a single type of receiver. For this purpose, the present invention relates to a method for detecting errors in a data message, implemented within a communication network adapted to transfer data and connecting a client device and a server device, said message of data comprising a plurality of fields each protected by an individual CRC (Cyclic Redundancy Check) type code, said method being characterized in that it comprises the following steps: - constructing a global CRC code from said individual CRC codes ; checking for the possible presence of errors in said data message by using the global built CRC code; and in the case of an error, locating the fields of the message containing an error using said individual CRCs. The method according to the present invention allows the reuse of the same field of CRC bits on the one hand for a global use allowing the detection of error in any part of the message on which this global CRC has been calculated and of on the other hand for a local use of locating these errors in at least one of the data bit fields constituting this 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. This is particularly advantageous for a system equipped with hardware means for calculating global CRCs over the whole of a message, over a field of fixed width in number of bits, where the individual CRC calculations would be of variable size and therefore should be The additional advantage of the method according to the present invention is to remain compliant with the TCP protocol. The method according to the present invention allows the reuse of a field defined by the TCP standard and will be compatible with a large number of existing devices ignorant of the invention, such as client terminals, gateways and proxy servers and others. network infrastructure equipment. Only some end devices implement the method according to the present invention. It is possible for the server and the client (receiver) of the TCP message to agree on the use of a non-standard algorithm for calculating the field named "TCP checksum" or "TCP checksum" in English terminology, part of the TCP header and two bytes long. This field contains by default a 16-bit value corresponding to a checksum (or "checksum" in English terminology) calculated over the entire TCP message (after removal of the level 2 fields and a part of the level fields 3). According to the method according to the present invention, after an exchange between client and server, the TCP checksum ("TCP checksum") is replaced by a plurality of individual CRCs calculated independently on individual data fields corresponding to parts of the TCP message. .

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. According to one embodiment, when the format of at least one field of the data message conforms to a predetermined communication protocol, the method further comprises a step of checking the conformity of the format of said field to the predetermined protocol. According to one embodiment, when errors have been located in a message field whose format conforms to a predetermined communication protocol, said method further comprises a step of correcting said field on the basis of ranges of possible values. defined by said predetermined protocol The verification of the conformity of the format provides an error detection means in the field of the message. This means can be complementary when the field is already protected by the CRC (but the latter has not detected errors). This means is particularly useful when the field in question is not protected by an individual CRC. According to a particular embodiment, said method further comprises the following steps: applying an error correction based on the knowledge of messages of the Network Abstraction Layer Unit (NALU) type that are not corrupted and already received; - application of an error correction based on the prediction of NALU ("Network Abstraction Layer Unit") type messages; - applying successive correction tests by replacing the corrupt values of fields from the values of the same fields in the NALUs obtained according to the two preceding steps; calculating an individual CRC on each of the new values of said fields at the end of each test; and - comparing the new individual CRC calculated to the individual CRC in the received message. Thus, the method according to the invention allows successive attempts to correct the corruptions of the received message and avoid retransmission by the server, decreasing the bandwidth used for this video stream and the transmission latency. According to one embodiment, when errors have been located in at least one field of said data message, said method further comprises the following steps: determining the importance of an erroneous field; and - retransmission request of the entire data message in the case where said erroneous field is important or acknowledgment of the entire data message in the case where said erroneous field is not 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. The method according to the invention thus makes it possible to reduce the cases in which a data message will be retransmitted while the application is capable of using this data message. The bandwidth consumed on the network between transmitter and receiver for the communication of messages is thus reduced. A message will also have a transmission waiting time that will be lower, especially in wireless networks where the occurrence of bit error in transmission is of greater probability. In the case of a message acknowledgment, the received message may be destroyed. Thus, according to the transport protocol of the message, it can be automatically retransmitted by the transmitter by detecting the absence of acknowledgment without further action on the part of the message receiver. Another aspect additional to the above method corresponds to the application to a TCP message comprising fields of various natures and of various importance, such as for example the case where the data transported in the useful part of the TCP message correspond to control fields. and data for a video stream formatted according to the ISO / IEC JTC1 H264 / SVC standard and transported in packets according to the principles of the document "RTP payload format for SVC video" draft-ietf-avt-rtp-svc-20.txt. The proposed method makes it possible, by prior knowledge by the TCP client of the formatting of the useful part of the RTP message included in the data part of the TCP message, to evaluate the relative importance of the various fields, and to avoid a retransmission of messages. to the server in case of error detection in one of these fields. According to a particular mode of implementation, the step of verifying the possible presence of errors in said data message comprises the steps of: calculating a CRC from the set of fields of the message together ; and - comparison of the calculated CRC with the overall CRC constructed; The presence of errors is thus detected when there is a difference between the two 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. The present invention also relates to a communication device capable of detecting errors in a data message comprising a plurality of fields each protected by an individual CRC type code (Cyclic Redundancy Check), said device comprising means for: constructing a global CRC code from said individual CRCs; - Check for possible errors in said data message using the global CRC code built; and - if there is an error, locate fields of the message containing an error using said individual CRCs. According to one embodiment, said device comprises, when the format of at least one field of the data message conforms to a predetermined communication protocol, means for verifying the conformity of the format of said field to the predetermined protocol. According to one embodiment, said device comprises, when errors have been located in a message field whose format conforms to a predetermined communication protocol, means for correcting said field on the basis of ranges of possible values defined by said predetermined protocol. According to one aspect of the present invention, the communication system between server and TCP client is a wireless network compliant with the IEEE 802.11 standard and its variations. According to this aspect, the MAC layer of the server and client interfaces are modified so that the frame checksum sequence completely covering the IEEE 802.11 frame only covers the header fields. ) MAC, IP, TCP and RTP protocols, thus allowing partially corrupted messages to be stored and transmitted to the client's different protocol layers and to implement the method according to the present 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. The present invention also relates to a client device of a communication network comprising means adapted to implement said method. The present invention also relates to a computer program loadable in a computer system, said program comprising instructions for implementing the error detection method. The invention will be better understood from the following description, given purely for explanatory purposes, of one embodiment of the invention, with reference to the appended figures: FIG. a multimedia data transport server in a wireless communication network; FIG. 2 represents the structure of an RTP / TCP / IP SVC message in an IEEE 802.11 frame; Figure 3 illustrates the structure of a message header according to the TCP protocol; - Figure 4 shows individual GRCs in the TCP checksum ("TCP checksum"); Figure 5 illustrates the reception processing of error detection and localization; FIG. 6a illustrates the correction processing of the NALU header; Figure 6b illustrates the correction processing of the NALU header extension for SVC; Figure 7 shows the correction processing of the header extension by use of several successive NALUs; Figure 8 illustrates further processing of the NALU header extension correction for SVC; and - Figure 9 shows a client device and a server device according to the present invention. A wireless radio local area network, for example of a type conforming to the IEEE 802.11 standard and its variants, constitutes the physical infrastructure network for transporting TCP / IP protocol messages exchanged between a server. and a client as shown in FIG. 1. In FIG. 1, a client 101 receives a stream of compressed and formatted audio-video messages for sending over the network according to a "Real Time Protocol" (RTP) protocol and control protocols. associated with (RTCP / RTSP) by a server 102. These messages are transported between the client 101 and the server 102 via a local network 100 such as those mentioned in the previous paragraph. The server 102 is for example a digital television decoder or any other type of device incorporating a means of storing audio-video content such as a personal computer or even an electronic device such as a camcorder, a digital camera or a multimedia hard drive, also called NAS (Network Attached Storage). It may also be an apparatus comprising a means of receiving such contents transported continuously via a second network, for example of a remote type such as an IPTV network (a "managed network"), a network access to the Internet, a mobile telecommunications network, or even a broadcast network, with broadcast provided by terrestrial, cable or satellite transmission of audiovisual content. The server 102 is capable of forming from this compressed audio-video content for example according to the standard ITU-T H.264-AVC with SVC extension (H.264 SVC is an amendment of H.264 AVC approved by the "ITU -T Video Coding Experts Group (VCEG) "and" International Standards Organization (ISO) MPEG "), a stream of messages conforming to RTP formatting, and capable of injecting this message flow on a previously established TCP logical connection. The radio transmission local area network 100 enables the transmission of this RTP message stream. The client 101 is a device connected to the local radio network 100, capable of receiving this RTP / TCP stream via its interface conforming for example to the IEEE 802.11 protocol and its variants. This device is for example a TV or a personal computer with a screen and means of audio and video reproduction for restoring the audiovisual content received in the RTP / TCP message stream via the IEEE 802.11 interface and its variants. It may also be a transcoding device (capable of decompressing the received stream and compressing the stream again according to the method described by another standard for image and audio compression different from that used for the received stream) or a network storage and streaming equipment for audiovisual content such as a multimedia hard disk, also called NAS (Network Attached Storage), for archiving content which is then transmitted in a RTP / TCP stream by the server 102 and received from a second network, of the remote type.

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. Figure 2 shows an IEEE 802.11 frame containing a TCP segment according to the invention. Thus, contrary to what is described in the IEEE 802.11 standard and its variants, the frame 200 is terminated by an FCS 210 field (FOS corresponds to "Prame Checksum Sequence") protecting only the fields 201, 202, 203 (including fields 204 and 205) and 206, instead of protecting all the bits of the transmitted frame according to the IEEE 802.11 standard and its variants. The fields 204 and 205 in the TCP header 203 correspond to the 16 bits of the TCP checksum. All frames and field bits of these frames when transmitted over the radio LAN are susceptible to errors and changes due to multiple causes. The FCS field generally contains a number computed by the source node based on the data contained in the IEEE 802.11 frame. This number is for example inserted at the end of the frame. When the destination node receives this frame, the FCS number is recalculated and compared to that received. In case of difference, a transmission error is supposed to have occurred without being able to locate it, the IEEE 802.11 receiver will then ignore this frame. The FCS field according to the IEEE 802.11 standard is a 32-bit field used for error detection during transmission and containing a 32-bit CRC. This CRC follows the rules of the IEEE standard and is calculated on all the fields of the MAC header and the body of the frame which are called calculation fields (which will also be called here protected area). In the context of the present invention; the FCS field is calculated in a manner identical to that described above, except that the 32-bit CRC is calculated only on certain headers of the frame. By doing so, bit errors that would occur in fields not protected by the FCS of the IEEE 802.11 frame will not be detected by the MAC layer. Thus, instead of being ignored as they would be in a standard case of implementation of the standard, these frames will be in the invention, transmitted to the upper layers, where, in particular, according to a particular embodiment of the invention, it will be take advantage of individual CRCs placed in fields 204 and 205 according to the principles described below. In the IEEE 802.11 standard, the MAC FCS 210 is calculated using the following standard generator polynomial G (X): G (x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 The FCS is the complement to one of the sum modulo 2 of the following elements: a) The rest of the modulo 2 division of xk (x31 + x3 ° + x29 + .... + x2 + x + 1) by G (x), where k is the number of bits of the computation field b) The remainder after multiplication of the contents of the protected area (calculation field, treated as a polynomial) by x32 and then divided by G (x ). The FCS field itself is transmitted starting with the coefficients of the highest ranking terms.

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. In a typical IEEE 802.11 emitter-side implementation, the initial remainder is set to one for all bits and then modified by dividing the protected area (calculation fields) by the generator polynomial. The remainder of one of the remainder is transmitted with the most significant bit first as the FCS field of an IEEE 802.11 frame.

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. On the receiver side, the initial remainder is initialized with all the bits at one. The bits received in series of the fields of the protected zone then of the FCS, after division by G (x) correspond in case of absence of transmission error to a single non-zero remainder, which is the following polynomial: 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. FIG. 3 represents the detail of the fields of the TCP header 203 of FIG. 2. The present invention uses in a particular way the corresponding zone in the TCP segment at the TCP checksum in the field. 301. In IETF RFC 793, the basic principles of TCP over IPv4 are described. This RFC thus gives the principles of calculation of this TCP checksum with, in the case of the transport of TCP over IPv6, modifications on this method of calculation described by the RFC 2460. But it is also indicated that according to a conventional method of signaling between the server and the client, the TCP checksum can be calculated according to a known non-standard method of both ends, known by the client and server linked by this TOP connection. The invention takes advantage of this possibility for the filling of the field 301 of the TCP header 203. FIG. 4 represents a set of two data zones 400 and 401 to be protected among the fields of the message 200, which will be the calculation fields. for the two CRC respectively 204 and 205 which constitute the bits of the field 301 "TCP checksum" (checksum TOP) according to the invention. According to one embodiment, these zones 400 and 401 correspond, for example, to the field 207 "NALU header" on the one hand and, on the other hand, to the "SVC extension header" field 208 attached to the field 209 containing the macro-data blocks. image of this NALU. A possible variant for the zone 401 is to cover also the field 208 but only a part of the field 209. In a polynomial representation of the zones 400 and 401, it is possible to write for messages 400 and 401 respectively comprising the bits a0, a1,. .., ap_1 and the bits bo, b1, bk-1 A (X) = a °, a1 x + ... + ap-1 xp 1 and B (X) = bo + b1 x + ... + bk -1 x-1 M (x) which is constructed by concatenation of the zones 400 and 401 can be written: - M (X) = xk A (x) + B (X) The CRC on the complete area M (x) is the remainder of the division of the polynomial M (x) by a generator polynomial (CRC polynomial) G (x), after shifting to the left with insertion of bits at 0, for a number of bits corresponding to the 16 bits of the " TCP checksum "(TCP checksum). We then write M (x) xdegree (G (x)) = Q (x) G (x) + R (x) or else R (x) = M (x) 10 xdegree (G (x)) + Q (x) X) G (X) The 16-bit CRC on the polynomial M (x) is - CRC_M (x) = [M (x) xdegree (G (x))] Modulo G (x) because (CRC_M (x)) Modulo G (x) = CRC_M (x) and (Q (x) G (x)) Modulo g (x) = 0 The polynomial B (x) is k bits, CRC_M (X) = [xk + degree ( G (x)) A (x) Modulo G (x) + [xdeg (G (x)) B (x) Modulo G (x). Using the foregoing developments, the global CRC on M (x) can be linked to the individual CRC respectively covering the error detection in the two areas A (x) and B (x) (field 207 for A (x) and fields 208, 209 for B (x) CRC M (x) = [xk CRC A (x)] Modulo G (x) + CRC B (x) where the lower-order expression simpler to calculate: CRC_M ( x) = [(xk Modulo G (x)) CRC_A (x)] Modulo G (x) + CRC_B (x) 25 Where G (x) is an 8-bit generator polynomial used for the calculation of CRC individual CRC A and CRC B. The TCP server 102 calculates the individual CRCs 204 and 205 on the basis of a generator polynomial according to the principles known to those skilled in the art, these CRCs are calculated on the field 207 on the one hand and the fields on the other hand respectively. 208, 209 on the other hand, a number of k consecutive bits of 208, 209 is taken into account for the calculation of CRC_A 204. This number k is known and fixed for the server TCP 102 and its client 101. A number of bits p is taken into account for the calculation of the CRC_B 205. These two individual CRCs 204 and 205 are concatenated and placed in the "checksum TCP" field (TOP checksum) of the TCP header 203. The TCP segment carries a RTP stream element which itself contains a container called Network Abstraction Layer Unit (NALU) containing compressed video data according to the H.264 / SVC standard. The NALU container consists of a Network Abstraction Layer Header (NALH) and a payload part containing the video data.

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. This TCP segment thus constituted is transmitted on the LAN radio network 100. During transport, this segment is susceptible to undergo alterations due to radio phenomena. Figure 5 shows the processing performed at the reception for error detection and localization.

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). In a receive step 500, the TCP Client 101 receives a TCP segment included in an IEEE 802.11 frame. If a bit corruption has occurred in one of the fields 201, 202, 203, this corruption is detected by the IEEE 802.11 MAC layer, the frame is ignored and will be automatically retransmitted. In the opposite cases, either the frame has not been corrupted or it has occurred in a field not protected by the FCS field 210 such as fields 207 to 209. The frame is then propagated within the frame. client network interface to the particular TCP layer of the invention. The invention proposes to process in this layer, the detection and localization of errors and possibly the correction of certain cases of corruption and thus avoid the retransmission of certain segments. In an evaluation step 501, in equipment designed for error detection performance optimization, the client uses a hardware means known to those skilled in the art which will allow a fast calculation of CRC global CRC_M 402 ( x) but only applying to calculations on fields of fixed size corresponding to the size of the field of fields 207 to 209. This CRC is calculated by dividing M (x) by the generator polynomial 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. At the end of global detection of a bit error due to the radio transmission, the client makes a comparison between this calculation and a second result obtained as follows. The client 101 of the invention obtains this second result by calculation according to the formula determined previously, and implemented according to principles known to those skilled in the art, from the values 403 CRC_A (x) and 404 CRC B (X ) received in fields 204 and 205 of the TCP segment under evaluation: CRC M (x) = [(xk Modulo G (x)) CRC A (x) Modulo G (x) + CRC B (x). This second result is then compared with the first result obtained by a hardware means adapted to the number of bits of the field area of the fields 207 to 209. It will be noted here that there are two ways to verify on reception that a message " M "protected by a CRC" C "contains or not errors. The CRC is the rest of the division of the message by a generator polynomial. A first way of checking is to take the received message M, redo the division by the same generator polynomial and compare the rest obtained with the received CRC. In case of equality, we consider that there are no errors. A second way of checking is to take the received message M and the received CRC together (in the form of a polynomial representation), to divide by the generator polynomial and to check whether the remainder obtained is zero or not. In the absence of errors, the rest should be zero since the initial remainder (CRC received) has already been taken into account. In case of equality, one can conclude in a step 502 to the absence of error. An acknowledgment as defined by the TCP protocol by means of an ACK message is then sent to the server and the TCP segment is transmitted within the client to the application portion which processes the RTP formatting and then to the video decoder in a known manner. skilled person. If there is a difference, an error exists in one of the fields. It should be located and assessed its criticality according to the corrupted field. According to the invention, an initialisation of an individual field counter is carried out during evaluation by using individual CRCs. Then, in a preferred embodiment in a step 504, the individual CRC is calculated by dividing the corresponding elementary field by the generating polynomial G (x), if in step 505 the remainder is equal to the value of GRC. received individually, proceed to step 507 where the individual field counter is incremented. In an evaluation step 517, if the counter designates the penultimate field protected by individual GRC, the error detected at the global level is therefore in the last field which is not considered critical and it is possible to send the segment to the H264 / SVC decoder for the corresponding processing and proceed to step 516 of acknowledging this received TCP segment with a non-fatal error.

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. If, at the verification step 505, the remainder is different, proceed to the verification step 506 where it is verified that the individual field counter corresponds to a NALU header field, if this is the case to a step 508 where a correction method described below is applied. A check step 510 is then checked whether the field counter corresponds to an extension header of the H264 / SVC standard, in which case it is proceeded to the correction step 509 where a correction method described below is applied. . We then check in a verification step 511 whether the field counter corresponds to a slice header, in which case it is considered that this error is not recoverable and this TCP segment is rejected by elimination in a step 513. a transmission step 514 according to a method known to those skilled in the art to the sending of three acknowledgments called Duplicated ACK according to the TCP standard. This causes the server to retransmit the corrupted TCP segment in a shorter amount of time than the typical wait time of a timer. This measurement, although known to those skilled in the art, makes it possible to compensate for the processing time of the various steps taken in FIG. 5. In a verification step 512, it is then checked whether the field counter designates a macro block data item and it is the last data item in the segment, if it is not the case it is also considered to be a critical data item and proceed to step 513 to reject the corrupted segment.

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. If this is the last data, it can proceed to the transmission step 515 within the client, where the data is sent to the decoder H264 / SVC for processing. The transmission step 516 is then followed to send a TCP acknowledgment to the server by means of an ACK message using the sequence number of the TCP segment received, before going back to 500 at the same time. waiting to receive the next TCP segment. Figures 6a and 6b show the processing of H264 / SVC data for error correction mentioned in correction steps 508 and 509 of 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. In the next section, we assume that each tested header is associated with an individual GRC for error detection. These GRCs make it possible to determine for each header whether it is wrong or not. We therefore describe more precisely here the steps 506, 508, 509 and 510 corresponding to the error correction attempt in the "NALU header" and the "SVC extension header". The goal is to try to regenerate correct headers so that the corresponding NALU can be transmitted to the client's decoder. For the sake of simplification, it is assumed in the context of the present invention that all transmitted packets are received either directly or indirectly as a result of retransmission. The client does not have to deal with packet loss, but only bit errors. In addition, it is assumed that each NALU is carried in a single package. It is therefore assumed that they will never be fragmented. Finally, it is assumed that the NALUs were delivered in their order of transmission by the client before their processing which is described later. This description is based on the H.264 / SVC standard reference document: "JVT-X201, ITU-T Rec. H.264 I ISO / IEC 14496-10 / amd Joint Draft. 3, Scalable video coding, Geneva, Switzerland, 29 june, 5 July 2007. "Figure 6a begins with the evaluation step 601 during which one tests whether the" NALU header "is correct. In case of a negative answer, we proceed to the attempt to correct this "NALU header". The answer to the question of the correction step 603 will therefore be systematically yes. During the verification step 605, the 1-bit NALU header field called Forbidden_zero_bit is checked. This field must always be 0. If it is not the case, it is corrected during the correction step 607, and then it is checked at step 609 with the CRC corresponding to the NALU header, if this correction makes it possible to get a correct NALU header (step 613). If this correction is not sufficient or if the field forbidden_zero_bit was equal to 0, we continue with the verification step 615. During this verification step, we check the value of the 5-bit field nal_unit_type. This field must take values specified by the H.264 / SVC standard between 1 and 15 or values 19 or 20. Any other value is incorrect. If an incorrect value is detected, then an attempt is made to correct this field by assigning all the possible values of nal_unit_type (step 617). At each attempt, the quality of the correction is checked with the CRC (steps 619 and 621). If one of the values of nal_unit_type is used to correct the NALU header, the correction procedure ends (step 623). Otherwise, if no value corrects the NALU header, then the detected error is considered unrecoverable (step 625) and the NALU will be rejected and unacknowledged, which will trigger its retransmission by the server.

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. If the nal_unit_type takes a value specified by the norm, we go to the verification step 627. We then check the 2-bit field nal_ref idc. If this field is equal to 0, then we check the consistency with nal_unit_type during the evaluation step 629. If nal_unit_type = 7 or 8 or 13 or 14 or 15 or 5 then this field should not be 0. then continues by the correction of nal_ref idc during the correction step 631. We then test all the possible values of nal_ref idc. At each attempt, we check if the correction corrects the NALU header. If we obtain a correct NALU header by this correction, then we stop the correction procedure. Otherwise, it is considered that the error can not be corrected and the NALU must be retransmitted.

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. If during the verification step 627, nal_ref idc is different from 0, then we check the consistency with the value of nal_unit_type. When nal_ref idc is other than 0, then nal_unit_type can not take the values 6, 9, 10, 11, and 12 (step 639). If this is the case, then set the value of nal_ref idc to 0 (step 641) and proceed to the verification of the GRC. If nal_ref idc is different from 0, and nal_unit_type is equal to 1, 2, 3, 4, 19, or 20 (check in steps 639 and 629), then we set nal_ref idc to 0 by default. step 633 already explained above. If the NALU header is correct, we can go to the analysis of the "SVC extension header". We continue then according to the representation of Figure 6b, with the verification step 645 which checks if the "SVC extension header" is correct. If so, proceed to step 647 which terminates the NALU header correction process. In this case, the NALU concerned will not be rejected due to errors in its header. In the case of errors in the SVC extension header, it continues with the correction step 649 during which the "reserved one bit" bit is corrected if necessary. This bit should always be 1. If it is not the case, it is corrected (651). The next step is to audit by the RCMP (653). If the check is positive, we conclude that only the "reserved one bit" bit was wrong and that after correcting this bit, the value of the header is correct. The correction procedure then stops at step 657, the NALU will not be rejected due to errors in its header.

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. If the correction of this bit did not correct the header, or if the bit was correct, we proceed to the analysis of the flag "idr_flag". If this flag ("flag") is different from 0 (659), it is verified during the verification step 661 that nal_ref idc = 0 in the NALU header. If yes, then the idr_flag should have been 0. It is corrected during the correction step 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. If nal ref idc is different from 0, we check that the current NALU is of type filler prefix nalu, this information being indicated by the field nal unit type of the NALU header. If this is the case, then this time again nal_ref idc should have been 0. It is corrected during the correction step 671. If the NALU is not of the filler prefix nalu type, we check that it is of the VCL prefix nalu type during the verification step 667. If this is the case, it is verified that the associated NALU (the NALU following the current NALU in the order of reception) is of type 5 (669). If this is the case, then idr_flag should have been 0. It is corrected during the correction step 671. If idr flag = 0, we check that the current NALU is of type VCL prefix nalu. If this is the case, we check that the NALU associated with this prefix (the NALU following the current NALU in the order of reception) is of type 1 (nal_unit_type = 1) (673). If this is the case, then the idr_flag should have been 1. It is corrected during the correction step 679. If the conditions of the steps 663, 661, 665, 667, 669 and 673 are not verified then we go to the 675 verification step. The H.264 / SVC standard specifies that all NALUs of the same spatial level in the same image must have the same idr_flag. During the verification step 675, it is therefore verified that the current NALU and the previous NALU belong to the same image in the same spatial level. For this we will use the timestamp RTP to determine that we are in the same image and the Did field to determine that we are in the same spatial level. It will be assumed here that the Did field of the current NALU is correct. If the condition of belonging to the same image in the same spatial level is verified, then copy the idr_flag from the previous NALU (677). If none of the above conditions are true, default is 0 by idr_flag. Once the attempt to correct the idr_flag is complete, the RCMP will proceed to verification. If this check is successful, the correction procedure stops. If this is not the case, we continue with the evaluation step 687. During the evaluation step 687, we test whether the field no_inter layer_prediction_flag = 0. If this is the case, we check that the current NALU is of type VCL prefix nalu (689). If it is, then the no_inter_layer_prediction_flag bit should have been set to 1. It is corrected in step 697. If no_inter_layer_prediction_flag is other than 0, it is checked during the check step 685 that the current NALU is type 20 and that the field Qid is greater than 0. It will be assumed here that Qid is correct. In this case, no_inter_layer_prediction_flag should have been 0. It is corrected during the correction step 693. If none of the conditions 685 and 689 are checked, the value of no_inter_layer_prediction_flag is set to 691. These steps are followed by the verification by the CRC. If it is conclusive, the correction procedure ends in step 699. Otherwise, the check step 701 is continued in FIG. 7. During the verification step 701, the RTP timestamp is checked. of the current package (noted timestamp in Figure 7) is equal to the RTP timestamp of the previous packet (noted timestamp_). If so, both NALUs belong to the same image. In this case, the field Tid is set to the value of the Tid of the preceding NALU (703), the field Did to the value of the Did of the preceding NALU and the field Qid to the value of the Qid of the preceding NALU.

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. We then go on to audit the CRC. If this verification is positive, the correction procedure is stopped in step 719. Otherwise, step 709 is set where the value of Qid is set to the value of Qid of the preceding NALU + 1. Again, we go to audit by the CRC. If this check is negative, we go to step 711 during which we set the value of Did to the value of Did of the previous NALU + 1. We then set Qid to 0 (step 713). Again we go to CRC verification. If this verification is negative, proceed with step 801 of FIG. 8. If the current NALU and the preceding NALU have different timestamps, the evaluation step 721 is carried out. During this step, several tests will be carried out alternately. values of Tid (Tid = Tid_, Tid = Tid_ + 1, Tid = O). For each of these values is fixed during step 723 Did to the minimum value taken by Did in the time level Tid. It is assumed here that to obtain this information, the client has received and decoded the scalable SEI message ("Supplemental Enhancement Information") containing a description of the structure of the SVC stream. In step 725, Qid is set to 0. Next, the CRC checks. If this verification fails, continue with step 801 indicated in FIG. 8. In step 801, the value of the use_ref field base_pic_flag is reversed and the impact of this modification with the CRC is then checked. If this change is inconclusive, use_ref base_pix_flag resumes its initial value. In the same way, we try to correct the fields discardable flag and output_flag by inverting them. Note that these last three fields are completely independent of each other and any other field. We can therefore only give them default values. We note that here we tried to successively correct the fields use_ref base_pic_flag, discardable flag and output_flag. We could just as easily have tried to correct them together by testing for all three fields a bit, all the possible values of three bits. If one of these inversions makes it possible to obtain a correct header, one stops the procedure of correction. If no previous modification allows to correct the header, we check the value of reserved_three_2bits. This field must always be 3, if it is not the case it is corrected. If this last check or correction does not make it possible to obtain a correct header, the "SVC extension header" is declared permanently incorrigible. The package will be rejected. It can also be noted that some decisions made during this correction procedure are firm decisions motivated by syntax inconsistencies, while other decisions are decisions by default. Default decisions are made when there is no syntax element to ensure that one field should take one value over another. One could imagine an implementation with an exhaustive search which could be realized on all the possible values of the fields for which one gave a value by defect. Fields that have been the subject of a firm decision will not be considered. The advantage is then to reduce the complexity of a comprehensive exhaustive search. Figure 9 shows a client device 101 and a server device 102 according to the present invention. The client device 101 comprises a read-only memory or ROM 903, a random access memory or RAM 904, a processor or CPU 902, a hard disk 906, and a communication interface 905. These elements are connected by an internal bus 910. Devices: a screen 912 and a keyboard 911 are connected to the client device 901. The client device 101 is connected to a communication network 100 by a communication interface 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. The server device 102 also comprises a read-only memory or ROM 1003, a random access memory or RAM 1004, a processor or CPU 1002, a hard disk 1006 connected by an internal bus 1010. The server device 102 also comprises a communication interface 1005 connected to the communication network 100. The invention is described in the foregoing by way of example. It is understood that the skilled person is able to realize different variants of the invention without departing from the scope of the patent.

Claims (11)

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). REVENDICATIONS1. A method of detecting errors in a data message (200), implemented within a communication network (100) adapted to transfer data and connecting a client device (101) and a server device (102), said data message (200) comprising a plurality of fields (203) each protected by an individual CRC (Cyclic Redundancy Check) type code (204, 205), said method being characterized in that it comprises the following steps: constructing a global CRC code from said individual CRC codes (204, 205); checking for the possible presence of errors in said data message (200), by using the global constructed CRC code; and - in case of error, locating the message fields (200) having an error using said individual CRCs (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é. A method of detecting errors in a data message (200) according to claim 1, characterized in that when the format of at least one field of the data message (200) conforms to a predetermined communication protocol the method further comprises a step of checking the conformity of the format of said field to the predetermined protocol. 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é. A method for detecting errors in a data message (200) according to claim 1, characterized in that, when errors have been located in a message field whose format conforms to a predetermined communication protocol, said the method further comprises a step of correcting (508, 509) said field based on ranges of possible values defined by said predetermined protocol. 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. 4. A method of detecting errors in a data message (200) according to at least one of claims 1, 2 or 3, characterized in that it further comprises the following steps: - application of a correction of errors based on the knowledge of non-corrupt and already received NALU (Network Abstraction Layer Unit) messages; - application of an error correction based on the prediction of 5 messages of NALU type ("Network Abstraction Layer Unit"); - applying successive correction tests by replacing the corrupt values of fields from the values of the same fields in the NALUs obtained according to the two preceding steps; calculating an individual CRC on each of the new values of said fields at the end of each test; and - comparing the new individual CRC calculated to the individual CRC in the received message. 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. A method for detecting errors in a data message (200) according to at least one of claims 1 to 4, characterized in that, when errors have been localized in at least one field of said data message ( 200), said method further comprises the steps of: - determining the importance of an erroneous field; and - retransmitting request of the entire data message (200) in the case where said erroneous field is large or acknowledgment of the entire data message (200) in the case where said erroneous field is not 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. 6. A method for detecting errors in a data message (200) according to at least one of claims 1 to 5, characterized in that the step of checking for the possible presence of errors in said data message. (200), comprises the steps of: calculating a CRC from the set of message fields combined; and 30 - comparing the calculated CRC with the overall CRC constructed; the presence of errors is thus detected when there is a difference between the two 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). A communication device (101) adapted to detect errors in a data message (200) comprising a plurality of fields (203) each protected by an individual CRC (Cyclic Redundancy Check) type code (204, 205), said device comprising means for: - constructing a global CRC code from said individual CRC codes (204, 205); - checking the possible presence of errors in said data message (200), using the global CRC code built; and - if there is an error, locating fields of the message (200) having an error using said individual CRCs (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é. 8. Communication device (101) adapted to detect errors in a data message (200) according to claim 7, characterized in that it comprises, when the format of at least one field of the data message (200) is in accordance with a predetermined communication protocol, means for checking the conformity of the format of said field to the predetermined protocol. 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é. 9. Communication device (101) adapted to detect errors in a data message (200) according to claim 8, characterized in that it comprises, when errors have been located in a message field whose format is in accordance to a predetermined communication protocol, means for correcting said field on the basis of ranges of possible values defined by said predetermined protocol. 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. 10. Client device of a communication network comprising means adapted to implement the method according to one of claims 1 to 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. A computer program loadable into a computer system, said program comprising instructions for performing the error detection method according to one of claims 1 to 6, when the program is loaded and executed by a computer system.