Method and related device for LWM2M client status synchronization

Abstract

A method for re - establishing a connection between an LWM2M client (110) and an LWM2M server 200 after reconnecting the LWM2M client (110) to the LWM2M server, comprising: at the LWM2M client (110), determining (706) the state of the LWM2M client (110) device before the reconnection of the LWM2M client; sending (708) an indication of the state of the LWM2M client (110) before the reconnection of the LWM2M client (110) to the LWM2M server (200); and receiving (710) from the LWM2M server a response indicating whether the indicated state of the LWM2M client (110) is an expected state or an unexpected state.

Description

Technical Field

[0001] The technology disclosed herein generally relates to the field of data communication, and particularly to methods and devices for synchronizing the state of a lightweight machine-to-machine (LWM2M) client device with an LWM2M server, an LWM2M client device, and an LWM2M server. Background Art

[0002] Machine-to-machine (M2M) is the concept of devices (such as sensors and so-called smart devices) that communicate with remote applications on a server, such as the Internet, using a network. Such communication can be used, for example, for monitoring and control purposes. The Internet of Things (IoT) refers to a network of objects ("things") with network connectivity, and M2M can be considered a major part of the IoT. At the same time, M2M / IoT covers a vast set of devices that communicate directly and across networks with each other based on various communication or access media, using short-range wireless technologies (such as Bluetooth or WiFi) as well as long-range technologies (such as radio access technologies, such as 3G, 4G, New Radio, etc.).

[0003] Lightweight M2M (LWM2M) is a standard promulgated by OMA SpecWorks that focuses on constrained cellular devices and other M2M devices. The standard defines an effective device-server interface based on open Internet Engineering Task Force (IETF) standards, such as the Constrained Application Protocol (CoAP) and Datagram Transport Layer Security (DTLS). The LWM2M enabler includes device management and service enabling for LWM2M devices and uses a light and compact protocol as well as an effective resource data model to be installed on constrained LWM2M devices.

[0004] An LWM2M client device or LWM2M client typically has limited processing and storage capabilities and limited power. Therefore, the power consumption of an LWM2M client is a concern and needs to be considered to keep the device functioning as long as possible without maintenance. Given this, it is necessary to perform overhead operations, such as the LWM2M client registration process, as efficiently as possible. Summary of the Invention

[0005] A lightweight machine-to-machine (LWM2M) client device includes: a processor circuit; a transceiver coupled to the processor circuit; and a memory 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 that include: at the LWM2M client, determining a state of the LWM2M client device prior to the LWM2M client reconnecting to the LWM2M server; sending an indication of the state of the LWM2M client prior to the LWM2M client's reconnection to the LWM2M server; and receiving from the LWM2M server a response indicating whether the indicated state of the LWM2M client is an expected state or an unexpected state of the LWM2M client.

[0006] A method for re-establishing a connection between an LWM2M client and an LWM2M server after reconnection of the LWM2M client includes: at the LWM2M client, determining a state of the LWM2M client device prior to the LWM2M client's reconnection; sending an indication of the state of the LWM2M client prior to the LWM2M client's reconnection to the LWM2M server; and receiving from the LWM2M a response indicating whether the indicated state of the LWM2M client is an expected state or an unexpected state of the LWM2M client.

[0007] If the response from the LWM2M server indicates that the indicated state of the LWM2M client is outdated, the method may further include: synchronizing the state of the LWM2M client with the LWM2M server.

[0008] The state of the LWM2M client prior to the LWM2M client's reconnection can be determined by obtaining an indication of the state of the LWM2M client prior to the LWM2M client's reconnection.

[0009] In some embodiments, the method may further include: prior to reconnection of the LWM2M client, determining the state of the LWM2M client; generating an indication of the state of the LWM2M client based on the determined state of the LWM2M client; and storing the indication of the state of the LWM2M client.

[0010] In some embodiments, the indication of the state of the LWM2M client may include a status counter or a generation counter.

[0011] In some embodiments, the indication of the state of the LWM2M client may include a digest value generated as a function of a state modification message sent or received by the LWM2M client. The state modification message may include, for example, a registration message, an observation subscription message, and / or an observation data transfer.

[0012] The digest value may include a hash value generated using a hash function applied to the status modification message. In some embodiments, the digest value may include a checksum value generated using a checksum function applied to the status modification message.

[0013] The indication of the state of the LWM2M client may include a digest value generated as a function of the status modification message sent or received by the LWM2M client and a nonce value exchanged between the LWM2M client and the LWM2M server when the LWM2M client is registered with the LWM2M server.

[0014] The indication of the state of the LWM2M client may include a digest value generated as a function of a plurality of status modification messages sent or received by the LWM2M client.

[0015] The reconnection of the LWM2M client may occur after a restart of the LWM2M client after shutdown and / or after waking the LWM2M client from a sleep mode.

[0016] If the response from the LWM2M server indicates that the indicated state of the LWM2M client is not desired, the LWM2M client may be re-registered with the LWM2M server and / or the existing observation subscriptions may be updated.

[0017] In some embodiments, if the response from the LWM2M server indicates that the indicated state of the LWM2M client is not desired, the method may further include: re-registering the LWM2M client with the LWM2M server.

[0018] An LWM2M server according to some embodiments includes: a processor circuit; a network interface coupled to the processor circuit; and a memory 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 including: receiving an indication of the state of the LWM2M client from the LWM2M client; obtaining a desired state of the LWM2M client; comparing the indication of the state of the LWM2M client with the desired state of the LWM2M client; and in response to a comparison of the indicated state of the LWM2M client with the desired state of the LWM2M client, determining that the indicated state of the LWM2M client is stale; and synchronizing the state of the LWM2M client with the LWM2M server.

[0019] A method for re - establishing a connection between an LWM2M client and an LWM2M server, comprising: receiving an indication of the state of the LWM2M client from the LWM2M client; obtaining a desired state of the LWM2M client; comparing the indication of the state of the LWM2M client with the desired state of the LWM2M client; and in response to the comparison of the indicated state of the LWM2M client with the desired state of the LWM2M client, determining that the indicated state of the LWM2M client is outdated; and synchronizing the state of the LWM2M client with the LWM2M server. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 Shows the LWM2M architecture.

[0021] Figure 2 Is a flowchart showing various conventional operations of an LWM2M client and an LWM2M server.

[0022] Figure 3A Is a table showing examples of objects that can be supported by an LWM2M client.

[0023] Figure 3B Is a table showing examples of objects that can instantiate an LWM2M client.

[0024] Figure 4A 、 Figure 4B 、 Figure 4C 、 Figure 5 、and Figure 6 Are flowcharts showing various operations of an LWM2M client and an LWM2M server according to some embodiments of the inventive concept.

[0025] Figure 7 、 Figure 8 、and Figure 9 Are flowcharts showing the operations of an LWM2M server according to some embodiments of the inventive concept.

[0026] Figure 10 Is a block diagram of an LWM2M client device according to some embodiments of the inventive concept.

[0027] Figure 11 Is a block diagram showing the functional modules of an LWM2M client device according to some embodiments of the inventive concept.

[0028] Figure 12 Is a block diagram of an LWM2M server according to some embodiments of the inventive concept.

[0029] Figure 13 Is a block diagram showing the functional modules of an LWM2M server according to some embodiments of the inventive concept. Detailed implementation manners

[0030] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, which show examples of embodiments of the inventive concept. However, the inventive concept may 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 the inventive concept to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be assumed to be presented / used in another embodiment by default.

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

[0032] Some embodiments described herein may provide a system / method that can more effectively register an LWM2M client device with an LWM2M server in terms of power consumption and / or bandwidth requirements.

[0033] In the following description, for purposes of explanation and not limitation, specific details are set forth, such as specific architectures, interfaces, technologies, 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 details. The same reference numerals refer to the same or similar elements throughout the specification.

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

[0035] The OMA SpecWorks Device Management (OMA DM) LWM2M protocol is a lightweight and compact device management protocol for managing IoT devices and their resources. LWM2M runs on top of CoAP, which uses the User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or System Management Server (SMS) bindings. Therefore, LWM2M is compatible with any constrained device that 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.

[0036] The LWM2M client contains multiple LWM2M objects with multiple resources. The LWM2M server can execute commands on these resources to manage the client, including commands to read, delete, or update resources, for example. The LWM2M client is typically a constrained device in terms of processing power, power, memory, etc.

[0037] The LWM2M server manages the LWM2M client by sending management commands to the LWM2M client.

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

[0039] Bootstrap: The LWM2M Bootstrap server sets the initial configuration on the LWM2M client when it starts up.

[0040] Client Registration: The LWM2M client 110 registers with one or more LWM2M servers 200 when the bootstrap is complete. The client registration interface is described in more detail below.

[0041] Device Management and Service Enablement: The LWM2M server 200 can send management commands to the LWM2M client 110 to perform management actions on the LWM2M resources of the client 110. The access control object of the client 110 determines the set of actions that the server 200 can perform.

[0042] Information Report: As a feature of the CoAP Observe-Notify mechanism, the LWM2M client 110 can initiate communication with the LWM2M server 200 and report information in the form of notifications.

[0043] Therefore, the interface between the LWM2M server 200 and the LWM2M client 110 includes: a bootstrap, which can be pre-provisioned or client / server-initiated; client registration, where the client and its objects are registered; device management and service enabling, which provides server access to objects or resources; and information reporting, enabling notifications with new resource values.

[0044] The LWM2M client 110 includes multiple 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 can have multiple instances (e.g., height H, weight W, length L). Objects and resources are identified by 16-bit integers, while instances are identified by 8-bit integers. Objects and resources can be accessed using a simple Uniform Resource Identifier (URI).

[0045] Client Registration Interface

[0046] The client registration interface is used by the LWM2M client 110 to register with one or more LWM2M servers 200, maintain each registration, and deregister from the LWM2M server 200. When registering, the LWM2M client 110 performs a "register" operation and provides the characteristics (e.g., supported objects and existing object instances) required by the LWM2M server 200 and optional parameters (e.g., Endpoint Client Name). The LWM2M client 110 maintains the registration and communication session with each LWM2M server 200 based on the configured parameters (e.g., Lifetime, Queue Mode). The LWM2M client periodically updates its registration information for the registered LWM2M server(s) 200 by performing an "update" operation.

[0047] Registration is performed when the LWM2M client 110 sends a "register" operation to the LWM2M server. After the LWM2M client device 100 is powered on and the bootstrap process 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. Figure 2 The registration process is shown.

[0048] As Figure 2As shown, the "register" operation may include the terminal client name parameter ("ep=") and other parameters. When receiving the "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 the LWM2M client 110.

[0049] For a brief reference, Figure 3A is a table showing examples of object versions or object types that can be supported by the 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 110. Thus, for example, for the LWM2M client 110 that supports Figure 3A the LWM2M server, access control, device, connectivity monitoring, and firmware update objects shown, the payload of the "register" operation will simply be: Figure 3A

[0050] <!--1-->,<!--2-->,<!--3-->,<!--4-->,<!--5-->

[0051] Now for a brief reference to Figure 3B is a table showing examples of the LWM2M client 110 that supports the LWM2M server, access control, device, connectivity monitoring, and firmware update objects (some of which have been instantiated). Each instantiated object is identified by an object ID and an object instance ID. If the object instance is already available on the LWM2M client 110 at the time of registration, then the payload of the "register" operation identifies the object by the object ID and the object instance ID. For example, using Figure 3B Figure 3B as an example, the format of the "register" operation payload will be:

[0052] <!--1 / 0-->,<!--1 / 1-->,<!--2 / 0-->,<!--2 / 1-->,<!--2 / 2-->,<!--2 / 3-->,<!--2 / 4-->,<!--2 / 3-->,<!--2 / 4-->,<!--3 / 0-->,<!--4 / 0-->,<!--5-->

[0053] If the LWM2M client 110 supports the JSON data format for all objects, it can notify the LWM2M server 200 by including the content type in the root path link by using 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).

[0054] ;ct=110,<!--1 / 0-->,<!--1 / 1-->,<!--2 / 0-->,<!--2 / 1-->,<!--2 / 2-->,<!--2 / 3-->,<!--2 / 4-->,<!--3 / 0-->,<!--4 / 0-->,<!--5-->

[0055] The "Register" operation can take the form of an HTTP POST command sent to the LWM2M server 200. For example, the POST command sent to the URI " / rd" (where "rd" represents the resource directory) of the LWM2M server 200 (which implements the "Register" operation for the LWM2M client 110 with the terminal name having "epname") can be as follows:

[0056] POST / rd?ep=epname&b=SQ;ct=11543,<!--1 / 0-->,<!--1 / 1-->,<!--2 / 0-->,<!--2 / 1-->,<!--2 / 2-->,<!--2 / 3-->,<!--2 / 4-->,<!--3 / 0-->,<!--4 / 0-->,<!--5-->

[0057] Upon successful registration, the LWM2M server 200 responds with an acknowledgement message ("ACK") indicating the URI assigned to the device, for example:

[0058] ACK 2.01 / rd / ls45

[0059] At the LWM2M server 200, the registration information for the registered device is maintained in the resource directory. The resource directory mechanism includes resources representing "things" (such as temperature sensors) in a common directory of resources registered to. After such registration is complete, the directory server and others using it will know the existence of the resources. They can then, for example, use the resources and clients to query information from the device, such as the current temperature.

[0060] The CoAP "Observe" mechanism involves subscribing to information. In the LWM2M model, this subscription is a request sent by the LWM2M server 200 to the LWM2M client 110 hosting the resource. Based on a specified time interval or a change in the sensor value, the LWM2M client 110 will then subsequently send an update to the LWM2M server 200, containing the most recently measured sensor value. The subscription of the sensor value and the associated subsequent notifications carry token values that help the two match each other. The benefit of the Observe mechanism is that the LWM2M server 200 does not have to continuously poll for information.

[0061] At the same time, these mechanisms allow services in the network to collect a database of the items in the network and obtain their latest sensor readings.

[0062] However, the CoAP resource directory and Observe model assume a shared state between the client and the server. That is, both the LWM2M client 110 and the LWM2M server 200 know the state of the LWM2M client 110. Based on a restart or other failure of the LWM2M client 110, the LWM2M client 110 or the LWM2M server 200 may lose track of the state. If that happens, the server may need to update the state of the LWM2M client 110. For the Observe function, when the LWM2M server 200 returns an error for a token carried in an unrecognized notification, a restart of the LWM2M server 200 can be detected. For example, if the LWM2M server 200 does not receive any updates from the client within a specified time range, a restart of the LWM2M client 110 can be detected.

[0063] For the resource directory function, the client is expected to periodically refresh the registration.

[0064] However, these methods may be slow and / or inefficient. In particular, the LWM2M client 110 knows when it starts from a sleep state or powers on, and can perform the necessary operations to refresh its state at the server. The LWM2M client 110 may also have partial knowledge of its past state stored in non-volatile memory. The LWM2M client 110 can remember, for example, the registration and its lifetime, the token and the server associated with the Observe request, or the latest sensor value sent to the interested party. However, the LWM2M client 110 may have missed the change between the last stored state and whatever state caused the crash, shutdown, power loss, sleep mode, etc.

[0065] While crashes and unexpected shutdowns may be exceptions, low-power IoT devices are preferably able to power down partially or completely (e.g., enter a sleep mode) for most of their time to save power. Thus, it may be important for the LWM2M client device 100 to be able to power down and not respond to requests when it is powered down.

[0066] During and after registration, the LWM2M client 110 may send and / or receive multiple messages that affect the state of the LWM2M client device 100. For example, the LWM2M client may send / receive registration messages, observe subscription messages, observe data transmissions, or other messages that cause the state of the LWM2M client to be modified. Such messages are referred to herein as "state modification messages". Some embodiments may maintain an indication of the state of the LWM2M client 110 at the LWM2M client 110 and the LWM2M server 200 that is updated whether the LWM2M client 110 is sending or receiving a state modification message. If the LWM2M client 110 regains connectivity with the LWM2M server 200, initializes, restarts, restarts, or wakes up from a sleep mode (such events are referred to herein as "reconnections"), then the LWM2M client 110 and the LWM2M server 200 may use the indication of the state of the LWM2M client 110 to determine whether any state modification messages need to be resent.

[0067] Accordingly, methods and / or systems are provided according to some embodiments that may enable the LWM2M client 110 and the LWM2M server 200 to synchronize states such that a full re-run of all operations after reconnection (e.g., resending all state modification messages) may not be necessary.

[0068] For example, the LWM2M client 110 may quickly determine based on stored information about its state whether it needs to restore its full state everywhere or whether only a smaller set of operations needs to be re-run to ensure that its state is up-to-date after reconnection.

[0069] Mechanisms for synchronizing databases or file system directories across machines are known. These mechanisms may synchronize based on a list of the most recent changes (e.g., "git pull"), explicitly asking whether a particular item is remembered by the other party, and / or by using separate checksum values (such as individual file checksums) to determine whether individual files are up-to-date. Such methods may be referred to as "hard synchronization".

[0070] That is, previous synchronization methods focused on ensuring that explicit transactions at either end of a connection were reflected on both sides. In contrast, some embodiments described herein can ensure that the current state of an IoT device, rather than the state of individual files or values, is consistent across a client / server connection. Such states can include states with dynamically changing values, such as sensor data. That is, even if the sensor value changes, the state can be updated / synchronized. This method can be referred to as "soft synchronization".

[0071] Some soft state solutions, such as NAT bindings, can be based on explicitly testing whether a state item is still valid or attempting to use facilities that require items to be remembered. In the event of a failure, the state needs to be re-established. In contrast, some embodiments perform an initial check of the summary of the state after reconnection rather than the summary of the state that fails later in the event of a conflict.

[0072] Figure 4A The flowchart of FIG. illustrates operations in accordance with some embodiments. As shown therein, the LWM2M client 110 may register with the LWM2M server 200 by sending a registration message 402 as described above. The LWM2M server 200 responds with an acknowledgement 404. At that time, the state of the LWM2M client 110 is now "registered" based on the state modification ACK message 404.

[0073] Then, at some point after registration, the LWM2M client device 100 hosting the LWM2M client 110 requests a reconnection 406 to the LWM2M server 200, such as if the LWM2M client 110 loses its connection to the LWM2M server 200 or undergoes a restart due to the LWM2M client device 100 restarting or waking up from a sleep mode. The LWM2M client 110 may then determine its state (block 410) and generate a state summary indicating its state. The state summary may include, for example, a state counter that is updated each time the LWM2M client 110 sends or receives a state modification message, such as a registration acknowledgement message 404. In some embodiments, the state summary may include a checksum calculated based on all state modification messages that jointly define the current state of the LWM2M client 110. Generation of the state summary is described more fully below.

[0074] Although the determination of the state and the generation of the state summary are shown in Figure 4A as occurring after the reconnection 406, in some embodiments, these operations may be performed prior to reconnection. For example, in some embodiments, the LWM2M client 110 may generate a new state summary each time the LWM2M client 110 sends or receives a state modification message.

[0075] After the LWM2M client device 100 hosting the LWM2M client 110 has reconnected, the LWM2M client 110 confirms that the LWM2M server 200 is consistent regarding the current state of the LWM2M client 110. In some embodiments, the LWM2M client 110 may do so by sending a status summary to the LWM2M server 200 in message 414. The LWM2M server 200 checks the status summary (block 416), and if it corresponds to the expected status summary, sends an affirmative response (e.g., ACK) 418 to the LWM2M client 110. To verify the status of the LWM2M client 110, in some embodiments, the LWM2M server may calculate an expected status summary based on status modification messages known to have been sent / received by the LWM2M client 110, and compare it with the status summary provided by the LWM2M client 110 in message 414.

[0076] In other embodiments, the LWM2M server 200 may generate and store the most recent status summary each time the LWM2M client 110 sends or receives a status modification message. In this case, to verify the status summary of the LWM2M client 110, the LWM2M server 200 simply retrieves the most recent status summary for the LWM2M client 110 from storage and compares it with the status summary provided by the LWM2M client 110 in message 414.

[0077] Figure 4B A further embodiment is shown. Figure 4B The operation of... is similar to Figure 4A the operation shown, except that after reconnection, the LWM2M client 110 synchronizes its state with the LWM2M server 200 by sending a message 422 to the LWM2M server 200 that requests a status summary. In response, the LWM2M server 200 generates or retrieves the status summary corresponding to the LWM2M client 110 (block 424) and sends it to the LWM2M client 110 in message 426. The LWM2M client 110 verifies the status summary (block 428), and if the verification indicates that the state is synchronized, sends an acknowledgement 430 to the LWM2M server 200.

[0078] Thus, in some embodiments, when the LWM2M Client 110 reconnects, the LWM2M Client 110 and the LWM2M Server 200 may exchange indications of the current state of the LWM2M Client 110. If the state matches the expected state, no further action is required. Also, in some embodiments, the LWM2M Client 110 device may check an earlier digest and if the digest matches, the LWM2M Client 110 and the LWM2M Server 200 know which updates were missed and can perform only those updates.

[0079] That is, after reconnection (such as due to shutdown / crash / sleep mode / loss of connectivity), some things that the LWM2M Client 110 was not aware of may have occurred. This can include, for example, new observe requests, cancellation of observe requests, data sent from the LWM2M Client 110 to the LWM2M Server 200 that the LWM2M Client 110 itself no longer remembers sending, etc. Information that should be synchronized can include, for example, registration, observe subscriptions, and transmission of observe data to observer subscribers. Such messages can be status modification messages as described herein. In the case of reconnection, if the state of the LWM2M Client 110 is not the same as the state expected by the LWM2M Server 200, it may be desirable to resend such messages to synchronize the state of the client.

[0080] Figure 4C An example of such a process is shown. As shown therein, after receiving the registration confirmation message 404, the LWM2M Client 110 may have an updated state represented by the state digest (SD) 98897. This state is known to both the LWM2M Client 110 and the LWM2M Server 200.

[0081] The LWM2M Server 200 then sends a status modification message 432 to the LWM2M Client 110 in the form of a subscription message. At that time, the LWM2M Server 200 believes that the LWM2M Client 110 has an updated state represented by the state digest 28323. However, at some point in time near the time when the message 432 was sent, the LWM2M Client 110 experiences a reconnection 434 and does not process the message 432. Thus, after reconnection, the LWM2M Client 110 believes that its state corresponds to an earlier state digest (SD = 98897).

[0082] After reconnection, to confirm synchronization, the LWM2M Client 110 sends its state digest to the LWM2M Server 200 in message 436. At block 438, the LWM2M Server 200 checks the state digest provided by the LWM2M Client 110 and determines that the state digest provided by the LWM2M Client 110 corresponds to an earlier state.

[0083] In some embodiments, the LWM2M server 200 may simply update the version of the state of its LWM2M client 110 and continue normal operation.

[0084] In other embodiments, the LWM2M server may send an optional negative acknowledgement 440 indicating the desired state summary back to the LWM2M client 110.

[0085] In some embodiments, the LWM2M server may re - send the state modification messages missed by the LWM2M client 110 based on the state summary provided by the LWM2M client 110. For example, the LWM2M server 200 may re - send a subscription message to the LWM2M client 110 in a new message 442. The LWM2M client 110 may respond to the subscription message with an acknowledgement 444, at which time both the LWM2M client 110 and the LWM2M server 200 understand the state of the LWM2M client 110 to correspond to the state summary 28323.

[0086] In some embodiments, the LWM2M server 200 may not update the state of the LWM2M client 110 based on the state modification message sent to the LWM2M client 110 until the LWM2M server has received an acknowledgement of the state modification message from the LWM2M client 110. In some embodiments, the LWM2M client 110 may send a new state summary value with each message it sends to the LWM2M server 200.

[0087] As is apparent from the Figure 4C message flow shown, the LWM2M client 110 may not need to redo the registration process (and potentially one or more subscription and sensor data update processes) after reconnecting. Instead, the LWM2M client 110 may only need to redo the actions that occurred starting from the previous state of the LWM2M client 110.

[0088] In some embodiments, the indication of the state of the LWM2M client 110 can be a counter that is updated each time the LWM2M client 110 sends or receives a status update message. Both the LWM2M client 110 and the LWM2M server 200 can track the counter for the LWM2M client 110. In other embodiments, the indication of the state of the LWM2M client 110 can be a digest value calculated according to a method known to the LWM2M client 110 and the LWM2M server 200, such that the LWM2M client 110 and the LWM2M server 200 can calculate the digest value based on the previous activities of the LWM2M client 110 (such as registration, subscription, observed messages, etc.). For example, the digest value can be calculated as follows by concatenating all previous state modification messages into a single string and calculating the checksum and hash of the string:

[0089] SD = f(S1 + S2 + … + Sn)[1]

[0090] where SD is the state digest, f() is a checksum or hash function, and Sn is the state from the nth state modification message sent / received by the LWM2M client 110. Since both the LWM2M client 110 and the LWM2M server 200 know all the state modification messages sent / received by the LWM2M client 110, either entity can calculate the state of the LWM2M client 110. The function f() can include a checksum function, a cyclic redundancy code (CRC) function, a cryptographic hash function such as MD5, SHA1, or SHA256, or a non-cryptographic hash function.

[0091] In other embodiments, the state of the LWM2M client 110 can be updated from the previous state by calculating a checksum or hash as follows based on the concatenation of the previous state digest and the latest state modification message:

[0092] SD n+1 = f(SD n + S n+1 )[2]

[0093] where SD n+1 is the updated digest value, SD n is the previous digest value and S n+1 is the state from the state modification message. Additionally, since both the LWM2M client 110 and the LWM2M server 200 know all the state modification messages sent / received by the LWM2M client 110, either entity can calculate the state of the LWM2M client 110.

[0094] In embodiments where a status summary is maintained as a generation counter, the generation counter may include a random component such that different restarts can be distinguished from one another. That is, when the generation counter is reset, it will not always start from the same number (e.g., 0 or 1), but may start at a random value and increment (register, subscribe, notification of new data, etc.) each time it changes.

[0095] In embodiments where a digest value is used to indicate the state of a client, the client and the server must agree on a method for generating the digest value, i.e., the two endpoints must agree on the algorithm to be used and what input should be used to generate the digest value.

[0096] The indication of the state may be sent as a new exchange from the LWM2M client 110 to the LWM2M server 200, or it may be piggybacked on a registration request such that if the indication of the state already matches the client state stored at the server, the LWM2M server 200 in response to the request may omit processing the registration request.

[0097] In operation, the LWM2M client 110 needs to register itself with various servers, directories, and other interested parties and send updates to the network regarding its latest sensor values. These registrations and updates can consume a large amount of resources from the client device and, if possible, it would be desirable to avoid performing unnecessary actions. When the LWM2M client 110 reconnects, it may not know whether the state stored in the network matches the state in the device. According to some embodiments, the device may provide an indication of its state to the nLWM2M server 200 and ask the server whether the version of its client state matches the version of the client. If the states match, the client 110 may resume normal operation. If the state indicated by the client corresponds to an earlier state known to the server 200, the server 200 may only perform those updates necessary to bring the state of the client 110 up to date.

[0098] Figure 5An example of such an operation is shown. As shown therein, the LWM2M client 110 may register with the LWM2M server 200 via a registration message 402 and a response 404. The LWM2M client 110 may perform one or more state modification operations 405 that change the state of the LWM2M client 110. After performing the state modification operation 405, for example, due to a loss of connectivity of the LWM2M client device 100 hosting the LWM2M client 110, or a restart, shutdown, or sleep, the LWM2M client 110 may reconnect 406. When the LWM2M client 110 reconnects, at block 412, it generates a state summary that it understands corresponding to its state. The LWM2M client 110 sends the state summary to the LWM2M server 200 in a message 414. At block 416, the LWM2M server 200 verifies the state of the LWM2M client 110. If the LWM2M server 200 determines that the summary value provided by the LWM2M client 110 corresponds to an earlier known state, the LWM2M server 200 may indicate this to the LWM2M client 110 via a negative acknowledgement (NACK) 518 and may cause one or more state modification operations to be re-run. For example, in response to the NACK, the LWM2M client 110 updates its registration by sending a new registration message 520 to the LWM2M server 200. The LWM2M client 110 may update its observations by sending an observe notification message 524 to the LWM2M server 200. Additionally, the LWM2M server 200 may update the observe subscriptions at the LWM2M client 110 by sending one or more subscription messages 528 to the LWM2M client 110. After the state of the LWM2M client 110 has been updated to the current state, the LWM2M client 110 and the LWM2M server 200 may exchange summary values to verify that the state of the LWM2M client 110 is synchronized at each end.

[0099] In the digest value method, it is useful to include an initial random nonce value so that an outsider cannot guess the content of the state based on viewing the digest value. For example, as Figure 6 shown, the registration message 602 from the LWM2M client 110 to the LWM2M server 200 may include a nonce value. The nonce value may be attached to one or more state modification messages so that the state digests generated by the LWM2M client 110 and the LWM2M server are randomized. That is, after the first state modification message (SMM1), the state digest (SD) of the LWM2M client 110 may be generated at each end according to the following function:

[0100] SD = f(SMM1 + nonce)[3]

[0101] After reconnection 606, the LWM2M client 110 can send a request 608 to the LWM2M server 200 for the current state stored by the LWM2M server 200. The LWM2M server uses the nonce value according to Equation [3] to generate a state digest and sends the state digest to the LWM2M client 110 in message 612. The LWM2M client 110 uses Equation [3] to generate its understanding of the state digest (block 616) and compares the two values at block 618. If the values match, the LWM2M client 110 sends a message 620 to the LWM2M server 200 indicating that the values match. Since the LWM2M client 110 can send some similar messages, such as registration messages, it is possible that it will generate similar state digests. Therefore, an attacker can potentially guess the state of the device by examining the state digests exchanged between the LWM2M client 110 and the LWM2M server. By including the nonce value in the calculation, the state digest can be randomized so that the attacker will be prevented from guessing the state of the client based on the state digest.

[0102] Figure 7 and Figure 8 is a flowchart showing a method of operating an LWM2M client 110 according to some embodiments. Referring to Figure 7 , a method of re - establishing a connection between an LWM2M client 110 and an LWM2M server 200 after reconnection of the LWM2M client 110 includes: at the LWM2M client 110, determining 706 the state of the LWM2M client 110 device before reconnection of the LWM2M client; sending 708 to the LWM2M server 200 an indication of the state of the LWM2M client 110 before reconnection of the LWM2M client 110; and receiving 710 from the LWM2M a response indicating whether the indicated state of the LWM2M client 110 is a desired state or an undesired state.

[0103] If the response from the LWM2M server indicates that the indicated state of the LWM2M client is outdated, the method may further include: synchronizing 714 the state of the LWM2M client 110 with the LWM2M server.

[0104] The state of the LWM2M client 110 before reconnection of the LWM2M client 110 can be determined by obtaining an indication of the state of the LWM2M client 110 before reconnection of the LWM2M client 110.

[0105] Referring to Figure 8, in some embodiments, the method may further include: determining the state of the LWM2M client 110 before reconnection of the LWM2M client 110; generating an indication of the state of the LWM2M client 110 based on the determined state of the LWM2M client 110; and storing the indication of the state of the LWM2M client 110.

[0106] In some embodiments, the indication of the state of the LWM2M client 110 may include a status counter or a generation counter.

[0107] In some embodiments, the indication of the state of the LWM2M client 110 may include a digest value generated as a function of status modification messages sent or received by the LWM2M client 110. The status modification messages may include, for example, registration messages, observe subscription messages, and / or observe data transmissions.

[0108] The digest value may include a hash value generated using a hash function applied to the status modification messages. In some embodiments, the digest value may include a checksum value generated using a checksum function applied to the status modification messages.

[0109] The indication of the state of the LWM2M client 110 may include a digest value generated as a function of status modification messages sent or received by the LWM2M client 110 and a nonce value exchanged between the LWM2M client 110 and the LWM2M server 200 when registering the LWM2M client 110 with the LWM2M server 200.

[0110] The indication of the state of the LWM2M client 110 may include a digest value generated as a function of multiple status modification messages sent or received by the LWM2M client 110.

[0111] The reconnection may occur when restarting the LWM2M client 110, such as by restarting the LWM2M client 110 after shutdown and / or waking up the LWM2M client 110 from a sleep mode.

[0112] If the response from the LWM2M server indicates that the indicated state of the LWM2M client 110 is outdated, the LWM2M client 110 may re-register with the LWM2M server 200 and / or update an existing observe subscription.

[0113] In some embodiments, if the response from the LWM2M server indicates that the indicated state of the LWM2M client 110 is not desired, the method may further include: re-registering the LWM2M client 110 with the LWM2M server 200.

[0114] Figure 9A method for re - establishing a connection between an LWM2M client 110 and an LWM2M server 200 after re - connection of the LWM2M client 110 is shown. The method includes: receiving 902 an indication of the state of the LWM2M client 110 from the LWM2M client 110; obtaining 904 the desired state of the LWM2M client 110; comparing the indication of the state of the LWM2M client 110 with the desired state of the LWM2M client 110; and in response to the comparison of the indicated state of the LWM2M client 110 with the desired state of the LWM2M client 110, determining 906 whether the indicated state of the LWM2M client 110 is a desired or an undesired state; and if the state is an undesired state, synchronizing 908 the state of the LWM2M client 110 with the LWM2M server 200.

[0115] Figure 10 is a block diagram showing elements of an 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), which is coupled to the transceiver circuit 102; and a memory circuit 105 (also referred to as a memory), which is 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 the embodiments disclosed herein. According to other embodiments, the processor circuit 103 may include a memory such that a separate memory circuit is not required.

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

[0117] In particular, the memory 105 may include machine-readable program instructions that, when executed by the processor circuitry, cause the LWM2M client device 100 to perform operations that include: reconnecting 704 the LWM2M client 110 hosted by the LWM2M client device 100 to the LWM2M server 200; at the LWM2M client 110, determining 706 the state of the LWM2M client 110 device prior to the reconnection of the LWM2M client; sending 708 to the LWM2M server 200 an indication of the state of the LWM2M client 110 prior to the reconnection of the LWM2M client 110; and receiving 710 from the LWM2M a response indicating whether the indicated state of the LWM2M client 110 is a desired state or an undesired state.

[0118] Figure 11 FIG. shows various functional modules of the 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 state management module 122 that manages the state of the LWM2M client 110 and generates an indication of the state of the LWM2M client 110, such as a digest value or a counter value; and a transceiver module 128 that performs operations of sending messages to and receiving messages from the LWM2M server.

[0119] Figure 12 FIG. is a block diagram showing 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 communication with other nodes of a communication network (e.g., with a base station, a RAN node, and / or a core network node). 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 a 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 the embodiments disclosed herein. According to other embodiments, the processor circuit 203 may include a memory such that a separate memory circuit is not required.

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

[0121] In particular, the memory 205 includes machine-readable program instructions that, when executed by the processor circuitry, cause the LWM2M server to perform operations that include: receiving 902 an indication of the state of the LWM2M client 110 from the LWM2M client 110; obtaining 904 the desired state of the LWM2M client 110; comparing the indication of the state of the LWM2M client 110 with the desired state of the LWM2M client 110; and in response to the comparison of the indicated state of the LWM2M client 110 with the desired state of the LWM2M client 110, determining 906 whether the indicated state of the LWM2M client 110 is desired or not; and if the state is an undesired state, synchronizing 908 the state of the LWM2M client 110 with the LWM2M server 200.

[0122] Figure 13 Various functional modules of the LWM2M server 200 are shown in accordance with 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 state management module 222 and a transceiver module 224. The transceiver module 224 may perform operations of sending messages to and receiving messages from LWM2M clients as described herein. The state management module 222 may track the state of one or more LWM2M clients as described herein.

[0123] Explanations for the abbreviations mentioned in this disclosure are provided below.

[0124] Abbreviation Explanation

[0125] CoAP Constrained Application Protocol

[0126] M2M Machine-to-Machine

[0127] LWM2M Lightweight Machine-to-Machine

[0128] RAN Radio Access Network

[0129] IoT Internet of Things

[0130] WWW World Wide Web

[0131] DTLS Datagram Transport Layer Security

[0132] IETF Internet Engineering Task Force

[0133] HTTP Hypertext Transfer Protocol

[0134] OMA DM OMA SpecWorks Device Management

[0135] UDP User Datagram Protocol

[0136] TCP Transmission Control Protocol

[0137] Further definitions and examples are discussed below.

[0138] In the foregoing description of the various embodiments of the inventive concept, it should be understood that the terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting of the inventive concept. 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 the inventive concept pertains. It will also be 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.

[0139] When an element is referred to as being “connected,” “coupled,” “responsive,” or a variation 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 a variation thereof, to another element, no intervening elements are present. The same numerals refer to the same elements throughout. Further, as used herein, “coupled,” “connected,” “responsive,” or a variation thereof may include wireless coupling, connection, or responsiveness. As used herein, unless the context clearly dictates otherwise, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well. Well-known functions or constructions may not be described in detail for the sake of brevity and / or clarity. The term “and / or” includes any and all combinations of one or more of the associated listed items.

[0140] 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. Thus, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments without departing from the teachings of the inventive concept. The same reference numerals or the same reference indicators indicate the same or similar elements throughout the specification.

[0141] As used herein, the terms "comprises," "comprising," "includes," "including," "contains," "containing," "has," "having," "with," or variations thereof are open-ended and include one or more of the recited features, integers, elements, steps, components, or functions, but do not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions, or combinations thereof. Further, as used herein, the common phrase "such as" derived 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 phrase "i.e." derived from the Latin phrase "id est" may be used to specify a particular item from a more general recitation.

[0142] 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 should be understood that the blocks in 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, which are executed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, a special purpose computer circuit, and / or other programmable data processing circuit to generate a machine, such that the instructions executed by the processor of the computer and / or other programmable data processing device transform and control transistors, values stored in memory locations, and other hardware components within such circuits to implement the functions / actions specified in the block diagram and / or (one or more) flowchart blocks, and thereby produce means (functions) and / or structures for implementing the functions / actions specified in the block diagram and / or (one or more) flowchart blocks.

[0143] These computer program instructions can also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions for implementing the functions / actions specified in the block diagrams and / or flowchart block(s). Accordingly, embodiments of the inventive concept can be implemented in hardware and / or in software (including firmware, resident software, microcode, etc.) running on a processor such as a digital signal processor, which may be collectively referred to as “circuitry,” “module,” or a variation thereof.

[0144] It should also be noted that in some alternative embodiments, the functions / actions noted in the blocks may occur out of the order noted in the flowchart. 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 / action involved. Also, the functionality of a given block of the flowchart and / or block diagram may be divided into multiple blocks, and / or the functionality of two or more blocks of the flowchart and / or block diagram may be at least partially integrated. Finally, other blocks may be added / inserted between the blocks shown, and / or blocks / operations may be omitted without departing from the scope of the inventive concept. Further, although some of the figures include arrows on communication paths showing the primary direction of communication, it should be understood that communication may occur in the opposite direction to that depicted by the arrows.

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

Claims

1. A lightweight Machine-to-Machine (LWM2M) client device (100), comprising: 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 (100) to perform operations including: reconnecting (704) an LWM2M client (110) hosted by the LWM2M client device to an LWM2M server (200); determining (706) the state of the LWM2M client (110) prior to the reconnecting of the LWM2M client (110); sending (708) an indication of the state of the LWM2M client (110) prior to the reconnecting of the LWM2M client (110) to the LWM2M server (200); and receiving (710) from the LWM2M server (200) a response indicating whether the indicated state of the LWM2M client (110) prior to the reconnecting of the LWM2M client (110) is a desired state or an undesired state of the LWM2M client (110).

2. The LWM2M client device (100) according to claim 1, wherein the LWM2M client device is further configured to perform operations including: determining (802) the state of the LWM2M client (110) prior to the reconnecting (704) of the LWM2M client (110); generating (804) an indication of the state of the LWM2M client (110) based on the determined state of the LWM2M client; and storing (806) the indication of the state of the LWM2M client (110).

3. The LWM2M client device (100) according to claim 2, wherein the indication of the state of the LWM2M client includes a status counter that is updated each time the LWM2M client (110) sends or receives a status modification message.

4. The LWM2M client device according to claim 2, wherein the indication of the state of the LWM2M client (110) includes: a digest value generated as a function of the client state sourced from status modification messages sent or received by the LWM2M client (110).

5. The LWM2M client device (100) according to claim 4, wherein The indication of the state of the LWM2M client (110) includes: a digest value generated as a function of the client state sourced from a state modification message sent or received by the LWM2M client (110), and a nonce value exchanged between the LWM2M client (110) and the LWM2M server (200) when the LWM2M client (110) registers with the LWM2M server (200).

6. The LWM2M client device (100) according to claim 2, wherein, the indication of the state of the LWM2M client (110) includes a digest value generated as a function of at least one state modification message sent or received by the LWM2M client (110).

7. The LWM2M client device (100) according to any one of claims 1 to 6, wherein, the LWM2M client device (100) is further configured to: in response to the response from the LWM2M server (200) indicating that the state of the indicated LWM2M client (110) before reconnection of the LWM2M client (110) is an undesired state of the LWM2M client (110), synchronize (714) the state of the LWM2M client (110) with the LWM2M server.

8. The LWM2M client device (100) according to any one of claims 1 to 6, further comprising: in response to the response from the LWM2M server (200) indicating that the state of the indicated LWM2M client (110) before reconnection of the LWM2M client (110) is an undesired state of the LWM2M client (110), re-register the LWM2M client (110) with the LWM2M server (200).

9. The LWM2M client device (100) according to any one of claims 1 to 6, wherein, the LWM2M client device (100) is further configured to: in response to the response from the LWM2M server (200) indicating that the state of the indicated LWM2M client (110) before reconnection of the LWM2M client (110) is an undesired state of the LWM2M client (110), update an existing observation subscription.

10. The LWM2M client device (100) according to claim 2, wherein, the indication of the state of the LWM2M client (110) before reconnection of the LWM2M client (110) includes a digest value generated as a function of one or more parameters, settings or values stored at the LWM2M client (110) characterizing the current state of the LWM2M client (110).

11. A method for re - establishing a connection between a lightweight machine - to - machine (LWM2M) client (110) and an LWM2M server (200) after a connection loss, the method being executed by an LWM2M client device (100), and comprising: re - connecting (704) the LWM2M client (110) to the LWM2M server (200); at the LWM2M client (110), determining (706) the state of the LWM2M client (110) before the re - connection of the LWM2M client (110); sending (708) an indication of the state of the LWM2M client (110) before the re - connection of the LWM2M client (110) to the LWM2M server (200); and receiving (710) from the LWM2M server (200) a response indicating whether the indicated state of the LWM2M client (110) before the re - connection of the LWM2M client (110) is an expected state or an unexpected state of the LWM2M client (110).

12. A lightweight machine - to - machine (LWM2M) server (200), comprising: 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 (200) to perform operations after the re - connection of an LWM2M client (110), the operations including: receiving (902) from the LWM2M client (110) an indication of the state of the LWM2M client (110) before the re - connection of the LWM2M client (110); obtaining (904) the expected state of the LWM2M client (110); comparing the indication of the state of the LWM2M client (110) before the re - connection of the LWM2M client (110) with the expected state of the LWM2M client (110), and determining (906) that the indicated state of the LWM2M client before the re - connection of the LWM2M client (110) is an unexpected state in response to the comparison of the indicated state of the LWM2M client (110) before the re - connection of the LWM2M client (110) with the expected state of the LWM2M client (110); and in response to determining that the indicated state of the LWM2M client before the re - connection of the LWM2M client (110) is an unexpected state, causing the state of the LWM2M client (110) to be synchronized (908) with the LWM2M server (200).

13. The LWM2M server (200) according to claim 12, wherein, The LWM2M server (200) synchronizes the state of the LWM2M client (110) with the LWM2M server (200) by resetting the desired state of the LWM2M client (110) to match the indicated state of the LWM2M client (110) before reconnection of the LWM2M client (110).

14. The LWM2M server (200) according to claim 12, wherein, the LWM2M server (200) synchronizes the state of the LWM2M client (110) with the LWM2M server (200) by resending a state modification message to the LWM2M client (110).

15. The LWM2M server (200) according to claim 12, wherein, the LWM2M server (200) synchronizes the state of the LWM2M client (110) with the LWM2M server (200) by sending a command to the LWM2M client (110) to re-register with the LWM2M server (200).

16. A method for re-establishing a connection between an LWM2M client (110) and an LWM2M server (200) after reconnection of the lightweight machine-to-machine LWM2M client (110), the method being performed by the LWM2M server (200) and comprising: receiving (902) from the LWM2M client (110) an indication of the state of the LWM2M client (110) before reconnection of the LWM2M client (110); obtaining (904) the desired state of the LWM2M client (110); comparing the indication of the state of the LWM2M client (110) before reconnection of the LWM2M client (110) with the desired state of the LWM2M client, and determining (906) that the indicated state of the LWM2M client (110) before reconnection of the LWM2M client (110) is an undesired state in response to the comparison of the indicated state of the LWM2M client (110) before reconnection of the LWM2M client (110) with the desired state of the LWM2M client (110); and synchronizing (908) the state of the LWM2M client (110) with the LWM2M server (200) in response to determining that the indicated state of the LWM2M client (110) before reconnection of the LWM2M client (110) is an undesired state.

Images