FR2823389A1 - Procede et dispositif de compression et de decompression de codes d'une application ecrite en langage evolue, notamment en telephonie mobile - Google Patents
Procede et dispositif de compression et de decompression de codes d'une application ecrite en langage evolue, notamment en telephonie mobile Download PDFInfo
- Publication number
- FR2823389A1 FR2823389A1 FR0104643A FR0104643A FR2823389A1 FR 2823389 A1 FR2823389 A1 FR 2823389A1 FR 0104643 A FR0104643 A FR 0104643A FR 0104643 A FR0104643 A FR 0104643A FR 2823389 A1 FR2823389 A1 FR 2823389A1
- Authority
- FR
- France
- Prior art keywords
- codes
- bytes
- sequence
- sequences
- compression
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Au niveau du poste émetteur (4, 14), on traite de façon dynamique au moins certaines séquences d'octets contenues dans lesdits codes de manière à reconnaître dans ces séquences d'octets, les séquences d'octets dupliquées à l'identique au moins deux fois. Pour au moins une séquence dupliquée, on définit une séquence de compression, et on mémorise cette séquence de compression à une adresse choisie dans une table de compression, on remplace au moins une séquence dupliquée dans les données d'origine par l'adresse de la séquence de compression correspondante, et on envoie à l'équipement mobile d'abonné (2) les codes ainsi comprimés. Au niveau du module d'identité d'abonné, on procède de manière symétrique à la décompression des codes.
Description
<Desc/Clms Page number 1>
Procédé et dispositif de compression et de décompression de codes d'une application écrite en langage évolué, notamment en téléphonie mobile.
La présente invention concerne la compression et la décompression de codes d'une application écrite en langage évolué, notamment en téléphonie mobile.
Elle trouve une application générale en traitement de données et plus particulièrement en téléphonie mobile.
La plupart des opérateurs de téléphonie mobile font appel à un nombre croissant de services utilisant le canal SMS (Short Message Service, c'est-à-dire Service de Messages Courts) de leur réseau pour transmettre des données applicatives écrites en langage évolué (par exemple des appliquettes écrites en langage JAVA) entre l'équipement mobile de l'abonné (terminal de télécommunication doté généralement d'un module d'identité d'abonné) et un équipement informatique gérant ce service.
Or, le standard de communication en téléphonie mobile, par exemple celui dit GSM pour Groupe Spécial Mobile, alloue une bande passante très faible (quelques centaines d'octets par seconde seulement) pour le canal SMS qui n'était prévu initialement que pour la transmission de messages textes n'excédant pas 180 octets.
L'équipement de l'opérateur se trouve rapidement engorgé par une quantité de données non négligeables à transmettre sur ce canal SMS à faible débit. Il en résulte un temps de latence important au niveau de l'abonné.
L'amélioration des performances passent par des investissements extrêmement coûteux dans des équipements réseaux que l'opérateur a de plus en plus de mal à amortir. De plus, il se trouve toujours limité par le débit maximum du canal SMS.
<Desc/Clms Page number 2>
Le Demandeur s'est posé le problème de réduire le nombre d'octets de données transmises notamment sur ce canal SMS.
La présente invention apporte justement une solution à ce problème.
Elle porte sur un procédé de traitement de données pour un équipement mobile de communication équipé d'un module d'identité d'abonné, lesdites données comprenant des codes appartenant à une application écrite en langage évolué en provenance d'un poste émetteur distant.
Le procédé est du type comprenant les étapes connues suivantes : - a) équiper le module d'identité d'abonné d'un interpréteur apte à interpréter les codes d'une application écrite en langage évolué ; - b) équiper le module d'identité d'abonné et le poste émetteur d'un protocole de communication selon lequel l'équipement mobile est apte à obtenir les codes d'une application désirée en provenance dudit poste émetteur.
Selon une définition générale de l'invention, le procédé comprend en outre au niveau du poste émetteur les étapes suivantes : - c) traiter de façon dynamique au moins certaines séquences d'octets contenues dans lesdits codes de manière à reconnaître dans ces séquences d'octets, les séquences d'octets dupliquées à l'identique au moins deux fois, et - d) pour au moins une séquence dupliquée, définir une séquence de compression, et mémoriser cette séquence de compression à une adresse choisie dans une table de compression, remplacer au moins une séquence dupliquée dans les données d'origine par l'adresse de la séquence de compression
<Desc/Clms Page number 3>
correspondante, et envoyer à l'équipement mobile d'abonné les codes ainsi comprimés.
En corollaire, le procédé comprend, au niveau du module d'identité d'abonné, les étapes suivantes : -1) recevoir les codes ainsi comprimés en provenance du poste émetteur, et les réassembler ;
-2) reconnaître dans les données ainsi réassemblées les séquences d'octets non dupliquées et les séquences de compression ; et -3) ranger chaque séquence d'octets non dupliquée dans une table de décompression à une adresse respective, et remplacer au moins une séquence de compression par la séquence d'octets non dupliquée correspondante se trouvant dans la table de décompression à l'adresse indiquée dans la séquence de compression, et obtenir ainsi des codes décomprimés.
-2) reconnaître dans les données ainsi réassemblées les séquences d'octets non dupliquées et les séquences de compression ; et -3) ranger chaque séquence d'octets non dupliquée dans une table de décompression à une adresse respective, et remplacer au moins une séquence de compression par la séquence d'octets non dupliquée correspondante se trouvant dans la table de décompression à l'adresse indiquée dans la séquence de compression, et obtenir ainsi des codes décomprimés.
Avantageusement, le procédé comprend en outre au niveau du poste émetteur l'étape suivante : - e) traiter de façon statique au moins certaines séquences d'octets desdits codes, et convertir lesdites séquences d'octets en chaînes de bits en fonction d'une règle de conversion prédéterminée, remplacer chaque séquence d'octets par sa chaîne de bits correspondante, et envoyer à l'équipement mobile d'abonné les codes ainsi convertis.
Avantageusement, les étapes d) et e) sont mises en oeuvre sensiblement simultanément, les codes envoyés à l'équipement mobile d'abonné étant à la fois convertis et comprimés.
En pratique, la règle de conversion est fonction de la fréquence des codes dans l'application à traiter.
Avantageusement, le procédé comprend en outre, au niveau du module d'identité d'abonné, l'étape suivante :
<Desc/Clms Page number 4>
-4) recevoir les codes ainsi convertis en provenance du poste émetteur, les réassembler, et remplacer au moins une chaîne de bits par la séquence d'octets correspondante selon une fonction de conversion prédéterminée.
Avantageusement, les étapes 3) et 4) sont mises en oeuvre simultanément, les codes traités au niveau du module d'identité d'abonné étant sensiblement simultanément convertis et décomprimés.
Les données peuvent être de différents types. Par exemple, lorsque les données sont des appliquettes, il est prévu selon l'invention d'équiper le poste émetteur d'un serveur d'appliquettes, et de télécharger des appliquettes auprès dudit serveur au profit du module d'identité d'abonné.
Dans un autre exemple, dans lequel les données sont des messages, le procédé selon l'invention comprend en outre une première étape supplémentaire prévoyant une passerelle reliée à un centre de gestion de messages et disposée entre l'équipement mobile et un serveur d'applications distant, et une seconde étape supplémentaire prévoyant l'utilisation au niveau de l'équipement mobile d'abonné, du centre de gestion, de la passerelle et du serveur d'applications, d'un protocole de communication selon lequel l'équipement mobile est apte à obtenir les codes d'une application désirée à la suite d'une requête auprès du serveur distant via ledit centre de gestion de messages et ladite passerelle, la passerelle comprimant les messages au moins selon les étapes c) et d) du procédé mentionnées ci-avant.
La présente invention a également pour objet un dispositif de traitement de données ainsi qu'un module d'identité d'abonné pour la mise en oeuvre du procédé selon l'invention.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ciaprès et les dessins dans lesquels :
<Desc/Clms Page number 5>
- la figure 1 représente schématiquement l'architecture du dispositif de traitement selon l'invention ; - la figure 2 est un organigramme illustrant la compression dynamique selon l'invention ;
- la figure 3 est un organigramme illustrant la compression statique selon l'invention ; - la figure 4 est un organigramme illustrant la décompression dynamique selon l'invention ; et la figure 5 illustre la décompression statique selon l'invention.
- la figure 3 est un organigramme illustrant la compression statique selon l'invention ; - la figure 4 est un organigramme illustrant la décompression dynamique selon l'invention ; et la figure 5 illustre la décompression statique selon l'invention.
En référence à la figure 1, on a représenté un dispositif de traitement de messages SMS selon l'invention trouvant par exemple une application dans le réseau de téléphonie mobile de type GSM de seconde génération.
Dans ce réseau, un terminal mobile d'abonné 2 est capable d'accéder à des services ou applications 6 (appliquettes) stockés sur un serveur d'applications distant 4.
Par exemple, les applications 6 sont des pages écrites en langage WML pour"Wireless Markup language, c'est-à-dire un langage de balises sans fil qui est un langage de description de contenu pour les petits équipements portatifs sans fil. En variante, les applications sont écrites en langage SATML pour "Simalliance Toolkit Markup Langage", c'est-à-dire un langage de balises selon une boîte à outils de la société Simalliance. Cette société, fondée en 2000, écrit des spécifications techniques permettant de mettre en commun les avantages du monde de l'internet et celui du monde des téléphones portables et plus particulièrement les modules d'identité d'abonné, appelés encore cartes SIM pour"Subscri-
ber identity module". Les spécifications techniques les plus significatives sont disponibles à l'adresse http ://www. simalliance. org/.
ber identity module". Les spécifications techniques les plus significatives sont disponibles à l'adresse http ://www. simalliance. org/.
<Desc/Clms Page number 6>
Le terminal 2 de l'abonné peut accéder à des pages du réseau Internet à partir d'un simple équipement de communication mobile 2 ne contenant pas de navigateur de type WAP pour wireless Application Protocol, c'est-à-dire Protocole d'Application sans fil). En effet, contrairement à ce type d'équipement mobile, où le navigateur de pages est incorporé dans le terminal téléphonique, le terminal 2 de l'invention comprend un navigateur 8 de type SIM TOOLKIT (ou Boîte à outils pour module d'identité d'abonné) tel que décrit dans la spécification GSM 11.14.
Lorsqu'un abonné souhaite obtenir un service ou une application 6 telle qu'une page d'un site internet, le terminal 2 émet une requête 10 au format SMS tel que décrit dans les spécifications GSM 11.14, 03. 48, et 03.40, et S@T (Simalliance toolbox specifications) 01.22, 01.20. Cette requête 10 est transmise via le centre de gestion 12 des messages SMS du réseau GSM jusqu'à une passerelle 14 qui s'occupe de transmettre ce genre de requête 10 vers le serveur distant 4 implanté sur le réseau Internet qui héberge la page demandée.
Ensuite, le contenu de la page 16 est renvoyé à la passerelle 14 qui encode celle-ci et passe le code interprétable 20 ainsi généré au centre de gestion 12 des messages SMS de l'opérateur de téléphonie de l'abonné. Le centre de gestion 12 se charge alors de transmettre la page encodée 22 au terminal 2, dont l'interpréteur 24 est apte à interpréter le code interprétable ainsi reçu.
Le Demandeur a observé que, pour réduire le temps d'attente de l'utilisateur, il convient de diminuer la taille des données transmises par le serveur 12 sur le canal SMS du réseau GSM en direction des terminaux de communication mobile 2.
Pour atteindre cet objectif, le flot de données résultant de l'encodage de la page au niveau de la passerelle 14 est compressée et décompressée de façon complémentaire au niveau du module d'abonné de l'équipement mobile.
<Desc/Clms Page number 7>
En référence à la figure 2, l'organigramme de l'algorithme de compression au niveau de la passerelle selon l'invention comprend les étapes suivantes.
Dans l'étape El, on lit les codes de l'application 16 (bytecode) en provenance du serveur d'applications 4 et on traite de façon dynamique au moins certaines séquences d'octets contenues dans lesdits codes. De préférence, on traite tous les octets.
Dans l'étape E2, on reconnaît dans ces séquences d'octets les séquences d'octets dupliquées à l'identique au moins deux fois.
Dans l'étape E3, pour au moins une séquence dupliquée, on définit une séquence de compression, et on mémorise cette séquence de compression à une adresse choisie dans une table de compression.
Dans l'étape E4, on remplace au moins une séquence dupliquée dans le message original par l'adresse de la séquence de compression correspondante, et on envoie à l'équipement mobile les codes ainsi comprimés.
En d'autres termes, on détecte de façon dynamique les groupes de motifs redondants. Concrètement, une table ou dictionnaire est construit au fur et à mesure de la lecture du fichier.
L'algorithme apprend les motifs du fichier durant la lecture.
Lorsqu'une chaîne de caractères déjà lue est détectée, on code alors non plus cette chaîne mais son adresse dans une table.
En pratique, on commence à lire le texte et on le stocke dans une mémoire tampon. A chaque nouveau caractère lu, on regarde si ce dernier existe dans la table. S'il n'y est pas, on l'ajoute à la table. S'il est présent, on écrit alors son adresse dans le fichier compressé plus une balise indiquant qu'il s'agit d'une adresse et on regarde si les caractères suivants coïncident.
<Desc/Clms Page number 8>
Par exemple, la table a une capacité de l'ordre de 512 octets. Il s'agit d'une table écrite en mémoire RAM. Dès que la table dépasse cette limite, on repart au début de la table.
La compression selon l'invention peut être mise en oeuvre sur un texte écrit en hexadécimal ayant par exemple la teneur suivante"ABCDEF12345678ABCDEF1234".
A l'étape 0, la mémoire tampon est initialisée à 000... 0.
A l'étape 1, l'octet AB n'appartenant pas à la mémoire tampon, la mémoire tampon est égal à AB000... 0.
A l'étape 2, l'octet CD n'appartenant pas à la mémoire tampon, la mémoire tampon contient maintenant ABCD000... 0, et ainsi de suite jusqu'à l'étape 8 où l'octet 78 n'appartenant pas, la mémoire tampon contient ABCDEF12345678000... 0 A l'étape 15 : ABCDEF1234 appartient à la mémoire tampon. On écrit alors le texte lu au préalable avec un indice sur le nombre d'octets écrits et une balise (tag) indiquant le nombre d'octets redondants et leur adresse.
Le fichier ainsi compressé devient 07ABCDEF123456788A0000. Le fichier comprend une balise de tête BAI et une balise de queue BA2.
La balise de tête BAI est une balise qui localise le texte non compressé et sa taille. Par exemple, la balise BAI est codée selon un format (un octet) dans lequel le premier bit est à 0 pour indiquer que le texte à suivre n'est pas compressé, et les bits 2 à 8 indiquent la taille du texte à suivre. Dans l'exemple, la balise BAI est égale à"07" indiquant ainsi que les sept octets à suivre ne sont pas compressés.
La balise de queue BA2 est une balise qui signale la séquence de compression et son adresse dans la table. Cette balise BA2
<Desc/Clms Page number 9>
est codée par exemple sur deux octets. Le premier bit à 1 indique qu'il s'agit d'une adresse. Les second à septième bits du premier octet indique le nombre d'octets consécutifs et les huitième à seizième bits est l'adresse dans la mémoire tampon. Par exemple, la balise BA2 égale à"8AOO"signifie qu'il y a cinq octets redondants à l'adresse 0.
En référence à la figure 3, l'algorithme de compression selon l'invention comprend également une boucle de traitement statique.
Dans cette boucle, on traite de façon statique au moins certaines séquences d'octets des codes (étape E10).
Ensuite (étape Elm), on convertit lesdites séquences d'octets en chaînes de bits en fonction d'une règle de conversion prédéterminée.
Dans l'étape E12, on remplace chaque séquence d'octets par sa chaîne de bits correspondante et on envoie à l'équipement mobile les codes ainsi convertis.
Cet algorithme statique est plus simple que l'algorithme dynamique décrit en référence à la figure 2.
Pour des raisons d'efficacité, la compression statique est effectuée après la compression dynamique. En effet, la compression dynamique ne compresse pas ou très peu les balises (tags) utilisées dans les fichiers traités, tels que les fichiers DECK décrits dans les spécifications de Simalliance. Ces balises sont communes à tous les fichiers et ont donc une fréquence d'apparition plus élevée que les autres.
Une évaluation statistique de la fréquence d'apparition de ces balises peut être calculée au préalable. On élabore ensuite une table où chaque caractère est codé sur un nombre de bits inversement proportionnel à sa fréquence.
Il est à remarquer que les codes interprétables (bytecode), ici balises, caractères ou autres sont généralement codés sur
<Desc/Clms Page number 10>
un octet. La conversion des séquences d'octets des bytecodes en chaîne de bits de taille inférieure à 8 bits a pour conséquence de reconvertir tous les bytecodes.
Par exemple, l'octet FF peut être représenté par la chaîne de bits 11. Afin de différencier cette chaîne des autres pendant le décodage, aucun des caractères restants ne pourra commencer par cette chaîne. Il conviendra donc de coder à nouveau les caractères commençant pas 11. Pour cela, il est nécessaire d'attribuer des poids à chaque caractère restant.
Une fois que la partie du fichier ou texte comportant des balises est traitée, il est possible de s'intéresser aux pages composées de texte écrites dans une langue donnée.
Cependant, contrairement à la partie taggée (avec balises) des fichiers, il n'est pas possible de connaître a priori le langage utilisé dans le texte.
En pratique, on place les caractères de ponctuation en tête de fichier dans la mesure où beaucoup de langues ont une ponctuation commune. Ensuite, on considère que la langue anglaise est la plus couramment utilisée et par conséquent on code les caractères en fonction de leur fréquence d'apparition dans ce langage. Il est possible aussi de stocker la table statique dans la mémoire EEPROM du module d'identité d'abonné afin de permettre à chaque opérateur de calculer cette table en fonction du pays et de la langue de l'utilisateur.
En référence à la figure 4, l'algorithme de décompression est symétrique à la compression.
Dans l'étape E20, on reçoit les codes ainsi comprimés en provenance de la passerelle 14, via le centre de gestion 12, et on les réassemble car ils n'arrivent pas nécessairement dans le bon ordre. En d'autres termes, le fichier compressé est écrit en mémoire EEPROM dans son intégralité et décompressé ensuite.
<Desc/Clms Page number 11>
Dans l'étape E21, on reconnait dans le message ainsi réassemblé les séquences d'octets non dupliquées et les séquences de compression.
Dans l'étape E22, on range chaque séquence d'octets non dupliquée dans une table de décompression à une adresse respective, et on remplace au moins une séquence de compression par la séquence d'octets non dupliquée correspondante se trouvant dans la table de décompression à l'adresse indiquée dans la séquence de compression, et on obtient ainsi des codes décomprimés.
En pratique, la table de décompression est construite en mémoire vive. Une balise informe la nature de la séquence d'octets, c'est-à-dire adresse (séquence de compression) ou caractère (séquence non dupliquée). Si c'est une adresse, la valeur correspondante est lue dans la table de décompression et on continue le traitement. Par contre, s'il s'agit d'un caractère formant texte, ce texte est ajouté à la table de décompression.
En pratique, le fichier à traiter est écrit à la place où sera stocké le fichier décompressé. Le fichier à traiter est écrasé progressivement par le texte décompressé. Les fichiers sont par conséquent décompressés par la fin de manière à ce que la partie décompressée ne puisse écraser une partie utile du fichier compressé.
Il est à noter que la notion dynamique de la création de la table de décompression est importante en terme de capacité mémoire car cette table dynamique n'est pas ajoutée au fichier compressé. En effet, cette table contient non seulement l'information sur la redondance des motifs, mais également l'information sur le contenu du texte.
En référence à la figure 5, la décompression du traitement statique se fait de manière symétrique.
<Desc/Clms Page number 12>
Selon l'étape E30, on reçoit les codes ainsi convertis de l'application désirée, on les réassemble, et on remplace au moins une chaîne de bits par la séquence d'octets correspondante selon une fonction de conversion prédéterminée.
Une table contient la valeur de chaque caractère converti afin de permettre la décompression et retrouver le texte initial.
Avantageusement, il est prévu de combiner les traitements statique et dynamique dans une même boucle, ce qui réduit considérablement la taille du code et le temps de décompression.
Il se peut que la compression ne soit pas efficace dans le cas de fichiers de petite taille (inférieure à 100 octets) et que le résultat donne un fichier de taille supérieure au fichier initial. Dans ce cas, une balise indique que la décompression n'est pas nécessaire et le fichier est envoyé non compressé.
Les performances de l'invention permettent d'obtenir un gain moyen de l'ordre de 34 % avec 0 % pour un fichier très court (64 octets) à 50 % pour un fichier de 900 octets. En moyenne, la partie dynamique de la compression permet un gain de l'ordre de 25 % et les 10 % restants résultent de la partie statique.
Au niveau de la décompression, la capacité mémoire requise est d'environ 1100 octets dont 575 sont attribués au stockage du tableau de fréquence d'apparition des caractères. La table construite en mémoire vive peut requérir 512 octets.
Dans la description, on a décrit en détail un exemple dans lequel les données traitées sont des messages échangés entre un navigateur de pages WML/S@Tml installé sur une carte SIM et un serveur de contenu situé sur le réseau internet.
L'invention peut aussi s'appliquer à d'autres types de données. Par exemple, les données peuvent être aussi des
<Desc/Clms Page number 13>
appliquettes à télécharger. Dans ce cas, la passerelle 14 est remplacée par un poste émetteur qui comprend un serveur d'appliquettes auprès duquel le module d'identité d'abonné télécharge"over the air"des appliquettes. Dans cet exemple, la compression selon l'invention est mise en place directement au niveau du serveur d'appliquettes.
Claims (15)
1. Procédé de traitement de données pour un équipement mobile de communication (2) équipé d'un module d'identité d'abonné (8), lesdites données comprenant des codes appartenant à une application écrite en langage évolué en provenance d'un poste émetteur distant (4,14), le procédé étant du type comprenant les étapes suivantes : - a) équiper le module d'identité d'abonné (8) d'un interpréteur (24) apte à interpréter les codes d'une application écrite en langage évolué ; - b) équiper le module d'identité d'abonné (8) et le poste émetteur (4,14) d'un protocole de communication selon lequel l'équipement mobile (2) est apte à obtenir les codes d'une application désirée en provenance dudit poste émetteur, caractérisé en ce qu'il comprend en outre les étapes suivantes, au niveau du poste émetteur (4,14) : - c) traiter de façon dynamique au moins certaines séquences d'octets contenues dans lesdits codes de manière à reconnaître dans ces séquences d'octets, les séquences d'octets dupliquées à l'identique au moins deux fois, - d) pour au moins une séquence dupliquée, définir une séquence de compression, et mémoriser cette séquence de compression à une adresse choisie dans une table de compression, remplacer au moins une séquence dupliquée dans les données d'origine par l'adresse de la séquence de compression correspondante, et envoyer à l'équipement mobile d'abonné (2) les codes ainsi comprimés.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre au niveau du module d'identité d'abonné, les étapes suivantes :
<Desc/Clms Page number 15>
-1) recevoir les codes ainsi comprimés en provenance du poste émetteur (4, 14), et les réassembler ; -2) reconnaître dans le message ainsi réassemblé les séquences d'octets non dupliquées et les séquences de compression ; -3) ranger chaque séquence d'octets non dupliquée dans une table de décompression à une adresse respective, et remplacer au moins une séquence de compression par la séquence d'octets non dupliquée correspondante se trouvant dans la table de décompression à l'adresse indiquée dans la séquence de compression, et obtenir ainsi des codes décomprimés.
3. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre, au niveau du poste émetteur (4,14), les étapes suivantes : e) traiter de façon statique au moins certaines séquences d'octets desdits codes, et convertir lesdites séquences d'octets en chaînes de bits en fonction d'une règle de conversion prédéterminée, remplacer chaque séquence d'octets par sa chaîne de bits correspondante, et envoyer à l'équipement mobile les codes ainsi convertis.
4. Procédé selon les revendications 1 et 3, caractérisé en ce que les étapes d) et e) sont mises en oeuvre simultanément.
5. Procédé selon la revendication 4, caractérisé en ce que la règle de conversion est fonction de la fréquence dans l'application à traiter des codes interprétés.
6. Procédé selon les revendications 2 et 3, caractérisé en caractérisé en ce qu'il comprend en outre au niveau du module d'identité d'abonné l'étape suivante : -4) recevoir les codes ainsi convertis de l'application désirée en provenance du poste émetteur (4,14), les réassembler, et remplacer au moins une chaîne de bits par la
<Desc/Clms Page number 16>
séquence d'octets correspondante selon une fonction de conversion prédéterminée.
7. Procédé selon les revendications 3 et 6, caractérisé en ce que les étapes 3) et 4) sont mises en oeuvre simultanément.
8. Procédé selon l'une des revendications précédentes, dans lequel les données sont des appliquettes, caractérisé en ce qu'il est prévu d'équiper le poste émetteur d'un serveur d'appliquettes (4), et de télécharger des appliquettes auprès dudit serveur (4) au profit du module d'identité d'abonné.
9. Procédé selon la revendication 1 ou la revendication 3, dans lequel les données sont des messages, caractérisé en ce qu'il comprend en outre une première étape supplémentaire prévoyant une passerelle (14) reliée à un centre de gestion de messages (12) et disposée entre l'équipement mobile (2) et un serveur d'applications distant (4), et une seconde étape supplémentaire prévoyant l'utilisation au niveau de l'équipement mobile d'abonné (2), du centre de gestion (12), de la passerelle (14) et du serveur d'applications (4), d'un protocole de communication selon lequel l'équipement mobile (2) est apte à obtenir les codes d'une application désirée à la suite d'une requête auprès du serveur distant (4) via ledit centre de gestion de messages (12) et ladite passerelle (14), la passerelle étant propre à comprimer les données selon les étapes c) et d).
10. Dispositif de traitement de données pour un équipement mobile de communication (2) équipé d'un module d'identité d'abonné (8), lesdites données comprenant des codes appartenant à une application écrite en langage évolué en provenance d'un poste émetteur distant (4,14), le dispositif étant du type comprenant : - un module d'identité d'abonné (8) comportant un interpréteur (24) apte à interpréter les codes d'une application écrite en langage évolué,
<Desc/Clms Page number 17>
- un poste émetteur (4, 14) comportant des moyens de communication équipés d'un protocole de communication selon lequel l'équipement mobile (2) est apte à obtenir lesdits codes en provenance dudit poste émetteur (4,14), caractérisé en ce qu'il comprend en outre des moyens de traitement-poste émetteur (18) aptes à traiter de façon dynamique au moins certaines séquences d'octets contenues dans lesdits codes, à reconnaître dans ces séquences d'octets les séquences d'octets dupliquées à l'identique au moins deux fois, pour au moins une séquence dupliquée, à définir une séquence de compression, et à mémoriser cette séquence de compression à une adresse choisie dans une table, à remplacer au moins une séquence dupliquée dans le message original par l'adresse de la séquence de compression correspondante, et en ce que les moyens de communication du poste émetteur sont aptes en outre à envoyer à l'équipement mobile (2) les codes ainsi comprimés.
11. Dispositif selon la revendication 10, caractérisé en ce que les moyens de traitement du poste émetteur (18) sont aptes en outre à traiter de façon statique au moins certaines séquences d'octets desdits codes interprétés, à convertir lesdites séquences d'octets en chaînes de bits en fonction d'une règle de conversion prédéterminée, à remplacer chaque séquence d'octets par sa chainede bits correspondante, et en ce que les moyens de communication du poste émetteur sont en outre aptes à envoyer à l'équipement mobile (2) les codes ainsi convertis.
12. Dispositif selon l'une des revendications 10 ou 11, caractérisé en ce que les données sont des appliquettes, en ce que le poste émetteur est un serveur d'appliquettes (4), et en ce que le module d'identité d'abonné est apte à télécharger des appliquettes auprès dudit serveur (4).
13. Dispositif selon l'une des revendications 10 ou 11, dans lequel les données sont des messages, caractérisé en ce que le poste émetteur est une passerelle (14) reliée à un centre
<Desc/Clms Page number 18>
de gestion de messages (12) et disposée entre l'équipement mobile (2) et un serveur d'applications distant (4), en ce que l'équipement mobile d'abonné (2), le centre de gestion (12), la passerelle (14) et le serveur d'applications (4) utilisent un protocole de communication selon lequel l'équipement mobile (2) est apte à obtenir les codes d'une application désirée à la suite d'une requête auprès du serveur distant (4) via ledit centre de gestion de messages (12) et ladite passerelle (14), et en ce que la passerelle comprend les moyens de traitement aptes à comprimer les données de façon dynamique et/ou statique.
14. Module d'identité d'abonné pour dispositif de traitement de données selon la revendication 10, caractérisé en ce qu'il comprend en outre des moyens de traitement (8) aptes à recevoir les codes ainsi comprimés de l'application désirée, à les réassembler, à reconnaître dans le message ainsi réassemblé les séquences d'octets et les séquences de compression, à ranger chaque séquence d'octets dans une table de décompression à une adresse respective, et à remplacer au moins une séquence de compression par la séquence d'octets correspondante se trouvant dans la table de décompression à l'adresse correspondante.
15. Module selon la revendication 11, caractérisé en ce que les moyens de traitement (8) sont aptes en outre à recevoir les codes ainsi convertis de l'application désirée, à les réassembler, et à remplacer au moins une chaîne de bits par la séquence d'octets correspondante selon une fonction de conversion prédéterminée.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0104643A FR2823389A1 (fr) | 2001-04-05 | 2001-04-05 | Procede et dispositif de compression et de decompression de codes d'une application ecrite en langage evolue, notamment en telephonie mobile |
| AU2002249504A AU2002249504A1 (en) | 2001-04-05 | 2002-04-04 | Compression of codes of an application written in high-level language, for use in mobile telephony. |
| PCT/IB2002/001061 WO2002082261A2 (fr) | 2001-04-05 | 2002-04-04 | Procede et dispositif de compression et de decompression de codes d'une application, ecrit en langage evolue, specialement pour la telephonie mobile. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0104643A FR2823389A1 (fr) | 2001-04-05 | 2001-04-05 | Procede et dispositif de compression et de decompression de codes d'une application ecrite en langage evolue, notamment en telephonie mobile |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2823389A1 true FR2823389A1 (fr) | 2002-10-11 |
Family
ID=8861984
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0104643A Pending FR2823389A1 (fr) | 2001-04-05 | 2001-04-05 | Procede et dispositif de compression et de decompression de codes d'une application ecrite en langage evolue, notamment en telephonie mobile |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2823389A1 (fr) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998011744A1 (fr) * | 1996-09-16 | 1998-03-19 | Nokia Telecommunications Oy | Service de transmission de donnees pour reseau de communications radiomobiles |
| EP0928070A2 (fr) * | 1997-12-29 | 1999-07-07 | Unwired Planet, Inc. | Compression de documents HTML préservant la structure syntaxique |
| US6079020A (en) * | 1998-01-27 | 2000-06-20 | Vpnet Technologies, Inc. | Method and apparatus for managing a virtual private network |
| WO2000070770A1 (fr) * | 1999-05-13 | 2000-11-23 | Euronet Uk Limited | Procede de compression/decompression |
| WO2001003456A1 (fr) * | 1999-07-05 | 2001-01-11 | Sila Technology Limited | Procede de transmission d'elements de donnees vers plusieurs stations mobiles, station mobile et module de stockage |
-
2001
- 2001-04-05 FR FR0104643A patent/FR2823389A1/fr active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998011744A1 (fr) * | 1996-09-16 | 1998-03-19 | Nokia Telecommunications Oy | Service de transmission de donnees pour reseau de communications radiomobiles |
| EP0928070A2 (fr) * | 1997-12-29 | 1999-07-07 | Unwired Planet, Inc. | Compression de documents HTML préservant la structure syntaxique |
| US6079020A (en) * | 1998-01-27 | 2000-06-20 | Vpnet Technologies, Inc. | Method and apparatus for managing a virtual private network |
| WO2000070770A1 (fr) * | 1999-05-13 | 2000-11-23 | Euronet Uk Limited | Procede de compression/decompression |
| WO2001003456A1 (fr) * | 1999-07-05 | 2001-01-11 | Sila Technology Limited | Procede de transmission d'elements de donnees vers plusieurs stations mobiles, station mobile et module de stockage |
Non-Patent Citations (2)
| Title |
|---|
| ECK P ET AL: "A new compression scheme for syntactically structured messages (programs) and its application to Java and the Internet", DATA COMPRESSION CONFERENCE, 1998. DCC '98. PROCEEDINGS SNOWBIRD, UT, USA 30 MARCH-1 APRIL 1998, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 30 March 1998 (1998-03-30), pages 542, XP010276586, ISBN: 0-8186-8406-2 * |
| GIRARDOT M ET AL: "Millau: an encoding format for efficient representation and exchange of XML over the Web", COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 33, no. 1-6, June 2000 (2000-06-01), pages 747 - 765, XP004304805, ISSN: 1389-1286 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0559593B1 (fr) | Procédé et dispositif de compression et décompression de données pour un système de transmission | |
| US6883035B2 (en) | System and method for communicating with temporary compression tables | |
| US6985965B2 (en) | Static information knowledge used with binary compression methods | |
| US9087070B2 (en) | System and method for applying an efficient data compression scheme to URL parameters | |
| FR2857538A1 (fr) | Systeme et methode de compression d'en-tete de paquets bases sur la creation dynamique d'un gabarit | |
| US20020078241A1 (en) | Method of accelerating media transfer | |
| US20050027731A1 (en) | Compression dictionaries | |
| EP0493286A1 (fr) | Système de transmission par paquets à compression de données, procédé et équipement correspondant | |
| US7640362B2 (en) | Adaptive compression in an edge router | |
| US6963587B2 (en) | Communication system and method utilizing request-reply communication patterns for data compression | |
| CN103346800B (zh) | 一种数据压缩方法及装置 | |
| US10817460B2 (en) | RDMA data sending and receiving methods, electronic device, and readable storage medium | |
| CA2428788C (fr) | Connaissance d'informations statiques utilisee avec des procedes de compression binaire | |
| US9294125B2 (en) | Leveraging language structure to dynamically compress a short message service (SMS) message | |
| CN112866196B (zh) | 一种短波数字信号解译还原方法 | |
| CN115499506B (zh) | 一种基于lzw算法的mqtt信息传输数据压缩方法及服务器 | |
| FR2823389A1 (fr) | Procede et dispositif de compression et de decompression de codes d'une application ecrite en langage evolue, notamment en telephonie mobile | |
| CN110519656B (zh) | 自适应流媒体的播放方法、系统以及服务器 | |
| WO2002089486A2 (fr) | Procede et systeme de compression et de distribution video | |
| EP1525663B1 (fr) | Compression de donnees numeriques robuste au bruit de transmission | |
| EP1613103B1 (fr) | Procédé de détection de messages redondants dans un flot de messages | |
| JP4456574B2 (ja) | 圧縮データ送信方法 | |
| CN115190182B (zh) | 一种适用于北斗系统的数据无损压缩方法、装置及设备 | |
| CN114726615B (zh) | 一种基于音频编码变换的VoIP隐蔽通道构建方法与系统 | |
| WO2002082261A2 (fr) | Procede et dispositif de compression et de decompression de codes d'une application, ecrit en langage evolue, specialement pour la telephonie mobile. |