EP1642439A1 - Procede de transmission d informations supplementaires par c ompression d en-tete - Google Patents

Procede de transmission d informations supplementaires par c ompression d en-tete

Info

Publication number
EP1642439A1
EP1642439A1 EP04741935A EP04741935A EP1642439A1 EP 1642439 A1 EP1642439 A1 EP 1642439A1 EP 04741935 A EP04741935 A EP 04741935A EP 04741935 A EP04741935 A EP 04741935A EP 1642439 A1 EP1642439 A1 EP 1642439A1
Authority
EP
European Patent Office
Prior art keywords
packets
transmission
channel
additional information
information
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.)
Ceased
Application number
EP04741935A
Other languages
German (de)
English (en)
Inventor
Catherine Lamy
Pierre Vila
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from FR0308235A external-priority patent/FR2857182B3/fr
Application filed by Thales SA filed Critical Thales SA
Publication of EP1642439A1 publication Critical patent/EP1642439A1/fr
Ceased legal-status Critical Current

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
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/22—Parsing or analysis of headers
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • 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/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the invention relates to a device and method for transmitting information between two layers of a network stack. It applies in the field of transmissions with losses due to the transmission medium (eg wireless transmissions). It applies in any data transmission system comprising a header compression and / or decompression mechanism.
  • the key point then consists in appropriately using the redundancy of the residual source for the decoding part.
  • This redundancy can be considered as a form of implicit channel protection by the decoder and can be exploited in order to offer an error correction capacity.
  • the joint source-channel coding techniques can be easily implemented by exchanging the information between the different blocks, as shown in FIG. 1.
  • the reference 5 designates the transmission channel.
  • data on the sensitivity of the source to channel errors (Source Significance Information or SSI) can be transmitted from the source coder to the channel coder in order to allow the application of techniques such as uneven protection.
  • the internal decoder In order to allow flexible decoding, the internal decoder must provide a flexible output to the external decoder and vice versa in the case of iterative decoding. Consequently, on the receiver side, the flexible outputs of the channel and the CSI information relating to both the amplitude of the fading and the noise, can be supplied by the channel to the channel decoder which will carry out the channel decoding at flexible input and output (Soft Input Soft Output or SISO).
  • SISO Soft Input Soft Output
  • the flexible output of the channel decoder or the decoder reliability information (DRI) will be transmitted to the source decoder which will perform source decoding with flexible inputs and provide a flexible output for source information , ie the posterior information of the source (Source A posteriori information or SAI) can be retransmitted with the channel decoder to carry out the decoding of channel controlled by the source and possibly the iterative decoding source-channel.
  • SAI posterior information of the source
  • SAI the source and channel coders / decoders are often devices belonging to a network which cannot exchange information because of the protocol layers 6 which separate them, as illustrated in FIG. 2. exchange between decoders must pass through different levels of network protocols.
  • this transmitted sequence is composed of the useful data framed by headers and possibly packet terminations (e.g. control fields such as CRC cyclic rendering codes). More explicitly, the transmission of data in the downward direction (from the application level to the network access level) through the protocol stack will consist of each layer transition in the execution of the following steps [1]:
  • the uplink transmission through the protocol stack will consist of each layer transition to:
  • this “transparency for the network” solution is based on the presence of adaptive layers which make it possible to take into account existing QoS quality of service mechanisms, and on the validation of the concept in a Berkeley Software environment. Linux distribution.
  • Such a solution has the advantage of being able to adapt to any protocol stack and to any network. However, it requires having a perfect knowledge of the protocol stack in terms of network access and application. It is moreover quite complex because it obliges to decapsulate once again at the level of the physical layer to modify the transmitted data.
  • Header compression Wireless links or communications are characterized by a limited bandwidth which, in practice, limits the rate of information sent or received by a user.
  • Such a connection is seen traditionally as a bottleneck (especially for BER and FER frame error rates between 10 "2 and 10 " 5 ) for data transmission as they often lead to multiple retransmissions of data, which compound the problem the narrowness of the limited band.
  • the direct transmission of IP packets over physical wireless links leads to a significant waste of the useful binary information rate, because in fact the headers of the RTP, UDP and IP layers add a significant load to the useful data. . This load can be easily reduced because these headers are often redundant, either inside the header itself or with the headers preceding or following the packet. In a real-time data context, where packets must be transmitted quickly, the charges resulting from the header can reach the size of the useful data up to several times (up to a factor of around 3).
  • the error correction mechanisms Forward Error Correction or FEC
  • FEC Forward Error Correction
  • variable header fields IP, UDP, RTP at the protocol stack level can be classified as follows:
  • INFERRED data which can be directly derived from the other header fields. They are not transmitted
  • STATIC static fields for the data transmission set. They are transmitted only once.
  • STATIC-DEF fields defining the data flow. They are managed like the STATIC classification.
  • STATIC-KNOWN fields with known values. They are not transmitted.
  • CHANGING fields whose values change regularly, either randomly or periodically. They are transmitted in full.
  • the invention proposes in particular a solution allowing the exchange of information (CSI, SSI, DRI, SAI,) between the source decoder and the channel decoder in the presence of intermediate network layers without modification of these layers. It is then possible to use the information exchanged to improve the decoding performance, for example by performing flexible decoding using the reliability information (DRI, SAI).
  • the term "downward direction” designates the transmission of information going from the application layer to the network access layer and the "upstream direction" the transmission of information from the network access layer to the application layer.
  • the invention relates to a method for exchanging data between two layers of a network stack in a data transmission system comprising a header compression and decompression mechanism. It is characterized in that it comprises at least the following stages:
  • the transmission of information flowing from the network access level to the application level comprises at least the following steps:
  • the transmission of information flowing from the application level to the network access level may include at least the following steps:
  • the method comprises for example at least the following steps:
  • the transmission of information flowing from the application level to the network access level can include at least the following steps: • differentiate the packets coming from the protocol stack into a packet stream into an initial packet stream and a packet stream d 'Additional Information,
  • the present invention notably has the following advantages:
  • FIG. 1 a generic diagram of joint channel source decoding
  • Figure 2 a joint source channel decoding on a network
  • Figure 3 a syntax principle for a packet generated by a protocol stack
  • Figure 4 the principle of the ROHC mechanism
  • Figure 5 an example of classification of header fields for an RTP / UDP / IPv4 stack
  • Figures 6A and 6B a diagram of the information transmissions on the transmitter side
  • FIGS. 7A and 7B a diagram of the information transmissions on the receiver side
  • FIGS. 8A and 8B the exchanges of information from the transmitter to the receiver
  • the FIGS. 9A and 9B the exchange of information from the receiver to the transmitter in the case of the existence of a return channel or for a bi-directional transmission
  • FIG. 9A and 9B the exchange of information from the receiver to the transmitter in the case of the existence of a return channel or for a bi-directional transmission
  • FIG. 9A and 9B the exchange of information from the receiver to the transmitter in the case of the existence of a return channel
  • FIG. 10 the processing of information at the level of the module compression / decompression
  • Figure 11 an example of generation of header fields for additional packets in an RTP / UDP / IPv4 stack
  • Figure 12 an example of classification of header fields for original packets in an RTP / UDP / IPv4 stack
  • Figures 13 and 14 two examples of extraction of additional information
  • FIG. 15 an example of application of the invention in a context of wireless transmission with header compression.
  • the additional information transmitted from the network access level to the application level is placed in valid packets generated by the header compression module in parallel with the transmission of the original data.
  • This integration within the reconstruction process assumes that the syntax to be used to construct additional packets are known and that the syntax of the reconstructed original data packets can be modified according to the user's wishes.
  • the additional information to be transmitted from the application level to the network access level is transmitted via additional packets which are intercepted by the header compression / decompression module and which are extracted for use according to the needs of the users.
  • the compression / decompression module 7 is a module suitable for implementing a header compression mode and a decompression mode, depending on the direction of information transmission.
  • FIGS. 6A and 6B describe an example of existing exchanges on the transmitter side E of the transmission having the capacity to transmit additional information.
  • the architecture of the transmitter E is similar to that described in FIG. 4, where the source coder 1 is linked to a part comprising a header compression / decompression module 7 and an encoder 2 / decoder 3 channel via a protocol stack 6 comprising several network layers (i, ... k).
  • the access layer on the transmitter side also includes a channel decoder 3 enabling it to receive and decode the return information, also called observations. of the canal.
  • the compression / decompression module 7 operates in decompression mode.
  • the observations from channel 5 are transmitted to the channel decoder 3 which generates an estimated original data packet P ⁇ St and a stream additional information quantified Supq according to techniques, an example of which is given by way of illustration and in no way limitative.
  • These two streams are transmitted to the header compression / decompression module 7 which applies standard processing to the original data packets and which transforms the additional information into additional packets compatible with the protocols transmitted to the layers.
  • the additional information contained in the packets is then used, for example, to determine the parameters of the source encoder according to the state of the channel (CSI).
  • the 6B diagrams the existing exchanges in the downward direction between the application level and the network access level.
  • the initial packets and the packets containing additional information quantified at the level of the source coder 1 are transmitted to the header compression module 7 which differentiates them for example by means of a particular header field (for example UDP port number).
  • the latter compresses the headers of the initial packets. It collects the quantified information.
  • the two streams thus generated are transmitted to the channel encoder 2 which differentiates them.
  • the header compression module retrieves the additional information quantified by extraction of the differentiated packets to transmit them directly to the channel coder, so synchronous or not synchronous with the initial packets.
  • the additional information for example SSI
  • SSI additional information
  • UEP unequal Error Protection
  • the packets containing the additional information have their headers compressed by the header compression module and transmitted to the channel 2 encoder for coding and transmission on channel 5.
  • the transmitted frames are then received and decoded at the receiver and go back to the compression / decompression module 7 of the receiver which will recognize the packets. intended for the channel decoder and will transmit them to it.
  • FIG. 7A and 7B represent the exchanges of information which take place on the side of the receiver.
  • the architecture of this receiver is similar to that of the receiver in FIG. 4.
  • FIG. 7A shows diagrammatically the exchanges in the "upstream" direction from the network access layer to the application layer.
  • the observations are received by the channel 3 decoder which generates the original estimated data (estimated useful data) and additional quantified information (for example SAI, DRI, etc.) according to methods of which an example is detailed below.
  • SAI estimated useful data
  • DRI DRI
  • These two streams are transmitted to the header compression module 7 which generates packets containing reconstructed original data and packets containing additional information. This information is typically generated by quantification of the flexible information at the output of the decoder 3.
  • FIGS. 8A and 8B represent the exchanges of information which take place from the transmitter to the receiver.
  • the architecture of this receiver is similar to that of the receiver in FIG. 4.
  • FIG. 8A diagrams the exchanges of information in the downward direction from the application layer to the network access layer.
  • the packets containing the useful data and the packets containing the additional information are transmitted to the header compression module 7.
  • the latter differentiates the additional packets and finding them intended for the receiver applies the same treatment to them as the initial data packets : at the output of the header compression module 7, an undifferentiated stream is therefore obtained at the input of the channel encoder 2, which will encode them and transmit them on channel 5.
  • Figure 8B schematically exchanges information in the uplink direction from the network access layer to the application layer. We assume here the presence of a return channel or a bi-directional transmission, therefore the presence of a channel decoder at the transmitter.
  • the observations made on the channel are supplied to the channel 3 decoder which supplies them to the decompression module.
  • This decoder is also able to supply additional quantified information (eg CSI) to the decompression module 7.
  • the decompression module 7 then processes the different streams received. It differentiates them and reconstructs the original packets, but also it generates additional packets if necessary, whose headers will be compressed by the compression module before retransmission on the channel to the receiver by the channel encoder 2.
  • FIGS. 9A and 9B represent the exchanges of information which take place from the receiver to the transmitter in the case where a return channel exists or for a bi-directional transmission.
  • the architecture of this receiver is similar to that of the receiver in Figure 4.
  • the different mechanisms described in FIGS. 8A and 8B apply respectively to FIGS. 9A and 9B.
  • FIG. 10 represents the processing of the additional information at the level of the compression / decompression module.
  • This treatment is similar for the transmitter or for the receiver. The difference being is the application module targeted: source coder 1 or source decoder 2.
  • the undifferentiated data stream coming from channel 5 is received and decoded by the channel decoder 3 and transmitted to module 7 for decompression of head. This differentiates the packets, reconstructs the original data packets and, as the case may be, transmits the additional information (e.g. coding parameters) to the channel 2 coder or to the channel 3 decoder or generates additional packets containing the additional information for the ascent to the application layer.
  • additional information e.g. coding parameters
  • the header compression module which traditionally performs header compression and therefore has knowledge of the packet structure, is modified to test the presence of the dedicated port: • if the presence of the dedicated port is found, the module recognizes the additional packet as such and eliminates it from the data flow. The useful part of the data is then extracted to be used by the channel decoder (demodulator, etc.) • if the port is not a dedicated port, the classic mechanism is applied.
  • the header compression mechanism is based on the fact that the variable header fields IP, UDP, RTP in the protocol stack have a fixed syntax which can be easily reconstructed from partial information (typically the STATIC, STATIC-DEF and CHANGING classes).
  • the reconstruction mechanism by the header compression module (operating in decompression mode) can also, in parallel with the initial data flow, reconstruct additional packets from the same header fields .
  • the principle, illustrated below in the case of IPv4 naturally remains valid in the case of IPv ⁇ .
  • Figure 1 shows an example of the application of this principle with 3 classes of header fields: RECOPIED: corresponds to the fields which are directly copied from valid data packets.
  • these fields mainly belong to the STATIC, STATIC-DEF and STATIC-KNOWN classes but can also be of the CHANGING class, copied such as (for example the time label or timestamp), INFERRED (deduced): as in the process ROHC process, these fields are derived directly from the other header fields, SPECIFICALLY DERIVED (calculated specifically): these fields are those which are specially modified to allow the transmission of additional information.
  • RECOPIED ⁇ Ver, Hd.L, TdeS, Identification, R, M, L, offset, TTL, Protocol, Source Address, Destination address (IPv4), Source Port (UDP), Ver, P, E, CCnt, M, P.Type, Timestamp, Identification Source Synchronization (SSRC) Identification Source Contribution 1 st , CSRC, Identification Source Contribution last)
  • Modification of the original packages according to the user's needs It is possible for the user to modify the headers of the initial packages.
  • the method for reconstructing the headers can be adapted to specific transmission needs with additional information.
  • the checksum on the useful part of the data (UDP checksum) can be neutralized for example by being set to zero. In this case, an error in the useful part of the data will not lead to elimination of this packet, the useful part of which can be corrected by flexible source decoding.
  • Figure 12 shows an example of changing the classification of packet headers for original packets in the RTP / UDP / IPv4 stack. Bold, italic, underlined, upper or lower case are respected between the figure and the description.
  • INFERRED ⁇ Packet 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 Synchronization (SSRC) ⁇ STATIC-KNOWN ⁇ / Hd. , R. Offset Ve ⁇ CHANGING ⁇ fTdeS. Identification. TTL CCnt.MP type.
  • the destination port can be chosen either dynamically, for example as the first port directly available above the port usually used or even be registered as a dedicated port for such a transmission, (the registration of dedicated ports defined by the IANA organization which can be found at the internet address http://www.iana.org), • the sequence number. This number can then be used to identify the initial packets of the additional packets, • the useful data part can be derived as previously detailed by quantifying the additional information.
  • the number k can be taken equal to 4 or 5.
  • the first quantization bit is for example taken equal to the hard value (estimation of the original datum) for better efficiency.
  • the format should be determined specifically between the two coders.
  • the CSI information could be coded on 4 levels, very bad, bad, good, very good, this corresponding to 2 bits of information.
  • the method according to the invention applies for example for very low speed and limited band networks.
  • it is used for wireless transmissions built on a protocol stack network with header compression such as an IP / UDP / RTP network implementing the ROHC mechanism.
  • It also applies in networks with a round trip retransmission time (Retum Time Trip or RTT) where the use of CSI information can help the behavior of the source decoder to choose between the requested retransmission or the application of cancellation techniques or other processing of the data received, depending on the probability of a chance of correctly receiving the information on the second request.
  • This method can also have advantages when information on the information flow coming from the source such as SSI information can be provided by the source coder to the decoder of the channel.
  • FIG. 15 represents an example of implementation of the invention in a combined transmission by wire / wireless transmission context where the additional information can be used for example between each user and his entry point, each being separate from the other by a low reliability transmission channel.
  • ROHC RObust Header Compression

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Time-Division Multiplex Systems (AREA)

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

Procédé de transmission d'informations supplémentaires par compression d'en-tête
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 médium 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/ou 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 classiquement réalisé grâce aux standards de compression des codes de longueur variable (VLC : codes d'Huffman, codes arithmétiques,..) et au codage de canal, à la modulation (ensemble désigné 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 de canal 2 (respectivement le décodeur de source 3 et le décodeur de canal 4) sont directement interfaces, les techniques de codage conjoint source- canal peuvent être 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 de source et de codage de 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) ou « pondérées » 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 de 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 de source à entrées souple et fournira une sortie souple pour les informations de source, c'est— à-dire l'information a posteriori de la source (Source A posteriori information ou SAI) peut être retransmise au décodeur de canal pour effectuer le décodage de canal contrôlé par la source et éventuellement le décodage itératif source-canal. Toutefois, les codeurs/décodeurs de source et de 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 il est 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 formant 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 protocolaire consistera à chaque transition de couches dans l'exécution des étapes suivantes [1] :
• Obtenir la séquence de données SLH 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 Sι_ en concaténant l'en-tête, la séquence SL+I 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 éventuelles 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'u 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 couche applicative de capturer et de filtrer les données au niveau des liaisons de données.
Toutefois, de telles solutions sont applicables uniquement localement (sur une même machine) 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ù le 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 existants. Présentée 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 de nécessiter 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 BER et de trame FER entre 10"2 et 10"5) pour la transmission de données car elles conduisent souvent à des retransmissions 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édents 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 Qusqu'à 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 divers mécanismes de correction appliqués aux codeurs de 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]. 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ériodiquement. 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 souple 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 par « sens montant » la transmission d'informations 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 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 ou du décodeur de canal 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 de source ou à une étape de décodage de 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,
• 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 :
• 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 OS1. • Elle permet de bénéficier de la connaissance des éléments disponibles au niveau de couches données 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, 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, Les figures 8A et 8B, les échanges d'information de l'émetteur vers le récepteur, Les figures 9A et 9B, les échanges d'information du récepteur vers l'émetteur dans le cas de l'existence d'un canal de retour ou pour une transmission bi-directionnelle, La figure 10, le traitement des informations au niveau du module de compression/décompression, La figure 11 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 12 un exemple de classification de champs d'en-tête pour des paquets originaux dans une pile RTP/UDP/IPv4, Les figures 13 et 14 deux exemples d'extraction d'informations supplémentaires, La figure 15 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 qui sont extraits pour être utilisés selon les besoins des utilisateurs. Le module de compression/décompression 7 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. Danse 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 E de la transmission ayant la capacité de transmettre des informations supplémentaires. L'architecture de l'émetteur E est similaire à celle décrite à la figure 4, où le codeur de source 1 est en liaison avec une partie comprenant un module 7 de compression/décompression d'en-tête et un codeur 2/décodeur 3 de canal par l'intermédiaire d'une pile protocolaire 6 comprenant plusieurs couches réseau (i,...k). Dans le cas (classique) où il existe une voie de retour ou lorsque la transmission est bi-directionnelle, la couche accès du côté émetteur comporte également un décodeur 3 de canal lui permettant de recevoir et de décoder les informations de retour, aussi appelées observations du canal. 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 7 fonctionne en mode décompression. Les observations en provenance du canal 5 sont transmises au décodeur de canal 3 qui génèrent un paquet de données d'origine estimées PΘSt et un flux d'informations supplémentaires quantifiées Supq selon des techniques dont un exemple est donné à titre illustratif et nullement limitatif. Ces deux flux sont transmis au module de compression/décompression 7 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 pour déterminer les paramètres du codeur de source en fonction de l'état du canal (CSI). 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 1 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 informations quantifiées. Les deux flux ainsi générés sont transmis au codeur de canal 2 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 3 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 2 pour codage et émission sur le canal 5. Les trames émises sont alors reçues et décodées au récepteur et remontent au niveau du module de compression/décompression 7 du récepteur qui reconnaîtra les paquets. destinés au décodeur de canal et les lui transmettra. 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 reçues par le décodeur de canal 3 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 7 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 3. 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'en- tête 7 qui génère des paquets de données utiles avec en-tête compressées et les transmet au codeur de canal 2 pour émission sur le canal 5 (dans le cas où un canal de retour existe ou lorsque la transmission est bidirectionnelle) ainsi que les informations supplémentaires quantifiées, qui peuvent être destinées soit au décodeur de canal 3 soit au codeur de canal 2 s'il existe. Les différents mécanismes décrits aux figures 6A et 6B s'appliquent respectivement pour les figures 7A et 7B. Les figures 8A et 8B représentent les échanges d'information qui se déroulent de l'émetteur vers le récepteur. L'architecture de ce récepteur est semblable à celle du récepteur de la figure 4. La figure 8A 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'en- tête 7. Celui-ci différencie les paquets supplémentaires et les trouvant destinés au récepteur leur applique le même traitement que les paquets de données initiales : en sortie du module de compression d'en-tête 7, on obtient donc un flux indifférencié à l'entrée du codeur de canal 2, qui va les coder et les transmettre sur le canal 5. L'interprétation des données supplémentaires est détaillée en Figure 10. La figure 8B schématise les échanges d'information dans le sens montant de la couche accès réseau vers la couche applicative. On suppose ici la présence d'un canal de retour ou une transmission bi-directionnelle, donc la présence d'un décodeur de canal à l'émetteur. Les observations faites sur le canal sont fournies au décodeur de canal 3 qui les fournit au module de décompression. Ce décodeur est également en mesure de fournir de l'information supplémentaire quantifiée (ex. CSI) au module de décompression 7. Le module de décompression 7 traite alors les différents flux reçus. Il les différentie et reconstruit les paquets originaux mais également il génère le cas échéant des paquets supplémentaires, dont les en-têtes seront compressées par le module de compression avant réémission sur le canal vers le récepteur par le codeur de canal 2.
Les figures 9A et 9B représentent les échanges d'information qui se déroulent du récepteur vers l'émetteur dans le cas où un canal de retour existe ou pour une transmission bi-directionnelle. L'architecture de ce récepteur est semblable à celle du récepteur de la figure 4. Les différents mécanismes décrits aux figures 8A et 8B s'appliquent respectivement aux figures 9A et 9B.
La figure 10 représente le traitement des informations supplémentaires au niveau du module de compression/décompression. Ce traitement est similaire pour l'émetteur ou pour le récepteur. La différence étant est le module applicatif visé : codeur de source 1 ou décodeur de source 2. Le flux de données indifférencié en provenance du canal 5 est réceptionné et décodé par le décodeur de canal 3 et transmis au module 7 de décompression d'en-tête. Celui-ci différencie les paquets, reconstruit les paquets originaux de données et selon les cas, transmet les informations supplémentaires (ex: paramètres de codage) au codeur de canal 2 ou au décodeur de canal 3 ou génère des paquets supplémentaires contenant l'information supplémentaire pour la remontée vers la couche application. 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 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. Le principe, illustré ci-après dans le cas d'IPv4, reste naturellement valable dans le cas d'IPvδ. La figure 1 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 : • 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), Datagra Length (UDP)} SPECIFICALLY DERIVED= {Destination Port, checksum, Séquence 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 étant mis à zéro. Dans ce cas, une erreur dans la partie utile des données ne conduira pas à une élimination de ce paquet dont la partie utile peut être corrigée grâce au décodage souple de source. La figure 12 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. , R. Offset Veή CHANGING≈fTdeS. Identification. TTL CCnt.M. P. type. Séquence 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. 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 13 . L'information b=(b1, b2, ..bn) réelle est quantifiée pour obtenir c=(cn, ...cnk) avec bi = (en, Ci2, k). 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 14. L'information supplémentaire est quantifiée selon un modèle préalablement défini par l'utilisateur. La séquence d = (ci, c2, .--., CR) 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é 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.org), • 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 (Retum 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 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 15 représente un exemple de mise en œuvre 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 édition, 1996.
[2] J.G. Proakis. Digital Communications. McGraw-Hill Book Company, New York, 3rd édition, 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 Conférence on Télécommunications (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. TCP/IP lllustrated volume 1: the protocols. Addison Wesley Professional Computing Séries, Jan. 1999.

Claims

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/ou 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 - 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 ou du décodeur de canal 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 - 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 ou du décodeur de canal 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 décodage source.
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 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 - 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 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. 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 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.
7 - Procédé selon l'une des revendications 1 à 3 caractérisé en ce que l'étape de décompression consiste à différencier les paquets provenant du canal de transmission, reconstruire les paquets originaux de données, transmettre les informations supplémentaires générées au codeur de canal ou au décodeur de canal.
8 - Procédé selon l'une des revendications 1 à 3 ou 7 caractérisé en ce que l'étape de décompression consiste à différencier les paquets provenant du canal de transmission, reconstruire les paquets originaux de données, générer des paquets supplémentaires contenant l'information supplémentaire et les transmettre vers le niveau applicatif.
EP04741935A 2003-07-04 2004-06-30 Procede de transmission d informations supplementaires par c ompression d en-tete Ceased EP1642439A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0308235A FR2857182B3 (fr) 2003-07-04 2003-07-04 Procede de transmission d'informations supplementaires par compression d'en-tete
FR0309553A FR2857194B1 (fr) 2003-07-04 2003-08-01 Procede de transmission d'informations supplementaires par compression d'en-tete
PCT/EP2004/051311 WO2005013578A1 (fr) 2003-07-04 2004-06-30 Procede de transmission d'informations supplementaires par compression d'en-tete

Publications (1)

Publication Number Publication Date
EP1642439A1 true EP1642439A1 (fr) 2006-04-05

Family

ID=33542630

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04741935A Ceased EP1642439A1 (fr) 2003-07-04 2004-06-30 Procede de transmission d informations supplementaires par c ompression d en-tete

Country Status (4)

Country Link
US (1) US20060198393A1 (fr)
EP (1) EP1642439A1 (fr)
FR (1) FR2857194B1 (fr)
WO (1) WO2005013578A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2924887B1 (fr) * 2007-12-07 2011-07-15 Thales Sa Procede et dispositif de transmission robuste d'en-tetes reseau compresses
EP3010161A1 (fr) 2010-04-01 2016-04-20 LG Electronics Inc. Multiple physical layer pipes (plb) avec information mutuelle
US9565114B1 (en) * 2014-03-08 2017-02-07 Google Inc. Weighted load balancing using scaled parallel hashing
US11019530B2 (en) * 2017-05-05 2021-05-25 The Regents Of The University Of California Trans-layer bidirectional robust header compression system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5828784A (en) * 1992-07-13 1998-10-27 Hitachi Denshi Kabushiki Kaisha Data coding method and apparatus using a plurality of blocks of different length
US6438123B1 (en) * 1998-11-10 2002-08-20 Cisco Technology, Inc. Method and apparatus for supporting header suppression and multiple microflows in a network
DE10015640A1 (de) * 2000-03-29 2001-10-04 Bosch Gmbh Robert Verfahren zur Signalisierung unterschiedlicher Kopfinformationen
FI112014B (fi) * 2000-06-28 2003-10-15 Nokia Corp Tiedonsiirtoresurssien varaus pakettivälitteisessä tiedonsiirrossa
KR100840877B1 (ko) * 2000-07-17 2008-06-24 코닌클리케 필립스 일렉트로닉스 엔.브이. 신호 코딩 방법 및 장치, 코딩된 데이터 스트림 코딩 방법 및 장치, 채널 인코딩 방법 및 채널 코더, 채널 디코딩 방법 및 채널 디코더, 및 저장 매체
US7165112B2 (en) * 2001-06-22 2007-01-16 Motorola, Inc. Method and apparatus for transmitting data in a communication system
US20050011365A1 (en) * 2001-12-11 2005-01-20 Catherine Lamy System for transmitting additional information via a network
US20050002265A1 (en) * 2003-07-01 2005-01-06 Broadcom Corporation Header compression

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005013578A1 *

Also Published As

Publication number Publication date
US20060198393A1 (en) 2006-09-07
FR2857194B1 (fr) 2005-09-09
FR2857194A1 (fr) 2005-01-07
WO2005013578A1 (fr) 2005-02-10

Similar Documents

Publication Publication Date Title
EP2218203B1 (fr) Procede et dispositif de transmission robuste d'en-tetes reseau compresses
EP1997254B1 (fr) Procede de protection de donnees multimedia au moyen de couches d'abstraction reseau (nal) supplementaires
EP2036359B1 (fr) Procede permettant de determiner des parametres de compression et de protection pour la transmission de donnees multimedia sur un canal sans fil
FR2939993A1 (fr) Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes
EP3692696B1 (fr) Signalisation d'une requête d'adaptation d'une session de communication en voix sur ip
FR2949931A1 (fr) Procedes et dispositifs de transmission d'un flux de donnees, produit programme d'ordinateur et moyen de stockage correspondants.
FR2909241A1 (fr) Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d'interconnexion de reseaux.
EP1936852A1 (fr) Système de télécommunication à adaptation de liaison
FR2939994A1 (fr) Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes
EP1642439A1 (fr) Procede de transmission d informations supplementaires par c ompression d en-tete
EP2704344B1 (fr) Méthode d'optimisation des ressources d'une transmission de données et dispositif mettant en oeuvre la méthode
JP3934073B2 (ja) リアルタイム情報の伝達システム、リアルタイム情報の送信装置、リアルタイム情報の伝達方法及びプログラム
EP1172958A1 (fr) Système de communication, émetteur, mèthode de protection contre des erreurs de transmission
FR2857182A1 (fr) Procede de transmission d'informations supplementaires par compression d'en-tete
FR2792476A1 (fr) Procede de type arq pour procede de transmission utilisant des turbo-codes, et dispositif associe
WO2008077909A2 (fr) Procede de retransmission a redondance incrementale pour des paquets fragmentes
FR2981231A1 (fr) Procede de transmission de paquets de donnees
JP2006345475A (ja) ネットワークのデータ伝送用エラー検出・訂正アーキテクチャ及び方法
WO2011077039A1 (fr) Procede de communication vocale par paquets de données avec differents niveaux de protection
FR2852180A1 (fr) Procede et systeme de protection de donnees avec en-tete dans un systeme de transmission
JP2005094661A (ja) 映像・音声の同時伝送方法ならびにシステム、および、これに用いる送信装置ならびに受信装置
JOSHI SYSTEM MANAGEMENT: Enterprise-Wide Administration
FR2957736A1 (fr) Procedes et dispositifs de transmission et de reception d'un flux de donnees, avec gestion de retransmission de donnees de parite, produit programme d'ordinateur et moyen de stockage correspondants
FR2921777A1 (fr) Procede d'acquittement hierarchique de donnees, produit programme d'ordinateur, moyen de stockage et noeud correspondants.
FR2922390A1 (fr) Procede de modification d'un paquet code, procede de transmission, procede de reception, produit programme d'ordinateur, dispositif de modification, noeud intermediaire et noeud destinataire correspondants

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060104

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20091121