FR2857182A1 - Procede de transmission d'informations supplementaires par compression d'en-tete - Google Patents

Abstract

Procédé pour échanger des données entre deux couches d'une pile réseau dans un système de transmission de données comprenant un mécanisme de compression et de décompression d'en-tête, comportant au moins les étapes suivantes :• transmettre les paquets initiaux à une étape de compression/reconstruction d'en-tête des paquets, et simultanément• transmettre des informations supplémentaires à une étape de mise en forme pour produire lesdites informations dans des paquets supplémentaires compatibles avec la pile réseau.

Description

<Desc/Clms Page number 1>

L'invention concerne un dispositif et un procédé permettant de transmettre des informations entre deux couches d'une pile réseau.

Elle s'applique dans le domaine des transmissions avec pertes dues au medium de transmission (ex : transmissions sans fil). Elle s'applique dans tout système de transmission de données comportant un mécanisme de compression et de décompression d'en-tête.

La transmission de texte, d'images et de vidéo par l'intermédiaire de canaux de largeur de bande limitée peut être affectée de manière importante par des erreurs dues au canal. De tels systèmes utilisent traditionnellement des codeurs de source pour réduire la redondance des symboles sources et réduire ainsi la quantité d'information à transmettre, puis des codeurs correcteur d'erreur (ou de canal) pour augmenter la robustesse de l'information transmise sur le canal. Ceci est réalisé classiquement grâce aux standards de compression des codes de longueur variable (VLC : codes d'Huffman, codes arithmétiques,..) et au codage canal, à la modulation (désignée dans la suite sous le terme générique de codeur/décodeur de canal ) pour augmenter la robustesse de la transmission sur le canal. Une optimisation plus intégrée peut être obtenue en développant une stratégie de codage/décodage conjoint source canal. Le point clef consiste alors à utiliser de manière appropriée la redondance de la source résiduelle pour la partie décodage. Cette redondance peut être considérée comme une forme de protection de canal implicite par le décodeur et être exploitée de façon à offrir une capacité de correction d'erreur.

Dans les systèmes simples où le codeur de source 1 et le codeur canal 2 (respectivement les décodeurs source 3 et canal 4) sont directement interfaces, les techniques de codage conjoint source canal peuvent être

<Desc/Clms Page number 2>

implémentées facilement en échangeant l'information entre les différents blocs, comme le montre la figure 1. La référence 5 désigne le canal de transmission.

Du côté émetteur, les données d'information sur la sensibilité de la source aux erreurs canal (Source Significance Information ou SSI), peuvent être transmises du codeur de source au codeur de canal afin de permettre l'application des techniques telles que la protection inégale aux erreurs (Unequal Error Protection ou UEP). De façon à adapter les taux de codage source et de codage canal aux conditions du canal de propagation, il est aussi utile de fournir l'information relative à l'état du canal (Channel State Information ou CSI) au codeur de source et au codeur de canal. Dans le domaine des communications numériques, les méthodes traditionnelles de décodage appliquées à de tels schémas concaténés, qui permettent des gains de codage élevés avec une complexité raisonnable et une robustesse aux erreurs de transmission, peuvent être à décisions dures (hard) ou à décisions souples (soft) selon que le signal est binaire ou analogique.

Les méthodes de décodage à décisions souples permettent d'améliorer asymptotiquement la performance, en terme d'erreur, de plusieurs décibels sur la plupart des canaux. L'information souple apparaît donc comme nécessaire dans le domaine des communications modernes.

Afin de permettre le décodage souple, le décodeur interne doit fournir une sortie souple au décodeur externe et vice-versa dans le cas d'un décodage itératif. En conséquence, du côté récepteur, les sorties souples du canal et l'information CSI relative à la fois à l'amplitude de l'évanouissement et au bruit, peuvent être fournies par le canal au décodeur de canal qui réalisera le décodage canal à entrée et sortie souples (Soft Input Soft Output ou SISO).

Par ailleurs, la sortie souple du décodeur de canal ou l'information de fiabilité du décodeur (Décoder Reliability Information ou DRI) seront transmises au décodeur de source qui réalisera le décodage source à entrées souple et fournira une sortie souple pour les informations de source, c'est-a-dire l'information a posteriori de la source (Source A posteriori

<Desc/Clms Page number 3>

information ou SAI) peut être retransmise au décodeur de canal pour effectuer le décodage canal contrôlé par la source et éventuellement le décodage itératif source canal.

Toutefois, les codeurs/décodeurs source et canal sont souvent des dispositifs appartenant à un réseau qui ne peuvent pas échanger d'information à cause des couches protocolaires 6 qui les séparent, comme illustré à la figure 2.

Les diverses informations à échanger entre les décodeurs doivent passer à travers différents niveaux de protocoles réseau. Toutefois, pour rester compatibles avec les recommandations et les implémentations [1], de telles transmissions ne doivent pas interférer avec l'utilisation régulière du réseau. Ceci implique que l'information supplémentaire soit transmise de façon transparente pour la pile protocolaire.

Modèle de la couche OSI
En pratique, le transfert des informations DRI et SAI entre le codeur de source et le codeur de canal consistera à transmettre des valeurs quantifiées à travers la pile protocolaire. Le problème de la transparence devient celui de la transmission de plusieurs entrées binaires (typiquement la quantification peut être faite sur 4 ou 5 bits) au lieu d'une entrée binaire unique pour chaque bit d'information considéré. Toutefois, comme la transmission ne se fait pas directement mais à travers un réseau, les bits d'information qui intéressent l'application constitue seulement une partie constituant la partie utile de la séquence effectivement émise. Comme il est illustré à la figure 3, cette séquence émise est composée des données utiles encadrées par des en-têtes et éventuellement des terminaisons de paquet (par exemple des champs de contrôle tels que les codes cycliques de rendondance CRC).

De façon plus explicite, la transmission de données dans le sens descendant (du niveau applicatif au niveau accès réseau) à travers la pile

<Desc/Clms Page number 4>

protocolaire consistera à chaque transition de couches dans les étapes suivantes [1] : # Obtenir la séquence de données L+1 de la couche supérieure, # Générer l'en-tête ad hoc et éventuellement des champs de contrôle, # Construire la nouvelle séquence de données SL en concaténant l'en-tête, la séquence SL+1 et le champ de contrôle. Cette étape est éventuellement réalisée en découpant la séquence de données en plusieurs blocs, ceci en tenant compte des limitations éventuelle de taille imposées par le protocole. Dans ce dernier cas, les paquets résultants peuvent avoir un nombre d'en-tête inférieur mais gardent une constitution similaire. Leur évolution est donc semblable à celle des paquets non divisés.

De l'autre côté du canal, la transmission montante à travers la pile protocolaire consistera à chaque transition de couches à : # Obtenir la séquence de données S'L-1 de la couche inférieure, décapsuler l'en-tête ad hoc (et éventuellement la terminaison de paquet) pour créer la séquence S'L. Cette étape est éventuellement réalisée en même temps que les requêtes de retransmission dans le cas où la décapsulation montre que le flux de données était corrompu, # Envoyer la séquence de données S'L à la couche supérieure si le champ de contrôle est correct.

Solutions pour échanger l'information à travers les couches de la pile protocolaire
Pour échanger de l'information entre les couches sans modifier la pile protocolaire, une première idée serait de contourner la pile et d'utiliser un lien parallèle, en particulier lorsque l'on travaille sur la même machine.

Certains liens existent en pratique sur un ordinateur, entre les couches de bas niveau (noyau) et le niveau utilisateur sans passer à travers la pile protocolaire. Par exemple il est possible d'utiliser des drivers dédiés avec des liens iotcl [3] ou des moyens spécifiques, par exemple des moyens de sélection par la méthode BPF (Berkeley Packet Filter [4] ) qui permettent à la

<Desc/Clms Page number 5>

couche applicative de capturer et de filtrer les données au niveau des liaisons de données.

Toutefois, de telles solutions sont applicables uniquement en local et correspondent à un cas où les données ne doivent pas traverser la pile protocolaire. Elles ne s'appliquent donc pas dans le cas où niveau accès au réseau et le niveau application ne peuvent pas être connectés de cette façon.

Une autre solution proposée permet l'échange d'information telle que la fiabilité ou information souple à travers un réseau entre le décodeur de source et le décodeur de canal, en évitant toute interférence avec l'utilisation standard du réseau et en conséquence en évitant de redéfinir des protocoles existant. Présenté dans la référence [5], cette solution de transparence pour le réseau repose sur la présence de couches adaptatives qui permettent de prendre en compte les mécanismes existants de qualité de service QoS, et sur la validation du concept dans un environnement Berkeley Software Distribution Linux. Une telle solution a l'avantage de pouvoir s'adapter à toute pile protocolaire et à tout réseau. Elle impose toutefois de posséder une connaissance parfaite de la pile protocolaire au niveau de l'accès réseau et de l'application. Elle est de plus assez complexe car elle oblige à décapsuler une fois de plus au niveau de la couche physique pour modifier la donnée transmise.

Ces solutions présentent comme inconvénient majeur, la présence d'un mécanisme capable de construire ou de modifier le contenu des paquets IP valables au niveau physique et au niveau accès réseau.

Compression d'en-tête
Les liaisons ou communications sans fils sont caractérisées par une largeur de bande limitée qui, en pratique, limite le débit d'informations émises ou reçues par un utilisateur. Une telle liaison est vue traditionnellement comme un goulot d'étranglement (particulièrement pour des taux d'erreur binaire ER et de trame FER entre 10-2 et 10-5) pour la transmission de données car elles conduisent souvent à des retransmissions

<Desc/Clms Page number 6>

multiples des données, qui aggravent le problème de l'étroitesse de la bande limitée.

En conséquence, la transmission directe des paquets IP sur des liens physiques sans fil conduit à un gaspillage important du débit d'information binaire utile, car en fait les en-têtes des couches RTP, UDP et IP ajoutent une charge non négligeable aux données utiles. Cette charge peut être aisément réduite car ces en-têtes sont souvent redondantes, soit à l'intérieur de l'en-tête elle-même ou avec les en-têtes précédants ou suivants le paquet. Dans un contexte de données temps-réel, où les paquets doivent être transmis rapidement, les charges résultant de l'en-tête peuvent atteindre jusqu'à plusieurs fois la taille des données utiles (jusqu'à un facteur d'environ 3). Par ailleurs les mécanismes de correction d'erreurs (Forward Error Correction ou FEC) appliqués à la couche de liaison de données MAC sont généralement choisis pour garantir un faible taux d'erreurs, ceci pour assurer que les paquets IP ne seront pas rejetés lorsque leur CRC est vérifié dans la couche 3 (IP). Ceci conduit à une protection globale du paquet IP au niveau le plus élevé, lorsqu'en fait seul l'en-tête est particulièrement sensible aux erreurs. Pourtant, les données multimédia transmises peuvent souvent tolérer un taux d'erreur plus élevé grâce aux diverses mécanismes de correction appliquées aux codeurs source (robustesse du décodage, techniques de masquage,..).

Pour répondre au double objectif de la réduction d'en-tête et de l'augmentation de la robustesse de l'en-tête pour les liaisons sans fil, un nouveau protocole proposé par l'IETF a été introduit dans les versions 5 et 6 de l'UMTS par le groupe de travail 3GPP. Ce schéma, désigné sous l'expression Compression d'en-tête robuste (Robust Header Compression ou ROHC) a été standardisé par l'IETF sous la référence RFC 3095 [6]. Le principe du mécanisme ROHC est présenté à la figure 4. La standardisation de la compression d'en-tête RTP/UDP/IP pour les liaisons UMTS est en cours d'étude par l'IETF [7].

<Desc/Clms Page number 7>

La figure 5 permet de mieux illustrer le mécanisme de ROHC. Les champs d'en-tête variables IP, UDP, RTP au niveau de la pile protocolaire peuvent être classifiés comme suit : INFERRED (décrites) :données qui peuvent être directement dérivées des autres champs d'en-tête. Elles ne sont pas transmises, STATIC: champs statiques pour l'ensemble de transmission de données. Ils sont transmis une seule fois.

STATIC-DEF : champs définissant le flux de données. Ils sont gérés comme la classification STATIC.

STATIC-KNOWN : champs avec des valeurs connues. Ils ne sont pas transmis.

CHANGING : champs dont les valeurs changent régulièrement, soit de manière aléatoire, soit périodique. Ils sont transmis en totalité.

Il est ainsi facile de comprendre que le taux de compression obtenu est assez important et permet d'économiser une grande largeur de bande de transmission. Cette largeur de bande disponible peut être utilisée pour mieux protéger les en-têtes extrêmement fragiles, l'ensemble des données ou encore transmettre plus d'information.

L'invention propose notamment une solution permettant l'échange d'informations (CSI, SSI, DRI, SAI, .....) entre le décodeur de source et le décodeur de canal en présence de couches réseaux intermédiaires sans modification de ces couches. Il est alors possible d'utiliser les informations échangées pour améliorer la performance de décodage, par exemple en réalisant un décodage ssouple grâce aux informations de fiabilité (DRI, SAI).

Dans la suite de la description, on désigne par sens descendant la transmission d'informations allant de la couche applicative vers la couche accès réseau et dans le sens montant la transmission d'information de la couche accès réseau vers la couche applicative.

L'invention concerne un procédé pour échanger des données entre deux couches d'une pile réseau dans un système de transmission de

<Desc/Clms Page number 8>

données comprenant un mécanisme de compression et de décompression d'en-tête. Il est caractérisé en ce qu'il comporte au moins les étapes suivantes : # transmettre les paquets initiaux à une étape de compression/décompression d'en-tête des paquets, et simultanément # transmettre des informations supplémentaires à une étape de mise en forme pour produire/extraire lesdites informations dans des paquets supplémentaires compatibles avec la pile réseau.

La transmission des informations circulant du niveau accès réseau vers le niveau applicatif, comporte par exemple au moins les étapes suivantes : # différencier les informations provenant du canal de transmission en un flux de paquets initiaux et un flux d'informations supplémentaires préalablement quantifiées, # transmettre les paquets initiaux codés et les informations supplémentaires à une étape de décompression d'en-tête, # mettre en forme les informations supplémentaires quantifiées en fonction des caractéristiques de la pile protocolaire, # transmettre les deux flux ainsi obtenus à une étape de codage source ou à une étape de décodage source.

La transmission d'informations circulant du niveau applicatif vers le niveau accès réseau, le procédé peut comporter au moins les étapes suivantes : # différencier les paquets provenant de la pile protocolaire en un flux de paquets en un flux de paquets initiaux et un flux de paquets d'informations supplémentaires, # compresser les en-têtes des paquets initiaux et les transmettre à une étape de codage de canal, # mettre en forme les informations supplémentaires par extraction de l'information supplémentaire pour transmission à l'étape de codage canal,

<Desc/Clms Page number 9>

# transmettre le flux généré par le codage de canal pour émission vers le canal de transmission.

La transmission d'informations circulant du niveau applicatif vers le niveau accès réseau, le procédé comporte par exemple au moins les étapes suivantes : # différencier les paquets provenant de la pile protocolaire en un flux de paquets en un flux de paquets initiaux et un flux de paquets d'informations supplémentaires, # compresser les en-têtes des paquets initiaux et les transmettre à une étape de codage de canal de la couche d'accès, # mettre en forme les informations supplémentaires par extraction de l'information supplémentaire pour transmission à l'étape de décodage canal, # transmettre le flux généré par le codage de canal pour l'émission sur le canal de transmission.

La transmission d'informations circulant du niveau applicatif vers le niveau accès réseau, il peut comporter au moins les étapes suivantes : # différencier les paquets provenant de la pile protocolaire en un flux de paquets en un flux de paquets initiaux et un flux de paquets d'informations supplémentaires, # compresser les en-têtes des paquets initiaux et les transmettre à une étape de codage de canal, # mettre en forme les paquets transportant les informations supplémentaires quantifiées par compression d'en-tête en fonction des caractéristiques de la pile protocolaire pour transmission à l'étape de codage canal, # transmettre les flux générés par le codage de canal pour émission sur le canal de transmission.

La présente invention présente notamment les avantages suivants :

<Desc/Clms Page number 10>

# Elle est compatible avec les réseaux existants IP qui implémentent le processus de compression d'en-tête. Elle permet de transmettre des informations supplémentaires via le mécanisme de compression et de reconstruction d'en-tête en contrepartie d'une augmentation réduite de la complexité numérique.

# Elle peut être appliquée tout en utilisant les outils de qualité de service proposés par IETF pour la pile protocolaire OSI.

# Elle permet de bénéficier de la connaissance des éléments disponibles au niveau de couches donnés de la pile protocolaire, ces éléments n'étant habituellement pas transmis.

# Elle permet notamment # de transmettre des informations supplémentaires telles que la fiabilité des bits décodés, l'information sur l'état du canal ou de la source (statistiques, etc) tout en restant compatible avec les recommandations OSI.

# de localiser l'information nécessaire pour générer des en-têtes de paquets valables supplémentaires et éventuellement de modifier les en-têtes des paquets initiaux selon les besoins de l'utilisateur au niveau accès réseau, # d'extraire l'information supplémentaire à la couche d'accès réseau et de l'utiliser comme donnée utile pour les paquets supplémentaires valides transmis par un port dédié à un niveau d'application,
D'autres avantages et caractéristiques de la présente invention apparaîtront mieux à la lecture de la description qui suit donnée à titre illustratif et nullement limitatif annexée des figures qui représentent : # La figure 1 un schéma générique de décodage source canal conjoint, # La figure 2 un décodage conjoint source canal sur un réseau, # La figure 3 un principe de syntaxe pour un paquet généré par une pile protocolaire,

<Desc/Clms Page number 11>

# La figure 4 le principe du mécanisme ROHC, # La figure 5 un exemple de classification des champs d'en-tête pour une pile RTP/UDP/IPv4, # Les figures 6a et 6b un schéma des transmissions d'information du côté émetteur, # Les figures 7a et 7b un schéma des transmissions d'information du côté récepteur, # La figure 8 un exemple de génération de champs d'en-tête pour des paquets supplémentaires dans une pile RTP/UDP/IPv4, # La figure 9 un exemple de classification de champs d'en-tête pour des paquets originaux dans une pile RTP/UDP/IPv4, # Les figures 10 et 11 deux exemples d'extraction d'informations supplémentaires, # La figure 12 un exemple d'application de l'invention dans un contexte de transmission sans fil avec compression d'en-tête.

En résumé, l'information supplémentaire transmise du niveau accès réseau au niveau application est placée dans des paquets valides générés par le module de compression d'en-tête en parallèle à la transmission des données d'origine. Cette intégration au sein du processus de reconstruction suppose que la syntaxe à utiliser pour construire des paquets supplémentaires est connue et que la syntaxe des paquets des données d'origine reconstruits peut être modifiée en fonction du souhait de l'utilisateur. De manière similaire, l'information supplémentaire à transmettre du niveau applicatif au niveau accès réseau est transmise via des paquets supplémentaires qui sont interceptés par le module de compression/décompression d'en-tête et extraits pour être utilisés selon les besoins des utilisateurs.

Le module de compression/décompression est un module adapté à mettre en #uvre un mode de compression d'en-tête et un mode de décompression, selon le sens de transmission des informations. Dans le

<Desc/Clms Page number 12>

sens montant, le module de compression/décompression fonctionne en mode décompression alors que dans le sens descendant, il fonctionne en mode de compression.

Les figures 6a et 6b décrivent un exemple d'échanges existants du côté émetteur de transmission ayant la capacité de transmettre des informations supplémentaires.

L'architecture de l'émetteur est similaire à celle décrite à la figure 4, où le codeur de source 1 est en liaison avec une partie comprenant un module 6 de compression/décompression d'en-tête et un codeur de canal 2 par l'intermédiaire d'une pile protocolaire 6 comprenant plusieurs couches réseau.

La figure 6a schématise les échanges dans le sens montant de la couche accès réseau vers la couche applicative. Le module de compression/décompression fonctionne en mode décompression. Les observations en provenance du canal 5 sont transmises au codeur de canal 2 qui génèrent un paquet de données d'origine estimées et un flux d'informations supplémentaires quantifiées selon des techniques dont un exemple est donné à titre illustratif et nullement limitatif. Ces deux flux sont transmis au module de compression/décompression d'en-tête qui applique un traitement standard aux paquets de données d'origine et qui transforme l'information supplémentaire en paquets supplémentaires compatibles avec les protocoles transmis aux couches.

Les informations supplémentaires contenues dans les paquets sont ensuite utilisées par exemple en décodage souple de type SOVA ou BCJR.

La figure 6b schématise les échanges existants dans le sens descendant entre le niveau applicatif et le niveau accès réseau.

Les paquets initiaux et les paquets contenant des informations supplémentaires quantifiées au niveau du codeur de source sont transmis au module 7 de compression d'en-tête qui les différencie par exemple au moyen d'un champ d'en-tête particulier (par exemple le numéro de port UDP). Ce dernier comprime les en-têtes des paquets initiaux. Il récupère les

<Desc/Clms Page number 13>

informations quantifiées. Les deux flux ainsi générés sont transmis au codeur de canal qui les différencie.

Selon la valeur fixée du champ d'en-tête en fonction des besoins de l'utilisateur, le module de compression d'en-tête récupère les informations supplémentaires quantifiées par extraction des paquets différenciés pour les transmettre directement au codeur de canal, de façon synchrone ou non synchrone avec les paquets initiaux. En effet, dans le cas où l'information supplémentaire (par exemple SSI) n'est pas directement liée à des paquets initiaux donnés, ceux-ci peuvent être absents et seule de l'information supplémentaire transmise. Le codeur de canal déquantifie ces informations et les utilise alors (par exemple la SSI qui peut permettre de faire de la protection inégale des données (Unequal Error Protection ou UEP)).

Dans le cas où les informations supplémentaires sont détectées comme étant destinées au décodeur de canal du récepteur, les paquets contenant l'information supplémentaire ont leurs en-têtes compressées par le module de compression d'en-tête et transmis au codeur de canal pour codage et émission sur le canal. Les trames émises sont alors reçues et décodées au récepteur et remontent au niveau du module de compression/décompression du récepteur qui reconnaitra les paquets destinés au décodeur de canal et les lui transmettra.

Tout ceci s'applique aussi pour la transmission vers les blocs décodeur de canal de l'émetteur et codeur de canal du récepteur dans le cas d'une transmission duplex.

Cela s'applique aussi pour la transmission vers les blocs décodeur de source et décodeur de canal de l'émetteur pour une transmission duplex.

Les figures 7a et 7b représentent les échanges d'information qui se déroulent du côté du récepteur. L'architecture de ce récepteur est semblable à celle du récepteur de la figure 4.

La figure 7a schématise les échanges dans le sens montant de la couche accès réseau vers la couche applicative. Les observations sont

<Desc/Clms Page number 14>

reçues par le décodeur de canal qui génère les données estimées d'origine (données utiles estimées) et des informations supplémentaires quantifiées (par exemple SAI, DRI, ..) selon des méthodes dont un exemple est détaillé ci-après. Ces deux flux sont transmis au module de compression d'en-tête qui génère des paquets contenant des données d'origine reconstruites et des paquets contenant des informations supplémentaires. Ces informations étant générées typiquement par quantification des informations souples en sortie du décodeur.

La figure 7b schématise les échanges d'information dans le sens descendant de la couche applicative vers la couche accès réseau. Les paquets contenant les données utiles et les paquets contenant les informations supplémentaires sont transmis au module de compression d'entête qui génère des paquets de données utiles avec en-tête compressées et les informations supplémentaires quantifiées.

Les différents mécanismes décrits aux figures 6a et 6b s'appliquent respectivement pour les figures 7a et 7b.

Différentes méthodes pour générer les en-têtes, pour modifier les paquets de données, pour utiliser l'information supplémentaire, pour quantifier les informations supplémentaires sont explicitées ci-après.

Génération des paquets supplémentaires au niveau applicatif et extraction des paquets supplémentaires au niveau accès réseau.

Le procédé selon l'invention permet de transmettre l'information supplémentaire du niveau applicatif au niveau accès réseau. En particulier (figure 2) les informations SSI ou SAI peuvent être exploitées au niveau accès réseau. Pour des systèmes utilisant la compression d'en-tête, ceci est réalisée en générant au niveau applicatif des paquets supplémentaires contenant l'information supplémentaire. Ces paquets peuvent ensuite être transmis via un numéro de port dédié. Ces paquets seront transmis sans capacité ARQ (automatic repeat request), comme ils ne seront pas vraiment transmis mais intercepté au niveau accès réseau. Au niveau accès réseau, le

<Desc/Clms Page number 15>

module de compression d'en-tête qui traditionnellement effectue la compression d'en-tête et en conséquence a une connaissance de la structure des paquets, est modifié pour tester la présence du port dédié : # si la présence du port dédié est trouvée, le module reconnaît le paquet supplémentaire comme tel et l'élimine du flux de données. La partie utile des données est ensuite extraite pour être utilisée par le décodeur de canal (démodulateur, ..) # si le port n'est pas un port dédié, le mécanisme classique est appliqué.

Génération d'en-tête de paquets valides pour transmettre l'information au niveau applicatif
Le mécanisme de compression d'en-tête repose sur le fait que les champs d'en-tête variables IP, UDP, RTP dans la pile protocolaire ont une syntaxe fixée qui peut être facilement reconstruite à partir d'une information partielle (typiquement les classes STATIC, STATIC-DEF et CHANGING).

Sur un principe similaire, le mécanisme de reconstruction par le module de compression d'en-tête (fonctionnant en mode décomprssion) peut aussi, en parallèle au flux de données initiales, reconstruire des paquets supplémentaires à partir des mêmes champs d'en-tête. La figure 7 montre un exemple d'application de ce principe avec 3 classes de champs d'en-tête : RECOPIED (recopié) : correspond aux champs qui sont directement copiés des paquets de données valides. En pratique, ces champs appartiennent principalement aux classes STATIC, STATIC-DEF et STATIC-KNOWN mais peuvent aussi être de la classe CHANGING, recopiés tels que (par exemple l'étiquette temporelle ou timestamp), INFERRED (déduit) : comme dans le procédé ROHC process, ces champs sont dérivés directement des autres champs d'en-tête, SPECIFICALLY DERIVED (calculé spécifiquement) : ces champs sont ceux qui sont modifiés spécialement pour permettre la transmission de l'information supplémentaire. En particulier :

<Desc/Clms Page number 16>

# le port de destination qui permettra à l'utilisateur de séparer le flux de données initiales du flux de données supplémentaires et d'éviter ainsi de perturber le fonctionnement habituel des divers protocoles (RTCP par exemple). Il est proposé de transporter les données initiales et l'information supplémentaire sur deux numéros de port distincts (UDP,
TCP) ; # le checksum (le total de contrôle UDP) qui dépend de la partie utile des données. Il doit être recalculé en fonction des nouvelles parties utiles que les paquets supplémentaires transportent, # le numéro de séquence qui sera utilisé pour identifier la correspondance entre le paquet d'origine et le paquet supplémentaire, # la partie de donnée utile qui sera remplacée par l'information supplémentaire à transmettre.

RECOPIED = {(Ver, Hd. L, TdeS, Identification , R, M, L, offset, TTL, Protocol, Source Adress, Destination address) IPv4, Source Port (UDP), Ver, P, E, CCnt, M, P. Type, Timestamp, Identification Source Synchronisation (SSRC) Identification Source Contribution 1st, CSRC, Identification Source Contribution last) INFERRED = ( Paquet Length, Checksum (IPv4), Datagram Length (UDP)} SPECIFICALLY DERIVED= {Destination Port, checksum, Sequence number (UDP)} Modification des paquets d'origine en fonction des besoins de l'utilisateur
Il est possible pour l'utilisateur de modifier les en-têtes des paquets initiaux. Le procédé de reconstruction des en-têtes peut être adapté à des besoins spécifiques de transmission avec de l'information supplémentaire. Par exemple, le checksum sur la partie utile des données ( UDP checksum) peut être neutralisé par exemple en le mettant à zéro. Dans ce cas, une erreur dans la partie utile des données ne conduira pas à une

<Desc/Clms Page number 17>

élimination de ce paquet dont la partie utile peut être corrigée grâce au décodage souple de source.

La figure 9 donne un exemple de modification de la classification des en-têtes des paquets pour les paquets originaux dans la pile RTP/UDP/IPv4. Les caractères gras, italique, soulignés, majuscule ou minuscule sont respectés entre la figure et la description.

INFERRED = {Paquet Length, Checksum (IPv4), Datagram Length (UDP)} STATIC = { Ver, M, L, Protocol (IPv4), P, E (UDP)} STATIC-DEF = {Source Address, Destination address, Source Port, Destination Port, Identification Source Synchronisation (SSRC)} STATIC-KNOWN = {Hd.L., R, L, Offset, Ver} CHANGING=fTdeS, Identification, TTL, CCnt,M, P.type, Sequence Number, Timestamp, Identification Source Contribution 1st, CSRC, Identification Source Contribution (last),} SPECIFICALLY DERIVED= (checksum (UDP)}
De telles modifications ne perturberont pas la transmission de l'information : le paquet d'origine est transmis normalement à travers la pile protocolaire. Si aucun protocole d'en-tête ne comporte d'erreurs, le paquet traverse l'ensemble de la pile protocolaire et est reçu au niveau applicatif.

Les paquets RTCP sont ainsi transmis normalement et la qualité de service (QoS) de la transmission est garantie.

Extraction de l'information présente au niveau accès réseau et intégration de cette information dans les paquets supplémentaires valides pour une utilisation au niveau applicatif
Plusieurs cas peuvent être envisagés pour transmettre l'information supplémentaire, CSI, DRI. Cette information est formatée pour être insérée dans les paquets supplémentaires. Ces paquets transportant des unités binaires (bits), l'information doit être en conséquence être transformée en bits.

<Desc/Clms Page number 18>

Dans le cas de l'information de fiabilité du décodeur ou de toute information directement proportionnelle aux données utiles, on utilise une étape de quantification [2] appliqué à un nombre donné k de bits, comme il est illustré à la figure 10 . L'information b=(b1, b2, ..bn) réelle est quantifiée pour obtenir c=(c11, ...Cnk) avec bi - (ci,, ci2, Cik). Les coefficients ci sont des éléments binaires.

Dans le cas d'une information relative à l'état de canal, ou pour toute information de taille non proportionnelle aux données utiles (et en pratique assez courte), ceci implique un procédé de quantification ou de modélisation sur un nombre k de bits donnés, comme il est illustré à la figure 11. L'information supplémentaire est quantifiée selon un modèle préalablement défini par l'utilisateur. La séquence d = (ci, c2, ...., ck) où ci e {0, 1}est un élément binaire, représente donc l'état du canal ou toute information semblable.

De même, en sortie du codeur/décodeur de source ou codeur/décodeur de canal, un quantificateur est disposé pour générer l'information quantifiée de DRI ou de SSI.

Cette extraction d'information réalisée, les valeurs quantifiées sont transmises en parallèle au flux standard au module de compression d'en-tête qui les exploitera.

Expressions possibles pour les champs intitulés 'SPECIFICALLY DERIVED'
Les champs présentés ci-dessus comme étant spécialement dérivés sont destinés à permettre le procédé de transmission d'information supplémentaire. Quelques exemples sont donnés à titre illustratif et nullement limitatif : # le port de destination peut être choisi soit de manière dynamique, par exemple comme le premier port directement disponible au-dessus du port habituellement utilisé ou encore être enregistré comme un port dédié

<Desc/Clms Page number 19>

pour une telle transmission, (l'enregistrement des ports dédiés définie par l'organisation IANA que l'on peut trouver à l'adresse internet http://www.iana.ora), # le numéro de séquence. Ce numéro peut être ensuite utilisé pour identifier les paquets initiaux des paquets supplémentaires, # la partie des données utiles peuvent être dérivées comme il a été détaillé précédemment en quantifiant l'information supplémentaire. Pour l'information de fiabilité, le nombre k peut être pris égal à 4 ou 5. Le premier bit de quantification est par exemple pris égal à la valeur hard (estimation de la donnée d'origine) pour une meilleure efficacité. Pour une information supplémentaire, telle que SSI ou CSI, le format devrait être déterminé de manière spécifique entre les deux codeurs. Par exemple, l'information CSI pourrait être codée sur 4 niveaux, très mauvais, mauvais, bon, très bon, ceci correspondant à 2 bits d'information.

Applications possibles
Le procédé selon l'invention s'applique par exemple pour des réseaux à très faible débit et à bande limitée. Par exemple il est utilisé pour des transmissions sans fil construites sur un réseau à pile protocolaire avec compression d'en-tête tel que un réseau IP/UDP/RTP implémentant le mécanisme ROHC.

Il s'applique aussi dans des réseaux avec un temps de retransmission aller retour (Return Time Trip ou RTT) où l'utilisation de l'information CSI peut aider le comportement du décodeur de source pour choisir entre la retransmission demandée ou l'application des techniques d'annulation ou encore d'autres traitements des données reçues, ceci en fonction de la probabilité de chance de recevoir correctement l'information à la seconde demande.

Ce procédé peut aussi présenter des avantages lorsque l'information sur le flux d'information en provenance de la source tel que l'information SSI peut être fournie par le codeur de source au décodeur du

<Desc/Clms Page number 20>

canal. Ceci est par exemple le cas lorsque la protection d'erreur inégale (UEP) est réalisée au niveau accès réseau.

La figure 12 représente un exemple de mise en oeuvre de l'invention dans un contexte combiné transmission par fil/transmission sans fil où l'information supplémentaire peut être utilisée par exemple entre chaque utilisateur et son point d'entrée, chacun étant séparé de l'autre par un canal de transmission de fiabilité faible.

Références [1] ] A. Tanenbaum. Computer networks. Prentice-Hall, New-York, 3rd edition, 1996.

[2] J. G. Proakis. Digital Communications. McGraw-Hill Book Company, New York, 3rd edition, 1995.

[3] LINUX Device Drivers. Alessandro Rubini, O'Reilly & Associates, February 1998 [4] S. McCanne and V. Jacobson, "The BSD Packet Filter: A new Architecture for User level Packet Capture, " Proc. USENIX'93, San Diego, USA, Jan. 1993.

[5] S. Mérigeault and C. Lamy, "Concepts for Exchanging Extra Information Between Protocol Layers Transparently for the Standard Protocol Stack, " 10th International Conference on Telecommunications (ICT'2003), February 23 - March 1, 2003, Tahiti, French Polynesia.

[6] C. Bormann et al., "RObust Header Compression (ROHC) : framework and four profiles: RTP, UDP, EPS, and uncompressed", Juillet 2001, RFC 3095 [7] "Requirements for robust IP/UDP/RTP header compression", RFC 3096 [8] W.R. Stevens. TCPIIP Illustrated volume 1: the protocols. Addison Wesley Professional Computing Series, Jan. 1999.

Claims (6)

1. REVENDICATIONS 1- Procédé pour échanger des données entre deux couches d'une pile réseau dans un système de transmission de données comprenant un mécanisme de compression et de décompression d'en-tête, caractérisé en ce qu'il comporte au moins les étapes suivantes : # transmettre les paquets initiaux à une étape de compression/décompression d'en-tête des paquets, et simultanément # transmettre des informations supplémentaires à une étape de mise en forme pour produire lesdites informations dans des paquets supplémentaires compatibles avec la pile réseau.
2. 2 - Procédé selon la revendication 1 caractérisé en ce que la transmission des informations circulant du niveau accès réseau vers le niveau applicatif, comporte au moins les étapes suivantes : # différencier les informations provenant du canal de transmission en un flux de paquets initiaux et un flux d'informations supplémentaires préalablement quantifiées, # transmettre les paquets initiaux codés et les informations supplémentaires à une étape de décompression d'en-tête, # mettre en forme les informations supplémentaires quantifiées en fonction des caractéristiques de la pile protocolaire, # transmettre les deux flux ainsi obtenus à une étape de codage source.
3. 3 - Procédé selon la revendication 1 caractérisé en ce que la transmission des informations circulant du niveau accès réseau vers le niveau applicatif, comporte au moins les étapes suivantes : # différencier les informations provenant du canal de transmission en un flux de paquets initiaux et un flux d'informations supplémentaires préalablement quantifiées,

   <Desc/Clms Page number 22>

   # transmettre les paquets initiaux codés et les informations supplémentaires à une étape de décompression d'en-tête, # mettre en forme les informations supplémentaires quantifiées en fonction des caractéristiques de la pile protocolaire, # transmettre les deux flux ainsi obtenus à une étape de décodage source.
4. 4 - Procédé selon la revendication 1 caractérisé en ce que la transmission d'informations circulant du niveau applicatif vers le niveau accès réseau, il comporte au moins les étapes suivantes : # différencier les paquets provenant de la pile protocolaire en un flux de paquets en un flux de paquets initiaux et un flux de paquets d'informations supplémentaires, # compresser les en-têtes des paquets initiaux et les transmettre à une étape de codage de canal, # mettre en forme les informations supplémentaires par extraction de l'information supplémentaire pour transmission à l'étape de codage canal, # transmettre le flux généré par le codage de canal pour émission vers le canal de transmission.
5. 5 - Procédé selon la revendication 1 caractérisé en ce que la transmission d'informations circulant du niveau applicatif vers le niveau accès réseau, il comporte au moins les étapes suivantes : # différencier les paquets provenant de la pile protocolaire en un flux de paquets en un flux de paquets initiaux et un flux de paquets d'informations supplémentaires, # compresser les en-têtes des paquets initiaux et les transmettre à une étape de codage de canal de la couche d'accès, # mettre en forme les informations supplémentaires par extraction de l'information supplémentaire pour transmission à l'étape de décodage canal,

   <Desc/Clms Page number 23>

   # transmettre le flux généré par le codage de canal pour l'émission sur le canal de transmission.
6. 6 - Procédé selon la revendication 1 caractérisé en ce que la transmission d'informations circulant du niveau applicatif vers le niveau accès réseau, il comporte au moins les étapes suivantes : # différencier les paquets provenant de la pile protocolaire en un flux de paquets en un flux de paquets initiaux et un flux de paquets d'informations supplémentaires, # compresser les en-têtes des paquets initiaux et les transmettre à une étape de codage de canal, # mettre en forme les paquets transportant les informations supplémentaires quantifiées par compression d'en-tête en fonction des caractéristiques de la pile protocolaire pour transmission à l'étape de codage canal, # transmettre les flux générés par le codage de canal pour émission sur le canal de transmission.