Rule-based compression method and corresponding management entity

Abstract

The invention relates to a method for determining an identifier of a set of data compression rules, a rule comprising at least one target value of at least one data field, said method being implemented by a data processing unit and comprising: applying a transformation to at least one target value selected from the target values included in the rules of the set of compression rules, the determined identifier resulting from said application.

Description

Method for determining identifier and management entity

[0001] This disclosure falls within the domain of data compression and decompression.

[0002] More specifically, it concerns a process for determining an identifier and a corresponding management entity.

[0003] Modern 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 related to a communication is sent by the sender to a receiver. The packets contain the receiver's address so that it can be addressed using various routing algorithms, and the content of the communication is reconstructed by the receiver by regrouping the data contained in the different packets. 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, which are sets of eight bits.The various protocols are traditionally viewed as being organized in layers, with a protocol at one layer relying on a protocol at a lower layer. The OSI (Open Systems Interconnection) model and the Internet model describe how the various protocols interact 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 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. 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. 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" will contain the version number of the protocol used. This field is four bits long. Other fields include, for example, the source and destination IP addresses of the packet.A header is therefore naturally divided into several 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 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 payload. It's important to remember that, following the encapsulation of data packets, the typical header of a packet will consist of several concatenated headers, one for each encapsulated protocol. For example, an Ethernet frame encapsulating an IP packet will begin with the IP header, followed by the UDP header. The fields of the IP packet will therefore be followed in the frame by the fields of the UDP packet.

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

[0010] There is a clear need for data compression in digital telecommunications to optimize the use of hardware and energy resources consumed by telecommunications networks. This need explains the creation of protocols dedicated to compressing exchanged data packets.

[0011] As we have seen, the exchanged data packets consist of a header containing the information necessary for packet transmission and a payload comprising the data transmitted by the packet itself. Compression can therefore be applied to the payload or to the data packet headers. Since the values ​​of certain fields in the data packet headers will take constant or only slightly variable values, it is possible to achieve very efficient compression of data packets by focusing solely on compressing the values ​​of the data packet header fields.

[0012] A prime example of a protocol that compresses the values ​​of data packet header fields is Robust Header Compression (ROHC), defined by the Internet Engineering Task Force (IETF) in RFC 3095. The basic principle of this protocol is that certain header field values ​​within the same communication will remain unchanged from one communication to the next. For example, the source and destination address fields will remain the same during a communication. After the first packet containing these field values ​​is sent, these values ​​are removed from the headers of subsequent packets to compress the packet header, and therefore the packet itself. These values ​​are then inserted upon reception, as they are known after the first packet was sent.Erasure is performed by a compression module and insertion of the value by a decompression module. Other types of compression can be applied.

[0013] This results in very efficient compression of data packets, even though the compression is limited to the headers. The ROHC protocol is used, for example, in mobile telecommunications networks. However, it requires that a context be created for each communication, specifying which values ​​can be compressed and how. Senders and receivers must therefore regularly update the contexts used for header compression. This update operation is very expensive, and other mechanisms are preferred in certain use cases.

[0014] The context of communication networks dedicated to connected objects imposes additional constraints. We are talking here about low-power wide area networks, also known as LPWANs, an acronym for Low-Power Wide Area Networks. In such a network, we find connected objects that must minimize their power consumption, such as meters deployed in locations without access to mains electricity and requiring battery power for several years. These objects communicate wirelessly with a gateway that covers a wide area. Updating the context with each communication would entail high bandwidth consumption, making the ROHC header compression protocol unsuitable in this context.

[0015] Furthermore, the data exchanged by these devices is often very small and may simply indicate that the device is still active, or it may only need to report a single value, such as a temperature reading for a thermometer or a water level reading for a water meter. The size of the data packet headers relative to the payload size will therefore be proportionally larger in the context of LPWANs than in other contexts. Consequently, there is a need for efficient data packet compression, which, in the context of LPWANs, focuses on compressing the values ​​in the header fields.

[0016] The SCHC protocol (acronym for Static Context Header Compression), defined by the IETF in RFC number 8724, was designed for use in the context of LPWANs. It is based on a static context.

[0017] For a given context, such as a type of connected device deployed on a given network, compression rules will be defined. These rules encompass operations that can be applied to the values ​​of the fields in packet headers. These operations can be of three types, all based on the idea that values ​​in certain fields, or a portion thereof, can be erased before transmission and then reconstructed upon reception: • The first type of compression operation is erasure: the field value is read and erased by the compression module if the value matches the expected one. The compression module is, for example, located within the connected device. The erased value is inserted upon reception by the decompression module, which is located in the gateway and operates under the same rules as the compression module. This type of operation is suitable for fields that take a constant value, such as the Version field in IP packets.If the field takes a value other than expected, the operation is not applied, the compression rule is ignored, and another rule may be used, or the field value may be transmitted unchanged. A second type of compression operation uses a dictionary: a dictionary is built for certain field values, and if the field value is found in the dictionary, the compression module will replace the field value with its index in the dictionary. The decompression module uses the dictionary to replace the index with the deleted value. Again, a field value outside the dictionary may be transmitted unchanged if no rule applies. A third type of operation involves prefix deletion: the field value is a sequence of bits, and a prefix of varying length may be defined in a compression operation.If the value has this prefix, the prefix is ​​erased during compression and inserted during decompression, or the value is transmitted unchanged if the prefix is ​​not recognized by the operation.

[0018] For completion reasons, a fourth type of operation is defined which consists of ignoring the value of the field and passing it as is.

[0019] Other combinations are possible, as well as other compression / decompression actions, for example to deal with fields of variable length.

[0020] A set of compression rules is then defined for a given deployment context. For example, compression rules (and their symmetrical decompression rules) can be defined for a gateway managing an LPWAN network and for all devices connected to this network and the internet via the gateway. The rule set can then handle compression and decompression of all data packets exchanged within the LPWAN network, with compression limited to the values ​​of the header fields. The SCHC protocol determines which compression rule applies when a data packet travels through the network.

[0021] To achieve this, each compression rule in the set is defined for a specific packet header format and consists of a set of operations to be applied to the values ​​of the header fields of a packet that conforms to that format. Several rules can cover the same data packet header format. For example, compression rules will be defined for the format of IP packets encapsulating a UDP packet, and these rules will include operations for all fields of an IP packet header followed by a UDP packet header.

[0022] A compression rule is part of a set of rules and has a rule identifier. The set of rules will attempt to cover all possible formats of data packet headers that can be exchanged in a given context.

[0023] The SCHC compression / decompression protocol is applied by a compression module, which processes a packet before sending it to a decompression module. Both compression and decompression modules share the same set of rules, defined for a given context. When a data packet is to be processed by the compression module, the protocol scans the compression module's rule set to select one or more rules. If a rule does not match the format of the header fields of the processed packet, the rule is discarded. If the field format matches, the protocol examines whether the field values ​​correspond to all the matching operators defined in the rule. If not, the rule is again discarded. If no rule matches, the packet is sent without processing. In all cases, the packet's payload is not processed by the SCHC protocol.In the context of LPWANs, packet compression limited to the compression of header field values ​​is still effective, because the size of the headers is proportionally important.

[0024] This illustrates the advantage of ignoring the field value and passing it as is. This ensures that a rule can effectively be applied to all fields in a given header: for easily compressible fields, an efficient compression operation will be defined, and for other fields, the operation that does nothing will serve as completion.

[0025] Ultimately, several rules can be selected where the field format and field values ​​match. One rule is then chosen, and only one, for example, the first one encountered in the rule set, or chosen randomly, according to the SCHC protocol implementation. The operations defined in the rule are applied by the compression module to the values ​​of the header fields in the packet. The packet is then transmitted with its header values ​​compressed, along with the identifier of the applied rule. The decompression module receives the packet with the compressed header values; uses the rule identifier to find the applied operations; and applies the corresponding decompression operations.For example, if the compression operation used a dictionary for a field value, the decompression module will use the transmitted index value to replace it with the value expected in the dictionary.

[0026] Since the rule identifier used for compression must be transmitted, along with certain values ​​(dictionary indices), there will be a limit beyond which adding new compression rules in a given context will no longer be worthwhile. This is because the potential gain from the additional rule is outweighed by the transmission cost incurred by the increasing size of the rule identifier as new rules are added. For example, beyond eight rules, the transmitted rule identifier will be encoded using three bits instead of two. If adding a ninth rule saves only one bit on average, then adding this ninth rule is not advantageous. The same applies if an added rule requires the use of additional bits to encode dictionary indices.

[0027] It is easy to see that the compression and decompression operations in the SCHC protocol can be lossless; that is, decompressing the data packet header according to the operations defined in the SCHC protocol reconstructs the header exactly as it was before compression. This is the general case, although there may be use cases where this is not the case.

[0028] Compression rule sets are therefore defined in the SCHC protocol for a given, static context and correspond to the expected packet formats in exchanges between senders and receivers. They are defined by an expert who knows that, in a given deployment context, a specific protocol will be used, according to a given encapsulation, and who therefore knows which packet header formats are expected. The expert also knows that a given field in packets conforming to a given format will take a constant value, or a value from a limited set, or a value that will frequently have the same prefix. For example, the expert knows that the IP-Version field that will appear in the headers of packets conforming to several formats (IP alone, or IP encapsulating UDP packets, or other…) will be constant.Alternatively, the expert knows that the IP address values ​​in a given field belong to a limited range and will therefore share a common prefix. This knowledge allows the expert to choose the most appropriate operation for a given field in a given format and incorporate it into the rule. The expert thus constructs a set of rules that will be deployed, for example, attached to compression and decompression modules embedded in a set of connected devices and a corresponding gateway, to implement the SCHC protocol.

[0029] The SCHC protocol was initially designed for LPWANs, but it can be used in other contexts, such as home networks, for compressing Ethernet frame headers, or for mobile telecommunications. In general, the data compression principles described here can be used in any type of packet communication. SCHC compression operations can also be applied to sections of a data packet's payload, not just the header.

[0030] In the current situation, context determination is implicitly based on the type of link used for communication. For example, using the SCHC protocol according to the principles outlined above imposes a static context adapted to the link technology used.

[0031] However, this approach has limitations, particularly in multi-hop communication scenarios where a single connected object may interact with various devices in distinct ways. These multiple and potentially varied interactions may require different contexts, each tailored to a specific communication. In such scenarios, the connected object must simultaneously manage several communication contexts, which complicates the efficient management of interactions and data exchange.

[0032] The known approach is also unsuitable in cases where contexts are dynamic and compression rule sets change over time.

[0033] There is a need for a mechanism capable of facilitating the efficient discrimination of these multiple contexts while minimizing the data exchanges related to context resolution.

[0034] Such a solution would significantly improve the overall performance of communication networks, especially those with low bandwidth. Summary

[0035] This disclosure improves the situation.

[0036] A method is proposed for determining an identifier for a set of data compression rules, a rule comprising at least one target value of at least one data field, said method being implemented by a data processing unit and comprising: applying a transformation to at least one target value selected from among the target values ​​included in the rules of the compression rule set, the identifier determined being the result of said application.

[0037] According to another aspect, a management entity is proposed configured to determine an identifier for a set of data compression rules, a rule comprising at least one target value from at least one data field, the management entity comprising: an application module of a transformation to at least one target value selected from the target values ​​included in the rules of the compression rule set, the determined identifier being the result of said application.

[0038] According to another aspect, a signal transmission method is proposed, the method comprising: obtaining at least one data field, obtaining an identifier from a set of data compression rules comprising at least one rule including at least one target value of the data field, determining a compression residual by applying the set of data compression rules at least to the data field, and transmitting a signal representing at least the identifier and the compression residual.

[0039] In another aspect, a computer program is proposed that includes instructions for implementing all or part of a process as defined herein when executed by a processor. In another aspect, a non-transient, computer-readable recording medium is proposed on which such a program is recorded.

[0040] In another aspect, a mobile terminal is proposed, comprising a management entity as defined herein. In another aspect, a communication device is proposed, comprising a management entity as defined herein.

[0041] The proposed technique allows for the efficient, rapid, and simple determination of an identifier from one or more data compression rules. The speed and simplicity of identifier determination stem from the automation of the transformation process of at least one selected target value, as well as its direct and deterministic nature. This method is designed to empirically minimize the risk of identifier conflicts. This low risk of conflicts improves the reliability and stability of connections. The reduced context management load and optimized data compression enable more efficient use of available bandwidth. The identifier of a set of compression rules determined by the proposed technique can also serve as the identifier for a given context or profile.This context or profile identifier can be used to ensure that participants in a communication session use the same compression rules when sending data and decompression rules when receiving compressed data.

[0042] The proposed technique uses a selected target value to determine the identifier. The selected value is chosen from among the target values ​​present in the data compression rules belonging to the set of compression rules for which the method according to the invention will determine an identifier. The identifier is determined by applying a transformation to the selected target value. The transformation is an operation. Such an operation takes at least one target value as input; and the result of applying the transformation to the target value is the determined identifier. The target value taken as input is, for example, expressed as a sequence of bits, and applying the transformation will produce another sequence of bits, which will be the determined identifier. The target value can be expressed in other formats, for example, as an integer, as can the determined identifier.A transformation applied to a target value (for example, an integer) can result in an identifier expressed in another format (for example, a bit sequence). Examples of possible transformations or operations include permutations, truncations, selections of parts of input values, hashing, arithmetic operations, and conversion from one format to another. The transformation can also be a combination of operations. Further examples of transformations are given below.An example of a transformation might be the following combination of operations: starting with an integer target value, multiply it by a given digit, then calculate the hash of the result using the MD5 hashing operation (or SHA256 or any other hashing operation), then convert the result into a bit sequence, then truncate the resulting bit sequence to its first eight bits, and finally apply a given permutation to this eight-bit sequence to obtain the determined identifier. Any other operation or combination of operations can, of course, be used as a transformation.

[0043] The proposed technique can be implemented independently or in combination with other methods, and can be scaled for use in a variety of communication environments, including multi-hop networks. Designed to integrate with existing data transmission and compression protocols, the proposed technique offers backward compatibility, facilitating its adoption in current telecommunications infrastructures.

[0044] The determination of the identifier can be implemented in a decentralized manner by nodes of a communication network, allowing for context-independent resolution without explicit transmission of rule identifiers between nodes.

[0045] This approach improves the efficiency of communication between devices within the communication system. By reducing the need to transmit metadata—that is, ancillary data created specifically for communication purposes—the proposed technique optimizes the energy consumption of communication devices, thereby extending their lifespan and reducing operational costs. Eliminating the need to transmit identifiers also contributes to reduced latency and increased data transmission speeds.

[0046] These combined technical effects result in increased performance, better quality of service and an improved user experience.

[0047] The features described in the following paragraphs may optionally be implemented independently of each other or in combination with each other.

[0048] In one example, the process involves obtaining the set of data compression rules. The set of data compression rules can be provided to an entity that will determine the identifier; or, the set of compression rules is known to an entity that uses it and will also determine the identifier.

[0049] In one example, the process further includes transmitting the identifier. Transmitting the identifier of a compression rule set allows a receiver capable of interpreting the identifier to use an appropriate decompression rule set to decompress data compressed using that rule set. For example, in an IoT network where sensors send compressed data to a central gateway, transmitting the identifier allows the gateway to correctly interpret and decompress the received data, enabling the subsequent retrieval of the compression rule set used, thus ensuring the integrity of the transmitted information.

[0050] In networking, a plane is an abstract representation of where certain processes take place. The term is used in the sense of a "plane of existence." The two most commonly referenced planes in networks are the control plane and the data plane (also known as the forwarding plane). The control plane is the part of a network that controls how data packets are routed—that is, how data is sent from one location to another. In an example, an identifier is passed to an entity in the control plane.

[0051] In one example, the identifier is: determined by one or more first entities of the control plane and / or data plane, and transmitted to one or more second entities of the control plane and / or data plane, thus enabling these second entities to use the identifier for communications.

[0052] With this embodiment, the generation of compression rule sets can be centralized in a control plane entity, including the generation of identifiers for these sets, and information relating to the identifiers of the compression rule sets can be transferred within the control plane to allow the implementation of multiple compression sets corresponding to the different network contexts managed in the control plane.

[0053] This embodiment also allows for the decentralized generation of compression rule set identifiers. In this case, identifiers are generated by network entities for their own needs, based on the compression rule sets that these network entities use to perform compressions, and the identifiers are then transmitted for use by entities belonging to the same network context, which will receive the compressions performed according to rules from the set thus identified.

[0054] In one example, the process further includes verifying the uniqueness of the identifier within an identifier database. Verifying uniqueness prevents identifier conflicts, thus improving network stability and reliability. For instance, in a multi-hop network, a node might be required to check before transmitting a packet that the context identifier is not already in use within its two-neighborhood, that is, its immediate neighbors and the neighbors of its neighbors. This prevents collisions and ensures that each communication uses a unique identifier.

[0055] In one example, the transformation application includes encoding and / or compression. Encoding and / or compression reduce the identifier size, thus optimizing bandwidth usage and reducing transmission time. It is particularly advantageous in networks with limited bandwidth, such as LPWAN or LoRaWAN networks, to use compressed identifiers to maximize transmission efficiency and send more useful data per packet. In one example, the encoding is achieved using a hash function. A hash function transforms input data into a unique fingerprint. Encoding is often reversible but can be irreversible, while hashing is irreversible.

[0056] In one example, the transformation application includes salting. Salting adds a layer of security by making the identifier harder to predict and reducing the risk of accidental collisions, thus improving the security and reliability of communications.

[0057] In one example, salting is conditional on the non-uniqueness of a previous identifier, determined by a transformation applied to at least one target value and not including the salt. This method allows for the dynamic resolution of identifier conflicts by applying salting only when necessary, thus simplifying the identifier determination process whenever possible.

[0058] In one example, the method further includes selecting a value from among the target values ​​included in the rules of the compression rule set. The target value can be selected during the execution of the method according to the invention or be selected elsewhere and provided to the entity implementing the method.

[0059] In an example, at least one target value is selected based on at least one criterion applied to at least part of the data compression rule set. Such a criterion is a filtering criterion that isolates a specific target value present in a compression rule belonging to the compression rule set. For example, the criterion used might be related to the order of rules within the rule set and the order of values ​​within a rule in the set; the filtering criterion could be, for example, to select the first target value present in the first rule of the compression rule set.

[0060] In one example, at least one criterion takes into account a rule type and / or a data field property. Considering the rule type and / or data field properties allows for the generation of more relevant identifiers tailored to the specific characteristics of the network and applications. For example, at least one criterion can consider data field properties specific to the communication protocol(s) used in a network, thereby improving the performance and reliability of data exchange within the network. An additional advantage is that, since the identifier is derived from the rule set fields, it can serve as a check to determine whether the rule set is stable or has been modified (accidentally or deliberately).When the criterion application is designed to select static elements of the rule set, such as IP addresses, the context identifier remains unchanged even if other elements of the rule set change. However, if the network context changes, the static elements will also change, resulting in a modification of the identifier. This approach is heuristic and not an absolute guarantee.

[0061] In one example, at least one criterion applies to the rules for completely erasing a value. For example, at least one criterion applies only to the rules for completely erasing a value. By determining the identifier only from fields that are actually compressed by complete erasure, we ensure that the identifier remains constant as long as these complete erasure rules do not change, even if other compression rules are modified. This can help ensure the stability of the context identifier.

[0062] In one example, at least one of the selected target values ​​is a network address. Network addresses, such as IPv6 addresses, are typically unique within a given network, and a communication context can often be associated or correlated with at least one source address and / or at least one destination address. Selecting a network address as the target value can help ensure that each context identifier is at least locally distinct and directly related to the network topology and participants.

[0063] Other features, details, and advantages will become apparent upon reading the detailed description below and analyzing the attached drawings, on which: Fig. 1

[0064] shows a communication system comprising a plurality of nodes configured to communicate using a data compression protocol, in an example embodiment. Fig. 2 Fig. 3

[0065] and each demonstrate a header compression rule in an example implementation. Fig. 4 Fig. 5

[0066] and demonstrate two derived rules resulting from a processing of the header compression rule, in an example implementation. Fig. 6

[0067] shows a derived rule resulting from processing the header compression rule, in an example implementation. Fig. 7

[0068] shows a selection of fields from the rules derived from and also an optional additional field.

[0069] In the description that follows, identical reference numbers denote identical elements or elements having similar functions.

[0070] Some terms specific to this patent application are now clarified for a better understanding of the proposed technique.

[0071] The term "field" or the expression "data field" refers to a unit of data identifiable by its structured representation within a signal and used for data processing or transmission. Examples include header fields such as the source address, destination address, type of service, as well as any metadata or specific field in the packet payload.

[0072] The term "field value" refers to the specific data or information contained within a data field. Examples include the source IP address, the destination IP address, or any other value in a header or payload field.

[0073] The term "field property" refers to a characteristic or attribute associated with a data field. Examples include the maximum field length, the data type (text, number, IP address), or the field's default value.

[0074] The term "identifier" refers to a piece of data or a set of data that allows an object or entity to be distinguished within a system. For example, a field identifier allows one field to be distinguished from a set of possible fields. A field identifier is thus an additional example of a property of that field.

[0075] As another example, an identifier for a particular set of data compression rules allows that particular set of data compression rules to be distinguished from several possible sets of data compression rules. When a set of data compression rules is defined for a deployment context, a communication, a communication session, and / or a data stream, then an identifier for that set of data compression rules can be considered equivalent to, or a substitute for, an identifier for that deployment context, communication, communication session, and / or data stream. The term "unique context identifier" can be used to refer to such an identifier for a particular set of data compression rules.Indeed, this identifier also identifies a communication context for which the specific set of compression rules is tailored. In some implementations, particularly when a heuristic approach is applied, identifiers may not be entirely unique across the entire network. Therefore, a unique context identifier should be considered sufficiently distinct to avoid conflicts in a local context, for example, at the two-neighborhood level in a multi-hop network.

[0076] The term "rule type" refers to a category or classification of rules that can be used to define behaviors or actions on at least one field containing at least one field value. Examples include specific compression rules such as "Equal / Not Sent" (if the field value is equal to a predefined value, then that field is not transmitted), "Ignore / Sent" (regardless of the field value, the field is transmitted), or "Ignore / Compute" (regardless of the field value, a calculation operation is performed on its value).

[0077] The term "criteria applied to a data compression rule" refers to a condition or set of conditions applied to the data compression rule to evaluate or select fields, their properties, and / or their values. A criterion can consider the rule type, the fields themselves, their properties, and / or their values. For example, a criterion might specify to select all field values ​​to which a rule of a certain type relates and which have a particular property (for example, a specific field value, or an identifier belonging to a predetermined list of identifiers). Generally, the same criterion can be applied to one, several, or all rules in a set of compression rules. For example, the criterion can be specified to be applied, or applicable, to all rules of one or more particular types within a set of compression rules.

[0078] The term "transformation" refers to an operation or set of operations that changes the form, format, and / or content of data. Examples of transformations include compression and / or hashing operations.

[0079] The term "uniqueness verification" refers to a validation process to ensure that an identifier within a set of data compression rules is unique within the system. The verification might include, for example, comparing the identifier with a list of known identifiers.

[0080] The term "hashing" refers to a mathematical function, such as an MD5, SHA-128, or SHA-256 function, that converts input data into a short string of characters, also called a hash or signature. A desirable characteristic of a hash function is to ensure that two different, even closely related, inputs will produce different outputs, even if the range of possible output values ​​is much smaller than the range of possible input values. A hash function therefore aims to minimize potential output collisions. Hashing is used, for example, for data integrity verification and / or data compression.A hash function can be complemented by a truncation operation to ensure, for example, that the result has a given size, and / or by a punching operation to improve compression efficiency by removing redundant or non-essential data located anywhere within the hash function's output. For example, a cyclic redundancy check uses a hashing procedure.

[0081] The term "salting" refers to the addition or concatenation of data to input data before hashing it. Salting is typically used to enhance the security of communications because it modifies the hash of the input data. In the context of this document, salting can be used to facilitate the resolution of identifier conflicts. Salting is static when the data added to the input data is fixed, and it is dynamic when this added data is generated, for example, randomly.

[0082] The term "data processing unit" refers to a component or set of hardware and / or software components designed to perform processing operations on data, including determining the identifiers of compression rule sets. Examples include a processor, a computer server, or a device embedded in a mobile terminal.

[0083] The term "management entity" refers, in the context of this document, to a component or set of hardware and / or software components responsible for managing a system or service.

[0084] The term "module," in the context of this document, refers to a software or hardware component that performs a specific function within a larger system, such as managing SCHC compression rules. Examples include a compression module, a transmission module, or an identifier management module.

[0085] The term "mobile terminal" refers to a portable device capable of connecting to a communication network to exchange data, using compression rules. Examples include a smartphone, a tablet, a laptop, or any type of connected object or device.

[0086] The term "communication device" refers to a device or set of devices that enables the exchange of data between different systems or users using one or more communication protocols. A communication device may apply data compression and / or decompression rules. Examples include, in addition to the aforementioned mobile terminals and non-mobile terminals, network equipment such as a router, modem, base station of a telecommunications network, or core entity of a telecommunications network.

[0087] The term "processing" refers to all operations performed on data to obtain a desired result, including, for example, compression, decompression, transformation, transmission, storage, analysis, etc.

[0088] The term "transmission" refers to the act or process of sending data from one point to another, with or without data compression rules. Examples include the transmission of compressed data packets or the transmission of messages with compressed headers.

[0089] This disclosure relates to a technique for efficiently and reliably determining an identifier for a set of data compression rules.

[0090] Reference is now made to the diagram, which represents a possible example of a communication system suitable for implementing the proposed technique. The communication system comprises a plurality of nodes 1, 2, 3, 4, 5, each node being a communication device. The architecture represented in the diagram could, for example, correspond to a multi-hop architecture, that is, a communication system whose nodes are configured to be used by other nodes as communication relays according to the principle of multi-hop routing.

[0091] Any suitable hardware and / or software may be used for the practical implementation of said communication system and / or communication devices. Generally, although aspects of the proposed technique may be described in this document as a process, device, system, procedure, method, or technique, it should be noted that the proposed technique may also encompass computer memory that can be connected to a processor, which may be connected to a communication interface. This memory stores instructions that, when executed by such a processor, enable the implementation of the processes, devices, systems, procedures, methods, or techniques described in this document. These means include those offered by cloud architectures, etc.

[0092] The nodes are configured to communicate with each other using a data compression protocol; that is, each communication between nodes uses a set of data compression rules, or deployment context.

[0093] In the example of the, five deployment contexts are represented: a first context 11 is associated with communication between a first node 1 and a second node 2, a second context 12 is associated with communication between the first node 1 and a third node 3, a third context 13 is associated with communication between the second node 2 and the third node 3, a fourth context 14 is associated with communication between the third node 3 and a fourth node 4, and a fifth context 15 is associated with communication between the fourth node 4 and a fifth node 5.

[0094] In the example presented, for the sake of simplicity, contexts correspond only to point-to-point communications between two distinct communication devices. This characteristic is not mandatory: a context can apply to communications between more than two communication devices. For example, a context can correspond to a wireless local area network (WLAN), and all devices connected to this WLAN can share the same set of compression rules capable of efficiently compressing messages exchanged on the LAN. The technique presented also applies without modification to multicast contexts. For example, in a multimedia content delivery network, a streaming server can broadcast videos to multiple receivers simultaneously. All receivers sharing this stream can use the same compression context to receive the data efficiently.It is also possible to have multiple distinct streams between the same communication devices, each with its own set of compression rules. For example, in a context where a communication device simultaneously sends different types of data streams (such as streaming video and text messages), each stream type can have a set of compression rules tailored to its specific characteristics. This allows for optimized compression for each data type, thus improving overall network performance. Furthermore, in an IoT (Internet of Things) network, a sensor can send data to multiple data collection devices. The same compression framework can be applied to communications between the sensor and each data collection device, ensuring efficient data transmission.For example, temperature sensors in a factory can send their readings to different control and monitoring systems, all sharing the same set of compression rules for the exchanged messages. Thus, the flexibility of the technique allows its application in various communication scenarios, whether unicast or multicast, and for data streams of different types between the same devices.

[0095] In the implementation example, one possible objective is to ensure that the contexts associated with communication involving the same node (e.g., the first node 1) are distinct. In other words, according to this objective, it is desirable for each node to use a distinct set of compression rules to communicate with every other node.

[0096] Indeed, when communication contexts used simultaneously by the same node are not distinct, decompression errors can occur. For example, if the first node (1) uses the same set of compression rules to communicate with the second node (2) and the third node (3), the compression rule identifiers can become ambiguous, leading to errors during packet decompression. This can cause data loss or misinterpretation of received packets, thus affecting the reliability and robustness of communications.

[0097] Thus, in the example considered, it is desirable that: the first context be distinct from the second context and the third context, the second, third and fourth contexts be distinct, and the fourth context be distinct from the fifth context.

[0098] However, there is no problem with the first context being identical to the fourth context, nor with the second or third context being identical to the fifth context, provided that these contexts are not simultaneously active for the same node. More specifically, the context identifiers can be identical between the first and fourth contexts, as well as between the identifiers of the second or third contexts and that of the fifth context.

[0099] Generally speaking, as long as the nodes involved do not need to manage multiple contexts simultaneously for different communications, using shared compression rule sets, or those sharing the same identifier, does not pose a problem. This situation typically occurs in networks where communications are sufficiently spaced out over time or managed by efficient scheduling mechanisms that avoid conflicts.

[0100] One aspect of the proposed technique relates to a method for determining an identifier for a set of data compression rules (or equivalently, a deployment context identifier, which may be called a unique context identifier) ​​applicable to any communications network. The method according to the proposed technique is implemented by a data processing unit.

[0101] It includes, at least one retrieval of at least one rule from the data compression rule set, said at least one rule being relative to at least one field comprising at least one field value.

[0102] It further includes determining the identifier by applying a transformation to at least one field value selected according to at least one criterion applied to said at least one data compression rule.

[0103] This technique aims to optimize compression context management by ensuring the uniqueness of identifiers, thereby minimizing the risk of conflicts and decompression errors. Context identifier uniqueness is targeted within a local (two-neighborhood) context. The objective is to guarantee that each context identifier is unique within its own immediate neighborhood, that is, the devices with which it communicates directly and those with which they communicate. It is designed to be effective in various types of networks using diverse architectures and communication protocols, including low-power wide-area networks (LPWANs) and multi-hop communications.

[0104] This technique minimizes identifier conflicts and decompression errors by using unique identifiers. For example, in a multi-hop network, each node must ensure that its two neighbors—that is, its neighbors and the neighbors of its neighbors—do not use the same context identifier. Identifier management can then be viewed as a graph coloring problem, where each edge of the graph represents a communication between two nodes, and each color represents a distinct identifier. In this context, a graph represents the neighborhood connections between devices. This context neighborhood graph is not necessarily identical to the graph of point-to-point communications. By applying concepts from graph theory, it is possible to ensure that communications involving the same node do not use conflicting context identifiers, thus improving communication reliability.

[0105] Furthermore, graph theory makes it possible to limit the total number of identifiers needed to avoid identifier conflicts, thus reducing the number of bits required to encode them. This reduced footprint is particularly advantageous in networks such as LPWANs where bandwidth and energy resources are limited.

[0106] This technique enables decentralized identifier management, facilitating network scalability and reducing management complexity. Each node can independently determine the appropriate context identifiers based on data compression rules, without requiring central coordination. This decentralization reduces the complexity and costs associated with centralized context management and allows for easier network scaling, which is particularly beneficial in environments where connected objects must interact with various devices separately and often simultaneously.

[0107] Conversely, this technique also allows for more centralized management of identifiers. In a centralized model, a central entity is responsible for determining contexts, calculating the corresponding identifiers, and transmitting them to the communication devices. This approach can be particularly useful in networks where strict coordination is necessary to ensure optimal performance and avoid identifier conflicts. In a centralized network, a control plane management entity, such as a network management system (NMS) or a software-defined networking (SDN) controller, can be responsible for determining contexts and generating identifiers.This centralized entity collects the necessary information from the communication devices, calculates the appropriate identifiers according to the compression rules, and then distributes them to the relevant devices.

[0108] Compression rule sets can be obtained in several ways. Using a traffic observation learning method, network traffic is analyzed to identify patterns and characteristics of the exchanged data. Machine learning algorithms can be used to observe the traffic, identify regularities, and optimize compression rules accordingly. For example, by observing video streams, rules specific to compressing video packet headers can be created. Alternatively, compression rules can be defined manually by network administrators or telecommunications experts. They use their knowledge of protocols and the types of data exchanged to create rule sets optimized for specific contexts. For example, specific rules can be defined to compress IP headers in a sensor network.Alternatively, standardized compression rule sets defined by standards bodies such as the IETF, for example in RFCs, can be adopted and implemented in communication devices. Optionally, compression rules can be dynamically adjusted based on real-time network conditions. For example, in a network where available bandwidth varies, compression rules can be adjusted to maximize transmission efficiency based on the current network capacity.

[0109] In one example implementation, obtaining a context identifier is done in several steps.

[0110] A management entity collects information about the network and communication devices, this information may include, for example, IP addresses, types of data exchanged, protocols used, and other relevant parameters.

[0111] Compression rule sets are defined according to one or more of the methods described above.

[0112] Relevant target values ​​for the data fields are selected based on the defined compression rules. This selection may include static properties such as IP addresses, protocol versions, etc. This selection is performed by applying one or more filtering criteria. It is desirable that these filtering criteria be carefully designed to ensure that the target values ​​are relevant and discriminating.

[0113] A transformation, such as hashing, is then applied to the selected target values. This transformation produces a unique bit sequence that serves as a context identifier. The resulting context identifier can be verified for uniqueness within the local or global context, as needed. The identifier can then be transmitted, for example, to a control plane entity and / or distributed to the relevant communication devices. Finally, the identifier can be used by the communication devices to configure their compression and decompression rules.

[0114] The proposed technique integrates easily into existing infrastructures, offering a practical and efficient solution for various communication environments, including LPWANs and multi-hop communications. Leveraging well-established concepts from graph theory and data compression methods, this approach seamlessly improves the management of communication contexts. It is compatible with current data transformation protocols, facilitating its adoption in both current and future telecommunications infrastructures.

[0115] Reference is now made to Figures 2 and 3, which illustrate two examples of data compression rules 21 and 22 according to the SCHC protocol. The principles presented in this example are not limited to the SCHC protocol alone. A rule comprises a rule identifier (RuleID) and several field descriptors.

[0116] Each field descriptor includes the following elements: a field identifier (FID) of the field in question (SCHC does not process the header globally, but field by field), for example, the IPv6 source address; a length (FL) in number of bits of the field; a position (FP) of the field in the packet header; a direction indicator (DI) indicating the packet direction to which this description applies, with three possible values: Up (Uplink), Dw (Downlink), or Bi (Uplink and Downlink); the target value (TV), which is a reference value against which the field value is compared; a matching operator (MO), for example, complete equality ("Equal") or equality of only the N most significant bits; and a compression / decompression action (CDA), which indicates what to do if the field content matches the target value: for example,do not transmit the field ("Not-Sent" in English, if its value is a known value), or (for the decompressor) recalculate its value ("Compute" in English) from the data.

[0117] This definition of field descriptors, including additional details such as the exhaustive list of possible compression and decompression actions, is detailed by the IETF in RFC document number 8724.

[0118] The example rules provided in Figures 2 and 3 are simplified in that they include a limited number of field descriptors. More generally, rules can include descriptors of all fields that might be contained in a packet before data compression, including, for example, fields related to the IP protocol, fields related to the UDP protocol, and fields related to the CoAP protocol.

[0119] When a data compression rule, as defined by the SCHC protocol in accordance with RFC 8724, is applied by a data compression module to a packet containing a header composed of several fields, each header field is processed individually according to the field descriptors included in the rule.

[0120] Each field in the packet header is identified by its field identifier (FID). The field value is compared to the target value (TV) defined in the field descriptor using the comparison operator (MO). If the field value matches the target value according to the comparison operator, the compression action (CDA) is applied. For example, if the action is "Not-Sent," the field is not transmitted. If the action is "Compute," the field is recalculated upon reception. If the value does not match, the field is included in the compression residual.

[0121] The concept of compression residue refers to the portion of the header that has not been compressed and must be transmitted with the packet. Compression residue may be empty if all field values ​​have been compressed according to the applied compression rules.

[0122] If a field value is not compressed because it does not match the target value, this value is included in the compression residue. This allows a decompression module receiving the compressed header packet to reconstruct the header of the original packet using the uncompressed field values ​​passed in the compression residue.

[0123] The structure of a data packet whose header has been compressed by applying a rule according to RFC 8724 comprises three main elements: the RuleID of the applied compression rule, this identifier enabling the decompression module to select the appropriate rule to decompress the packet; the compression residue, which contains the values ​​of the header fields that were not compressed, either because they did not match the target values, or because the applicable compression rule specified that they should be transmitted as is; and the payload, i.e. the part of the packet containing data unaffected by the header compression process.

[0124] It is therefore clear that each packet exchanged between nodes in a multi-hop scenario must include a Rule ID for each compression rule applied. This means that if a packet is to be processed by multiple compression rules, each corresponding Rule ID must be included in the packet header. This increases the header size and, consequently, the transmission overhead, thus reducing the overall communication efficiency.

[0125] For example, consider the system where nodes 1, 2, 3, 4, and 5 are connected in pairs, in a multi-hop scenario. In communication between nodes, including in each packet the rule identifiers necessary for header compression at each hop leads to information duplication and significant overhead.

[0126] In the same multi-hop scenario, with the proposed technique, each packet exchanged between nodes would include only a single context identifier to identify the set of applicable compression rules. This significantly reduces the header size and therefore the transmission overhead, thus improving overall communication efficiency. Furthermore, for application to this multi-hop scenario, it is desirable that the context identifier be calculated in such a way that it is unique across the two neighbors of each node.

[0127] The proposed technique presents, in one aspect, a deterministic selection module for one or more target values ​​that can be used to determine the context identifier using the field descriptors of the compression rules. This selection ensures that the context identifier can be reproduced identically at each end of the communication.

[0128] An illustrative example of a heuristic selection module suitable for implementing such a selection is now presented, continuing the example of the two rules 21, 22 illustrated in figures 2 and 3. For this purpose, reference is now made to figures 4 to 7.

[0129] Initially, the rules are processed in such a way as to separate the field descriptors applicable to uplink traffic from those applicable to downlink traffic.

[0130] The field descriptors of the first rule 21 are thus split into: a first set 31 of field descriptors applicable to downlink traffic, and a second set 32 ​​of field descriptors applicable to uplink traffic.

[0131] This splitting is done according to the value of the direction indicator of each field descriptor: the value 'Dw' indicates that the field descriptor is applicable to downlink traffic and is therefore only counted in the first set 31, the value 'Up' indicates that the field descriptor is applicable to uplink traffic and is therefore only counted in the second set 32, and the value 'Bi' indicates that the field descriptor is applicable to both uplink and downlink traffic and is therefore counted in both the first and second sets 32.

[0132] A third set 33 of field descriptors, applicable to uplink traffic, is formed from the field descriptors of the second rule 22, these all having the same direction indicator value ('Up').

[0133] The first set 31 comprises five field descriptors and the second set 32 ​​and the third set 33 each comprise six field descriptors.

[0134] In a second step, the sets of field descriptors thus obtained are filtered according to at least one criterion.

[0135] In the example considered, two criteria are applied successively.

[0136] A first criterion is applied: on the one hand to the first set 31 as the only set applicable to downlink traffic, and on the other hand jointly to the second set 32 ​​and the third set 33 as sets of the same type, in this case both applicable to uplink traffic.

[0137] Specifically, this involves retaining only field descriptors specifying: a complete equality comparison operator "Equal", a compression action "Not-Sent" indicating that the field is not transmitted, and an identical target value within each set of the same type, and excluding other field descriptors.

[0138] Applying the first criterion to the first set 31 results in: the retention of four field descriptors whose identifiers are "IPv6:SourceAddress", "IPv6:DestinationAddress", "CoAP:Version" and "CoAP:Type", as well as the exclusion of the field descriptor whose identifier is "CoAP:MessageID" because neither the comparison operator nor the compression action provided for in this field descriptor fulfills the first criterion.

[0139] Applying the first criterion to the second and third sets 32, 33 results in: the retention of four field descriptors whose identifiers are "IPv6:SourceAddress", "IPv6:DestinationAddress", "CoAP:Version" and "CoAP:PayloadMarker", as well as the exclusion of the field descriptor whose identifier is "CoAP:MessageID" because neither the comparison operator nor the compression action provided for in this field descriptor fulfills the first criterion, and the exclusion of the field descriptor whose identifier is "CoAP:Type" because the target value "0b01" specified for this field descriptor within the second set 32 ​​is different from that "0b00" specified for this field descriptor within the third set 33, thus this field descriptor does not fulfill the first criterion.

[0140] A second criterion is applied: it is a matter of keeping, among the field descriptors already filtered by application of the first criterion, only those kept for both uplink traffic management and downlink traffic management.

[0141] Applying the second criterion results in: the retention of three field descriptors whose identifiers are "IPv6:SourceAddress", "IPv6:DestinationAddress", "CoAP:Version" (because they are present, after filtering, in both the first set and the second and / or third set), and the exclusion of field descriptors whose identifiers are "CoAP:Type" (because they are absent from the second and third sets after filtering) and "CoAP:PayloadMarker" (because they are absent from the first set after filtering).

[0142] Thirdly, a target value is selected for each field descriptor retained after filtering.

[0143] Field descriptors with identifiers "IPv6:SourceAddress" and "IPv6:DestinationAddress" have a different target value depending on the traffic direction considered.

[0144] When the heuristic is implemented by an issuer, the relevant traffic direction is the uplink direction and it is therefore chosen to select, for these field descriptors, the target value corresponding to uplink traffic.

[0145] Three target values ​​are thus selected: for the identifier "IPv6:SourceAddress", the selected target value is "[20010db8::04]", for the identifier "IPv6:DestinationAddress", the selected target value is "[20010db8::03]", and for the identifier "CoAP:Version", the selected target value is "0b01".

[0146] Fourthly, the context identifier is determined from, at least, the selected target values.

[0147] The illustrative heuristic example thus detailed uses filtering criteria designed to select relevant target field values ​​that are discriminating from the deployment context without any prior assumptions about the number and nature of the data fields or the compression rules used for data compression.

[0148] Thus, these filtering criteria are designed to be relevant for a large number of applications using the SCHC protocol, particularly in LPWANs networks and / or in multi-hop communication scenarios, but also in LoRaWANs networks, in MPLS networks, in communications using a TLV coding scheme, etc.

[0149] More generally, regardless of the data compression protocol used (i.e., for an SCHC protocol or another protocol), it is often relevant to apply similar filtering criteria in order to select the most discriminating and representative target values ​​of the network configuration and thus ensure the uniqueness of context identifiers.

[0150] The advantage of this heuristic lies in its ability to select the most relevant target values ​​to ensure the uniqueness and representativeness of context identifiers. By filtering field descriptors according to strict criteria, the heuristic ensures that the generated identifiers are both discriminating and adapted to the specific characteristics of the network. This enables efficient and reliable context management, reducing the risk of conflicts and improving overall network performance. The heuristic can be applied to compression rules using different criteria, such as MSB (Most Significant Bit) and LSB (Least Significant Bit). For example, for rules where target values ​​are defined in terms of most or least significant bits, similar filtering criteria can be used to select the most representative target values.

[0151] For example, it is advisable to keep only target values ​​of fields whose descriptors specify strict comparison operators (ensuring that only identical values ​​are retained, which reinforces the discriminatory nature of the filtering criterion) and deterministic compression (or conversely non-compression) actions (so as to leave no ambiguity on how the fields are treated and thus again reinforce the discriminatory nature of the filtering criterion).

[0152] Selecting field values ​​that are static within a given network context, such as IP addresses or protocol versions, helps ensure the stability of the context identifier. Prioritizing field values ​​that appear frequently in network traffic ensures that the context identifier is relevant for the majority of communications.

[0153] For example, when the same set of data compression rules is used to manage multiple types of traffic (e.g., regarding traffic direction: uplink, downlink, or bidirectional), it is relevant to retain only target field values ​​whose descriptors are common to all traffic types. Traffic direction can be accounted for by inverting certain values. For instance, to ensure that the selected target values ​​are relevant for all traffic types, it is useful to compare a source address of a downlink communication with a destination address of an uplink communication, and vice versa.

[0154] However, the proposed technique cannot be limited to the application of one or more specific criteria. Depending on the intended application, other criteria could be applied.

[0155] For example, the choice of one or more criteria to apply for selecting one or more target values ​​can be made expertly, based on prior assumptions about the data fields and / or compression rules used. For example, in an IoT network where source and destination IP addresses are fixed for a certain type of communication, the selection module can be configured to prioritize the selection of these values.

[0156] Furthermore, the proposed technique cannot be limited to applying the criterion or criteria to the entire set of data compression rules to be identified. Alternatively, it is possible to apply the criterion or criteria only to a portion of the set of data compression rules, that is, only to certain rules within the set, or only to certain field descriptors contained in one or more rules within the set.

[0157] More generally, it may be planned to apply any field descriptor filtering criterion or any combination and / or sequence of field descriptor filtering criteria to all or part of the data compression rule set.

[0158] The proposed technique can also be applied to any type of communication network based on any type of transmission technology, and to any data compression protocol using any number of rules governing traffic of one or more types.

[0159] The determination of the context identifier from the selected target values ​​is now detailed.

[0160] Lare represents a table 41 including the target values ​​selected according to the illustrative heuristic example and the identifiers of the corresponding fields, as well as an additional value "0xbeef" called salting value or salt, usable for static salting.

[0161] The selected target values ​​(and, optionally, the additional value) are provided as input to a transformation module.

[0162] The main function of the transformation module is to deterministically determine a bit sequence shorter than the sum of the lengths of the input data, while preserving their distinctiveness. The resulting bit sequence can then be used as a "unique" context identifier for the selected target values.

[0163] The transformation module includes, for example, a concatenation module and a hashing module.

[0164] The concatenation module is configured to concatenate all or part of the input data. For example, the concatenation module can be configured to concatenate only the selected target values, or to concatenate the selected target values ​​and the additional value, or to concatenate the selected target values ​​and multiple repetitions of the additional value. Alternatively, the concatenation module can be replaced by a block coding module.

[0165] The hashing module is configured to determine a hash result from the data provided to it as input. When the hashing module receives as input the result of concatenating the selected target values ​​and the additional value, the hash result inherently includes static salting. Alternatively, the hashing module can, for example, be replaced by a compression module applying an algorithm such as Huffman, LZW, etc.

[0166] The result of the hashing or compression can be used directly as a context identifier.

[0167] The result of chopping or compressing can also be truncated and / or punched to achieve a smaller size, for example a predetermined desired size.

[0168] As an illustration, an example of calculating a context identifier is detailed based on the field values ​​as indicated. In this example, the selected field values, namely "20010db8::04", "20010db8::03", and "0b01", are simply concatenated, resulting in the following string: "20010db8::0420010db8::030b01". This string is then fed into an MD5 hashing algorithm. An MD5 hash provides a deterministic result in the form of a 32-character hexadecimal string. In this example, the result is "816607ec52d01dd4d40efac57e7ab7e6". This result can be truncated or subjected to any processing that reduces its size while retaining a property of local uniqueness at the scale of a two-neighborhood.For example, it might be possible to retain only the last four bits of the ASCII encoding of the first character in the MD5 hash result as the result of transforming the selected field values ​​and use this result as the context identifier. For example, the character "8" is represented in ASCII code by the 7-bit sequence "111000", of which the last four bits "1000" can be used as the context identifier.

[0169] Those skilled in the art will readily understand that the transformation module may include additional modules responsible for performing further transformations before or after encoding and before or after compression. For example, the transformation module may include an encryption module and / or a permutation module.

[0170] The transformation module may also include decision modules, for example a module responsible for choosing whether or not to concatenate the selected target values ​​with the additional value and for driving the concatenation module accordingly.

[0171] Such a decision module can, for example, be coupled with an identifier negotiation module.

[0172] Another aspect of the proposed technique relates to a signal transmission method.

[0173] The method includes: obtaining at least one data field, obtaining an identifier from a set of data compression rules comprising at least one rule comprising at least one target value of the data field, determining a compression residual by applying the set of data compression rules to at least the data field, and transmitting a signal representing at least the identifier and the compression residual.

[0174] As described herein, the data field cannot be limited to a header field but can refer to any structured representation of any type of data(s).

[0175] The identifier of the data compression rule set can be determined deterministically at the level of a management entity comprising: a module for obtaining the data compression rule set, and a module for determining the identifier by applying a transformation to at least one target value selected according to at least one criterion applied to at least a part of the data compression rule set. The identifier determination module may include, for example, a selection module and a transformation module as described herein.

[0176] The management entity can be located at any communication device (terminal or network management equipment), whether or not it acts as a sender and / or receiver. The management entity can also be distributed across multiple communication devices, for example, within a cloud architecture.

[0177] The "signal representing at least the identifier and the compression residue" can take various forms. It can contain the context identifier and the compression residue as separate field values. Alternatively, the signal can contain the result of a transformation of the identifier and / or the compression residue, such as concatenation or compression of both. This transformation can include techniques such as salting, hashing, or any other method relevant to optimizing transmission. Furthermore, within a data compression protocol such as SCHC, the signal can include compressed representations of the identifier and the compression residue according to the protocol's own compression rules, thus enabling efficient transmission that conforms to the protocol's specifications.In summary, the signal can be configured to maximize transmission efficiency and robustness by adapting the shape of the transmitted data according to the specific needs of the network and applications.

[0178] By using filtering criteria to select the most discriminating target values, the presented signal transmission method ensures the uniqueness and relevance of context identifiers, thereby reducing the risk of identifier collisions and improving network reliability. It is applicable to various types of networks and compression protocols, making it an adaptable and robust solution for managing data compression.

[0179] In one embodiment, a first management entity determines the context identifier. This entity includes a module for obtaining the set of data compression rules, a selection module that applies filtering criteria to field descriptors to select relevant target values, and a transformation module that uses the selected target values ​​to generate a unique context identifier.

[0180] A transmitter then implements the process by obtaining at least one data field and the set of compression rules, applying the compression rules to determine the compression residual, and transmitting a signal including the context identifier and the compression residual.

[0181] A second management entity, similar to the first, also determines the context identifier for a receiver, thus ensuring the consistency of context identifiers. The receiver receives this signal, uses the context identifier to select the appropriate decompression rule set, and reconstructs the original data from the compression residue.

[0182] An identifier negotiation mechanism can be provided to avoid context identifier conflicts that might still occur.

[0183] When a node (e.g., node 2) detects that the context identifier used to communicate with a neighboring node (e.g., node 1) is identical to that used for another neighbor (e.g., node 3), a conflict is reported.

[0184] To resolve the conflict, a salt value, as described herein, can be applied. If a conflict persists after the first salt application, a new salt value is applied. This process is repeated until no conflict is detected in the two-neighborhood of the nodes involved.

[0185] Specifically, when a conflict is detected, the affected node sends a conflict signal to its neighbors, including the conflicting context identifier. One or more of the relevant management entities determines a new identifier by applying a new salting value and sends this information to the affected nodes. The nodes then verify that the new context identifier, after salting, does not generate new conflicts. If conflicts persist, the process is repeated. If all nodes accept, the new identifier is validated. This negotiation process ensures that context identifiers are unique across the two-neighborhood, thus preventing collisions and improving the reliability of communications in complex networks.

[0186] The salting value can be deployed in several ways.

[0187] It can be provided directly to management entities using an ad hoc interface, or made accessible as a static value stored in a database, or incorporated into the data compression rule set using phantom field descriptors, designed never to be interpreted in compression operations, and specifying the salting value as the target value.

[0188] These technical solutions can be applied in various industrial and technological sectors requiring efficient and reliable communications, such as the Internet of Things (IoT), sensor networks, telecommunications, and network management systems. They are particularly well-suited for bandwidth-constrained environments, multi-hop networks, and scenarios requiring low power consumption, while also offering robust solutions for context identifier management and data compression.

[0189] This disclosure is not limited to the examples described above, which are merely examples, but encompasses all the variations that a person skilled in the art may consider in the context of the protection sought.

Claims

Method for determining an identifier of a set of data compression rules, a rule comprising at least one target value of at least one data field, said method being implemented by a data processing unit and comprising: applying a transformation to at least one target value selected from the target values ​​included in the rules of the compression rule set, the determined identifier being the result of said application. A method according to claim 1 comprising obtaining the set of data compression rules. A method according to claim 1 or 2, further comprising a transmission of the identifier. A method according to any one of claims 1 to 3, further comprising a verification of the uniqueness of the identifier within an identifier database. A method according to any one of claims 1 to 4, wherein the application of the transformation includes encoding and / or compression. A process according to any one of claims 1 to 5, wherein the application of the transformation includes salting. A method according to claim 6, wherein the salting is conditioned on a non-uniqueness of a previous identifier previously determined by a transformation applied to at least one target value. A method according to any one of claims 1 to 7, further comprising a selection of a value from among the target values ​​included in the rules of the compression rule set. A method according to any one of claims 1 to 8, wherein at least one target value is selected according to at least one criterion applied to at least a part of the data compression rule set. A method according to claim 9, wherein at least one criterion takes into account a type of rule. A method according to claim 10 wherein at least one criterion applies to the rules for the complete erasure of a value. A method according to any one of claims 9 to 11, wherein at least one criterion takes into account a property of the data field. A method according to claim 12 wherein at least one selected target value is a network address. A management entity configured to determine an identifier from a set of data compression rules, a rule comprising at least one target value from at least one data field, the management entity comprising: an application module of a transformation to at least one target value selected from the target values ​​included in the rules of the compression rule set, the determined identifier being the result of said application. Mobile terminal comprising a management entity according to claim 14. Communication device comprising a management entity according to claim 14.

Images