26 Chapitre 2. Etat <strong>de</strong> l'art et principales notionsFigure 2.9 Matrice <strong>de</strong> l'enco<strong>de</strong>ur global Raptor pour k = 500 et n = 1000 symbolesgénérésposés au début l k symboles nuls. Au nal, ces l k premières colonnes sontinutiles. La matrice comporte une diagonale démarrant après les l k premières colonnes.Ceci vali<strong>de</strong> le caractre systématique du co<strong>de</strong> Raptor. La partie non-systématique <strong>de</strong> la matrice globale n'a pas <strong>de</strong> structure particulière.Toutes les informations concernant le décodage ecace <strong>de</strong>s co<strong>de</strong>s Raptor ne sontpas connues. Certains éléments permettent tout <strong>de</strong> même <strong>de</strong> comprendre le décodage<strong>de</strong> ces co<strong>de</strong>s.Le décodage <strong>de</strong>s symboles sources à partir <strong>de</strong>s symboles intermédiaires est unsimple "encodage" LT <strong>de</strong> complexité linéaire. Le point crucial du décodage est doncla récupération <strong>de</strong> tous ces symboles intermédiaires. Sur ce point, les algorithmes <strong>de</strong>décodage utilisés sont similaires à ceux <strong>de</strong>s co<strong>de</strong>s LDPC, à savoir un décodage itératif,un décodage ML, ou un mélange <strong>de</strong>s <strong>de</strong>ux. A ce sujet, une métho<strong>de</strong> <strong>de</strong> décodageparticulière a été brevetée [33] pour améliorer les performances d'un décodage ML parpivot <strong>de</strong> Gauss.Si le nombre <strong>de</strong> symboles intermédiaires est <strong>de</strong> l, n'oublions pas cependant queceux-ci sont liés par s + h relations entre eux, ce qui rend bien le décodage possibledès lors que k symboles ont été reçus.Les résultats <strong>de</strong> simulation que nous avons eectué sur la version standardisée <strong>de</strong>ces co<strong>de</strong>s ont montré que le nombre moyen d'extra-symboles nécessaires au décodage<strong>de</strong>s co<strong>de</strong>s Raptor était quasiment constant quel que soit la dimension du co<strong>de</strong>, et
2.3. La compression d'en-têtes 27<strong>pro</strong>che <strong>de</strong> 2. Ceci est en accord avec les résultats ociels [34] qui donnaient unnombre moyen d'extra-symboles <strong>pro</strong>che <strong>de</strong> 1; 96. L'intérêt majeur <strong>de</strong> ces co<strong>de</strong>s estdonc d'avoir un nombre d'extra-symboles moyen constant, et donc une inecacité <strong>de</strong>plus en plus <strong>pro</strong>che <strong>de</strong> l'optimal lorsque la dimension du co<strong>de</strong> augmente. Néanmoins,nous avons également pu vérier que ce nombre est sous-estimé lorsque les dimensions<strong>de</strong> co<strong>de</strong>s sont faibles (< 100), comme annoncé, ce qui laisse entrevoir que ces co<strong>de</strong>s,tout comme les co<strong>de</strong>s LDPC ne sont pas adaptés pour ces dimensions, et où l'onfavorisera les solutions <strong>de</strong> type Reed-Solomon ou Reed-Muller.N'ayant pas accès au décodage réellement utilisé sur ces co<strong>de</strong>s, et <strong>de</strong>vant nouscontenter d'une version standardisée <strong>de</strong> vitesse inférieure, nous n'avons pu comparerla vitesse <strong>de</strong> décodage <strong>de</strong> ces co<strong>de</strong>s par rapport à d'autres co<strong>de</strong>s. Sur ce point,la seule donnée existante <strong>pro</strong>vient <strong>de</strong> l'article original présentant ces co<strong>de</strong>s qui annonce: "The Raptor implementation of Digital Fountain reaches speeds of severalgigabits per second, on a 2.4-GHz Intel Xeon <strong>pro</strong>cessor, while ensuring very stringentconditions on the error <strong>pro</strong>bability of the <strong>de</strong>co<strong>de</strong>r, even for very short lengths." quine précise ni la dimension du co<strong>de</strong>, ni le type <strong>de</strong> décodage, ni un ordre <strong>de</strong> vitesse précis.En conclusion, les co<strong>de</strong>s Raptor représentent d'excellents co<strong>de</strong>s à eacements entermes <strong>de</strong> capacité <strong>de</strong> correction, point que nous avons pu corroborer lors <strong>de</strong> nossimulations. Néanmoins, leur complexité linéaire associée n'est pas clairement dénieen pratique.2.3 La compression d'en-têtes2.3.1 Introduction2.3.1.1 Le meilleur com<strong>pro</strong>mis "redondance/abilité" : l'objectif commun <strong>de</strong>sco<strong>de</strong>s à eacements et <strong>de</strong> la compression d'en-têtesCette section présente l'autre domaine d'application <strong>de</strong> la théorie <strong>de</strong> l'informationdans le domaine <strong>de</strong>s réseaux que nous avons abordé dans cette thèse : la compressiond'en-têtes. La diérence entre le domaine <strong>de</strong>s co<strong>de</strong>s à eacements et celui <strong>de</strong> la compressiond'en-têtes rési<strong>de</strong> dans le fait que, pour les co<strong>de</strong>s à eacements, les donnéessont considérées être déjà compressées. On ne gère alors que l'ajout <strong>de</strong> redondanceet la gestion <strong>de</strong> cette redondance par rapport à la abilité. Pour la compression d'entêtes,les données à traiter, c'est-à-dire les en-têtes, contiennent déjà une redondancenaturelle. Pour obtenir un bon com<strong>pro</strong>mis "redondance/abilité" (équivalent au ratio"compression/abilité) on pourrait se ramener au schéma <strong>de</strong>s co<strong>de</strong>s à eacements encompressant les données au maximum, puis en rajoutant <strong>de</strong> la redondance pour luttercontre les erreurs et les pertes <strong>de</strong> paquets. Ceci a déjà été <strong>pro</strong>posé, par exemple dans[35]. Toutefois, vu le type <strong>de</strong> redondance (principalement inter-paquets), il apparaîtque la meilleur com<strong>pro</strong>mis "redondance/abilité" est obtenu en intégrant directementla gestion <strong>de</strong> la abilité dans les mécanismes <strong>de</strong> compression en réalisant ainsi un typeparticulier <strong>de</strong> codage conjoint source-canal.