Transmitting, receiving, and analysing, payload

Abstract

According to an aspect, there is provided a method performed by a first node (201) for transmitting a payload. The method comprises transmitting (401), to a second node (202), a packet comprising the payload, and one or more indications. The one or more indications comprise one or more of: a compression indication indicating whether or not the payload in the transmitted packet has been compressed; a format indication indicating a data format for data in the payload; a rule indication indicating a compression rule used to compress the payload; and a payload indication indicating where the payload starts in the transmitted packet.

Description

[0001] TRANSMITTING, RECEIVING, AND ANALYSING, PAYLOAD

[0002] Technical Field

[0003] This disclosure relates to a method for transmitting a payload, a method for receiving a payload, a method for analysing a payload, a corresponding computer program product, and corresponding nodes.

[0004] Sensor Measurement Lists (SenML) is a format defined in Request for Comments (RFC) 8428 by the Constrained RESTful Environments (CoRE) Working Group of the Internet Engineering Task Force (IETF) (https: / / datatracker.ietf.org / doc / html / rfc8428). It provides a way to represent simple sensor measurements and device parameters in the context of the Web. It supports JavaScript Object Notation (JSON), extensible Markup Language (XML), Concise Binary Object Representation (CBOR) and Efficient XML Interchange (EXI) data formats.

[0005] SenML is designed to be extendable and maintains a specification and registry at the IETF for base attributes and units of measurement. It also has support for attributes specific to the context of use.

[0006] Static Context Header Compression (SCHC) is defined in RFC 8724. It is a protocol defined by the Low-Power Wide Area Networking (LPWAN) Working Group of the IETF for compressing and fragmenting Internet packets over LPWANs. SCHC provides a mechanism for compressing protocol headers and transmitting them over LPWANs. It does this by defining rules in a context shared between the sender and receiver. The context provides the static information needed to restore the complete headers at the receiver. A packet with the uncompressed header is still called a SCHC Packet if the compression was attempted (in this case, a Rule Identifier (ID) might be used to indicate that the packet header has not been compressed).

[0007] Fig. 1 shows the structure of a SCHC packet 100. Data to be transmitted is included in a payload, and the payload has an associated header according to the protocol to be used for transmission. A SCHC packet 100 comprises the payload 102 (also referred to as ‘packet payload’), and a compressed header 104. The compressed header 104 comprises a Rule ID 106 and Compression Residue 108.

[0008] The Rule ID 106 indicates the Rule that was used to compress / decompress the original header. The Compression Residue 108 (effectively the compressed header) is assembled at the transmitter by concatenating the residues for each field in the uncompressed header, in the order the Field descriptions appear in the Rule, if required. It will be appreciated that the Compression Residue 108 may contain a full (uncompressed) field value or a value to apply the given operators from the rule, or not have any value at all. The Packet Payload 102 is the payload (data) of the original uncompressed packet 100.

[0009] An example of human-readable SCHC rules in the JSON format is displayed in Listing 1 below:

[0010] Listing 1

[0011] The example above is taken from the OpenSCHC implementation (found at: https: / / openschc.github.io / openschc / ). A description of all the fields of a SCHC rule can be found at: https: / / openschc.github.io / openschc / Source / gen_rulemanager.html#compression-rules. Summary

[0012] There are several header compression protocols that are widely used and already standardized in IETF, e.g., SCHC or Robust Header Compression (ROHC). However, payload compression is usually left to application designers, leading to sub-optimal compression and application over-engineering, induced by ad-hoc / non-standard solutions. Thus, the clear demarcation between header and payload compression harms the end-to-end efficiency of applications. For example, applications encoding their payload with efficient methods, for example CBOR, would only marginally reduce the size of the payload. The inefficiency arises because the compressor / encoder and decompressor / decoder would need to implement two different engines to be able to perform both compressions / decompressions, and in particular the payload part might have multiple implementations and formats that are not necessarily interoperable between systems.

[0013] A standard solution for full packet (i.e., header and payload) compression is not currently available, and current header compression solutions such as SCHC do not cover payload compression. One issue to be highlighted is that the lack of a comprehensive solution hinders the deployment of bandwidth-efficient applications, which in turns translates to energy inefficiency as the network infrastructure uses more resources.

[0014] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. In particular, this disclosure provides a method to enable a SCHC engine to implement payload compression, optionally in addition to header compression for which it was originally designed. At the compressor side, the header can be compressed in the usual way, and the payload is also compressed. The compressor generates ‘hints’ for the decompressor on how to decompress the payload, and includes these hints in the compressed packet. In addition, the compressor can include an indication in or with the compressed packet indicating whether the payload has been compressed and / or where the compressed payload starts in the transmitted packet. The decompressor uses the hints and indication in the received packet to decompress the payload.

[0015] In some embodiments, a payload can be analysed and long and / or repeated payload values can be identified for compression. Rules (e.g., SCHC rules) can be generated for payload values that also contain hints for the decompressor on how to decompress the payload (naming semantics in Field ID (FID)). This analysis can be performed at either the compression or decompression side, i.e., by the node implementing the compression / decompression itself, or by another node (which is also referred to herein as a “third node”).

[0016] Particular embodiments provide a method for extending the SCHC IETF standard to support dynamic payload compression / decompression, in addition to header compression for which it was originally designed.

[0017] The SCHC static context, which enables header compression to work, can be exchanged out of band, and can be devised before the deployment of the client's software, e.g. the firmware of the Internet of Things (loT) device. It is possible to set up a-priori the SCHC context for header information, as it likely does not change.

[0018] However, payload is dynamic. Nevertheless, the techniques described herein allow the compression and decompression engines built for header compression to be applied also to the payload, making the implementation more efficient.

[0019] Embodiments of the techniques provide for the dynamic generation, and sharing with the client, of SCHC rules derived from an analysis of a payload sent from a client. The server or other node can decide from this analysis which part(s) of future payloads should be compressed, and how. Moreover, the values that have been marked for compression can be translated into SCHC rules, since SCHC rule parameters, such as matching operator and compression actions, should be decided to provide effective compression.

[0020] At the decompressor side, given a set of SCHC rules, the decompressor can reconstruct the original payload in the original uncompressed format, specifically key-value based formats, e.g., JSON, YAML, XML, etc. This can be enabled by encoding specific semantic(s) into the FID field of SCHC rules.

[0021] A signalling mechanism can be provided for the compressor to signal the existence of the SCHC compressed payload so that the decompressor knows where and if to apply payload decompression.

[0022] Certain embodiments may provide one or more of the following technical advantage(s).

[0023] Payload compression is enabled in SCHC, which is otherwise designed only for header compression. SCHC is an IETF standard and widely used in loT, and can be used in 3rdGeneration Partnership Project (3GPP) networks, for example as described in RFC 9391 “Static Context Header Compression over Narrowband Internet of Things”.

[0024] Smaller payloads (due to compression) can either reduce network resource utilisation, or increase the number of concurrent transmissions (with the same amount of network resources).

[0025] Payloads carrying (possibly long) strings, e.g., long Uniform Resource Locators (URLs), may see significant benefit from the compression described herein. It is noted that even efficient encoding schemes, such as CBOR, cannot further compress strings such as URLs.

[0026] The transmission time of sensor updates may be dramatically reduced.

[0027] Shorter transmission times translates to better energy efficiency and improved sensor battery life. According to a first aspect, there is provided a method performed by a first node for transmitting a payload. The method comprises transmitting, to a second node, a packet comprising the payload, and one or more indications. The one or more indications comprise one or more of: a compression indication indicating whether or not the payload in the transmitted packet has been compressed; a format indication indicating a data format for data in the payload; a rule indication indicating a compression rule used to compress the payload; and a payload indication indicating where the payload starts in the transmitted packet.

[0028] According to a second aspect, there is provided a method performed by a second node for receiving a payload. The method comprises: receiving, from a first node, a packet comprising the payload, and one or more indications. The one or more indications comprises one or more of: a compression indication indicating whether or not the payload in the received packet has been compressed; a format indication indicating a data format for data in the payload; a rule indication indicating a compression rule used to compress the payload; and a payload indication indicating where the payload starts in the received packet.

[0029] According to a third aspect, there is provided a method performed by a node. The method comprises analysing respective payloads of one or more packets to identify parts of the payload that can be compressed; and determining one or more compression rules based on the identified parts.

[0030] According to a fourth aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect, the second aspect, the third aspect, or any embodiments thereof.

[0031] According to a fifth aspect, there is provided a node configured to perform the method according to first aspect, the second aspect, the third aspect, or any embodiments thereof.

[0032] According to a sixth aspect, there is provided a node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said node is operative to perform the method according to the first aspect, the second aspect, the third aspect, or any embodiments thereof.

[0033] Brief Description of the Drawings

[0034] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0035] Fig. 1 shows the structure of a SCHC packet;

[0036] Fig. 2 shows conventional sensing update signalling between a client and server; Fig. 3 shows sensing update signalling between a client and server according to some embodiments;

[0037] Fig. 4 is a flow chart illustrating a method of operating a first node according to some embodiments;

[0038] Fig. 5 is a flow chart illustrating a method of operating a second node according to some embodiments;

[0039] Fig. 6 is a flow chart illustrating a method of operating a third node according to some embodiments; and

[0040] Fig. 7 is a block diagram of a node according to some embodiments.

[0041] Detailed Description

[0042] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0043] Fig. 2 illustrates an example used throughout this disclosure, and which is referenced in the discussion of the new techniques, which is a standard loT scenario in which one node, an loT device (shown in Fig. 2 as client 201), sends sensing updates upstream towards a remote node (shown in Fig. 2 as server 202). The remote node may be located at a cloud / edge facility or in the network of which the client 201 is part. The loT device that sends sensor updates 203 is referred to herein as a client 201 , or more generally a “first node”. The server 202 or remote node is also referred to herein as a “second node”. In a conventional implementation, the sensing update 203 is a SCHC packet in which the header has been compressed using SCHC techniques.

[0044] The sensing device 201 can send updates 203 in the SenML format, an example of which is found in Listing 2 below:

[0045] Listing 2: SenML reference example of sensor updates.

[0046] The SenML payload in Listing 2 above, assuming a UTF-8 encoding, is 118 Bytes (B) in size. For so-called constrained devices (i.e., loT devices), such a payload size is quite large and may bring premature exhaustion of the device’s energy budget.

[0047] In general, the client 201 can be any type of device that has data to transmit to another device. In a 3rdGeneration Partnership Project (3GPP)-standardised communication network, the client 201 can be a User Equipment (UE), and the server 202 can be a node in the Radio Access Network (RAN), a node in the Core Network (CN), or a node external to the communication network. The UE / client 201 can be an loT device that has one or more sensors or sensing functions, and that is to intermittently send sensor measurements (sensing update 203) to the server 202.

[0048] Fig. 3 is a signalling diagram showing signalling of a sensing update between a client 201 and server 202 according to some embodiments of the techniques described herein. In particular, techniques based on SCHC are used to compress a payload 102 that contains the sensor measurements. It will be appreciated that the techniques described herein can be used to compress any type of key-value based payload 102, and the content of such payloads is not limited to sensor measurements.

[0049] In general, a sensing update from the client 201 to the server 202 may need to be transmitted. A sensing update may be transmitted periodically, when a new sensing update is available, when an amount of data stored in a buffer of the client 201 reaches or exceeds a threshold, or in response to a request from another node (e.g., a request from the server 202). The sensing update contained in the uncompressed payload 102 may be in a format such as SenML, JSON, XML, CBOR or EXI.

[0050] Block 300 of Fig. 3 relates to an optional technique for identifying, determining or improving how payloads 102 can be compressed. In particular, based on one or more payloads (e.g., sensing updates) 301 sent to the server 202, in step 302 the server 202 can inspect and / or analyse the payloads 102 to identify parts of the payload that can be compressed in future payload transmissions by the client 201. Step 302 is described in more detail below, but briefly step 302 can comprise the server 202 identifying parts of the payload 102 as candidates for compression that are common to other transmissions of payloads 102. For example, the parameter names, e.g., "temperature" or "humidity" in Listing 2 above may be identified as repeated parts of payloads 102, and are therefore candidates for compression according to the techniques described herein.

[0051] The server 202 generates SCHC rules that relate to compression of the payload (step 303), and these are sent to the client 201 (signal 304). The generation of SCHC rules for payload compression is described in more detail below. As shown in Fig. 3, the analysis (step 302) and compression rule generation (step 303) can be performed on ‘live’ packets from the client 201 , but it will be appreciated that compression rules can be predetermined or preconfigured before the client 201 or server 202 are operational. For example, if the type of content and / or data structure of the payloads from the client 201 are known in advance, then the compression rules can be generated and the client 201 can be preconfigured with the compression rules.

[0052] In either case (i.e. , generation of the compression rules via block 300, or preconfiguring the client 201 with the compression rules), for a (or any) future payload(s) 102, the client 201 can use the received SCHC rules to compress the payload 102 to generate a compressed payload, and sends a SCHC packet including the compressed payload to the server 202 (signal 305). The conventional SCHC techniques can also be used to compress the header of the packet, and so the SCHC packet can include a compressed header 104 (e.g., comprising a Rule ID 106 and Compression Residue 108) and the compressed payload.

[0053] The SCHC packet 305 can include, or the transmission of the SCHC packet 305 can be accompanied by, information that assists the server 202 in decompressing the compressed payload. This information may comprise any one or more of a compression indication, a format indication, a rule indication and a payload indication.

[0054] The compression indication is an indication of whether the payload in the SCHC packet 305 has been compressed. This indication is useful as some SCHC packets may not have a compressed payload, for example the payload in sensing update 301 , and this indication informs the server 202 whether decompression is required.

[0055] The format indication is an indication of the format of the data contained in the original (decompressed) payload (e.g., SenML, JSON, XML, CBOR or EXI). This indication is useful as it assists the server 202 in reading the data in the payload.

[0056] The compression rule indication is an indication of one or more compression rules used to compress the payload. This indication is useful as it enables the server 202 to apply the correct rule(s) when decompressing the payload.

[0057] The payload indication is an indication of where in the received SCHC packet 305 the compressed payload starts. This indication is useful as the start of the compressed payload in the SCHC packet 305 may not be clear, or even consistent from packet to packet.

[0058] In step 306 the server 202 decompresses the compressed payload according to the SCHC payload compression / decompression rules to obtain the original payload 102.

[0059] While block 300 of Fig. 3 is shown as operating on payloads in the sensing updates 301 that were not compressed (as the compression rules have not yet been established in step 303 following the analysis in step 302), it will be appreciated that the operations in block 300 can be performed regularly or continuously to update the compression rules useable by the client 201 to compress the payloads (for example if the data content of the payloads changes overtime). Thus, after receiving a SCHC packet 305 including a compressed payload from the server 202 and decompressing the payload, steps 302 and 303 can be performed with respect to that decompressed payload to determine new or updated compression rules. The analysis in step 302 and generation of compression rules in step 303 can result in compression rules for the payload in a form that is similar to the rules shown in Listing 1 above. In SenML, JSON, and key-value data structures at large, only two fields can be directly mapped to a SCHC rule, namely, FID (the key) and Target Value (TV) (the value). However, a SCHC rule is composed of 7 to 9 fields. Such fields are populated according to specific needs of the client 201 , and the server 202 (or other node generating the compression rules) can have a policy to decide on those. As an example, the server 202 / node may be set to operate in a way to minimise the transmitted payload, rather than minimise the overhead of storing the SCHC context for each client 201 .

[0060] The following description provides examples of the analysis of payload data and selection of values to compress according to step 302. In particular, the following example describes a way to select values to compress in the case of SenML, or JSON more generally.

[0061] In step 302, the server 202 inspects the payload received from the client 201 and builds a data structure that keeps track of the occurrences of each key or value in different received payloads. In the context of this disclosure, “value” refers to the key / value of a key-value data structure. A common example of key-value structure is a JSON object, like SenML. For example: {"key1”:” “valuel”, “key2”: value2}.

[0062] For example, the server 202 receives three sensing updates similar to Listing 2, but with different values, i.e., 25.2, 25.1 , and 24.8, for temperature, and 30, 31 , and 35, for humidity. A data structure constructed by the server 202 with such occurrences may be as shown in Listing 3 below:

[0063]

[0064] Listing 3: A dictionary-like data structure used to count the occurrences of keys and values of the payload sent by the client.

[0065] Thus, in the analysis in step 302, the server 202 evaluates the data structure and marks payload values for compression that are either long, or repeated several times. The server 202 can perform step 302 (and step 303) continuously, e.g., after each sensing update is received from the client 201 , or intermittently. In the latter case, the server 202 may evaluate a criterion to determine whether or not to perform step 302 (and step 303). One criterion can be if a minimum amount of time has elapsed since the step(s) were last performed, e.g., 10 minutes. A different criterion can be if a required amount of messages (sensing updates 301) have been received since the step(s) were last performed, e.g., 10 messages. Another criterion can be based on the size of the payload of a received sensing update 301 exceeding a minimum size, e.g., the step(s) can be performed if the payload exceeds 100B. Another criterion can be based on a number of repetitions in the content of received payloads, e.g., the steps can be performed if a particular element is repeated more than 3 times in adjacent messages. In some cases, a combination of the above criteria could be used to determine whether to perform steps 302 and / or step 303.

[0066] There are several ways the server 202 can mark specific values for compression. A simple way is for the values to satisfy a server-defined condition. For example, such a condition may be that there is at least one item for which the number of occurrences is greater than two, and its length is greater than two bytes or greater than two characters. As a result, after applying the condition, Listing 3 can be reduced to the non-empty, data structure shown in Listing 4:

[0067] Listing 4: A dictionary-like data structure after applying the server-defined condition for compression to Listing 3.

[0068] Subsequently, the server 202 may take Listing 4 as input, and manipulate it by assigning a unique key for each value in the data structure. An example of such output is shown in Listing 5 below:

[0069] Listing 5: A dictionary-like data structure that maps unique keys to the values that will be compressed via SCHC.

[0070] The unique key and the respective value can be mapped to the FID and TV fields, respectively, in the SCHC payload compression rules, as described further below.

[0071] The description below provides an example of a strategy and generation of SCHC payload compression rules implemented by the server 202 or other node. More advanced implementations of the generation of compression rules may make use of state machines, or Machine Learning (ML) or Artificial Intelligence (Al) algorithms, etc.

[0072] FID (Field Identifier) - The FID may be mapped straight from the keys in Listing 5, e.g., application / senml+json.n.1. In this particular example, the naming of the key carries semantics. The part to the left of the first dot, i.e. , “senml+json”, identifies the content type of the payload, which provides a hint to the decompressor (e.g. server 202) on how to decompress the compressed key-value pair. The part to the right of the first dot, i.e., “n.1”, encodes the name of the key of the key-value pair, n, followed by a number that groups together fields of the same objects. For example, all FIDs with number 1 , namely “n.1”, and “u.1”, belong to the same SenML record (and will all be enclosed in curly brackets).

[0073] FL (Field Length) - The FL is computed by the server 201 or node simply by evaluating the size of the value to compress.

[0074] FP (Field Position) - The FP may not be useful in the case of SenML, meaning that whether the measurement unit comes before or after the value is irrelevant. However, if for any specific reason the position of the field is of relevance, then this field can be used.

[0075] Direction (DI) - The DI expresses whether the compression / decompression happens upstream or downstream. In the case of loT scenarios, the direction is almost always upstream since it is critical to reduce transmission time to extend the battery life of loT devices as much as possible.

[0076] TV (Target Value) - The TV is the value on which to perform the Matching Operator (MO). Essentially, it is the value, or part of the value, that is to be compressed.

[0077] MO (Matching Operator) - The MO is the operation that is applied to every payload value and, when there is a match between such value and the TV, a compression / decompression action (ODA) will be applied. Essentially, if there is a match, the payload value will be com pressed / decompressed .

[0078] CPA (Compression / Decompression Action) - This is the action to be taken to the payload value in case the payload value matches the TV. Common actions are: not-sent (the value will be omitted in the sent payload), value-sent (the value will be sent), L(ess)S(ignificant)B(it) (only the least significant part of the payload value will be sent).

[0079] An exemplary set of SCHC rules for Listing 2 generated by the server 202 may be as follows in the JSON encoding used by OpenSCHC:

[0080] Listing 6: OpenSCHC payload compression rule generated in step 303.

[0081] In the above rule (“Rule 12”), the fields “application / senml+json. u.1 / 2” are never sent because they are known a-priori and will probably never change (since a temperature sensor will always return Celsius or Fahrenheit). The fields “application / senml+json. n.1 / 2” are shortened only to their last character (due to Most Significant Bit (MSB) and LSB), namely, “e” and “y”. Finally, the fields “application / senml+json. v.1 / 2” are ignored by the compressor and will be sent without compression, given that they may change.

[0082] As a result, the initial SenML payload from Listing 2 of 118 Bytes can be shortened to 7 Bytes. Applying rule 12 to the SenML payload in Listing 2 yields the following payload (in hexadecimal format):

[0083] Listing 7: Result of applying SCHC rule 12 from Listing 6 to the payload from Listing 2.

[0084] In the above example, 0C is the hexadecimal representation of 12, which indicates that whatever follows is compressed according to rule 12. That is, the SenML base name, 2001 :db8: 1234:5678:: 1 / , is omitted. The hexadecimal representation of “12” is one example of the rule indication described above. Then, the last letter of the names is compressed, namely, 65 and 76, representing e (from temperature) and y (from humidity). In addition, the measurement units Cel and %RH are omitted (“not-sent” CDA applies). Finally, the values are encoded as 4 Bytes.

[0085] The following section explains how decompression hints (e.g., one or more of the indications described above) can be encoded in one or more FID fields at the compression side (i.e., the client 201). In particular, this section describes how to manipulate the FID field(s) so as to provide hints to the decompressor on how to reconstruct the original payload. Several ways to encode such hints are possible, and two particular examples are set out below.

[0086] In the first example, the content-type of the payload, the name of the field associated with the value, and a group identifier, are encoded in the FID. It is possible to separate these pieces of information with a single character, a dot (“.”) for example. Taking Listing 5 as an example, the part to the left of the first dot is a standard content type, e.g., application / senml+json, while the part to the right of the first dot is the name of the payload field followed by a number used to group fields together, e.g., n.1. As a result, the name of such a key would be “application / senml+json. n.1 ”.

[0087] In this way, the decompression side (i.e. the server 202) knows that the compressed payload is of SenML type encoded in JSON, thus knows that every field must be decompressed as “key”: “value”, every field with the same numeric identifier, e.g., n.1 , and u.1 , enclosed by curly brackets, and finally everything enclosed in square brackets, as per SenML encoding.

[0088] More generally, the hints for the decompressor can be encoded as:

[0089] Listing 8

[0090] In the second example, the content-type of the payload is encoded in a first FID of the rule. This can save some bandwidth when the context is exchanged. For example, the first FID of the rule can be “application / senml+json. name1.1”. A second FID of the rule can be “name2.1” (in the second FID the content-type is implicit).

[0091] This section describes how the compressor side can signal a SCHC compressed payload. The SCHC decompressor at the server 202 needs to know whether or not to apply the payload compression rules, and where the payload (or rather the payload residue following compression) starts in the received SCHC packet 305. These are respectively provided by the compression indication and payload indication described above. For header compression the activation of SCHC is pre-agreed and therefore assumed. In that case, the decompressor knows that each packet (even uncompressed ones) will start with a SCHC rule. However, in the case of payload compression this becomes more complicated because the rules are applied only when the payload matches the rules, and in all other cases the other type(s) of payload will have to be distinguished from what requires decompression. This should be taken in account in cases where only part of the payload is compressed through SCHC rules, or in cases where the client 201 no longer has the relevant compression rules, for example due to a reset of the client or due to implementation problems. Therefore, the uncompressed part should be distinguishable from anything else in the payload. Five possible implementations to address this issue are proposed below, although it will be appreciated that other options are also feasible.

[0092] - A first implementation uses a pre-agreed special character. The beginning of a SCHC compressed payload may be signalled with a special character, such as “*”, followed by the rule identifier, e.g., This special character can be either pre-agreed by the

[0093] Application Programming Interface (API) definition or by a standard, where there is an agreement on using a special character to indicate a rule. This can be a character, a set of characters, or even a field name (e.g., “schc”). After that the rest of the data is the compression residue (for example, *12:[12,23,54,2]).

[0094] - A second implementation uses an explicit rule identifier in the rule definition that can be used by the decompressor to understand what rule to apply. For example, when defining rule 12 there could be a RuleField: “schc12”. If such RuleField is found in the payload the decompressor knows that it must apply the matching rule using the data provided as compression residue (for example, {schc12:[23,12,24A]}).

[0095] - A third implementation, which applies to a partial encoding / compression, uses a rule identifier plus rule field followed by its residue. First, the rule identifier is provided, then the field that is compressed, and finally the residue. For example: 12,4,0,0,0,30 (rule 12, field 4 [PAYLOAD. V2], and value 30, as shown in Listing 6).

[0096] - A fourth implementation uses a rule identifier and residue encoded in a known format that is specified either by the APIs or a standard. The compressed payload could be formatted in a JSON-like format as follows:

[0097] {schc:[rulelD, residue]} or {schc:{rulelD: [residue]}}

[0098] - A fifth implementation uses a new content type to signal that the payload is compressed with SCHC and therefore the decompressor must use SCHC rules for decompression. This new content type can be signalled by the application protocols, for example in Constrained Application Protocol (CoAP) or Hypertext Transfer Protocol (HTTP). An example of such content type may be application / schc and may be indicated in Internet Assigned Numbers Authority (IANA) registry, e.g., 3333.

[0099] If a method as above is not found in the payload, this means that the payload is uncompressed. The following section explains how decompression of a SCHC-compressed payload can be performed. In particular, this section describes how a SCHC decompressor (e.g., in the server 202) can translate data from Listing 7 into Listing 2.

[0100] The SCHC decompressor inspects the first byte of the payload, namely, 0C. The decompressor knows that the first byte corresponds to SCHC RulelD 12 in this case. The decompressor retrieves the rules and starts parsing from the first rule. The first rule “application / senml+json.bn.1” has CDA “not-sent”, which means that the bn value was omitted in the compression phase, and thus must be included now in the decompressed payload. To this end, the decompressor knows that the bn field and its value are encoded in the format “application / senml+json”. Therefore, the decompressor produces:

[0101] “bn”: “2001 :db8:1234:5678: :1 / ”

[0102] The SCHC decompressor moves now to the second rule “application / senml+json. n.1”. The decompressor learns that an MSB CDA was performed at the compression phase, which means that the compressor added a 1-byte (FL - MSB) value to the compressed payload. Specifically, the decompressor gets such value, 0x65 (the letter “e”), and adds it to the target value (temperature) and creates the following JSON key-value pair: “n”:“temperature”.

[0103] Similarly, all the other rules are applied and, when CDA is different from “not-sent”, data from the payload from Listing 7 is used to rebuild the original payload from Listing 2.

[0104] It should be noted that the decompressor should have knowledge of the content-type of the payload in order to reconstruct the original payload. This is the format indication described above. In this example, the content-type used was SenML JSON; however, other formats may be implemented on the decompressor to extend flexibility, e.g., YAML, XML, etc.

[0105] Fig. 4 is a flow chart illustrating a method of operating a first node according to various embodiments. As noted above, the first node can be client 201 , e.g., a UE, an loT device, etc. The first node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0106] In step 401 , the first node transmits a packet comprising a payload to a second node. The first node also transmits one or more indications to the second node. The one or more indications comprise one or more of: a compression indication indicating whether or not the payload in the transmitted packet has been compressed; a format indication indicating a data format for data in the payload; a rule indication indicating a compression rule used to compress the payload; and a payload indication indicating where the payload starts in the transmitted packet.

[0107] The payload in the transmitted packet may have been compressed, in which case, prior to transmitting the packet, the method can further comprise the first node compressing at least part of the payload according to one or more compression rules to generate a compressed payload.

[0108] If the payload in the transmitted packet was compressed, the one or more indications can comprise the compression indication, with the compression indication indicating that the payload was compressed.

[0109] If the payload in the transmitted packet was compressed, the one or more indications can comprise the rule indication indicating the one or more compression rules used to generate the compressed payload.

[0110] The compression rules used to compress the payload may have been received from the second node or a third node. The compression rules can be based on SCHC rules.

[0111] In some cases, the payload in the packet transmitted in step 401 may not have been compressed. In this case the compression indication can indicate that the payload in the transmitted packet is not compressed.

[0112] The payload, or data in the payload, can be in any of the following data formats: SenML, JSON, XML, CBOR, and EXI.

[0113] The packet transmitted in step 401 can further comprise a header. The header may be compressed, for example using SCHC rules. Regardless of whether the header is compressed, the one or more indications can be included in the header. In this case, the one or more indications can be included in one or more FID fields of the header. Alternatively, even in embodiments where the packet comprises a header, the one or more indications can be transmitted to the second node separately from the packet.

[0114] In some embodiments, the payload indication is a character or value. In some embodiments, the payload indication may be the rule indication.

[0115] Fig. 5 is a flow chart illustrating a method of operating a second node according to various embodiments. As noted above, the second node can be server 202. The second node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0116] In step 501 the second node receives a packet comprising a payload from a first node. The second node also receives one or more indications from the first node. The one or more indications comprise one or more of: a compression indication indicating whether or not the payload in the transmitted packet has been compressed; a format indication indicating a data format for data in the payload; a rule indication indicating a compression rule used to compress the payload; and a payload indication indicating where the payload starts in the transmitted packet.

[0117] The payload in the transmitted packet may have been compressed, in which case the method further comprises the second node decompressing at least part of the payload according to one or more compression rules.

[0118] If the payload in the received packet was compressed, the one or more indications can comprise the compression indication, with the compression indication indicating that the payload was compressed.

[0119] If the payload in the received packet was compressed, the one or more indications can comprise the rule indication indicating the one or more compression rules used to generate the compressed payload.

[0120] The compression rules used by the first node to compress the payload may have been sent to the first node by the second node or a third node. In general, the compression rules can be based on SCHC rules.

[0121] In some cases, the payload in the packet received in step 501 may not have been compressed. In this case the compression indication can indicate that the payload in the received packet is not compressed.

[0122] The payload, or data in the payload, can be in any of the following data formats: SenML, JSON, XML, CBOR, and EXI.

[0123] The packet received in step 501 can further comprise a header. The header may be compressed, for example using SCHC rules. Regardless of whether the header is compressed, the one or more indications can be included in the header. In this case, the one or more indications can be included in one or more FID fields of the header. Alternatively, even in embodiments where the packet comprises a header, the one or more indications can be received from the first node separately from the packet.

[0124] In some embodiments, the payload indication is a character or value. In some embodiments, the payload indication may be the rule indication.

[0125] Fig. 6 is a flow chart illustrating a method of operating a third node according to various embodiments. The method in Fig. 6 relates to the derivation of the compression rules, and can therefore be performed by the second node (e.g., server 202), the first node (e.g., client 201), or by another node on either the compression or decompression side. In the event that the method in Fig. 6 is performed by the first node, the first node can perform the method of Fig. 4 and Fig. 6. Likewise, in the event that the method in Fig. 6 is performed by the second node, the second node can perform the method of Fig. 5 and Fig. 6. The third node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0126] In step 601 , the third node analyses respective payloads of one or more packets to identify parts of the payload that can be compressed. This step can comprise identifying parts common to multiple payloads.

[0127] In step 603, the third node determines one or more compression rules based on the identified parts. This step can comprise determining a compression rule to encode or omit parts that are common to multiple payloads.

[0128] The third node may send the determined compression rules to another node, for example the first node and / or the second node.

[0129] Fig. 7 is a simplified block diagram of an apparatus 700 that can be used to implement, or implement part of, one or more of the nodes described herein. The apparatus 700 may be, or be a part of, a first node, a client 201 , a UE, an loT device, a server 202, a computer, etc. In particular embodiments, the apparatus 700 can be configured or adapted to perform the method in any one or more of Figs. 4, 5, and 6.

[0130] The apparatus 700 comprises processing circuitry (or logic) 701 . It will be appreciated that the apparatus 700 may comprise one or more virtual machines running different software and / or processes. The apparatus 700 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0131] The processing circuitry 701 controls the operation of the apparatus 700 to implement any of the methods described herein. The processing circuitry 701 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the apparatus 700 in the manner described herein. In particular implementations, the processing circuitry 701 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the apparatus 700.

[0132] The apparatus 700 also comprises a communications interface 702. The communications interface 702 is for use in enabling communications with other network node, computers, servers, etc. For example, the communications interface 702 can be configured to transmit to and / or receive from other nodes, requests, acknowledgements, information, data, signals, or similar. The communications interface 702 can use any suitable communication technology.

[0133] The processing circuitry 701 may be configured to control the communications interface 702 to transmit to and / or receive from other nodes, etc. requests, acknowledgements, information, data, signals, or similar, according to the methods described herein.

[0134] The apparatus 700 may comprise a memory 703. In some embodiments, the memory 703 can be configured to store program code that can be executed by the processing circuitry 701 to perform the methods described herein in relation to the apparatus 700. Alternatively or in addition, the memory 703 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 701 may be configured to control the memory 703 to store such information therein.

[0135] Although the computing devices described herein (e.g., UEs, nodes, clients, servers, etc.) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions, and methods, disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non- computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0136] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole.

[0137] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

Claims1. A method performed by a first node (201) for transmitting a payload, the method comprising: transmitting (401), to a second node (202), a packet comprising the payload, and one or more indications, wherein the one or more indications comprise one or more of: a compression indication indicating whether or not the payload in the transmitted packet has been compressed; a format indication indicating a data format for data in the payload; a rule indication indicating a compression rule used to compress the payload; and a payload indication indicating where the payload starts in the transmitted packet.

2. The method as claimed in claim 1 , wherein the method further comprises: compressing at least part of the payload according to one or more compression rules to generate a compressed payload; and wherein the step of transmitting (401) comprises transmitting the packet comprising the compressed payload.

3. The method as claimed in claim 2, wherein the compression indication indicates that the payload in the transmitted packet is compressed.

4. The method of embodiment 2 or 3, wherein the rule indication indicates the one or more compression rules used to generate the compressed payload.

5. The method as claimed in any of claims 1-4, wherein the method further comprises: receiving one or more compression rules from the second node (202) or a third node.

6. The method as claimed in claim 5, wherein the payload is compressed using the received compression rules.

7. The method as claimed in claim 1 , wherein the payload in the transmitted packet is not compressed and the compression indication indicates the payload in the transmitted packet is not compressed.

8. The method as claimed in any of claims 1-7, wherein the compression rules are based on Static Context Header Compression, SCHC, rules.

9. The method as claimed in any of claims 1-8, wherein the payload or data in the payload is in any of the data formats: Sensor Measurement Lists, SenML, JavaScript Object Notation, JSON, extensible Markup Language, XML, Concise Binary Object Representation, CBOR, and Efficient XML Interchange, EXI.

10. The method as claimed in any of claims 1-9, wherein the packet further comprises a header that is transmitted to the second node (202) with the payload.11 . The method as claimed in claim 10, wherein the one or more indications are included in the header.

12. The method as claimed in claim 10 or 11 , wherein the header is compressed and the compressed header is transmitted with the payload.

13. The method as claimed in claim 12, wherein the header is compressed using Static Context Header Compression, SCHC, rules.

14. The method as claimed in any of claims 1-13, wherein the one or more indications are included in one or more Field Identifier, FID, fields of a header of the packet.

15. The method as claimed in any of claims 1-14, wherein the payload indication is a character or value.

16. The method as claimed in any of claims 1-15, wherein the payload indication is the rule indication.

17. The method as claimed in any of claims 1-16, wherein the one or more indications are transmitted to the second node (202) separately from the packet.

18. A method performed by a second node (202) for receiving a payload, the method comprising: receiving (501), from a first node (201), a packet comprising the payload, and one or more indications, wherein the one or more indications comprises one or more of:a compression indication indicating whether or not the payload in the received packet has been compressed; a format indication indicating a data format for data in the payload; a rule indication indicating a compression rule used to compress the payload; and a payload indication indicating where the payload starts in the received packet.

19. The method as claimed in claim 18, wherein the method further comprises: decompressing at least part of the payload according to one or more compression rules.

20. The method as claimed in claim 19, wherein the compression indication indicates that the payload is compressed.

21. The method as claimed in claim 18, wherein the payload is not compressed and the compression indication indicates the payload is not compressed.

22. The method as claimed in any of claims 18-21 , wherein the compression rules are based on Static Context Header Compression, SCHC, rules.

23. The method as claimed in any of claims 18-22, wherein the payload or data in the payload is in any of the data formats: Sensor Measurement Lists, SenML, JavaScript Object Notation, JSON, extensible Markup Language, XML, Concise Binary Object Representation, CBOR, and Efficient XML Interchange, EXI.

24. The method as claimed in any of claims 18-23, wherein the received packet further comprises a header.

25. The method as claimed in claim 24, wherein the one or more indications are comprised in the header.

26. The method as claimed in claim 24 or 25, wherein the header is compressed and the compressed header is received with the payload.

27. The method as claimed in claim 26, wherein the header is compressed using Static Context Header Compression, SCHC, rules.

28. The method as claimed in any of claims 18-27, wherein the one or more indications are included in a Field Identifier, FID, field of a header of the packet.

29. The method as claimed in any of claims 18-28, wherein the payload indication is a character or value.

30. The method as claimed in any of claims 18-28, wherein the payload indication is the rule indication.

31. The method as claimed in any of claims 18-30, wherein the one or more indications are received from the first node (201) separately from the packet.

32. The method as claimed in any of claims 18-31 , wherein the method further comprises: sending one or more compression rules to the first node (201).

33. The method as claimed in any of claims 18-32, wherein the payload is compressed using the compression rules sent to the first node (201).

34. A method performed by a node (201; 203) for analysing a payload, the method comprising: analysing (601) respective payloads of one or more packets to identify parts of the payload that can be compressed; and determining (603) one or more compression rules based on the identified parts.

35. The method of embodiment 35, wherein the method further comprises: sending the determined compression rules to another node (201; 203).

36. The method as claimed in claim 35 or 36, wherein the step of analysing (601) comprises identifying parts common to multiple payloads.

37. The method as claimed in claim 37, wherein the step of determining (603) one or more compression rules comprises determining a compression rule to encode or omit parts that are common to multiple payloads.

38. The method as claimed in any of claims 35-38, wherein the third node is the first node (201) of any of claims 1-17 and the method further comprises the third node performing the method of any of claims 1-17.

39. The method as claimed in any of claims 35-38, wherein the third node is the second node (202) of any of claims 18-33 and the method further comprises the third node performing the method of any of claims 18-33.

40. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-39.

41. A node (201 ; 203) configured to perform the method of any of the claims 1-39.

42. A node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said node is operative to perform the method of any of claims 1-39.

Images