Management of the transmission and reception of a compressed data packet

Abstract

The invention relates to a method for managing the transmission of a data packet compressed by applying a compression rule belonging to a set of compression rules, referred to as the compressed packet (P), comprising the insertion into the compressed packet (P) of an identifier of the set of compression rules, referred to as the unique context identifier (ICU), followed by the transmission of the thus modified compressed packet (P').

Description

Methods for managing the transmission and reception of a compressed data packet

[0001] The technical field is that of data compression transmitted in a communication network.

[0002] More specifically, the invention relates to a method for transmitting a compressed data packet in a communication network. The invention also relates to a method for receiving a compressed data packet.

[0003] Modern networked computing and digital telecommunications operate on the principle of exchanging data packets between senders and receivers using protocols such as the IP protocol (Internet Protocol). A set of data packets relating to a given message is sent by the sender to a receiver, each packet corresponding to a part of the complete message. The packets contain the receiver's address. Using this information, a packet can be addressed to its final recipient through various routing algorithms. The overall content of the message is reconstructed by the recipient by regrouping the data contained in the different packets. The message can also be audio or visual media, as in the case of telephone or audiovisual communications, which also operate on the principle of packet transmission.To achieve complete communication, numerous protocols must be used, each fulfilling a role from the physical transmission of bits—the atomic building blocks of digital data—to the interpretation of data for computer applications. Bits are typically grouped into bytes, which are sets of eight bits. The various protocols are generally viewed as being organized into layers, with a protocol at one layer relying on a protocol at the layer below. The OSI (Open Systems Interconnection) model and the Internet model describe how the various protocols interact across different layers.

[0004] For example, in a simplified version, the HTTP (Hypertext Transfer Protocol) protocol is an Application layer protocol that allows data to be transferred to or from a website. The data to be transferred is organized into data packets. The HTTP protocol uses the TCP (Transmission Control Protocol), which belongs to the Transport layer, for example, to request the transfer of data packets representing the content of a website to a user. The TCP protocol, for example, operates in three phases: establishing a connection, transferring data, and terminating the connection. Transport layer protocols use a Network layer protocol, generally the IP (Internet Protocol) protocol in one of its IPv4 or IPv6 versions.This protocol is only concerned with the transmission of data organized into packets from one address to another, without dealing with establishing the connection or the order in which the data packets arrive within a transmission; these considerations are handled by the protocol of the higher Transport layer. The IP protocol uses a protocol of the Data Link layer, for example, the Ethernet protocol, which organizes the sending of the elementary data that constitutes the packet. This elementary data is bits, transmitted using the Physical layer, either via fiber optic cable or wireless communication, depending on the case.

[0005] Other protocols in the Application layer use other protocols from lower layers to perform their functions. For example, the CoAP (Constrained Application Protocol) protocol used in the Internet of Things generally relies on the UDP (User Datagram Protocol) protocol of the Transport layer.

[0006] A common feature of all protocols across all layers is the organization of exchanged data into data packets. A data packet is organized into two parts: the first part is the packet header, which contains the information necessary for the protocol responsible for processing the packet; the second part is the payload, which contains the data transported within the packet itself. If packets of a given protocol contain one or more encapsulated packets of another protocol, the payload of a packet from the first protocol may contain the header of that other protocol. At the Data Link layer, we speak of frames rather than packets, and, in addition to the header, there is a frame footer indicating the end of the frame.

[0007] Packet headers contain fields. A field is a continuous set of bits of either a fixed or variable length. When a field is variable in length, mechanisms exist to determine the actual length of the field transmitted. When the value in a fixed-length field is variable, padding bits are used to add to the value until it reaches the fixed length of the field. Each field has an identifier that indicates the nature of the value it contains. The values ​​in the field are used by the relevant protocol to process the packet appropriately. For example, in the header of an IP packet, a field with the identifier "Version" contains the version number of the protocol being used. This field is four bits long.Other fields relate, for example, to the source and destination IP addresses of the packet. A header is therefore naturally divided into several sections, namely the header fields. The packet's payload can also be divided into several sections, for example, by defining sections of a constant length expressed in bits.

[0008] A packet analysis tool such as Wireshark or tcpdump allows you to capture and analyze data packets. This analysis separates a data packet exchanged over a network into its header and payload, reads the information contained in the header and the data contained in the payload, and identifies the various sections of a packet, both in its header and its payload. As a reminder, following the encapsulation of data packets, the typical header of a packet consists of several concatenated headers, one for each encapsulated protocol. For example, an Ethernet frame encapsulating an IP packet begins with the IP header, followed by the UDP header. A UDP datagram carried by an Ethernet frame then presents, successively, the Ethernet header, followed by the IP header, and then the UDP header.

[0009] There is a clear need for data compression in computing and digital telecommunications to optimize the use of hardware and energy resources consumed by computer and telecommunications networks. This need explains the creation of protocols dedicated to compressing exchanged data packets. Examples of compression protocols include ROHC (Robust Header Compression), defined by the IETF (Internet Engineering Task Force) in RFC 3095, and SCHC (Static Context Header Compression), defined by the IETF in RFC 8724.

[0010] These protocols operate using compression rules that apply to a specific data packet. A compression rule specifies, on the one hand, the conditions a data packet must meet for the rule to apply to that packet, and on the other hand, the compression performed when the rule is applied. The conditions for applying a rule relate to the values ​​taken by the different sections of that given packet. According to compression rules used in protocols such as ROHC or SCHC, the application condition relates to a value taken by a section of a packet, and the compression performed consists of erasing that value. The receiver, knowing the applied compression rule, restores the erased value upon receiving the packet. According to other rules, an index is transmitted, this index corresponding to a value taken by a given section.Upon reception, the receiver restores the value that was replaced by the index by consulting a dictionary that is part of the applied compression rule. According to other rules, the condition is based on a prefix of the value expressed as a sequence of bits, and the compression consists of removing this prefix. The receiver, again, restores the removed prefix when it decompresses the packet. This results in very efficient compression of data packets, even if the compression is limited to the headers.

[0011] In all cases, the operation of data packet compression protocols relies on sets of compression rules that describe the compression operations to be performed on header field values ​​or, more generally, on sections of the data packets. These compression operations are triggered when the packets meet conditions relating to the values ​​of the packet sections. A compression rule is said to apply to a packet when all the compression operations present in the rule can be applied to the values ​​of the fields in question. When a data packet is compressed by a given rule, it is transmitted along with an identifier of the applied compression rule. In this way, the receiver can retrieve the compression rule applied to the packet and thus reconstruct the original packet by performing the reverse operations to the compression.In some cases, the identifier of the compression rule used is not transmitted, and the compression rule is deduced from other information. For example, if one rule in a set of compression rules achieves significantly stronger compression than the others, and a received packet is very small, this information may be sufficient to deduce that this highly efficient rule was applied, even without transmitting the rule identifier. In all cases, the receiver and sender must have a shared understanding of the compression rules that could be applied and the rule actually used to compress a packet, in order to be able to restore it upon reception.

[0012] All of these elements are well known in the state of the art and will not be described further. State of the art

[0013] As previously mentioned, a data compression protocol requires that the set of compression rules that can be applied be known to both the sender and the receiver in order to perform the compression and then decompression of the transmitted packets. When a sender applies a compression rule to a data packet before transmitting it, they attach the identifier of the compression rule used to the transmitted packet. The receiver, which has the same set of compression rules as the sender, finds the applied compression rule within the rule set using its identifier and reconstructs the original packet by applying the inverse operations of those that constitute the applied compression rule.

[0014] These elements are well established in compression protocols, particularly ROHC and SCHC. In the ROHC protocol, compression occurs in the context of mobile telecommunications between a base station and mobile devices, and the compression rules, defined by the ROHC protocol, are known to both senders and receivers. In the case of the SCHC protocol, the context of use is that of the Internet of Things (IoT) or Low Power Wide Area Networks (LPWAN). In this context, a gateway communicates with the devices belonging to the network it creates and shares with them the same set of compression rules.

[0015] Currently, it is not possible to use these compression techniques in larger networks, such as the Internet. In larger networks, devices such as routers act as gateways between distinct networks. A data packet travels from network to network before reaching its destination. This communication occurs by passing from network to network and is therefore called multi-hop. A given device, in this context, communicates with other devices in several distinct contexts, each context corresponding to a specific network. Furthermore, these contexts change over time; a device such as a router can be connected to a set of other routers at any given time and share sets of compression rules with them. These sets must change as other routers connect to or disconnect from the initial router.Compression techniques that are useful in one context may be completely unsuitable in another. Therefore, a given device must be able to use distinct sets of compression rules, each corresponding to a specific context, to perform its packet compression.

[0016] However, the compression rule identifiers that are generally transmitted with a compressed packet are unique only within a given context and within the associated compression rule set. But there is no guarantee that the same compression rule identifier will not appear in multiple compression rule sets corresponding to several distinct contexts.

[0017] Therefore, there are currently no possibilities to use the efficient compression rules of data compression protocols such as ROHC or SCHC in a context where the network equipment that must apply the compression rules belongs to several separate, scalable networks, and where, therefore, the network equipment must use several sets of compression rules, each corresponding to distinct contexts.

[0018] The invention improves the situation.

[0019] According to a first functional aspect, the invention relates to a method for managing the transmission of a compressed data packet by applying a compression rule belonging to a set of compression rules, called a compressed packet, comprising the insertion into said compressed packet of an identifier of said set of compression rules, called a unique context identifier, followed by the transmission of the compressed packet thus modified.

[0020] Thanks to this invention, it becomes possible to use highly efficient compression in environments where telecommunications equipment belongs to several different contexts and contributes to multi-hop, network-to-network communications. In a given context, a specific set of compression rules is used by a given device to compress a data packet before sending it to another device that belongs to the same context and has that particular set of compression rules stored in memory. A given device will therefore manipulate several distinct sets of compression rules, each corresponding to a specific context. A unique context identifier can be assigned to a given set of compression rules; this identifier will be the same for the different devices that belong to the same context and use that same set of compression rules.The methods for creating and assigning this unique context identifier are outside the scope of the present invention. The invention relates to the proper functioning of data packet compression in an environment where several different contexts coexist and are known within the same equipment. The invention enables compression to function in a multi-context and multi-hop environment by ensuring that an identifier from the rule set used is transmitted in the compressed data packet. This identifier is called a unique context identifier, but it will not necessarily be unique for all possible contexts in all networks. It simply needs to be unique within a close neighborhood of a given network device, more precisely in its immediate neighborhood and the neighborhood of that neighborhood.In this way, context confusion can be avoided in multi-hop communications around the network equipment in question. The receiver can then use this context identifier to identify the set of compression rules that was used to compress the data packet. It can then reconstruct the original content of the compressed packet using the compression rule set thus identified. The invention therefore effectively solves the problem of using efficient compression techniques in a multi-context environment for multi-hop communications.

[0021] According to a particular embodiment of the invention, the compressed packet includes padding bits and the unique context identifier is inserted into the padding bits of the compressed packet.

[0022] The objective of the invention is to transmit compressed data packets in order to achieve maximum data transmission efficiency. Since the invention relies on the transmission of additional information, namely the unique context identifier, it is essential to ensure that this transmission is carried out economically. In this embodiment, the objective of maximum data efficiency is achieved. To this end, the invention uses padding bits, which are normally unused, to transmit the additional information of the unique context identifier. In this way, the embodiment of the invention does not require the use of more transmitted bits than would otherwise be necessary.The invention also achieves an optimization of the resources reserved for transmission by using filler bits which are transmitted in all cases and therefore consume resources regardless of whether or not this embodiment is implemented.

[0023] According to a particular embodiment of the invention, which can be implemented cumulatively with the previous embodiment, the insertion of the unique context identifier into the padding bits of the compressed packet is done starting from the last bit of the compressed packet according to a defined permutation.

[0024] This embodiment allows for the effective use of padding bits in the compressed packet. Indeed, it is not possible to know in advance the number of padding bits in the compressed packet. Therefore, for a given compressed packet, it is not possible to know the starting point of the padding bits in the standard left-to-right reading direction of a compressed packet. However, padding bits, when they exist, are necessarily located in the last bit of the compressed packet. To ensure that a known starting point is used when inserting the unique context identifier, this insertion is performed starting from the last bit of the compressed packet, according to a defined permutation.The permutation defined on the unique context identifier, presented as a sequence of bits, allows each bit forming the unique context identifier to be assigned to a padding bit, starting from the last bit of the compressed packet, where these padding bits are located. In this way, upon receiving the compressed packet, the starting point for inserting the unique context identifier into the padding bits is clearly known to the receiver. By using a permutation, in the mathematical sense of the term, each bit of the sequence of bits forming the unique context identifier has a reserved and distinct place within the padding bits of the compressed packet. Therefore, all the bits of the unique context identifier can be inserted into the padding bits using a permutation rather than any other function.

[0025] According to a particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding embodiments, the insertion of the unique context identifier into the padding bits of the compressed packet is done by inserting the unique context identifier into the padding bits in the opposite direction to the reading direction of the compressed packet.

[0026] In this embodiment, as before, the insertion of the unique context identifier into the padding bits is performed starting from the last bit of the compressed packet to ensure that the identifier is correctly inserted into padding bits. Here, the chosen method is to insert the identifier starting from the last bit of the compressed packet, in the reverse order of reading the compressed packet. This method corresponds to a defined permutation of the bits forming the unique context identifier, in which the first bit of the identifier is assigned to the last bit of the compressed packet, the second bit of the identifier to the penultimate bit, and so on, in the reverse order of reading the compressed packet.

[0027] According to a particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding embodiments, the insertion of the unique context identifier into the padding bits of the compressed packet is done starting from the last bit of the compressed packet and inserting the unique context identifier into the padding bits starting from the end of the identifier, in the reading direction of the compressed packet.

[0028] This embodiment proposes an alternative permutation for inserting the unique context identifier into the padding bits. Here, the insertion begins with the last bit of the compressed packet and inserts the identifier from the end of that bit. That is, the last bit of the identifier is inserted into the last bit of the compressed packet, the second-to-last bit of the identifier into the second-to-last bit of the compressed packet, and so on.

[0029] The two preceding embodiments insert the unique context identifier into the padding bits continuously, one bit of the identifier after another, without skipping. This solution has the advantage of simplicity, but an embodiment of the invention can use any permutation, including skipping during the insertion, which will be filled at the end of the permutation.

[0030] According to one embodiment, which may be implemented alternatively or cumulatively with the preceding embodiments, the unique context identifier is repeated until the padding bits are exhausted when the number of padding bits is greater than the size of the unique context identifier.

[0031] With this embodiment, all padding bits are used to transmit the unique context identifier. By repeating this process, the transmission is made more robust in case of transmission errors, without consuming any additional bits, since the insertion of the unique context identifier is always limited to the padding bits that would have to be transmitted anyway.

[0032] According to one embodiment, which may be implemented alternatively or cumulatively with the preceding embodiments, the unique context identifier is truncated during insertion when the number of padding bits is less than the size of the unique context identifier.

[0033] With this embodiment, the insertion of the unique context identifier does not occur on the non-padding bits of the data packet. In this way, the information present in the compressed packet is preserved and is not erased to transmit the unique context identifier. This embodiment takes into account the variable size of the padding bits. It is not possible to guarantee that, for all compressed packets, there will be enough padding bits to insert the entire unique context identifier in their place.

[0034] According to a particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding embodiments, the insertion of the unique context identifier further includes an operation of combining the bits of the compressed packet other than the padding bits with a sequence of bits constructed by repeating the unique context identifier.

[0035] Thanks to this embodiment, additional information is used to facilitate the transmission of the unique context identifier. Indeed, the number of padding bits in the compressed packet is variable and can even be zero. Therefore, there is no guarantee that it will always be possible to write the entire unique context identifier within the padding bits. By combining the bits of the compressed packet outside of the padding bits with a bit sequence constructed by repeating the unique context identifier, additional information is transmitted that allows the receiver to more easily retrieve the unique context identifier inserted into the padding bits or combined with the other bits of the compressed packet. In this mode, the unique context identifier is combined with the bits other than the padding bits and not inserted in their place.Indeed, the information contained in bits other than padding bits must not be erased. Therefore, a combination of methods is used to recover both the initial information of the compressed packet and the unique context identifier, possibly by making some assumptions.

[0036] The operations of inserting the unique context identifier into the padding bits and combining the non-padding bits with a sequence constructed by repeating the unique context identifier can be performed sequentially, in any order, or in parallel. This is because these two operations work on disjoint parts of the compressed packet. Performing the two operations sequentially is simpler, while parallel execution has the advantage of saving execution time.

[0037] According to one embodiment, the combination operation uses an exclusive OR between the bits of the compressed packet and those of the constructed bit sequence.

[0038] In this embodiment, the unique context identifier is combined with the non-padding bits of the compressed packet in a way that allows for easy recovery of the original values ​​of the compressed packet bits before the combination. Indeed, applying a new XOR operation with the unique context identifier restores the original values ​​of the compressed packet bits. In this way, it is possible to recover the original information through trial and error.

[0039] According to a second functional aspect, the invention relates to a method for managing the reception of a compressed data packet by applying a compression rule belonging to a set of compression rules, called a compressed packet, comprising receiving the compressed packet followed by reading in the compressed packet an identifier of said set of compression rules, called a unique context identifier, previously inserted in the compressed packet.

[0040] Thanks to this aspect of the invention, the unique context identifier inserted into the compressed packet is received along with the compressed packet and then read. This information makes it possible, in a multi-context and multi-hop environment, to retrieve the set of compression rules that was used to compress a given packet and thus restore the compressed packet to its original state.

[0041] According to a particular implementation mode with respect to the second functional aspect, the compressed packet includes padding bits, the unique context identifier having been previously inserted into the padding bits of the compressed packet, and the unique context identifier is read by making an assumption about the number of padding bits of the compressed packet.

[0042] With this embodiment, the unique context identifier embedded in the padding bits of the compressed packet can be retrieved. Since the number of padding bits varies for each packet, one approach is to make assumptions about the number of padding bits present in the received compressed packet. Depending on such an assumption, it is possible (or not) to read a context identifier embedded in the padding bits. Furthermore, for a given assumption about the number of padding bits, several context identifiers may be possible. Therefore, several assumptions can be made regarding the context identifier for a given assumption about the padding bit length. For example, for an assumption of zero padding bits, the context identifier could not have been embedded in the non-existent padding bits, and all context identifiers remain possible.Therefore, different hypotheses about the possible value of the identifier of the compression rule set used to compress the packet can exist for a given padding bit length.

[0043] According to a particular implementation method relating to the second functional aspect, which can be implemented alternatively or cumulatively with the previous methods, the process is iterative, a different assumption on the number of padding bits being made at each iteration, and the process stops as soon as the unique context identifier read according to the assumption allows the compressed packet to be decompressed.

[0044] This embodiment provides a possible way to read the unique context identifier. An assumption about the length of the padding bits determines whether or not one or more unique context identifiers for that given length can be read. This read context identifier can then be tested. The test consists of trying to decompress the compressed packet using this identifier. The read context identifier identifies a set of compression rules. The compressed packet also generally carries an identifier for the rule used to compress it. If the set of compression rules corresponding to the read context identifier includes a compression rule matching the rule identifier read on the compressed packet, and if this compression rule allows for consistent decompression of the compressed packet, then the test is successful and the process can stop.In some cases, a decompression rule can be deduced without reading a rule identifier, which does not change the principle of the invention. The compressed packet was thus, thanks to the method, transmitted in a multi-context and multi-hop environment without adding any data to the compressed packet, since the unique context identifier is inserted into the padding bits, therefore without using any additional bits.

[0045] Unfortunately, the unique context identifier read according to the assumption was incorrect, but the compressed packet was still decompressed. This decompression was therefore erroneous, but went undetected. This scenario should, however, be very rare and can be accepted in comparison to the advantage provided by the invention, which enables highly efficient compression in a multi-context and multi-hop environment.

[0046] According to a particular implementation method relating to the second functional aspect, which can be implemented cumulatively with the previous method, the iterative process starts from the maximum possible number for the length of the padding bits and decreases this number by one at each iteration.

[0047] This embodiment provides an efficient way to select the different hypotheses. Starting with a maximum padding bit length, a maximum number of constraints are imposed on the unique context identifier that can be read from the padding bits. It is possible that no identifier can be read due to inconsistency, which would simply indicate that the hypothesis about the padding bit length in the compressed packet is incorrect. By decreasing the padding bit length hypothesis one by one, it will eventually be possible to read a unique context identifier consistent with the padding bit length hypothesis. If this read context identifier allows the compressed packet to be decompressed, it is most likely the correct identifier.The rare case where this identifier is not correct, but still allows the compressed package to be decompressed is accepted in view of the advantages provided by the invention.

[0048] According to a particular implementation mode with respect to the second functional aspect, which may be implemented alternatively or cumulatively with the previous modes, the bits of the compressed packet other than the padding bits having been previously combined with a sequence of bits constructed by repeating the unique context identifier, the decompression of the compressed packet includes an inverse combination with the unique context identifier read allowing the compressed packet to be recovered as it was before the prior combination.

[0049] This embodiment improves the handling of hypotheses about possible unique context identifiers. In this embodiment, to determine whether a unique context identifier derived from a hypothesis is correct, an additional operation is performed before testing the decompression of the compressed packet. This operation is the inverse combination of the operation performed between the unique context identifier and the bits other than padding bits. This inverse combination allows the reconstruction of the original version of the compressed packet before it was combined with the unique context identifier. If the resulting original packet cannot be decompressed using the unique context identifier obtained through the hypothesis, then that hypothesis is incorrect and another must be tried. This additional operation thus makes successive hypotheses more discriminating by performing an extra test.This embodiment therefore reduces the risk that a chosen hypothesis is ultimately wrong, and for this purpose uses additional information that has been given by the combination of the unique context identifier with the bits other than the padding bits of the compressed packet.

[0050] According to a particular implementation method relating to the second functional aspect, which may be implemented alternatively or cumulatively with the previous methods, the first decompressed package obtained by performing a decompression test with the unique context identifier read is considered to be the original package for subsequent uses.

[0051] Thanks to this embodiment, an additional decompression operation is avoided. Since the compressed packet reception process involves successive decompression attempts and stops when decompression is successful, the method according to the invention also includes at least one decompression operation and yields a decompressed packet that, in all likelihood, corresponds to the original packet. The original packet is thus obtained without an additional decompression operation that would be performed with the unique context identifier read and can be used later. The embodiment therefore saves an additional computational step, thus saving time, energy, and computing and memory resources.

[0052] According to a first material aspect, the invention relates to an entity for managing the transmission of a compressed data packet by applying a compression rule belonging to a set of compression rules, called a compressed packet, comprising the following modules: An insertion module into a compressed packet of an identifier from the set of compression rules, called a unique context identifier; and, A transmission module of a compressed packet thus modified by the insertion module.

[0053] According to one embodiment of this material aspect, the invention relates to telecommunications equipment comprising an entity for managing the transmission of a compressed data packet according to the invention.

[0054] According to one embodiment of this material aspect, the invention relates to a mobile terminal comprising an entity for managing the transmission of a compressed data packet according to the invention.

[0055] According to a second material aspect, the invention relates to an entity for managing the reception of a compressed data packet by applying a compression rule belonging to a set of compression rules, called a compressed packet, comprising the following modules: A module for receiving a compressed packet; and, A module for reading in a compressed packet an identifier from the set of compression rules, called a unique context identifier, previously inserted into the compressed packet.

[0056] According to one embodiment of this second material aspect, the invention relates to telecommunications equipment comprising an entity for managing the reception of a data packet compressed according to the invention.

[0057] According to one embodiment of this second material aspect, the invention relates to a mobile terminal comprising an entity for managing the reception of a compressed data packet according to the invention.

[0058] According to another material aspect, the invention relates to a computer program suitable for implementation by an entity managing the transmission of a compressed data packet, the program comprising code instructions which, when executed by a processor, performs the steps of the transmission management process defined above.

[0059] According to another material aspect, the invention relates to a computer program suitable for implementation by an entity managing the reception of a compressed data packet, the program comprising code instructions which, when executed by a processor, performs the steps of the reception management process defined above.

[0060] Finally, according to another material aspect, the invention relates to data carriers on which computer programs are recorded, comprising sequences of instructions for implementing the reception and transmission management processes defined above.

[0061] Data storage media can be any entity or device capable of storing programs. For example, media can include a storage medium, such as a ROM (e.g., a CD-ROM or a microelectronic circuit ROM), or a magnetic recording medium such as a hard drive. Alternatively, media can be transmissible, such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. Programs according to the invention can, in particular, be downloaded from a network such as the Internet. Alternatively, the information storage medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.The program according to the invention can use any type of computer technology in terms of compiled programming languages, interpreted languages, or a combination of both, as well as in terms of operating systems. Brief description of the figures

[0062] The invention will be better understood upon reading the following description, given by way of example, and made with reference to the accompanying drawings in which:

[0063] represents an entity for managing the transmission of a compressed data packet and an entity for managing the reception of a compressed data packet according to the invention.

[0064] illustrates an example of inserting a unique context identifier into the bits of a compressed packet according to an embodiment of the invention.

[0065] illustrates an example of a sequence of steps enabling the reading of a unique context identifier according to an embodiment of the invention.

[0066] illustrates an example of a sequence of steps implementing the processes for managing the transmission and reception of a compressed data packet according to the invention. Detailed description

[0067] Lare represents a computer or telecommunications system including a management entity 100 for the transmission of a compressed data packet P and a management entity 200 for the reception of a compressed data packet P' according to the invention.

[0068] The management entity 100 for the transmission of a compressed data packet P includes the following modules: A module 101 for inserting a unique context identifier ICU into a compressed data packet P; A module 102 for transmitting the compressed data packet P', obtained by inserting the identifier ICU into the compressed packet P.

[0069] The management entity 200 for receiving a compressed data packet P' includes the following modules: A module 201 for receiving the compressed data packet P'; A module 202 for reading the ICU identifier from the compressed data packet P', which had been previously inserted into the compressed packet P. This insertion modifies the compressed data packet P into the compressed packet P'.

[0070] The two management entities 100 and 200 belong to a NET communication network. The NET communication network allows management entities 100 and 200 to communicate with each other, and potentially with other entities, using communication protocols based on the transmission and reception of data packets. The NET network can, for example, be an IP network (an acronym for Internet Protocol). The NET network can also be an Ethernet network. Other communication protocols can be deployed within the NET network. The physical technologies enabling communication within the NET network can be of any type. It can be a wired or wireless network. The NET network can be, for example, the Internet or any subnetwork of the Internet. The NET network can also be a private network, such as a corporate network. The NET network can also be a mobile telecommunications network using 3G and subsequent technologies up to 6G.A network can be a local or larger-scale network. For example, a network can use WiFi or Bluetooth technology. A network can also be an Internet of Things (IoT) network and use protocols suited to this type of communication, such as LoRaWAN, Sigfox, Zigbee, or other similar technologies.

[0071] The two management entities 100 and 200 represent the hardware architecture of a conventional computer. They include, in particular, a processor, RAM (Random Access Memory), and read-only memory such as Flash or ROM (not shown in the figure), or may have such resources. Management entities 100 and 200 also include input / output devices, specifically one or more network cards (not shown in the figure) that allow them to communicate via the NET network. In some embodiments, they may also include devices such as keyboards and / or monitors (not shown in the figure).

[0072] The two management entities 100 and 200 can belong to IT or telecommunications equipment. For example, they can be included in desktop or laptop computers, or computer servers. They can also be included in routers, network gateways, or terminals, whether mobile or not. They can also be included in connected objects of any type, such as smartwatches, connected cameras, connected vehicles, water or energy meters, or others.

[0073] The two management entities 100 and 200 can also be deployed in a cloud architecture. Management entities 100 and 200 can run on remote computing and memory resources to execute the processes described in the invention.

[0074] The two management entities, 100 and 200, can exchange data packets using the protocols deployed in the NET communication network. Specifically, communications within the NET network implement at least one data packet compression protocol. This protocol may be the ROHC protocol, the SCHC protocol, an evolution of one of these protocols, or a protocol that uses principles or techniques similar to those implemented by these protocols.

[0075] In particular, within the NET network, exchanged data packets P, P' can be compressed and decompressed through the implementation of a compression protocol. A data packet P, P' is compressed by one entity by applying a compression rule according to the protocol. The compressed data packet P, P' can then be transmitted across the NET network; compressing the packet significantly saves network, memory, and computing resources. Upon receipt, the compressed packet P, P' can be decompressed by another entity by applying a decompression rule according to the protocol. The decompression rule is, in general, the inverse operation of the operations applied during the compression of the data packet P, P'. Therefore, knowledge of the compression rule applied to compress the data packet P, P' is generally necessary to decompress the packet P, P'.In some embodiments, one can imagine an operation that proceeds by trial and error, thus without knowledge of the compression rule used. However, the standard decompression operation relies on this shared knowledge, between the entity performing the compression on the one hand and the entity performing the decompression on the other, of the applied compression rule.

[0076] The objective of the invention is to implement a data packet compression protocol in an environment with multiple possible compression contexts. A compression context could be, for example, a specific subnetwork, for which certain compression rules are more suitable than others. The presence of different possible compression contexts results in the coexistence of several sets of compression rules. Therefore, the compression of a data packet and the transmission of a compressed packet must be adapted to account for the coexistence of multiple contexts and the multiple sets of compression rules associated with those contexts.

[0077] In particular, rules present in different sets of compression rules can share the same rule identifier, which is used to differentiate a rule within a given set of compression rules. In other words, knowing the compression rule identifier alone is not enough to identify the compression rule used to compress a packet. Indeed, a given rule identifier can correspond to different rules, present in different rule sets, which happen to share the same rule identifier but are otherwise distinct.

[0078] Management entity 100 performs a process for transmitting a compressed data packet P by applying a compression rule belonging to a set of compression rules. This set of compression rules is identified by a unique context identifier (UCI).

[0079] In exemplary embodiments, the method according to the invention includes first obtaining the ICU identifier. For example, network equipment, mobile devices, or computing equipment can be assigned different sets of compression rules corresponding to the various compression contexts that the equipment or device must handle according to a given compression protocol. These different sets of compression rules can be obtained through machine learning by observing real traffic and then distributed to the various devices and devices that will apply them. The machine learning of compression rule sets can be centralized or distributed across the various devices or devices that will use the learned compression rule sets.Sets of compression rules corresponding to different contexts can also be defined by experts and distributed across the various equipment or terminals that will use them.

[0080] In example implementations, a method for obtaining an identifier for compression rule sets is implemented. For example, the method might include extracting target values ​​from the rule fields of the set. Target values ​​may be extracted for only certain types of rules. From these target values, the method might include applying transformations that will produce the identifier for the compression rule set from the extracted target values. These transformations might include applying functions such as hash functions or other encoding functions, as well as functions that ensure a given size for the identifier, such as truncation or punching operations.

[0081] The resulting compression rule set identifier can be expressed as a bit sequence. It can be called a Unique Context Identifier (UCI) because it identifies a network context for which a given compression rule set is relevant. Devices or terminals implementing compression and / or decompression can use a Unique Context Identifier (UCI) to more precisely specify the network context in which they will apply compression and / or decompression rules. The Unique Context Identifier (UCI) thus allows devices or terminals to use a compression protocol in a multi-context or multi-hop environment.

[0082] The ICU identifier thus obtained in certain implementation examples can be used by management entity 100.

[0083] Module 101 of management entity 100 inserts the ICU identifier into a compressed data packet P, which has been compressed by applying a rule belonging to a set of compression rules identified by the ICU identifier. The packet P modified by the insertion of the ICU identifier is denoted P' on the system. To facilitate the insertion of the ICU identifier into the compressed packet P, the ICU identifier can be expressed as a sequence of bits.

[0084] In one embodiment, the ICU identifier is inserted into the padding bits of the compressed packet P. In this way, the data present in the compressed packet P is not erased by the insertion of the ICU identifier. Using the padding bits of the compressed packet P to insert the ICU identifier contributes to the goal of conserving network bandwidth resources, since no additional data is used to transmit the extra information of the ICU identifier.

[0085] In one embodiment, the ICU identifier is inserted into the padding bits of the compressed packet P, starting with the last bit of packet P, according to a defined permutation. Since the number of padding bits varies for each packet, it is convenient to start with the last bit of the compressed packet for the insertion because the padding bits are located at the end of the compressed packet. To ensure that all bits of the compressed packet are inserted, a permutation can be defined to assign to each padding bit one and only one bit from the sequence of bits that represents the ICU identifier. This permutation does not have to be continuous.

[0086] In an example, the insertion of the unique context identifier ICU into the padding bits of the compressed packet P is done by inserting the unique context identifier ICU into the padding bits in the opposite direction to the reading direction of the compressed packet P. Here, the first bit of the identifier ICU is inserted into the last bit of the compressed packet P, if this is a padding bit, then the insertion of the identifier ICU is done in the opposite direction to the reading of the compressed packet P.

[0087] In another example, the insertion of the unique context identifier ICU into the padding bits of the compressed packet P is done by inserting the unique context identifier ICU into the padding bits starting from the end of the ICU identifier, in the reading direction of the compressed packet P. Here, the last bit of the ICU identifier is inserted into the last bit of the compressed packet P, if this is a padding bit, then the insertion of the ICU identifier is done respecting the reading direction of the compressed packet P. That is to say, the last bit of the ICU identifier is inserted on the last bit of the packet P, the second-to-last of the ICU identifier on the second-to-last bit of the compressed packet P and so on.

[0088] There is no guarantee regarding the number of padding bits present in the compressed packet P. In one embodiment, the insertion of the ICU identifier into the padding bits of the compressed packet P stops when there are no more padding bits available to insert the ICU identifier. In other words, in this case, the ICU identifier is truncated when there are not enough padding bits to perform a complete insertion. There may be zero padding bits in the compressed packet P, and in that case, no bits of the ICU identifier will be inserted.

[0089] Conversely, if the number of padding bits exceeds the length of the ICU identifier, one possible implementation is to continue inserting the ICU identifier. This way, all accessible padding bits are used. This redundancy makes the transmission of the ICU identifier more robust.

[0090] In one embodiment, the insertion of the unique context identifier (ICU) further includes an operation that combines the bits of the compressed packet P, other than the padding bits, with a bit sequence constructed by repeating the unique context identifier ICU. In this example, an additional operation improves the transmission of the ICU outside the padding bits. To achieve this, the ICU cannot simply be inserted into the bits of the compressed packet P outside the padding bits. Indeed, a direct insertion would erase the information transmitted in the compressed packet P. The solution given in this embodiment is to combine the ICU with the bits other than the padding bits in order to preserve both pieces of information. One possible combination is to use an exclusive OR operation, which, as we will see, will allow us to easily retrieve the bits of the compressed packet before modification.The combination is done with a sequence built by repeating the unique context identifier ICU. In almost all cases, the non-padding bits of the compressed packet will be greater in number than those that form the ICU identifier, which makes it possible to repeat the latter to reach the end of the non-padding bits of the compressed packet P.

[0091] The operation of combining bits that are not padding bits can be performed sequentially with the operation of inserting them into the padding bits, in any order, or in parallel. This is because these two operations manipulate disjoint parts of the compressed packet P, namely the padding bits on the one hand, and the other bits on the other.

[0092] The result of inserting the ICU identifier into the compressed packet P is a packet P', modified from packet P, but which is also a compressed packet because it is the same size as packet P, which was itself compressed by applying a given compression rule. The compressed packet P' is produced by module 101 of management entity 100. It is provided to module 102 of management entity 100.

[0093] Module 102 of the management entity carries out the transmission of the compressed packet P' as modified by the insertion module 101.

[0094] This transmission of the compressed packet P' is carried out using the NET communication network according to data packet exchange protocols implemented within the NET network. The transmission of a compressed packet P' saves memory, energy, computing power, and bandwidth compared to the original data packet, which had already been compressed to produce packet P. Compared to packet P, the transmission of packet P' includes additional information related to the ICU identifier, which was inserted into the compressed packet P to produce the compressed packet P'.

[0095] Module 201 of management entity 200 performs the reception of the compressed packet P'. This reception is the implementation of the communication protocols deployed in the NET communication network which were used to transmit the compressed packet P'.

[0096] The 202 module of the 2000 management entity reads the ICU identifier from the compressed packet P' of the compression rule set in which the rule that was applied to compress packet P is located. The ICU identifier was previously inserted into the compressed packet P, resulting in the compressed packet P' which was transmitted and then received as shown above.

[0097] In one embodiment, the compressed packet P' includes padding bits, and the ICU identifier has been previously inserted into the padding bits of packet P'. The ICU identifier is then read by making an assumption about the number of padding bits present in packet P'. Indeed, it is this assumption that allows us to determine which bits of the compressed packet P' are likely to carry the unique context identifier ICU.

[0098] According to one embodiment, the reading of the ICU identifier is done using an iterative process, a different assumption on the number of padding bits being made at each iteration, and the process stops as soon as the unique context identifier read according to the assumption allows the compressed packet to be decompressed.

[0099] Reading the ICU identifier generally cannot be done based on a single assumption about the number of padding bits in the compressed packet P'. The reading process is therefore iterative, changing the assumption about the number of padding bits at each iteration. The process stops when the assumption allows reading a unique context identifier ICU, which then enables decompression of the compressed packet P'. Indeed, the context identifier ICU allows finding a set of compression rules that may have been used to compress the packet P (and therefore P', which differs from P by the insertion of the ICU identifier). A rule identifier can then be searched for within the compressed packet P', and if the rule corresponding to this rule identifier in the set of rules identified by ICU allows decompression of the compressed packet P', then there is no need to search further.Unfortunately, the ICU identifier read may be incorrect, leading to erroneous decompression of the compressed packet P'. This risk is low and can be mitigated by including sufficient information about the ICU identifier in the compressed packet P'. This drawback is largely offset by the possibility of implementing highly efficient compression in a multi-hop context.

[0100] In some embodiments, the packet obtained when the decompression of the compressed packet P' is successful will be considered as the original packet, which was originally compressed to give the packet P. In this way, the process achieves the complete decompression of the compressed packet P and does not merely provide the unique context identifier ICU.

[0101] In one embodiment, the iterative process begins with the maximum possible length of the padding bits and decreases this number by one at each iteration. In this way, the assumptions made about the length of the padding bits begin with the most discriminating hypothesis possible, the one that includes the most padding bits. The process proceeds by decreasing this hypothesis by one at each iteration in order to successively examine all possible assumptions about the length of the padding bits of packet P', taking care to examine the most discriminating hypotheses first.

[0102] In another example, the bits of the compressed packet P, other than the padding bits, were previously combined with a sequence of bits constructed by repeating the unique context identifier ICU to give the packet P'. In this example, decompressing the compressed packet P' involves a reverse combination with the unique context identifier ICU read, allowing the compressed packet to be recovered as it was before the prior combination.

[0103] It is possible to provide information about the ICU identifier in the non-padding bits of P'. This is achieved by combining the ICU identifier with the non-padding bits. When an ICU identifier is read from the padding bits of packet P' according to a given hypothesis, the inverse combination can be applied to the non-padding bits of P'. The process then attempts to decompress the result of this inverse combination, since the result is the compressed packet P as it was before the initial combination. If the decompression is successful, it provides further confirmation that the hypothesis is correct. The inverse combination thus allows the recovery of the additional information encoded in the non-padding bits of packet P'.

[0104] In practical examples, the inverse combination is an exclusive OR operation. When the initial combination was performed using an exclusive OR, the inverse combination uses the same exclusive OR operation thanks to its properties. This makes applying a combination on the one hand and its inverse on the other very easy and computationally efficient.

[0105] The, for its part, presents an example of inserting a unique context ICU identifier into a compressed packet P according to an embodiment of the invention.

[0106] In the example shown, the compressed packet P consists of three bytes. The bytes forming P are represented in the figure as separated by vertical bars. The compressed packet P was compressed by applying a rule R. As is often the case, the identifier of the rule R was added to the compressed packet P's header to facilitate subsequent decompression. The identifier of the rule R is given by the first four bytes of the compressed packet P, namely 0001. This identifier is an integral part of the compressed packet P.

[0107] The compressed packet P, expressed as a sequence of bits, did not contain the exact number of bytes. Therefore, packet P was padded with four filler bits, indicated in the figure by the letters XXXX. As is customary, the filler bits XXXX were added to the end of the compressed packet P to ensure it contained the exact number of bytes, thus simplifying its transmission.

[0108] The compression rule R has the identifier 0001. This identifier is expressed as 4 bits. It allows the rule R to be found within a set of compression rules. This set is itself identified by an ICU identifier of 110, which is therefore expressed as 3 bits. It is possible to identify eight sets of compression rules with three bits, and sixteen compression rules with four bits. In other words, in the example given, network equipment can manipulate up to 8 distinct sets of compression rules, and therefore 8 different network contexts. And each context, or set of compression rules, can have up to 16 different rules. Other numerical examples are, of course, possible depending on the lengths of the rule and compression set identifiers.

[0109] It is clear that different sets of compression rules may include different rules but which have the same identifier 0001 as rule R. In itself, knowing the identifier 0001 written in the compressed packet P does not allow us to find the rule R that was used to compress the packet P. The unique context identifier ICU, which is 110, must also be provided.

[0110] To achieve this, the implementation of the compressed packet P transmission process includes a step of inserting the ICU identifier into packet P, which will thus be modified into a packet P'. Packet P' will then be transmitted, and a reception process will allow the initial compressed packet P to be retrieved.

[0111] Inserting the ICU identifier into the compressed packet P involves two distinct operations in this example. These two operations can take place in any order or be performed in parallel.

[0112] Regarding the first operation, the ICU identifier is inserted into the padding bits XXXX of packet P. To do this, a permutation choice is made; in our example, the choice is to write the identifier starting from the last bit of the compressed packet P, in reverse reading order. This is represented by a right-to-left arrow in the diagram. The last three bits of the modified compressed packet P' are therefore bits 011, which correspond to a reverse reading of the ICU identifier 110.

[0113] Since there are four padding bits and the ICU identifier is three bits long, the decision is made to repeat the ICU identifier and, in this example, to write the first bit of the ICU identifier, namely 1, to the last padding bit of the compressed packet P, counting from the end. The last four bits of the modified compressed packet P', which correspond to the four padding bits XXXX of the compressed packet P, are therefore 1011.

[0114] If there had been fewer padding bits than needed to write the ICU identifier, it could have been truncated in our example implementation.

[0115] The second operation involves combining the non-padding bits of the compressed packet P with a sequence constructed by repeating the ICU identifier. Since there are 4 padding bits and 20 other bits in the compressed packet P, the sequence obtained by repeating the ICU identifier is: | 11011011 | 01101101 | 1011. We have used vertical bars to indicate the byte boundaries. This sequence is denoted Rep(ICU) in the diagram.

[0116] The chosen combination operation is an exclusive OR operation performed bit by bit between the bits of packet P other than the padding bits and the sequence constructed by repeating the ICU identifier. This exclusive OR operation is denoted XOR, as is customary in the field.

[0117] After these two operations, which can be performed in any order or in parallel, we obtain a compressed packet P' modified from the compressed packet P by inserting the ICU identifier into the padding bits XXXX of packet P and by combining a sequence constructed by repeating the ICU identifier with the bits of packet P other than the padding bits. Finally, using vertical bars to mark the byte boundaries, the compressed packet P' obtained by modifying the compressed packet P in this way is: | 11001100 | 11100111 | 00101011 |.

[0118] Figure 1, meanwhile, presents an example of reading a unique context ICU identifier in a compressed packet P' according to an embodiment of the invention.

[0119] The compressed packet P' received which is shown in the is the same as that which was obtained in the example of the, namely: | 11001100 | 11100111 | 00101011 |.

[0120] The method according to the invention will seek to read the ICU identifier by making assumptions about the initial length of the padding bits of the compressed packet P which has been modified to give the packet P'. In the example of the, the permutation chosen to insert the ICU identifier consisted of writing it starting from the last bit of the compressed packet, in reverse reading direction, repeating it if there were too many padding bits compared to the length 3 of the ICU identifier and truncating it if necessary.

[0121] So, the reading shown in the beginning takes the last eight bits of the compressed packet P' and reads them backwards, which gives the sequence 11010100. In this example, we take the last eight bits because this is the maximum number of padding bits that could be present in the compressed packet P, i.e., an entire byte.

[0122] The first hypothesis, Hyp1, assumes that the length L of the padding bits was 8, the maximum length. In this case, since the ICU identifier is three bits long, the ICU identifier should be 110. If the length L of the padding bits were indeed eight, the ICU identifier would have been repeated to cover all eight padding bits. However, the sequence 11010100, which is read from the last eight bits of the compressed packet P', does not contain the repetition of the ICU identifier assumed to be 110. Therefore, the first hypothesis, Hyp1, is impossible.

[0123] The same applies to the following hypotheses Hyp2, Hyp3, Hyp4 which are made assuming a length L of the filling bits decreasing by one each time, i.e. successively L=7, L=6, L=5.

[0124] Other sequences of assumptions about the length L of the padding bits can be chosen. For example, it is possible to use jumps to speed up the process. Or to start with a shorter length in order to make several assumptions about the unique context identifier ICU.

[0125] Hypothesis Hyp5 of length L=4 for the padding bits is consistent. It yields an ICU identifier of 110 repeated only on one bit to complete the four padding bits.

[0126] Using this hypothesis Hyp5, it is possible to separate the padding bits (the last four, indicated as XXXX in the diagram) from the other bits (the first twenty) in the compressed packet P'. It is also possible to construct the sequence Rep(ICU) by repeating the identifier ICU until twenty bits are obtained. The inverse combination can then be applied to P' using the exclusive OR (XOR) operation. The advantage of using the exclusive OR (XOR) operation for the combination is that it is used both for combination and inverse combination, which simplifies the process.

[0127] This gives us a hypothesis of a compressed packet P which has been modified according to the process to give the compressed packet P' transmitted and then received instead of P. The ICU identifier is known in the hypothesis and is equal to 110, and the rule R is identified in the hypothesis by the first four bits of packet P, i.e. 0001. These two combined identifiers 110 and 0001 allow us to recover the rule R which was used to give the compressed packet P.

[0128] An operation not shown in the diagram is the final consistency test. Does the identified rule R allow the packet P to be decompressed correctly? If so, the process will stop. The risk of error is considered low enough not to negate the advantage of highly efficient compression. In particular, the inverse combination performed with the Rep(ICU) sequence provides information independent of the assumption about the length L of the padding bits, thus indicating strong consistency in the final result.

[0129] In this particular example, the result obtained by reading the ICU identifier does indeed give the initial compressed packet P. Therefore, decompressing packet P with rule R, obtained from the set identified by the ICU identifier (which is 110) using rule identifier 0001, will be successful.

[0130] The compressed packet reception process therefore also allows us to obtain, through this final test, the decompressed packet for any subsequent use.

[0131] This, for its part, presents an example of a succession of steps implementing the processes for managing the transmission and reception of a compressed data packet according to the invention.

[0132] Management entity 100 is responsible for transmitting the compressed packet P in a multi-context environment. The set of compression rules from which the rule that compressed packet P was extracted is identified by the identifier ICU.

[0133] To carry out the transmission process according to the invention, module 101 of management entity 100 will first insert the ICU identifier into packet P. For this, in the example presented here, module 101 carries out the two steps S1 and S2.

[0134] In step S1, the ICU identifier is inserted into the padding bits of the compressed packet P.

[0135] In step S2, a sequence constructed by repeating the ICU identifier is combined bit by bit with the bits of the compressed packet P that are not padding bits.

[0136] These two steps are presented, in the example, as taking place one after the other, but step S2 can take place before step S1 or be carried out in parallel with step S1. Indeed, these two steps manipulate disjoint parts of the compressed packet P and are therefore independent of each other.

[0137] The compressed packet P thus modified is referred to, in all the figures, as the compressed packet P'. It is provided after the execution of steps S1 and S2 (in any order or in parallel) to module 102 of management entity 100.

[0138] Module 102 of management entity 100 performs the actual transmission of the compressed packet P', which corresponds to the compressed packet P modified by the insertion of the unique context identifier ICU. This transmission is referred to on the system as step S3.

[0139] This transmission takes place via the NET communication network, using the communication protocols offered by this network. The compressed packet P' is received by the management entity 200, which implements a reception process according to the invention.

[0140] In the example shown, module 201 of management entity 200 receives the compressed packet P', performing step S4. It provides it to module 202 of management entity 200, which will read the compressed packet P and the unique context identifier ICU.

[0141] To do this, module 202 makes an assumption in the example presented here, during step S5, about the number of padding bits and will read the ICU identifier and the compressed packet P according to this assumption.

[0142] If the hypothesis allows for the decompression (DEC) of the compressed packet P, the process stops. It has enabled the receipt and decompression of the compressed packet P and the acquisition of the unique context identifier (ICU), which identifies the set of compression rules used to obtain the compressed packet P. The initial packet, resulting from the decompression of packet P, is also obtained by side effect.

[0143] In simpler implementation examples of the processes, only the steps of inserting the ICU identifier into the compressed packet P, transmitting and then receiving it, and reading the ICU identifier from the received packet are carried out.

[0144] Finally, it should be noted that, in this text, the term "module" can refer to a software component, a hardware component, or a set of hardware and software components. A software component itself corresponds to one or more computer programs or subprograms, or more generally, to any element of a program capable of implementing a function or set of functions as described for the modules in question. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module in question (integrated circuit, smart card, memory card, etc.).

Claims

Method of managing the transmission of a compressed data packet by applying a compression rule belonging to a set of compression rules, called compressed packet (P), comprising inserting into said compressed packet (P) an identifier of said set of compression rules, called unique context identifier (UCI), followed by the transmission of the compressed packet thus modified (P'). Method of managing the transmission of a compressed packet according to claim 1 characterized in that the compressed packet (P) includes padding bits and in that the unique context identifier (ICU) is inserted into the padding bits of the compressed packet (P). Method of managing the transmission of a compressed packet according to claim 2 characterized in that the insertion of the unique context identifier (ICU) into the padding bits of the compressed packet (P) is done starting from the last bit of the compressed packet (P) according to a defined permutation. Method of managing the transmission of a compressed packet according to claim 3 characterized in that the insertion of the unique context identifier (ICU) into the padding bits of the compressed packet (P) is done by inserting the unique context identifier (ICU) into the padding bits in the opposite direction to the reading direction of the compressed packet (P). Method of managing the transmission of a compressed packet according to any one of claims 2 to 4 characterized in that the insertion of the unique context identifier (ICU) further includes an operation of combining the bits of the compressed packet (P) other than the padding bits with a sequence of bits constructed by repeating the unique context identifier (ICU). Method of managing the reception of a compressed data packet by applying a compression rule belonging to a set of compression rules, called compressed packet (P'), comprising receiving the compressed packet (P') followed by reading in the compressed packet (P') an identifier of said set of compression rules, called unique context identifier (UCI), previously inserted in the compressed packet (P'). Method for managing the reception of a compressed packet according to claim 6 characterized in that the compressed packet (P') includes padding bits, the unique context identifier (ICU) having been previously inserted into the padding bits of the compressed packet (P'), and in that the unique context identifier (ICU) is read by making an assumption about the number of padding bits of the compressed packet (P'). Method for managing the reception of a compressed packet according to claim 7 characterized in that the method is iterative, a different assumption on the number of padding bits being made at each iteration, and in that the method stops as soon as the unique context identifier (ICU) read according to the assumption allows the compressed packet (P') to be decompressed. Method for managing the reception of a compressed packet according to claim 8 characterized in that the iterative method starts from the maximum possible number for the length (L) of the padding bits and decreases this number by one at each iteration. Method of managing the reception of a compressed packet according to any one of claims 6 to 9 characterized in that, the bits of the compressed packet (P') other than the padding bits having been previously combined with a sequence of bits constructed by repeating the unique context identifier (ICU), the decompression of the compressed packet (P') includes an inverse combination with the unique context identifier (ICU) read allowing the compressed packet (P') to be recovered as it was before the prior combination. Management entity (100) of the transmission of a compressed data packet by the application of a compression rule belonging to a set of compression rules, called compressed packet (P), comprising the following modules: A module (101) for inserting into the compressed packet (P) an identifier from the set of compression rules, called unique context identifier (UCI); and, A module (102) for transmitting the compressed packet (P') thus modified by the insertion module (101). Management entity (200) for receiving a compressed data packet by applying a compression rule belonging to a set of compression rules, called compressed packet (P'), comprising the following modules: A module (201) for receiving the compressed packet (P'); and, A module (202) for reading from the compressed packet (P') an identifier from the set of compression rules, called unique context identifier (UCI), previously inserted into the compressed packet (P'). Mobile terminal comprising a management entity (100) for the transmission of a compressed data packet according to claim 11. Mobile terminal comprising a management entity (200) for receiving a compressed data packet according to claim 12. Computer program capable of being implemented by a management entity (100), the program comprising code instructions which, when executed by a processor, performs the steps of the process of managing the transmission of a compressed data packet defined in claim 1. Computer program capable of being implemented by a management entity (200), the program comprising code instructions which, when executed by a processor, carries out the steps of the process of managing the reception of a compressed data packet defined in claim 6. Data carrier, on which is recorded a computer program comprising a sequence of instructions for implementing the method of managing the transmission of a compressed data packet according to claim 1 when it is loaded into and executed by a processor. Data carrier, on which is recorded a computer program comprising a sequence of instructions for implementing the method of managing the reception of a compressed data packet according to claim 6 when it is loaded into and executed by a processor.

Images