TECHNICAL FIELD The present disclosure relates generally to a first node and methods performed thereby for handling configuration of resources. The present disclosure also relates generally to a second node, and methods performed thereby for handling configuration of resources. The present disclosure also relates generally to a communications network comprising the first node and the second node, for handling configuration of resources. BACKGROUND

Communication devices within a wireless communications network may be wireless devices such as e.g., User Equipments (UEs), stations (STAs), mobile terminals, wireless terminals, terminals, and/or Mobile Stations (MS). Wireless devices are enabled to communicate wirelessly in a cellular communications network or wireless communication network, sometimes also referred to as a cellular radio system, cellular system, or cellular network. The communication may be performed e.g., between two wireless devices, between a wireless device and a regular telephone, and/or between a wireless device and a server via a Radio Access Network (RAN) , and possibly one or more core networks, comprised within the wireless communications network. Wireless devices may further be referred to as mobile telephones, cellular telephones, laptops, or tablets with wireless capability, just to mention some further examples. The wireless devices in the present context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the RAN, with another entity, such as another terminal or a server. The wireless communications network covers a geographical area which may be divided into cell areas, each cell area being served by a network node, such as radio network node or Base Station (BS), which sometimes may be referred to as e.g., Transmission Point (TP), Radio Base Station (RBS), gNB, evolved Node B (“eNB”), “eNodeB”, “NodeB”, “B node”, or BTS (Base Transceiver Station), depending on the technology and terminology used. The base stations may be of different classes such as e.g., Wide Area Base Stations, Medium Range Base Stations, Local Area Base Stations and Home Base Stations, based on transmission power and thereby also cell size. A cell is the geographical area where radio coverage is provided by the base station at a base station site. One base station, situated on the base station site, may serve one or several cells. Further, each base station may support one or several communication technologies. The wireless communications network may also be a non-cellular system, comprising network nodes which may serve receiving nodes, such as wireless devices, with serving beams. In 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), base stations, which may be referred to as eNodeBs or even eNBs, may be directly connected to one or more core networks. In the context of this disclosure, the expression Downlink (DL) may be used for the transmission path from the base station to the wireless device. The expression Uplink (UL) may be used for the transmission path in the opposite direction i.e. , from the wireless device to the base station.

In 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), base stations, which may be referred to as eNodeBs or even eNBs, may be directly connected to one or more core networks. All data transmission in LTE is controlled by the radio base station.

The standardization organization 3GPP is currently in the process of specifying a New Radio Interface called NR or 5G-UTRA, as well as a Fifth Generation (5G) Packet Core Network, which may be referred to as Next Generation Core Network, abbreviated as NG-CN, NGC or 5G CN.

Internet of Things (loT)

The Internet of Things (loT) may be understood as an internetworking of communication devices, e.g., physical devices, vehicles, which may also referred to as "connected devices" and "smart devices", buildings and other items — embedded with electronics, software, sensors, actuators, and network connectivity that may enable these objects to collect and exchange data. The loT may allow objects to be sensed and/or controlled remotely across an existing network infrastructure.

"Things," in the loT sense, may refer to a wide variety of devices such as heart monitoring implants, biochip transponders on farm animals, electric clams in coastal waters, automobiles with built-in sensors, DNA analysis devices for environmental/food/pathogen monitoring, or field operation devices that may assist firefighters in search and rescue operations, home automation devices such as the control and automation of lighting, heating, e.g. a “smart” thermostat, ventilation, air conditioning, and appliances such as washer, dryers, ovens, refrigerators or freezers that may use Wi Fi for remote monitoring. These devices may collect data with the help of various existing technologies and then autonomously flow the data between other devices.

Machine Type Communication (MTC)

Machine Type Communication (MTC) has, especially in the context of the Internet of Things (loT), shown to be a growing market segment. An MTC device may be a communication device, typically a wireless communication device or simply wireless device, that is a self and/or automatically controlled unattended machine and that is typically not associated with an active human user in order to generate data traffic. An MTC device may be typically more simple, and typically associated with a more specific application or purpose, than, and in contrast to, a conventional mobile phone or smart phone.

MTC involves communication in a wireless communication network to and/or from MTC devices, in which communication typically may be of quite different nature and with other requirements than communication associated with e.g. conventional mobile phones and smart phones. In the context of the loT it is evident that MTC traffic will be increasing and thus needs to be increasingly supported in wireless communication systems.

Constrained Application Protocol (CoAP)

Some of the devices that may make use of loT or MTC may be considered constrained devices. A constrained device or constrained node may be understood as a node where some of the characteristics of Internet nodes may not be attainable, often due to cost constraints and/or physical constraints on characteristics such as size, weight, and available power and energy. For example, a constrained device may be a sensor in a car or in a building.

The Constrained Application Protocol (CoAP) may be understood as an example of a protocol designed for loT applications in constrained nodes and constrained networks. CoAP may be understood to provide a request-response based Representational State Transfer (REST)-ful communication architecture between constrained nodes or between constrained nodes and nodes in the Internet. Hence, CoAP may be easily integrated to the web and web services by translating CoAP messages to HTTP. That is, CoAP may be considered to enable constrained devices to communicate with the wider Internet using similar protocols. CoAP may be understood as defined in RFC7252.

On current deployments, CoAP-based solutions like Open Mobile Alliance (OMA) like Lightweight Machine to Machine Protocol (LWM2M) are becoming increasingly popular in order to manage devices in a REST-based fashion.

OMA SpecWorks LwM2M protocol

(http://www.openmobilealliance.org/release/LightweightM2M /V1_1-20180612-C/OMA-TS- LightweightM2M_Core-V1_1-20180612-C.pdf) is a light and compact device management protocol that may be used for managing loT devices and their resources. LwM2M may run on top of CoAP, which may either use User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or Short Message Service (SMS) bindings. Hence, LwM2M may be understood to be compatible with any constrained device which may support CoAP. LwM2M may define three components: - LwM2M Client: An LwM2M Client may contain several LwM2M objects with several resources. An LwM2M Server may execute commands on these resources to manage the client. The commands may be instructions such as to read, to delete or to update the resources. LwM2M Clients may generally be constrained devices.

- LwM2M Server (Management Server): An LwM2M Server may manage LwM2M Clients by sending management commands to them.

- LwM2M Bootstrap Server: An LwM2M Bootstrap Server may be used to manage the initial configuration parameters of LwM2M Clients during bootstrapping of the devices.

To maintain the communication between the components mentioned above, the following LwM2M interfaces may be defined:

- Bootstrapping: An LwM2M Bootstrap Server may set the initial configuration on the LwM2M Client when the client device bootstraps. There may be four different bootstrapping methods: a Factory Bootstrap, a Bootstrap from Smartcard, a Client Initiated Bootstrap and a Server Initiated Bootstrap.

- Client Registration: An LwM2M Client may register to one or more LwM2M Servers when the bootstrapping is completed.

- Device Management and Service Enablement: An LwM2M Server may send management commands to LwM2M Clients to perform several management actions on LwM2M resources of the client. An access control object of the client may determine the set of actions the server may perform.

Information Reporting: As a feature of the CoAP Observe-Notify mechanism [2], LwM2M Clients may initiate the communication to an LwM2M Server and report information in the form of notifications.

A resource in LwM2M may be understood as an item of interest that may be identified by a Uniform Resource Identifier (URI). A resource may often encapsulate a piece of state in a system. A resource may be a simple parameter, a complex data structure, binary data, e.g., an image file, etc... Typical resources in an loT system may be, e.g., a sensor, the current value of a sensor, the location of a device, or the current state of an actuator. LwM2M defines Write-Composite operation in LwM2M TS v1.1 to enable updating a number of different resources across different instances of one or more objects in a single operation. With this command, an LwM2M Server may provide a list of resources, as opposed to a single resource or object ID, to be updated on an LwM2M Client. Similarly, the specification defines a Read-Composite operation to enable reading multiple resources across different objects.

RFC7232 (HTTP/1.1) defines “precondition” header fields for HTTP requests that define what state the operable resource should be in order to apply an HTTP request. The existing methods to configure resources in LwM2M may result in that desired configurations may not be executed, or may be executed at the wrong time, which may result in, for example, security breaches in a communications network, or an inability to make proper use of the devices in a network.

SUMMARY

It is an object of embodiments herein to improve the handling of radio frequency bands by wireless devices in a communications network. It is a particular object of embodiments herein to improve the management of configuration of resources by constrained wireless devices in a communications network.

According to a first aspect of embodiments herein, the object is achieved by a method performed by a first node. The first node operates in a communications network. The first node sends a request to a second node operating in the communications network using a LwM2M internet protocol. The request comprises a configuration for a plurality of resources. The configuration comprises at least one change to be applied to at least one resource of the plurality of resources. The request further comprises one or more conditions to be checked by the second node before applying the configuration.

Only if at least one of the one or more conditions is satisfied, is the second node to apply the configuration. Otherwise, the second node is to reject the configuration. The first node also receives a response from the second node. The response indicates whether the configuration has been applied or rejected.

According to a second aspect of embodiments herein, the object is achieved by a method performed by the second node. The second node operates in the communications network. The second node receives the request from the first node operating in the communications network using the LwM2M internet protocol. The request comprises the configuration for the plurality of resources. The configuration comprises at least one change to be applied to at least one resource of the plurality of resources. The request further comprises the one or more conditions to be checked by the second node before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node to apply the configuration. Otherwise, the second node is to reject the configuration. The second node also sends the response to the first node. The response indicates whether the configuration has been applied or rejected.

According to a third aspect of embodiments herein, the object is achieved by the first node, configured to operate in the communications network. The first node is configured to send the request to the second node configured to operate in the communications network using the LwM2M internet protocol. The request is configured to comprise the configuration for the plurality of resources. The configuration is configured to comprise at least one change to be applied to at least one resource of the plurality of resources. The request is further configured to comprise the one or more conditions to be checked by the second node before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node to apply the configuration. Otherwise, the second node is to reject the configuration. The first node is further configured to receive the response from the second node. The response is further configured to indicate whether the configuration has been applied or rejected.

According to a fourth aspect of embodiments herein, the object is achieved by the second node, configured to operate in the communications network. The second node is configured to receive the request from the first node configured to operate in the communications network using the LwM2M internet protocol. The request is configured to comprise the configuration for the plurality of resources. The configuration comprises at least one change to be applied to at least one resource of the plurality of resources. The request is further configured to comprise the one or more conditions to be checked by the second node before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node to apply the configuration. Otherwise, the second node is to reject the configuration. The second node is further configured to send the response to the first node. The response is configured to indicate whether the configuration has been applied or rejected.

According to a fifth aspect of embodiments herein, the object is achieved by the communications network. The communications network comprises the first node and the second node configured to operate in the communications network. The first node is configured to send the request to the second node configured to operate in the communications network using the LwM2M internet protocol. The request is configured to comprise the configuration for the plurality of resources. The configuration is configured to comprise at least one change to be applied to at least one resource of the plurality of resources. The request is further configured to comprise the one or more conditions to be checked by the second node before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node to apply the configuration. Otherwise, the second node is to reject the configuration. The first node is further configured to receive the response from the second node. The response is further configured to indicate whether the configuration has been applied or rejected. The second node is configured to receive the request from the first node. The second node is further configured to send the response to the first node.

By sending the request in this Action 203, the first node may make an update to resources in the second node, conditional to the one or more conditions, so that negative consequences derived from untimely updates due to delays in the communications network 10 may be prevented. Similarly, overwriting of simultaneously received update requests from the first node and other nodes in the communications network, e.g., the third node, may also be prevented, by making the updates subject to specific conditions.

A remote-controlled smart lock case is an example of when such condition check may be necessary. A smart lock should be opened only when there is the authorized person next to the lock. If the delays in the communications network also delay the open command, an unauthorized person may get access. Moreover, by sending the configuration for the plurality of resources in a single request, and updating the resource or resources in a single operation, less signalling overhead is used. Furthermore, the configuration may be executed as an atomic operation when using the “if-match” field. That is, the configuration may not be split and may not have partial success. This ensures consistency of the given configuration on the second node.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to the accompanying drawings, according to the following description.

Figure 1 is a schematic diagram illustrating two non-limiting examples in a) and b), respectively, of a communications network, according to embodiments herein. Figure 2 is a flowchart depicting embodiments of a method in a first node, according to embodiments herein.

Figure 3 is a flowchart depicting embodiments of a method in a second node, according to embodiments herein.

Figure 4 is a flowchart depicting an example of a method in a communications network according to embodiments herein.

Figure 5 is a flowchart depicting another example of a method in a communications network according to embodiments herein.

Figure 6 is a schematic block diagram illustrating two non-limiting examples, a) and b), of a first node, according to embodiments herein.

Figure 7 is a schematic block diagram illustrating two non-limiting examples, a) and b), of a second node, according to embodiments herein.

Figure 8 is a schematic block diagram illustrating a non-limiting example of a communications network, according to embodiments herein. DETAILED DESCRIPTION

As part of the development of embodiments herein, a number of problems with existing methods will first be identified and discussed.

In the currently specified approach, a Write-Composite operation always performs all write operations as long as the resources exist, and the server is allowed to write to them. This may result in simultaneous updates of a resource, e.g., by multiple servers or the client itself, to be overwritten. A further problem is that delays in network communication may result in performing an operation later, and hence resulting in a change to an old state of a resource, that is, a state that has changed since the operation was sent. One typical use case is a Smart Lock use case, where the lock should be opened only if it has a certain state. For example, the lock should only be opened if a security guard is present. If the LwM2M "open" message to the lock is delayed, e.g., because of a congestion in the network traffic, there is no way to ensure that the lock will be securely opened when the security guard is by the door, and it may be opened once the security guard has left the scene. Another example of a problem that may arise is that some resources may need to be changed only if other resources have a known state. For example, a door dead-bolt should only be enabled when the door is closed. Otherwise, it will not be possible to close the door, as long as the dead-bolt is enabled.

Similarly, for composite read operations, certain values may only be enabled to be read if other resources on the client have expected values. For example, a sensor value should be read only when the sensor is properly activated. Further, to save bandwidth, a client would not need to even send values to the server, that may be already known to the server.

Today, these problems may be mitigated by first reading, or Observing, the current state of the resources, and then immediately performing the update or the new read. However, due to network delays, other operations may intervene with this approach. Furthermore, the approach itself may also increase network consumption, since the information that is likely known by the server already needs to be retrieved before applying operations. There are currently no existing methods to reconfigure Write-Composite requests in LwM2M. Existing methods, as described in https://tools.ietf.Org/html/rfc7232#section-2.3, are drawn to reconfiguration of single resources in so called entity tags. Such methods are not applicable to composite operations. This is due to the fact that the composite operations span across multiple resources and objects. This method would require LwM2M server to know the etag values for each resource before applying the commands. Also, this method would require multiple requests, one for each impacted resource in the Write-Composite request, which may again run into problems of untimely executions due to network delays, as well as mutual overwrites due to simultaneously received requests, hence not solving the existing problems. The existing LwM2M device management protocol currently lacks a mechanism to check and satisfy conditions to perform already existing write- or read- composite operations.

Several embodiments are comprised herein, which address the limitations of the existing methods. As an overview, embodiments herein may be understood to be drawn to providing method to reconfigure a write- and read-composite. In particular, embodiments herein may be understood to relate to a conditional write- and read- composite in LwM2M.

Embodiments herein describe a method to reconfigure a conditional Write- Composite request in LwM2M, which ensures that the state changes in a LwM2M Client are only executed if a given condition in the request is satisfied. Similarly, a new conditional Read-Composite is described that may be enabled to return the values of requested resources if other resources in the request have a known state, or if all the resources have a known state, the client may simply acknowledge that the resource states have not changed.

Embodiments herein introduce a new Sensor Measurements List (SenML) field “if- match”, which will be described in detail later. The value of this field may be populated by using different means depending on what a Server may wish to verify with a Client. The values of this field may be called "tags".

The embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which examples are shown. In this section, embodiments herein are illustrated by exemplary embodiments. It should be noted that these embodiments are not mutually exclusive. Components from one embodiment or example may be tacitly assumed to be present in another embodiment or example and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments.

Figure 1 depicts two non-limiting examples, in panels “a” and “b”, respectively, of a communications network 10, in which embodiments herein may be implemented. In some example implementations, such as that depicted in the non-limiting example of Figure 1a), the communications network 10 may be a computer network, e.g., a wired computer network. In other example implementations, such as that depicted in the non limiting example of Figure 1b), the communications network 10 may be implemented in a telecommunications network 100, sometimes also referred to as a cellular radio system, cellular network or wireless communications system. In some examples, the telecommunications network 100 may comprise network nodes which may serve receiving nodes, such as wireless devices, with serving beams.

The telecommunications network 100 may for example be an loT network, a Narrow-Band loT (NB-loT) network, a Category M1 (CATM) network, a Global System for Mobile communications (GSM) network, or another Internet service provider (ISP)- oriented network.

In some examples, the communications network 10, or the telecommunications network 100 may for example be a network such as 5G system, or Next Gen network.

The telecommunications network 100 may also support other technologies, such as a Long-Term Evolution (LTE) network, e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), LTE operating in an unlicensed band, Wideband Code Division Multiple Access (WCDMA), Universal Terrestrial Radio Access (UTRA) TDD, GSM/Enhanced Data Rate for GSM Evolution (EDGE) Radio Access Network (GERAN) network, Ultra-Mobile Broadband (UMB), EDGE network, network comprising of any combination of Radio Access Technologies (RATs) such as e.g. Multi-Standard Radio (MSR) base stations, multi-RAT base stations etc., any 3rd Generation Partnership Project (3GPP) cellular network, Wireless Local Area Network/s (WLAN) or WiFi network/s, Worldwide Interoperability for Microwave Access (WiMax), IEEE 802.15.4-based low-power short-range networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LowPAN), Zigbee, Z-Wave , Bluetooth Low Energy (BLE), or any cellular network or system.

The communications network 10 comprises a plurality of nodes, whereof a first node 111, a second node 112, and a third node 113 are depicted in Figure 1. Each of the first node 111 , the second node 112 and the third node 113 may be understood as a computer system. Each of the first node 111 , the second node 112 and the third node 113 may be understood to be enabled to operate using a Lightweight Machine to Machine protocol (LWM2M). Any of the first node 111 and the third node 113 may be a network node, such as the network node 120 described below. Any of the first node 111 and the third node 113 may be understood to have a capability to communicate with communication devices being constrained devices. In typical examples, the first node 111 and the third node 113 may be a LWM2M server. In some examples, any of the first node 111 and the third node 113 may support operation on the CoAP and on the DNS protocol. The second node 112 may be a wireless device, such as the wireless device 130 described below, which may be a constrained device. In particular examples, the second node 112 may be a LWM2M client. In some examples, the first node 111 and the third node 113 may the co-localized or be the same node. In typical examples, the first node 111 and the third node 113 may be different nodes. The communications network 10 comprises a plurality of network nodes, whereof a network node 120 is depicted in Figure 1. In some examples, the network node 120 may be implemented, as depicted in the non-limiting example of Figure 1a) and 1b), as a standalone server in e.g., a host computer in the cloud 125. The network node 120 may in some examples be a distributed node or distributed server, with some of its functions being implemented locally, e.g., by a client manager, and some of its functions implemented in the cloud 125, by e.g., a server manager. Yet in other examples, the network node 120 may also be implemented as processing resources in a server farm.

The network node 120 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider.

The communications network 10 comprises a wireless device 130, as depicted in the non-limiting example scenario of Figure 1. The communications network 10 may also comprise other communication devices. The wireless device 130 may be a UE or a Customer Premises Equipment (CPE) which may be understood to be enabled to communicate data, with another entity, such as a server, a laptop, a Machine-to-Machine (M2M) device, device equipped with a wireless interface, or any other radio network unit capable of communicating over a wired or radio link in a communications system such as the communications network 10. In some embodiments, the wireless device 130 may be understood to be a constrained device in e.g., an loT network. In some particular embodiments, the wireless device 130 may be understood to be a constrained device operating on LWM2M. The wireless device 130 may run a client application, which may be enabled to communicate with a host application run by the wireless device 130. The wireless device 130 may support operation on CoAP.

The wireless device 130 may be a wireless device comprised in the communications network 10, such as a Bluetooth Low Energy (BLE) User Equipment (UE). The wireless device 130 may be enabled to communicate wirelessly in the communications network 10 and, in some particular examples, may be able support beamforming transmission. The communication may be performed e.g., via a RAN and possibly one or more core networks, comprised within the communications network 10.

The wireless device 130 may be also e.g., a mobile terminal, wireless terminal and/or mobile station, mobile telephone, cellular telephone, or laptop, just to mention some further examples. The wireless device 130 may be, for example, portable, pocket- storable, hand-held, computer-comprised, a sensor, camera, or a vehicle-mounted mobile device, enabled to communicate voice and/or data, via a RAN, with another entity, such as a server, a laptop, a Personal Digital Assistant (PDA), or a tablet computer, sometimes referred to as a tablet with wireless capability, or simply tablet, a Machine-to-Machine (M2M) device, a device equipped with a wireless interface, such as a printer or a file storage device, modem, Laptop Embedded Equipped (LEE), Laptop Mounted Equipment (LME), USB dongles or any other radio network unit capable of communicating over a wired or radio link in the communications network 10.

The telecommunications network 100 may cover a geographical area which, which in some embodiments may be divided into cell areas, wherein each cell area may be served by a radio network node 140, although, one radio network node may serve one or several cells. In the example of Figure 1b, the radio network node 140 serves a cell 150. The radio network node 140 may be e.g., a gNodeB. That is, a transmission point such as a radio base station, for example an eNodeB, or a Home Node B, a Home eNode B or any other network node capable to serve a wireless device, such as a user equipment or a machine type node in the communications network 10. The radio network node 140 may be of different classes, such as, e.g., macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also cell size. In some examples, the radio network node may serve receiving nodes with serving beams. The radio network node 140 may support one or several communication technologies, and its name may depend on the technology and terminology used. Any of the radio network nodes that may be comprised in the communications network 10 may be directly connected to one or more core networks.

The first node 111 is configured to communicate within the communications network 10 with the second node 112 over a first link 161, e.g., a radio link, an infrared link, or a wired link. The first link 161 may be comprised of a plurality of individual links. The third node 113 is configured to communicate within the communications network 10 with the second node 112 over a second link 162, e.g., a radio link, an infrared link, or a wired link. Any of the first link 161 and the second link 162 may be comprised of a plurality of individual links. The wireless device 130 is configured to communicate within the communications network 10 with the radio network node 140, in the cell 150, over a third link 163, e.g., a radio link, an infrared link, or a wired link. The third link 163 may be comprised of a plurality of individual links.

Any of the first link 161 and the second link 162 may be a direct link or it may go via one or more computer systems or one or more core networks in the communications network 10, which are not depicted in Figure 1, or it may go via an optional intermediate network. The intermediate network may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network, if any, may be a backbone network or the Internet; in particular, the intermediate network may comprise two or more sub-networks, which is not shown in Figure 1. In general, the usage of “first”, “second”, “third”, etc. herein may be understood to be an arbitrary way to denote different elements or entities, and may be understood to not confer a cumulative or chronological character to the nouns they modify.

Embodiments of method performed by the first node 111 will now be described with reference to the flowchart depicted in Figure 2. The method may be understood to be for handling a configuration of resources of the second node 112. The first node 111 operates in the communications network 10. In some embodiments, the communications network 10 may operate on a LwM2M technology. The first node 111 may be, for example, an LwM2M server. The second node 112 may be, for example, an LwM2M client.

Resource, as used herein, may be understood as a LwM2M resource, as described before, or resource of a newer technology of similar functionality. A resource may be, e.g., a part of an object.

The method may comprise the actions described below. Several embodiments are comprised herein. In some embodiments some of the actions may be performed. In some embodiments all the actions may be performed. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example may be tacitly assumed to be present in another example and it will be obvious to a person skilled in the art how those components may be used in the other examples. In Figure 2, optional actions are indicated with dashed boxes.

Action 201

In the course of operations of the communications network 10, the first node 111 may need to update a configuration of one or more resources in the second node 112, for example, turn off some light sources. According to embodiments herein, and as will be described in further detail later, in Action 203, the update may be subject to one or more conditions that may need to be checked by the second node 112 before applying the configuration. The one or more conditions may be indicated by the first node 111 using semantics that may be understood to need to be known by both, the first node 111 and the second node 112, so both of them may use them accordingly. That is, the first node 111 may need to set the one or more conditions for the intended purpose, and the second node 112 may need to be able to correctly read and interpret the one or more conditions. Therefore before setting the one or more conditions, in this Action 201 , the first node 111 may send a first indication to the second node 112. The first indication may indicate how the second node 112 is to determine whether or not the one or more conditions are satisfied upon receiving a request, in other words, how to interpret the one or more conditions. For example, in some examples, the one or more conditions may be based on specific values of the resources, in other examples, the one or more conditions may be based on a timestamp value associated with a certain resource record. In other examples, the one or more conditions may be based on both, a value of the resources, and a value of the timestamp. In other examples, the one or more conditions may be based on an identifier of a node, e.g., a third node 113, that may have made a last change to the resource for which a condition is checked. Yet in other examples, the one or more conditions may be based on a combination of access control rules applicable to the resource, e.g., an Access Control List (ACL) resource, which may be referred to as an “ACL mode”. In yet other examples, the one or more conditions may be based on a time period during which a timestamp may be considered valid.

The sending, e.g., providing, in this Action 201 may be performed, e.g., via the first link 161.

In some embodiments, the one or more conditions may be expressed as one or more values, which may be also referred to as one or more “tags”. According to embodiments herein, the value or values may be generated using hash functions. According to the foregoing, different hash functions may be used according to embodiments herein to generate the value or values. For example, the hash functions may be based on the content of the resource, a timestamp, a combination of both, or based on the additional methods mentioned earlier. A non-limiting illustrative example of the content of the first indication will now be provided.

Example using SenML

LwM2M v1.1 introduced SenML as the preferred data format for transferring LwM2M/IPSO resource information. For example, a Write-Composite request using SenML-JSON format to configure resources associated with a lightning system, where 3311/0, 3311/1 and 3311/2 may be individual light sources and 3308/0 may be a set point for a controller, such as a thermostat, may look as follows on the wire:

[fn 73311/0/5850", "vb false},

{"n":73311/1/5850", "vb":false},

{"n":73311/2/5851", "v":20}, fn 73308/0/5900 ", "v":18}] This payload may be understood to be aimed at switching off two lights: / 3311/0 and /3311/1, while dimming a third light: /3311/2, in the same request, and setting a setpoint resource to value 18. In some embodiments herein, each of the one or more conditions in this Action 201 may be indicated, respectively, as a SenML field. The SenML field, according to embodiments herein, may be a new SenML field, that may be named an “if-match” field. The if-match field may be used, e.g., in an LwM2M request for each SenML record that, according to embodiments herein, may need to be checked before applying the requested resource changes in the payload. Another example of SenML field will be described later, in Action 203.

Following the example of the lightning system provided, an example of the new SenML field may be as follows: [fn":"/3311/0/5850", "vb":false, “if-match": " 42abba "},

{"n":"/3311/1/5850", "vb":false, “if-match": "cd54aa"},

{"n":"/3311/2/5851", "v":20},

{"n ": 73308/0/5900 ", "v":18}] According to embodiments herein, upon receiving this payload, the second node 112 may need to check the values given in at least one of the records which includes an “if-match” field before updating that resource, as will be further explained later. The operation may be rejected by the second node 112, that is, the configuration change may not be executed, if, for example, any of the "if-match" values does not match. The method of how the value of the “if-match” field may have been generated may be understood to need to be known to both the first node 111 and the second node 112. For that purpose, the first node 111 may send the first indication in this Action 201. The first indication may be a LwM2M Object, that is, the information comprised in the LwM2M Object. In particular, the first indication may be, e.g., an LwM2M Server object such as an Object ID 1 , which may comprise three new resources to control how the “if-match” field is to be handled by the second node 112. The LwM2M Server object may be configured by the first node 111. Table 1 shows a non-limiting example of the content of the first indication as a LwM2M Server object, and in particular what the three new resources may be. Each of the resources may be identified by an Resource Identifier (Resource ID) to be determined (TBD), and by a Resource Name, indicated by the second column. Each of the resources may be susceptible to be Read and Written (RW), as indicated by the Operations column, may have only a single instance, as indicated by the Instances column, may be optional, as indicated by the Mandatory column, and may be of a type expressed by an integer value, as indicated by the Type column, which integer value may be one of a range indicated by the Range-Enumeration column. The Description column succinctly indicates the content of each resource. That a resource has a single instance may be understood to indicate that there is only one instance of this kind of resource in this object. This may be understood to be the default for resources. That a resource is optional may be understood to mean that that the support for this resource on the client is optional, that is, that the client does not have to support and implement this resource.

The first resource in Table 1 defines a first method, a “condition method”, which may adopt different forms, listed in the Description column, each form corresponding different methods that may be used to generate the value of the “if-match” field using a hash function may be indicated by the first indication.

When the "resource" method is used, the input to the hash algorithm is the value of the resource, e.g., the value of the SenML "value" field of an SenML record in an Object indicating the reconfiguration of a resource. The resource method may be indicated by a “0” integer value of a series of integer values from 0 to 31, as indicated in Table 1.

When the "timestamp" method is used, the second node 112 may include in all SenML records also a timestamp value. The input to the hash algorithm is the timestamp of the resource after the record may be resolved, see https://tools.ietf.Org/html/rfc8428#section-4.6, section 4.6. The timestamp method may be indicated by a “1” integer value.

In a "timestamp + resource value" method, the timestamp value may be concatenated with a resource value, and hash value may be calculated from both. The timestamp+resource method may be indicated by a “2” integer value.

When the “Short server ID of LwM2M Server” is used, the short server ID of LwM2M Server who may be performing the operation, may be used for calculation of the hash. This option may be understood to enable to check which node in the communications network 10, that is, which third node 113, e.g., which LwM2M Server, may have been the last to update the value of the resource. To achieve this functionality, the hash value may need to be stored on the second node 112. The Short server ID of LwM2M Server method may be indicated by a “3” integer value.

When a combination of access control rules, e.g., an "ACL mode", is used, the first node 111 may include the state, that is, the value, of the Access Control Object's resources, referring to the object instance being modified, to the hash calculation to for this resource. This may be understood to enable the second node 112 to ensure that the access control is what it expects and may enable requests such as "do not do the change if there is a new server that may be able to read the value”. The second node 112 making the request may have some assumption about the current access control rules for the target resource. For example, it may assume that it is the only server that is able to read the values written there. By including the ACL rules in the hash calculation, it may check that this assumption holds. If a new server would have been given access rights to the resource, the ACL rules would be different and hence the hash value would be different. The ACL mode method may be indicated by a “4” integer value.

The rest of the integer values 5-31 may remain reserved.

The Condition Hash Algorithm resource may be used to determine which particular hash algorithm may be used in the calculation. Examples of different hash algorithm choices include "SHA1 truncated to 8 bytes", indicated with value "1" in the example below, and "SHA-256 truncated to 16 bytes", indicated with value "2" in the example. If no suitable hash algorithm is available, it may be possible to use the input values as such in the tags, e.g., "identity (no hash)", indicated with value 0, in the example.

The third, "Timestamp window", resource may be used to give more flexibility for matching the hash while using the "timestamp" method. The "timestamp" may be considered valid with the value in "timestamp window" value, if this resource exists.

Read Composite operation may alternatively use the SenML value field, e.g., "v", "vb", etc, to indicate the expected values for resources. However, using a separate field such as the "if-match" just described may likely be preferable due to simpler parser logic.

According to the foregoing, in some embodiments, the first indication may indicate that the second node 112 is to determine whether or not the one or more conditions are satisfied by calculating one or more functions. The one or more functions may be based on at least one of, for a respective resource for which a condition is checked: a) a value of the resource, b) a timestamp associated with the resource, c) a combination of the value and the timestamp, d) an identifier of a third node (113) that made a last change to the resource, e) a combination of access control rules applicable to the resource, and f) a time period during which the timestamp may be considered valid. Any, or each of, the one or more functions may be, e.g., a hash function.

It may be understood that in some examples, the calculating of the one or more functions may comprise calculating multiple calculations, e.g., one for each tag in the field. In some examples, different condition methods or hash functions may be calculated for each tag.

The first indication may therefore be understood as a configuration of object resources. By sending the first indication in this Action 201 , the first node 111 may enable the second node 112 to know how to later determine whether or not one or more conditions are satisfied. Table 1 Action 202

In this Action 202, the first node 111 may receive a second indication from the second node 112 acknowledging receipt of the first indication.

The receiving, e.g., obtaining, in this Action 202 may be performed, e.g., via the first link 161.

Receipt of the second indication may enable the first node 111 to know that the second node 112 may be enabled to know how to determine whether or not the one or more conditions are satisfied. Action 203

At some point, the first node 111 may then need to make an update to any of the resources in the second node 112, following the example provided earlier, switch off some light sources. In this Action 203, the first node 111 sends a request to the second node 112 operating in the communications network 10 using a LwM2M internet protocol. The request comprises a configuration for a plurality of resources. The configuration comprises at least one change to be applied to at least one resource of the plurality of resources. The request also comprises one or more conditions to be checked by the second node 112 before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node 112 to apply the configuration. Otherwise, the second node 112 is to reject the configuration.

The sending, e.g., providing, in this Action 203 may be performed, e.g., via the first link 161.

In some embodiments, the request may be a Write-Composite request.

In some embodiments herein, each of the one or more conditions in this Action 201 may be indicated in the request, respectively, as an SenML field, such as the “if-match” field described earlier.

According to embodiments herein, upon receiving this payload, the second node 112 may need to check the values given in each of the records which includes an “if- match” field before updating that resource, according to any of the methods explained earlier, as may have been indicated by the first indication. If any of the "if-match" values does not match, the operation may be rejected by the second node 112. That is, the configuration change may not be executed.

According to other embodiments, it may be possible to require only one tag to match in order for the write to be performed. In such embodiments, a new field, “if-one- match" may be used to provide the tag values. According to these embodiments, if any of the tags with “if-one-match" field matches, the composite write is performed. It may be understood that when using the “if-one-match” field, the operation may only be rejected by the second node 112, if none of the one or more conditions is met. One such example may be:

[fn":"/3311/0/5850", "vb": false, “if -one-match”: " 42abba "}, fn":"/3311/1/5850", "vb":false, “if -one-match”: "cd54aa"},

{"n":"/3311/2/5851", "v":20},

{"n ": 73308/0/5900 ", "v":18}]

It may also be understood that different requests may comprise different number of one or more conditions. That is, not all resources configured in a request may be subject to a respective condition, although in some examples, all resources configured in a request may be subject to a respective condition.

In some examples, one condition field may contain multiple tags. The multiple tags may be presented, e.g., as a comma separated list in any of the condition fields. If any of the tags matches, the condition may be considered satisfied.

Further, some examples may use the inverse of the "if-match" fields; which may be called "if-not-match" and "if-not-one-match". These conditions may be considered satisfied if the given tag, or all tags, do not match.

By sending the request in this Action 203, the first node 111 may make an update to resources in the second node 112, conditional to the one or more conditions, so that negative consequences derived untimely updates due delays in the communications network 10 may be prevented. Similarly, overwriting of simultaneously received update requests from the first node 111 and other nodes in the communications network 10, e.g., the third node 113, may also be prevented, by making the updates subject to specific conditions. Moreover, by sending the configuration for the plurality of resources in a single request, and updating the resource or resources in a single operation, less signalling overhead is used. Furthermore, the configuration may be executed as an atomic operation when using the “if-match” field. That is, the configuration may not be split and may not have partial success. This ensures consistency of the given configuration on node 112.

Action 204

Having sent the request to the second node 112, the first node 111, in this Action 204, receives a response from the second node 112. The response indicates whether the configuration has been applied or rejected. Whether the configuration has been applied or rejected by the second node 112 may be understood to be based on whether the one or more conditions indicated in the request have been met or not, as described above.

The receiving, in this Action 204 may be performed over e.g., the first link 161. Embodiments of a method performed by the second node 112, will now be described with reference to the flowchart depicted in Figure 3. The method may be understood to be for handling a configuration of resources of the second node 112. The second node 112 operates in the communications network 10. In some embodiments, the communications network 10 may operate on the LwM2M technology. The second node

112 may be, for example, an LwM2M client. The first node 111 may be, for example, an LwM2M server.

The method may comprise one or more of the following actions. Several embodiments are comprised herein. In some embodiments all the actions may be performed. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example may be tacitly assumed to be present in another example and it will be obvious to a person skilled in the art how those components may be used in the other examples. In Figure 3, optional actions are indicated with dashed boxes.

The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the second node 112, and will thus not be repeated here to simplify the description. For example, the third node

113 may be another LWM2M server.

Action 301

In this Action 301 , the second node 112 receives the first indication from the first node 111. The first indication may indicate how the second node 112 is to determine whether or not the one or more conditions are satisfied upon receiving the request from the first node 111.

The first indication may be the LwM2M Object described earlier. Therefore, in some embodiments, the first indication may indicate that the second node 112 is to determine whether or not the one or more conditions are satisfied by calculating one or more functions. The one or more functions may be based on at least one of, for a respective resource for which a condition may be checked: a) the value of the resource, e.g., when the "resource" method is used, b) the timestamp associated with the resource, e.g., when the "timestamp" method is used, c) the combination of the value and the timestamp, e.g., when the "timestamp + resource value" method is used, d) the identifier of the third node 113 that made the last change to the resource, e.g., when the "Short server ID of LwM2M Server" method is used, e) the combination of access control rules applicable to the resource, e.g., when the "ACL mode" method is used, and f) the time period during which the timestamp may be considered valid, e.g., when the " Timestamp window " resource exists. Any, or each of, the one or more functions may be, e.g., a hash function.

The receiving in this Action 301 may be performed, e.g., via the first link 161.

Action 302

In some embodiments, the second node 112 may, in this Action 302, send, the second indication to the first node 111 acknowledging receipt of the first indication.

The sending in this Action 302 may be performed, e.g., via the first link 161.

Action 303

The second node 112, in this Action 303, receives the request from the first node 111 operating in the communications network 10 using the LwM2M internet protocol. The request comprises the configuration for the plurality of resources. The configuration comprises at least one change to be applied to at least one resource of the plurality of resources. The request also comprises the one or more conditions to be checked by the second node 112 before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node 112 to apply the configuration.

Otherwise, the second node 112 is to reject the configuration.

The receiving, e.g., obtaining, in this Action 303 may be performed over e.g., the first link 161.

In some embodiments, the request may be a Write-Composite request.

In some embodiments herein, each of the one or more conditions in this Action 201 may be indicated in the request, respectively, as an SenML field, such as the “if-match” field, and/or the “if-one-match" field described earlier.

Action 304

In this Action 304, the second node 112 may determine whether or not the one or more conditions are satisfied. The determining in this Action 304 may be based on the received first indication. That is, the determining in this Action 304 may be based on the condition method that may have been indicated in the first indication, and whether or not the "Timestamp window" resource exists.

Furthermore, the determining in this Action 304 may be further based on whether the SenML field is the “if-match” field, or whether it is an “if-one-match" field. If the “if- match” field is used, and if any of the "if-match" values does not match, the operation may be rejected by the second node 112. If the “if-one-match” is used, the operation may only be rejected by the second node 112, if none of the one or more conditions is met. If any of the tags with “if-one-match" field matches, the composite write is performed.

Determining may be understood as e.g., calculating. Action 305

In this Action 305, the second node 112 sends the response to the first node 111. The response may indicate whether the configuration has been applied or rejected. The response sent in this Action 305 may be understood to be based on a result of the determining performed on Action 304.

The sending, e.g., providing, in this Action 305 may be performed over e.g., the first link 161.

Figure 4 is a schematic diagram illustrating a non-limiting example of the methods that may be performed by the first node 111, which is an LwM2M Server, and the second node 112, which is an LwM2M Client in the non-limiting example of Figure 4. At 201, the first node 111 sends the first indication to the second node 112, configuring LwM2M Server Object resources. The request is received by the second node 112 in according to Action 301, and, in agreement with Action 302, the second node 112 sends back the second indication acknowledging receipt of the first indication with an “OK”. At 203, the first node 111 sends the request to the second node 112, which is an LwM2M Composite- Write payload with an “if-match” for the desired resources. The second node 112 receives the request in agreement with Action 303. At 304, the second node 112 determines whether or not the one or more conditions are satisfied by validating the value of the “if-match” tag or tags in the first indication. The validation is a success because none of the “if-match” tags have not matched. The second node 112 therefore sends, in agreement with Action 305, the response indicating that the configuration has been applied, that is changed according to the received request. The response is received by the first node 111 in agreement with Action 204.

Figure 5 is a schematic diagram illustrating another non-limiting example of the methods that may be performed by the first node 111, which is an LwM2M Server, and the second node 112, which is an LwM2M Client in the non-limiting example of Figure 5. The description of 201-303 is the same as that for Figure 4. At 304, the second node 112 determines whether or not the one or more conditions are satisfied by validating the value of the “if-match” tag or tags in the first indication. However this time, because of a lossy network, the communications network 10 is experiencing delays in the communications. The validation fails because the “if-match” tags were based on the “Timestamp” method, and the timestamp check has resulted in that the required timestamp has passed, and the condition is not matched. The second node 112 therefore sends, in agreement with Action 305, the response indicating that the configuration indicated in the received request has been rejected, that is, not applied. The response is received by the first node 111 in agreement with Action 204.

As a general summarized overview of the foregoing, embodiments herein may be understood to aim at preventing use cases where overriding a resource or delays in updating a resource may cause serious physical world problems. Embodiments herein may be understood to address this problem by introducing an “if-match” tag to LwM2M for conditional resource updates. The proposed embodiments provide for a way to verify that the resource to be updated is updated to the exact value at the correct time.

One advantage of embodiments herein is that they enable to prevent simultaneous updates of a resource, such that each is overwritten by other requests. Another advantage of embodiments herein is that they ensure that resource values may be read if the state of the rest of the system is as expected. A further advantage of embodiments herein is that they enable optimizing composite-reads of values that have not changed by enabling a server to request a client to send the values only if they are something different than what the server is aware of. Yet another advantage of embodiments herein is that they enable to prevent physical security risks which may occur by wrong/delayed update of a LwM2M resource due to e.g., network delays.

Figure 6 depicts two different examples in panels a) and b), respectively, of the arrangement that the first node 111 may comprise to perform the method actions described above in relation to Figure 2. The first node 111 is configured to operate in the communications network 10.

The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the first node 111, and will thus not be repeated here. For example, the wireless communications network 10 may be configured to operate on the LwM2M technology.

The first node 111 is configured to, e.g. by means of a sending unit 601 within the first node 111 configured to, send the request to the second node 112 configured to operate in the communications network 10 using the LwM2M internet protocol. The request is configured to comprise the configuration for the plurality of resources. The configuration is configured to comprise at least one change to be applied to at least one resource of the plurality of resources. The request is configured to comprise the one or more conditions to be checked by the second node 112 before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node 112 to apply the configuration. Otherwise, the second node 112 is to reject the configuration. In some embodiments, each of the one or more conditions may be configured to be indicated in the request, respectively, as an SenML field.

The first node 111 is also configured to, e.g. by means of a receiving unit 602 within the first node 111 configured to, receive the response from the second node 112. The response is further configured to indicate whether the configuration has been applied or rejected.

In some embodiments, the first node 111 may be further configured to, e.g. by means of the sending unit 601 within the first node 111 configured to, send the first indication to the second node 112. The first indication may be further configured to indicate how the second node 112 is to determine whether or not the one or more conditions are satisfied upon receiving a request, such as the request configured to be received.

In some embodiments, the first node 111 may be further configured to, e.g. by means of the receiving unit 602 within the first node 111 configured to, receive the second indication from the second node 112 acknowledging receipt of the first indication.

In some embodiments, the first indication may be configured to indicate that the second node 112 is to determine whether or not the one or more conditions are satisfied by calculating the one or more functions. The calculating of the one or more functions may be configured to be based on at least one of, for a respective resource for which a condition is configured to be checked: a) the value of the resource, b) the timestamp associated with the resource, c) the combination of the value and the timestamp, d) the identifier of the third node 113 that made the last change to the resource, e) the combination of access control rules applicable to the resource, and f) the time period during which the timestamp may be configured to be considered valid.

In some embodiments, the request may be configured to be a Write-Composite request.

In some embodiments, the first indication may be configured to be a LwM2M Object.

The embodiments herein may be implemented through one or more processors, such as a processor 603 in the first node 111 depicted in Figure 6, together with computer program code for performing the functions and actions of the embodiments herein. The processor 603 may be understood herein to be a hardware component. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the in the first node 111. One such carrier may be the cloud 125. 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 server and downloaded to the first node 111. The first node 111 may further comprise a memory 604 comprising one or more memory units. The memory 604 is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the first node 111.

In some embodiments, the first node 111 may receive information from, e.g., the second node 112 and/or the third node 113, through a receiving port 605. In some examples, the receiving port 605 may be, for example, connected to one or more antennas in the first node 111. In other embodiments, the first node 111 may receive information from another structure in the communications network 10 through the receiving port 605. Since the receiving port 605 may be in communication with the processor 603, the receiving port 605 may then send the received information to the processor 603. The receiving port 605 may also be configured to receive other information.

The processor 603 in the first node 111 may be further configured to transmit or send information to e.g., the second node 112 and/or the third node 113, through a sending port 606, which may be in communication with the processor 603, and the memory 604.

Any of the sending unit 601 and the receiving unit 602 may be the processor 603 of the first node 111, or an application running on such processor.

Those skilled in the art will also appreciate that the sending unit 601 and the receiving unit 602 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor 603, perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

Thus, the methods according to the embodiments described herein for the first node 111 may be respectively implemented by means of a computer program 607 product, comprising instructions, i.e. , software code portions, which, when executed on at least one processor 603, cause the at least one processor 603 to carry out the actions described herein, as performed by the first node 111. The computer program 607 product may be stored on a computer-readable storage medium 608. The computer-readable storage medium 608, having stored thereon the computer program 607, may comprise instructions which, when executed on at least one processor 603, cause the, at least, one processor 603 to carry out the actions described herein, as performed by the first node 111. In some embodiments, the computer-readable storage medium 608 may be a non- transitory computer-readable storage medium, such as a memory stick, or stored in the cloud space. In other embodiments, the computer program 607 product may be stored on a carrier containing the computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium 608, as described above.

The first node 111 may comprise an interface unit to facilitate communications between the first node 111 and other nodes or devices, e.g., the second node 112 and/or the third node 113. In some particular examples, the interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

In other embodiments, the first node 111 may comprise the following arrangement depicted in Figure 6b. The first node 111 may comprise a processing circuitry 603, e.g., one or more processors such as the processor 603, in the first node 111 and the memory 604. The first node 111 may also comprise a radio circuitry 609, which may comprise e.g., the receiving port 605 and the sending port 606. The processing circuitry 603 may be configured to, or operable to, perform the method actions according to Figure 2 and/or Figures 4-5, in a similar manner as that described in relation to Figure 6a. The radio circuitry 609 may be configured to set up and maintain at least a wireless connection with the wireless device 130. Circuitry may be understood herein as a hardware component.

Hence, embodiments herein also relate to the first node 111 operative to operate in the communications network 10. The first node 111 may comprise the processing circuitry 603 and the memory 604, said memory 604 containing instructions executable by said processing circuitry 603, whereby the first node 111 is further operative to perform the actions described herein in relation to the first node 111, e.g., in Figure 2 and/or Figures 4-5.

Figure 7 depicts two different examples in panels a) and b), respectively, of the arrangement that the second node 112 may comprise to perform the method actions described above in relation to Figure 3. The second node 112 is configured to operate in the communications network 10.

The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the second node 112, and will thus not be repeated here. For example, the wireless communications network 10 may be configured to operate on the LwM2M technology. In some embodiments, the second node 112 may comprise the following arrangement depicted in Figure 7a.

The second node 112 is configured to, e.g. by means of a receiving unit 701 within the second node 112 configured to, receive the request from the first node 111 configured to operate in the communications network 10 using the LwM2M internet protocol. The request may be configured to comprise the configuration for the plurality of resources.

The configuration comprises at least one change to be applied to at least one resource of the plurality of resources. The request is further configured to comprise the one or more conditions to be checked by the second node 112 before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node 112 to apply the configuration. Otherwise, the second node 112 is to reject the configuration.

The second node 112 is also configured to, e.g. by means of a sending unit 702 within the second node 112 configured to, send the response to the first node 111. The response is configured to indicate whether the configuration has been applied or rejected.

In some embodiments, each of the one or more conditions may be configured to be indicated in the request, respectively, as an SenML field.

In some embodiments, the second node 112 may be further configured to, e.g. by means of the receiving unit 701 within the second node 112 configured to, receive the first indication from the first node 111. The first indication may be configured to indicate how the second node 112 is to determine whether or not the one or more conditions are satisfied upon receiving a request.

In some embodiments, the second node 112 may be further configured to, e.g. by means of the sending unit 702 within the second node 112 configured to, send the second indication to the first node 111 acknowledging receipt of the first indication.

In some embodiments, the first indication may be configured to indicate that the second node 112 is to determine whether or not the one or more conditions are satisfied by calculating the one or more functions. The calculating of the one or more functions may be configured to be based on at least one of, for a respective resource for which a condition is configured to be checked: a) the value of the resource, b) the timestamp associated with the resource, c) the combination of the value and the timestamp, d) the identifier of the third node 113 that made the last change to the resource, e) the combination of access control rules applicable to the resource, and f) the time period during which the timestamp may be configured to be considered valid.

The second node 112 may be also configured to, e.g. by means of a determining unit 703 within the second node 112 configured to, determine whether or not the one or more conditions are satisfied. The determining may be configured to be based on the first indication configured to be received. In some embodiments, the request may be configured to be a Write-Composite request.

In some embodiments, the first indication may be configured to be a LwM2M Object.

The embodiments herein may be implemented through one or more processors, such as a processor 704 in the second node 112 depicted in Figure 7a, together with computer program code for performing the functions and actions of the embodiments herein. The processor 704 may be understood herein to be a hardware component. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the in the second node 112. 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 server and downloaded to the second node 112.

The second node 112 may further comprise a memory 705 comprising one or more memory units. The memory 705 is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the second node 112.

In some embodiments, the second node 112 may receive information from, e.g., the first node 111 and/or the third node 113, through a receiving port 706. In some examples, the receiving port 706 may be, for example, connected to one or more antennas in second node 112. In other embodiments, the second node 112 may receive information from another structure in the communications network 10 through the receiving port 706. Since the receiving port 706 may be in communication with the processor 704, the receiving port 706 may then send the received information to the processor 704. The receiving port 706 may also be configured to receive other information.

The processor 704 in the second node 112 may be further configured to transmit or send information to e.g., the first node 111 and/or the third node 113, through a sending port 707, which may be in communication with the processor 704, and the memory 705.

Any of the receiving unit 701 , the sending unit 702 and the determining unit 703 may be the processor 704 of the second node 112, or an application running on such processor.

Those skilled in the art will also appreciate that the receiving unit 701, the sending unit 702 and the determining unit 703 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor 704, perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application- Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

Thus, the methods according to the embodiments described herein for the second node 112 may be respectively implemented by means of a computer program 708 product, comprising instructions, i.e. , software code portions, which, when executed on at least one processor 704, cause the at least one processor 704 to carry out the actions described herein, as performed by the second node 112. The computer program 708 product may be stored on a computer-readable storage medium 709. The computer- readable storage medium 709, having stored thereon the computer program 708, may comprise instructions which, when executed on at least one processor 704, cause the at least one processor 704 to carry out the actions described herein, as performed by the second node 112. In some embodiments, the computer-readable storage medium 709 may be a non-transitory computer-readable storage medium, such as memory stick, or stored in the cloud space. In other embodiments, the computer program 708 product may be stored on a carrier containing the computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium 709, as described above.

The second node 112 may comprise an interface unit to facilitate communications between the second node 112 and other nodes or devices, e.g., the first node 111 and/or the third node 113. In some particular examples, the interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

In other embodiments, the second node 112 may comprise the following arrangement depicted in Figure 7b. The second node 112 may comprise a processing circuitry 704, e.g., one or more processors such as the processor 704, in the second node 112 and the memory 705. The second node 112 may also comprise a radio circuitry 710, which may comprise e.g., the receiving port 706 and the sending port 707. The processing circuitry 704 may be configured to, or operable to, perform the method actions according to Figure 3 and/or Figures 4-5, in a similar manner as that described in relation to Figure 7a. The radio circuitry 710 may be configured to set up and maintain at least a wireless connection with the the first node 111 and/or the third node 113. Circuitry may be understood herein as a hardware component.

Hence, embodiments herein also relate to the second node 112 operative to operate in the communications network 10. The second node 112 may comprise the processing circuitry 704 and the memory 705, said memory 705 containing instructions executable by said processing circuitry 704, whereby the second node 112 is further operative to perform the actions described herein in relation to the second node 112, e.g., in Figure 3 and/or Figures 4-5.

Figure 8 depicts an example of the arrangement that the communications network 10 may comprise. The communications network 10 comprises the first node 111 and the second node 112 configured to operate in the communications network 10.

The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the first node 111, and will thus not be repeated here. For example, the wireless communications network 10 may be configured to operate on the LwM2M technology.

The first node 111 is configured to, e.g. by means of a sending unit 601 within the first node 111 configured to, send the request to the second node 112 configured to operate in the communications network 10 using the LwM2M internet protocol. The request is configured to comprise the configuration for the plurality of resources. The configuration is configured to comprise at least one change to be applied to at least one resource of the plurality of resources. The request is configured to comprise the one or more conditions to be checked by the second node 112 before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node 112 to apply the configuration. Otherwise, the second node 112 is to reject the configuration.

The first node 111 is also configured to, e.g. by means of a receiving unit 602 within the first node 111 configured to, receive the response from the second node 112. The response is further configured to indicate whether the configuration has been applied or rejected.

The second node 112 is configured to, e.g. by means of a receiving unit 701 within the second node 112 configured to, receive the request from the first node 111 configured to operate in the communications network 10 using the LwM2M internet protocol. The request may be configured to comprise the configuration for the plurality of resources.

The configuration comprises at least one change to be applied to at least one resource of the plurality of resources. The request is further configured to comprise the one or more conditions to be checked by the second node 112 before applying the configuration. Only if at least one of the one or more conditions is satisfied, is the second node 112 to apply the configuration. Otherwise, the second node 112 is to reject the configuration.

The second node 112 is also configured to, e.g. by means of a sending unit 702 within the second node 112 configured to, send the response to the first node 111. The response is configured to indicate whether the configuration has been applied or rejected. In some embodiments, the first node 111 may be further configured to, e.g. by means of the sending unit 601 within the first node 111 configured to, send the first indication to the second node 112. The first indication may be further configured to indicate how the second node 112 is to determine whether or not the one or more conditions are satisfied upon receiving a request, such as the request configured to be received.

In some embodiments, the first node 111 may be further configured to, e.g. by means of the receiving unit 602 within the first node 111 configured to, receive the second indication from the second node 112 acknowledging receipt of the first indication.

In some embodiments, the second node 112 may be further configured to, e.g. by means of the receiving unit 701 within the second node 112 configured to, receive the first indication from the first node 111. The first indication may be configured to indicate how the second node 112 is to determine whether or not the one or more conditions are satisfied upon receiving a request.

In some embodiments, the second node 112 may be further configured to, e.g. by means of the sending unit 702 within the second node 112 configured to, send the second indication to the first node 111 acknowledging receipt of the first indication.

The second node 112 may be also configured to, e.g. by means of a determining unit 703 within the second node 112 configured to, determine whether or not the one or more conditions are satisfied. The determining may be configured to be based on the first indication configured to be received.

In some embodiments, each of the one or more conditions may be configured to be indicated in the request, respectively, as an SenML field.

In some embodiments, the first indication may be configured to indicate that the second node 112 is to determine whether or not the one or more conditions are satisfied by calculating the one or more functions. The calculating of the one or more functions may be configured to be based on at least one of, for a respective resource for which a condition is configured to be checked: a) the value of the resource, b) the timestamp associated with the resource, c) the combination of the value and the timestamp, d) the identifier of the third node 113 that made the last change to the resource, e) the combination of access control rules applicable to the resource, and f) the time period during which the timestamp may be configured to be considered valid.

In some embodiments, the request may be configured to be a Write-Composite request.

In some embodiments, the first indication may be configured to be a LwM2M Object. When using the word "comprise" or “comprising”, it shall be interpreted as non limiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.

Therefore, the above embodiments should not be taken as limiting the scope of the invention.

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.

As used herein, the expression “at least one of:” followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the “and” term, may be understood to mean that only one of the list of alternatives may apply, more than one of the list of alternatives may apply or all of the list of alternatives may apply. This expression may be understood to be equivalent to the expression “at least one of:” followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the “or” term.

Any of the terms processor and circuitry may be understood herein as a hardware component.

As used herein, the expression “in some embodiments” has been used to indicate that the features of the embodiment described may be combined with any other embodiment or example disclosed herein.

As used herein, the expression “in some examples” has been used to indicate that the features of the example described may be combined with any other embodiment or example disclosed herein.