Technical Field

The present disclosure relates to methods for compressing, decompressing and managing information about data objects hosted at a device. The present disclosure also relates to a node and to a computer program and a computer program product configured, when run on a computer to carry out methods for compressing, decompressing and managing information about data objects hosted at a device.

Background

The “Internet of Things” (loT) refers to devices enabled for communication network connectivity, so that these devices may be remotely managed, and data collected or required by the devices may be exchanged between individual devices and between devices and application servers. Such devices, examples of which may include sensors and actuators, are often, although not necessarily, subject to severe limitations on processing power, storage capacity, energy supply, device complexity and/or network connectivity, imposed by their operating environment or situation, and may consequently be referred to as constrained devices. Constrained devices often connect to the core network via gateways using short range radio technologies. Information collected from the constrained devices may then be used to create value in cloud environments.

The constrained nature of loT devices has prompted the design and implementation of new protocols and mechanisms. The Constrained Application Protocol (CoAP), as defined in RFC 7252, is one example of a protocol designed for loT applications in constrained nodes and constrained networks. CoAP provides a request-response based RESTful communication architecture between constrained nodes or between constrained nodes and nodes on the Internet. CoAP can easily be integrated to the web and web services by translating CoAP messages to HTTP.

The Open Mobile Alliance (OMA) Lightweight Device Management (DM) protocol, also known as the Lightweight Machine to Machine protocol (LWM2M), is a light and compact device management protocol that may be used for managing loT devices and their resources. LWM2M is designed to run on top of CoAP, which may use UDP or SMS bindings, or may run on another transport protocol, including for example TCP. LWM2M is therefore compatible with any constrained device which supports CoAP. LWM2M defines three components:

LWM2M Client: contains several LWM2M objects with resources. A LWM2M Server can execute commands on the resources to manage the client, including reading, deleting or updating resources. LWM2M Clients are generally run in constrained devices.

LWM2M Server: manages LWM2M Clients by sending management commands to them.

LWM2M Bootstrap Server: is used to manage the initial configuration parameters of LWM2M Clients during bootstrapping of a device.

LWM2M data objects and object instances are presented with Constrained RESTful Environments (CoRE) Link format for device registration and resource discovery. The CoRE Link format allows web-enabled constrained devices to use web linking using a link format to describe hosted resources, their attributes, and other relationships between links.

For example, a device that registers two instances of temperature sensors, three power meter instances, and one set point could express them as follows: /3303/1 ></3303/2x/3305/0></3305/1 ></3305/3></3308/1 >

A LWM2M server can then discover the details of a specific object instance using the Discovery method as follows:

Discover: 3303/1

The result is again encoded using CoRE Link format. In the illustrated example below, the temperature sensor object instance [1] has 5 resources, the mandatory "value" resource, followed by optional minimum and maximum measured values, reset functionality, and sensor units resource:

Result:

</3303/1 /57 OOx/3303/1 /5601 ></3303/1/5602></3303/1/5605></3303/1/5701 > Typically, a server would perform the discovery process for all object instances (i.e. 6 times for the example device above) to populate the information properly in the server. The result below illustrates the resources for instance [2] of the temperature sensor object:

</3303/2/5700></3303/2/5601 ></3303/2/5602></3303/2/5605></3303/2/5701 >

A result of the above format, setting out the mandatory and optional resources associated with each object instance hosted at the device, would be obtained for each of the six object instances hosted on the device in order to discover all of the resources hosted at the device.

For a constrained network, the discovery process set out above can consume a lot of bandwidth. In order to address this problem, CBOR encoding has been proposed to achieve a more efficient encoding that the above illustrated web links. However, this only reduces the bandwidth consumption by some tens of percentage points. For many constrained environments, a greater reduction in bandwidth required for object discovery is desirable.

Summary

It is an aim of the present disclosure to provide a method, node and computer readable medium which at least partially address one or more of the challenges discussed above.

According to a first aspect of the present disclosure, there is provided a method for compressing information about data objects hosted at a device, wherein the data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The method comprises, for an instance of a data object hosted at the device, determining which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance. The method further comprises mapping the determined resources to a resource bit array. According to the method, each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. According to the method, a value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device.

According to examples of the present disclosure, the“ordered sequence of resources which may be associated with instances of a data object of that object type” that is specified in the object model may include only optional resources, such that only optional resources which are present are mapped to the bit array.

According to examples of the present disclosure, mapping the determined resources to a resource bit array may comprise, for a resource having a position i in the ordered sequence of resources which may be associated with instances of the data object, setting the bit having the corresponding position i in the resource bit array according to whether or not the resource having position i in the ordered sequence is associated with the instance. Thus mapping may comprise, for an ith resource in the ordered sequence, setting the ith bit of the resource bit array according to whether or not the ith resource is associated with the instance.

According to examples of the present disclosure, the method may further comprise performing, for all instances of data objects hosted at the device, the step of mapping resources associated with the instance to a resource bit array.

According to examples of the present disclosure, the method may further comprise determining an object type of objects hosted at the device, and delta encoding the determined object types.

According to examples of the present disclosure, delta encoding the object types of data objects hosted at the device may comprise representing the objects types of data objects hosted at the device as an ordered sequence of object types, encoding the first object type in the ordered sequence of object types, and, for each subsequent object type in the ordered sequence of object types, encoding a difference between the object type under consideration and the preceding object type in the ordered sequence of object types. According to examples of the present disclosure, the encoding may comprise binary encoding.

According to examples of the present disclosure, the method may further comprise, for a data object hosted at the device, determining identifiers of instances of the data object that are hosted at the device, and mapping an ordered sequence of the identifiers of instances of the data object that are hosted at the device to an instance bit array. According to examples of the present disclosure, positions in the instance bit array may correspond to integers in a consecutive integer sequence, and a value of a bit in the instance bit array may indicate whether or not an instance of the data object having an instance identifier of the integer corresponding to the position of the bit in the instance bit array is hosted at the device.

According to examples of the present disclosure, mapping the ordered sequence of the identifiers of instances of the data object that are hosted at the device to an instance bit array may comprise, for an instance identifier j, setting the bit of the instance bit array corresponding to integer j in the consecutive integer sequence according to whether or not the instance with identifier j is hosted at the device.

According to examples of the present disclosure, mapping the ordered sequence of the identifiers of instances of the data object that are hosted at the device to an instance bit array may further comprise selecting n consecutive bits of the bit array, the n consecutive bits selected from an end of the bit array and determining whether the remaining bits of the bit array comprise at least one bit that is set to indicate an identifier of an instance that is hosted at the device. Mapping the ordered sequence of the identifiers of instances of the data object that are hosted at the device to an instance bit array may further comprise writing the selected n consecutive bits into a first instance array byte and, if the remaining bits of the bit array comprise at least one bit that is set to indicate an identifier of an instance that is hosted at the device, writing the next n consecutive bits of the instance bit array into another instance array byte.

According to examples of the present disclosure, selecting the n consecutive bits from an end of the bit array may comprise selecting the n least significant bits.

According to examples of the present disclosure, n may be equal to 7, and mapping the ordered sequence of the identifiers of instances of the data object that are hosted at the device to an instance bit array may further comprise, if the remaining bits of the bit array comprise at least one bit set to indicate that an instance is hosted at the device, setting a reserved bit in the first instance array byte to indicate the presence of a subsequent instance array byte.

According to examples of the present disclosure, n may be equal to 8, and mapping the ordered sequence of the identifiers of instances of the data object that are hosted at the device to an instance bit array may further comprise, if the remaining bits of the bit array comprise at least one bit set to indicate that an instance is hosted at the device, encoding a marker indicating the presence of an array of instance bytes.

According to examples of the present disclosure, an array of instance bytes may comprise at least two instance array bytes, and the marker may indicate the number of instance array bytes in the array of instance bytes and/or the start of the array of instance bytes.

According to examples of the present disclosure, encoding a marker may comprise performing at least one of Concise Binary Object Representation (CBOR) encoding, MessagePack encoding, JavaScript Object Notation (JSON) encoding, and/or Binary JSON (BSON) encoding.

According to examples of the present disclosure in which encoding a marker comprises performing CBOR encoding, the marker may comprise a CBOR tag.

According to examples of the present disclosure, for a data object hosted at the device, the consecutive integer sequence to which positions in the instance bit array correspond may start at a non-zero integer, and mapping an ordered sequence of instances of the data object that are hosted at the device to the instance bit array may further comprise encoding a start integer of the consecutive integer sequence.

According to examples of the present disclosure, encoding a start integer of the consecutive integer sequence may comprise setting a reserved bit in the instance bit array to indicate that a start integer of the consecutive integer sequence is encoded, encoding the start integer of the consecutive integer sequence, and concatenating the encoded start integer with the instance bit array. According to examples of the present disclosure, encoding a start integer of the consecutive integer sequence may comprise encoding a marker indicating that a start integer of the consecutive integer sequence is encoded, and encoding the start integer of the consecutive integer sequence.

According to examples of the present disclosure, encoding a marker may comprise performing at least one of CBOR encoding, MessagePack encoding, JSON encoding and/or BSON encoding. According to examples of the present disclosure in which encoding a marker comprises performing CBOR encoding, the marker may comprise a CBOR tag.

According to examples of the present disclosure, encoding the start integer of the consecutive integer sequence may comprise binary encoding the start integer.

According to examples of the present disclosure, the method may further comprise, for a data object hosted at the device, obtaining metadata describing the data object, encoding the metadata, and indicating that encoded metadata is included with the compressed information.

According to examples of the present disclosure, indicating that encoded metadata is included with the compressed information may comprise at least one of setting a reserved bit in the instance bit array, or encoding a marker indicating that encoded metadata is included with the compressed information.

According to examples of the present disclosure, encoding a marker may comprise performing at least one of CBOR encoding, MessagePack encoding, JSON encoding and/or BSON encoding. According to examples of the present disclosure in which encoding a marker comprises performing CBOR encoding, the marker may comprise a CBOR tag.

According to examples of the present disclosure, the metadata may comprise at least one attribute of the data object hosted at the device.

According to examples of the present disclosure, the method may further comprise concatenating encoded object types, instance bit arrays and resource bit arrays such that each encoded object type is followed by an instance bit array for that object type and each instance bit array is followed by resource bit arrays for each of the instances indicated in the instance bit array as hosted at the device.

According to examples of the present disclosure, the data objects may comprise IPSO (Internet Protocol for Smart Objects) smart objects.

According to examples of the present disclosure, before compression, the information about data objects hosted at a device may be represented in at least one of Constrained RESTful Environments (CoRE) Link Format, CoRE Link Format represented in JSON, Constrained RESTful Application Language (CoRAL), or Sensor Measurement Lists (SenML).

According to examples of the present disclosure, the device may be operable to run a Light Weight Machine to Machine (LWM2M) client.

According to examples of the present disclosure, the method may be performed by at least one of the device, a LWM2M server and/or a LWM2M bootstrap server.

According to another aspect of the present disclosure, there is provided a method for managing information about data objects hosted at a device, wherein the data objects conform to an object model that specifies, for a given object type, an ordered sequence of resources which may be associated with instances of the object type. The method comprises compressing the information about data objects hosted at the device, and performing at least one of storing the compressed information in a memory or transmitting the compressed information over a communication link. Compressing the information about data objects hosted at the device comprises performing a method according to any one of the preceding aspects or examples of the present disclosure.

According to examples of the present disclosure, transmitting the compressed information over the communication link may comprises transmitting the compressed information as part of at least one of a bootstrapping procedure, a registration procedure, and/or a discovery procedure.

According to examples of the present disclosure, the device at which the data objects are hosted may comprise a Machine to Machine (M2M) device, and the M2M device may comprise a constrained device. For the purposes of the present disclosure, a constrained device comprises a device which conforms to the definition set out in section 2.1 of RFC 7228 for“constrained node”.

According to the definition in RFC 7228, a constrained device is a device in which“some of the characteristics that are otherwise pretty much taken for granted for Internet nodes at the time of writing are not attainable, often due to cost constraints and/or physical constraints on characteristics such as size, weight, and available power and energy. The tight limits on power, memory, and processing resources lead to hard upper bounds on state, code space, and processing cycles, making optimization of energy and network bandwidth usage a dominating consideration in all design requirements. Also, some layer-2 services such as full connectivity and broadcast/multicast may be lacking”. Constrained devices are thus clearly distinguished from server systems, desktop, laptop or tablet computers and powerful mobile devices such as smartphones. A constrained device may for example comprise a Machine Type Communication device, a battery powered device or any other device having the above discussed limitations. Examples of constrained devices may include sensors measuring temperature, humidity and gas content, for example within a room or while goods are transported and stored, motion sensors for controlling light bulbs, sensors measuring light that can be used to control shutters, heart rate monitor and other sensors for personal health (continuous monitoring of blood pressure etc.) actuators and connected electronic door locks. A constrained network correspondingly comprises“a network where some of the characteristics pretty much taken for granted with link layers in common use in the Internet at the time of writing are not attainable”, and more generally, may comprise a network comprising one or more constrained devices as defined above.

According to another aspect of the present disclosure, there is provided a method for decompressing information about data objects hosted at a device, wherein the data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The method comprises, for an instance of a data object hosted at the device, mapping a resource bit array for the instance of the data object to the ordered sequence of resources which may be associated with instances of the data object. According to the method, each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device, and a value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. The method further comprises determining from the mapped resource bit array which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance of the data object.

According to another aspect of the present disclosure, there is provided a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any one of the preceding aspects or examples of the present disclosure.

According to another aspect of the present disclosure, there is provided a carrier containing a computer program according the preceding aspect of the present disclosure, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

According to another aspect of the present disclosure, there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program according to a preceding aspect of the present disclosure.

According to another aspect of the present disclosure, there is provided a node for compressing information about data objects hosted at a device, wherein the data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The node comprises a processor and a memory, the memory containing instructions executable by the processor such that the node is operable to, for an instance of a data object hosted at the device, determine which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance, and map the determined resources to a resource bit array. Each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. A value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. According to examples of the present disclosure, the node may be further operable to carry out a method according to any one of the preceding aspects or examples of the present disclosure.

According to examples of the present disclosure, the node may comprise at least one of a device operable to run a LWM2M client, a LWM2M server, or a LWM2M bootstrap server.

According to another aspect of the present disclosure, there is provided a node for compressing information about data objects hosted at a device, wherein the data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The node is adapted to, for an instance of a data object hosted at the device, determine which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance, and map the determined resources to a resource bit array. Each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. A value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device.

According to examples of the present disclosure, the node may be further operable to carry out a method according to any one of the preceding aspects or examples of the present disclosure.

According to examples of the present disclosure, the node may comprise at least one of a device operable to run a LWM2M client, a LWM2M server, or a LWM2M bootstrap server.

According to another aspect of the present disclosure, there is provided a node for decompressing information about data objects hosted at a device, wherein the data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The node comprises a processor and a memory, the memory containing instructions executable by the processor such that the node is operable to, for an instance of a data object hosted at the device, map a resource bit array for the instance of the data object to the ordered sequence of resources which may be associated with instances of the data object. Each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. A value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. The node is further operable to determine from the mapped resource bit array which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance of the data object.

According to another aspect of the present disclosure, there is provided a node for decompressing information about data objects hosted at a device, wherein the data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The node is adapted to, for an instance of a data object hosted at the device, map a resource bit array for the instance of the data object to the ordered sequence of resources which may be associated with instances of the data object. Each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. A value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. The node is further adapted to determine from the mapped resource bit array which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance of the data object.

Brief Description of the Drawings

For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which: Figure 1 is a flow chart illustrating process steps in a method for compressing information about data objects hosted at a device;

Figures 2a to 2e show a flow chart illustrating process steps in another example of method for compressing information about data objects hosted at a device;

Figure 3 illustrates an example implementation of the method shown in Figures 2a to 2e;

Figure 4 is a flow chart illustrating process steps in a method for decompressing information about data objects hosted at a device;

Figures 5a to 5c are signalling diagrams illustrating processes between a device and a node;

Figure 6 is a block diagram illustrating functional units in a node; and

Figure 7 is a block diagram illustrating functional units in another example of node.

Detailed Description

Aspects of the present disclosure provide methods for compressing and decompressing information about data objects hosted at a device. The device may be an loT device, such as an M2M device, and may or may not be a constrained device. The device may be operable to run a LWM2M client and may host one or more data objects. The data objects may for example be IPSO smart objects, or may be data objects conforming to a different standard. The data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. An example for an IPSO smart object temperature sensor can be found at http://www.openmobilealliance.org/tech/profiles/lwm2m/3303.x ml (as of the date of filing of the present application). The example specification sets out one mandatory resource which must always be associated with an instance of a temperature sensor data object. The mandatory resource is the sensor value. The example specification also sets out an ordered list of optional resources, including minimum and maximum measured values, minimum and maximum ranges, sensor units and a reset resource. It will be appreciated that the example IPSO smart object specification is provided for the purpose of illustration, and other specifications of data objects, setting out an ordered sequence of optional resources that may be associated with instances of the data object, exist.

Examples of the present disclosure take advantage of the ordered sequence provided in specification documents for data objects to achieve compression of data object information using a bit array. Resources associated with an instance of a data object hosted at a device are mapped to a resource bit array in which each bit position corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. A value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. Additional information compression may be achieved by mapping instance identifiers of instances of data objects hosted at the device to an instance bit array, and by delta encoding object identifiers, as discussed in greater detail below. The compressed information about data objects hosted at the device may be stored at the device or another node, so offering resource savings in terms of the memory required to store the information, or may be transmitted over a communication link, so offering resource savings in terms of the bandwidth required on the communication link to transmit the information.

Figure 1 is a flow chart illustrating process steps in a method 100 for compressing information about data objects hosted at a device in accordance with aspects of the present disclosure. The data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The object model may for example comprise a standard model such as the IPSO Smart Objects object model. The object model may alternatively be any other standard or non-standard model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type, such that the ordered sequence is known to both client devices and to a relevant server. The device hosting the data objects may be a constrained device as set out above. The device may be operable to run a LWM2M client. The device may be configured to communicate using a RESTful protocol including for example CoAP, HTTP etc, or other loT protocol such as MQTT. The method 100 may be carried out by the device hosting the data objects or by another node, which may be a management node for the device. For example, the method may be carried out by a LWM2M server or a LWM2M bootstrap server. Referring to Figure 1 , the method 100 comprises, for an instance of a data object hosted at the device, as illustrated at 120a, in a first step 120, determining which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance. In step 130, the method 100 comprises mapping the determined resources to a resource bit array. As illustrated at 130a, each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. As illustrated at 130b, a value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. Thus for example, a 1 may be entered in the bit array to signify that the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance, and a 0 may be entered into the bit array if the resource is not associated with the instance.

Figures 2a to 2e show a flow chart illustrating process steps in another example of a method 200 for compressing information about data objects hosted at a device in accordance with aspects of the present disclosure. The data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The object model may for example comprise a standard model such as the IPSO Smart Objects object model. The steps of the method 200 illustrate one way in which the steps of the method 100 may be implemented and supplemented in order to achieve the above discussed and additional functionality. As for the method 100 of Figure 1 , the device hosting the data objects may be a constrained device as set out above. The device may be operable to run a LWM2M client. The device may be configured to communicate using a RESTful protocol including for example CoAP, HTTP etc, or other loT protocol such as MQTT. The method 200 may be carried out by the device hosting the data objects or by another node, which may be a management node for the device. For example, the method may be carried out by a LWM2M server or a LWM2M bootstrap server. For convenience, the method 200 is discussed below as being carried out by a device, however it will be appreciated that this is merely for the purposes of illustration, and the following discussion of the method 200 is equally applicable to the performance of the method 200 by another node, such as a LWM2M server or a LWM2M bootstrap server. Referring first to Figure 2a, in a first step 202, the device determines an object type of objects hosted at the device. The object type may comprise an identifier indicating a type of objects, instances of which are hosted at the device. In step 204, the device represents the object types of data objects hosted at the device as an ordered sequence of object types. This ordering may facilitate delta encoding of the object types, as discussed in further detail below. In step 206, the device encodes the first object type in the ordered sequence of object types. As illustrated in step 206, this may comprise binary encoding the first object type. Thus for an example IPSO smart object“temperature sensor”, having object type 3303, step 206 may comprise encoding 3303 as:

1 1001 110011 1

The object type may be encoded as two bytes of information, and may thus be encoded as binary:

00001 1001 110011 1

Or hexadecimal as 0CE7.

For ease of reading in the following discussion, hexadecimal representation (designated by hex) of binary encoded information may be provided in the place of or alongside the binary encoding. It will be appreciated that this is merely to increase the ease with which the specification may be understood by the reader.

Referring still to Figure 2a, in step 208, the device obtains metadata describing the data object (the type of which was encoded in step 206). The metadata may for example be an attribute of the data object such as the content type, object version, short server id (ssid) etc. Other examples of object attributes may be found in the OMA LWM2M specification at: http://www.openmobilealliance.org/release/LightweightM2M/V1_ 1- 20180612-C/OMA-TS-LightweightM2M_Core-V1_1 -20180612-C.html#Table-512-1 - lessPROPERTIESgreater-Class-Attributes. The CoRE link format is used in LWM2M to convey attributes but any other format may be used to represent metadata describing the data object. In step 210, the device determines identifiers of instances of the data object (the type of which was encoded in step 206) that are hosted at the device. In step 212, the device maps an ordered sequence of the identifiers of instances of the data object that are hosted at the device to an instance bit array. As illustrated at 212a, positions in the instance bit array correspond to integers in a consecutive integer sequence, and, as illustrated at 212b, a value of a bit in the instance bit array indicates whether or not an instance of the data object having an instance identifier of the integer corresponding to the position of the bit in the instance bit array is hosted at the device. Thus for example, for a consecutive integer sequence:

0 1 2 3 4 5 6 7

The presence of instances having instance identifiers 1 , 4 and 7 hosted at the device would be indicated by the bit array below, read from the least significant bit towards the most significant bit:

10010010

Various different implementation options may be considered for the encoding of the instance identifiers into bytes of compressed information in accordance with steps 212, 212a and 212b. Two example implementation options are illustrated in Figures 2d and 2e. Each of Figures 2d and 2e illustrates a process 1000, 1 100, which may take place in order to carry out the step 212 of mapping an ordered sequence of instance identifiers into an instance bit array.

Referring first to Figure 2d, in a first example process 1000 for mapping instance identifiers, the device initially checks at step 1002 whether there is an integer sequence offset. This may be the case for example if the lowest integer number of an instance identifier hosted at the device is above a threshold value. The offset may thus avoid an overly large instance bit array containing a large number of 0s in the least significant bit positions. In the above example of instance identifiers 0, 3 and 6, an integer sequence offset would not be included, as the lowest integer identifier is 0. However, if the lowest integer identifier was, for example, 25, using an integer sequence starting at 0 would require including 25 zero bits in the instance bit array before the first 1 , signifying the presence of an instance having instance identifier 25. In such an example, an offset, such that the consecutive integer sequence starts, say, at 25, would provide for a more efficient encoding. The threshold for offsetting the consecutive integer sequence may be selected by an administrator according to operational priorities, and may be configurable. If an integer sequence offset is to be used (yes in step 1002), the device then encodes a marker at step 1004 indicating that a start integer of the consecutive integer sequence is encoded. The marker may be encoded using CBOR, MessagePack, JSON, BSON etc. and may in some examples comprise a CBOR tag. The device then encodes the start integer of the consecutive integer sequence. The start integer may be encoded in binary and/or using the same encoding as the marker.

Once the offset has been encoded, or if no offset is required (No at step 1002), the device then generates an instance bit array at step 1008 by, for an instance identifier j, setting the bit of the instance bit array corresponding to integer j in the consecutive integer sequence according to whether or not the instance with identifier j is hosted at the device. The device then selects n consecutive bits of the bit array from an end of the bit array. In the example illustrated in Figure 2d, n=8, and the bits are selected starting from the least significant bit. In step 1012, the device writes the selected consecutive bits into a first instance array byte. In step 1014, the device then checks whether the remaining bits of the array include any bits indicating the presence of an object instance (in the case of a 1 signifying the presence of an object instance, the device therefore checks if the remaining bits of the bit array include a 1 ). If there are no further 1 s in the bit array, then identifiers of all instances of the data object that are hosted at the device have been encoded, and the process may terminate. Step 212 of Figure 2a is therefore complete and the device returns to Figure 2a at step 1016. If the remaining bits of the instance bit array include a 1 (Yes at step 1014), signifying the presence of further object instances hosted at the device, then the device encodes a marker indicating the presence of an array of instance bytes at step 1018. The marker may be encoded using CBOR, MessagePack, JSON, BSON etc. In some examples, the marker may merely signify the presence of an array (i.e. that more than one byte of instance identifiers is included in the compressed information). In other examples, the marker may indicate the length of the array of instance bytes i.e. how many instance bytes are included in the compressed information for this object type). In such examples, the process may wait until all instance bytes have been written before encoding the marker.

In step 1020, the device writes the next n=8 bits of the instance bit array into another instance array byte, and then returns to step 1014 to check whether the remaining bits of the array include any bits indicating the presence of an object instance. The device repeats the steps of checking and writing the next n=8 consecutive bits into a new instance array byte until identifiers of all object instances hosted at the device have been encoded. The device then exits process 1000, having completed step 212 and returns to Figure 2a.

With reference to Figure 2d, it will be appreciated that in some examples, all of the instance array bytes and the offset value may be encoded using the same encoding as the marker(s). Thus the compressed information may comprise a first encoded object comprising an offset marker, a second encoded object comprising the offset, a third encoded object comprising an instance byte array marker and then one or more encoded objects containing the instance array bytes. In further examples, the presence of encoded metadata may also be indicated by an encoded marker, and both the marker and metadata may be encoded using the same encoding as the markers for offset and instance array bytes.

Figure 2e illustrates another example process for carrying out step 212 by mapping instance identifiers to an instance bit array. In the process 1 100 of Figure 2e, instead of encoding markers indicating an offset or an array of instance bytes, reserved bits in the bytes of instance identifier information may be used to signify the presence of these elements, as discussed in further detail below.

Referring to Figure 2e, in another example process 1 100 for mapping instance identifiers to an instance bit array, the device first checks, in step 1 102, whether an offset to the integer sequence is required. The reasons for using an offset, and a condition for determining whether or not an offset should be included, are discussed above with reference to Figure 2d. If an offset is to be included (Yes at step 1 102), then the device sets, at step 1 104, a reserved bit in the first instance array byte to indicate that a start integer of the consecutive integer sequence is encoded. In step 1 106, the device then encodes the start integer of the consecutive integer sequence, for example using binary encoding. Once the offset has been encoded, or if no offset is required (No at step 1 102), the device then generates an instance bit array at step 1 108 by, for an instance identifier j, setting the bit of the instance bit array corresponding to integer j in the consecutive integer sequence according to whether or not the instance with identifier j is hosted at the device. The device then selects n consecutive bits of the bit array from an end of the bit array. In the example illustrated in Figure 2e, n=6, and the bits are selected starting from the least significant bit. In step 1 1 12, the device writes the selected consecutive bits into a first instance array byte. In step 1 1 14, the device then checks whether the remaining bits of the array include any bits indicating the presence of an object instance (in the case of a 1 signifying the presence of an object instance, the device therefore checks if the remaining bits of the bit array include a 1 ). If there are no further 1 s in the bit array, then identifiers of all instances of the data object that are hosted at the device have been encoded. The device then sets a reserved bit in the instance array byte to indicate that the current instance array byte is the last instance array byte for this object type. In one example, this may comprise setting the reserved bit to 0. The remaining seven bits of the first instance byte comprise the reserved bit for indicating an offset, and the 6 bits selected from the bit array. Once the reserved bit had been set in step 1 1 16, the process may terminate as step 212 of Figure 2a is complete and the device returns to Figure 2a at step 1018.

If the remaining bits of the instance bit array include a 1 , signifying the presence of further object instances hosted at the device, then, at step 1 120, the device sets the reserved bit in the instance array byte to indicate that the current instance array byte is not the last instance array byte for this object type. In one example, this may comprise setting the reserved bit to 1 . In step 1020, the device writes the next n=7 bits of the instance bit array into another instance array byte, and then returns to step 1 1 14 to check whether the remaining bits of the array include any bits indicating the presence of an object instance. It will be appreciated that only the first instance array byte includes two reserved bits, as the offset is only indicated in the first instance array byte. Subsequent instance array bytes only include a single reserved bit that is used to indicate whether or not the current instance array byte is the last instance array byte for the current object type. The device repeats the steps of checking and writing the next n=7 consecutive bits into a new instance array byte until identifiers of all object instances hosted at the device have been encoded. In the final instance array byte, the reserved bit is set to 0, to indicate that the current instance array byte is the last instance array byte. The device then exits process 1 100, having completed step 212, and returns to Figure 2a.

With reference to Figure 2e, it will be appreciated that in some examples, the presence of encoded metadata may also be indicated by a reserved bit in a specific instance array byte. Included metadata may then be encoded using binary encoding, as discussed below with reference to step 214. It will be appreciated that the processes 1000 and 1 100 are provided for the purposes of illustration, and alternative combinations of encoded markers and reserved bits to signal additional instance bytes, an offset in the continuous integer sequence, and/or the presence of metadata, may be envisaged.

Once the device has completed the mapping of an ordered sequence of identifiers of instances of the data object to an instance bit array in step 212, as illustrated in Figure 2a, the device proceeds to encode the metadata obtained in step 208 as illustrated in Figure 2b, if this has not already been performed as part of the mapping in step 212. The encoding of the metadata may be binary encoding. The device then indicates that encoded metadata is included with the compressed information in step 216. As illustrated at 216a and 216b, and as discussed above, this may comprise setting a reserved bit in one or more bytes formed from the instance bit array, and/or may comprise encoding a marker indicating that encoded metadata is included with the compressed information. The encoding may be CBOR, MessagePack, JSON, BSON etc. If an encoded marker is used to indicate the presence of encoded metadata in step 216, the same encoding method may be used to encode the metadata in step 214.

Referring still to Figure 2b, the device then selects an instance of the data object (the type of which was encoded at step 206), in step 218. In step 220, the device determines which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the selected instance. In step 230, the device maps the determined resources to a resource bit array. As illustrated at 230a, each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. As illustrated at 230b, a value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. Thus for example, a 1 may be entered in the bit array to signify that the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance, and a 0 may be entered into the bit array if the resource is not associated with the instance.

As illustrated in step 230, the mapping process may comprise, for a resource having a position i in the ordered sequence of resources which may be associated with instances of the data object, setting the bit having the corresponding position i in the resource bit array according to whether or not the resource having position i in the ordered sequence is associated with the instance. Thus mapping may comprise, for an ith resource in the ordered sequence, setting the ith bit of the resource bit array according to whether or not the ith resource is associated with the instance. Taking the example of the IPSO temperature sensor smart object mentioned above, the IPSO object model sets out the following ordered list of optional resources:

5601 min measured value,

5602 max measured value,

5603 min range value,

5604 max rage value,

5701 sensor units,

5605 reset min and max measured values.

This list of optional resources may be ordered as it is set out in the object model, in numerical order of the resources or in an alternative order. If resources are considered in the order in which they are set out in the object model, then the presence of optional resources min measured value and max measured value only at a data object instance would be indicated by the resource bit array (counting form the least significant bit):

00001 1

The above bit array indicates that the first two resources in the ordered sequence of optional resources are associated with the relevant data object instance. It will be appreciated that as mandatory resources must always be present, there is no need to signal their presence using a bit array, although their presence may be signalled according to different implementation options for the method. It will also be appreciated that as the number of resources that may be associated with instances of a particular data object type is fixed by the data model, the resource bit array will always be of a known fixed length, and there is therefore no need to indicate a potential offset or a number of bytes of the resource bit array, although these may be signalled according to different implementation options for the method. Once the resource bit array has been generated, it may be written into one or more resource bytes, starting for example with the 8 least significant bits of the array and continuing until the full resource bit array has been written into bytes. At step 232, the device checks whether resources for all instances of the current object type have been mapped. If resources for one or more instances have not yet been mapped, then the device returns to step 218, selects a new instance of the data object and performs the determining and mapping steps for the newly selected instance. It will be appreciated that the mapping of resources for multiple instances of a data object may be sequential or may be conducted in parallel. Once resources for all instances of the current object type have been mapped, the device proceeds to step 234, as illustrated in Figure 2c, and checks whether all data objects hosted at the device have been considered. If one or more data objects hosted at the device have not yet been considered, then the device selects, at step 236, the next object type from the ordered sequence of object types that was prepared in step 204. In step 238, the device encodes a difference between the newly selected object type and the preceding object type in the ordered sequence. The encoding of the difference may be binary encoding. Thus if the preceding object type in the ordered sequence was 3303 (temperature sensor) and the next object type in the ordered sequence is 3308 (set point), then the difference between the object types is 5, which may encoded as:

00000101 or hexadecimal 05

Having encoded the difference to the next selected object type, the device returns to step 210 to map instances of the newly selected object type and then to map resources for each of the instances, following steps 210 to 234 of the method. Once all object types in the ordered sequence generated at step 204 have been considered (Yes at step 234), the device then concatenates the various encoded object types, instance bit arrays and resource bit arrays, such that each encoded object type is followed by an instance bit array for that object type, and each instance bit array is followed by resource bit arrays for each of the instances indicated in the instance bit array as being hosted at the device. If included, encoded markers may be inserted at appropriate locations between the encoded bit arrays and object types, as discussed above.

As discussed above, the method 200 for compressing information about data objects hosted at a device may be performed as part of a method for managing such information. The method may thus further comprise the step 242 of either storing the compressed information in a memory or transmitting the compressed information over a communication link. This transmission may be performed as part of a procedure involving the device, such as a registration procedure, discovery procedure or bootstrapping procedure, as discussed in further detail with reference to Figures 5a to 5c.

An example implementation of the method 200 of Figures 2a to 2e is discussed below, with reference to a streamlined implementation 300 of the method 200, illustrated in Figure 3. The example implementation illustrates the compression of information about a device hosting two instances of temperature sensors, three power meter instances and one set point. The object types, instances and optional resources for the example device are set out below in the CoRE weblinks format using IPSO smart objects:

Object types and instances: /3303/1 ></3303/2x/3305/0></3305/1 ></3305/3></3308/1 >

Resources of the six object instances:

</3303/1 /57 OOx/3303/1 /5601 ></3303/1/5602></3303/1/5605></3303/1/5701 >

</3303/2/5700></3303/2/5601 x/3303/2/5602x/3303/2/5605></3303/2/5701 >

</3305/0/5800x3305/0/5801 >

<3305/1/5800x3305/1/5801 >

<3305/3/5800x3305/3/5801 >

<3308/1/5900x3308/1/5701 >

From the above weblinks, it can be seen that the instances of the temperature sensor each have one mandatory resource and four optional resources, while each of the remaining instances of power meters and set point have one mandatory resource and one optional resource. The object models for the data objects above can be found at: http://www.openmobilealliance.org/wp/OMNA LwM2M/LwM2MRegistry.html (as of the date of filing of the present application)

Referring to Figure 3, and considering again the example of the method being conducted by the device, the implementation of the method 200 starts at step 302 and at step 304, the device determines the set of objects. In the illustrated example this includes 3 object types (3303, 3305 and 3308). In step 306, the device encodes the identifier of the first object type in binary to the first bytes of the compressed information: 3303 is encoded to 0000 1 100 1 1 10 01 1 1 or 0CE7 (hex)

In step 308, the device determines the set of instance IDs for the current object type: Object type 3303: instance identifiers 1 and 2.

In step 310, the device maps the instance identifiers to a consecutive integer sequence, such that for each instance identifier i, the ith bit in the instance bit array is set to 1 :

Integer sequence for instance identifiers: 0 1 2 3 4 5 6

Instance identifiers present: 1 2

Instance bit array (starting from least significant bit): 00001 10

Implementation 300 illustrates an instance mapping that sues reserved bits, as in Figure 2e, and in step 312, the device therefore selects the 7 least significant bits in the bit array. In step 314 the device checks if there are any remaining 1 s in the rest of the bit array. In the present example there are no further 1 s in the bit array, so a single byte of instance bit array is output at step 320 with a 0 highest bit (indicating that no further instance array bytes will be included) and the 7 selected bits:

First (and only) byte of the instance bit array: 0000 01 10 or 06 (hex)

If the instance bit array had contained additional 1 s, the device would have output, at step 316, a first instance array byte with a 1 as the highest bit (indicating that an additional instance array byte will follow) and the 7 selected bits. The device would then have returned to step 312 to select the next 7 least significant bits and repeat steps 312, 314 and 316 until there were no remaining 1 s in the instance bit array.

Thus for example, if instances 1 , 2 and 9 had been present at the device, the generation of the instance bit array would have been as follows:

Integer sequence for instance identifiers: 0 1 2 3 4 5 6 7 8 9

Instance identifiers present: 1 2 9

Instance bit array (starting from least significant bit): 10000001 10

First byte of instance bit array: 1000 01 10 or 86 (hex) (Most significant bit set to 1 and 7 least significant bits from the bit array)

Second byte of instance bit array: 0000 0100 or 04 (hex)

(Most significant bit set to 0 and next 7 least significant bits from the bit array)

For simplicity, Figure 3 does not illustrate the encoding of the resources, however this encoding is discussed below.

Each object instance bit array is followed by N resource bit arrays, where N is equal to the number of instances of that particular object (that is the number of 1 s in the object instance bitmap.

As discussed above, the optional resources of an object instance are given positions in the bit array based on an ordered sequence from the object model. This may be the order in which they appear in the object model, or a numerical order of the resource identifiers specified in the object model, or any other ordered sequence obtained from the object model. Continuing the current example, temperature sensor object 3303 has one mandatory resource: 5700, and 6 optional resources: 5601 , 5602, 5603, 5604, 5701 , 5605. As the instance 1 has optional resources 5601 , 5602, 5701 , and 5605 implemented, it would set the first, second, fifth and sixth bits in the resource bit array to 1 :

Ordered sequence of optional resources:

5605 5701 5604 5603 5602 5601

1 1 0 0 1 1

Or 33 (hex)

In some examples, a reserved highest bit may again be used to indicate if additional bytes are included for the resource array. As noted above, mandatory resources may be ignored as they are always implemented. In the present example, the second instance of object temperature sensor has the same resources associated with it and so will have the same resource bit array. Referring again to Figure 3, once resource bit arrays have been generated for all the instances of the selected object type, the device checks, at step 322 whether all objects hosted at the device have been considered. If all objects have not been considered, the next object type is encoded as a difference from the previous object type in step 318. Variable length delta encoding, similar to CoAP options encoding, may be used. This delta encoding of the object types saves a considerable number of bytes, particularly in cases in which the identifiers of object types at the same device are relatively close together. The delta encoding may be applied to any object model with numeric identifiers. In the present example, the next object type is 3305, which is 2 higher than the previous object type of 3303. The delta between the object types can therefore be expressed with single byte 00000010 or 02 (hex). The device then returns to step 308 and encodes instance bit arrays and resource bit arrays for the next object type. Once all object types have been considered, the device exits the implementation at step 324. The following table illustrates the full encoding of the information for the example device:

The encoded information is concatenated so that each encoded object type is followed by an instance bit array and then by the resource bit arrays for the instances in the instance bit array. The full example can therefore be compressed and represented in hex for ease of reading as:

0C E7 06 33 33 02 OB 01 01 01 03 02 01 (13 bytes) This is a very significant saving compared to the approximately 500 bytes that would be required for standard encoding using weblinks.

The above example illustrates compression of information from the CoRE weblinks format as an example. It will be appreciated that the information for compression may alternatively be expressed in other formats including CoRE Link Format represented in JSON, as set out in https://tools.ietf.org/html/draft-ietf-core-links-ison-10, CoRAL, as set out in https://tools.ietf.org/html/draft-hartke-t2trq-coral-06, or SenML. The methods disclosed herein may be applied to information expressed in any of these or other formats. As JSON and CoRAL represent more efficient and compact formats than CoRE weblinks, the saving through compression according to examples of the present disclosure is less that that obtained when compressing from weblinks, but remains significant, so offering significant savings in memory and bandwidth when stored or transmitted. Aspects of the present disclosure also provide a method for decompressing information about data objects hosted at a device. It will be appreciated that it may be desirable for a node to be able to recover weblinks or other format information from the compressed form in which it was stored or transmitted. The same node may be capable of both compressing and decompressing information. Alternatively, in some examples, a single node may only conduct one of the methods of compressing or decompressing, for example if the reverse functionality is not needed for the node to conduct its normal operations. The process for decompressing information will be understood to comprise essentially the steps of the method 100 and/or 200 conducted in reverse.

Figure 4 is a flow chart illustrating process steps in a method 400 for decompressing information about data objects hosted at a device in accordance with aspects of the present disclosure. The data objects conform to an object model that specifies, for a given object type of a data object, an ordered sequence of resources which may be associated with instances of a data object of that object type. The object model may for example comprise a standard model such as the IPSO Smart Objects object model. The device hosting the data objects may be a constrained device as set out above. The device may be operable to run a LWM2M client. The device may be configured to communicate using a RESTful protocol including for example CoAP, HTTP etc, or other loT protocol such as MQTT. The method 400 may be carried out by the device hosting the data objects or by another node, which may be a management node for the device. For example, the method may be carried out by a LWM2M server or a LWM2M bootstrap server. Referring to Figure 4, the method 400 comprises for an instance of a data object hosted at the device as shown at 430a, mapping a resource bit array for the instance of the data object to the ordered sequence of resources which may be associated with instances of the data object in step 420. As illustrated at 420a, each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device. As illustrated at 420b, a value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. The method further comprises, in step 430, determining from the mapped resource bit array which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance of the data object. It will be appreciated that additional decompression steps may be carried out, substantially corresponding to the compression steps of the method 200 and/or 300. The decompression steps of Figure 4 may be carried out as part of a method for managing information about data objects hosted at a device according to examples of the present disclosure, in addition to or as an alternative to the compression steps of Figures 1 , 2a to 2e and 3.

As discussed above, the information compressed according to examples of the present disclosure may be transmitted over a communication link and/or stored as part of one or more processes which may be carried out between the device at which the data objects are hosted and another node. Processes carried out between a device and another node according to the LWM2M specification are set out in the OMA SpecWorks Lightweight Machine to Machine Technical Specification: Core, Candidate Version: 1 .1 - 12 Jun 2018. Figures 5a to 5c are simplified signaling diagrams illustrating compression of information according to examples of the present disclosure in the context of three example processes between a device and another node.

Figure 5a illustrates a bootstrapping process, according to which a device sends a bootstrap request to a LWM2M bootstrap server in step 1 . In step 2, the LWM2M bootstrap server compresses information about data objects to be configured on the device using an example of methods presented in the present disclosure. In step 3, the LWM2M bootstrap server sends a bootstrap response to the device, the response including the compressed information. In step 4, the device stores the compressed information and in step 5, the device decompresses the information and configures data objects on the device in accordance with the information. In the simplified example process of Figure 5a, the compression of the information offers bandwidth savings during the transmission step 3 and memory savings in the storage step 4. It will be appreciated that these resource savings may be particularly significant in a constrained environment, in which bandwidth on communication links and device memory may both be very limited. Compression of the information may for example enable the device to save the information in its memory, when the information in its original, uncompressed form would have been too large for the device’s limited storage capacity. In a further example, (not shown), the LWM2M bootstrap server may transmit the information about objects to the configured on the device in an uncompressed format, and the device may then compress the information on receipt for storage. This may be appropriate for example if bandwidth on the communication link between the device and the LWM2M bootstrap server is not overly constrained, but storage on the device is limited. Figure 5b illustrates a registration process, according to which a device compresses information about data objects hosted on the device in step 1. The device may alternatively retrieve such compressed information in step 1 , having previously stored the information, for example as part of a bootstrapping procedure as set out above. In step 2, the device sends a registration request including the compressed information to a LWM2M server. In step 3, the LWM2M server decompresses the information, and may store it or take other appropriate action. In step 4, the LWM2M server sends a registration response to the device.

Figure 5c, illustrates a discovery process, according to which a LWM2M server sends a discovery request to a device in step 1. In step 2, the device compresses information about data objects hosted on the device. The device may alternatively retrieve such compressed information in step 2, having previously stored the information, for example as part of a bootstrapping procedure as set out above. In step 3, the device sends a discovery response to the LWM2M server, the discovery response including the compressed information. In step 4, the LWM2M server decompresses the information, and may store it or take other appropriate action. As discussed above, the methods 100, 200, 300, 400 may be performed by a node, which maybe a device such as an loT device or M2M device, and which may be a constrained device. The device may be operable to run a LWM2M client. In other examples the node may be a management node for the device, such as a LWM2M server or LWM2M bootstrap server. In the case of a management node, the node may be a physical node or may be a Virtualised Network Function. Figure 6 is a block diagram illustrating an example node 600 which may implement the methods 100, 200, 300, 400 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 650. Referring to Figure 6, the node 600 comprises a processor or processing circuitry 602, a memory 604 and interfaces 606. The memory 604 contains instructions executable by the processor 602 such that the node 600 is operative to conduct some or all of the steps of the method 100, 200 300 and/or 400. The instructions may also include instructions for executing one or more telecommunications and/or data communications protocols. The instructions may be stored in the form of the computer program 650. In some examples, the processor or processing circuitry 602 may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry 602 may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) etc. The memory 604 may include one or several types of memory suitable for the processor, such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive etc.

Figure 7 illustrates functional units in another example of node 700 which may execute examples of the methods 100, 200, 300, 400 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 7 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 7, the node 700 comprises a determining module 720, a mapping module 730 and interfaces 740. The determining module may be for determining, for an instance of a data object hosted at a device, which of the resources in an ordered sequence of resources which may be associated with instances of the data object are associated with the instance. The mapping module may be for mapping the determined resources to a resource bit array, wherein each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device, and wherein a value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. The mapping module may alternatively or additionally be for mapping a resource bit array for an instance of a data object hosted at a device to an ordered sequence of resources which may be associated with instances of the data object, wherein each bit position in the resource bit array corresponds to a position in the ordered sequence of resources which may be associated with instances of a data object having the object type of the data object hosted at the device, and wherein a value of a bit in the resource bit array indicates whether or not the resource whose position in the ordered sequence of resources corresponds to the position of the bit in the resource bit array is associated with the instance of the data object hosted at the device. The determining module may alternatively or additionally be for determining from the mapped resource bit array which of the resources in the ordered sequence of resources which may be associated with instances of the data object are associated with the instance of the data object. The term module may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, processors, processing circuitry, memories, logic, solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described in the present disclosure.

Examples of the present disclosure thus provide methods for compression and decompression of information about data objects hosted at a device. Delta encoding of object types may be combined with bit arrays based on a data object model to compress object instance and resource information. The resulting compressed information may be stored and/or maybe transmitted over a communication link, resulting in an efficient storage of the resource implementation state and in a reduction of the bandwidth required for processes such as bootstrapping, registration and discovery between a device and another node, for example an loT server. The compression efficiency achieved with the examples of the methods of the present disclosure is considerably higher than that achieved by existing solutions.

It will be appreciated that examples of the present disclosure may be virtualised, such that the methods and processes described herein may be run in a cloud environment.

The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim,“a” or“an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.