COAP endpoint and method thereof

Abstract

According to an aspect, there is provided a method performed by a first node. The first node is operating as a first Constrained Application Protocol, CoAP, endpoint. The method comprises negotiating (701), with a second node operating as a second CoAP endpoint, use of Static Context Header Compression, SCHC, for compressing packets transmitted between the first node and second node. The negotiation (701) comprises exchanging a support label that indicates a protocol or layer in a protocol stack of the first node and / or second node that SCHC can be applied to.

Description

[0001] CoAP ENDPOINT AND METHOD THEREOF

[0002] Technical Field

[0003] This disclosure relates to a method performed by a first node operating as a first Constrained Application Protocol (CoAP) endpoint, a corresponding computer program product, and corresponding first nodes.

[0004] Background

[0005] Constrained Application Protocol (CoAP) is a specialised web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. CoAP is described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 7252. CoAP provides a request-response interaction model between application endpoints, supports built-in resource discovery, and includes key concepts of the Web such as Uniform Resource Indicators (URIs) and Internet media types. CoAP is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

[0006] CoAP also introduces the ability to observe resources over a period of time, enabling clients to ‘subscribe’ to resource states. This is defined in the Observe extension to CoAP (described in “Observing Resources in the Constrained Application Protocol (CoAP)” IETF RFC 7641), where a CoAP client can “observe” a resource and be notified when its state changes.

[0007] The CoAP header structure is shown below:

[0008] Listing 1 : CoAP header structure.

[0009] Static Context Header Compression (SCHC) is defined in IETF RFC 8724 (“SCHC: Generic Framework for Static Context Header Compression and Fragmentation”). 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 low-power wide-area networks (LPWANs).

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

[0011] A packet with the uncompressed header is still called an 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).

[0012] Fig. 1 shows the structure of an 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. An 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.

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

[0014] Sensor Measurement Lists (SenML) is a format defined in IETF RFC 8428 by the core working group of the IETF. 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.

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

[0016] CoAP defines a number of options that can be included in messages. These are defined in detail in section 5.10 of the CoAP specification RFC 7252. All options are Type-Length-Value (TLV) encoded, and the option number is represented in a compressed form. It is important to note that the option number order in a message must be strictly increasing as laid out in the specification. Summary

[0017] IETF RFC 8824 (“Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)”) standardises how to enable header compression for the CoAP protocol using SCHC. In this way, a context with all the necessary information to enable header compression using SCHC can be built and used by all the parties involved in the communication. However, SCHC, and RFC 8824, does not standardise or define how the context is exchanged between nodes.

[0018] Therefore, there are currently no mechanisms for CoAP endpoints to establish and use a Static Context Header Compression (SCHC) context at the application layer that can be established dynamically. This means that the context provisioned must be designed in advance, and updates based on the particular ongoing communication have not been established. In addition, there is no negotiation procedure between the communication peers of what levels of the protocol stack support compression by SCHC. For example, there may be support for the whole stack (for example from Internet Protocol (IP) v6 to CoAP), or only part of the stack (for example only IPv6 and User Datagram Protocol (UDP)). Dynamic activation of SCHC without SCHC having agreed by design at the deployment is therefore desirable, and can allow the activation to be according to the characteristics of the network or the capabilities of the peers.

[0019] Also, as discussed in more detail below, there is a possibility of introducing payload compression that applies the header compression engine in SCHC to the payload. In a similar way to header compression, a mechanism is provided to negotiate what parts of the payload are going to be compressed, and to determine if all the peers support such compression.

[0020] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. In particular, this disclosure proposes a mechanism for provisioning devices with SCHC rules and SCHC operation parameters, and embodiments allow two CoAP endpoints (e.g. a client and a server) to establish and negotiate the setup of an SCHC context at the application layer. Embodiments provide that the endpoints / peers can agree on using compression and also what protocol headers compression to use. The negotiation solution can utilise mechanisms where a CoAP endpoint establishes an Observe relationship with a server’s resource, and the server can use a new CoAP Option defined herein, the schc-option. This new Option can contain a content-format identifying a new content type, e.g. application / schc+senml, that can be used to signal payload compression. The rules can be defined with a label that allows the endpoint to differentiate for which protocols or payload the rules apply to, and to signal support of such compression back to the server.

[0021] In addition, the client may send additional SCHC context rules, or send an update to the already established context, for example to enable payload compression, in one of the observation response payloads.

[0022] Certain embodiments may provide one or more of the following technical advantage(s). One advantage is improved efficiency as SCHC allows for the elimination of unnecessary transmission of repetitive information over the network. This can mean that only new or changing data is transmitted, which greatly reduces the load on the network and makes data transmission more efficient. The techniques described herein enable this to be dynamically activated, since it might not be known in advance that a client has SCHC support, or what type of protocols are supported to be compressed. In addition, the techniques allow the setup of dynamic compression of payload that goes beyond to the header compression provided by SCHC.

[0023] Another advantage is optimal, or more optimal, use of network bandwidth. The possibility of dynamic configuration, in particular for the payload, enables the possibility to use less bandwidth to transmit the same information. This can lead to optimised use of network resources, and the ability to transfer more data within given bandwidth constraints.

[0024] Another advantage is energy conservation, since devices using the techniques described herein can be more energy-efficient as they spend less time transmitting data and more time in low-power modes. This can result in longer battery life for devices and overall energy conservation.

[0025] Yet another advantage is flexibility. As the client is able to choose whether to use the SCHC context, the proposed techniques offer flexibility in operation. The client has no mandate to accept this format. In addition, it allows for the identification and negotiation of what a client implementation is capable of, and to select the level of functionality that is able to operate with.

[0026] According to a first aspect, there is provided a method performed by a first node. The first node is operating as a first CoAP endpoint. The method comprises negotiating, with a second node operating as a second CoAP endpoint, use of SCHC for compressing packets transmitted between the first node and second node. The negotiation comprises exchanging a support label that indicates a protocol or layer in a protocol stack of the first node and / or second node that SCHC can be applied to.

[0027] According to a second 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 or any embodiment thereof.

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

[0029] Brief Description of the Drawings

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

[0031] Fig. 1 shows the structure of an SCHC packet;

[0032] Fig. 2 shows conventional sensing update signalling between a client and server;

[0033] Fig. 3 illustrates the exemplary layers / protocols in a CoAP Protocol Stack;

[0034] Fig. 4 is a diagram showing the signalling between a CoAP client and CoAP server in option negotiation;

[0035] Fig. 5 shows a state diagram for the server according to the negotiation in Fig. 4;

[0036] Fig. 6 shows sensing update signalling between a client and server in which payload compression can be used;

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

[0038] Fig. 8 is a block diagram of a node according to some embodiments.

[0039] Detailed Description

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

[0041] 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. In a conventional implementation, the sensing update 203 is an SCHC packet in which the header can be compressed using SCHC techniques.

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

[0043] The client 201 and server 202 are considered to be CoAP endpoints, with the client 201 being referred to as a CoAP client endpoint, and the server 202 being referred to as a CoAP server. The term “first node” is used in this disclosure to refer to any of the loT device, client 201 , server 202, remote node, and CoAP endpoint(s).

[0044] The CoAP endpoints 201 , 202 are to establish and use an SCHC context at the application layer. As noted herein, the structure of the CoAP messages allows the use of SCHC also for compression of the payload, since some of the payloads are tuple of field and values, similar to a header. Thus, a method is proposed to provide rules that enable the use of SCHC mechanisms at the application layer to compress repetitive payload data in addition to the headers.

[0045] As noted above, this disclosure provides for the provisioning and negotiation of an SCHC context between communication peers, where there is also an agreement on what configuration the peers are able to support according to their capabilities. Two configuration aspects can be taken in account. The first aspect is what protocol(s) / layers SCHC header compression is supported for (i.e., to what layer / level of the protocol stack is the peer capable of encoding or decoding protocol headers). The second aspect is whether there is support for SCHC-based payload compression (in particular for CoAP carrying SenML).

[0046] The SCHC context can include SCHC rules and SCHC operation parameters. The SCHC operation parameters can relate to configuration options such as: use of fragmentation, use of reliability options (e.g., acknowledgement (ACK), negative acknowledgement (NACK) or none), and if they are being deployed. The configuration of such options can include parameters such as the retransmission timer, the window size, the fragmentation tile size, etc. (as described in Appendix D of RFC8724). The parameters can be fetched in a machine-readable format, for example in JSON or XML format, which are defined as part of the options above. These parameters are not part of the negotiation of the SCHC context, but they can be provided and used for the operation of the SCHC protocol to allow the deployment to be optimised where the communication will happen (for example, the parameters may be different when using WiFi compared to using mobile broadband for communication).

[0047] One possible implementation is to signal the configuration type with metadata associated to the rules definition of the suggested SCHC context. This metadata can be referred to as a “support label”, which is not present in conventional SCHC context rules. The support label can provide a context of what protocol(s) / layer(s) can be compressed by the rule, or, if instead of (or in addition to) header compression, the rules apply to compressing the payload.

[0048] Fig. 3 illustrates the exemplary layers / protocols in a CoAP Protocol Stack. In the CoAP Protocol Stack, the Application layer is CoAP (a request / response layer and message layer), the Transport layer is UDP, the Network layer is IPv6, the DataLink layer is WiFi IEEE 802.11. MAC and the Physical layer is WiFi IEEE 802.11. PHY.

[0049] The support label could be implemented or represented as a string, enumeration, or bitmap, or be in a pre-agreed format. In either case, the support label (or the value of the support label) can be mapped to a series of protocols that are covered by the rule, or applies only to the payload. An exemplary SCHC context definition is set out in Listing 2 below, which shows three different rules with respective support labels. This exemplary context definition uses the syntax from OpenSCHC, and the support label refers to the latest protocol compressed in the stack that is present in the rule and the RFC defining such SCHC profile:

[0050] Listing 2

[0051] In the following embodiments, the procedure is initiated by the server 202, but in other embodiments it can be initiated on the client side. If the client 201 and server 202 are unaware of whether SCHC mapping is available, then they can use the steps described herein.

[0052] Label Information - Labels are a term used herein to refer to rules subsets that pertain to the same part of the protocol stack. Labels can be standardised, for example via RFCs, or be pre- agreed / predefined. The label information may be agreed between a client 201 and server 202 in different ways.

[0053] In one approach, the label information can be negotiated via a CoAP option, which can be used when the label subsets refer to standard or default SCHC rules that are known by both endpoints. In another approach, the label information can be exchanged as payload information. This might be appropriate if the rules belonging to a label information change frequently or is closely tied to the data payload of a particular resource. In this case the SCHC context needs to be provisioned.

[0054] In the case of the CoAP option, a custom CoAP option is proposed, which is denoted schc- option. This is used to negotiate the SCHC label support between a CoAP client 201 and server 202. In some cases, there is need for a discovery of the rules beforehand to understand the support for compression of the peers.

[0055] The schc-option can be represented in multiple ways, for example as a variable-length field, a bit array, or other. In the case of a bit array or bit field, each bit can indicate the presence or absence of a specific capability. UDP, COAP, SenML, and PAYLOAD labels can be mapped in those bit fields. For example, the server 202 could indicate that capability by setting the schc- option to 00010011 (i.e. , bit positions 0, 1 and 4 are set to 1).

[0056] In the case where label information can be exchanged as payload information, a mechanism is proposed to provision (configure / set up) the rule set.

[0057] Rule Provisioning - For a CoAP server 202 that is equipped with an SCHC engine but without a specific rule set, the SCHC rule set can be dynamically provisioned and configured. A CoAP client 201 can write the SCHC rule set on the CoAP server 202. This can be achieved through a specific CoAP request, which includes the desired SCHC rules in its payload (for example as set out in Listing 2). The provisioning of these rules establishes a context per client 201 , meaning that each client 201 may have a different context according to what they can handle. A sample request is set out below:

[0058] {"type" : "CON" , "code" : "POST" , "URI" : " / schc - rules" , "payload" : <SCHC Rule Set (SCHC context ) >}

[0059] The / schc-rules path is used as an example, but other paths may be used as long as it is known. The rule set is then stored and utilised on a per-client basis. This path can also be discovered, and the client 201 may retrieve its values like those of any other CoAP resource.

[0060] The path can be used to create, update or delete the context. The server 202 can return the usual response message with the result of the operation (e.g., one of the CoAP response codes on success: 2.01 - Created, 2.04 - Changed, or 2.02 - Deleted). As per Section 5.9.1.1 of RFC 7252, the payload returned with the response, if any, is a representation of the action result. In the present case, the payload returned on CoAP response code 2.01 should include the labels that were successfully applied in the SCHC rules. So, for example, if only the UDP related rules were applied the server 202 would return: {"type" : "ACK" , "code" : "2.01 Created" , "payload" : {"rules" : " RFC8724 / UDP" }}

[0061] Over time, the SCHC context may need to be updated to accommodate changes in the client’s requirements, or the network conditions. If it is not desired to save bandwidth, the CoAP client 201 can update the SCHC rule set using the CoAP PATCH method. This request can be as follows:

[0062] {"type" : "CON", "code" : "PATCH", "URI" : " / schc -rules", "payload" : <Partial SCHC Rule Set>}

[0063] This request instructs the server 202 to update the existing rule set with the new rules provided in the payload. This dynamic update capability enables the SCHC context to remain optimal and relevant to the ongoing communication needs.

[0064] Thus, the CoAP server’s ability to have its SCHC rule set provisioned and updated by the CoAP client 201 provides a flexible and efficient approach to managing SCHC contexts. This enables an optimised (or more optimal) communication process tailored to each client’s specific needs / capabilities.

[0065] SCHC Context - Discovering the SCHC rules and SCHC operation parameters in a

[0066] CoAP endpoint can be achieved through two primary methods. The first uses a preconfigured path like / SCHC, and the second dynamically uses the .well-known / core resource with a specific resource type, like rt= schc-rules, and / or rt=schc-param.

[0067] The first method involves the preconfigured path which is conventionally used for storing and managing the SCHC rules and / or SCHC operation parameters. A CoAP client 201 can send a GET request to this path to retrieve the current SCHC rule set and / or SCHC operation parameters. A sample request is shown below. The server 202 can respond with the current SCHC rule set in the payload of the response.

[0068] {"type" : "CON" , "code" : "GET" , "URI" : " / schc" }

[0069] The second method involves querying the .well-known / core resource on the CoAP server 202 with the resource type (rt) parameter set to “schc-rules” and / or “schc-parameters”. This method is particularly useful when the client 201 does not know the exact path to where the SCHC rules and / or SCHC operation parameters are stored. A sample request for the SCHC rules is shown below:

[0070] {"type" : "CON", "code" : "GET", "URI" : . well-known / core?rt=schc-rules"}

[0071] The server 202 will respond with the URI(s) of the resource(s) that contain the SCHC rules (or SCHC operation parameters, if these were requested), which can be further retrieved according to the first method.

[0072] Negotiation Rule sets may be standardised, or previously determined / known, and two

[0073] CoAP endpoints may negotiate the rule subset to be used. A negotiation mechanism for such a scenario is described below with reference to Fig. 4. Fig. 4 is a diagram showing the signalling between a CoAP client 201 and CoAP server 202 in option negotiation, and Fig. 5 shows a state diagram for the server 202 according to the negotiation in Fig. 4.

[0074] Initially the server 202 is in an idle state (block 501 in Fig. 5).

[0075] The CoAP client endpoint 201 can initiate a GET request to the CoAP server 202 on a specific resource (shown by signal 401 from CoAP client 201 to CoAP server 202), which sets up a CoAP Observe relationship. This relationship allows the client 201 to get updates any time there is a change in the resource state. This already indicates a long-term notification relationship between a client 201 and a server 202, which might benefit from further compression mechanisms. The GET request can be as follows:

[0076] {"type" : "CON", "code" : "GET", "obs" : 0, URI" : " / resource"}

[0077] Upon receiving this request 401 (state 502 in Fig. 5), the server 202 detects that optimisations might be applied to the future communications (state 503 in Fig. 5). The server 202 sends an acknowledgement (ACK) to the client 201 including the new CoAP Option in its payload (as shown by signal 402 and state 504). The server 202 can initially propose to use an SCHC context represented by schc-option value 00010011 , indicating that it supports the SCHC labels mentioned before.

[0078] The data exchange between client 201 and server 202 may be as set out below. The ACK message 402 can be as follows:

[0079] {"type" : "ACK", "code" : "2.05 Content", "schc-option" : 00010011, "payload" : <serialized resource values>} The client 201 then sends a new GET request (signal 403) agreeing to use the overlapping capabilities (00000011) from the proposed SCHC context. This new GET request 403 can be as follows:

[0080] {"type" : "CON", "code" : "GET", "obs" : 0, "schc-option" : "00000011", "URI" : " / resource"}

[0081] Receipt of this GET request 403 at the server corresponds to state 505 in Fig. 5. The server 202 acknowledges the proposed set of capabilities by sending a response 404 (state 506) back to the client 201 that indicates schc-option set 00000011 , which confirms the negotiated, overlapping capabilities. The acknowledgement message 404 can be as follows:

[0082] {"type" : "ACK", "code" : "2.05 Content", "schc-option" : "00000011", "payload" : <serialized resource values>}

[0083] In cases where the context is provisioned, when the observation relationship between the client 201 and the server 202 ends, the server 202 can delete the SCHC context together with the observation context.

[0084] New “application / schc” content format - SCHC context serialisation is not yet standardised. Therefore, many optimisations for resource-constrained devices could be used to convey the context. The examples in this disclosure use the schema used by OpenSCHC, but other types of format can be used in different implementations.

[0085] After the SCHC compression has been agreed, both client 201 and server 202 are allowed to use a content format indicating that a compressed payload is being used. This content format is used to indicate that the expected serialised data is compressed using SCHC. For example, a new content format “application / schc" can be defined for that purpose, since there is not currently an existing available content format.

[0086] CoAP is similar to Hypertext Transfer Protocol (HTTP), but the content-formats are a CoAP addition, similar to content type, but represented as a number rather than a string. These numbers are often registered in IANA. If the content format is registered with IANA, a value such as 3333 in the registry could be used as it is available. A CoAP client 201 using it could send a request such as:

[0087] Header : GET (T=CON, Code=0.01, MID=0x7e34) Token : 0x34

[0088] Uri-Path : "resource-data"

[0089] Content-Format : "3333"

[0090] The response from the server 202 can include the compressed payload and the header required for this exchange. For example:

[0091] Header : 2.05 Content (T=ACK, Code=2.05JMID=0x7e34)

[0092] Token : 0x34

[0093] Content-Format : "3333"

[0094] Payload : (SCHC-compressed data)

[0095] This content format can also be used during resource registration and discovery to signal that compression is possible for certain resources.

[0096] SCHC Context - The server 202 may keep a context on a per-client basis so that the negotiation can be performed just once, and then reused over multiple future resource requests.

[0097] So, for example, the client 201 could request with "Accept" : 3333 signalling the server 202 to use the existing compression mechanism.

[0098] Payload Compression using SCHC

[0099] As noted above, it is possible to introduce payload compression that applies the header compression engine in SCHC to the payload. In a similar way to header compression, a mechanism can be provided to negotiate what parts of the payload are going to be compressed, and to determine if all the peers support such compression. Thus, an SCHC engine can be used 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.

[0100] A payload may be analysed and long and / or repeated payload values 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.

[0101] It is possible for SCHC rules for payload compression to be dynamically generated from an analysis of a payload sent from a client, and then shared with the 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.

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

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

[0104] In this discussion of payload compression, the sensing device / client 201 can send updates 203 in the SenML format, an example of which is found in Listing 3 below:

[0105] Listing 3: SenML reference example of sensor updates.

[0106] The SenML payload in Listing 3 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.

[0107] Fig. 4 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. 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.

[0108] Block 400 of Fig. 4 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) 401 sent to the server 202, in step 402 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 402 is described in more detail below, but briefly step 402 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.

[0109] The server 202 generates SCHC rules that relate to compression of the payload (step 403), and these are sent to the client 201 (signal 404). The generation of SCHC rules for payload compression is described in more detail below. As shown in Fig. 4, the analysis (step 402) and compression rule generation (step 403) 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.

[0110] In either case (i.e., generation of the compression rules via block 400, 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 an SCHC packet including the compressed payload to the server 202 (signal 405). 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.

[0111] The SCHC packet 405 can include, or the transmission of the SCHC packet 405 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. The compression indication is an indication of whether the payload in the SCHC packet 405 has been compressed. This indication is useful as some SCHC packets may not have a compressed payload, for example the payload in sensing update 401 , and this indication informs the server 202 whether decompression is required.

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

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

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

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

[0116] While block 400 of Fig. 4 is shown as operating on payloads in the sensing updates 401 that were not compressed (as the compression rules have not yet been established in step 403 following the analysis in step 402), it will be appreciated that the operations in block 400 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 an SCHC packet 405 including a compressed payload from the server 202 and decompressing the payload, steps 402 and 403 can be performed with respect to that decompressed payload to determine new or updated compression rules.

[0117] The analysis in step 402 and generation of compression rules in step 403 can result in compression rules for the payload in a form that is similar to rules generated for header compression. In SenML, JSON, and key-value data structures at large, only two fields can be directly mapped to an SCHC rule, namely, FID (the key) and Target Value (TV) (the value). However, an 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 .

[0118] The following description provides examples of the analysis of payload data and selection of values to compress according to step 402. In particular, the following example describes a way to select values to compress in the case of SenML, or JSON more generally. In step 402, 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}.

[0119] For example, the server 202 receives three sensing updates similar to Listing 3, 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 4 below:

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

[0121] Thus, in the analysis in step 402, 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 402 (and step 403) 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 402 (and step 403). 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 401) 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 401 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 402 and / or step 403.

[0122] 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 4 can be reduced to the non-empty, data structure shown in Listing 5:

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

[0124] Subsequently, the server 202 may take Listing 5 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 6 below:

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

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

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

[0128] FID (Field Identifier) - The FID may be mapped straight from the keys in Listing 6, 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).

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

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

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

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

[0133] 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 / decom pressed .

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

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

[0136] Listing 7: OpenSCHC payload compression rule generated in step 303.

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

[0138] 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 3 yields the following payload (in hexadecimal format):

[0139] Listing 8: Result of applying SCHC rule 12 from Listing 6 to the payload from Listing 3.

[0140] In the above example, OC 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.

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

[0142] 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 6 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 ”.

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

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

[0145] Listing 9

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

[0147] This section describes how the compressor side can signal an 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 405. 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 an 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.

[0148] - A first implementation uses a pre-agreed special character. The beginning of an SCHC compressed payload may be signalled with a special character, such as “*”, followed by the rule identifier, e.g., “*12...”. This special character can be either pre-agreed by the 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]).

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

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

[0151] - 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:

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

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

[0154] If a method as above is not found in the payload, this means that the payload is uncompressed.

[0155] The following section explains how decompression of an SCHC-compressed payload can be performed. In particular, this section describes how an SCHC decompressor (e.g., in the server 202) can translate data from Listing 8 into Listing 3.

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

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

[0158] 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”.

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

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

[0161] Fig. 7 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., a server 202, or more generally a CoAP endpoint. 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.

[0162] In step 701 , the first node negotiates the use of SCHC for compressing packets transmitted between the first node and a second node. The first node is operating as a first CoAP endpoint, and the second node is operating as a second CoAP endpoint. The negotiation comprises exchanging a support label that indicates a protocol or layer in a protocol stack of the first node and / or second node that SCHC can be applied to. The support label may indicate that the protocol or layer in the protocol stack that SCHC can be applied to includes CoAP.

[0163] The first node may be operating as a CoAP client, and the second node may be operating as a CoAP server. Alternatively, the first node may be operating as a CoAP server, and the second node may be operating as a CoAP client. In this latter case, the first node may perform the negotiation in step 701 separately for a plurality of CoAP clients (i.e., a plurality of second nodes).

[0164] The negotiation in step 701 may comprise determining a protocol or layer in the protocol stack to apply SCHC to based on the exchanged support label.

[0165] The negotiation in step 701 can comprise sending a support label to the second node that indicates a protocol or layer in a protocol stack of the first node that SCHC can be applied to. Alternatively or in addition, step 701 can comprise receiving a support label from the second node that indicates a protocol or layer in a protocol stack of the second node that SCHC can be applied to.

[0166] The support label may be a value that maps to a particular protocol or layer. The value may be in the form of a string, an enumeration, or a bitmap.

[0167] In some embodiments, the exchange of the support label in step 701 is performed using a CoAP Option. Alternatively, the support label can be exchanged in a payload of a CoAP packet.

[0168] The method by the first node can further comprise establishing one or more SCHC compression rules to use to compress packets transmitted between the first node and second node. This may comprise sending one or more SCHC compression rules to the second node, or receiving one or more SCHC compression rules from the second node. In the latter case, the first node can store the received one or more SCHC compression rules.

[0169] The SCHC compression rule(s) can be exchanged between the first node and the second node in response to one of the first node and second node sending a discovery request to the other. The discovery request can be a CoAP GET request. The CoAP GET request can indicate a path for a storage location where the one or more SCHC compression rules are stored, or a resource type parameter corresponding to SCHC compression rules.

[0170] The SCHC compression rule(s) established as described above can be updated using a CoAP PATCH procedure.

[0171] In some case, a plurality of sets of compression rules are defined for the first node and second node, and the SCHC compression rule(s) are established by determining one of the plurality of sets of compression rules to use.

[0172] Fig. 8 is a simplified block diagram of an apparatus 800 that can be used to implement, or implement part of, one or more of the nodes described herein. The apparatus 800 may be, or be a part of, a first node, a client, a CoAP client, a UE, an loT device, a server, a CoAP server, a computer, a CoAP endpoint, etc. In particular embodiments, the apparatus 700 can be configured or adapted to perform the method in Fig. 7.

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

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

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

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

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

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

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

[0180] 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 operating as a first Constrained Application Protocol, CoAP, endpoint, the method comprising: negotiating (701), with a second node operating as a second CoAP endpoint, use of Static Context Header Compression, SCHC, for compressing packets transmitted between the first node and second node; wherein the negotiation (701) comprises exchanging a support label that indicates a protocol or layer in a protocol stack of the first node and / or second node that SCHC can be applied to.

2. The method as claimed in claim 1 , wherein the negotiation (701) comprises determining a protocol or layer in the protocol stack to apply SCHC to based on the exchanged support label.

3. The method as claimed in claim 1 or 2, wherein the negotiation (701) comprises one or both of: sending, to the second node, a support label that indicates a protocol or layer in a protocol stack of the first node that SCHC can be applied to; and receiving, from the second node, a support label that indicates a protocol or layer in a protocol stack of the second node that SCHC can be applied to.

4. The method as claimed in any of claims 1-3, wherein the protocol or layer in the protocol stack that SCHC can be applied to includes CoAP.

5. The method as claimed in any of claims 1-4, wherein the support label is a value that maps to a particular protocol or layer, and wherein the value is in the form of a string, an enumeration, or a bitmap.

6. The method as claimed in any of claims 1-5, wherein the exchange of the support label is performed using a CoAP Option.

7. The method as claimed in any of claims 1-5, wherein the support label is exchanged in a payload of a CoAP packet.

8. The method as claimed in any of claims 1-7, wherein the method further comprises:establishing one or more SCHC compression rules to use to compress packets transmitted between the first node and second node.

9. The method as claimed in claim 8, wherein establishing the one or more SCHC compression rules comprises one of: sending, to the second node, one or more SCHC compression rules; or receiving, from the second node, one or more SCHC compression rules.

10. The method as claimed in claim 8, wherein establishing the one or more SCHC compression rules comprises: receiving, from the second node, one or more SCHC compression rules; and storing the received one or more SCHC compression rules.11 . The method as claimed in claim 9 or 10, wherein the one or more SCHC compression rules are exchanged between the first node and the second node in response to one of the first node and second node sending a discovery request to the other one of the first node and second node.

12. The method as claimed in claim 11 , wherein the discovery request is a CoAP GET request indicating one of: a path for a storage location where the one or more SCHC compression rules are stored, or a resource type parameter corresponding to SCHC compression rules.

13. The method as claimed in any of claims 8-14, wherein the method further comprises: updating the one or more SCHC compression rules using a CoAP PATCH procedure.

14. The method as claimed in claim 8, wherein a plurality of sets of compression rules are defined for the first node and second node, and wherein the step of establishing the one or more SCHC compression rules comprises determining one of the plurality of sets of compression rules to use.

15. The method as claimed in any of claims 1-14, wherein the first node is operating as a CoAP client, and the second node is operating as a CoAP server.

16. The method as claimed in any of claims 1-14, wherein the first node is operating as a CoAP server, and the second node is operating as a CoAP client.

17. The method as claimed in claim 16, wherein the first node performs the negotiation of the use of SCHC separately for a plurality of CoAP clients.

18. 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 any of claims 1-17.

19. A first node (201 ; 202; 800) configured to perform the method according to any of claims 1- 17.

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

Images