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

Abstract

Methods for managing the transmission and reception of a compressed data packet. 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 the compressed packet (P), comprising inserting into said compressed packet (P) an identifier of said set of compression rules, called the unique context identifier (UCI), followed by the transmission of the compressed packet thus modified (P'). Figure 1

Description

Title of the invention: Methods for managing the transmission and reception of a compressed data packet. Technical field

[0001] The technical field is that of the compression of data 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 (acronym for 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 elements that constitute digital data—to the interpretation of data for computer applications. Bits are typically grouped into bytes, 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 the interaction of the various protocols between 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 Internet Protocol (IP) in one of its versions, IPv4 or IPv6. 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 Data Link layer protocol, 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 situation.

[0005] Other Application layer protocols 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 (UserDatagram 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 header, which contains the information necessary for the protocol responsible for processing the packet; the second part is the payload, which contains the data carried within the packet itself. If packets of a given protocol contain one or more encapsulated packets of another protocol, the payload of a packet of the first protocol may contain the header of that other protocol. At the Data Link layer, the term frame is used rather than packet, and, in addition to the header, there is a footer indicating the end of the frame.

[0007] Packet headers include fields. A field is a continuous set of bits of fixed or variable length. When a field is variable in length, mechanisms exist to determine the actual length of the transmitted field. When the value in a fixed-length field is variable in length, padding bits are used to pad the value up to the field's fixed length. A 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 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 parts. sections, namely the header fields. The packet payload can also be divided into several sections, for example by defining sections of a constant length expressed in number of bits.

[0008] A packet analysis tool such as Wireshark or tcpdump allows the capture and analysis of data packets. The analysis makes it possible to separate a data packet exchanged over a network into its header and payload, to read the information contained in the header and the data contained in the payload, and to identify the various sections of a packet, both in its header and in its payload. It should be noted that, 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 successively presents 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 or 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) standardization body in RFC 3095 (Request For Comments, a specification document underlying the Internet), and SCHC (Static Context Header Compression), defined by the IETF in RFC 8724.

[0010] These protocols operate using compression rules that apply to a particular data packet. A compression rule specifies, on the one hand, the conditions that a data packet must meet for the rule to apply to that packet, and on the other hand, the compressions performed when the rule is applied to a packet. 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 compression 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 this value. The receiver, knowing the compression rule applied, 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 others... According to the rules, the condition applies to 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 though the compression is limited to the headers.

[0011] In all cases, the operation of data packet compression protocols relies on the existence of sets of compression rules that describe the compression operations to be performed on the values ​​of header fields or, more generally, on sections of data packets. These compression operations are triggered when the packets meet conditions relating to the values ​​taken by 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 ​​taken by the fields of the packet in question. When a data packet is compressed by a given rule, it is transmitted in association with an identifier of the applied compression rule.In this way, the receiver can determine the compression rule applied to the packet, thus reconstructing the original packet by performing the reverse operations. 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 performs 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 prior art and will not be described further. State of the art

[0013] As previously stated, 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 ensure the compression and then decompression of the transmitted packets. When a sender applies a compression rule to a data packet before transmitting it, it attaches 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 in the compression rule set thanks to its identifies and reconstructs the original packet by applying the inverse operations of those that form the applied compression rule.

[0014] These elements are well established in compression protocols, particularly in the ROHC and SCHC protocols. In the ROHC protocol, compression occurs in the context of mobile telecommunications between a base station and mobile terminals, 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 objects belonging to the network created by the gateway and shares with them the same set of compression rules.

[0015] To date, it is not possible to use these compression techniques in larger networks, such as the Internet. Indeed, in larger networks, equipment such as routers acts as a gateway between distinct networks. A data packet travels from network to network before reaching its destination. Communication occurs by passing from network to network and is therefore called multi-hop. A given piece of equipment, in this context, communicates with other equipment in several distinct contexts, each context corresponding to a given network. Moreover, these contexts change over time; a piece of equipment such as a router may at a given time be connected to a set of other routers and share with them sets of compression rules, sets which 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 be found in several compression rule sets corresponding to several distinct contexts.

[0017] Therefore, there are currently no possibilities of using 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 equipment Networks must use multiple sets of compression rules, each corresponding to distinct contexts.

[0018] The invention improves the situation. Description of the invention

[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 inserting into said compressed packet 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 the invention, it becomes possible to use highly efficient compression in an environment 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 piece of equipment to compress a data packet before sending it to another piece of equipment that belongs to the same context and has the specific set of compression rules stored in memory. A given piece of equipment will therefore manipulate several distinct sets of compression rules, each corresponding to a given context.A unique context identifier (UCI) can be assigned to a given set of compression rules. This UCI will be the same for different devices that are part of the same context and use the same set of compression rules. The methods for creating and assigning this unique context identifier are outside the scope of this 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 device. The invention enables compression to function in a multi-context and multi-hop environment by ensuring that an identifier of the rule set used is transmitted within 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, it is possible to avoid context confusion in multi-hop communications around the network device 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 set of compression rules 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 necessary to ensure that this transmission is carried out economically. In this embodiment, the objective of maximum data transmission 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 required.The invention also optimizes the resources reserved for transmission by using padding 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 may 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 makes it possible to effectively use the padding bits of 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, the 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... 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 bits of the unique context identifier can be inserted into the padding bits through permutation rather than using 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 direction of reading the compressed packet. This method corresponds to a permutation defined on 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 direction 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 direction of reading the compressed packet.

[0028] This embodiment proposes to implement an alternative permutation for inserting the unique context identifier into the padding bits. Here, the insertion is performed starting from the last bit of the compressed packet and inserting 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 penultimate bit of the identifier is inserted into the penultimate 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] Thanks to this embodiment, all the padding bits are used to transmit the unique context identifier. By repeating this, the transmission is made more robust in case of a transmission error, while not consuming more bits in the transmission, 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] Thanks to this embodiment, the insertion of the unique context identifier does not occur on the bits of the data packet that are not padding bits. In this way, the information present in the compressed packet is well 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 fully write the unique context identifier within the padding bits. By combining the bits of the compressed packet outside the padding bits with a bit sequence constructed by repeating the unique context identifier, additional information is transmitted that will allow 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 present in bits other than the padding bits must not be erased. Therefore, it is a combination that will allow the information to be recovered. initial of the compressed packet as well as the unique context identifier which is achieved, possibly by making assumptions.

[0036] The operations of inserting the unique context identifier into the padding bits, on the one hand, and combining the non-padding bits with a sequence constructed by repeating the unique context identifier, on the other hand, 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 such a way that the original values ​​of the compressed packet bits before combination can be easily recovered. Indeed, applying a new XOR operation with the unique context identifier allows the original values ​​of the compressed packet bits to be restored. In this way, the original information can be recovered by 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 in the compressed packet is received 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 embodiment 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] Thanks to this embodiment, the unique context identifier inserted in the padding bits of the compressed packet can be retrieved. Since the number of padding bits varies for each packet, one way to proceed is to make assumptions about the number of padding bits present in the packet The compressed packet that was received is considered. Under such an assumption, it is possible (or not) to read a context identifier inserted into the padding bits. Furthermore, for a given assumption about the number of padding bits, several context identifiers are 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 inserted into the non-existent padding bits, and all context identifiers remain possible. Different assumptions about the possible value of the identifier of the compression rule set used to compress the packet can thus exist for a given padding bit length.

[0043] According to a particular implementation mode with respect to the second functional aspect, which may be implemented alternatively or cumulatively with the preceding modes, 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. Indeed, the read context identifier allows the identification of a set of compression rules. The compressed packet also generally carries an identifier for the rule used to compress the packet. 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 the compressed packet to be decompressed consistently, 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 therefore, 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, thus without using any additional bits.

[0045] Unfortunately, the unique context identifier read according to the assumption was incorrect, but still allowed the compressed packet to be decompressed. This decompression was therefore erroneous, but was not detected. This scenario should, however, be very rare and can be accepted in comparison to the advantage brought about by the invention which allows for very efficient compression in a multi-context and multi-jump environment.

[0046] According to a particular implementation mode with respect to the second functional aspect, which may be implemented cumulatively with the previous mode, 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 length hypothesis for the padding bits, 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 length of the padding bits in the compressed packet is incorrect. By decreasing the hypothesis about the length of the padding bits one by one, it will eventually be possible to read a unique context identifier consistent with the hypothesis about the length of the padding bits. If this read context identifier allows the compressed packet to be decompressed, it is in all likelihood the correct identifier.The rare case where this identifier is incorrect, 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 preceding 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] Thanks to this embodiment, the handling of hypotheses about possible unique context identifiers is improved. Indeed, in this embodiment, to decide whether a unique context identifier derived from a hypothesis is correct, an additional operation is performed before the decompression test of the compressed packet. This operation is the inverse combination of the operation performed between the unique context identifier and the bits other than the padding bits. This inverse combination makes it possible to reconstruct the original version of the compressed packet before it was combined with the unique context identifier. If the original packet thus obtained cannot be decompressed using the unique context identifier obtained by hypothesis, then this hypothesis is incorrect and another one must be tried.This additional step therefore makes successive hypotheses more discriminating by performing an additional test. This method of implementation... It therefore reduces the risk that a chosen hypothesis is ultimately wrong, and for this purpose uses additional information that was given by combining the unique context identifier with bits other than padding bits of the compressed packet.

[0050] 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 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 includes successive decompression attempts and stops when decompression is successful, the process according to the invention also includes at least one decompression operation and makes it possible to obtain a decompressed packet that, in all likelihood, corresponds well to the original packet. The original packet is thus obtained by avoiding an additional decompression operation that would be performed with the unique context identifier read and can be used subsequently. 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: • A module for inserting an identifier from the compression rule set, called a unique context identifier, into a compressed package; and, • A transmission module for 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 data packet compressed 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 reading module in a compressed package of an identifier from the set of compression rules, called a unique context identifier, previously inserted into the compressed package.

[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 compressed data packet 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, carries out 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 for managing the reception of a compressed data packet, the program comprising code instructions which, when executed by a processor, carries out 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 carriers can be any entity or device capable of storing programs. For example, the carriers can include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means such as a hard drive. On the other hand, the carriers can be transmissible media such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The programs according to the invention can, in particular, be downloaded from a network such as the Internet. Alternatively, the information carrier 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] [Fig-1] 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] [Fig.2] illustrates an example of inserting a unique context identifier into the bits of a compressed packet according to an embodiment of the invention.

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

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

[0067] The [Fig.1] 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 comprises the following modules: • A module 101 for inserting a unique context identifier (ICU) into a compressed data packet P; • A 102 module for transmitting the compressed data packet P', obtained by inserting the ICU identifier into the compressed packet P.

[0069] The management entity 200 for receiving a compressed data packet P' comprises the following modules: • A module 201 for receiving the compressed data packet P'; • A 202 module read from the compressed data packet P' of the ICU identifier 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, according to communication protocols based on the transmission and reception of data packets. The NET network can, for example, be an IP network (acronym for Internet Protocol). The NET network can also be an Ethernet network. Other communication protocols can be deployed in the NET network. Physical technologies The means of communication within a network can be of any type. It can be a wired or wireless network. A network can be, for example, the Internet or any subnetwork of the Internet. A network can also be a private network, such as a corporate network. A network can also be a mobile telecommunications network using 3G and later technologies up to 6G. A network can be a local area network or a larger-scale network. A network can, for example, use Wi-Fi or Bluetooth technology. A network can be an Internet of Things (IoT) network and use protocols adapted to this mode of communication, such as LoRaWAN, Sigfox, Zigbee, or other similar technologies.

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

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

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

[0074] The two management entities 100 and 200 can transmit data packets to each other using the protocols deployed in the NET communication network. In particular, communications within the NET network implement at least one data packet compression protocol. This protocol may be the ROHC protocol, or the SCHC protocol, or 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, in the NET network, the exchanged data packets P, P' can be compressed and decompressed by implementing a compression protocol. A data packet P, P' is compressed by an entity by applying a compression rule according to the protocol. The compressed data packet P, P' can then be transmitted in the NET network; compressing the packet saves network, memory, and computing resources very significantly. When received, 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 application of the inverse operations of the operations that were applied during the compression of the data packet P, P'. Knowledge of the compression rule that was applied to compress the data packet P, P' is therefore, in general, necessary to decompress the packet P, P'.In some embodiments, one can imagine an operation that proceeds by trial and error, therefore without knowledge of the compression rule used. However, the standard operation of decompression 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 be able to implement a data packet compression protocol in an environment where there are several possible compression contexts. A compression context could be, for example, a particular 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. The compression of a data packet and the transmission of a compressed packet must therefore be adapted to take into account the coexistence of several contexts and several sets of compression rules associated with the different contexts.

[0077] In particular, rules present in different sets of compression rules may have 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 sufficient to determine the compression rule used to compress a packet. Indeed, a given rule identifier may correspond to different rules, present in different sets of rules, which happen to share the same rule identifier but are otherwise distinct.

[0078] The 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 ICU identifier, called a unique context identifier.

[0079] In exemplary embodiments, the method according to the invention includes first obtaining the ICU identifier. For example, network equipment, mobile terminals, or computer equipment can be assigned different sets of compression rules corresponding to the different compression contexts that the equipment or terminal 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 equipment and terminals that will apply them. The machine learning of compression rule sets can be centralized or distributed across the various equipment or terminals that will use the learned compression rule sets.Compression rule sets corresponding to different contexts can also be defined by experts and distributed across the various devices or terminals that will use them.

[0080] In exemplary embodiments, a method for obtaining an identifier for compression rule sets is implemented. For example, the method may include extracting target values ​​from the rule fields of the set. Target values ​​may be extracted for certain types of rules only. From these target values, the method may include applying transformations that produce the identifier of the compression rule set from the extracted target values. These transformations may include applying functions such as hash functions or other encoding functions, as well as functions for ensuring 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 (ICU) because it allows the identification of a network context for which a given compression rule set is relevant. Devices or terminals that implement a compression and / or decompression process can use a unique context identifier (ICU) to better specify in which network context they will apply compression and / or decompression rules. The unique context identifier (ICU) 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 embodiment examples can be used by the 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' in [Fig. 1]. 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] According to 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 objective of saving bandwidth resources in the NET network, since no additional data is used to transmit the extra information of the ICU identifier.

[0085] According to 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 to perform 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 so that each padding bit is assigned one and only one bit forming the sequence of bits that represents the ICU identifier. This permutation does not have to be continuous.

[0086] In one 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 identifier ICU, in the reading direction of the compressed packet P. Here, the last 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 respecting the reading direction of the compressed packet P. That is to say, the last bit of the identifier ICU is inserted on the last bit of the packet P, the penultimate bit of the identifier ICU on the penultimate 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 for inserting the ICU identifier. In other words, in this case, the ICU identifier is truncated when there are not enough padding bits to perform a full 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 present exceeds the length of the ICU identifier, one possible implementation is to continue inserting the ICU identifier. In this way, all accessible padding bits are used. This redundancy makes the transmission of the ICU identifier more robust.

[0090] According to one embodiment, 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 bit sequence constructed by repeating the unique context identifier ICU. In this example, an additional operation improves the transmission of the ICU identifier outside the padding bits. For this reason, the ICU identifier 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 identifier 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 constructed 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 combination operation with bits that are not filler bits can be performed sequentially with the insertion operation into the filler bits, in any order, or in parallel. Indeed, these two operations manipulate disjoint parts of the compressed packet P, namely the filler 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 compared to 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' thus 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 put in place works within the NET network. The transmission of a compressed packet P' saves resources in memory, energy, computing power and bandwidth compared to the original data packet which had already been compressed to give the packet P. Compared to packet P, the transmission of packet P' contains additional information relating to the ICU identifier which was inserted into the compressed packet P to give 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] Module 202 of management entity 2000 reads from the compressed packet P' the ICU identifier 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, which resulted in the compressed packet P' which was transmitted and then received as shown above.

[0097] According to 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 such an assumption that makes it possible to know 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 by means of 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 cannot generally be done after a single assumption about the number of padding bits in the compressed packet P'. The reading process is therefore iterative and proceeds by changing the assumption about the number of padding bits at each iteration. The process stops when the assumption actually allows reading a unique context identifier ICU, which then allows decompression of the compressed packet P'. Indeed, the context identifier ICU makes it possible to find a set of compression rules that could 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 in 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 it is not necessary to search further.Unfortunately, the ICU identifier read may not be correct and lead to an incorrect decompression of the compressed packet P'. This risk. is low and can be reduced by writing sufficient information relating to the ICU identifier in the compressed packet P'. This disadvantage is largely offset by the possibility of implementing very efficient compressions in a multi-hop context.

[0100] In embodiments, the packet obtained when the decompression of the compressed packet P' is successful will be considered as the original packet, which was initially 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] According to one embodiment, the iterative process begins with the maximum possible number for the length of the padding bits and decreases this number by one at each iteration. In this way, the hypotheses 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 hypotheses 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 have been previously combined with a sequence of bits constructed by repeating the unique context identifier ICU to give the packet P'. In this example, the decompression of the compressed packet P' includes 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 bits of P' that are not padding bits. To do this, a combination of the ICU identifier with the non-padding bits can be performed. When an ICU identifier is read from the padding bits of packet P' according to a given assumption, the inverse combination can be applied to the non-padding bits of P'. It is the result of this inverse combination that the process will then attempt to decompress, since the result of this inverse combination is the compressed packet P as it was before the initial combination. If the decompression is successful, this is further evidence that the assumption made is correct. The inverse combination thus makes it possible to recover the additional information encoded in the non-padding bits of packet P'.

[0104] The inverse combination, in exemplary embodiments, is an exclusive OR operation. When the initial combination was performed with an exclusive OR, the inverse combination uses the same exclusive OR operation thanks to the properties of this operation. This makes applying a combination on the one hand and the inverse combination on the other very easy and economical in terms of computing resources.

[0105] Figure 2, meanwhile, presents an example of the insertion of an ICU identifier of a unique context in a compressed packet P according to an embodiment of the invention.

[0106] In the example in [Fig. 2], 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 in its 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 fall to an 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 so that it would consist of an exact number of bytes, thus simplifying its transmission.

[0108] The compression rule R has the identifier 0001. This identifier is expressed in 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 in three 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 in [Fig. 2], 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 quite clear that different sets of compression rules may include different rules but which have the same identifier 0001 as rule R. In itself, knowledge of the identifier 0001 written in the compressed packet P does not allow us to find the rule R which was used to compress the packet P. The unique context identifier ICU which is 110 must also be communicated.

[0110] To this end, the implementation of the compressed packet P transmission process includes a step of inserting the ICU identifier into the packet P, which will thus be modified into a packet P'. The 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, as shown in [Fig. 2], involves two distinct operations. 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. A permutation choice is made for this; 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 [Fig. 2]. 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 consists of three bits, the choice is made to repeat the ICU identifier and, in this example, to write the first bit of the ICU identifier, i.e., 1, to the last padding bit of the compressed packet P, starting 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 necessary to write the ICU identifier, it could have been truncated in our example embodiment.

[0115] As regards the second operation, it consists of combining the bits other than the 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 as follows: I 11011011 I 01101101 I 1011. We have used vertical bars to indicate the byte boundaries. This sequence is denoted Rep(ICU) in [Fig. 2].

[0116] The chosen combination operation is a bitwise exclusive OR operation between the bits of packet P other than the padding bits and the sequence constructed by repeating the identifier ICU. This exclusive OR operation is denoted XOR as is customary in [Fig.2].

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

[0118] Fig. 3, 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 [Fig.3] is the same as that which was obtained in the example in [Fig.2], namely: I 11001100 I 11100111 I 00101011 I.

[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 [Fig.2], 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 [Fig.3] starts by taking the last eight bits of the compressed packet P' and reading 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, Hypl, assumes that the length L of the padding bits was 8, i.e., the maximum length. In this case, since the length of the ICU identifier is three bits, the ICU identifier should be 110. If the length L of the padding bits were indeed eight, the ICU identifier would have been repeated until all eight padding bits were covered. 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. The first hypothesis, Hypl, is therefore 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 make jumps to speed up the process. Or to start from a smaller length in order to make several assumptions about the unique context identifier ICU.

[0125] Hypothesis Hyp5 of length L=4 of the padding bits is consistent. It gives an ICU identifier which is equal to 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 [Fig. 3]) 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 combination The inverse can then be applied to P' by applying the exclusive OR (XOR) operation. The advantage of using the exclusive OR (XOR) operation as a combination is that it is used both in combination and inverse combination, which simplifies the processes.

[0127] We thus obtain 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 in place 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 the packet P, i.e. 0001. These two joint identifiers 110 and 0001 make it possible to recover the rule R which was used to give the compressed packet P.

[0128] An operation not shown in [Fig. 3] 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 sufficiently low 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 ensuring high consistency of the final result.

[0129] In this case, in the example of [Fig. 3], the result obtained by reading the ICU identifier does indeed give the initial compressed packet P. The decompression of packet P with the rule R obtained in the set identified by the ICU identifier, which is 110, using the rule identifier 0001, will therefore be successful.

[0130] The compressed packet reception process therefore also makes it possible to obtain, by this final test, the decompressed packet for any subsequent use.

[0131] Fig. 4, meanwhile, presents an example of a succession of steps implementing the methods 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 purpose, in the example presented here, module 101 carries out the two steps SI and S2.

[0134] In the SI step, 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 filler bits.

[0136] These two steps are presented, in the example of [Fig. 4], as taking place one after the other, but step S2 may take place before step SI or may be carried out in parallel with the SI step. 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 SI and S2 (in any order or in parallel) to module 102 of management entity 100.

[0138] Module 102 of management entity 100 carries out 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 designated in [Fig.4] as step S3.

[0139] This transmission takes place through 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 in [Fig.4], 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] For this purpose, module 202 makes an assumption in the example presented here, during step S5, on the number of padding bits and will read the ICU identifier and the compressed packet P according to this assumption.

[0142] If the assumption allows the DEC decompression of the compressed packet P, the process stops. It has made it possible to receive and decompress the compressed packet P and to obtain the unique context identifier ICU that 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 embodiments 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 here 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 concerned. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module concerned (integrated circuit, smart card, memory card, etc.).

Claims

Demands

1. 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').

2. 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).

3. 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.

4. 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).

5. 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 filler bits with a sequence of bits constructed by repeating the unique context identifier (ICU).

6. 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').

7. 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').

8. 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.

9. 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.

10. A method for 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.

11. Management entity (100) for the transmission of 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 (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).

12. Management entity (200) of the reception of a data packet compressed by the application of 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 (ICU), previously inserted into the compressed packet (P').

13. Mobile terminal comprising a management entity (100) for the transmission of a compressed data packet according to claim 11.

14. Mobile terminal comprising a management entity (200) for receiving a compressed data packet according to claim

15. 1Z. 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 method for managing the transmission of a compressed data packet defined in claim 1.

16. Computer program capable of being implemented by a management entity (200), the program comprising code instructions which, when executed by a processor, performs the steps of the process of managing the reception of a compressed data packet defined in claim 6.

17. 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 loaded into and executed by a processor.

18. 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