Data transfer between lwm2m client and lwm2m server

Abstract

A network (200), an LwM2M client (210; 1000) and an LwM2M server (220; 1000) for data transfer between the LwM2M client and the LwM2M server, a method (300; 400; 500) performed by the network, the LwM2M client and the LwM2M server, a corresponding computer program and computer program product each for the network, the LwM2M client and the LwM2M server is disclosed. The LwM2M client receives from the LwM2M server, a first CoAP message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server and obtains a first LwM2M object comprising information about the CoAP block-wise transfer.

Description

DATA TRANSFER BETWEEN LWM2M CLIENT AND LWM2M SERVERTECHNICAL FIELD

[0001] The invention relates to a network, a Lightweight Machine-to-Machine (LwM2M) client and an LwM2M server for data transfer between the LwM2M client and the LwM2M server, a method performed by the network, the LwM2M client and the LwM2M server, a corresponding computer program and computer program product each for the network, the LwM2M client and the LwM2M server.BACKGROUND

[0002] Constrained Application Protocol (CoAP) is a generic Representational State Transfer (REST) application protocol for constrained devices. CoAP is designed to be used over User Datagram Protocol (UDP) over the Internet as defined by Internet Engineering Task Force (IETF) Request for Comments (RFC) 768. CoAP uses a short fixed-length binary header, wherein the length of the binary header is 4 bytes. CoAP was originally intended for UDP transmission, which is unreliable. This means that CoAP request and response messages may arrive out of order, appear duplicated, or go missing without notice. For this reason, CoAP implements a lightweight reliability mechanism using four different message types, including “confirmable” and “non-confirmable” messages.

[0003] In order to allow for larger payload transfer over UDP (for e.g., 100 KB or 100 MB) , block-wise transfers in CoAP were created. Block-wise transfers in CoAP is defined by IETF RFC 7959. In contrast to Hypertext Transfer Protocol (HTTP) , where Transmission Control Protocol (TCP) performs segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS) . Datagram transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, block-wise transfer extends basic CoAP with a pair of “Block” options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.

[0004] Three items of information may need to be transferred in a Block (Block1 or Block2) option: the size of the block (SZX) , whether more blocks are following (M) and the relative number of the block (NUM) within a sequence of blocks with the given size. The minimum block size is 16 and the maximum is 1024 bytes. The size of the block: 16, 32, 64, 128, 256,  512 and 1024 and SZX is a way to represent the size of the block as a three-bit unsigned integer indicating the size of a block to the power of two.

[0005] Block-wise defines new response status codes such as 2.31 Continue, which indicates that the transfer of a block of the request body was successful and that the server encourages sending further blocks. 4.08 Request Entity Incomplete client error status code indicates that the server has not received the blocks of the request body that it needs to proceed. Block-wise can be used with CoAP’s GET, POST, PUT methods and allows for negotiating the block size. Finally, RFC7959 also defines a CoAP option to tell in advance the total size of the file being transferred (size1 for requests and size2 for responses) . CoAP uses block-wise feature of RFC 7959 for Firmware Over The Air (FOTA) and Software Over The Air (SOTA) data transfers.

[0006] Current CoAP deployments are performed via device management and provisioning protocol for IoT devices such as Lightweight Machine to Machine Protocol (LWM2M) .

[0007] WO 2017 / 040940 A1 discloses modifications to the existing CoAP block transfer mechanism to minimize waste associated with excess load and congestion, and excess message and block transfers during transfers of resources that are dynamically changing.SUMMARY

[0008] An object of the invention is to provide a mechanism for discontinuous data transfer for devices using LwM2M protocol.

[0009] This and other objects are met by means of different aspects of the invention, as defined by the independent claims.

[0010] According to a first aspect, a method performed by a Lightweight Machine-to-Machine (LwM2M) client for data transfer between the LwM2M client and an LwM2M server in a network is provided. The method comprises receiving from the LwM2M server, a first Constrained Application Protocol (CoAP) message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server. The method comprises obtaining a first LwM2M object comprising information about the CoAP block-wise transfer. Hereby is achieved that, information about the CoAP block-wise transfer is obtained.

[0011] According to an embodiment, obtaining the first LwM2M object comprises creating the first LwM2M object at the LwM2M client. According to an embodiment, the information about the CoAP block-wise transfer comprises an operational state of the block-wise transfer.

[0012] According to an embodiment, the method comprises sending to the LwM2M server, a second CoAP message including information about the CoAP block-wise transfer after an interruption of the CoAP block-wise transfer.

[0013] According to an embodiment, the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption.

[0014] According to an embodiment, the method comprises interrupting the CoAP block-wise transfer. Hereby is achieved that, battery consumption of the LwM2M client and / or LwM2M server is reduced.

[0015] According to an embodiment, the method comprises using a resource ‘Pause’ in a second LwM2M object, wherein using the resource ‘Pause’ triggers the interruption of the block wise transfer. The method further comprises using a resource ‘Pause’ in a second LwM2M object, wherein using the resource ‘Pause’ triggers the obtaining of a first LwM2M object comprising information about the CoAP block-wise transfer.

[0016] According to an embodiment, a condition for interrupting the CoAP block-wise transfer comprises one or more of: a battery level of the LwM2M client or of the LwM2M server is below a given battery level threshold; a signal strength of a message exchanged between the LwM2M client and the LwM2M server is below a given strength threshold; a reduction of a reliability of the network; a service level agreement (SLA) of the network is not met; a Quality of Service (QoS) level of the network is below a QoS threshold; a Quality of Experience (QoE) level of the network is below a QoE threshold; and a throughput at the LwM2M client or the LwM2M server is below a throughput threshold.

[0017] According to an embodiment, the method comprises resuming the block-wise transfer based on the information about the CoAP block-wise transfer. Hereby is achieved that, battery consumption of the LwM2M client and / or LwM2M server is reduced. Furthermore, hereby is achieved that, unnecessary retransmissions between the LwM2M server and the LwM2M client are reduced. In other words, retransmissions between the LwM2M server and the LwM2M client are reduced.

[0018] According to an embodiment, the method comprises using a resource ‘Resume’ in the second LwM2M object, wherein using the resource ‘Resume’ triggers the resumption of the CoAP block-wise transfer based on the information obtained about the CoAP block-wise transfer.

[0019] According to an embodiment, using the resource ‘Resume’ triggers a method comprising resuming the CoAP block-wise transfer after the last block successfully received from blocks of the block-wise transfer.

[0020] According to an embodiment, the first CoAP message comprises one of: a PUT message; a GET message; or a POST message.

[0021] According to an embodiment, the information about the block-wise transfer comprises at least one of: an identifier related to the block-wise transfer; an instance number of the block-wise transfer; an expected size of the block-wise transfer; a path related to where contents of the block-wise transfer is being stored; information related to a block option being used for the block-wise transfer; information related to a block size being used for the block-wise transfer; and information related to a last block received. Hereby is achieved that, the exchange of messages with payload between the LwM2M server and the LwM2M client is reduced. In other words, retransmission of blocks of the data transfer which were successfully transferred to the LwM2M client from the LwM2M server is reduced.

[0022] According to an embodiment, the LwM2M server comprises a CoAP client and the LwM2M client comprises a CoAP server.

[0023] According to an embodiment, the first LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’

[0024] According to an embodiment, the second LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ .

[0025] According to an embodiment, the method comprises exposing the obtained first LwM2M object to the LwM2M server as an observable resource for CoAP.

[0026] According to an embodiment, the method comprises adjusting block size of the block-wise transfer based on network conditions.

[0027] According to an embodiment, the method comprises sending a third CoAP message comprising information about a block from where the block-wise transfer should resume.

[0028] According to a second aspect, a method performed by an LwM2M server for data transfer between an LwM2M client and the LwM2M server in a network is provided. The method comprises sending to the LwM2M client, a first CoAP message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server. The method comprises obtaining a first LwM2M object comprising information about the CoAP block-wise transfer.

[0029] According to an embodiment, obtaining the first LwM2M object comprises receiving from the LwM2M client, the first LwM2M object. According to an embodiment, the information about the CoAP block-wise transfer comprises an operational state of the block-wise transfer.

[0030] According to an embodiment, the method comprises receiving from the LwM2M client, a second CoAP message including information about the CoAP block-wise transfer after an interruption of the CoAP block-wise transfer.

[0031] According to an embodiment, the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption.

[0032] According to an embodiment, the method comprises interrupting the CoAP block-wise transfer.

[0033] According to an embodiment, the method comprises using a resource ‘Pause’ in a second LwM2M object, wherein using the resource ‘Pause’ triggers the interruption of the block wise transfer. The method comprises using the resource ‘Pause’ , wherein using the resource ‘Pause’ triggers the obtaining of a first LwM2M object comprising information about the CoAP block-wise transfer.

[0034] According to an embodiment, a condition for interrupting the CoAP block-wise transfer comprises one or more of: a battery level of the LwM2M client or of the LwM2M server is below a given battery level threshold; a signal strength of a message exchanged between the LwM2M client and the LwM2M server is below a given strength threshold; a reduction of a reliability of the network; an SLA, of the network is not met; a QoS level of the network is below a QoS threshold; a QoE level of the network is below a QoE threshold; and a throughput at the LwM2M client or the LwM2M server is below a throughput threshold.

[0035] According to an embodiment, the method comprises resuming the block-wise transfer based on the information about the CoAP block-wise transfer.

[0036] According to an embodiment, the method comprises using a resource ‘Resume’ in the second LwM2M object, wherein using the resource ‘Resume’ triggers the resumption of the CoAP block-wise transfer based on the information obtained about the CoAP block-wise transfer.

[0037] According to an embodiment, using the resource ‘Resume’ triggers a method comprising resuming the CoAP block-wise transfer after the last block successfully received from blocks of the block-wise transfer.

[0038] According to an embodiment, the first CoAP message comprises one of: a PUT message; a GET message; and a POST message.

[0039] According to an embodiment, the information about the block-wise transfer comprises at least one of: an identifier related to the block-wise transfer; an instance number of the block-wise transfer; an expected size of the block-wise transfer; a path related to where contents of the block-wise transfer is being stored at the LwM2M client; information related to a block option being used for the block-wise transfer; information related to a block size being used for the block-wise transfer; and information related to a last block sent.

[0040] According to an embodiment, the LwM2M server comprises a CoAP client and the LwM2M client comprises a CoAP server.

[0041] According to an embodiment, the first LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ .

[0042] According to an embodiment, the second LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ .

[0043] According to an embodiment, the method comprises observing the obtained first LwM2M object as an observable resource for CoAP.

[0044] According to an embodiment, the method comprises adjusting a block size of the block-wise transfer based on network conditions.

[0045] According to an embodiment, the method comprises receiving a third CoAP message comprising information about a block from where the block-wise transfer should resume.

[0046] According to a third aspect, an LwM2M client for data transfer between the LwM2M client and an LwM2M server in a network is provided. The LwM2M client is adapted to receive from the LwM2M server, a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server. The LwM2M client is adapted to obtain a first LwM2M object comprising information about the CoAP block-wise transfer.

[0047] According to an embodiment, the LwM2M client according to the third aspect is adapted to perform operations according to any one of the embodiments of the first aspect.

[0048] According to a fourth aspect, an LwM2M client for data transfer between the LwM2M client and an LwM2M server in a network is provided. The LwM2M client comprises at least one processing circuitry. The LwM2M client comprises at least one memory. The at least one memory is connected to the at least one processing circuitry. The at least one memory storing program code that is executed by the at least one processing circuitry to perform the method according to the first aspect or the at least one processing circuitry to perform the method according any one of the embodiments of the first aspect.

[0049] According to a fifth aspect, a computer program comprising instructions which, when executed by at least one processing circuitry of an LwM2M client is provided. The computer program causes the LwM2M client to carry out the method according to the first aspect or the computer program causes the LwM2M client to carry out the method according any one of the embodiments of the first aspect.

[0050] According to a sixth aspect, a computer program product stored on a non-transitory computer readable medium is provided. The computer program product comprises instructions  that, when executed by at least one processing circuitry of an LwM2M client, causes the LwM2M client to perform the method according to the first aspect or the computer program product comprises instructions that, when executed by at least one processing circuitry of an LwM2M client, causes the LwM2M client to perform the method according any one of the embodiments of the first aspect.

[0051] According to a seventh aspect, an LwM2M server for data transfer between the LwM2M server and an LwM2M client in a network is provided. The LwM2M server is adapted to send to the LwM2M client, a first CoAP message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server. The LwM2M server is adapted to obtain a first LwM2M object comprising information about the CoAP block-wise transfer.

[0052] According to an embodiment, the LwM2M server is adapted to perform operations according to any one of embodiments of the second aspect.

[0053] According to an eight embodiment, an LwM2M server for data transfer between the LwM2M server and an LwM2M client in a network is provided. The LwM2M server comprises at least one processing circuitry (1002) and at least one memory. The at least one memory is connected to the at least one processing circuitry. The at least one memory is configured to store program code that is executed by the at least one processing circuitry to perform the method according to the second aspect or the at least one processing circuitry to perform the method according any one of the embodiments of the second aspect.

[0054] According to a ninth aspect, a computer program is provided. The computer program comprises instructions which, when executed by at least one processing circuitry of an LwM2M server, causes the LwM2M server to carry out the method according to the second aspect or the at least one processing circuitry causes the LwM2M server to carry out the method according any one of the embodiments of the second aspect.

[0055] According to a tenth aspect, a computer program product stored on a non-transitory computer readable medium is provided. The computer program product comprises instructions that, when executed by an LwM2M server, causes the LwM2M server to perform the method according to the second aspect or the computer program product comprises instructions that, when executed by an LwM2M server, causes the LwM2M server to perform the method according any one of the embodiments of the second aspect.

[0056] According to an eleventh aspect, a method performed by a network comprising an LwM2M client and an LwM2M server for data transfer between the LwM2M client and the LwM2M server is provided. The method comprises receiving, at the LwM2M client from the LwM2M server, a first CoAP message comprising a confirmable request for initiating a CoAP  block-wise transfer with the LwM2M server. The method comprises obtaining a first LwM2M object comprising information about the CoAP block-wise transfer.

[0057] According to an embodiment, the method comprises performing an operation according to any one of the first aspect, the second aspect, the embodiments of the first aspect and the embodiments of the second aspect.

[0058] According to a twelfth aspect, a network comprising an LwM2M client and an LwM2M server for data transfer between the LwM2M client and the LwM2M server is provided. The network is adapted to receive, at the LwM2M client from the LwM2M server, a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server. The network is adapted to obtain a first LwM2M object comprising information about the CoAP block-wise transfer.

[0059] According to an embodiment, the network is adapted to perform operations according to any one of the first aspect, the second aspect, the embodiments of the first aspect and the embodiments of the second aspect.

[0060] According to a thirteenth aspect, a computer program is provided. The computer program comprises instructions which, when executed by at least one processing circuitry of a network, causes the network to carry out the method according to the eleventh aspect or the at least one processing circuitry causes the network to carry out the method according any one of the embodiments of the eleventh aspect.

[0061] According to a fourteenth aspect, a computer program product stored on a non-transitory computer readable medium is provided. The computer program product comprises instructions that, when executed by at least one processing circuitry of a network, causes the network to carry out the method according to the eleventh aspect or the at least one processing circuitry causes the network to carry out the method according any one of the embodiments of the eleventh aspect.

[0062] In some examples, the disclosure herein provides a mechanism for discontinuous Firmware Over The Air (FOTA) and / or Software Over The Air (SOTA) data transfer in LwM2M protocol. The disclosure herein further provides a mechanism to handle state loss on LwM2M client or a Constrained Application Protocol (CoAP) server side.

[0063] An advantage of the disclosure herein is that the information about the CoAP block-wise transfer can be used by the LwM2M client and / or the LwM2M server to make an informed decision about whether to continue or discontinue the data transfer. The disclosure herein advantageously enables resuming data transfer from a state wherein the state was lost by the LwM2M client or the CoAP server. Further, the disclosure herein advantageously provides a  mechanism for an LwM2M client to save the / astate of a data transfer and provides a mechanism for an LwM2M server to pause the data transfer, query for required parameters to resume the data transfer and resume the data transfer once the required parameters are met. The concept of saving a state for data transfer, pausing the data transfer and resuming the data transfer may be equated to breakpoint continuity. Advantageously, breakpoint continuity support requires only transferring the remaining parts or blocks of the data transfer, instead of transferring all the parts. Advantageously, the breakpoint continuity reduces network load. Advantageously, the invention herein improves success rate for FOTA and / or SOTA. Furthermore, the disclosure herein reduces battery consumption for LwM2M devices resulting from lesser data transfer and / or lesser required uptime for the devices.BRIEF DESCRIPTION OF THE DRAWINGS

[0064] The above, as well as additional objects, features and advantages of the invention, will be better understood through the following illustrative and non-limiting detailed description of embodiments of the invention, with reference to the appended drawings, in which:

[0065] Fig. 1 illustrates a prior art embodiment for a CoAP client and a CoAP server performing a block-wise operation.

[0066] Fig. 2 illustrates a network according to an embodiment of the invention.

[0067] Figs. 3-5 illustrate methods according to embodiments of the invention.

[0068] Figs. 6-9 illustrate signaling diagrams according to embodiments of the invention.

[0069] Fig. 10 shows a UE in accordance with some embodiments.

[0070] Fig. 11 illustrates an example of a computer program product in accordance with an embodiment of the invention.

[0071] All the figures are schematic, not necessarily to scale, and generally only show parts which are necessary in order to elucidate the invention, wherein other parts may be omitted or merely suggested.DETAILED DESCRIPTION

[0072] The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention 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 by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0073] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0074] Fig. 1 illustrates a prior art embodiment for a CoAP client and a CoAP server performing a block-wise operation. The method comprises sending from a client to a server, a first message including “CON [MID=1234] , PUT,  / options, 1: 0 / 1 / 128” . The method further comprises, receiving at the client from the server, a message including “ACK [MID=1234] , 2.31 Continue, 1: 0 / 1 / 128” . The method comprises, sending from the client to the server, a message including “CON [MID=1235] , PUT,  / options, 1: 1 / 1 / 128” . Furthermore, the method comprises receiving at the client from the server, a message including “ACK [MID=1235] , 2.31 Continue, 1: 1 / 1 / 128” . In the prior art embodiment, the client initiates a PUT operation towards a server in the first message. The expression “1: 0 / 1 / 128” indicates that the block option is set to 1 (i.e., the Block option 1) , the current block number value is 0, M bit value is 1 (i.e., whether more blocks are coming is set to true or yes) and the size of the block is 128. The Message ID MID field is used to detect message duplication and to match messages of type Acknowledgement / Reset to messages of type Confirmable / Non-confirmable. In the second message, the server indicates, in the acknowledgment, the block which it has received and also indicates to the client to continue the transfer with status code 2.31. When the server has received all the data to be transferred by the client for that transfer, the server may send a message including the status code 2.04, suggesting that the transfer is complete.

[0075] Over Light-weight Machine-to-Machine (LwM2M) , when a firmware update is initiated on an LwM2M server, the firmware image is split into blocks / chunks / parts with a predefined size. The created blocks are sent to the LwM2M client, which identifies them by Message ID MID. The size of the block is defined by the LwM2M server (e.g., 128 bytes) and the firmware image size may range from as little as 80 KiloBytes (KB) to a few MegaBytes  (MB) in size. For example, if a firmware image has a total size of 80 KiB and the image is split into blocks of 128 bytes, then the LwM2M server needs to send 640 messages to the LwM2M client. Once the firmware image has been transferred to the LwM2M client, the LwM2M-based firmware update is initiated.

[0076] The prior art does not provide for implementation of block-wise transfer in LwM2M since the LwM2M specification does not allow for pause and resume of existing block-wise transfers. For example, when a firmware update needs to be performed on an LwM2M client, the connection between the LwM2M server and the LwM2M client may disconnect. This disconnection occurs since firmware updates may take from a few minutes up to an hour to complete, and also due to a variety of other issues such as bandwidth choking, low signal strength and low reliability, to name a few. During such disconnections, the LwM2M client (or the CoAP server) may lose a state of the transfer making it inconvenient to be able to resume the transfer once the connection recovers. In another example, when LwM2M devices such as an LwM2M server or a CoAP client is sending large files to an LwM2M client or a CoAP server, the bandwidth of the link and the throughput of the transfer of files between the two devices is oftentimes less –leading to a break in connection while having no mechanism for resuming the connection from the last state. The LwM2M server may also disrupt the connection in case of one or more of a constraint and / or issues but the LwM2M client is configured to keep waiting until timeout, which is not optimal for energy consumption of the LwM2M client.

[0077] Over LwM2M, when a firmware update has been initiated, the LwM2M server may need to support discontinuous Firmware Over The Air (FOTA) data transfer or Software Over The Air (SOTA) data transfer in scenarios when the LwM2M Server (or the CoAP Client) loses the state of the transfer. The loss of state can occur after a protracted pause, which may happen due to a variety of reasons. For example, there may be a loss of state at the LwM2M server when the LwM2M server detects that a battery level of an LwM2M client (or any other connected device) cannot complete the remaining data transfer. The LwM2M server may wait until the LwM2M client (or the device) is re-charged and pause the on-going data transfer session. In another example, the LwM2M server may lose state of the data transfer when a LwM2M client (or any other device connected to the LwM2M server) detects that a current signal strength is too weak to keep a stable, continuous data transfer. The LwM2M server may wait until the signal strength is back to normal and pause the transfer or the LwM2M client may signal the LwM2M server to pause the on-going data transfer session.

[0078] Currently, LwM2M lacks mechanisms for reducing the amount of retransmitted data which could lead to reduced network load and reduced power consumption for the devices involved, that is, the LwM2M server and the LwM2M client. Additionally, if one of the LwM2M server or the LwM2M client pauses the data transfer session (sender-side) , there is no mechanism to send information to the other of the LwM2M server or the LwM2M client (receiver-side) , that the receiver-side does not need to wait MAX_TRANSMIT_WAIT as defined by RFC 7252 (default value is 93 seconds) . Especially for devices such as the LwM2M client, waiting for a period such as MAX_TRANSMIT_WAIT translates into significant power consumption.

[0079] The disclosure herein provides a mechanism for saving a current state of a block-wise transfer. The disclosure herein further provides a mechanism for pausing a block-wise transfer and resuming the block-wise transfer at a later point in time. In other words, the disclosure herein provides a mechanism for discontinuous / non-continuous data transfer for devices using LwM2M protocol.

[0080] Fig. 2 illustrates a network 200 according to an embodiment of the invention. The network 200 comprises an LwM2M client 210 and an LwM2M server 220. The LwM2M client 210 and the LwM2M server 220 may be a hardware device. In an example, the LwM2M client 210 and / or the LwM2M server 220 may be implemented in a virtual machine. The LwM2M client 210 is configured / adapted / configurable to receive from the LwM2M server 220, a first CoAP message. The first message comprises a confirmable request for initiating a CoAP block-wise transfer with the server. The LwM2M client 210 is further configured to obtain a first object comprising information about the CoAP block-wise transfer. In an embodiment, the first object comprises an LwM2M object. In an example, the LwM2M client comprises a CoAP server and the LwM2M server comprises a CoAP client.

[0081] Fig. 3 illustrates a method 300 according to an embodiment of the invention. The method 300 is performed by an LwM2M client 210 for data transfer between the LwM2M client 210 and an LwM2M server 220 in a network 200. The method comprises receiving 305 from the LwM2M server 220, a first CoAP message. The first CoAP message comprises a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server 220. The method comprises obtaining 310 a first LwM2M object comprising information about the CoAP block-wise transfer. In an example, obtaining 310 the first LwM2M object comprises creating the first LwM2M object at the LwM2M client 210. In an embodiment, the LwM2M client may be a CoAP server. In an embodiment, the LwM2M server may be a CoAP client. In an example, the information about the CoAP block-wise transfer comprises an operational state  of the block-wise transfer. In an example, the operation state of the block-wise transfer may relate to the last state of the block-wise transfer before, for example, a loss of state at the LwM2M client 210. In other words, the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption. In an example, the operational state is saved only when no response is received to the first CoAP message. In an example, the operational state of the block-wise transfer may be one of that: the block-wise transfer has failed, the block-wise transfer cannot continue, the block-wise transfer is pending, the block-wise transfer is completed, the block-wise transfer is incomplete, and the block-wise transfer is ongoing. Optionally, the method further comprises sending 315 to the LwM2M server 220, a second CoAP message including information about the CoAP block-wise transfer after an interruption of the CoAP block-wise transfer. In an example, the method comprises interrupting 320 the CoAP block-wise transfer. In an example, the method comprises using 325 a resource ‘Pause’ in a second LwM2M object, wherein using the resource ‘Pause’ triggers the interruption 320 of the block wise transfer and / or using the resource ‘Pause’ triggers the obtaining 310 of a first LwM2M object comprising information about the CoAP block-wise transfer. In an example, the method comprises resuming 330 the block-wise transfer based on the information about the CoAP block-wise transfer. In an example, the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption. In an example, the first CoAP message and / or the second CoAP message comprise (s) the information about the CoAP block-wise transfer. In an example, the first LwM2M object and the second LwM2M object are the same. In another example, the first LwM2M object and the second LwM2M are different, that is, contents of the first LwM2M object and the contents of the second LwM2M object are different. In an example, the method comprises using 335 a resource ‘Resume’ in the second LwM2M object, wherein using the resource ‘Resume’ triggers the resumption of the CoAP block-wise transfer based on the information obtained about the CoAP block-wise transfer. In an embodiment, using the resource ‘Resume’ triggers a method comprising resuming 330 the CoAP block-wise transfer after the last block successfully received from blocks of the block-wise transfer. The method of resuming 330 enabling a reduction or mitigation of retransmission of blocks in the block-wise transfer. In an example, the method comprises exposing 340 the obtained first LwM2M object to the LwM2M server 220 as an observable resource for CoAP. In an example, the method comprises adjusting 345 block size of the block-wise transfer based on conditions / parameters of the network 200. In an example, the method comprises sending 350 a third CoAP message comprising information about a block from where the block-wise transfer should  resume. In an example, at least one of the first CoAP message, the second CoAP message and the third CoAP message comprises one of: a PUT message; a GET message; and a POST message. In an example, the LwM2M server comprises a CoAP client and the LwM2M client comprises a CoAP server. In an example, the first LwM2M object comprises a ‘Firmware Update’ and / or a ‘Software Update’ . In an example, the second LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ . In an example, any one of the steps 315, 320, 325, 330, 335, 340, 345 and 350 may be performed before or after one or more of steps 305, 310.

[0082] In an embodiment, a condition for interrupting 320 the CoAP block-wise transfer comprises one or more of i) a battery level of the LwM2M client 210 or of the LwM2M server 220 is below a given battery level threshold, ii) a signal strength of a message exchanged between the LwM2M client 210 and the LwM2M server 220 is below a given strength threshold, iii) a reduction of a reliability metric of the network 200, iv) a service level agreement (SLA) of the network 200 is not met, v) a Quality of Service (QoS) level of the network 200 is below a QoS threshold, vi) a Quality of Experience (QoE) level of the network 200 is below a QoE threshold, vii) a throughput at the LwM2M client 210 or the LwM2M server 220 is below a throughput threshold, viii) a QoS level of the LwM2M client 210 is below a QoS threshold, ix) a QoS level of the LwM2M server 220 is below a QoS threshold, x) a QoE level of the LwM2M client 210 is below a QoE threshold, xi) x) a QoE level of the LwM2M server 220 is below a QoE threshold.

[0083] In an example, the information about the block-wise transfer comprises at least one of i) an identifier related to the block-wise transfer, ii) an instance number of the block-wise transfer, iii) an expected size of the block-wise transfer, iv) a path related to where contents of the block-wise transfer is being stored, v) information related to a block option being used for the block-wise transfer, vi) information related to a block size being used for the block-wise transfer, and vii) information related to a last block received. In an example, the identifier related to the block-wise transfer may be a message ID or MID which represents a message number. In another example, the identifier related to the block-wise transfer may be based on a block size or SZX and a block number. In an example, the instance number of the block-wise transfer may be related to the created LwM2M object. In an example, the path related to where contents of the block-wise transfer is being stored relates to where the contents are being stored at the LwM2M client 210.

[0084] Fig. 4 illustrates a method 400 according to an embodiment of the invention. The method 400 is performed by an LwM2M server 220 for data transfer between an LwM2M client 210 and the LwM2M server 220 in a network 200. The method comprises sending 405  to the LwM2M client 210, a first CoAP message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server 220. The method further comprises obtaining 410 a first LwM2M object comprising information about the CoAP block-wise transfer. In an example, obtaining 410 the first LwM2M object comprises receiving from the LwM2M client, the first LwM2M object. In an example, the information about the CoAP block-wise transfer comprises an operational state of the block-wise transfer. In an example, the method comprises receiving 415 from the LwM2M client, a second CoAP message including information about the CoAP block-wise transfer after an interruption of the CoAP block-wise transfer. In an example, the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption. Optionally, the method comprises interrupting 420 the CoAP block-wise transfer. In an example, the method comprises using 425 a resource ‘Pause’ in a second LwM2M object, wherein using the resource ‘Pause’ triggers the interruption of the block wise transfer and / or using the resource ‘Pause’ triggers the obtaining of a first LwM2M object comprising information about the CoAP block-wise transfer. In an example, the method comprises resuming 430 the block-wise transfer based on the information about the CoAP block-wise transfer. In an example, the method comprises using 435 a resource ‘Resume’ in the second LwM2M object, wherein using the resource ‘Resume’ triggers the resumption of the CoAP block-wise transfer based on the information obtained about the CoAP block-wise transfer. In an example, using 435 the resource ‘Resume’ triggers a method comprising resuming the CoAP block-wise transfer after the last block successfully received from blocks of the block-wise transfer. In an example, the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption. In an example, the first CoAP message and / or the second CoAP message comprise (s) the information about the CoAP block-wise transfer. In an example, the first LwM2M object and the second LwM2M object are the same. In another example, the first LwM2M object and the second LwM2M are different, that is, contents of the first LwM2M object and the contents of the second LwM2M object are different. In an example, the method comprises observing 440 the obtained first LwM2M object as an observable resource for CoAP. Optionally, the method comprises adjusting 445 block size of the block-wise transfer based on conditions or parameters of the network 200. In an example, the method comprises receiving 450 a third CoAP message comprising information about a block from where the block-wise transfer should resume. In an example, at least one of the first CoAP message, the second CoAP message and the third CoAP message comprises one of: a PUT message; a GET message; and a POST message. In an  example, the LwM2M server comprises a CoAP client and the LwM2M client comprises a CoAP server. In an example, the first LwM2M object comprises a ‘Firmware Update’ and / or a ‘Software Update’ . In an example, the second LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ . In an example, any one of the steps 415, 420, 425, 430, 435, 440, 445 and 450 may be performed before or after one or more of steps 405, 410.

[0085] In an embodiment, a condition for interrupting 320 the CoAP block-wise transfer comprises one or more of i) a battery level of the LwM2M client 210 or of the LwM2M server 220 is below a given battery level threshold, ii) a signal strength of a message exchanged between the LwM2M client 210 and the LwM2M server 220 is below a given strength threshold, iii) a reduction of a reliability metric of the network 200, iv) a service level agreement (SLA) of the network 200 is not met, v) a Quality of Service (QoS) level of the network 200 is below a QoS threshold, vi) a Quality of Experience (QoE) level of the network 200 is below a QoE threshold, vii) a throughput at the LwM2M client 210 or the LwM2M server 220 is below a throughput threshold, viii) a QoS level of the LwM2M client 210 is below a QoS threshold, ix) a QoS level of the LwM2M server 220 is below a QoS threshold, x) a QoE level of the LwM2M client 210 is below a QoE threshold, xi) x) a QoE level of the LwM2M server 220 is below a QoE threshold.

[0086] In an example, the information about the block-wise transfer comprises at least one of i) an identifier related to the block-wise transfer, ii) an instance number of the block-wise transfer, iii) an expected size of the block-wise transfer, iv) a path related to where contents of the block-wise transfer is being stored, v) information related to a block option being used for the block-wise transfer, vi) information related to a block size being used for the block-wise transfer, and vii) information related to a last block received. In an example, the identifier related to the block-wise transfer may be a message ID or MID which represents a message number. In another example, the identifier related to the block-wise transfer may be based on a block size or SZX and a block number. In an example, the instance number of the block-wise transfer may be related to the created LwM2M object. In an example, the path related to where contents of the block-wise transfer is being stored relates to where the contents are being stored at the LwM2M client 210.

[0087] Fig. 5 illustrates a method 500 according to an embodiment of the invention. The method 500 is performed by a network 200 comprising an LwM2M client 210 and an LwM2M server 220. The method 500 comprises receiving 505, at the LwM2M client 210 from the LwM2M server 220, a first CoAP message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server. The method further comprises obtaining  510 a first LwM2M object comprising information about the CoAP block-wise transfer. Optionally, the method comprises the operations performed according to the methods described in relation to Figures 3 and 4.

[0088] In an example, the first LwM2M object may be an object called “FOTA_STATE” . FOTA_STATE relates to an object for a Firmware Over The Air (FOTA) transfer. The FOTA_STATE object may be used for large file transfers other than FOTA transfers as well. The LwM2M client is configured to store the FOTA_STATE in a path in its memory. The FOTA_STATE object may comprise one or more of: a state of an FOTA transfer FOTA_STATE*, an instance number instance number, an identifier for the FOTA transfer FotaID, a path wherein the FOTA state is saved FotaPath, a size of the FOTA in KiB FotaSize, block option number for the FOTA block-wise transfer BlockOpt, size of a part or a block of the FOTA data transfer BlockSize and an indication of a last block that was successfully transferred to the LwM2M client LastBlock. All the parameters of the LwM2M object may be read, erased and written. In other words, the LwM2M object provides write and read access. In other words, the LwM2M object includes an identifier of the specific FOTA transfer, the instance number, the expected total size of the FOTA, the path where the file is being stored, the Block Option being used, the Block Size and the Last Block that has successfully been transferred. The last block is always tied to a specific block size, this is because the resource representation that is partitioned will vary depending on the block. For example, a FOTA transfer of 80 KiB can be split into 80 blocks of size 1024 bytes or can be split into 320 blocks of size 256 bytes. A similar object may be defined for SOTA as well, denoted by “SOTA_STATE” with corresponding parameters.

[0089] Fig. 6 illustrates a signaling diagram according to an embodiment of the invention. The signaling diagram represents an example interaction between an LwM2M client 210 and an LwM2M server 220. In the example interaction, the data to be transferred from the LwM2M server 210 to the LwM2M client is 80 KiB and block size BlockSize is 1024 bytes. Additionally, the data to be transferred is a FOTA which is stored in the path  / firmware. The LwM2M server 220 is configured to send to the LwM2M client 210, a CoAP message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server. The CoAP message contents are “CON [MID=11] , PUT,  / firmware, 1: 0 / 1 / 1024” . The expression “1: 0 / 1 / 1024” indicates that the block option is set to 1 (i.e., the Block option 1) , the current block number value is 0, M bit value is 1 (i.e., whether more blocks are coming is set to true or yes) and the size of the block is 1024. The Message ID MID field indicates a value of 11, which is used to detect message duplication and to match messages of type Acknowledgement / Reset to  messages of type Confirmable / Non-confirmable. In response to the first CoAP message, the LwM2M client 210 is configured to send to the LwM2M server 220, a message comprising an acknowledgment ACK, the block that the LwM2M client 210 has received, i.e., the first block (1: 0 / 1 / 1024) of the total transfer for the FOTA and also indicates to the client to continue the transfer with status code 2.31, that is, 2.31 Continue response code as defined by RFC 7959. A similar process of sending a message with the second block of the total transfer to the LwM2M client 210 from the LwM2M server 220 continues until there is a break in connection between the LwM2M client 210 and the LwM2M server 220. In an example, the connection breaks after 3 blocks are transferred and the last CON message, that is, the fourth CON message is never replied to, by the LwM2M client 210. In other words, when the fourth CON message is not replied to within a particular time period, there is a high probability of a break in connection. At this point, the LwM2M client 210 possesses 3 blocks of 1024 bytes each and the LwM2M client 210 is contextually aware of the proportion of the total transfer of the FOTA that the LwM2M client 210 possesses. Either of the LwM2M client 210 or the LwM2M server 220 is configured to trigger an interruption at the LwM2M client 210 by using a new resource PAUSE in the LwM2M FOTA Object as defined by Object ID 5 of Firmware Update in the documentation for Lightweight M2M by Open Mobile Alliance. In other words, over LwM2M, a new resource PAUSE in the LwM2M FOTA Object “ / 5” , wherein  / 5 refers to the object ID 5 of Firmware Update, can trigger this interruption. The LwM2M Client 210 is configured to store information about the last successfully transferred block and the block size of the previous transfer.

[0090] Fig. 7 illustrates a signaling diagram according to an embodiment of the invention. The signaling diagram represents an example interaction between an LwM2M client 210 and an LwM2M server 220, picking up from the break in connection for the example as described in relation to Fig. 6. In the example interaction, the data to be transferred from the LwM2M server 210 to the LwM2M client is 80 KiB and block size BlockSize is 1024 bytes, and when the connection is established again, the transfer of FOTA continues from the last successfully received block. The last successfully received block in the example of Fig. 6 was block 2, which is the third block. When the connection is re-established, the LwM2M server 220 is configured to send a message including a confirmable request CON with contents similar to the first CoAP message, that is, “CON [MID=44] , PUT,  / firmware, 1: 0 / 1 / 1024” . Since the message ID MID is different for this message, in an example, the MID value is 44. In response to this message, the LwM2M client 210 which now possesses the first three blocks (block 0, block 1 and block 2) , is configured to send a message to the LwM2M server 220 with the  contents “ACK [MID=44] , 2.31 Continue, 1: 3 / 1 / 1024” . The response message indicates that the LwM2M client 210 possesses blocks 0-2 already and thus, provides an indication that the LwM2M client 210 has now received the fourth block, block 3. In other words, when the LwM2M server 220 tries to start the FOTA transfer from the beginning or from the first block, the LwM2M client 210 replies with the last block received, that is the last ACK with a MID equal to the current CON request, that is MID = 44. This process of resuming the firmware transfer from the last successfully transferred block after a break in connection involves process equivalent to a handshake between the LwM2M client 210 and the LwM2M server 220. In other words, in this case the LwM2M client 210 is configured to reply with “2.31 Continue, 1:3 / 1 / 1024” instead of “2.31 Continue, 1: 0 / 1 / 1024” . The LwM2M server 220 is configured to adjust according to the response of the LwM2M client 210 and continue from the block that was signaled by the LwM2M client 210.

[0091] Further, the LwM2M server 220 is configured to send to the LwM2M client 210, a message including “CON [MID=45] , PUT,  / firmware, 1: 4 / 1 / 1024” . The LwM2M client 210 is configured to send, in response to the received message, a message including “ACK [MID=45] , 2.31 Continue, 1: 4 / 1 / 1024” . The process of sending from the LwM2M server 220 to the LwM2M client 210 and receiving at the LwM2M server 210 from the LwM2M client 220 then continues until the entire payload of FOTA is transferred.

[0092] If any break in connection occurs, either of the LwM2M client 210 or the LwM2M server 220 is configured to trigger a resumption at the LwM2M client 210 by using a new resource RESUME in the LwM2M FOTA Object as defined by Object ID 5 of Firmware Update in the documentation for Lightweight M2M by Open Mobile Alliance before continuing the process as described in relation to Fig. 7. Over LwM2M, a new resource RESUME in the LwM2M FOTA Object ( / 5) can trigger this continuation. The LwM2M Client 210 is configured to store information about the last successfully transferred block and the block size of the previous transfer. In an example, this mechanism of resuming from the last successfully transferred block may be implemented if LwM2M the FOTA_STATE object is created in the LwM2M FOTA Object “ / 5” . The LwM2M server 220 may be configured to send or indicate the correct current block to the LwM2M client 210.

[0093] Fig. 8 illustrates a signaling diagram according to an embodiment of the invention. The signaling diagram represents an example interaction between an LwM2M client 210 and an LwM2M server 220, picking up from the break in connection for the example as described in relation to Fig. 6 and / or Fig. 7. In the example interaction, the data to be transferred from the LwM2M server 210 to the LwM2M client is 80 KiB and block size BlockSize is 1024 bytes,  and when the connection is established again, the transfer of FOTA continues from the last successfully received block. In an example, the LwM2M client 210 may not be able adapt to different FOTA block-wise modes. In these cases, the LwM2M server 220 is configured to initiate or drive the entire FOTA process by means of an FOTA_STATE object as described in relation to Figures 6 and 7. The LwM2M client 210 is configured to expose or make accessible to the LwM2M server 220, the FOTA_STATE as an observable resource as defined by RFC 7641. The LwM2M server 220 is configured to read the FOTA_STATE object and take an appropriate action such as a PAUSE or RESUME as defined in relation to Figures 2-7.

[0094] The last successfully received block in the example of Fig. 6 was block 2, which is the third block. In the present example, considering that the last successfully received block was the seventy-ninth block, block 78. When the connection is re-established, the LwM2M server 220 is configured send a message including “GET,  / fota_state” which indicates that the LwM2M server 220 send a GET request to the LwM2M client 210 to obtain the FOTA of the LwM2M client 210. In an example, the LwM2M client is configured to send in response to the “GET,  / fota_state” message, a message including “ACK 2.05 [283, 80,  / firmware, 1, 1024, 78] ” which indicates that the stored FotaID is 283, firmware size is 80 KiB, path of the firmware is “ / firmware” , Blockwise Option is set to 1 because PUT was the last CoAP method received by the LwM2M client 210, block size is set to 1024 and the last successful block is block 78. This message from the LwM2M client 210 also indicates that the seventy-ninth block was received but the connection broke before sending the final block, that is, block 79. The LwM2M server 220 is configured to continue with the parameters as received from the LwM2M client 210 and send the eightieth block, block 79 to the LwM2M client 210 to conclude the FOTA. In other words, the LwM2M server 220 is configured to send to the LwM2M client 210, a message including “CON [MID=XX] , PUT,  / firmware, 1: 79 / 0 / 1024” wherein the Message ID MID is set to XX. The LwM2M client 210 is configured to send a message including “ACK [MID=XX] , 2.04 Changed 1: 79 / 0 / 1024” indicating that the eightieth block was received and thus concludes the firmware and / or software transfer.

[0095] Fig. 9 illustrates a signaling diagram according to an embodiment of the invention. The signaling diagram represents an example interaction between an LwM2M client 210 and an LwM2M server 220, picking up from the break in connection for the example as described in relation to Fig. 6, Fig. 7, and / or Fig. 8. In the example interaction, the data to be transferred from the LwM2M server 210 to the LwM2M client is 80 KiB and block size BlockSize is 1024 bytes, and when the connection is established again, the transfer of the firmware or software continues from the last successfully received block. In an example, after re-establishment of  connection between the LwM2M server 220 and the LwM2M client 210, the LwM2M server 220 is configured to detect a poor network reliability or a network reliability that is below a desired threshold due to which error rates during the interaction may increase. In such cases, the LwM2M server 220 is configured to indicate that a different block size as compared to the currently used block size. The FotaSize parameter of the FOTA_STATE object may be used to adjust the block-size transfer rate to ensure a reliable transfer. In an example, the LwM2M server 220 is configured to send a message including “CON [MID=45] , PUT,  / firmware, 1: 78 / 1 / 1024” , and the LwM2M server 220 is configured to receive from the LwM2M client 210, a message including “ACK [MID=45] , 4.08 1: 78 / 1 / 1024” . Thus, the last successfully received block by the LwM2M client 210 is the seventy-ninth block of the total firmware update, block 78. The LwM2M server 220 is further configured to detect latency and / or reliability. If the LwM2M server 220 detects a high latency and / or a high unreliability (low / poor reliability) , the LwM2M server 220 is configured to send a message including “CON [MID=46] , PUT,  / firmware, 1: 316 / 1 / 256” . The message indicates that 320 blocks of 256 bytes each would be transferred after the last successfully transferred block of 1024 bytes. Since the block size is reduced to 256 bytes, the block number would increase from 316 to 319 to complete the transfer of the firmware. The LwM2M server 220 is configured to receive from the LwM2M client 210, a message including “ACK [MID=46] , 2.31 Continue, 1: 316 / 1 / 256” for the block number 316. The process of sending to the LwM2M client 210 and receiving from the LwM2M client 210 continues until the transfer of the firmware and / or software is complete. In other words, in the example, the FOTA process indicates an error by, for example, a 4.08 error code sent from the LwM2M client 210 to the LwM2M server 220. In this case, the LwM2M server is configured to adapt the transfer of the FOTA to have lower block sizes, thereby increasing the chance of completing the transfer with the prevailing network conditions. Over LwM2M, the mechanism of adapting bit rate may be implemented by the same PAUSE and / or RESUME mechanism and / or by a modification of the block size, provided that the LwM2M server 220 has exchanged / communicated the total file size of the FOTA with the LwM2M client 210 over the CoAP Option size1. The mechanism of adapting the bit rate by the LwM2M server 220 is provided by configuring the LwM2M server 220 to calculate a new block size and append smaller block (corresponding to the new block size) to the last successfully transferred block for the FOTA, i.e., in this example, block 78 with size 1024.

[0096] The methods, signaling diagram and mechanisms as described in relation to Figures 2-9 for FOTA may be applied to a case where the data to be transferred is a SOTA or any other larger file. In an example, wherein the data to be transferred from an LwM2M server 220 to an  LwM2M client 210 is a SOTA, the LwM2M object for SOTA is denoted by Object ID 9 or “ / 9” as defined in the documentation for Lightweight M2M by Open Mobile Alliance. Considering the fact that LwM2M is primarily used with UDP, the process as described in relation to Figures 2-9 may be performed for any other stateless transport protocol as well. In general, CoAP should remain stateless. The confirmable messages ensure reliability with some additional features. Even TCP will face the same situation during FOTA and / or SOTA for LwM2M.

[0097] In some embodiments, the LwM2M server 220 may be a CoAP client. In some embodiments, the LwM2M client 210 may be a CoAP server. In some embodiments, the LwM2M server 220 is an LwM2M manager node. In some embodiments, the LwM2M client 210 is an IoT device.

[0098] The skilled person may understand that the teachings of the disclosure herein may apply to other UDP-based protocols, involving communication interaction between a server and a client, such as Domain Name Server (DNS) , Network Basic Input / Output System (NetBIOS) , Session Initiation Protocol (SIP) , Simple Network Management Protocol (SNMP) , Network Time Protocol (NTP) , Dynamic Host Configuration Protocol (DHCP) , Lightweight Directory Access Protocol (LDAP) and Quick UDP Internet Connections (QUIC) .

[0099] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the network 200 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The network 200 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0100] The LwM2M client 210 and the LwM2M server 220 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with other network nodes and other communication devices.

[0101] As a whole, the network 200 of Fig. 2 enables connectivity between the LwM2M client 210 and the LwM2M server 220, network nodes, and hosts. In that sense, the network may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM) ; Universal Mobile Telecommunications System (UMTS) ; Long Term Evolution (LTE) , and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g.,  6G) ; wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi) ; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax) , Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0102] In some examples, the network 200 is a cellular network that implements 3GPP standardized features. Accordingly, the network 200 may support network slicing to provide different logical networks to different devices that are connected to the network 200. For example, the network 200 may provide Ultra Reliable Low Latency Communication (URLLC) services to the LwM2M client 210 and the LwM2M server 220, while providing Enhanced Mobile Broadband (eMBB) services to other LwM2M clients and the LwM2M servers, and / or Massive Machine Type Communication (mMTC)  / Massive IoT services to yet further LwM2M clients and LwM2M servers.

[0103] In some examples, the LwM2M client 210 and the LwM2M server 220 are configured to transmit and / or receive information without direct human interaction. For instance, the LwM2M client 210 and / or the LwM2M server 220 may be designed to transmit information to the network 200 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network 200. Additionally, the LwM2M client 210 and the LwM2M server 220 may be configured for operating in single-or multi-RAT or multi-standard mode. For example, the LwM2M client 210 and the LwM2M server 220 may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC) , such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio –Dual Connectivity (EN-DC) .

[0104] Fig. 10 shows a UE 1000 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA) , wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , smart device, wireless customer-premise equipment (CPE) , vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP) , including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC)  UE. In an example, the UE 1000 is an LwM2M client 210 and / or an LwM2M server 220. The UE is configured to perform the operations according to any of the methods disclosed herein.

[0105] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC) , vehicle-to-vehicle (V2V) , vehicle-to-infrastructure (V2I) , or vehicle-to-everything (V2X) . In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller) . Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter) .

[0106] The UE 1000 includes processing circuitry 1002 that is operatively coupled via a bus 1004 to an input / output interface 1006, a power source 1008, a memory 1010, a communication interface 1012, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Fig. 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0107] The processing circuitry 1002 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1010. The processing circuitry 1002 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs) , application specific integrated circuits (ASICs) , etc. ) ; programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP) , together with appropriate software; or any combination of the above. For example, the processing circuitry 1002 may include multiple central processing units (CPUs) .

[0108] In the example, the input / output interface 1006 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1000. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera  (e.g., a digital camera, a digital video camera, a web camera, etc. ) , a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0109] In some embodiments, the power source 1008 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet) , photovoltaic device, or power cell, may be used. The power source 1008 may further include power circuitry for delivering power from the power source 1008 itself, and / or an external power source, to the various parts of the UE 1000 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1008. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1008 to make the power suitable for the respective components of the UE 1000 to which power is supplied.

[0110] The memory 1010 may be or be configured to include memory such as random access memory (RAM) , read-only memory (ROM) , programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1010 includes one or more application programs 1014, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1016. The memory 1010 may store, for use by the UE 1000, any of a variety of various operating systems or combinations of operating systems.

[0111] The memory 1010 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID) , flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM) , synchronous dynamic random access memory (SDRAM) , external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) , such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded  UICC (eUICC) , integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card. ’ The memory 1010 may allow the UE 1000 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1010, which may be or comprise a device-readable storage medium.

[0112] The processing circuitry 1002 may be configured to communicate with an access network or other network using the communication interface 1012. The communication interface 1012 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1022. The communication interface 1012 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network) . Each transceiver may include a transmitter 1018 and / or a receiver 1020 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth) . Moreover, the transmitter 1018 and receiver 1020 may be coupled to one or more antennas (e.g., antenna 1022) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0113] In the illustrated embodiment, communication functions of the communication interface 1012 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA) , Wideband Code Division Multiple Access (WCDMA) , GSM, LTE, New Radio (NR) , UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP) , synchronous optical networking (SONET) , Asynchronous Transfer Mode (ATM) , QUIC, Hypertext Transfer Protocol (HTTP) , and so forth.

[0114] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1012, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature) , random (e.g., to even out the load from reporting from several  sensors) , in response to a triggering event (e.g., when moisture is detected an alert is sent) , in response to a request (e.g., a user initiated request) , or a continuous stream (e.g., a live video feed of a patient) .

[0115] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0116] A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR) , a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal-or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV) , and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE 1000 shown in Fig. 10.

[0117] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0118] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0119] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0120] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0121] Fig. 11 illustrates an example of a computer program product in accordance with an embodiment of the invention. Computer program product 1110 includes a computer readable storage medium 1130 (storage or recording medium) storing a computer program 1120 comprising computer readable instructions. Computer readable medium 1130 of the UE 1000, may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk) , optical media, memory devices (e.g., random access memory, flash memory) , and the like. In some embodiments, the computer readable instructions of computer program 1120 are configured such that when executed by processing circuitry 1002, the computer readable instructions cause the UE 1000 to perform steps described herein (e.g., method 300, method 400, method 500) . In other embodiments, the UE 1000 may be configured / operable to perform steps described herein without the need for code. That is, for example, processing circuitry 1002 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0122] The computer program code mentioned above may also be provided, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the hardware. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a LwM2M server 220 or an LwM2M client 210 or a network 200, and downloaded to the hardware at production, and / or during software updates.

[0123] Although a UE 1000 has been used in the above embodiments, a person skilled in the art understands that the apparatus may also be a UE, an Internet of Things (IoT) device, a virtual machine, a cloud-computing node, an edge node, any electronic device with a network interface chip, a network management node, Operations Sub-System (OSS) , Network Management System (NMS) and a 2G / 3G / 4G / 5G / 6G network node.

[0124] The LwM2M client 210 or the LwM2M server 220 in the form of an IoT device may be a device for use in one or more application domains, these domains comprising, but not limited to, home, city, wearable technology, extended reality, industrial application, and healthcare.

[0125] By way of example, the IoT device for a home, an office, a building or an infrastructure may be a baking scale, a coffee machine, a grill, a fridge, a refrigerator, a freezer, a microwave oven, an oven, a toaster, a water tap, a water heater, a water geyser, a sauna, a vacuum cleaner, a washer, a dryer, a dishwasher, a door, a window, a curtain, a blind, a furniture, a light bulb, a fan, an air-conditioner, a cooler, an air purifier, a humidifier, a speaker, a television, a laptop, a personal computer, a gaming console, a remote control, a vent, an iron, a steamer, a pressure cooker, a stove, an electric stove, a hair dryer, a hair styler, a mirror, a printer, a scanner, a photocopier, a projector, a hologram projector, a 3D printer, a drill, a hand-dryer, an alarm clock, a clock, a security camera, a smoke alarm, a fire alarm, a connected doorbell, an electronic door lock, a lawnmower, a thermostat, a plug, an irrigation control device, a flood sensor, a moisture sensor, a motion detector, a weather station, an electricity meter, a water meter, and a gas meter.

[0126] By further ways of example, the IoT device for use in a city, urban, or rural areas may be connected street lighting, a connected traffic light, a traffic camera, a connected road sign, an air control / monitor, a noise level detector, a transport congestion monitoring device, a transport controlling device, an automated toll payment device, a parking payment device, a sensor for monitoring parking usage, a traffic management device, a digital kiosk, a bin, an air quality monitoring sensor, a bridge condition monitoring sensor, a fire hydrant, a manhole sensor, a tarmac sensor, a water fountain sensor, a connected closed circuit television, a scooter, a hoverboard, a ticketing machine, a ticket barrier, a metro rail, a metro station device, a passenger information panel, an onboard camera, and other connected device on a public transport vehicle.

[0127] As further way of example, the IoT device may be a wearable device, or a device related to extended reality, wherein the device related to extended reality may be a device related to augmented reality, virtual reality, merged reality, or mixed reality. Examples of such IoT devices may be a smart-band, a tracker, a haptic glove, a haptic suit, a smartwatch, clothes, eyeglasses, a head mounted display, an ear pod, an activity monitor, a fitness monitor, a heart rate monitor, a ring, a key tracker, a blood glucose meter, and a pressure meter.

[0128] As further ways of example, the IoT device may be an industrial application device wherein an industrial application device may be an industrial unmanned aerial vehicle, an intelligent industrial robot, a vehicle assembly robot, and an automated guided vehicle.

[0129] As further ways of example, the IoT device may be a transportation vehicle, wherein a transportation vehicle may be a bicycle, a motor bike, a scooter, a moped, an auto rickshaw, a rail transport, a train, a tram, a bus, a car, a truck, an airplane, a boat, a ship, a ski board, a  snowboard, a snow mobile, a hoverboard, a skateboard, roller-skates, a vehicle for freight transportation, a drone, a robot, a stratospheric aircraft, an aircraft, a helicopter and a hovercraft.

[0130] As further ways of example, the IoT device may be a health or fitness device, wherein a health or fitness device may be a surgical robot, an implantable medical device, a non-invasive medical device, and a stationary medical device which may be: an in-vitro diagnostic device, a radiology device, a diagnostic imaging device, and an x-ray device.

Claims

1.A method (300) performed by a Lightweight Machine-to-Machine, LwM2M, client (210; 1000) for data transfer between the LwM2M client (210; 1000) and an LwM2M server (220; 1000) in a network (200) , the method comprising:receiving (305) from the LwM2M server, a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server; andobtaining (310) a first LwM2M object comprising information about the CoAP block-wise transfer.2.The method of claim 1, wherein obtaining (310) the first LwM2M object comprises:creating the first LwM2M object at the LwM2M client.3.The method of claims 1 or 2, wherein the information about the CoAP block-wise transfer comprises an operational state of the block-wise transfer.4.The method according to one or more of the preceding claims, comprising:sending (315) to the LwM2M server, a second CoAP message including information about the CoAP block-wise transfer after an interruption of the CoAP block-wise transfer.5.The method according to claim 4, wherein the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption.6.The method according to one or more of the preceding claims, comprising interrupting (320) the CoAP block-wise transfer.7.The method according to claim 6, comprising using (325) a resource ‘Pause’ in a second LwM2M object, wherein using the resource ‘Pause’ triggers the interruption of the block wise transfer and / or using the resource ‘Pause’ triggers the obtaining of a first LwM2M object comprising information about the CoAP block-wise transfer.8.The method according to claim 6 or 7, wherein a condition for interrupting the CoAP block-wise transfer comprises one or more of:a battery level of the LwM2M client or of the LwM2M server is below a given battery level threshold;a signal strength of a message exchanged between the LwM2M client and the LwM2M server is below a given strength threshold;a reduction of a reliability of the network;a service level agreement, SLA, of the network is not met;a Quality of Service, QoS, level of the network is below a QoS threshold;a Quality of Experience, QoE, level of the network is below a QoE threshold; anda throughput at the LwM2M client or the LwM2M server is below a throughput threshold.9.The method of one or more of claims 6 to 8, comprising resuming (330) the block-wise transfer based on the information about the CoAP block-wise transfer.10.The method of claim 9, comprising using (335) a resource ‘Resume’ in the second LwM2M object, wherein using the resource ‘Resume’ triggers the resumption of the CoAP block-wise transfer based on the information obtained about the CoAP block-wise transfer.11.The method of claim 10, wherein using the resource ‘Resume’ triggers a method comprising:resuming the CoAP block-wise transfer after the last block successfully received from blocks of the block-wise transfer.12.The method according to one or more of the preceding claims, wherein the first CoAP message comprises one of: a PUT message; a GET message; or a POST message.13.The method to one or more of the preceding claims, wherein the information about the block-wise transfer comprises at least one of:an identifier related to the block-wise transfer;an instance number of the block-wise transfer;an expected size of the block-wise transfer;a path related to where contents of the block-wise transfer is being stored;information related to a block option being used for the block-wise transfer;information related to a block size being used for the block-wise transfer; andinformation related to a last block received.14.The method of one or more of the preceding claims, wherein the LwM2M server comprises a CoAP client and the LwM2M client comprises a CoAP server.15.[Corrected under Rule 26, 04.08.2023]The method of one or more of the preceding claims, wherein the first LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ .16.The method of one or more of the preceding claims, wherein the second LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ .17.The method of one or more of the preceding claims, comprising exposing (340) the obtained first LwM2M object to the LwM2M server as an observable resource for CoAP.18.The method of one or more of the preceding claims, comprising adjusting (345) block size of the block-wise transfer based on network conditions.19.The method of one or more of the preceding claims, comprising sending (350) a third CoAP message comprising information about a block from where the block-wise transfer should resume.20.A method (400) performed by a Lightweight Machine-to-Machine, LwM2M, server (220; 1000) for data transfer between an LwM2M client (210; 1000) and the LwM2M server (210; 1000) in a network (200) , the method comprising:sending (405) to the LwM2M client, a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server; andobtaining (410) a first LwM2M object comprising information about the CoAP block-wise transfer.21.The method of claim 20, wherein obtaining (410) the first LwM2M object comprises:receiving from the LwM2M client, the first LwM2M object.22.The method of claims 20 or 21, wherein the information about the CoAP block-wise transfer comprises an operational state of the block-wise transfer.23.The method according to one or more of the preceding claims, comprising:receiving (415) from the LwM2M client, a second CoAP message including information about the CoAP block-wise transfer after an interruption of the CoAP block-wise transfer.24.The method according to claim 23, wherein the information about the CoAP block-wise transfer includes information about a last block successfully transferred before the interruption.25.The method according to one or more of claims 20 to 23, comprising interrupting (420) the CoAP block-wise transfer.26.The method according to claim 25, comprising using (425) a resource ‘Pause’ in a second LwM2M object, wherein using the resource ‘Pause’ triggers the interruption of the block wise transfer and / or using the resource ‘Pause’ triggers the obtaining a first LwM2M object comprising information about the CoAP block-wise transfer.27.The method according to claim 25 or 26, wherein a condition for interrupting the CoAP block-wise transfer comprises one or more of:a battery level of the LwM2M client or of the LwM2M server is below a given battery level threshold;a signal strength of a message exchanged between the LwM2M client and the LwM2M server is below a given strength threshold;a reduction of a reliability of the network;a service level agreement, SLA, of the network is not met;a Quality of Service, QoS, level of the network is below a QoS threshold;a Quality of Experience, QoE, level of the network is below a QoE threshold; anda throughput at the LwM2M client or the LwM2M server is below a throughput threshold.28.The method of one or more of claims 25 to 27, comprising resuming (430) the block-wise transfer based on the information about the CoAP block-wise transfer.29.The method of claim 28, comprising using (435) a resource ‘Resume’ in the second LwM2M object, wherein using the resource ‘Resume’ triggers the resumption of the CoAP block-wise transfer based on the information obtained about the CoAP block-wise transfer.30.The method of claim 29, wherein using the resource ‘Resume’ triggers a method comprising:resuming the CoAP block-wise transfer after the last block successfully received from blocks of the block-wise transfer.31.The method according to one or more of claims 20 to 30, wherein the first CoAP message comprises one of: a PUT message; a GET message; and a POST message.32.The method to one or more of claims 20 to 31, wherein the information about the block-wise transfer comprises at least one of:an identifier related to the block-wise transfer;an instance number of the block-wise transfer;an expected size of the block-wise transfer;a path related to where contents of the block-wise transfer is being stored at the LwM2M client;information related to a block option being used for the block-wise transfer;information related to a block size being used for the block-wise transfer; andinformation related to a last block sent.33.The method of one or more of claims 20 to 32, wherein the LwM2M server comprises a CoAP client and the LwM2M client comprises a CoAP server.34.The method of one or more of claims 20 to 33, wherein the first LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ .35.The method of one or more of claims 20 to 34, wherein the second LwM2M object comprises a ‘Firmware Update’ or a ‘Software Update’ .36.The method of one or more of claims 20 to 35, comprising observing (440) the obtained first LwM2M object as an observable resource for CoAP.37.The method of one or more of claims 20 to 36, comprising adjusting (445) block size of the block-wise transfer based on network conditions.38.The method of one or more of claims 20 to 37, comprising receiving (450) a third CoAP message comprising information about a block from where the block-wise transfer should resume.39.A Lightweight Machine-to-Machine, LwM2M, client (210) for data transfer between the LwM2M client (210) and an LwM2M server (220) in a network (200) , the LwM2M client (210) adapted to:receive (305) from the LwM2M server, a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server; andobtain (310) a first LwM2M object comprising information about the CoAP block-wise transfer.40.The LwM2M client (210; 1000) according to claim 39, adapted to perform operations according to any one of claims 1 to 19.41.A Lightweight Machine-to-Machine, LwM2M, client (210; 1000) for data transfer between the LwM2M client (210; 1000) and an LwM2M server (220; 1000) in a network (200; 1000) , the LwM2M client (210; 1000) comprising:at least one processing circuitry (1002) ; andat least one memory (1010) connected to the at least one processing circuitry (1002) and storing program code that is executed by the at least one processing circuitry to perform the method according to any one of claims 1 to 19.42.A computer program (1120) comprising instructions which, when executed by at least one processing circuitry (1002) of a Lightweight Machine-to-Machine, LwM2M, client (210; 1000) , causes the LwM2M client to carry out the method according to any one of claims 1 to 19.43.A computer program product (1110) stored on a non-transitory computer readable medium (1130) and comprising instructions that, when executed by at least one processing circuitry (1002) of a Lightweight Machine-to-Machine, LwM2M, client (210; 1000) , cause the LwM2M client to perform the method according to any one of claims 1 to 19.44.A Lightweight Machine-to-Machine, LwM2M, server (220; 1000) for data transfer between the LwM2M server (220; 1000) and an LwM2M client (210; 1000) in a network (200) , the LwM2M server (220; 1000) adapted to:send (405) to the LwM2M client (210; 1000) , a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server (220; 1000) ; andobtain (410) a first LwM2M object comprising information about the CoAP block-wise transfer.45.The LwM2M server (220; 1000) according to claim 44, adapted to perform operations according to any one of claims 20 to 38.46.A Lightweight Machine-to-Machine, LwM2M, server (220; 1000) for data transfer between the LwM2M server (220; 1000) and an LwM2M client (210; 1000) in a network (200) , the LwM2M server (220; 1000) comprising:at least one processing circuitry (1002) ; andat least one memory (1010) connected to the at least one processing circuitry (1002) and storing program code that is executed by the at least one processing circuitry to perform the method according to any one of claims 20 to 38.47.A computer program (1120) comprising instructions which, when executed by at least one processing circuitry (1002) of a Lightweight Machine-to-Machine, LwM2M, server (220; 1000) , causes the LwM2M server to carry out the method according to any one of claims 20 to 38.48.A computer program product (1110) stored on a non-transitory computer readable medium (1130) and comprising instructions that, when executed by at least one processing circuitry (1002) of a Lightweight Machine-to-Machine, LwM2M, server (220; 1000) , cause the LwM2M server to perform the method according to any one of claims 20 to 38.49.A method (500) performed by a network (200) , comprising a Lightweight Machine-to-Machine, LwM2M, client (210; 1000) and an LwM2M server (220; 1000) , for data transfer between the LwM2M client (210; 1000) and the LwM2M server (220; 1000) , the method comprising:receiving (505) , at the LwM2M client from the LwM2M server, a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server; and obtaining (510) a first LwM2M object comprising information about the CoAP block-wise transfer.50.The method according to claim 49, comprising performing an operation according to any one of claims 1 to 38.51.A network (200) , comprising a Lightweight Machine-to-Machine, LwM2M, client (210; 1000) and an LwM2M server (220; 1000) , for data transfer between the LwM2M client (210; 1000) and the LwM2M server (220; 1000) , the network (200) adapted to:receive (505) , at the LwM2M client from the LwM2M server, a first Constrained Application Protocol, CoAP, message comprising a confirmable request for initiating a CoAP block-wise transfer with the LwM2M server; and obtain (510) a first LwM2M object comprising information about the CoAP block-wise transfer.52.The network (200) adapted to perform operations according to any one of claims 1 to 38.53.A computer program (1120) comprising instructions which, when executed by at least one processing circuitry (1002) of a network (200) , causes the network to carry out the method according to claims 49 or 50.54.A computer program product (1110) stored on a non-transitory computer readable medium (1130) and comprising instructions that, when executed by at least one processing circuitry (1002) of a network (200) , cause the network to perform the method according to claim 49 or 50.

Images