Brevet FR2687259A1 — publié le 19930813

-4 Procédé de compression de données pour système de transmission par unités de données de protocole, procédé de décompression et dispositif correspon- dants. Le domaine de l'invention est celui des systèmes de transmission de données, et plus précisément des systèmes de transmission structurés, dans lesquels les communications entre deux terminaux se font par échanges d'unités de données de protocole (en anglo-saxon: protocol data unit, ou PDU). L'invention s'applique donc notamment à tous les systèmes de transmission par paquets (système mettant en oeuvre une procédure de niveau 3, selon le modèle de normalisation OSI à sept niveaux), mais également aux systèmes de transmission par trames (niveau 2) ou d'unités de données de protocole de transport (niveau 4) Plus généralement, l'invention peut s'appliquer à tout type de système de transmission, quel que soit le niveau (selon la terminologie des normes OSI) du protocole de communication associé au système considéré. Un domaine d'application particulier de l'invention est celui des systèmes d'échanges de données selon le protocole X 25, normalisé par le CCITT Sur le territoire français, l'invention s'applique donc par exemple aux communications effectuées sur le réseau public TRANSPAC (marque déposée). L'invention concerne plus particulièrement l'optimisation des communica- tions, c'est-à-dire notamment la réduction des coûts, par la réduction des volumes de données transmis et/ou des temps de communication. On sait en effet que, en particulier lorsqu'il est nécessaire d'emprunter un réseau public de communication, les coûts sont généralement fonction, entre autres, du nombre d'unités de données du protocole (ou de sous-ensembles de ces unités) émises et du temps de communication. Une façon connue de diminuer le volume des données transmises est de compresser les données à transmettre. De nombreuses techniques de compression de données sont en effet connues, notamment dans le cas des liaisons point à point Ainsi, par exemple, un algorithme de compression adaptatif, dit algorithme de "Ziv- Lempel", a été retenu dans la recommandation V 42 bis du CCMIT, pour les modems asynchrones. Toutefois, dans le cas des systèmes fonctionnant par échanges d'unités de données de protocole, par exemple selon la norme X 25, plusieurs difficultés sont généralement rencontrées. On connaît ainsi un système, appelé DATAMISER (marque déposée), qui compresse systématiquement, octet par octet, lensemble du flux de données délivré par un terminal Lorsque ce flux de données organisé en unités de données de protocole, comprenant chacune des zones descriptives de la communication (champs d'en-tête) et des zones de données (champs de données), un tel système de compression ne respecte pas cette structuration En d'autres termes, il ne reconnaît ni ne préserve les en-têtes Il ne peut donc être utilisé pour une communication qui traverse un réseau à commutation par paquets. De façon à pallier cet inconvénient, on peut penser à compresser sélective- ment les zones de données Dans ce cas, les en-têtes sont conservés intégralement, et la quantité d'informations à transmettre est réduite de façon importante En d'autres termes, à une unité de données de protocole source est associée une unité de données de protocole compressé, dont l'en-tête est identique à celle de l'unité de données de protocole source. Dans la pratique, cette technique s'avère d'une efficacité non optimale En effet, le nombre de paquets transmis reste le même. L'invention a notamment pour objectif de pallier ces différents inconvé- neients de l'état de la technique. Plus précisément, un objectif de l'invention est de fournir un procédé d'optimisation du rendement des communications effectuées sur un réseau d'échanges de données, réduisant le nombre d'unités de données de protocole ou de sous-ensembles d'unités transmis. Un autre objectif de l'invention est de fournir un tel procédé, qui concerne la structure des unités de données de protocole émises En d'autres termes, un objectif de l'invention est de fournir un tel procédé qui soit transparent tant du point de vue des terminaux que du point de vue du réseau de transmission. Plus généralement, l'invention a pour objectif de fournir un tel procédé, qui permette de réduire au moins un des paramètres suivants: coût de la communication; durée de la communication; quantité de l'information transmise. Un autre objectif de l'invention est de fournir un tel procédé, qui puisse être mis en oeuvre sur tout système de transmission de données structuré. L'invention a également pour objectif de fournir un dispositif mettant en oeuvre un tel procédé, qui puisse être inséré entre un terminal et un réseau de communication, de façon transparente, c'est-à-dire ne nécessitant aucune adaptation, ni du terminal, ni du réseau. Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de compression de données, du type appliqué à un système de transmission de données par unités de données de protocole entre au moins un terminal émetteur et au moins un terminal récepteur, chaque unité de données de protocole comprenant un champ d'en-tête et un champ de données, procédé associant à une première séquence de N unités de données de protocole source une seconde séquence de M unités de données de protocole à transmettre, M étant inférieur ou égal à N, les champs de données desdites unités de données de protocole à transmettre, comprenant d'une part des données correspondant à la compression, selon au moins un algorithme de compression, des données contenues dans les champs de données desdites unités de données de protocole source, et d'autre part des données permettant de reconstruire ladite première séquence d'unités de données de protocole source. De cette façon, le rendement de la communication peut être fortement augmenté, mais la structure initiale des données est conservée Il est en effet possible, à la réception, de reconstituer la séquence source, à l'aide des données de reconstruction ajoutées aux données transmises. Ainsi, selon l'invention, on modifie momentanément, pendant la transmis- sion, la structure des données, ce qui permet de réduire le nombre d'unités de données de protocole à transmettre, mais on prévoit une étape supplémentaire nouvelle, par rapport aux techniques connues, à savoir l'insertion parmi les données compressées à transmettre de données de reconstruction. Un tel procédé comprend avantageusement les étapes de: réception de ladite première séquence d'unités de données de protocole source, compression de données, associant à chacune desdites unités de données de protocole source un sous-champ de données compressées comprenant des données correspondant à la compression des données du champ de données de ladite unité de données de protocole source, association à chacun desdits sous-champs de données compressées d'un sous-en-tête comportant au moins une information représentative de la longueur dudit sous-champ de données compressées, concaténation desdits sous-en-têtes et desdits sous-champs de données compressés en une suite de données concaténées, découpage de ladite suite de données concaténées en éléments de données de longueur prédéterminée choisie parmi un sous-ensemble d'au moins une longueur possible, création de ladite seconde séquence d'unités de données de protocole à transmettre, le champ de données de chacune desdites unités de données de protocole à transmettre comprenant au moins un desdits éléments de données. Selon cette méthode, on ajoute donc, en quelque sorte, un sous-protocole du réseau, de façon transparente (pour ce réseau) Il est à noter que les étapes de concaténation, de découpage et de création de la seconde séquence, qui sont ici distinguées dans le but de faciliter la compréhension de l'invention, peuvent en réalité être effectuées simultanément (on commence à créer un paquet dès que des données à concaténer sont reçues). Préférentiellement, lesdites données permettant de reconstruire ladite première séquence d'unités de données de protocole source comprennent au moins une des informations présentes dans le champ d'en-tête de chacune desdites unités de données de protocole source. En effet, outre la longueur des données compressées, il peut être nécessaire, pour reconstituer la séquence source, de conserver des informations qualifiant les unités de données de protocole source. Dans un mode de réalisation particulier de l'invention, ledit sous-entête comprend au moins un premier octet, portant au moins une des informations présentes dans le champ d'en-tête de l'unité de données de protocole source correspondant audit sous-en-tête, et un second octet portant la longueur du sous- champ de données compressées associé. De façon avantageuse, ledit algorithme de compression est un algorithme de compression adaptatif gérant à l'émission et à la réception des dictionnaires de séries de données, lesdits dictionnaires étant mis à jour identiquement à chaque transmission d'une desdites unités de données de protocole. Cet algorithme adaptatif s'avère en effet particulièrement intéressant, en terme d'efficacité de compréhension. Préférentiellement, le procédé comprend une étape de compression de données comprenant les étapes de: mise en oeuvre d'un algorithme de compression associant à un champ de données source un champ de données compressées; comparaison de la longueur desdits champs de données source et compressées, et sélection comme sous-champ de données compressées du champ de données de longueur la plus faible. Il est clair que, dans le cas o la compression n'est pas efficace, il est préférable de transmettre les données sous forme non compressée. Dans ce cas, ledit sous-en-tête comporte une information représentative de ladite sélection du champ de données source ou du champ de données compressé. Les unités de données de protocole considérées peuvent être de tout type, et par exemple des paquets de données, des trames de données ou des unités données de niveau 4 (transport). De façon classique, celles-ci peuvent avoir une longueur d'unité de données de protocole choisie dans un ensemble d'au moins une longueur possible. Avantageusement, le procédé comprend également une étape d'initialisa- tion d'une transmission, consistant notamment à vérifier que le récepteur dispose de moyens de mise en oeuvre d'un procédé de décompression correspondant audit procédé de compression. Par récepteur, on comprend soit des terminaux équipés en interne de moyens de compression/décompression, soit des dispositifs spécifiques de compression/décompression associés à des terminaux. L'invention permet donc de ne transmettre que des unités de données pleines, puisque leurs champs de données comprennent des données concaténées appartenant à plusieurs unités source Toutefois, le remplissage d'une unité ne doit pas être une condition obligatoire, au risque de bloquer le procédé En effet, en particulier lorsqu'il s'agit d'une fin de séquence, il doit être possible d'émettre une unité de données non complète Pour cela, deux temporisations sont envisageables. Ainsi, le procédé comprend de façon avantageuse une première étape de temporisation, fixant un délai d'attente maximum Dl avant la création d'une unité de données de protocole à transmettre non pleine. De plus, il peut aussi comprendre une seconde étape de temporisation, fixant un délai d'attente maximum D 2, D 2 étant inférieur à Dl, avant la création d'une unité de données de protocole à transmettre comprenant au moins un élément de données de longueur prédéterminée plein, et aucun élément non plein. L'invention concerne bien sûr également un procédé de décompression symétrique au procédé de compression décrit ci-dessus, comprenant les étapes de: recherche et analyse desdites données permettant de reconstruire ladite première séquence d'unités de données de protocole, décompression desdites données correspondant, sous une forme compressée, aux données contenues dans les champs de données des unités de données de protocole source, restitution de ladite première séquence d'unités de données de protocole source. Elle concerne également tout dispositif mettant en oeuvre ce procédé de compression et/ou ce procédé de décompression, et notamment un dispositif comprenant d'une part des moyens de connexion à au moins un terminal émetteur/récepteur, se comportant de façon similaire au système de transmission de données, et d'autre part des moyens de connexion audit système de transmission de données, se comportant de façon similaire à un terminal émetteur/récepteur. De cette façon, le dispositif est tout à fait transparent. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre illustratif et non limitatif, et des dessins annexés dans lesquels: la figure 1 présente de façon schématique un système de transmission de données comprenant deux dispositifs selon l'invention; la figure 2 est un schéma synoptique illustrant le procédé de compression de l'invention; la figure 3 illustre le traitement subi par une séquence de paquet source, selon le procédé de la figure 2; la figure 4 est un schéma simplifié d'un dispositif mettant en oeuvre le procédé de la figure 2; la figure 5 est un exemple de sous-en-tête pouvant être utilisé dans les paquets compressés de la figure 3. Le mode de réalisation décrit ci-dessous s'applique notamment aux réseaux de communication offrant une interface conforme à la norme X 25, et en particulier aux réseaux utilisant un principe de tarification par segments, tel que le réseau public français TRANSPAC (marque déposée) Il est clair toutefois que l'invention ne se limite pas à ce type de réseaux, mais peut au contraire s'appliquer dans tous les cas o des échanges de données se font par unités de données de protocole. Ainsi, et bien que par la suite on considérera plus précisément le cas de paquets de données, l'invention peut être mise en oeuvre à tous les niveaux de protocole de la normalisation OSI, notamment au niveau 2 et/ou au niveau 4. Comme on l'a déjà mentionné, l'invention a donc pour objectif d'améliorer le rendement des communications sur un réseau donné, tout en conservant la structure du train de données émis. La figure 1 présente un exemple de mise en oeuvre de l'invention Trois terminaux émetteur/récepteur 11 A, 11 i B et lic sont connectés à un réseau 12 de communication par paquets. Ces terminaux 11 A et lic représentent tout système d'extrémité pouvant se connecter à un réseau, tel que par exemple un ordinateur, un serveur de base de données, un terminal de saisie, etc Deux terminaux 11 A et lic peuvent être associés pour une communication particulière Ces deux terminaux peuvent éventuellement gérer plusieurs communi- cations simultanément Par exemple, le terminal 11 A peut entretenir en même temps une première communication avec le terminal 11 B et une seconde communication avec le terminal lic. Dans le mode de réalisation préférentiel de l'invention décrit en liaison avec la figure 1, les moyens de compression/décompression sont installés dans des dispositifs 13 À et 13 B' indépendants des terminaux 11 A et 11 B Ces dispositifs de compression/décompression sont donc placés en coupure sur le câble de connexion au réseau, et sont "transparents, tant pour le terminal 11 A que pour le réseau 12. En d'autres termes, le dispositif 13 A se comporte ( 14, 15), vu du terminal 11 A, comme le réseau, et, vu du réseau 12, comme un terminal ( 16, 17). Chaque dispositif 13 A, 13 B comprend des moyens de compression de données 18 A, 18 B, mettant en oeuvre le procédé qui sera décrit par la suite, et des moyens symétriques de décompression 19 A, 19 B On décrira essentiellement par la suite le procédé de compression Le procédé de décompression en est aisément déductible par symétrie. Il est à noter que la compression des données d'une communication n'est pas systématique Tout d'abord, il faut que le terminal récepteur soit associé (ou comprenne) un dispositif de décompression Ainsi, toute communication impliquant le terminal 11 c se fera sans compression Par ailleurs, il faut que les deux dispositifs de compression/décompression 13 A et 13 B disposent des moyens nécessaires (moyens de traitement et/ou mémoire) On peut par exemple prévoir des dispositifs capables de gérer plusieurs communications, dont seulement un nombre réduit avec compression/décompression. Par ailleurs, il est tout à fait envisageable que la compression ne soit mise en oeuvre que dans un des deux sens de communication, en fonction des moyens disponibles et/ou de l'intérêt que représente la compression, en terme d'efficacité, dans chaque sens de communication. Enfin, bien que les dispositifs 13 A et 13 B soient ici présentés sous forme d'éléments indépendants, ce qui présente l'avantage important de pouvoir les utiliser avec tous types de terminaux existants (il suffit d'interconnecter le dispositif 13 A entre le terminal 11 A et le réseau 12), il est clair que les mêmes moyens de compression/décompression peuvent être intégrés à un terminal. La figure 2 est un schéma synoptique simplifié du procédé de compression de l'invention. Au début de chaque communication, on peut effectuer tout d'abord (si cela est nécessaire) une phase d'initialisation 21, consistant notamment à vérifier que le dispositif récepteur dispose de moyens de compression/décompression correspon- dant. Cette phase 21 comprend tout d'abord la vérification que le terminal visé dispose d'un dispositif de compression/décompression Cela peut se faire soit de façon passive, chaque dispositif de compression gérant une liste de terminaux pouvant effectuer la décompression, soit de façon active, par une procédure d'interrogation interactive Dans un second temps, il convient de vérifier que le dispositif récepteur a des moyens de décompresseion disponibles. On aborde ensuite (si la compression est possible) une phase de compression 22 proprement dite Cette phase 22 comprend une étape de réception 23 des paquets source à compacter Il convient de noter que le procédé de l'invention ne fait aucune hypothèse sur la séquence de paquets reçus, ni sur la constitution de ces paquets Ceux-ci peuvent être pleins ou non, être de taille fixe ou variable, provenir de diverses origines, etc Le procédé de l'invention est complètement transparent vis-à-vis de la structure d'origine. En revanche, ainsi qu'on le verra par la suite, il assure la conservation de cette structure d'origine. On a déjà expliqué en préambule qu'il n'était pas possible de compresser sans distinction les champs de données et les en-têtes Selon l'invention, seul le champ de données 24 subit une compression 25 Une méthode particulière de compression avantageuse est un algorithme de compression du type dit de "Ziv- Lempel' Les peincipes de base de codage, décodage et mise à jour des dictionnai- res sont proches de ceux décrits dans la recommandation V 42 bis Bien sûr, tout autre algorithme de compression peut être utilisé Eventuellement, plusieurs algorithmes peuvent être mis en oeuvre simultanément, le résultat le plus efficace étant seul conservé. Par ailleurs, on crée 26 un sous-en-tête, ou zone d'information comprenant notamment une information 27 représentative de la longueur du champ de données compressées, délivrée par l'étape 25 de compression Cet en-tête comporte de plus les données 28 nécessaires à la reconstruction de la séquence de paquets d'origine, c'est-à-dire en particulier les informations indiquant, dans l'en-tête de chaque paquet d'origine (non compressé) le type du paquet (information de qualification), la structuration en messages complets selon le protocole X 25, etc Un exemple particulier de sous-en-tête est décrit plus loin en liaison avec la figure 4. Le sous-en-tête 29 et le champ de données compressées 30 correspondant à chaque paquet source sont ensuite concaténés ( 31) dans une suite 32 de données continue Cette suite 32 est ensuite découpée ( 33) arbitrairement, c'est-à-dire sans respect des paquets d'origine, à une longueur correspondant à une longueur de champ de données autorisée par le réseau, ou à une longueur sous-mulitple de cette longueur autorisée. Chaque élément 34 ainsi découpé est utilisé pour créer ( 35) un nouveau paquet, dont il devient le champ de données (ou une portion de ce champ) Ce nouveau paquet a en revanche un en-tête nouveau qui lui est propre. L'efficacité de ce procédé sera mieux perçue sur l'exemple de compression présenté en figure 3. il On considère une séquence source de trois paquets consécutifs 41 A' 41 B 41 c Chaque paquet est constitué de façon classique d'un en-tête 42 A, 42 l et 42, (dans l'exemple considéré, conforme à la norme X 25) et d'un champ de données 43 A' 43 B et 43 c. On considère ici le cas de paquets pleins (mais ce n'est nullement une condition obligatoire), et d'un format conforme avec celui admis par le réseau de communication. Chaque paquet 41, est donc ensuite compressé ( 44) On obtient ainsi une séquence de paquets compressés 45 A' 45 B' 45 C Bien sûr, le nombre de paquets est conservé, et les en-têtes 42 A à 42 C de chacun d'entre-eux restent inchangés en revanche, la longueur des champs de données 46 A, 46 B et 46 C est sensiblement réduite. Cette compression s'avère intéressante, en particulier lorsque le réseau utilise un système de tarification par segments. C'est notamment le cas du réseau TRANSPAC, qui utilise pour sa tarification des segments de 64 octets Cette découpe en segments, qui est différente de la structure en paquets, a pour objectif de base d'inciter les utilisateurs à émettre des paquets de données pleins En effet, chaque segment entamé (c'est-à-dire contenant au moins un octet) est comptabilisé, et a donc un prix de revient identique à un segment plein ( 64 octets). Ainsi, le paquet 41 A' s'il était émis, serait comptabilisé pour deux segments 471 et 472 Au contraire, le paquet 45 B ne comprend qu'un segment comptabilisé 48 i Dans ce cas de figure, la compression permet une réduction de 50 % du coût de la transmission du paquet. Toutefois une telle compression n'offre, au mieux, qu'un taux de compression de 2 (réduction de 50 % du volume de données transmis), alors que les techniques de compression permettent souvent d'obtenir des taux de compression égaux à 3, 4 voir plus En effet, quelle que soit la qualité de la compression réalisée, il aura toujours au moins un segment de facturé par paquet. L'invention propose une solution nouvelle, et très efficace, à ce problème. En effet, après avoir procédé à la compression 44, une étape de traitement complémentaire de compactage 50 est effectuée. Selon l'invention, une nouvelle séquence de paquets 51 D' 51 E est créée. Ces paquets sont tout à fait indépendants des paquets de la séquence 41 A à 41 C. Notamment, leurs en-têtes 52 D' 52 E ne correspondent à aucun des en-têtes 42 A à 42 C. En revanche, l'ensemble des données utiles à la reconstruction du train de paquets source est disponible dans les champs de données 53 D et 53 E des nouveaux paquets 51 D et 51 E Plus précisément, et il s'agit de la caractéristique principale de l'invention, un champ de données 53 D ne comprend pas uniquement les données concaténées des champs de données 46 et 46 B, mais également, sous la forme d'un sous-en-tête 47 A' des données de reconstruction de la séquence d'origine. Ce sous-en-tête 47 A est transparent, du point de vue du réseau En revanche, à la décompression, il permet d'une part d'extraire du champ de données 53 D la suite de données 46 A correspondant au paquet 45 A' par l'information de longueur 54 Par ailleurs, il contient les informations nécessaires à la reconstruction, au moins partielle, de l'en-tête 42 À, Les champs de données 53 D et 53 E sont considérés en continu Ainsi, les données de compression 46 B peuvent être sans problème réparties en deux sous- ensembles 46 M et 46 dans deux paquets distincts Le sous-entête 47 B indique la fin du sous-ensemble 46 M Un sous-en-tête peut également être réparti sur deux paquets. La figure 4 donne un exemple de sous-en- tête pouvant avantageusement être utilisé dans le cadre du protocole X 25. Ce sous-en-tête est constitué de deux octets 61 et 62 Le premier octet contient d'une part deux éléments binaires Q et M, qui sont la reproduction directe des éléments binaires Q("Q-bit") et M ("M-bit") existant dans l'en-tête d'un paquet selon le protocole X 25 Ces bits sont nécessaires pour, respectivement, qualifier le paquet et indiquer le début ou la fin d'un message. D'autre part, il comprend un élément binaire C, qui indique si la compression a été mise en oeuvre pour le paquet considéré. Cinq bits ( 63) sont disponibles pour des développements futurs. Le second octet comprend, sur 8 bits, la longueur L ( 54, fig 3) de la suite de données compressée. La figure 5 présente un schéma synoptique d'un dispositif selon l'invention, tel que représenté ( 13 A'13 B) en figure 1, et mettant en oeuvre le procédé décrit ci-dessus. Les paquets source 71 sont reçus dans un module 72 de réception et de séparation, qui délivre d'une part le champ de données 73 et d'autre part l'en-tête 74 de chaque paquet. Le champ de données 73 est alors compressé par le module de compres- sion 75, qui met en oeuvre par exemple un algorithme adaptatif de "ZivLempel". Dans ce cas, un dictionnaire est mis à jour en permanence dans une mémoire 76. Le champ de données compressé 77 est ensuite transmis à un module 78 de comparaison, qui sélectionne le champ de données le plus court, 79, (comparai- son entre le champ compressé 77 et le champ non compressé 73, et sélection du plus court, et, dans le cas de longueurs égales, du champ nom compressé, qui nécessitera moins de traitement à la réception). Dans le cas o plusieurs moyens de compression sont mis en oeuvre en parallèle, le module 78 effectue de même la sélection du plus efficace. Un module 80 de construction des sous-en-têtes 81 prépare chaque sous- en-tête (par exemple selon le format de la figure 4), en tenant compte de l'en-tête 74 (pour extraire les bits Q et M), et des informations de longueur L et d'activation de la compression C délivrées par le module 78. Ces sous-en-têtes 81 et champs de données compressées 79 sont ensuite concaténés ( 82), de façon à créer des segments pleins (et plus généralement, des paquets pleins), lorsqu'on se trouve en fin de séquencesource (fin de message) On tient donc compte de deux temporisations Dl et D 2, de la façon suivante: Dl: temporisation segment plein: on émet un paquet non plein, mais ne comprenant que des segments pleins (cette temporisation est notamment intéressante dans le cas du réseau TRANSPAC, o la facturation se fait par segments); D 2: temporisation maximum: émission d'un paquet, contenant un dernier segment non plein (cette temporisation est nécessaire, pour éviter le blocage du dispositif, notamment en fin de séquence source). De préférence, on choisira D 2 très inférieur à Dl, de façon à minimiser le nombre de segments émis. L'efficacité du procédé et du dispositif de l'invention apparaît clairement sur la figure 3, puisque l'on constate que deux paquets ( 5 E, 51 D) sont transmis, alors que la séquence source comprenait trois paquets pleins ( 41 A 41 B' 41 c). Cette efficacité est encore plus probante, bien sûr, lorsque les paquets source ne sont pas pleins Dans ce cas, le principe de la concaténation permet un gain important en nombre de paquets (ou en segments, c'est-à-dire de portions de paquets) transmis. REVENDICATIONS 1 Procédé de compression de données, du type appliqué à un système de transmission de données par unités de données de protocole ( 41) entre au moins un terminal émetteur ( 11 A) et au moins un terminal récepteur ( 11 B), chaque unité de données de protocole ( 411) comprenant un champ d'en-tête ( 42 f) et un champ de données ( 43;), caractérisé en ce qu'il associe à une première séquence de N unités de données de protocole source ( 41 A, 41 B' 41 c) une seconde séquence de M unités de données de protocole à transmettre ( 51 D, 51 E), M étant inférieur ou égal à N, et en ce que les champs de données ( 53 e) desdites unités de données de protocole à transmettre ( 511) comprennent d'une part des données ( 46,) correspondant à la compression, selon au moins un algorithme de compression, des données contenues dans les champs de données ( 431) desdites unités de données de protocole source ( 411), et d'autre part des données ( 471) permettant de reconstruire ladite première séquence d'unités de données de protocole source ( 41 f). 2 Procédé selon la revendication 1, caractérisé en ce qu'il comprend les étapes de: réception ( 23) de ladite première séquence d'unités de données de protocole source, compression de données ( 25), associant à chacune desdites unités de données de protocole source un sous-champ ( 30) de données compressées comprenant des données correspondant à la compression des données du champ de données ( 24) de ladite unité de données de protocole source, association ( 26) à chacun desdits sous-champs ( 30) de données compressées d'un sous-en- tête ( 29) comportant au moins une information ( 27) représentative de la longueur dudit sous-champ ( 30) de données compressées, concaténation ( 31) desdits sous-en-têtes ( 29) et desdits sous-champs ( 30) de données compressés en une suite ( 32) de données concaténées, découpage ( 33) de ladite suite ( 32) de données concaténées en éléments ( 34) de données de longueur prédéterminée choisie parmi un sous-ensemble d'au moins une longueur possible, création ( 35) de ladite seconde séquence d'unités de données de protocole à transmettre, le champ de données de chacune desdites unités de données de protocole à transmettre comprenant au moins un desdits éléments ( 34) de données. 3 Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que lesdites données ( 47,; 29) permettant de reconstruire ladite première séquence d'unités de données de protocole ( 47 f) source comprennent au moins une des informations présentes dans le champ d'entête ( 42 f; 28) de chacune desdites unités de données de protocole ( 411) source. 4 Procédé selon les revendications 2 et 3, caractérisé en ce que ledit sous- en-tête ( 47 e; 29) comprend au moins un premier octet ( 61), portant au moins une des informations (Q, M) présentes dans le champ d'en-tête ( 42 f) de l'unité de données de protocole source ( 41 f) correspondant audit sous-en-tête, et un second octet ( 62) portant la longueur (L) du sous-champ ( 46 e; 30) de données compressées associé. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit algorithme de compression ( 25) est un algorithme de compression adaptatif gérant à l'émission et à la réception des dictionnaires ( 76) de séries de données, lesdits dictionnaires ( 76) étant mis à jour identiquement à chaque transmission d'une desdites unités de données de protocole. 6 Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend une étape ( 25) de compression de données comprenant les étapes de: mise en oeuvre ( 75) d'un algorithme de compression associant à un champ de données source ( 73) un champ de données compressées ( 77); comparaison ( 78) de la longueur desdits champs de données source ( 73) et compressées, et sélection ( 79) comme sous-champ de données compressées ( 79) du champ de données ( 73, 77) de longueur la plus faible. 7 Procédé selon les revendications 2 et 6, caractérisé en ce que ledit sous- en-tête ( 47 f; 29; 81) comporte une information (C) représentative de ladite sélection ( 79) du champ de données source ( 73) ou du champ de données compressées ( 77). 8 Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que lesdites unités de données de protocole sont des paquets de données ( 41; 51 f), des trames de données ou des unités de données de protocole de niveau transport. 9 Procédé selon l'une quelconque des revendications 2 à 8, caractérisé en ce que lesdites unités de données de protocole ( 41 f; 511) ont une longueur d'unité de données de protocole choisie dans un ensemble d'au moins une longueur possible, et en ce que la longueur desdits éléments de données est un sous-multiple de ladite longueur d'unités de données de protocole choisie. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend une étape ( 28) d'initialisation d'une transmission, consistant notamment à vérifier que le récepteur ( 11 B) dispose de moyens ( 19 B) de mise en oeuvre d'un procédé de décompression correspondant audit procédé de compres- sion. 11 Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend une première étape de temporisation, fixant un délai d'attente maximum Dl avant la création d'une unité de données de protocole à transmettre non pleine. 12 Procédé selon les revendications 9 et 11, caractérisé en ce qu'il comprend une seconde étape de temporisation, fixant un délai d'attente maximum D 2, D 2 étant inférieur à Dl, avant la création d'une unité de données de protocole à transmettre comprenant au moins un élément de données de longueur prédéter- minée plein et aucun élément non plein. 13 Procédé de décompression d'unités de données de protocole compres- sées selon le procédé de l'une quelconque des revendications 1 à 12, caractérisé en ce qu'il comprend les étapes de: recherche et analyse desdites données ( 471) permettant de reconstruire ladite première séquence d'unités de données de protocole ( 411), décompression desdites données ( 461) correspondant, sous une forme compressée, aux données contenues dans les champs de données ( 431) des unités de données de protocole source ( 411), restitution de ladite première séquence d'unités de données ( 41 f) de protocole source. 14 Dispositif de compression et/ou de décompression, caractérisé en ce qu'il comprend des moyens ( 181, 19 j) de mise en oeuvre, dans au moins un sens de transmission de données et, pour au moins une communication, du procédé de compression selon l'une quelconque des revendications 1 à 12 et/ou du procédé de décompression selon la revendication 13. Dispositif selon la revendication 14, caractérisé en ce qu'il comprend d'une part des moyens de connexion à au moins un terminal émetteur/récepteur, se comportant de façon similaire au système de transmission de données, et d'autre part des moyens de connexion audit système de transmission de données, se comportant de façon similaire à un terminal émetteur/récepteur.