Method for determining identifier and management entity

Abstract

A method for determining an identifier for a set of data compression rules, a rule comprising at least one target value for at least one data field, said method being implemented by a data processing unit and comprising: obtaining the set of data compression rules, and 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 set of data compression rules. Abstract figure: Figure 1

Description

Title of the invention: Method for determining identifier and management entity. Technical field

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

[0002] It relates more specifically to a method 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 (acronym for Internet Protocol). A set of data packets relating to a communication is sent by the sender to a receiver. The packets contain the receiver's address so that they 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 constituting digital data, to the interpretation of data for computer applications. Bits are typically grouped into bytes, sets of eight bits.The various protocols are classically 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 the articulation 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) 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 the establishment of the connection or the order of arrival of the data packets forming a transmission, these considerations being . managed by the protocol of the upper Transport layer. The IP protocol uses a protocol of the Link layer, for example the Ethernet protocol which organizes the sending of the elementary data constituting the packet, this elementary data being bits, transmitted using the Physical layer, whether using a transmission by optical fiber, or by wireless communication depending on the case.

[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 transported within the packet itself. 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 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 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, and 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. We Recall 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 prior art and will not be described further. Previous technique

[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, on the one hand, of a header containing the information necessary for the transmission of the packet and, on the other hand, of 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 the data packets by focusing solely on compressing the values ​​of the fields in the data packet headers.

[0012] A first example of a protocol compressing the values ​​of data packet header fields is the ROHC (Robust Header Compression) protocol, defined by the IETF (Internet Engineering Task Force) standards body in RFC (Request For Comments, the Internet's foundational specification document) number 3095. The basic idea of ​​this protocol is that certain header field values ​​within the same communication will not change from one communication to the next. For example, the source and destination address field values ​​will remain the same during a communication. After the first packet containing the values ​​of these fields is sent, these values ​​are erased from the headers of subsequent packets to compress the packet header, and therefore the packet itself, and are inserted upon reception since they are known after the first packet has been sent.The erasure is performed by a compression module and the 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 if the compression is limited to the headers. The ROHC protocol is used, for example, in mobile telecommunications networks. But it requires that it be built for Each communication has a context indicating 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 will be preferred in certain usage contexts.

[0014] The context of communication networks dedicated to connected objects imposes additional constraints. This refers to low-power wide area networks, also known as LPWANs. In such a network, connected objects 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 result in high bandwidth consumption, making the ROHC header compression protocol unsuitable in this context.

[0015] Furthermore, the data exchanged by these objects is often very small and may be limited to indicating that the object is still active, or the object may want to report a single value, such as a temperature for a thermometer or a water level 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 compression of the data packets, which, in the context of LPWANs, will focus on compressing the values ​​of 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, for example a type of connected object deployed in a given network, compression rules will be defined. These rules group together operations that can be applied to the values ​​of the fields in the packet headers. These operations can be of three types, all based on the idea that the values ​​of certain fields, or part of the values, can be erased before transmission and then reconstructed upon reception: • A 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 in the connected device. The erased value is inserted at the receiving end 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 IP packet version field. If the field takes a value other than expected, the operation does not apply, the compression rule is ignored, and another rule may be used, or the value of the field 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 can be passed unchanged if no rule applies. • A third type of operation involves prefix removal: the field value is a sequence of bits, and a prefix of varying length can be defined during a compression operation. If the value does indeed have this prefix, the prefix is ​​removed during compression and inserted during decompression; otherwise, 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 transmitting 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 will then be 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 to 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 this end, each compression rule in the set is defined for a given 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 the 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 the 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 seek 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 forwarding it to a decompression module. The 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 set of rules to select one or more. 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 in the set 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 compressing the values ​​of the header fields is still effective, because the size of the headers is proportionally large.

[0024] Here we see the advantage of the operation which consists of ignoring the value of the field and transmitting it as is. This operation ensures that a rule can effectively be applied to all fields of a given header: for fields that are easy to compress, an efficient compression operation will be defined, and for the other fields, the operation which does nothing will serve as completion.

[0025] Finally, several rules can be selected for which the format of the fields, on the one hand, and the field values, on the other, correspond. One rule is then chosen, and only one, for example, the first one encountered in the rule set, or chosen randomly, according to the implementation of the SCHC protocol. The operations defined in the rule are applied by the compression module to the values ​​of the header fields of the packet. Then the packet is transmitted with its header values ​​compressed, as well as with the identifier of the rule that was applied. The decompression module receives the packet whose header values ​​have been compressed; uses the rule identifier to find the operations that were applied; and applies the symmetric decompression operations.For example, if the compression operation used a dictionary for a field value, the decompression module will use the passed index value to replace it with the value expected from the dictionary.

[0026] Since the identifier of the rule used for compression must be transmitted, as well as certain values ​​(dictionary indexes), there will be a limit beyond which adding new compression rules in a given context will no longer be worthwhile because the potential gain provided by the additional rule is outweighed by the transmission cost induced by the increase in the size of the identifier. The rule is updated 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, adding this ninth rule is not worthwhile. The same applies if adding a rule requires using additional bits to encode dictionary indexes.

[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 provided for 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 could 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 could be used in any type of packet communication. The compression operations of the SCHC protocol could also be applied to sections of a data packet's payload and not just to the header.

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

[0031] However, this approach has limitations, particularly in multi-hop communication scenarios where the same connected object may interact with various devices in distinct ways. These multiple and potentially varied interactions may require different contexts, each adapted 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 exchanges.

[0032] The known approach is also unsuitable in the case where the contexts are dynamic and the sets of compression rules change over time.

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

[0034] Such a solution would significantly improve the overall performance of communication networks, particularly 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 for at least one data field, said method being implemented by a data processing unit and comprising: obtaining the set of data compression rules, and determining the identifier by applying a transformation to at least one target value selected according to at least one criterion applied to at least one part of the set of data compression rules.

[0037] According to another aspect, a management entity is proposed that is configured to determine an identifier for a set of data compression rules, a rule comprising at least one target value for at least one data field, the management entity comprising: a module for obtaining the set of data compression rules, 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 one part of the set of data compression rules.

[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, a determination of a compression residual by applying the set of data compression rules at least to the data field, and a transmission of a signal representing at least the identifier and the compression residue.

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

[0040] According to another aspect, a mobile terminal is proposed comprising a management entity as defined herein. According to 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 result from the automation of the transformation process of at least one selected target value, as well as from its direct and deterministic nature. This method of obtaining the identifier is designed to empirically minimize the risk of identifier conflicts. This low risk of conflicts improves the reliability and stability of connections. The reduction in context management overhead and the optimization of data compression allow for more efficient use of available bandwidth.

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

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

[0044] This approach improves the efficiency of communications between devices in the communication system. By reducing the need for metadata transmission, i.e., ancillary data created for communication purposes, the proposed technique optimizes the energy consumption of the devices. communication, thus extending their lifespan and reducing operational costs. Eliminating the need to transmit identifiers also contributes to reduced latency and increased data transmission speeds.

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

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

[0047] In one example, the method 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 the compression rule set. For example, in a 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, making it possible to subsequently retrieve the compression rule set used, thus ensuring the integrity of the transmitted information.

[0048] In the field of networking, a plane is an abstract design 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 transfer 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 place to another. In one example, the identifier is passed to an entity in the control plane.

[0049] In one example, the identifier is: determined by one or more primary entities of the control plane and / or data plane, and transmitted to one or more secondary entities in the control plane and / or data plane, thus allowing these second entities to use the identifier for communications.

[0050] Thanks to 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 sets compression corresponding to the different network contexts managed in the control plane.

[0051] This embodiment also allows for the decentralized generation of identifiers for compression rule sets. In this case, the 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 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.

[0052] In one example, the method further includes checking the uniqueness of the identifier within an identifier database. Checking the uniqueness of the identifier prevents identifier conflicts, thereby improving network stability and reliability. For example, in a multi-hop network, a node may 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 neighborhood and the neighbors of its neighbors. This prevents collisions and ensures that each communication uses a unique identifier.

[0053] In one example, the transformation applied to determine the identifier includes encoding and / or compression. Encoding and / or compression reduce the size of the identifier, thereby 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 obtained by a hash function. A hash function transforms input data into a unique fingerprint. Encoding is often reversible but can be irreversible, whereas hashing is irreversible.

[0054] In one example, the transformation applied to determine the identifier includes salting. Salting adds a layer of security by making the identifier more difficult to predict and reducing the risk of accidental collisions, thus improving the security and reliability of communications.

[0055] 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 said salting. This method allows for the dynamic resolution of identifier conflicts by applying salting only when necessary, thus simplifying the identifier determination process whenever possible.

[0056] In one example, at least one criterion takes into account a rule type and / or a property of the data field. Considering the rule type and / or the properties of the data fields makes it possible to generate identifiers that are more relevant and adapted to the specific characteristics of the network and applications. For example, at least one criterion can take into account the properties of the data fields specific to the communication protocol(s) used in a network, thus improving the performance and reliability of data exchanges within the network. An additional advantage is that, since the identifier is derived from the fields of the rule set, it can serve as a check to determine whether the rule set is stable or whether it has been modified (accidentally or deliberately).When the application of the criterion 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.

[0057] 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, it is guaranteed 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.

[0058] In one example, the at least one selected target value is a network address. Network addresses, such as IPv6 addresses, are generally 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. Brief description of the drawings

[0059] Other features, details and advantages will become apparent from reading the detailed description below and from analyzing the accompanying drawings, in which: Fig. 1

[0060] [Fig.1] 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

[0061] [Fig.2] and [Fig.3] each show a header compression rule in a example of a project. Fig. 4 Fig. 5

[0062] [Fig.4] and [Fig.5] show two derived rules resulting from a processing of the rule of header compression of [Fig.2], in an example implementation. Fig. 6

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

[0064] [Fig.7] shows a selection of fields resulting from rules derived from [Fig.5] and [Fig.6] as well as an optional additional field. Description of the implementation methods

[0065] In the description that follows, identical reference numerals designate identical elements or elements having similar functions.

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

[0067] 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.

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

[0069] 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.

[0070] 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 to distinguish a field from a set of possible fields. The identifier of a field is thus an additional example of a property of that field.

[0071] According to another example, an identifier for a particular set of data compression rules makes it possible to distinguish that particular set of data compression rules from among 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 substitutable 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.

[0072] 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 comprising 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 computational operation is performed on its value).

[0073] The expression "criterion 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 may take into account the type of the rule, the fields themselves, their properties, and / or their values. For example, a criterion may specify to select all field values ​​to which a rule of a certain type relates and which have a particular property (for example, a particular field value, or an identifier belonging to a predetermined list of identifiers). Generally, the same criterion may be applied to one, several, or all of the rules in a set of compression rules. For example, the criterion may be intended to be applied, or applicable, to all rules of one or more particular types within a set of compression rules.

[0074] 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.

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

[0076] The term "hashing" refers to a mathematical function, for example 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 result in different outputs when hashed, even if the space of possible output values ​​is much smaller than that of possible input values. A hash function therefore seeks to minimize possible output collisions. Hashing is used, for example, for data integrity verification and / or for data compression.A hash function can be complemented by a truncation operation on its result to ensure, for example, that the result has a given size, and / or by a puncturing operation, for example, to improve compression efficiency by removing redundant or non-essential data located anywhere within the hash function's result. As an example, a cyclic redundancy check uses a hashing procedure.

[0077] 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.

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

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

[0080] 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.

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

[0082] 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, a modem, a base station in a telecommunications network, or a core entity in a telecommunications network.

[0083] 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.

[0084] 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.

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

[0086] Reference is now made to [Fig. 1], 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 shown in [Fig. 1] may, 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.

[0087] All suitable hardware and / or software may be used for the practical implementation of said communication system and / or said communication devices. In general, 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 technique The proposed solution may also cover 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 processes described in this document. Examples of such solutions include those offered by cloud architectures, etc.

[0088] 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.

[0089] In the example of [Fig. 1], 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.

[0090] In the example shown in [Fig. 1], 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, and all devices connected to this wireless network can share the same set of compression rules capable of efficiently compressing messages exchanged on the local network. 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 several receivers simultaneously. All receivers sharing this stream can use the same compression context to receive the data efficiently.It is also possible to have several 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 data streams of different types (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 performance. 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.

[0091] In the example embodiment of [Fig. 1], an example of a lens that can be The desired outcome 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.

[0092] Indeed, when communication contexts used simultaneously by the same node are not distinct, decompression errors can result. 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.

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

[0094] On the other hand, 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 precisely, 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.

[0095] Generally speaking, as long as the nodes involved do not need to manage multiple contexts simultaneously for different communications, the use of shared compression rule sets, or sets that share the same identifier, does not pose a problem. This situation typically occurs in networks where communications are sufficiently spaced out in time or managed by effective planning mechanisms that avoid conflicts.

[0096] 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.

[0097] It comprises, at least one obtaining of at least one rule from the set of data compression rules, said at least one rule being relative to at least one field comprising at least one field value.

[0098] 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.

[0099] This technique aims to optimize the management of compression contexts by ensuring the uniqueness of identifiers, thereby minimizing the risks of conflicts and decompression errors. The uniqueness of the context identifier 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.

[0100] The present 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 point-to-point communication graph. By applying concepts from graph theory, it is possible to ensure that communications involving the same node do not use conflicting context identifiers, thereby improving communication reliability.

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

[0102] The present technique enables decentralized management of identifiers, facilitating network scaling 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.

[0103] Conversely, the present 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) server or a software-defined networking (SDN) controller, can be responsible for determining contexts and generating identifiers.This centralized entity collects the necessary information from communication devices, calculates the appropriate identifiers according to compression rules, and then distributes them to the relevant devices.

[0104] Compression rule sets can be obtained in several ways. According to 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. These individuals 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, the compression rules can be dynamically adjusted according to conditions. real-time network. For example, in a network where available bandwidth varies, compression rules can be adjusted to maximize transmission efficiency based on the current network capacity.

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

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

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

[0108] 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 this filtering criterion or criteria be judiciously designed to ensure that the target values ​​are relevant and discriminating.

[0109] A transformation, such as hashing, is then applied to the selected target values, this transformation producing a unique bit sequence that will serve as a context identifier. The resulting context identifier may be verified for uniqueness in the local or global context, as required. 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.

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

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

[0112] 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 direction of the packet to which this description applies, three values ​​being possible: Up (Uplink), Dw (Downlink) or Bi (Uplink and Downlink), the target value (TV), which is a reference value against which the value of the field is compared, a comparison operator (MO), for example complete equality ("Equal") or equality of only the N most significant bits, a compression and decompression action (CDA), which indicates what to do if the content of the field matches the target value: for example, do not transmit the field ("Not-Sent"),if its value is a known value), or (for the decompressor) recalculate its value ("Compute" in English) from the data.

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

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

[0115] 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 comprising a header consisting of several fields, each field of the header is treated individually according to the field descriptors included in the rule.

[0116] Each field in the packet header is identified by its 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 residue.

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

[0118] 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 values ​​of the uncompressed fields transmitted in the compression residue.

[0119] The structure of a data packet whose header has been compressed by applying a rule according to RFC 8724 comprises three main elements: the identifier (RulelD) 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 correspond to the target values, or because the applicable compression rule specified that they should be transmitted as is; and the payload, that is, the part of the packet containing data not affected by the header compression process.

[0120] It is therefore understood that each packet exchanged between nodes in a multi-hop scenario must include a rule identifier (RulelD) for each compression rule applied. This means that if a packet is to be processed by several compression rules, each corresponding RulelD must be included in the packet header. This increases the size of the header and, consequently, the transmission overhead, thus reducing the overall efficiency of the communications.

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

[0122] 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 so as to be unique across the two neighbors of each node.

[0123] The proposed technique presents, according to 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.

[0124] An illustrative example of a heuristic selection module suitable for implementing such a selection is now set forth, 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.

[0125] 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.

[0126] 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.

[0127] This splitting is performed 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 set and the second set 32.

[0128] 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').

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

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

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

[0132] 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 with the second set 32 ​​and the third set 33 as sets of the same type, in this case both applicable to uplink traffic.

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

[0134] Applying the first criterion to the first set 31 entails: 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 in this field descriptor fulfills the first criterion.

[0135] Applying the first criterion to the second and third sets 32, 33 entails: 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 in this field descriptor meets the first criterion, and the exclusion of the field descriptor whose identifier is "CoAP:Type" because the target value "ObOl" specified for this field descriptor within the second set 32 ​​is different from that "ObOO" specified for this field descriptor within the third set 33, thus this field descriptor does not fulfill the first criterion.

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

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

[0138] In a third step, a target value is selected for each field descriptor retained after filtering.

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

[0140] 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.

[0141] 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 "ObOl".

[0142] In a fourth step, the context identifier is determined from, at least, the selected target values.

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

[0144] 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...

[0145] 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.

[0146] 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 the most significant bits. significant or less significant, similar filtering criteria can be used to select the most representative target values.

[0147] 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).

[0148] 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.

[0149] 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 values ​​for fields whose descriptors are common to all the traffic types considered. Traffic direction can be taken into account by inverting certain values. For example, to ensure that the selected target values ​​are relevant for all traffic types, it is relevant to compare a source address of a downlink communication with a destination address of an uplink communication, and vice versa.

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

[0151] For example, the choice of one or more criteria to apply for selecting one or more target values ​​can be made expertly and based on prior assumptions about the data fields and / or compression rules used. For example, in an IoT network where the 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.

[0152] 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 may be possible to apply the criterion or criteria only to a part of the set of data compression rules, that is, only to certain rules in the set, or only to certain field descriptors contained in one or more rules in the set.

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

[0154] 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.

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

[0156] Fig. 7 represents a table 41 comprising the target values ​​selected according to the illustrative heuristic example and the identifiers of the corresponding fields, as well as an additional value "Oxbeef" called salting value or salt, usable for static salting.

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

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

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

[0160] 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 several repetitions of the additional value. Alternatively, the concatenation module can, for example, be replaced by a block coding module.

[0161] The hashing module is configured to determine a hashing result for 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 hashing 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.

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

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

[0164] By way of illustration, an example of calculating a context identifier is detailed based on the field values ​​as shown in [Fig. 7]. In this example, the selected field values, namely "20010db8::04", "20010db8::03", and "ObOl", are simply concatenated, resulting in the following string: "20010db8::0420010db8::030b01". The resulting string is provided as input to 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 obtained 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 may be possible to retain only the last four bits of the ASCII encoding of the first character of the MD5 hash result as the result of the transformation of the selected field values ​​and to 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.

[0165] 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.

[0166] The transformation module may further 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.

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

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

[0169] The process comprises: obtaining at least one data field, obtaining an identifier from a set of data compression rules including at least one rule including at least one target value of the data field, a determination of a compression residual by applying the set of data compression rules at least to the data field, and a transmission of a signal representing at least the identifier and the compression residue.

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

[0171] 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.

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

[0173] 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, for example, concatenation or compression of both. This transformation can include techniques such as salting, hashing, or any other method relevant to optimizing transmission. Furthermore, within the framework of a data compression protocol such as the SCHC protocol, the signal can include compressed representations of the identifier and the compression residue according to the compression rules specific to the protocol used, thus enabling efficient transmission in accordance with the specifications of that protocol.In summary, the signal can be configured to maximize transmission efficiency and robustness by adapting the shape of the transmitted data to the specific needs of the network and applications.

[0174] 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.

[0175] 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 the filtering criteria to the field descriptors to select the relevant target values, and a transformation module that uses the selected target values ​​to generate a unique context identifier.

[0176] 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.

[0177] 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.

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

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

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

[0181] 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 avoiding collisions and improving the reliability of communications in complex networks.

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

[0183] 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. Industrial application

[0184] 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 offering robust solutions for context identifier management and data compression.

[0185] 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

Demands

1. 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: obtaining the set of data compression rules, and 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 set of data compression rules.

2. A method according to claim 1, further comprising a transmission of the identifier.

3. A method according to claim 1 or 2, further comprising a verification of the uniqueness of the identifier within an identifier database.

4. A method according to any one of claims 1 to 3, wherein the transformation applied to determine the identifier includes encoding and / or compression.

5. A method according to claims 1 to 4, wherein the transformation applied to determine the identifier includes salting.

6. Method according to claim 5, 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.

7. A method according to any one of claims 1 to 6, wherein at least one criterion takes into account a type of rule.

8. A method according to claim 7 wherein at least one criterion applies to the rules for completely erasing a value.

9. A method according to any one of claims 1 to 8, wherein at least one criterion takes into account a property of the data field.

10. Method according to claim 9 wherein at least one selected target value is a network address.

11. Management entity configured to determine an identifier for a set of data compression rules, a rule comprising at least one target value for at least one data field,

12.

13. the management entity comprising: a module for obtaining the set of data compression rules, 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 one part of the data compression rule set. Mobile terminal comprising a management entity according to claim 11. Communication device comprising a management entity according to claim 11.

Images