Transmitting and receiving application data using schc

Abstract

According to an aspect, there is provided a method performed by a first node for transmitting first application data to a second node using Static Context Header Compression (SCHC). The first application data is structured data comprising values for a first plurality of application data elements. The first node has a stored set of element groups each identified by a respective SCHC rule identifier, and element groups are for use in compressing application data. The method comprises identifying (401) a first element group in the set of element groups based on a structure of the first application data; compressing (403) the first application data according to the first element group to generate a compression residue for the first application data; and transmitting (405) a packet to the second node, wherein the packet comprises the compression residue and the SCHC rule identifier for the first element group.

Description

[0001] TRANSMITTING AND RECEIVING APPLICATION DATA USING SCHC

[0002] Technical Field

[0003] This disclosure relates to a method performed by a first node for transmitting first application data to a second node using Static Context Header Compression (SCHC), a method performed by a second node for receiving first application data from a first node using SCHC, a corresponding computer program product, and corresponding nodes.

[0004] Background

[0005] Header compression is used in communication networks to improve efficiency of data transfer by means of compressing header information. 3rd Generation Partnership Project (3GPP) networks have traditionally used Robust Header Compression (RoHC), which is defined in Request for Comments (RFC) 3085 by the Internet Engineering Task Force (IETF). More recently a simpler standard suitable also for constrained devices and networks, Static Context Header Compression (SCHC) has been standardised at the IETF in RFC 8724.

[0006] SCHC is a protocol for compressing and fragmenting Internet packets over Low-Power Wide Area Networks (LPWANs). SCHC provides a mechanism for compressing protocol headers and transmitting them over LPWANs. It does this by defining a context that is shared between the sender and receiver. The context consists of a set of rules that can be applied for compression and decompression. 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] SCHC has profiles for different protocols beyond Internet Protocol (IP) and User Datagram Protocol (UDP), such as SCHC for Constrained Application Protocol (CoAP) (defined in RFC 8824).

[0008] SCHC compression is based on knowledge of relatively static data in the headers that can be elided (omitted) from the transmission by referring to a rule, with a Rule ID, that contains this information. The information can be in the rule of the context directly, or it can be obtained from another context, such as lower protocol layers. Only the information that is not static or that cannot be inferred is transmitted, in addition to the Rule ID, as “compression residue”.

[0009] Fig. 1 shows the structure of a SCHC packet 100. Application 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.

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

[0011] Sensor Measurement Lists (SenML) is a format defined in RFC 8428 by the IETF. SenML provides a data format for representing simple sensor measurements, device parameters, and metadata. SenML can used by devices for expressing time-series data in a manner that is suitable for constrained devices and networks, but can also be efficiently used by highly scalable data processing system. SenML has multiple serialisation formats, including text-based JavaScript Object Notation (JSON), binary Concise Binary Object Representation (CBOR) and Efficient extensible Markup Language (XML) Interchange (EXI) data formats.

[0012] SenML is designed to be extendable and maintains a specification and registry at the IETF for units of measurement and SenML labels.

[0013] The SenML RFC 8428 defines several terms that are relevant to this disclosure:

[0014] SenML Record: One measurement or configuration instance in time presented using the SenML data model.

[0015] SenML Pack: One or more SenML Records in an array structure.

[0016] SenSML: Sensor Streaming Measurement List.

[0017] SenSML Stream: One or more SenML Records to be processed as a stream.

[0018] As an example, the following data payload has one SenML Pack (contained within square brackets, [...]) and two SenML Records (contained within curly brackets, {...}):

[0019] Listing 1 : Example SenML payload with one SenML Pack and two SenML records

[0020] SenML includes a "base value" mechanism that enables the expression of a value for the name, time, or numeric data, that is used as a "base", and the following records with name / time / value only need to express the delta to the base value, thus saving bits during transmission since the delta is commonly much smaller / shorter value than the full value and can accordingly be encoded with fewer bits.

[0021] Summary

[0022] While SenML format is designed for constrained networks, it can be too verbose for the extremely constrained networks such as the Zero Energy / Am bient Internet of Things (loT) systems envisioned for 6th Generation (6G) 3GPP networks or certain LPWANs, such as Long Range Wide Area Network (LoRAWAN), when the smallest frame sizes are used. Other data formats based on the structure of JSON have similar challenges.

[0023] As noted above, SCHC can compress protocol headers, but with the current set of compression rules it is not well suited for compressing application data in the payload, such as SenML. Instead, the application data in the payload is sent uncompressed.

[0024] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. In particular, this disclosure provides new SCHC processing rules and encoding extensions that enable the encoding of SenML application data, or application data in other data formats with typically similar time series characteristics, efficiently with static rules. The extensions are designed in such way that they make the rules compact and apply generically to different variations of how the application data is organised.

[0025] Embodiments of the new SCHC Rules can use a template language that supports efficient encoding of time-series data. Embodiments of the template language use “repeat”, “relative value”, “relative time”, and “field length”, commands and data structure syntax aware compression / decompression to enable compact and re-usable rules. Embodiments relating to SenML application data can take advantage of SenML data format awareness to generalise rules further by operating on resolved records for both template and data. A template can comprise SenML fields, such as any of names, metadata (e.g., measurement unit) related to each Record, SenML value type, and base values, and placeholders indicating a field (or part of a field) that has a value that is variable. The SenML matching rule compression residue contains the values associated with values of the fields that are variable.

[0026] Thus, instead of handling fields one by one as is common with SCHC rules, embodiments of the new SenML rules take advantage of the common repetitive nature of the sensor measurement data and efficiently encodes, using template language repetition features, the values associated with each Record in the compression residue.

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

[0028] For example, the proposed techniques allow for enhanced compression of time series sensor data (e.g., SenML) and is suitable also for extremely constrained networks.

[0029] The techniques allow the possibility to reconstruct the structure of the data (e.g., recreating a SenML data format or JSON payload) without having to send the structure each time in the payload. This allows efficient communication in constrained networks and “normal” operation after decompression.

[0030] The techniques further reduce the size of the payload, and embodiments allow compressors to use relative values in the compression residue (since a template can allow the base or relative values to be specified in the template). The techniques also account for cases where such values may change. In conventional header compression techniques, the SCHC rules would need to be updated each time the relative value changes. However, embodiments of the disclosed techniques provide that an update of the values is not always needed.

[0031] For data formats where each record contains an identifier, data value, and optionally metadata (e.g., SenML), a simplified version of templates can be used. A new SCHC matching operator (referred to herein as “equal-list”) is used to match a sequence of identifiers (and potentially metadata) in the records, and, for matching records only, it is used to send the data values as compression residue along with an identifier (ID) of the rule with the matching sequence of identifiers. The equal-list operation described herein allows for easy rule matching of multiple values, as opposed to having each field value in the “normal” SCHC.

[0032] The techniques also address cases where ordering is not important (e.g., in the case of SenML). The techniques allow for concatenating all values to be sent into a single compression residue.

[0033] According to a first aspect, there is provided a method performed by a first node for transmitting first application data to a second node using SCHC. The first application data is structured data comprising values for a first plurality of application data elements. The first node has a stored set of element groups each identified by a respective SCHC rule identifier, and element groups are for use in compressing application data. The method comprises identifying a first element group in the set of element groups based on a structure of the first application data. The method further comprises compressing the first application data according to the first element group to generate a compression residue for the first application data. The method further comprises transmitting a packet to the second node. The packet comprises the compression residue and the SCHC rule identifier for the first element group.

[0034] According to a second aspect, there is provided a method performed by a second node for receiving first application data from a first node using SCHC. The first application data is structured data comprising values for a first plurality of application data elements. The second node has a stored set of element groups each identified by a respective SCHC rule identifier, and element groups are for use in decompressing application data. The method comprises receiving a packet from the first node. The received packet comprises a compression residue and a SCHC rule identifier. The method further comprises identifying a first element group in the stored set of element groups using the SCHC rule identifier. The method further comprises decompressing the compression residue according to the first element group to generate the first application data.

[0035] According to a third 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, or any embodiments thereof.

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

[0037] According to a fifth 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, or any embodiments thereof.

[0038] Brief Description of the Drawings

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

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

[0041] Fig. 2 shows conventional signalling between a client and server;

[0042] Fig. 3 shows how rules in SCHC are described using a Compression / Decompression Context;

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

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

[0045] Fig. 6 is a block diagram of a node according to some embodiments of the invention.

[0046] Detailed Description

[0047] Some of the embodiments of the invention 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.

[0048] 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”, and can be a user equipment (UE) as defined in one or more 3GPP standards or a constrained device, e.g., a temperature sensor, a humidity sensor, etc. 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. The sensing update / sensor updates 203 is more generally referred to herein as “application data”.

[0049] The techniques described herein provide that the application data at a first node 201 is compressed, with the compression residue of the application data being included in a SCHC packet, along with a SCHC rule identifier that identifies the rule used to compress the application data. The application data can have any of the following data formats JSON, XML, CBOR, and EXI.

[0050] The application data is structured data that comprises values for a plurality of application data elements. The application data can be in SenML format, and each application data element can be a SenML Record corresponding to one measurement (e.g., a temperature measurement or a humidity measurement) or configuration instance. A value of an application data element in the first application data can be a measurement or configuration instance for a respective SenML Record (for example a value can be measured temperature value, or a measured humidity value).

[0051] The rules that can be used to compress the application data are in the form of, or are based on, element groups that are each identified by a respective SCHC rule identifier. Each element group relates to a respective combination of application data elements. The set of element groups can form a SCHC Context. The element groups may have a SCHC Field Identifier (Fl) indicating that the element group is for compression and / or decompression of application data.

[0052] The structure of the application data is determined or identified, and the structure of the application data is used to select a suitable element group in the set of element groups. In embodiments, the structure of the application data relates to a structure of the application data elements in the application data. The selected element group can be an element group that has application data elements corresponding to the application data elements in the first application data.

[0053] The application data is compressed according to the selected element group to generate a compression residue for the application data. Then, a SCHC packet is transmitted to the second node 202, with the packet comprising the compression residue and the SCHC rule identifier for the element group used to compress the application data. The header of the SCHC packet can also be compressed using SCHC in the usual manner.

[0054] In some embodiments, the compression residue comprises, or is, the values for the application data elements in the application data. In other embodiments, the compression residue comprises values that are determined as a difference between a relative value indication for one or more application data elements and the values for the application data elements in the application data.

[0055] At the second node 202, the SCHC rule identifier is used to determine the element group that was used to generate the compression residue, and the compression residue is decompressed using that element group to recover the original application data.

[0056] Template-based approach: This section presents a template-based approach for defining the rules for SCHC Compression / Decompression. Thus, in these embodiments, each element group is a template. This template approach can be applied to various structured data formats, such as JSON and CBOR. SenML is used here as example application data to provide examples. The examples use JSON representation, but CBOR representation can be used to achieve a smaller template (and hence rule) size in practice.

[0057] Case 1 : Fixed number of SenML Records

[0058] In the following example, an entity with SenML base name “dev1.example.com / ” sends two values periodically - one a temperature value (“temp” with value 20) and the second a humidity value (“hum” with value 40). It encodes the values in one SenML Pack (the application data) consisting of two SenML Records (i.e., two application data elements):

[0059] Listing 2: Example application data before compression

[0060] The template for the compression-decompression rule can then be as follows:

[0061] Listing 3: Template-based rule for the example in Listing 2 It will be noted that the variable values are replaced with $n placeholders where “n” represents the position of the field value in the resulting compression residue.

[0062] In this case, upon applying the rule to the application data in Listing 2, the compression residue will include exactly two values (20 and 40). The result of the decompression using the template rule in Listing 3 will be is exactly one SenML Pack with two SenML records.

[0063] The compression gain achieved in compressing the application data from Listing 2 using the template in Listing 3 is a reduction from the original size of 73 bytes to 2-4 bytes (2 bytes when the values are 8-bit unsigned integers and 4 bytes when the values are 16-bit unsigned integers).

[0064] Case 2: Varying number of compression residue values

[0065] In this example, the application data may include multiple temperature and multiple humidity values, and the number of such measurements may not be known in advance. Further, the measurements may be performed at different times, but they are to be sent to the second node 202 together in one payload.

[0066] The following is an example of application data with multiple temperature and humidity measurements.

[0067] Listing 4: Example uncompressed application data with multiple measurements

[0068] The template for the compression-decompression rule for this type of application data can be as follows:

[0069] Listing 5: Template-based rule for the application data example in Listing 4

[0070] In Listing 5, the “$repeat()” command means that the two records for the “temp” and “hum” measurements are repeated, and the first record (with the “temp” value) contains a time value (base time: “bt”) that applies to both records. A value for “bt” in SenML applies to the following Records until the next “bt” value. If a Record does not contain a time value, it is assumed to be zero, and hence the same as the base time. The compression residue can contain a list of triplets with the measurement values for both, followed by the time stamp (i.e. , the compression residue can be “$1, $2, $3”). On the decompression side, the two records are repeated in the decompressed version as many times as there are triplets in the compression residue. For example, if the compression residue contains three values, the decompressed application data will include one SenML Pack with two SenML records. However, if the compression residue contains six values, the decompressed application data will include one SenML Pack with four SenML Records, and so on.

[0071] The “$repeat()” command and the decompressor (at / in the second node 202) are aware of the syntax of the enclosing data format, and hence can generate valid JSON, e.g., by adding the commas between records, or valid CBOR / EXI with proper record delimiters, etc., instead of simply repeating the template string given as the parameter.

[0072] It should be noted that the template mechanism from Case 1 can be used in the example of Listing 4 instead of the “$repeat()” command by repeating the two records twice in the template. However, by using the “$repeat()” command, the size of the rule becomes smaller and allows for multiple sets of values to be sent, which is especially useful if the number of measurements or configuration parameters can vary or is not known a priori.

[0073] The compressor (at / in the first node 201) is required to follow the ordering of $n semantics when sending the residual values. For example, switching the position of the temperature and humidity values would lead to inconsistent decompression. In other words, the residual value $1 should precede the residual value $2. In most cases, the ordering of the measurements in the compression residue is controllable by the compressor since the semantics are known by the application developers at the time of developing the application. However, if this is not known, the device behaviour can be derived through observation and rules with appropriate templates can be determined based on the observed data. In scenarios where the ordering cannot be controlled, it is still possible to achieve compression, although it will require multiple rules with one rule for each ordering to be defined.

[0074] Additional operations for improved compression: This section considers ways to further improve the efficiency of the compression. In particular, the use of absolute timestamps (since epoch) or absolute measurement values may be undesirable, and relative timestamps and / or values might be preferable. To achieve this, the epoch value or base measurement value needs to be established. The following provides three different mechanisms through which the epoch / base values can be defined in the template. Case 3: Base value defined in the template

[0075] In this case, the base value is defined in the template with a “relValue” keyword in the placeholder. Using the example from Listing 4, the template can be updated to:

[0076] Listing 6: Base values defined in the template

[0077] Based on the above template, the compression residue values would be relative to the values specified in the template (i.e., 20, 1696231409, 40, respectively). Continuing the example from Listing 4, the compression residue would then have the following field values: 0, 0, 0, 1 , 2, 4. In this way, the number of bits transmitted can be substantially reduced since small numbers can be represented with a smaller number of bits than large values. For example, the set of values in this example can be represented with 4 bits each with an unsigned integer representation, whereas the original values range from 4 bits (for values under 32) to 8 bits (for values under 255). The gain is much larger in the case of the timestamps in the example of Listing 4 as the time values can be encoded in 4 to 16 bits (up to 65535) instead of the 32 to 64 bits required originally (when using double floating point precision).

[0078] In an alternative approach to using the “relValue” keyword, the “relValue” can be applied to string values when the “relValue” in the template is a prefix to the value that is in the compression residue. In this way, during decompression the relValue prefix and value in the compression residue are concatenated to recover the original value.

[0079] Case 4: Look-up from external resource

[0080] In Case 3, the relative values are static. If the relative values change, the rule will need to be updated. This may be undesirable if the relative value changes often (‘often’ may be subjective, i.e., depending on the circumstances often could mean every hour, every day, every month, etc.). In such cases, it may instead be desirable to look up the relative value from an external resource. This look-up can be performed periodically, when application data is to be sent to the second node 202, or every X transmissions of application data.

[0081] A “relValueExternal” keyword can be defined which includes a Uniform Resource Locator (URL) to the external resource along with a periodicity of how often to look up and update the value. As an example: relValueExternal:[https: / / externalUrl.com / relValue, 60s],

[0082] In the above example, the compressor looks up the external resource every time the 60- second timer expires. The time field can be expressed in any suitable time unit, e.g., seconds, minutes, hours, days, weeks, months, or years.

[0083] The URL can also point to a resource on the first / second node itself to avoid external lookups. A protocol outside of the SCHC framework would be then used to update the resource.

[0084] Case 5: Base value based on common indicators

[0085] In some cases, a shared context can be established without specifying exact relative values. This can be used, for example, for timestamps, and / or can make use of environmental knowledge.

[0086] In the case of timestamps, a relTime:x attribute can be used, where ‘x’ can be “m” (minute), “h” (hour), “d” (day), “M” (month) and “Y” (year). Hence, without specifying an absolute value, the compressor can send the time relative to the “top of” the minute, hour, day, month, or year. In this way, the rules do not need to be updated, and a look up does not need to be performed.

[0087] In some cases, the shared context can be established through environmental conditions. For example, in the case of temperature and humidity, the base values for these measurements can be defined differently for different environmental conditions. For example, the base value in summer for temperature can be 20, and 60 for humidity, whereas in winter the base value for temperature can be 0, and 10 for humidity. Such context can be established outside the SCHC template, but can be expressed in the template using the notation relContext:x where ‘x’ is an identifier for the shared context. For example, ‘x’ could be “season” using the above example. When the switch occurs between summer and winter is context specific and not expressed in the template.

[0088] Variable-length and fixed-length residue values: The SCHC RFC describes mechanisms for handling both fixed and variable length residue fields in the header. Fixed length fields are specified in the Field Length (FL) field of the rule, whereas the varying length fields are specified such that the compression residue includes the field length and the value.

[0089] Embodiments of the technigues described herein can use variable-length fields for the values, and as such the field length usually needs to be indicated within the compression residue. However, it may be undesirable to include the field length for static cases. Hence a fl:x template convention is proposed, e.g., $1 (fl: 16) which indicates that the length of the $1 value is always 16 bits. Hence, compression of variable length values is supported without indicating length in the residue. The special case of all fields using the same length can be handled by indicating that length in the FL field.

[0090] Mapping the template-approach to the SCHC C / D Context: Rules in SCHC are described using the Compression / Decompression (C / D) Context using the format (and terminology) shown in Fig. 3. The SCHC C / D Context shown in Fig. 3 corresponds to Figure 6 in RFC 8724.

[0091] This section describes the content of the C / D context when using the template-based approach.

[0092] Field ID (FID): A new Field ID called “StructuredAppData” or similar is introduced to indicate that the compression / decompression is being performed on the application data / payload.

[0093] Field Length (FL): If all compression residue values are of same length (e.g., 4 bits), then the FL field contains the bit length. Otherwise, this field can contain value 0 indicating that variable-length values are used in the compression residue.

[0094] Field Position (FP): this can be set to 1 (default).

[0095] Direction Indicator (DI): This can be set as per the current SCHC specification, i.e. , it can be Up (uplink / upward), Dw (downlink / downward), or Bi (both). However, given that the techniques described herein apply primarily to application data, the expected value is typically likely to be “Up”.

[0096] Target Value (TV): The Target Value is where the template itself is defined.

[0097] Matching Operator (MO): A new MO called “template” is introduced to indicate that the compressor / decompressor should follow template based matching operations.

[0098] Compression / Decompression Action: A new action called “template” is introduced. The compressor sends all the values (as described in examples above) and the decompressor reconstructs the original payload but replacing the “$x” placeholders (and expanding the other operations such as $repeat, etc.).

[0099] Full Example: In this section, it is assumed that a first node 201 is to send two measurement values in one SCHC packet. The values are assumed to be of varying length. Listing 2 above is used as the basis for this example.

[0100] First, the SCHC C / D rule on the compressor / decompressor will be as shown in Table 1 below:

[0101] Table 1

[0102] On the compressor side, when a node wants to send the two residual values, the SCHC packet can be as shown below (which is based on a combination of Figure 4, Figure 7, and Figure 9, of RFC 8724):

[0103] On the decompressor side, once the above SCHC packet is received, the decompressor can simply replace the $n fields in the template with the appropriate values. The result is the application data as shown in Listing 2.

[0104] Equal-list operation: When the above template-based approach is too complex to implement or use, new and simpler SenML-specific rules can be implemented instead. For a single SenML Record (application data element), it is sufficient to use the existing SCHC Matching Operators and Compression / Decompression Actions, combined with an understanding of SenML structure in compressor and decompressor. The SenML Name and Unit can be part of the rule, Value will be sent as compression residue, and Time can be either part of the rule (e.g., if the time is always “now”) or also sent as compression residue.

[0105] Table 2 below shows an example SenML compression rule for a SenML Pack with a single SenML Record: Table 2

[0106] When a varying number of SenML Records are sent in a SenML Pack, it quickly becomes very inefficient to have specific rules for each potential combination of SenML Records (i.e., for each potential combination of application data elements). Instead, a new Matching Operator (MO) “equal-list”, and a new Compression / Decompression Action (ODA) “send-list” can be introduced. The “equal-list” Target Value contains a list of values that are matched in sequence to the values found in the SenML Records. The “equal-list” MO is used to match a sequence of identifiers (and potentially metadata) in the Records, and, for matching Records only, it is used to send the data values as compression residue along with an identifier (ID) of the rule with the matching sequence of identifiers.

[0107] That is, the “SenML Names” field contains, in order, the names found in all the SenML Records (the first value is from the first SenML record, the second value is from the second SenML record, etc.). The “send-list” ODA includes in the compression residue a list of values in the same order they are found in the SenML Records.

[0108] For example, the SenML Pack shown in Listing 7 below, can be compressed using the rule in Table 3 below into a compression residue containing only four sensor values and four time values:

[0109] Listing 7 Table 3

[0110] The compressor / decompressor in this case understands SenML semantics, so it can match names, units, and values, to the rule, independently of whether base names, values, and units, are used.

[0111] For example, the SenML Pack in Listing 8 below can be compressed using the same rule in Table 3 above.

[0112] Listing 8

[0113] In this example, no base names or times are used, but all SenML Records contain a full name and (relative) time. Nevertheless, the same rule can be applied since the resolved version of the names matches the rule.

[0114] Combining l-list : While the template and equal-list mechanisms are described separately above, they can be combined also together to achieve higher efficiency and agility with the rules.

[0115] In particular, the understanding of SenML semantics can be applied to the template approach so that the exact way in which base values are used in the uncompressed data does not matter. For example, the compression and templates could use resolved SenML Records for matching / compression even if, for efficiency, the rules and data used base values. Resolved SenML Records are described in Section 4.6 of RFC 8428.

[0116] Re-orderinq of records In some cases, the order of the Records in the SenML Pack may be difficult to predict, or otherwise inconsistent, and hence having a rule with a template, or equallist values in the right order, requires many rules, one for each possible permutation of Records. This can be avoided if the Records can be reordered to match the rule. In general, this is acceptable for SenML data, as each Record can be handled individually, independent of the Records before or after when base values are resolved. In addition, the standard resolved form suggests performing the reordering chronologically, based on the time field value. However, to minimise the number of rules needed, further consistency in ordering is required for Records that have the same time field value.

[0117] In addition to ordering by time, the Records with the same time value can be ordered consistently using the other SenML fields by: taking a concatenation of each field name and value, ordering each field alphabetically in the Record, concatenating the result and performing string comparison (e.g., using the standard C strcmp() function) for each concatenated value, and ordering the Records in the Pack accordingly.

[0118] For example, for the SenML Pack in Listing 9 below, the two Records have the same time value and hence can be in any of the two possible orders while having the same semantics.

[0119] Listing 9

[0120] To have a consistent order for the SenML Pack in Listing 9, the fields other than time would be treated as follows: concatenating fields in the first SenML record results in three elements: “ndev1.example.com / temp”, “v20”, and “uCel”; ordering the three elements alphabetically and concatenating again results in string: “ndevl . example. com / tempuCelv20”; and comparing that to the second SenML Record's fields after the same process (“ndevl . example. com / humuRH%v40”) results in the second SenML Record moving to be the first SenML Record since the first character that differs (“h” in “hum” vs. “t” in “temp”) has a lower ASCII value in the second SenML Record.

[0121] 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, a constrained 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.

[0122] The first node performs the method in Fig. 4 to transmit first application data to a second node using SCHC. The second node can be a server 202. The first application data is structured data comprising values for a first plurality of application data elements. The first node has a stored set of element groups each identified by a respective SCHC rule identifier, and element groups are for use in compressing application data.

[0123] The set of element groups can form, or be, a SCHC Context. One or more of the element groups may have a SCHC Field Identifier indicating that the element group is for compression and / or decompression of application data. Each element group can relate to a respective combination of application data elements. The application data elements in each element group may be ordered.

[0124] The data format of the first application data can be any of: JSON, XML, CBOR, and EXI.

[0125] Step 401 of Fig. 4 comprises the first node identifying a first element group in the set of element groups based on a structure of the first application data. The structure of the first application data may relate to a structure of the first plurality of application data elements in the first application data, and the first element group is an element group having application data elements corresponding to the first plurality of application data elements in the first application data.

[0126] In step 403, the first node compresses the first application data according to the first element group to generate a compression residue for the first application data.

[0127] The compression residue can comprise the values for the plurality of application data elements in the first application data. In some embodiments, values in the compression residue are determined as a difference between a relative value indication for one or more application data elements and the values for the first plurality of application data elements in the first application data. This relative value indication can be defined in the first element group, obtained by the first node from another node (i.e. , an external resource), or determined according to a time and / or environmental context of the first application data.

[0128] One or more of the application data elements may have a variable field length, and in this case, the compression residue generated in step 403 for an application data element having a variable field length can comprises the value, and a field length indication indicating the field length.

[0129] In embodiments where the application data elements in each element group are ordered, the compression residue generated in step 403 can comprise the values for the plurality of application data elements in the first application data, with the order of those values in the compression residue corresponding to the order the application data elements occur in the first element group.

[0130] If the application data elements in the first element group are in a different order to the application data elements in the first application data, then step 403 can further comprise reordering the application data elements in the first application data to correspond to the order of application data elements in the first element group. In these embodiments, the first application data is preferably in a data format for which the order of two or more of the application data elements in the first application data does not affect the semantic meaning of the first application data. As a result, the order of the application data elements can be changed without affecting the semantic meaning of the first application data.

[0131] In step 405, the first node transmits a packet to the second node. The packet comprises the compression residue and the SCHC rule identifier for the first element group. The transmitted packet can also comprise a header that is compressed using SCHC.

[0132] The first application data can be in SenML format, and each application data element can be a SenML Record corresponding to one measurement or configuration instance. In these embodiments, each value in the first application data can be a measurement or configuration instance for a respective SenML Record.

[0133] In particular embodiments, each element group is a template. A template can comprise one or more SenML fields. A template defines structure and content of one of JSON data, XML data, CBOR data, and EXI data.

[0134] The first element group can relate to a respective combination of application data elements, and the first element group can comprise a repeat indication that indicates one or more application data elements are repeated. In this case, the compression residue generated in step 403 can comprise the values for the one or more repeated application data elements.

[0135] 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, etc. 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.

[0136] The second node performs the method in Fig. 5 to receive first application data from a first node using SCHC. The first node can be client 201 , e.g., a UE, an loT device, a constrained device, etc. The first application data is structured data comprising values for a first plurality of application data elements. The second node has a stored set of element groups each identified by a respective SCHC rule identifier, and element groups are for use in decompressing application data.

[0137] The set of element groups can form, or be, a SCHC Context. One or more of the element groups may have a SCHC Field Identifier indicating that the element group is for compression and / or decompression of application data. Each element group can relate to a respective combination of application data elements. The application data elements in each element group may be ordered.

[0138] The data format of the first application data can be any of: JSON, XML, CBOR, and EXI.

[0139] In step 501 , the second node receives a packet from the first node. The packet comprises a compression residue and a SCHC rule identifier. The received packet can also comprise a header that is compressed using SCHC.

[0140] In step 503, the second node identifies a first element group in the stored set of element groups using the SCHC rule identifier.

[0141] The structure of the first application data may relate to a structure of the first plurality of application data elements in the first application data, and the first element group will be an element group having application data elements corresponding to the first plurality of application data elements in the first application data.

[0142] In step 505, the second node decompresses the compression residue according to the first element group to generate the first application data.

[0143] The compression residue can comprise the values for the plurality of application data elements in the first application data. In some embodiments, values in the compression residue were determined by the first node as the difference between a relative value indication for one or more application data elements and the values for the first plurality of application data elements in the original (uncompressed) first application data. Thus, in step 505, the second node can use the relative value indication and the values in the compression residue to recover the original values in the first application data. The relative value indication can be defined in the first element group; obtained by the second node from another node (i.e. , an external resource); or determined according to a time and / or environmental context of the first application data.

[0144] One or more of the application data elements may have a variable field length, and in this case, the compression residue received in step 501 for an application data element can comprise a value, and a field length indication indicating the field length, which indicates to the second node that the application data element has a variable field length.

[0145] In embodiments where the application data elements in each element group are ordered, the compression residue received in step 501 can comprise the values for the plurality of application data elements in the first application data, with the order of those values in the compression residue corresponding to the order the application data elements occur in the first element group.

[0146] The first application data may be in a data format for which the order of two or more of the application data elements in the first application data does not affect the semantic meaning of the first application data. As a result, the order of the application data elements can be changed without affecting the semantic meaning of the first application data. The first application data can be in SenML format, and each application data element can be a SenML Record corresponding to one measurement or configuration instance. In these embodiments, each value in the first application data can be a measurement or configuration instance for a respective SenML Record.

[0147] In particular embodiments, each element group is a template. A template can comprise one or more SenML fields. A template defines structure and content of one of JSON data, XML data, CBOR data, and EXI data.

[0148] The first element group can relate to a respective combination of application data elements, and the first element group can comprise a repeat indication that indicates one or more application data elements are repeated. In this case, the first application data generated in step 505 can comprise one or more repeated application data elements, and the values from the received compression residue.

[0149] Fig. 6 is a simplified block diagram of an apparatus 600 that can be used to implement, or implement part of, one or more of the nodes described herein. The apparatus 600 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 600 can be configured or adapted to perform the method in any one or more of Figs. 4 or 5.

[0150] The apparatus 600 comprises processing circuitry (or logic) 601 . It will be appreciated that the apparatus 600 may comprise one or more virtual machines running different software and / or processes. The apparatus 600 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.

[0151] The processing circuitry 601 controls the operation of the apparatus 600 to implement any of the methods described herein. The processing circuitry 601 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the apparatus 600 in the manner described herein. In particular implementations, the processing circuitry 601 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 600.

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

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

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

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

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

[0157] 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 first application data to a second node (202) using Static Context Header Compression, SCHC, wherein the first application data is structured data comprising values for a first plurality of application data elements, wherein the first node (201) has a stored set of element groups each identified by a respective SCHC rule identifier, and wherein element groups are for use in compressing application data, the method comprising: identifying (401) a first element group in the set of element groups based on a structure of the first application data; compressing (403) the first application data according to the first element group to generate a compression residue for the first application data; and transmitting (405) a packet to the second node (202), wherein the packet comprises the compression residue and the SCHC rule identifier for the first element group.

2. The method as claimed in claim 1 , wherein the structure of the first application data relates to a structure of the first plurality of application data elements in the first application data.

3. The method as claimed in claim 2, wherein the first element group is an element group having application data elements corresponding to the first plurality of application data elements in the first application data.

4. The method as claimed in any of claims 1-3, wherein each element group relates to a respective combination of application data elements.

5. The method as claimed in any of claims 1-4, wherein the application data elements in each element group are ordered.

6. The method as claimed in claim 5, wherein the compression residue comprises the values for the plurality of application data elements in the first application data, and wherein the order of the values in the compression residue corresponds to the order of the application data elements in the first element group.

7. The method as claimed in claim 5 or 6, wherein the application data elements in the first element group are in a different order to the application data elements in the first application data,and wherein the step of compressing (403) further comprises reordering the application data elements in the first application data to correspond to the order of application data elements in the first element group.

8. The method as claimed in any of claims 1-7, wherein the first application data is in a data format for which the order of two or more of the application data elements in the first application data does not affect the semantic meaning of the first application data.

9. The method as claimed in any of claims 1-8, wherein a data format of the first application data is any of: 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 first application data is in Sensor Measurement Lists, SenML, format, and wherein each application data element is a SenML Record corresponding to one measurement or configuration instance.

11. The method as claimed in claim 10, wherein each value in the first application data is a measurement or configuration instance for a respective SenML Record.

12. The method as claimed in any of claims 1-11 , wherein each element group is a template.

13. The method as claimed in claim 12, wherein a template comprises one or more Sensor Measurement Lists, SenML, fields.

14. The method as claimed in claim 12, wherein each template defines structure and content of one of: JavaScript Object Notation, JSON data; extensible Markup Language, XML, data; Concise Binary Object Representation, CBOR, data; and Efficient XML Interchange, EXI data.

15. The method as claimed in any of claims 1-14, wherein the first element group is a first template, wherein the application data elements in the template are in a different order to the application data elements in the first application data, and wherein the step of compressing (403) further comprises reordering the application data elements in the first application data to correspond to the order of application data elements in the first template.

16. The method as claimed in any of claims 1-15, wherein the first element group relates to a respective combination of application data elements, and the first element group comprises a repeat indication that indicates one or more application data elements are repeated.

17. The method as claimed in claim 16, wherein the compression residue comprises the values for the one or more repeated application data elements.

18. The method as claimed in any of claims 1-17, wherein the compression residue comprises the values for the plurality of application data elements in the first application data.

19. The method as claimed in any of claims 1-18, wherein values in the compression residue are determined as a difference between a relative value indication for one or more application data elements and the values for the first plurality of application data elements in the first application data.

20. The method as claimed in claim 19, wherein the relative value indication is:(i) defined in the first element group;(ii) obtained by the first node from another node; or(iii) determined according to a time and / or environmental context of the first application data.21 . The method as claimed in any of claims 1-20, wherein one or more of the application data elements have a variable field length, and wherein the compression residue for an application data element having a variable field length comprises (i) the value, and (ii) a field length indication indicating the field length.

22. The method as claimed in any of claims 1-21 , wherein the set of element groups form a SCHC Context.

23. The method as claimed in any of claims 1-22, wherein the element groups have a SCHC Field Identifier indicating that the element group is for compression and / or decompression of application data.

24. The method as claimed in any of claims 1-23, wherein the transmitted packet comprises a header compressed using SCHC.

25. A method performed by a second node (202) for receiving first application data from a first node (201) using Static Context Header Compression, SCHC, wherein the first application data is structured data comprising values for a first plurality of application data elements, wherein the second node (202) has a stored set of element groups each identified by a respective SCHC rule identifier, and wherein element groups are for use in decompressing application data, the method comprising: receiving (501) a packet from the first node (201), wherein the packet comprises a compression residue and a SCHC rule identifier; identifying (503) a first element group in the stored set of element groups using the SCHC rule identifier; and decompressing (505) the compression residue according to the first element group to generate the first application data.

26. The method as claimed in claim 25, wherein the structure of the first application data relates to a structure of the first plurality of application data elements in the first application data.

27. The method as claimed in claim 26, wherein the first element group is an element group having application data elements corresponding to the first plurality of application data elements in the first application data.

28. The method as claimed in any of claims 25-27, wherein each element group relates to a respective combination of application data elements.

29. The method as claimed in any of claims 25-28, wherein the application data elements in each element group are ordered.

30. The method as claimed in claim 29, wherein the compression residue comprises the values for the plurality of application data elements in the first application data, and wherein the order of the values in the compression residue corresponds to the order of the application data elements in the first element group.31 . The method as claimed in any of claims 25-30, wherein the first application data is in a data format for which the order of two or more of the application data elements in the first application data does not affect the semantic meaning of the first application data.

32. The method as claimed in any of claims 25-31 , wherein a data format of the first application data is any of: JavaScript Object Notation, JSON, extensible Markup Language, XML, Concise Binary Object Representation, CBOR, and Efficient XML Interchange, EXI.

33. The method as claimed in any of claims 25-32, wherein the first application data is in Sensor Measurement Lists, SenML, format, and wherein each application data element is a SenML Record corresponding to one measurement or configuration instance.

34. The method as claimed in claim 33, wherein each value in the first application data is a measurement or configuration instance for a respective SenML Record.

35. The method as claimed in any of claims 25-34, wherein each element group is a template.

36. The method as claimed in claim 35, wherein a template comprises one or more Sensor Measurement Lists, SenML, fields.

37. The method as claimed in claim 35, wherein each template defines structure and content of one of: JavaScript Object Notation, JSON data; extensible Markup Language, XML, data; Concise Binary Object Representation, CBOR, data; and Efficient XML Interchange, EXI data.

38. The method as claimed in any of claims 25-37, wherein the first element group relates to a respective combination of application data elements, and the first element group comprises a repeat indication that indicates one or more application data elements are repeated.

39. The method as claimed in claim 38, wherein the compression residue comprises the values for the one or more repeated application data elements.

40. The method as claimed in any of claims 25-39, wherein the compression residue comprises the values for the plurality of application data elements in the first application data.41 . The method as claimed in any of claims 25-40, wherein values in the compression residue are a difference between a relative value indication for one or more application data elements and the values for the first plurality of application data elements in the first application data.

42. The method as claimed in claim 41 , wherein the step of decompressing (505) comprises determining the values for the first plurality of application data elements in the first application data from the relative value indications and the values in the compression residue.

43. The method as claimed in claim 41 or 42, wherein the relative value indication is:(i) defined in the first element group;(ii) obtained by the second node from another node; or(iii) determined according to a time and / or environmental context of the first application data.

44. The method as claimed in any of claims 25-43, wherein one or more of the application data elements have a variable field length, and wherein the compression residue for an application data element having a variable field length comprises (i) the value, and (ii) a field length indication indicating the field length.

45. The method as claimed in any of claims 25-44, wherein the set of element groups form a SCHC Context.

46. The method as claimed in any of claims 25-45, wherein the element groups have a SCHC Field Identifier indicating that the element group is for compression and / or decompression of application data.

47. The method as claimed in any of claims 25-46, wherein the received packet comprises a header compressed using SCHC.

48. 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-47.

49. A node (600) configured to perform the method of any of claims 1-47.

50. 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-47.

Images