[0001] Technical Field

[0002] The technology disclosed herein relates generally to the field of data

communication, and in particular to methods and devices for registering a Lightweight Machine-to-Machine (LWM2M) client device with an LWM2M server, to an LWM2M client device, and an LWM2M server.

[0003] Background

[0004] Machine to machine (M2M) is a concept encompassing devices, such as for instance sensors and so-called smart devices, using a network for communicating with remote applications of e.g. a server of Internet. Such communication may, for example, be for the purpose of monitoring and control. Internet of Things (loT) refers to a network of objects ("things") with network connectivity, and M2M may be considered an integral part of loT. Together M2M/loT covers a huge set of devices that communicate with each other directly and across networks based on various communication or access media, using short range wireless technologies (e.g. Bluetooth or WiFi) as well as long range technologies (e.g. radio access technologies, such as 3G, 4G, New Radio, etc.).

[0005] Lightweight M2M (LWM2M) is a standard promulgated by OMA SpecWorks that is focused on constrained cellular devices and other M2M devices. The standard defines an efficient device-server interface based on open Internet Engineering Task Force (IETF) standards, such as Constrained Application Protocol (CoAP) and Datagram Transport Layer

Security (DTLS). The LWM2M enabler includes device management and service enablement for LWM2M devices, and uses a light and compact protocol as well as an efficient resource data model to fit on constrained LWM2M devices.

[0006] LWM2M client devices, or LWM2M clients, typically have limited processing and storage capabilities as well as limited power sources. The power consumption of the LWM2M client is hence an issue and needs to be considered to keep the device functional as long as possible without maintenance. In view of this, there is a need to make overhead operations, such as the LWM2M client registration process, as efficient as possible.

SUMMARY

[0007] A method of registering a lightweight machine-to-machine, LWM2M, client to an LWM2M server includes providing (502) a plurality of LWM2M registration parameters for the LWM2M client, providing (504) a hash value generated using the plurality of LWM2M registration parameters, generating (506) an LWM2M registration message including the hash value, and transmitting (508) the LWM2M registration message to the LWM2M server.

[0008] The LWM2M message may exclude the plurality of LWM2M registration parameters.

[0009] The plurality of LWM2M registration parameters includes a first plurality of LWM2M registration parameters and the hash value includes a first hash value, the method further including providing a second hash value associated with a second plurality of LWM2M registration parameters for the LWM2M client. The LWM2M registration message may further include the second hash value and exclude the second plurality of LWM2M registration parameters. [0010] The method may further include receiving (602) a request message from the

LWM2M server requesting the LWM2M registration parameters associated with the hash value, and transmitting (604) the LWM2M registration parameters associated with the hash value to the LWM2M server.

[0011] The LWM2M registration parameters may include registration object links that identify objects and/or object instances associated with the first LWM2M client.

[0012] Providing the hash value may include generating a string including the plurality of registration parameters, and applying a hashing algorithm to the string.

[0013] The plurality of registration parameters may include registration object links that identify objects and/or object instances associated with the LWM2M client. The hash value may uniquely identify the plurality of LWM2M registration parameters.

[0014] A lightweight machine-to-machine, LWM2M, client device (100) according to some embodiments includes a processor circuit (103), a transceiver (102) coupled to the processor circuit, and a memory (105) coupled to the processor circuit, wherein the memory includes machine readable program instructions that, when executed by the processor circuit, cause the LWM2M client device to perform operations of providing (502) a plurality of LWM2M registration parameters for an LWM2M client (110) in the LWM2M client device, providing (504) a hash value generated using the plurality of LWM2M registration parameters, generating (506) an LWM2M registration message including the hash value, and transmitting (508) the LWM2M registration message to the LWM2M server.

[0015] A method of registering a first lightweight machine-to-machine, LWM2M, client to an LWM2M server device according to some embodiments includes receiving (702) an LWM2M registration message at the LWM2M server from the first LWM2M client, the LWM2M registration message including a hash value, identifying (704) a plurality of LWM2M registration parameters for the first LWM2M client associated with the hash value, registering (706) the first LWM2M client using the plurality of LWM2M registration parameters, and transmitting (708) an acknowledgement message to the first LWM2M client.

[0016] Identifying the plurality of LWM2M registration parameters for the first LWM2M client associated with the hash value may include looking up the plurality of LWM2M registration parameters in an LWM2M registration parameter database based on the hash value.

[0017] In some embodiments, identifying the plurality of LWM2M registration parameters for the first LWM2M client associated with the hash value may include transmitting a message including the hash value to the first LWM2M client, wherein the message requests the plurality of LWM2M registration parameters from the first LWM2M client.

[0018] In some embodiments, identifying the plurality of LWM2M registration parameters for the first LWM2M client associated with the hash value may include requesting the plurality of LWM2M registration parameters from a third party registration service that may be associated with a manufacturer of the first LWM2M client.

[0019] The method may further include transmitting a request message to the first LWM2M client requesting a list of objects in response to the LWM2M registration message, and receiving the plurality of LWM2M registration parameters in response to the request message. [0020] The method may further include storing the hash value and the plurality of

LWM2M registration parameters in a database for use with a subsequent registration message from a further LWM2M client.

[0021] The method may further include identifying (802) a second set of LWM2M registration parameters for the first LWM2M client associated with the second hash value, and registering (804) the first LWM2M client using the first and second sets of LWM2M registration parameters.

[0022] The method may further include receiving (902) a second LWM2M registration message at the LWM2M server from a second LWM2M client, the LWM2M registration message including the hash value, identifying (904) the plurality of LWM2M registration parameters for the second LWM2M client associated with the hash value, registering (906) the second LWM2M client using the plurality of LWM2M registration parameters, and transmitting (908) an acknowledgement message to the second LWM2M client.

[0023] A lightweight machine-to-machine, LWM2M, server (200) according to some embodiments includes a processor circuit (203), a network interface (207) coupled to the processor circuit, and a memory (205) coupled to the processor circuit, wherein the memory includes machine readable program instructions that, when executed by the processor circuit, cause the LWM2M server to perform operations of receiving (702) an LWM2M registration message at the LWM2M server from the first LWM2M client, the LWM2M registration message including a hash value, identifying (704) a plurality of LWM2M registration parameters for the first LWM2M client associated with the hash value, registering (706) the first LWM2M client using the plurality of LWM2M registration parameters, and transmitting (708) an acknowledgement message to the first LWM2M client.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 illustrates an LWM2M architecture.

[0025] Figure 2 is a flow diagram illustrating various conventional operations of an LWM2M client and an LWM2M server.

[0026] Figure 3A is a table illustrating an example of objects that may be supported by an LWM2M client.

[0027] Figure 3B is a table illustrating an example of objects that may be instantiated an LWM2M client.

[0028] Figure 4 is a flow diagram illustrating various operations of an LWM2M client and an LWM2M server according to some embodiments of the inventive concepts.

[0029] Figures 5 and 6 are flowcharts illustrating operations of an LWM2M client according to some embodiments of the inventive concepts.

[0030] Figures 7, 8 and 9 are flowcharts illustrating operations of an LWM2M server according to some embodiments of the inventive concepts.

[0031] Figure 10 is a block diagram of an LWM2M client device according to some embodiments of the inventive concepts.

[0032] Figure 11 is a block diagram illustrating functional modules of an LWM2M client device according to some embodiments of the inventive concepts. [0033] Figure 12 is a block diagram of an LWM2M server according to some embodiments of the inventive concepts.

[0034] Figure 13 is a block diagram illustrating functional modules of an LWM2M server according to some embodiments of the inventive concepts.

DESCRIPTION OF EMBODIMENTS

[0035] Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.

[0036] The following description presents various embodiments of the disclosed subject matter. These embodiments are presented as teaching examples and are not to be construed as limiting the scope of the disclosed subject matter. For example, certain details of the described embodiments may be modified, omitted, or expanded upon without departing from the scope of the described subject matter.

[0037] Some embodiments described herein may provide systems/methods that are capable of more efficiently registering LWM2M client devices to LWM2M servers in terms of power consumption and/or bandwidth requirements [0038] In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding. In other instances, detailed descriptions of well- known devices, circuits, and methods are omitted so as not to obscure the description with unnecessary detail. Same reference numerals refer to same or similar elements throughout the description.

[0039] Constrained Application Protocol (CoAP) is an example of a protocol designed for Internet of Things (loT) applications in constrained nodes and constrained networks. CoAP provides a request-response based RESTful communication architecture between constrained devices or between constrained devices and nodes in the Internet. CoAP can easily be integrated to World Wide Web (WWW) ("the web") and web services by translating CoAP messages to Hypertext Transfer Protocol (HTTP) messages.

[0040] The OMA SpecWorks Device Management (OMA DM) LWM2M protocol is a light and compact device management protocol that is used for managing loT devices and their resources. LWM2M runs on top of CoAP, which either uses User Datagram Protocol (UDP), Transmission Control Protocol (TCP) or Systems Management Server (SMS) bindings. Hence, LWM2M is compatible with any constrained device which supports CoAP. LWM2M defines three components: the LWM2M Client, the LWM2M Server and the LWM2M Bootstrap Server. To maintain communication between these components, various LWM2M interfaces are defined, as discussed herein.

[0041] The LWM2M client contains several LWM2M objects with several resources. The

LWM2M server can execute commands on these resources to manage the client, including, for example, commands to read, delete or update the resources. LWM2M clients are generally constrained devices in terms of processing capacity, power source, memory etc.

[0042] The LWM2M server manages LWM2M clients by sending management commands to them.

[0043] Figure 1 illustrates an LWM2M architecture including an LWM2M server 200 and an LWM2M client application 110 (sometimes also denoted simply LWM2M client 110 or client 110) running on an LWM2M client device 100, e.g. a M2M device such as a sensor. Although only a single LWM2M client 110 is shown in Figure 1, multiple LWM2M clients 110 may operate on a single LWM2M client device 100. To maintain the communication between the LWM2M client 100, LWM2M server 200 and an LWM2M bootstrap server (not shown in Figure 1), the following LWM2M interfaces are defined:

[0044] Bootstrapping: The LWM2M bootstrap server sets the initial configuration on the LWM2M client 110 when it boots.

[0045] Client Registration: The LWM2M client 110 registers to one or more LWM2M servers 200 when the bootstrapping is completed. The client registration interface is described in more detail below.

[0046] Device Management and Service Enablement: The LWM2M server 200 can send management commands to LWM2M clients 110 to perform management actions on LWM2M resources of the client 110. Access control object of the client 110 determines the set of actions the server 200 can perform. [0047] Information Reporting: As a feature of CoAP Observe-Notify mechanism,

LWM2M clients 110 can initiate the communication to LWM2M server 200 and report information in the form of notifications.

[0048] Interfaces between the LWM2M server 200 and the LWM2M client 110 thus include: bootstrapping, which may be pre-provisioned or client/server initiated; client registration, wherein the client and its objects are registered; device management and service enablement, providing server access to objects or resources; and information reporting, enabling notifications with new resource values.

[0049] The LWM2M client 110 includes a number of object instances. An object is a collection of resources; a resource is a piece of information that can be read, written or executed. Each resource may have multiple instances (e.g. height H, weight W, length L).

Objects and resources are identified by a 16-bit integer, while instances are identified by an 8- bit integer. Objects and resources may be accessed with simple Uniform Resource Identifiers (URIs).

[0050] Client Registration Interface

[0051] The Client Registration Interface is used by an LWM2M client 110 to register with one or more LWM2M servers 200, to maintain each registration, and to de-register from an LWM2M server 200. When registering, the LWM2M client 110 performs the "Register" operation and provides the properties required by the LWM2M server 200 (e.g. the supported Objects and existing Object Instances) as well as optional parameters (e.g. Endpoint Client Name). The LWM2M client 110 maintains the registration and communications session(s) with each LWM2M server 200 based on the configured parameters (e.g. Lifetime, Queue Mode). The LWM2M client periodically performs an update of its registration information to the registered

LWM2M server(s) 200 by performing the "Update" operation.

[0052] Registration is performed when an LWM2M client 110 sends a "Register" operation to the LWM2M Server. After the LWM2M client device 100 is turned on and the bootstrap procedure has been completed, the LWM2M client 110 performs a "Register" operation to each LWM2M server 200 for which the LWM2M client 110 has a Server Object Instance. The registration process is illustrated in Figure 2.

[0053] As shown in Figure 2, The "Register" operation may include the Endpoint Client Name parameter ("ep=") along with other parameters. Upon receiving a "Register" operation from the LWM2M client 110, the LWM2M server 200 records the connection information of the Registration message (e.g. source IP address and port or MSISDN) and uses this information for all future interactions with that LWM2M client 110.

[0054] Brief reference is made to Figure 3A, which is a table showing an example of object versions, or object types, that may be supported by an LWM2M client 110. Each object version has an associated Object ID. The payload of the "Register" operation identifies the object types supported by the LWM2M client 100. Thus, for example, for an LWM2M client 110 supporting LWM2M Server, Access Control, Device, Connectivity Monitoring and Firmware Update objects shown in Figure 3A, the payload of the "Register" operation would simply be:

</l>, </2>, </3>, </4>, </5> [0055] Brief reference is now made to Figure 3B, which is a table showing an example of an LWM2M client 110 that supports LWM2M Server, Access Control, Device, Connectivity Monitoring and Firmware Update objects, some of which are already instantiated. Each instantiated object is identified by an Object ID and an Object Instance ID. If object instances are already available on the LWM2M client 110 at the time of registration, then the payload of the "Register" operation identifies the objects by Object ID and Object Instance ID. For example, using the example of Figure 3B, the format of the "Register" operation payload would be:

</1/0>,</1/1>,</2/0>,</2/1>,</ 2/2>,</2/3>,</2/4>,</3/0>,</4/0>, </5>

[0056] If the LWM2M client 110 supports the JSON data format for all the objects, it may inform the LWM2M server 200 by including the content type in the root path link using the ct= link attribute. An example is as follows (note that the content type value 110 is the value assigned in the CoAP Content-Format Registry for the SenML JSON format used by LWM2M).

</>;ct=110, </1/0>,</1/1>,</2/0>,</2/1>,</2/2 >,</2/3>,</2/4>,</3/0>,</4/0>,< ;/5>

[0057] The "Register" operation may take the form of an HTTP POST command transmitted to the LWM2M server 200. For example, a POST command transmitted to the URI "/rd" of an LWM2M server 200 that implements the "Register" operation for an LWM2M client 110 having an endpoint name of "epname" may be the following: POST /rd?ep=epname&b=SQ </>; ct=11543, </1/0>,</1/1>, </2/0>,</2/l>,

</2/2>,</2/3>, </2/4>,</3/0>, </4/0>,</5>

[0058] Due to the size of the payload, the message carrying the "Register" operation may be hundreds of bytes in size, and may represent a substantial overhead burden to the LWM2M client device 100. In particular, the "Register" operation arguably carries one of the largest payloads that is sent in LWM2M. Considering that a Registration message is sent at least once by every managed device, and that it is often the same for each device type (i.e. every device of a given type very often registers the same sensors and actuators) it would be desirable to reduce the size of the message if possible.

[0059] Some embodiments described herein are based on a realization that the object sets referenced in the payload of the "Register" operation are often very similar, or even identical, across devices of the same type from the same manufacturer. Simple devices from different manufacturers are also likely to have similar sets of objects and more complex devices are likely to consist of multiple similar sets.

[0060] Accordingly, some embodiments described herein provide short identifiers derived from the registration information. The short identifier may be included in the

Registration message in place of the lengthy registration parameters carried in the payload of the "Register" operation. Some embodiments provide a mechanism for the LWM2M server 200 to determine that the short identifier is that of a known registration, as well as a way to request full registration if the short identifier is unknown. [0061] Operations according to some embodiments are illustrated in the flow diagram of Figure 4, which illustrates various scenarios involving LWM2M clients 110A, HOB and an LWM2M server 200. A conventional LWM2M registration operation is illustrated as a Basic Case in which the LWM2M client 110A sends a Registration message 402 to the LWM2M server 200 in the following form:

POST /rd?ep=epname&b=SQ </>; ct=11543, </1/0>,</1/1>, </2/0>,</2/l>,

</2/2>,</2/3>, </2/4>,</3/0>, </4/0>,</5>

[0062] The LWM2M server 200 receives the command 402 and registers the LWM2M client 110A. Upon successful registration, the LWM2M server 200 returns an

acknowledgement to the LWM2M client 110A indicating successful registration and including the URI assigned to the LWM2M client 110A as follows:

ACK 2.01 /rd/92nf

[0063] To reduce the size of the payload of the Registration message, some

embodiments provide a short code that represents the registration parameters that would otherwise be included in the Registration message. The LWM2M client 110A includes the short code in the payload of the Registration message in place of the parameters. Assuming the LWM2M server 200 is aware of or can obtain the registration parameters represented by the short code, the LWM2M server 200 can perform the registration based on the short code. In this way, the size of the Registration message can be considerably reduced, thereby reducing bandwidth needed to carry the Registration message and/or power consumption by the LWM2M client device 100 in transmitting the Registration message.

[0064] In some embodiments, the short code may be generated as a hash value of the registration parameters by performing a hash function that takes a list of registration parameters as an input and generates a fixed length hash value as an output. The generation of hash values is well known in the art, and there are many suitable algorithms for generating hash values, such as SHA-1, SHA-256, MD4, etc. The algorithm for generating the short code need not be a secure hashing algorithm, however. In some embodiments, a 16- or 32- bit checksum, cyclic redundancy check (CRC) code, or the like, may be generated as a short code or hash value to represent a set of registration parameters. The term "hash value" is used herein in a generic sense to represent all such codes.

[0065] The hashing function used to generate the hash value should output a large enough hash value that collisions are statistically unlikely. That is, it should be unlikely that applying the hashing function to two different sets of registration parameters would result in the same hash value.

[0066] In one example, where a string, s, of registration parameters that would be transmitted in the payload of a Registration message is "</1/0>,</1/1>, </2/0>,</2/l>, </2/2>,</2/3>, </2/4>,</3/0>, </4/0>,</5>", a hash value may be generated by processing the string with a hashing function, f(), that outputs a hash value, h, as follows: h = f(s) [1] [0067] In one example, applying the hashing function f() to the string of registration parameters results in h = 222. The Registration message may then be constructed as:

POST /rd?ep=epname&b=SQ h=222

[0068] Accordingly, the Registration command excludes the string of registration parameters that would normally be sent and instead includes a parameter identifying the hash value, "h=222" in the payload.

[0069] Upon receipt of the Registration command, the LWM2M server 200 parses the command to obtain the hash value and proceeds to look up the value of the string of registration parameters based on the hash value, for example, from a database of hash values and associated sets of registration parameters. Brief reference is made to Figure 12, which is block diagram illustrating various aspects of an LWM2M server 200. As shown therein, the LWM2M server 200 may include a database 210 that includes a plurality of entries containing hash values and associated sets of registration parameters, which may be stored, for example, in a key/value arrangement. An example of data that may be stored in such a database is shown in Table 1, below.

Table 1 - Hash value/Registration parameter database

[0070] When the LWM2M server 200 receives a Registration message from an LWM2M client 110A containing a hash value rather than a list of registration parameters in the payload, the LWM2M server 200 checks the database 210 to determine if the hash value is already known, and if so, retrieves the corresponding set of registration parameters from the database 210 and uses the retrieved set of registration parameters to register the LWM2M client 110A.

[0071] Referring again to Figure 4, these operations are illustrated in the example labeled Case 1. In particular, the LWM2M client 110A sends a Registration message 406 to the LWM2M server 200 having the following form:

POST /rd?ep=epname&b=SQ h=222

[0072] The LWM2M server 200 parses the Registration message and determines that the payload of the message contains a hash value of 222 rather than a list of registration parameters. The LWM2M server 200 checks the database 210 and determines that the hash value of 222 is already known and corresponds to the set of registration parameters

"</1/0>,</1/1>, </2/0>,</2/l>, </2/2>,</2/3>, <2,4>,</3/0>,</4/0>,</5>." The LWM2M server 200 proceeds to register the LWM2M client 110A using the obtained set of registration parameters and returns a confirmation message 408 to the LWM2M client 110A in the form of an ACK message including the URI assigned to the LWM2M client 110A ("/rd/ls45").

[0073] Still referring to Figure 4, if the LWM2M server 200 determines that the hash value included in the Registration message is not already known, the LWM2M server 200 may query the LWM2M client 110A to obtain the set of registration parameters corresponding to the hash value. In Figure 4, this is illustrated as Case 2. In that case, the LWM2M client 110A sends a Registration message 410 to the LWM2M server 200 having the following form:

POST /rd?ep=epname&b=SQ h=453

[0074] The LWM2M server 200 parses the Registration message and determines that the payload of the message contains a hash value of 453 rather than a list of registration parameters. The LWM2M server 200 checks the database 210 and determines that the hash value of 453 is not already known. In this example, the LWM2M server 200 proceeds to register the LWM2M client 110A without any registration parameters and sends a confirmation message 412 back to the LWM2M client 110A confirming registration.

[0075] The LWM2M server 200 then determines at block 413 that it should query the LWM2M client 110A to obtain the set of registration parameters associated with the hash value provided by the LWM2M client 110A in the Registration message 410. The LWM2M server 200 may accomplish this by issuing an FITTP GET command 414 to the LWM2M client 110A requesting the contents of the ".well-known/core" object of the LWM2M client 110A as follows: GET .well-known/core

[0076] In response, the LWM2M client 110A transmits an acknowledgement message 416 to the LWM2M server 200 containing the registration parameters (i.e., a list of objects) associated with the hash value, for example:

ACK </1/0>,</1/1>, </2/0>,</2/l>,</2/2>,</3/0>, </4/0>,</5>

[0077] Upon receipt of the acknowledgement message 416, the LWM2M server 200 may store the hash value and associated set of registration parameters as a new entry in the database 210.

[0078] In some embodiments, the LWM2M server 200 may query the LWM2M client 110A directly for the registration parameters associated with a hash, rather than querying the .well-known/core object. For example, the LWM2M server 200 may transmit a GET command to the LWM2M client 110A specifying the hash value in question as follows:

GET /h453

[0079] The LWM2M client 110A may respond to the GET command with the registration parameters corresponding to the identified hash value as shown above, e.g.: </1/0>,</1/1>, </2/0>,</2/l>, </2/2>,</3/0>, </4/0>,</5>

[0080] In some embodiments, the LWM2M server 200 may query the LWM2M client 110A for the registration parameters corresponding to the unrecognized hash value before completing the registration of the LWM2M client 110A.

[0081] In still further embodiments, the LWM2M server 200 may obtain the registration parameters from a third-party database, such as a database provided by a manufacturer of devices that may store default sets of registration parameters and associated hash values.

[0082] Continuing the example of Case 2 in Figure 4, after the LWM2M server 200 has stored the hash value ("453") along with the associated set of registration parameters

("</1/0>,</1/1>, </2/0>,</2/l>, </2/2>,</3/0>, </4/0>,</5>") in the database 210, the LWM2M server 200 may receive a subsequent registration request 422 from a second LWM2M client HOB. For example, the LWM2M server 200 may receive a message 422 from the second LWM2M client HOB in a POST command as follows:

POST /rd?ep=epname2&b=SQ </>; h=453

[0083] The LWM2M server 200 checks the database 210 and determines that the hash value of 453 is already known and corresponds to the set of registration parameters

"</1/0>,</1/1>, </2/0>,</2/l>, </2/2>,</3/0>,</4/0>,</5>." The LWM2M server 200 proceeds to register the second LWM2M client HOB using the obtained set of registration parameters and returns a confirmation message 424 to the second LWM2M client HOB in the form of an ACK message including the URI assigned to the second LWM2M client HOB ("/rd/4d52").

[0084] In some embodiments, the Registration message transmitted by an LWM2M client 110 may include multiple hash values that reference multiple sets of registration parameters. For example, a POST command that transmits a Registration message may be constructed as follows:

POST /rd?ep=epname&b=SQ </>; h=354 h=732

[0085] Upon receipt of the registration command, the LWM2M server 200 checks the database 210 and determines that hash value h=354 corresponds to the parameter string "</1/0>,</1/1>,</1/2>,</2/0>, <2,l>,</2/2>,</2/3>" while the hash value h=732 corresponds to the parameter string "</4/0>,</4/l>,</4/2>". The LWM2M server 200 would therefore register the LWM2M client 110 using the combined registration parameter set of

"</1/0>,</1/1>,</1/2>,</2/0>, <2,1>,</2/2>,</2/3>,</4/0>,</4/1& gt;,</4/2>."

[0086] The LWM2M client 110 may use multiple hash values, or generate hash values only from a set of registration parameters, based on the knowledge of what objects are likely to be shared across many devices. For example, one hash value could be generated for the basic management objects (0-9) and another for the basic IPSO smart objects (3200-3350). There may also be manufacturer specific rules for selecting which objects to include in a given set of registration parameters. Similarly, certain objects that are likely to be very different across devices could be excluded from the hash values to promote reusability of the hash values. [0087] In some embodiments, a Registration message may include both a set of registration parameters and a hash value, such as, for example:

POST /rd?ep=epname&b=SQ </>; h=354 </4/0>,</4/l>,</4/2>

[0088] Again, the LWM2M server 200 would check the database 210 and determine that hash value h=354 corresponds to the parameter string "</1/0>,</1/1>,</1/2>,</2/0>, <2,l>,</2/2>,</2/3>." The LWM2M server 200 would therefore register the LWM2M client 110 using the combined registration parameter set of "</1/0>,</1/1>,</1/2>,</2/0>,

<2, l>,</2/2>,</2/3 >,</ 4/0>,</ 4/ 1 >, </ 4/2>."

[0089] A method of registering an LWM2M client to an LWM2M server is illustrated in Figure 5. As shown therein, the method includes providing (502) a plurality of LWM2M registration parameters for the LWM2M client device, providing (504) a hash value generated using the plurality of LWM2M registration parameters, generating (506) an LWM2M

Registration message including the hash value, and transmitting (508) the LWM2M Registration message to the LWM2M server.

[0090] Referring to Figure 6, the method may further include receiving (602) a request message from the LWM2M server requesting the LWM2M registration parameters associated with the hash value, and transmitting (604) the LWM2M registration parameters associated with the hash value to the LWM2M server. [0091] The LWM2M registration parameters may include registration object links that identify objects and/or object instances associated with the first LWM2M client device.

Providing the hash value may include generating a string including the plurality of registration parameters, and applying a hashing algorithm to the string.

[0092] The plurality of registration parameters may include registration object links that identify objects and/or object instances associated with the LWM2M client device. The hash value may uniquely identify the plurality of LWM2M registration parameters.

[0093] Figure 7 is a flowchart illustrating a method of registering a first lightweight machine-to-machine, LWM2M, client device to an LWM2M server device according to some embodiments. The method includes receiving (702) an LWM2M Registration message at the LWM2M server from the first LWM2M client device, the LWM2M Registration message including a hash value, identifying (704) a plurality of LWM2M registration parameters for the first LWM2M client device associated with the hash value, registering (706) the first LWM2M client device using the plurality of LWM2M registration parameters, and transmitting (708) an acknowledgement message to the first LWM2M client device.

[0094] Referring to Figure 8, the method may further include identifying (802) a second set of LWM2M registration parameters for the first LWM2M client device associated with the second hash value, and registering (804) the first LWM2M client device using the first and second sets of LWM2M registration parameters.

[0095] Referring to Figure 9, the method may further include receiving (902) a second LWM2M Registration message at the LWM2M server from a second LWM2M client device, the LWM2M Registration message including the hash value, identifying (904) the plurality of LWM2M registration parameters for the second LWM2M client device associated with the hash value, registering (906) the second LWM2M client device using the plurality of LWM2M registration parameters, and transmitting (908) an acknowledgement message to the second LWM2M client device.

[0096] Figure 10 is a block diagram illustrating elements of a LWM2M client device 100 according to some embodiments. As shown, the LWM2M client device 100 may include a wireless transceiver circuit 102 for providing a wireless communication interface with network nodes, such as base stations, access points, etc. The LWM2M client device 100 may also include a processor circuit 103 (also referred to as a processor) coupled to the transceiver circuit 102 and a memory circuit 105 (also referred to as memory) coupled to the processor circuit. The memory circuit 105 may include computer readable program code that when executed by the processor circuit 103 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 103 may be defined to include memory so that a separate memory circuit is not required.

[0097] As discussed herein, operations of the LWM2M client device 100 may be performed by processor 103 and the wireless transceiver circuit 102. For example, the processor 103 may control the wireless transceiver circuit 102 to transmit communications to one or more other network nodes and/or to receive communications from one or more other network nodes. Moreover, modules may be stored in memory 105, and these modules may provide instructions so that when instructions of a module are executed by processor 103, processor 103 performs respective operations (e.g., operations discussed herein with respect to an LWM2M client device 100).

[0098] Figure 11 illustrates various functional modules of an LWM2M client device 100 according to some embodiments. The functional modules may be stored, for example, in the memory 105 of the LWM2M client device 100. The functional modules may include a registration parameter module 122, a hash value module 124 and a registration message generation module 126 that are part of an LWM2M client 110 instantiated by the LWM2M client device 100.

[0099] The registration parameter module 122 may perform operations of providing (502) a plurality of LWM2M registration parameters for the LWM2M client. The hash value module 124 may perform operations of providing (504) a hash value or generating a hash value using the plurality of LWM2M registration parameters, and the registration message generation module 126 may perform operations of generating (506) an LWM2M registration message including the hash value.

[0100] The LWM2M client device 100 may further include a transceiver module 128 that performs operations of transmitting (508) the LWM2M registration message to the LWM2M server.

[0101] Figure 12 is a block diagram illustrating elements of an LWM2M server 200 of a communication system according to some embodiments. As shown, the LWM2M server 200 may include a network interface circuit 207 (also referred to as a network interface) configured to provide communications with other nodes (e.g., with base stations, RAN nodes and/or core network nodes) of the communication network. The LWM2M server 200 may also include a processor circuit 203 (also referred to as a processor) coupled to the network interface 207, and a memory circuit 205 (also referred to as memory) coupled to the processor circuit. The memory circuit 205 may include computer readable program code that when executed by the processor circuit 203 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 203 may be defined to include memory so that a separate memory circuit is not required.

[0102] As discussed herein, operations of the LWM2M server 200 may be performed by processor 203, the wireless transceiver circuit 202 and/or the network interface 207. For example, the processor 203 may control the network interface 207 to transmit communications through network interface 207 to one or more other network nodes and/or LWM2M client devices and/or to receive communications through network interface from one or more other network nodes and/or LWM2M client devices. Moreover, modules may be stored in memory 205, and these modules may provide instructions so that when instructions of a module are executed by processor 203, processor 203 performs respective operations (e.g., operations discussed herein).

[0103] Figure 13 illustrates various functional modules of an LWM2M server 200 according to some embodiments. The functional modules may be stored, for example, in the memory 205 of the LWM2M server 200. The functional modules may include a registration module 222 and a transceiver module 224. The transceiver module 224 may perform operations of receiving (702) an LWM2M registration message at the LWM2M server from a first LWM2M client, the LWM2M registration message including a hash value and transmitting (708) an acknowledgement message to the first LWM2M client. The registration module 222 may perform operations of identifying (704) a plurality of LWM2M registration parameters for the first LWM2M client associated with the hash value and registering (706) the first LWM2M client using the plurality of LWM2M registration parameters.

[0104] Explanations are provided below for abbreviations that are mentioned in the present disclosure.

Abbreviation Explanation

CoAP Constrained Application Protocol

M2M Machine-to-Machine

LWM2M Lightweight Machine-to-Machine

RAN Radio Access Network

loT Internet of Things

WWW World Wide Web

DTLS Datagram Transport Layer Security

IETF Internet Engineering Task Force

HTTP Hypertext Transport Protocol

OMA DM OMA SpecWorks Device Management

UDP User Datagram Protocol

TCP Transmission Control Protocol

[0105] Further definitions and embodiments are discussed below.

[0106] In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. [0107] When an element is referred to as being "connected", "coupled",

"responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected",

"responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

[0108] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0109] As used herein, the terms "comprise", "comprising", "comprises",

"include", "including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

[0110] Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

[0111] These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer- readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.

Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0112] It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the

functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated.

Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0113] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.