Compression device wherein compression is adapted as a function of the transport medium, and associated decompression device, for communication equipments

0001The invention concerns Internet Protocol (IP) communication networks, and more precisely the compression and/or decompression of data of IP packets of streams that communication equipments exchange within such networks.

0002Here “IP communication network (or IP network)” means any type of network having an access network (where applicable a radio access network) capable of transmitting data in the form of cells, for example of ATM (Asynchronous Transfer Mode) type, on a transport medium, for example of the TCP/IP or UDP/IP type. ATM cells are the result of decomposition (or segmentation) of packets of data, for example of IP type, and those packets (here IP packets) comprise an IP header, a header specific to the transport medium (for example UDP or TCP) and payload data. The IP network can in particular be a satellite network, for example a DVB-RCS (Digital Video Broadcasting-Return Channel System) network, providing Internet access via satellite, or an SDMB (Satellite Digital Multimedia Broadcast) network, or a terrestrial network, for example a cable (xDSL) network or a mobile or cellular network (GPRS/EDGE, or UMTS (where applicable of the MBMS (Multimedia Broadcast/Multicast Services) type, or the evolution of the UMTS known as LTE (Long Term Evolution), or DVB-H (Digital Video Broadcasting-Handhelds)), or a hybrid (satellite and terrestrial) network.

0003Generally speaking, the invention applies to any unit (or terminal) that has to send cells (where applicable of ATM type) on the AAL5 layer and in time slots allocated by another remote allocation control unit (for example a gateway or a hub). In fact it is a question here of reducing the number of cells to be sent, which number depends on the size of the data and the headers of protocol(s) utilizing the UDP/IP and TCP/IP layers.

0004Moreover, here “communication equipment” means any fixed or mobile (or portable or cellular) communication equipment capable of exchanging data by cable or by waves with another equipment, via an access network (where applicable a radio access network). Consequently, it can be, for example, a question of a fixed or mobile (or cellular) telephone, a fixed or portable computer, or a satellite gateway.

0005As the person skilled in the art knows, to transmit payload data in IP networks the data is integrated into IP packets comprising at least two headers (one of IP type (generally containing 20 bytes), the other of UDP or TCP type (generally containing 20 bytes), or IGMP, ICMP, DNS or SNMP type, for example). In some cases, for example in the presence of satellite transmission on a TCP medium (known as “T/TCP”) necessitating an option field (typically of at least 8 bytes), it is also necessary to add thereto a third header known as the “AAL5 trailer” (containing 8 bytes) in order to terminate the AAL5 layer of fragmentation into cells (for example of ATM type).

0006For a standard TCP acknowledgement without options, 40 bytes (20 bytes for IP and 20 bytes for the TCP acknowledgement) are necessary to fit exactly into the portion reserved for the payload data of a fixed and delimited ATM cell of 48 bytes under AAL5 including the AAL5 trailer of a byte (40+8=48).

0007For transmission via satellite, it is further necessary to add a T/TCP “option” field of at least 1 byte (and more typically 8 bytes), which totals 56 bytes (20+20+8+8=56), which cannot fit into one ATM cell and therefore necessitates two ATM cells (one containing 48 bytes (20 (IP)+20 (TCP)+8 (options)) and the other containing 8 bytes to describe the trailer of the AAL5 PDU (Packet Data Unit).

0008For networks in which the assignment of sending locations of cells to be sent (where applicable ATM cells) is a rare and costly resource, it is clear that two cells are then necessary rather than one (a factor of 2 applies to the usable bandwidth because of the “option” field). Generally speaking, if N is the number of initial cells and N−1 the number of final cells after compression, the compression gain is given by the ratio N−1/N, which is highly significant in the case of small packets.

0009Thus when IP packets are segmented into cells, each cell must comprise the headers of the IP packet from which it comes, the consequence of which is to reduce very significantly the ratio between the payload data transported and the associated header data, and therefore to monopolize a large quantity of resources. This is a particularly severe penalty if the IP network uses an access network the resources whereof are rare and generally costly, for example in the case of a satellite network. Unless otherwise indicated, the expression “header of an IP packet” when used hereinafter means both the IP header and the header of the transport protocol (for example UDP or TCP).

0010In order to reduce the amount of data to be transmitted, compression techniques can be used at the same time. Thus the ZIP technique can be used, for example. To compress the headers, techniques such as the Van Jacobson, IPHC (RFC 2508) or ROHC (RFC 2509) techniques can be used, for example. However, these techniques are very complex to implement because of their highly generic character and lead to compression of the TCP/IP headers and its T/TCP satellite option. In fact, these techniques are primarily concerned with reducing the size of the TCP/RTP/UDP/IP headers to be sent on a channel but without considering whether this size of headers and the size of the payload data will together occupy N or N−1 containers (here N or N−1 cells).

0011Moreover, the encoding of the fields to be compressed being based primarily on the difference of the headers to be sent, it is then necessary to use delicate restart mechanisms for TCP the performance whereof in degraded mode (loss of message) is considerably reduced via a satellite access network (major impact on the round trip time).

0012Moreover, known header compression techniques are applied regardless of the type of header, and thus regardless of the lifetime of the stream to which the header belongs, which can consume computation (CPU) resources unnecessarily.

0013Finally, the known header compression techniques generally take no account of the availability of computation (CPU) resources and/or local and remote memory resources, which is a problem for low-cost communication equipments (such as mobile or portable terminals, where applicable with satellite access).

0014No known solution proving entirely satisfactory, an object of the invention is therefore to improve upon this situation.

0015To this end it proposes a device dedicated to compression of streams of packets of data, for a communication equipment constituting a transmission end point in an Internet Protocol (IP) communication network, the packets of a stream each (initially) comprising, in particular, an IP header including a destination end point identifier, a session identifier and stream attributes, and a transport protocol header, each packet being intended to be transmitted after decomposition into cells (where applicable of ATM type).

0016This compression device is characterized in that it comprises processing means responsible, if they receive a packet of a stream to be transmitted: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0017">for determining if the IP header of that packet can be compressed as a function of at least one chosen criterion, then</li><li id="ul0002-0002" num="0018">if so, for determining if the compression can lead to a reduction in the number of cells having to result from the decomposition of the received packet, and</li><li id="ul0002-0003" num="0019">if so, for replacing in the received packet at least its IP header by a compressed header comprising at least the session identifier and a compression identifier, after having transmitted beforehand (at least once) to the communication equipment constituting the destination end point of the received stream, in a partially compressed form, at least the IP header that has to be replaced.</li></ul></li></ul>

0020The compression device according to the invention can have other features, and in particular, separately or in combination:

0021its processing means can be responsible, in the presence of a TCP type transport protocol, for replacing the IP header of the received packet by a compressed header of two bytes comprising at least the session identifier, a compression identifier and a transport protocol type identifier;

0022its processing means can be responsible, in the presence of a UDP type transport protocol, for replacing the IP header and the UDP header of the received packet by a compressed header of two bytes comprising at least the session identifier, a compression identifier and a transport protocol type identifier;

0023its processing means can be responsible for determining if the header of the received packet can be compressed as a function of at least one criterion chosen from the fragmentation of the packet, the transport protocol type, a transport protocol subtype, a compression authorization received from the destination end point, and a local compression authorization;

0024its processing means can be responsible for determining first and second numbers of cells that would result from the decomposition of the packet of the stream respectively in the absence and in the presence of compression of their header, and for proceeding to the replacement of at least the IP header of the last packet received by an at least partially compressed header if the first number is strictly greater than the second number;

0025its processing means can be responsible, if they receive a packet of a stream and have decided to compress at least its IP header, i) for assigning to the stream a hashing key as a function of chosen fields of the IP header of its received packet, then ii) for determining in storage means if that hashing key is stored there, and iii) if not, for considering the stream as a new stream and then for storing the hashing key in the storage means if the session identifier that is associated with the flux is available at least from the expiry of a first time-delay, and for proceeding to the replacement of the IP header of the received packet by a partially compressed header, or if so for resetting to zero the first time-delay associated with the session identifier of the stream and for proceeding to the replacement of at least the IP header of the received packet by a compressed header;

0026its processing means can be responsible either for triggering a second time-delay associated with the stream just before proceeding to the replacement of the IP header of the received packet by a partially compressed header or, after having reset to zero the first time-delay associated with the session identifier of the stream, for determining if the second time-delay associated with this stream has expired in order either to proceed to the replacement of at least the IP header of the received packet by a compressed header if the second time-delay has not expired or to trigger a second time-delay associated with the stream just before proceeding to the replacement of the IP header of the received packet by a partially compressed header;

0027its processing means can be responsible, after having reset to zero the first time-delay associated with the session identifier of the stream and in the case of non-expiry of the second time-delay associated with that stream, for comparing to a chosen threshold the number of packets of the stream that have been successively transmitted in the form of cells with a compressed header in order either to proceed to the replacement of at least the IP header of the last packet received by the compressed header if the second time-delay has not expired or to trigger the second time-delay associated with the stream just before proceeding to the replacement of the IP header of the received packet by a partially compressed header if the number of packets is greater than or equal to the threshold;

0028its processing means can be responsible, in case of replacement of at least the IP header of a received packet by an at least partially compressed header, for determining if the payload data associated with the at least partially compressed header can be compressed as a function of at least one chosen criterion, and if so for integrating into that compressed header an identifier signaling the data compression;

0029its processing means can be responsible for determining if the payload data associated with the at least partially compressed header can be compressed as a function of at least one criterion chosen from the availability of local resources, the availability of decompression resources in the communication equipment constituting the destination end point and the size of the received packet;

0030its processing means can be responsible, in case of determination of a possibility of compression of the payload data of the packet comprising the compressed header, for determining if the data compression can lead to a reduction in the number of cells that have to result from the decompression of the packet, then, if so, for integrating into the compressed header an identifier signaling the compression of the payload data, and if not, for integrating into the compressed header an identifier signaling the prohibition on compression of the payload data.

0031The invention also proposes a device dedicated to decompression of cells (where applicable ATM cells) of a stream that has been the subject of compression by means of a compression device of the type described above, for a communication equipment constituting a transmission end point in an IP communication network.

0032This decompression device is characterized in that it comprises processing means responsible, if they receive cells of a packet of a stream:

0033for determining if those cells comprise an (the same) at least partially compressed header including in particular a compression identifier and a session identifier, then

0034if so, for determining in storage means if that session identifier is already stored therein and therefore corresponds to a known stream, then

0035if so, either for storing in the storage means the information relating to the stream if the compression identifier signals a partially compressed header, and then for reconstructing the original IP header from the partially compressed header, or, if the compression identifier signals a compressed header, for reconstructing the original header from corresponding information stored in the storage means and designated by the session identifier contained in the received compressed header.

0036The decompression device according to the invention can have other features, and in particular, separately or in combination:

0037its processing means can be responsible, if they receive cells of a packet of a stream, for beginning by determining if they concern an IP packet to be decompressed, and if so for determining if those cells comprise an at least partially compressed header only on condition that they concern chosen versions of the Internet Protocol (for example IPv4 or IPv6);

0038its processing means can be responsible, if the compression identifier signals a partially compressed header, for accessing the storage means to determine if the session identifier contained in that header is stored therein, and if not for storing the session identifier in the storage means, and then for storing in the storage means the information relating to the stream in corresponding relationship to the session identifier;

0039its processing means can be responsible, if said compression identifier signals a compressed header, for accessing the storage means to determine if the session identifier contained in that compressed header is stored therein, and if not for dropping the packet to which the received cells belong;

0040its processing means can be responsible, if the compression identifier signals a partially compressed header, for storing in the storage means the information relating to the stream of that header, then for triggering a first time-delay relating to that stream before reconstructing the original IP header from the partially compressed header;

0041its processing means can be responsible, if the compression identifier signals a compressed header, for resetting to zero (reactivating) the first time-delay associated with the stream of that header, before reconstructing the original header from the corresponding information stored in the storage means and designated by the session identifier contained in the received compressed header;

0042it can comprise decompression means responsible, in case of reconstruction of the original header of cells of a packet of a stream, for determining if that header comprises a data compression identifier signaling that the cells have been the subject of payload data compression, and if so, either for proceeding to decompress said payload data if there exist locally resources that enable it, or for sending the communication equipment constituting the source of the cells a message signaling saturation of the receive resources and then for dropping the packet to which the received cells belong.

0043The invention also proposes a communication equipment intended to constitute a transmission end point in an IP network and provided with a compression device and/or a decompression device of the types described hereinabove. Such equipment can, for example, take the form of a satellite terminal or a satellite gateway. It will be noted that the invention applies equally to so-called “star” communication between a terminal and a gateway and so-called “meshed” communication between terminals that do not pass through a gateway.

Other features and advantages of the invention will become apparent on reading the following detailed description and examining the appended drawings, in which:

<figref idref="DRAWINGS">FIG. 1</figref> illustrates in a highly schematic and functional way a satellite network comprising a satellite gateway and a satellite mobile terminal each equipped with one embodiment of a compression device according to the invention and one embodiment of a decompression device according to the invention,

<figref idref="DRAWINGS">FIG. 2</figref> illustrates in a highly schematic way the principal fields of an IP header partially compressed in accordance with the invention, followed by a UDP or TCP header,

<figref idref="DRAWINGS">FIG. 3</figref> illustrates in a highly schematic way the fields of a UDP/IP header compressed in accordance with the invention, followed by payload data,

<figref idref="DRAWINGS">FIG. 4</figref> illustrates in a highly schematic way the fields of an IP header compressed in accordance with the invention, followed by an uncompressed TCP header,

<figref idref="DRAWINGS">FIG. 5</figref> illustrates schematically one example of a compression algorithm that can be used by a compression device according to the invention,

<figref idref="DRAWINGS">FIG. 6</figref> illustrates schematically one example of a decompression algorithm that can be used by a decompression device according to the invention, and

<figref idref="DRAWINGS">FIG. 7</figref> illustrates schematically and functionally the “locations” at which the compression and decompression operations are effected in the case of communication between a gateway and a terminal (A) and between two terminals (B), respectively.

0052The appended drawings can constitute part of the description of the invention as well as contributing to the definition of the invention, if necessary.

0053An object of the invention is to adapt compression as a function of the transport medium, and if possible taking account of the lifetime of the streams and the availability of the computation (CPU) resources and/or local memory resources necessary for compression and/or the computation resources and/or remote memory resources necessary for decompression.

0054Use of the invention between two communication equipments E<b>1</b> and E<b>2</b>, constituting communication end points in an Internet Protocol (IP) communication network R is described first with reference to <figref idref="DRAWINGS">FIG. 1</figref>.

0055It is considered hereinafter by way of nonlimiting example that the IP network is a satellite network, for example of DVB-RCS (Digital Video Broadcasting-Return Channel System) type. However, the invention is not limited to that type of IP network. In fact it concerns any type of IP network having an access network (where applicable a radio access network) capable of transmitting data in the form of cells on a transport medium, for example of TCP/IP or UDP/IP type. The IP network can therefore be a satellite network, for example of SDMB (Satellite Digital Multimedia Broadcast) type, or a terrestrial network, for example of cable (xDSL) type or of mobile or cellular (GPRS/EDGE, or UMTS (where applicable of MBMS (Multimedia Broadcast/Multicast Services) type, or the evolution of the UMTS called LTE (Long Term Evolution), or DVB-H (Digital Video Broadcasting-Handhelds—mobile television)), or a hybrid (satellite and terrestrial) network.

0056Moreover, it is considered hereinafter, by way of nonlimiting example, that the communication equipments E<b>1</b> and E<b>2</b> are respectively a satellite gateway (E<b>1</b>) and a satellite mobile (or cellular) telephone (E<b>2</b>). However, the invention is not limited to these types of communication equipment. In fact it concerns any type of fixed or mobile (or portable or cellular) communication equipment capable of exchanging data by cable or by waves with another equipment, via an access network (where applicable a radio access network). Consequently, it can, for example, be a question of a fixed or mobile telephone, a fixed or portable computer, or even radio equipment for receiving television programs, for example a personal stereo or a fixed or portable television, or radio or cable equipment for receiving video or music programs, or radio equipment on board a vehicle (car, truck, bus, train and the like).

0057Moreover, it is considered hereinafter, by way of nonlimiting example, and unless explicitly indicated otherwise, that the cells are of ATM (Asynchronous Transfer Mode) type. In fact, sending from a gateway E<b>1</b> to a terminal E<b>2</b> (or E<b>2</b>′) may not be in ATM mode only (it is conventionally in MPE/MPEG or even ULE/MPEG mode). Sending from a terminal E<b>2</b> (or E<b>2</b>′) to a gateway E<b>1</b> is on the other hand of ATM type (conventionally AAL5/ATM type).

0058The invention proposes a compression device D<b>1</b> and a decompression device D<b>2</b> intended to be installed in communication equipments connected to the IP network R, or forming part of the latter (in particular of its access network). In the nonlimiting example illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the satellite gateway E<b>1</b> and the mobile telephone E<b>2</b> are each equipped with a compression device D<b>1</b> and a decompression device D<b>2</b>. This is not obligatory, however. The satellite gateway E<b>1</b> being equipped only with a compression device D<b>1</b> and the mobile telephone E<b>2</b> being equipped only with a decompression device D<b>2</b> can in fact be envisaged. Generally speaking, all combinations can be envisaged provided that a first communication equipment, constituting a communication end point acting as sender, comprises at least one compression device D<b>1</b>, and that at least one second communication equipment, constituting a communication end point acting as receiver, comprise at least one decompression device D<b>2</b>.

0059As illustrated schematically and functionally in <figref idref="DRAWINGS">FIG. 1</figref>, a compression device D<b>1</b> according to the invention comprises at least one processing module MT<b>1</b> and preferably storage means M<b>1</b>, for example a memory arranged in the form of a table of correspondence, or a tree, or of CAM type.

0060The processing module MT<b>1</b> is responsible for compressing at least a portion of the headers of the stream data packets, before the latter are decomposed or segmented into cells (here ATM cells) in order to be transmitted to a communication end point (receiver). A packet of a stream (involved in a session) includes in particular an IP header including a destination end point (receiver) identifier, a session identifier (session_id), and stream attributes, for example the IP version used (IP_version, for example IPv4 or IPv6), IHL, TOS, TTL, the source IP address, the destination IP address, the source port, the destination port, the transport protocol type (for example UDP or TCP), an option field (reserved for future use), a field indicating readiness for compression or decompression (Rx_ready), a reservation field (“reserved”, for example for padding and in particular for evolution of the standards).

0061This processing module MT<b>1</b> is operative each time that an IP packet of a stream must be transmitted. The operations effected by the processing module MT<b>1</b> are described hereinafter with reference to the algorithm shown by way of example in <figref idref="DRAWINGS">FIG. 5</figref>.

0062On reception of an IP packet (step <b>10</b>), the processing module MT<b>1</b> begins by determining if the header of that IP packet can be the subject of compression as a function of at least one chosen criterion (step <b>20</b>). Here “header of an IP packet” means both its IP header and its transport protocol (UDP or TCP) header, where applicable with option header.

0063Among the criteria that can be used, there may be cited in particular the fragmentation of the packet (“has the packet been fragmented?”), the presence of an option (“does the packet comprise an option?”), the type of transport protocol used (for example UDP or TCP), the subtype of the transport protocol, if any (for example DNS or SNMP or ICMP or T/TCP), the compression authorization received from said destination end point (“has the receiver of the steam authorized compression, because it has sufficient computation (CPU) and/or memory resources to proceed to decompression?”), and local compression authorization (“has the sender of the stream authorized compression, because it has sufficient computation (CPU) resources to proceed to compression and/or it has not yet used all its session identifiers (session_id), of which there are generally 254)”).

0064It is important to note that these criteria can be used separately or in combination (including all of them at once).

0065Applying a criterion or criteria means that the headers of IP packets belonging to a stream whose service life is reduced or sporadic need not be compressed. This is the case in particular of DNS, SNMP or ICMP streams. It also avoids using local (sender E<b>1</b>) resources to compress IP packets when the resources of the sender E<b>1</b> dedicated to this function are saturated and/or the resources of the receiver E<b>2</b> dedicated to decompression are saturated.

0066If the result of the test effected in the step <b>20</b> is negative, then the processing module MT<b>1</b> transmits the IP packet to a compression module of its equipment E<b>1</b> (or E<b>2</b>), for example, or of its compression device D<b>1</b>, responsible for compressing the payload data, for example by means of a ZIP type technique.

0067If the result of the test effected in the step <b>20</b> is positive, then the processing module MT<b>1</b> determines in a step <b>30</b> if header compression can reduce the number of ATM cells that will result from the decomposition of the received IP packet.

0068To do this, the processing module MT<b>1</b> can, for example, calculate the first number N<b>1</b> and the second number N<b>2</b> of ATM cells that would result from the decomposition of the received IP packet respectively in the absence and in the presence of compression of at least its IP header. To this end it effects a simulation. It then authorizes the replacement of at least the IP header of the received IP packet by an at least partially compressed header if the first number N<b>1</b> is strictly greater than the second number N<b>2</b> (N<b>1</b>>N<b>2</b>), for example. It could instead calculate the difference between N<b>1</b> and N<b>2</b> and authorize header compression if that difference is above a chosen threshold.

0069In the case of compression preceding sending from a gateway E<b>1</b> to a terminal E<b>2</b>, the compression gain can be calculated from the ratio in bytes of the sizes in bytes before compression and after compression, and then by comparing that gain to a chosen threshold percentage (for example equal to 10%).

0070If the result of the test effected in the step <b>30</b> is negative, then the processing module MT<b>1</b> transmits the IP packet to a compression module of its equipment E<b>1</b> (or E<b>2</b>), for example, or of its compression device D<b>1</b>, responsible for compressing the payload data, for example by means of a ZIP type technique.

0071If the result of the test effected in the step <b>30</b> is positive, then the processing module MT<b>1</b> replaces in the received IP packet (step <b>120</b>) at least its IP header by a compressed header (C) that comprises at least the session identifier (session_id) and a compression identifier (for example a specific value of the (ip_version) field dedicated to the version of the IP used).

0072More precisely, for the processing module MT<b>1</b> to be able to replace in the received IP packet at least its IP header by a compressed header (C), it must beforehand have transmitted to the receiver (for example E<b>2</b>) that is the destination of the stream the header of that IP packet in a partially compressed (PC) form, in order for it to be in a position to reconstruct the original (complete) header from a compressed header (C). In other words, when an IP packet is received belonging to a (new) unknown stream, the processing module MT<b>1</b> must first, in a step <b>110</b>, replace its IP header by a partially compressed IP header (PC). The IP packet, which then comprises a partially compressed IP header (PC) and the original UDP or TCP header, can then be transmitted to the receiver E<b>2</b>, in the form of ATM cells, in order for it to store in storage means M<b>2</b> (for example a memory, where applicable arranged in the form of a table of correspondence) the information that is contained at least in their compressed IP header PC (as well as their UDP header, only if the transport protocol is UDP). The processing module MT<b>1</b> can then, in a step <b>120</b>, replace at least the IP header of the subsequent IP packets of the same stream by a compressed IP header C. Thus when the receiver E<b>2</b> receives the ATM cells including the compressed header C it can reconstruct the original (complete) header from the compressed header C and information that corresponds to it stored beforehand in the memory M<b>2</b>.

0073In order to be able to distinguish an IP packet of a known stream from an IP packet of an unknown stream, the processing module MT<b>1</b> can proceed as follows, for example.

0074First of all, it can calculate in a step <b>40</b> a hashing key associated with the stream to which the received IP packet belongs. In order to be specific to a stream the hashing key can, for example, be calculated from values of at least some of the fields of the IP header of the received IP packet. For example, there may be used for this purpose the identifier of the (destination) receiver, the source IP address, the destination IP address, the source port, the destination port, and the transport protocol type.

0075Then, in a step <b>50</b> the processing module MT<b>1</b> determines in the memory M<b>1</b> if the hashing key that it has just calculated is already stored there. If the key is not found to be stored there, it considers the stream as a new stream.

0076The processing module MT<b>1</b> preferably then determines, in a step <b>60</b>, if a session identifier (session_id) is still available for the stream concerned. If not, then the processing module MT<b>1</b> transmits the IP packet to a compression module of its equipment E<b>1</b> (or E<b>2</b>), for example, or its compression device D<b>1</b>, responsible for compressing the payload data, for example by means of a ZIP type technique. On the other hand, if a session identifier is available after the expiry of a first time-delay T<b>1</b>, the processing module MT<b>1</b> stores the new hashing key in the memory M<b>1</b> (step <b>70</b>). A first time-delay T<b>1</b> of chosen duration (typically one minute, for example) is preferably associated with each stream that has just finished in order to be able to re-use it on the expiry of that first time-delay T<b>1</b> whilst leaving the receiver E<b>2</b> sufficient time to decompress the last IP packet of that stream.

0077The processing module MT<b>1</b> preferably then associates a second time-delay T<b>2</b> of chosen duration (for example equal to one second (1 s)), to the session of the new stream, and then activates (sets to zero) this second time-delay T<b>2</b> in a step <b>80</b>, and proceeds in the step <b>110</b> to the replacement of at least the IP header of the received IP packet by a partially compressed header PC. This time-delay then periodically synchronizes the receiver with non-compressed headers to alleviate the degraded modes.

0078The second time-delay T<b>2</b> is used to refresh periodically the information that is stored in the memory M<b>2</b> of the receiver E<b>2</b> and that defines the original IP header of the IP packets together with the data of the UDP or IP headers of a stream being transmitted.

0079There is represented schematically in <figref idref="DRAWINGS">FIG. 2</figref> an example of a partially compressed IP header PC, followed by a header dedicated to the transport protocol (for example UDP or TCP).

0080In this example, the partially compressed IP header PC comprises 13 bytes (instead of the 20 bytes of a standard IP header):

0081a field (IP_version) designating at the same time the IP version used and the fact that the IP header is partially compressed, for example value 0x00 for IPv4 and value 0x02 for IPv6, on 4 bits,

0082a reservation field (“reserved”, for example for padding), on 4 bits,

0083the transport protocol type, on 2 bits, for example the value 00 for UDP and the value 01 for TCP,

0084an option field (“reserved”), for future use, on 1 bit,

0085a field indicating readiness for compression or decompression (Rx_ready), on 1 bit,

0086a payload data compression version field (zip_version), on 4 bits, that identifies the algorithm selected by the sender for compressing the payload data, in order for the receiver to be able to reconstitute the data correctly if it is compressed; some of these algorithms are supplied by free software well known to the person skilled in the art,

0087a field (“zipped”), on 1 bit, signaling if the payload data has been compressed or not, so that the receiver applies decompression of the original data, or not,

0088a session identifier (session_id), on 7 bits,

0089a field “DSCP/TOS”, on 1 byte,

0090a field “TTL”, on 1 byte,

0091the source IP address, on 4 bytes, and

0092the destination IP address, on 4 bytes.

0093The assignment and the number of bits of the fields described hereinabove are given by way of illustrative example. They can therefore form the subject of numerous variations.

0094If the processing module MT<b>1</b> determines in the step <b>50</b> that the hashing key that it has just calculated is stored in the memory M<b>1</b>, that signifies that the stream is known and that its IP packets are being transmitted. Then, in a step <b>90</b>, it re-activates (resets to zero) the first time-delay T<b>1</b> associated with the stream of which the received IP packet is part. Then, in a step <b>100</b>, it effects a test in order to determine if the second time-delay T<b>2</b> associated with the session identifier of the stream has expired.

0095If this is the case, then it effects the step <b>80</b> (re-activation (resetting to zero) of the second time-delay T<b>2</b> associated with the session identifier), then the step <b>110</b> (replacement of the IP header of the received IP packet by the partially compressed header PC in order to refresh the information on the stream stored in the memory M<b>2</b> of the receiver E<b>2</b>).

0096If the result of the test of the step <b>100</b> is negative (second time-delay T<b>2</b> not yet expired), the processing module MT<b>1</b> proceeds to the replacement of at least the IP header of the received IP packet by a compressed header C.

0097There is schematically represented in <figref idref="DRAWINGS">FIG. 3</figref> an example of a compressed header C, in the case of a UDP/IP transport medium. In this case, the original IP header and the original UDP header are replaced by a compressed header C of two bytes, followed by payload data.

0098In the example illustrated, the compressed header C comprises:

0099the field (IP_version) designating at the same time the IP version used and the fact that the IP and UDP headers are compressed, for example value 0x01 for IPv4 and value 0x03 for IPv6, on 4 bits,

0100the transport protocol type on 2 bits, for example (value 00 for UDP),

0101the option field (“reserved”, for future use), on 1 bit,

0102the field indicating readiness for compression or decompression (“Rx_ready”), on 1 bit,

0103the field (“zipped”) signaling if the payload data has been compressed or not, on 1 bit, and

0104the session identifier (session_id), on 7 bits.

0105The assignment and the number of bits of the fields described hereinabove are given by way of illustrative example. They are given here to obtain a header of two bytes, in particular in the presence of a field session_id including seven bits. They can therefore be the subject of numerous variations.

0106There is also represented schematically in <figref idref="DRAWINGS">FIG. 4</figref> an example of a compressed header C, in the case of a TCP/IP transport medium. In this case, only the original IP header is replaced by a compressed header PC of two bytes, followed by the TCP header, then payload data (not represented). In the example illustrated, the compressed header C is identical to that described hereinabove with reference to <figref idref="DRAWINGS">FIG. 3</figref> (only the value of the transport protocol type is different because the transport protocol is now TCP (for example the value 01 is used for TCP)).

0107It will be noted that in the step <b>100</b>, after having reset to zero the first time-delay T<b>1</b> (which is associated with the session identifier of the flux to which the received IP packet belongs) and if the second time-delay T<b>2</b> associated with that stream has not expired, the processing module MT<b>1</b> can additionally compare to a chosen threshold the number of packets of the stream that have been transmitted in the form of ATM cells with a compressed header C since the beginning of the last activation of said second time-delay T<b>2</b>. In this case, the processing module MT<b>1</b> proceeds to the replacement of the IP header (or the IP header and the UDP header) of the last IP packet received with the compressed header C only on the condition that the corresponding second time-delay T<b>2</b> has not expired and the aforementioned number of packets is below the chosen threshold. In other cases, the processing module MT<b>1</b> effects the step <b>80</b> (reactivation (resetting to zero) of the second time-delay T<b>2</b> associated with the session identifier), then the step <b>110</b> (replacement of the IP header of the received IP packet by the partially compressed header PC).

0108As shown in <figref idref="DRAWINGS">FIG. 5</figref>, the processing module MT<b>1</b> of the compression device D<b>1</b> can also be responsible for determining if it is useful to proceed to compression of the payload data of the received IP packet.

0109To do this, the processing module MT<b>1</b> can, for example, start by determining in a step <b>130</b> if the payload data associated with the at least partially compressed header (C or PC) can be compressed as a function of at least one chosen criterion.

0110Among the criteria that can be used, there may in particular be cited the compression authorization received from the destination end point E<b>2</b> (“has the receiver of the stream authorized compression, because it has sufficient computation (CPU) and/or memory resources to proceed to the decompression?”), the local compression authorization (“has the sender of the stream authorized compression, because it has sufficient computation (CPU) resources to proceed to the compression and/or because it has not yet used all its session identifiers (session_id)?”), and the size of the received packet (“does the packet comprise a number of bytes above a chosen threshold (for example typically equal to 80)”).

0111It is important to note that these criteria can be used separately or in combination (including all at once).

0112If the IP packet with at least partially compressed header (C or PC) does not satisfy at least one of the criteria applied, then the compression device D<b>1</b> stops its processing. The IP packet is then segmented (or decomposed) into ATM cells by the sender E<b>1</b>, after which the ATM cells are transmitted to the receiver E<b>2</b>.

0113If the IP packet with at least partially compressed header (C or PC) satisfies each criterion applied, then the processing module MT<b>1</b> can, for example, determine in a step <b>140</b> if compression of the payload data can in fact lead to a reduction in the number of ATM cells that should result from the decomposition (or segmentation) of the IP packet with at least partially compressed header (C or PC).

0114To do this, the processing module MT<b>1</b> can, for example, calculate the first number N<b>1</b>′ and the second number N<b>2</b>′ of ATM cells that would result from the decomposition of the IP packet with compressed header respectively in the absence and in the presence of compression of its payload data. To do this it effects a simulation. It then authorizes compression of the payload data if the first number N<b>1</b>′ is strictly greater than the second number N<b>2</b>′ (N<b>1</b>′>N<b>2</b>′), for example. It could instead calculate the difference between N<b>1</b>′ and N<b>2</b>′ and authorize compression of the payload data if that difference is above a chosen threshold.

0115Authorization of compression of the payload data is signaled by the processing module MT<b>1</b> placing in the at least partially compressed header (C or PC) (in a step <b>150</b>) a chosen first value of the compression identifier (“zipped”). In the presence of a compression authorization the processing module MT<b>1</b> transmits the IP packet with compressed header (C or PC) to a payload data compression module of its equipment E<b>1</b> (or E<b>2</b>), or of its compression device D<b>1</b>, responsible for compressing the payload data, for example by means of a ZIP type technique. The IP packet is then segmented (or decomposed) into ATM cells by the sender E<b>1</b>, and the ATM cells are sent to the receiver E<b>2</b>.

0116The prohibition of compression of the payload data is signaled by the processing module MT<b>1</b> placing in the at least partially compressed header (C or PC) (in a step <b>160</b>) a chosen second value of the compression identifier (“zipped”). In the presence of a compression prohibition the compression device D<b>1</b> stops its processing. It transmits the IP packet with compressed header (C or PC) to its equipment E<b>1</b> (or E<b>2</b>), for example, in order for it to segment (or decompose) it into ATM cells, and then transmits the ATM cells to the receiver E<b>2</b>.

0117One embodiment of a decompression device D<b>2</b> according to the invention is described next with reference to <figref idref="DRAWINGS">FIGS. 1 and 6</figref>.

0118As schematically and functionally shown in <figref idref="DRAWINGS">FIG. 1</figref>, a decompression device D<b>2</b> according to the invention comprises at least one processing module MT<b>2</b> and preferably one payload data decompression module MD and storage means M<b>2</b>, for example a memory taking the form of a table of correspondence, or a tree, or of CAM type.

0119The processing module MT<b>2</b> is responsible for decompressing, at a communication end point acting as receiver E<b>2</b> (or E<b>1</b>), cells (where applicable ATM cells) of an IP packet of a stream that was the subject of compression by means of a compression device D<b>1</b>.

0120This processing module MT<b>2</b> is therefore operative each time that a receiver E<b>2</b> (or E<b>1</b>) has reconstituted a packet of a stream from received (ATM) cells and resulting from its segmentation. The operations effected by the processing module MT<b>2</b> are described hereinafter with reference to the example of an algorithm shown in <figref idref="DRAWINGS">FIG. 6</figref>.

0121On reception of a packet (step <b>200</b>), the processing module MT<b>2</b> determines in a step <b>230</b> if its header is at least partially compressed (C or PC).

0122As shown, before effecting this step <b>230</b>, the processing module MT<b>2</b> preferably begins by determining in a step <b>210</b> if the received packet is of IP type. To do this, it analyzes the value of the IP version identifier (IP_version) of its header, for example.

0123If the packet is not an IP packet, the decompression device D<b>2</b> stops processing and communicates the packet to its equipment E<b>2</b> (or E<b>1</b>).

0124On the other hand, if it is an IP packet, the processing module MT<b>2</b> preferably determines in a step <b>220</b> the IP version used (for example IPv4 or IPv6). That type is defined by the value of the IP version identifier (IP_version) of the header of the received ATM cell. For example, the values 0x00, 0x02 and 0x04 designate IPv4, while the values 0x01, 0x03 and 0x06 designate IPv6.

0125If the value of the identifier of the IP version is equal to 0x04 or 0x06 (and therefore does not correspond to an IP subjected to compression in accordance with the invention), the decompression device D<b>2</b> stops its processing and communicates the IP packet to its equipment E<b>2</b> (or E<b>1</b>).

0126On the other hand, if the value of the IP version identifier corresponds to an IP subjected to compression in accordance with the invention, the decompression device D<b>2</b> determines in the step <b>230</b> if the header of the received IP packet is at least partially compressed (C or PC).

0127Two situations can arise here. If the value of the IP version identifier corresponds to complete header compression (C—for example value 0x01 or 0x03), then the processing module MT<b>2</b> proceeds to a step <b>280</b> described later. If the value of the IP version identifier corresponds to partial header compression (PC—for example value 0x00 or 0x02), then the processing module MT<b>2</b> proceeds to a step <b>240</b>.

0128In the step <b>240</b>, the processing module MT<b>2</b> determines in the memory M<b>2</b> of its decompression device D<b>2</b> if the session identifier (contained in the partially compressed header PC of the IP packet) is already stored therein and thus corresponds to a known stream.

0129If the session identifier is not stored in the memory M<b>2</b>, that indicates that the received IP packet belongs to a new stream. The processing module MT<b>2</b> then stores the new session identifier in the memory M<b>2</b>, in a step <b>250</b>.

0130It then proceeds to a step <b>260</b> in which it stores (again in the memory M<b>2</b>) the information relating to the new stream (i.e. the information contained in the IP header and where applicable in the UDP header) in corresponding relationship to the session identifier previously stored (in the step <b>250</b>). It is this stored information (relating at least to the IP header) that will subsequently enable the processing module MT<b>2</b> to reconstruct complete entities from compressed headers C.

0131Before beginning each step <b>260</b>, the processing module MT<b>2</b> preferably verifies if its (receiver) equipment E<b>2</b> (or E<b>1</b>) has computation (CPU) resources available for reconstructing the IP header (or the IP header and the UDP header) properly.

0132If so, it proceeds to the step <b>260</b> described later.

0133On the other hand, if the (receiver) equipment E<b>2</b> (or E<b>1</b>) does not have sufficient computation and/or memory resources, the decompression device D<b>2</b> requests its receiver equipment E<b>2</b> (or E<b>1</b>) to inform the sender equipment E<b>1</b> (or E<b>2</b>) of this.

0134This can be done by using a particular value of the “Rx_ready” field of the IP header, for example. On reception of such information, the compression device D<b>1</b> of the sender equipment E<b>1</b> (or E<b>2</b>) momentarily ceases to authorize local compression of headers and associated payload data. Compression can resume subsequently as soon as the (receiver) equipment E<b>2</b> (or E<b>1</b>) has informed the sender equipment E<b>1</b> (or E<b>2</b>) of the end of saturation of its computation and/or memory resources dedicated to decompression.

0135This terminates the processing effected on the IP packet by the decompression device D<b>2</b>.

0136If the session identifier is stored in the memory M<b>2</b>, that indicates that the received IP packet belongs to a known stream. The processing module MT<b>2</b> is then responsible for refreshing in the memory M<b>2</b>, in the step <b>260</b> (preferably after verifying the local availability of calculation and/or memory resources), the information relating to the known stream (i.e. the information contained in the IP header and in the UDP header, if any, and that is to be stored in corresponding relationship to the session identifier of the stream).

0137In the same step <b>260</b> the processing module MT<b>2</b> preferably associates a first time-delay T<b>1</b>′ with the session identifier of the stream, and then activates it (sets it to zero). This first time-delay T<b>1</b>′ represents a duration that is preferably slightly shorter than that of the first time-delay T<b>1</b> of the compression device D<b>1</b>. This first time-delay T<b>1</b>′ is used to monitor a stream with the aim of releasing the context that has been allocated to the current session if it is not used during a time period greater than or equal to T<b>1</b>′. As a general rule, T<b>1</b>′=T<b>1</b>−10 sec (T<b>1</b> being typically of the order of one minute).

0138Then, in a step <b>270</b> the processing module MT<b>2</b> reconstructs the original IP header of the ATM cells of the received IP packet from their partially compressed header PC, and in those ATM cells replaces the partially compressed header PC by the reconstructed IP header.

0139If the processing module MT<b>2</b> becomes aware during the test of the step <b>230</b> that the value of the IP version identifier does not correspond to partial header compression (PC), it then proceeds to the step <b>280</b>. In the latter step, the processing module MT<b>2</b> determines if the header of the received IP packet corresponds to header compression C.

0140If the value of the IP version identifier does not correspond to complete header compression of type C, then the processing module MT<b>2</b>, in a step <b>290</b>, drops the received IP packet, as there is an inconsistency.

0141On the other hand, if the value of the IP version identifier does indeed correspond to complete header compression (C—for example value 0x01 or 0x03), then the processing module MT<b>2</b> proceeds to a step <b>300</b>.

0142In the step <b>300</b>, the processing module MT<b>2</b> determines in the memory M<b>2</b> of its decompression device D<b>2</b> if the session identifier (contained in the compressed header C of the IP packet) is already stored therein and therefore corresponds to a known stream.

0143If the session identifier is not stored in the memory M<b>2</b>, then the processing module MT<b>2</b>, in the step <b>290</b>, drops the received packet, because there is some inconsistency.

0144On the other hand, if in the step <b>300</b> the processing module MT<b>2</b> becomes aware that the session identifier is stored in the memory M<b>2</b>, and therefore does indeed correspond to a known stream, it proceeds to a step <b>310</b> in which it reactivates (resets to zero) the first time-delay T<b>1</b>′ that is associated with the session identifier of the stream. This reactivation of the first time-delay T<b>1</b>′ serves to reactivate the stream (in order to release the associated context in the case of inactivity).

0145Then, in a step <b>320</b> the processing module MT<b>2</b> reconstructs only the original IP header (in the case of a TCP transport protocol) and the original IP header as well as the original UDP header (in the case of a UDP transport protocol) from the compressed header C contained in the (ATM) cells of the received IP packet and corresponding information stored in the memory M<b>2</b> during a previous step <b>260</b>. It then replaces in each ATM cell of the received IP packet the compressed header C by the reconstructed header.

0146As shown in <figref idref="DRAWINGS">FIG. 6</figref>, the decompression device D<b>2</b> can also be responsible for decompressing the payload data of the received ATM cells, once their original header has been reconstructed.

0147To do this, it can for example comprise a payload data decompression module MD responsible firstly for determining in a step <b>330</b> if the received packet contains compressed payload data. To this end it can analyze the value of the “zipped” field.

0148If the payload data has not been compressed, the decompression device D<b>2</b> stops its processing of the IP packet.

0149On the other hand, if the payload data has been compressed, the decompression module MD determines in a step <b>340</b> if its (receiver) equipment E<b>2</b> (or E<b>1</b>) has computation (CPU) resources available for decompressing the payload data properly.

0150If this is the case, the decompression module MD decompresses the payload data of the received IP packet using the technique that is the inverse of that used by the compression module of the sender equipment E<b>1</b> (or E<b>2</b>), for example “UNZIP” (or any other decompression technique). The IP packet is then entirely decompressed, which terminates the processing effected on the IP packet by the decompression device D<b>2</b>.

0151On the other hand, if the (receiver) equipment E<b>2</b> (or E<b>1</b>) does not have sufficient computation resources, the decompression device D<b>2</b> requests its receiver equipment E<b>2</b> (or E<b>1</b>), in a step <b>360</b>, to inform the sender equipment E<b>1</b> (or E<b>2</b>) of this.

0152This can be done for example by using a particular value of the “Rx_ready” field of the compressed header. On receipt of such information, the compression device D<b>1</b> of the sender equipment E<b>1</b> (or E<b>2</b>) temporarily ceases to authorize local compression of the payload data (and the associated headers, if any). Compression can resume subsequently as soon as the (receiver) equipment E<b>2</b> (or E<b>1</b>) has informed the sender equipment E<b>1</b> (or E<b>2</b>) of the end of saturation of its computation resources dedicated to decompression or on the expiry of a third time-delay T<b>3</b> at the sender end, typically with a value of the order of one second (sender configuration parameter).

0153Then, in a step <b>370</b> the decompression device D<b>2</b> drops the IP packet (received in segmented form) given that it is not in a position to decompress its payload data. This then terminates the processing effected on the IP packet (received in segmented form) by the decompression device D<b>2</b>.

0154The compression device D<b>1</b> according to the invention, and in particular its processing module MT<b>1</b> and memory M<b>1</b>, if any, and the compression device D<b>1</b> according to the invention, and in particular its processing module MT<b>2</b> and its decompression module MD and memory M<b>2</b>, if any, can be produced in the form of electronic circuits, software (or electronic data processing) modules, or a combination of circuits and software.

0155The “locations” at which the operations of compression (D<b>1</b>) and decompression (D<b>2</b>) are effected in the case of communication between a gateway E<b>1</b> and a terminal E<b>2</b> (A) and between two terminals E<b>2</b> and E<b>2</b>′ (B), respectively, are shown schematically and functionally in <figref idref="DRAWINGS">FIG. 7</figref>.

0156More precisely, the case A corresponds to star communication between a gateway E<b>1</b> and a terminal E<b>2</b> while case B corresponds to meshed communication between two terminals E<b>2</b>.

0157At a terminal E<b>2</b> (or E<b>2</b>′) compression (D<b>1</b>) is effected on sending just before IP over AAL5/ATM encapsulation, while decompression (D<b>2</b>) is effected on reception either just after reassembly of MPE/MPEG or ULE/MPEG type (compression by a gateway E<b>1</b> to the DVB-S or DVB-S2 standard) intended to reconstitute the IP packets, in case A (star), or just after reassembly of AAL5/ATM type intended to reconstitute the IP packets, in case B (meshed).

0158At a gateway E<b>1</b> compression (D<b>1</b>) is effected on sending just before IP over MPE/MPEG or IP over ULE/MPEG encapsulation (compression by a gateway E<b>1</b> to the DVB-S or DVB-S2 standard), while decompression (D<b>2</b>) is effected on reception just after reassembly of AAL5/ATM type intended to reconstitute the IP packets.

0159The invention offers a certain number of advantages, including:

0160estimation of the compression gain before compression is effected and only if compression is possible,

0161simple and robust header compression, especially in the case of the adaptation layer known as “AAL5”,

0162compression/decompression can be effected dynamically as a function of the calculation resources available locally, the available memory size, and the number of sessions already open in parallel,

0163an implementation of significantly reduced complexity compared to those imposed by RFCs,

0164reduced computation and memory powers,

0165transmission of compressed headers of 2 bytes (instead of 40) in the case of a UDP/IP type transport protocol, of 22 bytes (instead of 40) in the case of a TCP/IP type transport protocol without options, and of 30 bytes (instead of 56) in the case of a TCP type transport protocol with satellite option (T/TCP), all these headers therefore occupying only one ATM cell (of 48 bytes maximum including the AAL5 trailer of 8 bytes),

0166a “UDP checksum” field that does not need to be recomputed (because it is set to zero and a CRC32 is used in the low-level protocol layers (MPE, AAL5)), so saving on computation resources at the time of decompression,

0167if the compression header is present (identified by the IP_version field), then it is possible to compress the application data according to the local/remote resources and above all if a data compression gain is in fact obtained for a given stream (there is no benefit in continuing to attempt to compress the data if the size after compression is greater than or equal to the original size because an additional header (overhead) is added and the entropy is at a maximum, i.e. in the absence of redundant information that can benefit from a compression gain),

0168the degraded TCP (with option) mode can continue to be used without disruption caused by the fact that the TCP header has not been compressed.

0169The invention is not limited to the compression device, decompression device and communication equipment embodiments described hereinabove by way of example only, but encompasses all variants that the person skilled in the art might envisage within the scope of the following claims.

0170Thus there have been described hereinabove examples of communication equipment comprising both a compression device according to the invention and a decompression device according to the invention. However, a communication equipment according to the invention may include only a compression device according to the invention or only a decompression device according to the invention.

0171Moreover, there has been described hereinabove a situation in which a sender (provided with a compression device) transmits compressed streams to a single receiver (provided with a decompression device). However, the compression device of a sender can process in parallel a plurality of streams intended for a plurality of receivers (each provided with a decompression device).