WO2019238226A1 - Gateway policies for internet of things control and data traffic - Google Patents

Abstract

Methods of operating a gateway node in a data communication network are provided. The gateway node receives a command message from an internet of things (IoT) controller, analyzes the command message to determine if a command management policy applies to the command message, and applies the command management policy to the command message. The gateway node may receive a sensor data message from an IoT device, determine, based on the sensor data message, whether a sensor data management policy applies to the sensor data message, and apply the sensor data management policy to the sensor data message.

Description

GATEWAY POLICI ES FOR INTERNET OF THI NGS CONTROL AND DATA TRAFFIC

TECHN ICAL FI ELD

[0001] The present disclosure generally relates to the field of communications, and more particularly, to methods and nodes providing wireless network communications with I nternet of Things devices.

BACKGROUN D

[0002] The Internet of Things (loT) is the network of physical objects or "things" embedded with electronics, software, sensors, and connectivity that enable objects to exchange data with the manufacturer, operator and/or other connected devices. The I nternet of Things allows objects, referred to herein as "loT devices," to be accessed and controlled remotely across existing network infrastructure creating opportunities for more direct integration between the physical world and computer-based systems, and resulting in improved efficiency, accuracy and economic benefit. An loT device may be any computing device that com municates autonomously with other devices over a communication network using loT protocols. Typically, an loT device is a wireless communication device that can access a packet data communication network, such as the I nternet, via a radio access network, such as Long Term Evolution, LTE, radio access network. Each loT device is uniquely identifiable through its embedded com puting system but is able to interoperate within the existing I nternet infrastructure.

[0003] One common application of loT technology is in remote sensor devices, which may connect to a packet data communication network through a wireless radio access network (RAN). Remote sensor devices may collect and transmit sensor data, such as temperature data, to an loT controller, which is typically a server device that is located remote from the sensors. Referring to Figures 1 and 2, a conventional configuration of an loT controller 30, a gateway 20 and a plurality of loT devices 10 is illustrated. An loT controller is a device that sends com mands to one or more loT devices over a communication network. For example, an loT controller may transmit one or more commands to an loT device instructing the loT device to wake up, take a measurement, and transmit the resulting data to the loT controller. The loT controller 30 may transmit commands to the loT devices 10 through the gateway 20. The gateway 20 may, for example, be a core network (CN) node in a wireless RAN 25 that serves the loT devices 10, and may maintain packet data contexts for the loT devices 10. The gateway 20 receives a command from the loT controller 30 through a packet data network (PDN) 15, resolves the address of the loT device 10 to which the command is addressed, and forwards the command to the loT device 10.

[0004] Sensor data transmitted by the loT device 10 is handled in a similar manner.

Namely, the gateway 20 receives the sensor data from the loT device 10 via the RAN 25 and forwards the sensor data to the loT controller 30 via the PDN 15.

SUMMARY

[0005] A method of operating a gateway node in a data communication network includes receiving a command message from an internet of things, loT, controller, wherein the command message is addressed to an loT device registered with the gateway node and includes a command for the loT device; determining based on the command message to determine whether a command management policy applies to the command message; and applying the command management policy to the command message.

[0006] A method of operating a gateway node in a data communication network includes receiving a sensor data message from an internet of things, loT, device, wherein the sensor data message is addressed to an loT controller; determining based on the sensor data message to determine whether a sensor data management policy applies to the sensor data message; and applying the sensor data management policy to the sensor data message.

[0007] A method of operating an loT controller according to some embodiments includes transmitting a command management policy to a gateway node in a data

communication network, wherein the gateway node is configured to receive command messages from the loT controller and forward the command messages to loT devices that are managed by the gateway node, wherein the command management policy defines policies for handling command messages transmitted by the loT controller. The method further includes transmitting a command message to the gateway node, wherein the command message is addressed to an loT device managed by the gateway node and wherein the command message contains a command that is subject to the command management policy.

[0008] A method of operating an loT controller according to some embodiments includes transmitting a sensor data management policy to a gateway node in a data

communication network, wherein the gateway node is configured to receive sensor data messages from loT devices and forward the sensor data messages to loT controller, wherein the sensor data management policy defines policies for handling sensor data messages transmitted by the loT devices to the loT controller. The loT controller then receives a sensor data message from the gateway node in accordance with the sensor data management policy.

[0009] A method of operating a gateway node in a data communication network according to some embodiments includes establishing a packet data connection with a second node, receiving a first message from the second node over the first packet data connection, wherein the first message is addressed to the gateway node and comprises a second message for a third node, determining, based on the received message, whether a management policy applies to the second message, and applying the management policy to the second message.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a block diagram that illustrates a conventional arrangement of an

Internet of Things (loT) controller, a gateway node and an loT device.

[0011] Figure 2 is a flow diagram that illustrates conventional data flows between an loT controller, a gateway node and an loT device.

[0012] Figure 3A is a flow diagram that illustrates data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0013] Figure 3B is a flowchart illustrating operations of a gateway node configured according to some embodiments of the inventive concepts.

[0014] Figure 3C is a flowchart illustrating operations of an loT controller configured according to some embodiments of the inventive concepts. [0015] Figures 4A, 4B and 4C are flow diagrams that illustrate data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0016] Figures 5 and 6 are flow diagrams that illustrate data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0017] Figure 7A is a flow diagram that illustrates data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0018] Figure 7B is a flowchart illustrating operations of a gateway node configured according to some embodiments of the inventive concepts.

[0019] Figure 7C is a flowchart illustrating operations of an loT controller configured according to some embodiments of the inventive concepts.

[0020] Figures 8A and 8B are flow diagrams that illustrate data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0021] Figure 8C is a flowchart illustrating operations of a gateway node configured according to some embodiments of the inventive concepts.

[0022] Figure 9A is a flow diagram that illustrates data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0023] Figure 9B is a flowchart illustrating operations of a gateway node configured according to some embodiments of the inventive concepts.

[0024] Figures 10A and 10B are flow diagrams that illustrate data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0025] Figure 11A is a flow diagram that illustrates data flows between an loT controller, a gateway node and an loT device according to some embodiments of the inventive concepts.

[0026] Figure 11B is a block diagram illustrating a sensor data message according to some embodiments of the inventive concepts. [0027] Figure 11C is a block diagram illustrating a command message according to some embodiments of the inventive concepts.

[0028] Figure 12A is a block diagram illustrating a gateway node according to some embodiments of the inventive concepts.

[0029] Figure 12B is a block diagram illustrating functional modules in a memory of a gateway node according to some embodiments of the inventive concepts.

[0030] Figure 13A is a block diagram illustrating an loT device according to some embodiments of the inventive concepts.

[0031] Figure 13B is a block diagram illustrating functional modules in a memory of an loT device according to some embodiments of the inventive concepts.

[0032] Figure 14A is a block diagram illustrating an loT controller according to some embodiments of the inventive concepts.

[0033] Figure 14B is a block diagram illustrating functional modules in a memory of an loT controller according to some embodiments of the inventive concepts.

DETAILED DESCRIPTION OF EMBODIMENTS

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

[0035] As noted above, loT devices 10, such as sensors, may communicate with their corresponding loT controller through a gateway 20. Some embodiments are described herein in the context of loT devices 10 that act as remote sensors that collect and transmit sensor data to an loT controller 30. Accordingly, the terms "loT device," "sensor," "sensor device" and "loT sensor device" are used interchangeably in this description for convenience and ease of understanding. It will be appreciated, however, that embodiments described herein may be applied to systems including loT devices 10 other than sensor devices, and that the

embodiments described herein are not limited to loT sensor devices, but could be employed in connection with other types of loT devices 10. In addition, some loT devices 10 may include multiple sensors (e.g., temperature, humidity, ambient light, etc.) loT devices 10 may send measurement data (e.g., temperature, humidity, moisture, wind speed data, etc., to the gateway 20 and the gateway 20 relays the data to an loT controller 30 that requested the data. In the opposite direction, the loT controller 30 may send commands to the gateway 20, which the gateway 20 relays to the loT devices 10.

[0036] However, having a gateway 20 relay all measurements and commands right away may not be optimal in certain scenarios. For example, where an loT device 10 is used for collecting temperature information about, for example, an article of machinery, an loT controller 30 that is interested in detecting overheating of the machinery may not want to receive reports of temperatures in a normal range, but may only want to receive data indicating temperature measurements over a certain threshold.

[0037] Some of the commands sent by an loT controller 30 may not be time critical.

That is, the commands may not need to be executed right away. Instead, the commands can be executed at a later point in time (possibly within defined time limits). Forwarding all commands to an loT device 10 immediately may make the loT device 10 wake up from sleep mode unnecessarily to receive every command, which may increase power usage by the loT device 10. This approach may also incur unnecessary overhead costs, since multiple data packets, with header information for each, must be sent instead of batching multiple commands in a single data packet.

[0038] Gateways 20 are typically deployed in relatively close proximity (e.g. physically and/or within a short Round-trip Time (RTT)) to loT devices 10 compared to the loT controller 30, which is often deployed in a cloud data center. If an loT device 10 needs to wait for acknowledgement of receipt of each message to the loT controller 30, it may need to stay awake for extended periods of time, further increasing power requirements. [0039] Embodiments of the inventive concepts provide policies that manage traffic patterns between an loT controller 30 and a gateway 20, and between a gateway 20 and one or more loT devices 10 (e.g., loT devices 10 that provide sensor data). According to some embodiments, an loT controller 30 may install policies in the gateway 20 that define how the gateway 20 handles data messages transmitted by the loT devices 10 to the loT controller 30 and commands and other messages transmitted by the loT controller 30 to the loT devices 10.

[0040] According to some embodiments, an loT controller 30 can use a control protocol to install a policy at the gateway 20 that instructs the gateway 20 as to how to handle data transmitted by loT devices 10, such as the types of notifications the loT controller 30 wants to receive. The loT controller 30 can install a policy in the gateway 20 that causes the gateway 20 to acknowledge and buffer or simply discard some notifications from an loT device 10 (e.g., temperatures that are within the normal range), while forwarding other notifications from the loT device 10.

[0041] When an loT device 10 with sensors sends important information, a reliable method of transporting the information may be used, such as a confirmable Constrained Application Protocol, CoAP CON, message. When a CoAP CON message is sent by the loT device 10, the loT device 10 waits for an acknowledgement of the reception of the message and re transmits the message if there is no acknowledgement before the request times out.

Therefore, the device 10 needs to be awake until an acknowledgement is received.

Furthermore, an loT controller 30 may want to send commands back to the device 10 if the sensor information indicates need for that (e.g., "close heating valve" if temperature is too high), so, in some cases, an loT device 10 should not return to sleep mode until some later time.

[0042] To allow the loT device 10 to sleep as much as possible, the loT controller 30 can install a policy on the gateway 20 that defines 1) what kind of information reports can be acknowledged and dropped by the gateway 20 immediately without being forwarded to the loT controller 30, 2) which reports should be sent to the loT controller 30 without the gateway 20 acknowledging them to the loT device 10, and/or 3) which reports the gateway 20 can acknowledge but should be still forwarded to the loT controller 30. An example of a type 1 report (acknowledge and drop) is where the reported values are within a defined range and there is no need to use bandwidth from the gateway 20 to the loT controller 30 to report them. Type 2 reports (forward without acknowledgement) can be critical information where the loT device 10 should not be allowed to return to sleep mode because the loT controller 30 may need to send commands back to the loT device 10. Type 3 reports (acknowledge and forward) can be, for example, used for small deviations from an expected value or range.

[0043] Brief reference is made to Figure 11B which illustrates an example of a sensor data message 200A that may be provided by the loT device 10. The sensor data message 200A may include a header 202 containing control and/or addressing information and a message body 210 containing the actual message. The message body 210 may be encrypted by the loT device 10 and thus may not be readable by the gateway 20 in some embodiments. In other embodiments, message body 210 may not be encrypted and thus may be readable by the gateway 20. The sensor data message 200A may further include a message type 206 that is not encrypted and that describes the type of message being transmitted.

[0044] A message digest 204 that contains a hash of the message body 210 and the message type 206 may also be included to ensure integrity of the message. A hash is the output of a one-way mathematical function ("hashing function") that converts ("hashes") an arbitrary length binary input string to a fixed length output string in a manner such that the original binary input string cannot practicably be recovered from the output string. If any change is made to the binary input string, the hash of the modified string will, with extremely high probability, not match the original hash, allowing the change to be detected. The generation of message digests is well known in the art and need not be described further herein.

[0045] Table 1 illustrates an example of a sensor data management policy that enables handling of various message types and resulting actions. The sensor data management policy shown in Table 1 is provided as a simplified example for illustrative purposes.

Table 1 - Example Sensor Data Management Policy

[0046] As shown in Table 1, if a message type indicates that the message is a normal status message ("Status - normal"), the gateway 20 may discard the message without immediate acknowledgement. If the message type indicates that it is an alert status ("Status - alert") or that it contains sensor data with a large deviation from a predetermined range ("Sensor data - large deviation"), the gateway 20 may forward the message to the loT controller 30 without immediate acknowledgement. If the message type indicates that it contains sensor data with a small deviation from the predetermined range ("Sensor data - small deviation"), the gateway 20 may forward the message to the loT controller 30 and send an immediate acknowledgement to the loT device 10. If the message type indicates that it contains sensor data within the predetermined range ("Sensor data - in range"), the gateway 20 may discard the message and send an immediate acknowledgement to the loT device 10.

[0047] In some embodiments, the sensor data may be carried in an extensible markup language, XML, file that is readable by the gateway 20, and the configuration message 112 from the loT controller 30 may provide the gateway 20 with instructions for parsing the XML file containing the sensor data to determine, for example, whether the sensor data is inside or outside a predetermined range. The gateway 20 may then apply the sensor data management policy based on the parsed sensor data.

[0048] Operations according to some embodiments are illustrated in Figures 3A and 3B.

Figure 3A is a message flow diagram illustrating the flow of messages between an loT controller 30, a gateway 20 and an loT device 10 according to some embodiments. Figure 3B is a flowchart of operations of a gateway 20 according to some embodiments. [0049] Referring to Figures 3A and 3B, an loT controller 30 may configure a gateway 20 with a sensor data management policy that defines how the gateway 20 should handle data messages received from the loT device 10 via a message 112 from the loT controller 30 to the gateway 20. In particular, the sensor data management policy may define whether sensor data messages should be forwarded, acknowledged, and/or dropped based on the type and/or content of the sensor data message. The gateway 20 receives and stores the sensor data management policy for later reference.

[0050] The gateway 20 then receives a sensor data message 116 (block 312) from the loT device 10 and determines based on the sensor data message block 118, 314 whether the sensor data management policy applies to the data message. The sensor data message 116 may in some embodiments be addressed to the loT controller 30 (e.g., may be carried in one or more data packets that specify a destination IP address corresponding to the loT controller 30). In other embodiments, the sensor data message may be carried in a container message that is addressed to the gateway 20, and the gateway 20 may be configured to receive the sensor data message and route it to the appropriate loT controller 30. If the policy applies to the data message, the gateway 20 then applies the policy to the sensor data message at blocks 120, 316. Applying the policy to the sensor data message may result in the gateway sending a response, such as an acknowledgement 122, to the loT device 10, forwarding the sensor data to the loT controller in a message 124, or discarding the sensor data.

[0051] Figure 3C illustrates a method of operating an loT controller 30 according to some embodiments. The method includes transmitting a sensor data management policy to a gateway node in a data communication network (block 322), wherein the gateway node is configured to receive sensor data messages from loT devices and forward the sensor data messages to loT controller, wherein the sensor data management policy defines policies for handling sensor data messages transmitted by the loT devices to the loT controller. The loT controller 30 then receives a sensor data message from the gateway node in accordance with the sensor data management policy (block 324).

[0052] Various scenarios for handling sensor data according to a sensor data

management policy are illustrated in Figures 4A to 4C. Referring to Figure 4A, in some embodiments, based on applying the sensor data management policy at block 120, the gateway 20 may send a response 122, such as an acknowledgement, back to the loT device 10 and then discard the sensor data rather than forwarding it to the loT controller 30. In some

embodiments, the gateway 20 may analyze the actual data provided by the loT device 10 in applying the sensor data management policy, while in other embodiments, the gateway 20 may analyze a message type indicator provided along with the message as described above. If the sensor data message includes a message type field 206 (Fig. 11B) indicating the type of message that is being transmitted, and the gateway 20 may apply the sensor data management policy based on the type of message.

[0053] In response to receiving the acknowledgement, the loT device 10 may return to sleep mode to conserve battery life (block 130). That is, the loT device 10 may have no awareness that the data was not forwarded to the loT controller 30, and may not have to wait for the loT controller to receive, process, and reply to the message before transitioning to sleep mode, thus potentially saving energy.

[0054] Referring to Figure 4B, in some embodiments, based on applying the sensor data management policy at block 120, the gateway 20 may forward the sensor data to the loT controller 30 without sending an immediate acknowledgement to the loT device 10. Based on the type and/or content of the sensor data, the sensor data management policy may provide that the loT device should wait for acknowledgement, and possibly further commands, from the loT controller 30 before transitioning to sleep mode.

[0055] Referring to Figure 4C, in some embodiments, based on applying the sensor data management policy at block 120, the gateway 20 may forward the sensor data to the loT controller 30 and send an acknowledgement 122 to the loT device 10. For example, for some types of messages, the loT controller 30 may want to receive the data and also want the loT device 10 to immediately return to sleep mode at block 130.

[0056] Still further embodiments are illustrated in Figure 5. As shown therein, after applying the sensor data management policy at block 120, the gateway 20 may send a response message 122 back to the loT device 10 instructing the loT device to wait for further response from the loT controller 30. The loT device 10 then knows not to enter sleep mode, but to wait for a response from the loT controller 30. The gateway 20 forwards the sensor data to the loT controller 30 in a message 124, and the loT controller 30 responds in a message 126 with a response (OK), which the gateway 20 forwards to the loT device 10 in a message 128. The loT device 10 may then transition to sleep mode at block 130.

[0057] Still further embodiments are illustrated in Figure 6. As shown therein, after applying the sensor data management policy at block 120, the gateway 20 may simply discard the sensor data without acknowledgement and without forwarding it to the loT controller 30.

[0058] In some embodiments, an loT controller 30 can configure the gateway 20 with a command management policy that controls how the gateway 20 processes some types of commands provided by the loT controller 30. For example, the loT controller 30 can install a policy on the gateway 20 that defines time-related policies for handling one or more types of commands. Accordingly, in some embodiments, a gateway 20 that receives multiple non-time- critical commands directed to a single loT device 10 can buffer the commands and possibly combine multiple commands into a single command or packet (in a process referred to as "batching") for delivery to the loT device 10, instead of sending them directly to the loT device 10 one at a time. Thus, the gateway 20 can wait to transmit the command(s) until the sensor wakes up, which may conserve power at the loT device 10.

[0059] In some embodiments, the command management policy may be provided within the message itself. For example, when the loT controller 30 sends a command to the loT device 10, it may include information in the command message informing the gateway 20, for example, when the command should be delivered to the device at the latest (e.g., a latest delivery delay time period), and/or information indicating when the command should be discarded if not already sent (e.g., a delivery time-out period). The command may also include an indication of the importance of the command so that, for example, its transmission can be prioritized by the gateway 20 relative to other commands.

[0060] When the gateway 20 receives a message that is critical to be delivered, it may send the message immediately to the loT device 10, potentially attempting to wake up the loT device 10 (e.g., using Wake-on-LAN methods) before sending the message. For important messages, the gateway 20 may send the message directly to the loT device 10 unless the device 10 is sleeping. For sleeping devices, the gateway 20 may wait for either (i) the device 10 to wake up or (ii) the latest delivery delay time period to pass before sending the message. For messages that are not important or critical, the gateway 20 may wait for the device 10 to wake up before sending the message, or, if the device 10 does not wake up before the expiration of the delivery time-out period at time T2, the message may be dropped.

[0061] Table 2 illustrates an example of a command management policy that enables handling of various commands and resulting actions. The command management policy shown in Table 2 is provided as a simplified example for illustrative purposes.

Table 2 - Example Command Management Policy

[0062] A delivery delay time limit or delivery time-out period of zero indicates that no such limit is set. Thus, as shown in Table 2, if a command type indicates that the command is a status request, the gateway 20 may delay sending the message until the loT device 10 is awake with a delivery delay time limit of 100 seconds and a delivery time-out period of 500 seconds. If the command is a critical data request ("Data request - critical"), the gateway will attempt to deliver the command to the loT device 10 immediately, even if it has to wake the device up to do so. If the command is a non-critical data request ("Data request - non-critical"), the gateway 20 will attempt to deliver the message immediately even if it has to wake the device up to do so, but will set a delivery time out period for the request. If the command is an

acknowledgement, the gateway 20 will wait 100 seconds for the loT device to wake up before attempting delivery of the message.

[0063] Brief reference is made to Figure 11C which illustrates an example of a command message 200B that may be transmitted by the loT controller 30 to the gateway 20. The command message 200B may include a header 212 containing control and/or addressing information and a message body 220 containing the actual message. The message body 220 may be encrypted by the loT controller 30 and thus may not be readable by the gateway 20 in some embodiments. In other embodiments, message body 220 may not be encrypted and thus may be readable by the gateway 20. The command message 200B may further include a GW command field 216 that is not encrypted and that provides an explicit command to the gateway 20. The command message 200B may further include a command parameters field 218 that is not encrypted and that provides parameters accompanying the command in the GW command field 216. The command message 200B may further include a message digest 214 that contains a hash of the message body 210, the GW command field 216 and the command parameters 218 may also be included to ensure integrity of the message.

[0064] The GW command and command parameter fields 216, 218 may be used by the loT controller to provide explicit instructions to the gateway 20 for handling a particular command and/or may be used to configure or update the configuration of one or more management policies at the gateway 20.

[0065] Operations according to some embodiments are illustrated in Figures 7A and 7B.

Figure 7A is a message flow diagram illustrating the flow of messages between an loT controller 30, a gateway 20 and an loT device 10 according to some embodiments. Figure 7B is a flowchart of operations of a gateway 20 according to some embodiments.

[0066] Referring to Figures 7A and 7B, an loT controller 30 may configure a gateway 20 with a command management policy that defines how the gateway 20 should handle commands received from the loT controller 30 via a message 100 from the loT controller 30 to the gateway 20. In particular, the command management policy may define how the gateway should process commands transmitted to loT devices 10 based on the type and/or content of the command. The gateway 20 receives and stores the command management policy for later reference.

[0067] After configuring the gateway 20 with a command management policy, the loT controller 30 may send a command message 102 to the gateway 20. The command message 102 may be addressed to the loT device 10. In some embodiments, the command message 102 may be carried within a container message addressed to the gateway 20, and the gateway 20 determines which loT device 10 the command message 102 should be sent to. The gateway 20 receives the command message (block 702) and determines based on the command message at block 104 whether the command message policy applies to the command message (block 704). If the policy applies to the command message, the gateway 20 then applies the command message policy to the command message at block 106, 706. As a result of applying the command message policy to the command message, the gateway 20 may transmit the command message to the loT device 10 in operation 108.

[0068] Figure 7C illustrates a method of operating an loT controller 30 according to some embodiments. The method includes transmitting a command management policy to a gateway node in a data communication network (block 722), wherein the gateway node is configured to receive command messages from the loT controller and forward the command messages to loT devices that are managed by the gateway node, wherein the command management policy defines policies for handling command messages transmitted by the loT controller. The method further includes transmitting a command message to the gateway node (block 724), wherein the command message is addressed to an loT device managed by the gateway node and wherein the command message contains a command that is subject to the command management policy.

[0069] Various scenarios for handling command messages according to a command management policy are illustrated in Figures 8A to 8C. Referring to Figure 8A, in some embodiments, based on applying the command management policy at block 120, the gateway 20 may wait until a latest delivery delay time period has elapsed at time Tl, and if the loT device 10 has not woken up before the latest delivery delay time period has elapsed at time Tl, the gateway 20 may send a wake up message 107 to the loT device 10 and then send the command message 108 to the loT device. The latest delivery delay time period may represent the longest period of time that the gateway 20 should wait for the loT device 10 to wake up before proceeding to sent the command to the loT device 10.

[0070] Referring to Figure 8B, in some embodiments, the loT device 10 may wake up before the latest delivery delay time period has elapsed at time Tl. The loT device 10 may indicate that it is awake by sending a message 109 to the gateway 20. The message 109 may by any message that indicates that the loT device 10 is out of sleep mode, including a data message and/or a control message. In response to the message 109, the gateway 20 may send the command message 108 before the latest delivery delay time period has elapsed at time Tl.

[0071] Figure 8C is a flowchart of operations that may be performed by a gateway 20 according to some embodiments. Referring to Figure 8C, a gateway 20 may receive a command message from an loT controller 30 (block 802). The gateway 20 then proceeds to determine at block 822 if a command policy that covers the message has set a latest delivery delay time period. If not, the operations proceed to block 828, where the gateway 20 transmits the message to the loT device 10, waking the loT device up if need be. If a command policy that covers the message has set a latest delivery delay time period, operations proceed to block 824 where the gateway 20 determines if the latest delivery delay time period has expired. For example, if a command management policy has provided that a latest delay delivery time period of one minute should apply to the message, the gateway 20 checks at block 824 to see if one minute has passed since the message was received at the gateway 20. If so, the operations proceed to block 828, where the gateway 20 transmits the message to the loT device 10, waking the loT device up if need be. If the latest delay delivery time period has not expired, the gateway 20 checks at block 826 to see if the loT device is awake, for example, based on whether or not the gateway 20 has received a message from the loT device 10 indicating that it is out of sleep mode. In some embodiments, the loT device may enter/exit sleep mode based on a schedule known to the gateway 20. If the loT device 10 is not awake, operations return to block 822. If the loT device 10 is determined at block 826 to be awake, the gateway 20 transmits the message to the loT device at block 828.

[0072] Further scenarios for handling command messages according to a command management policy are illustrated in Figures 9A and 9B. Referring to Figure 9A, in some embodiments, both a latest delivery delay time period and a delivery time-out period may be defined by a command management policy. The delivery time-out period may define a time limit after which a command may no longer be valid and can be discarded by the gateway 20 if it has not yet been delivered. Thus, after applying the command management policy to the command 102 at block 106, the gateway 20 may attempt to deliver the command message after the latest delivery delay time period has elapsed at time Tl. If the gateway 20 has not successfully delivered the command message before the expiration of the delivery time-out period at time T2, the gateway 20 may discard the command message at block 111. It will be appreciated that a command management policy may define a latest delivery time period without defining a delivery time-out period, and vice-versa.

[0073] Operations according to some embodiments are illustrated in Figure 9B.

Referring to Figure 9B, a gateway 20 may receive a command message from an loT controller 30 (block 902). The gateway 20 then proceeds to determine at block 942 if a command policy that covers the message has set a delivery time-out period. If not, the operations proceed to block 950, where the gateway 20 keeps the message in the transmit queue. If a command policy that covers the message has set a delivery time-out period, operations proceed to block 944 where the gateway 20 determines if the command message has been transmitted to the loT device yet. If so, the gateway 20 removes the command message from the queue at block 948. If not, the gateway 20 determines at block 946 whether or not the delivery time-out period has expired. If so, operations proceed to block 948 where the gateway 20 removes the message from the transmit queue. Otherwise, operations return to block 944.

[0074] Still further scenarios for handling command messages according to a command management policy are illustrated in Figures 10A and 10B. In particular, Figures 10A and 10B illustrate scenarios in which a gateway 20 may aggregate multiple command messages received from an loT controller 30 and addressed to a common loT device 10 in a batching process. Referring to Figure 10A, a gateway 20 may receive a first command message 132 containing command Cl addressed to the loT device 10. Applying a command message policy to the command Cl, the gateway 20 may determine that a latest delay delivery time period applies to the command Cl and, rather than transmitting the command to the loT device 10, the gateway 20 may queue the command for later processing.

[0075] Before the expiration of the latest delay delivery time period at time Tl, the gateway 20 may receive a second message 136 from the loT controller 30 containing a second command C2. The gateway 20 may apply a command message policy to the command C2, and may as a result of applying the policy determine that a latest delay delivery time period applies to the command C2. Again, rather than transmitting the command C2 to the loT device 10 immediately, the gateway 20 may queue the command for later processing. After the expiration of the latest delay delivery time period that applies to the first command Cl at time Tl, the gateway 20 may send a wake-up message 140 to the loT device 10. The gateway 20 may assemble the first command Cl and the second command C2 into a single compound command containing both the first command Cl and the second command C2, and transmit the compound command to the loT device in a message 142. Because only a single command message is sent to the loT device 10, power requirements and/or transmission overhead may be reduced. Figure 10B illustrates a similar scenario, except that transmission of the command message 142 including the compound command occurs in response to receiving a message 140 from the loT device 10 before the expiration of the latest delivery delay time period at time Tl indicating that the loT device 10 is awake.

[0076] The loT controller 30 may use a control channel to install policies in the gateway

20. The control channel may a protocol such as one used for sending measurements and commands, such as a Lightweight Machine to Machine Protocol, LwM2M, which has been defined for loT devices. The policies installed by the loT controller 30 may describe what type of messages the loT controller 30 wants to receive from the gateway 20. Additionally, policies regarding commands describe the required handling of those commands by the gateway 20.

[0077] For the gateway 20 to act based on the contents of the messages, it needs to be able to read them. Therefore, full end-to-end encryption from the loT device to the loT controller may, in some embodiments, not feasible. Instead, the gateway 20 can work as a CoAP proxy that terminates a transport layer security (TLS) connection from the device and another TLS connection to the loT controller 30 as illustrated in Figure 11A. In some

embodiments, the TLS connection may be a datagram TLS (DTLS) connection. In addition or alternatively, object security with integrity protection only can be used so that the gateway 20 cannot change the data but can act based on it. Referring to Figure 11A, in some embodiments, the gateway 20 may establish a first TLS connection 220 with the loT device 10 that encrypts data transmitted between the gateway 20 and the loT device 10 and a second TLS connection 230 with the loT controller 30 that encrypts data transmitted between the gateway 20 and the loT controller 30.

[0078] Figure 12A is a block diagram illustrating elements of a gateway 20 according to embodiments of inventive concepts. As shown, the gateway 20 may include a transceiver circuit 1201 (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with wireless devices. The gateway 20 may include a network interface circuit 1207 (also referred to as a network interface) configured to provide communications with other nodes (e.g., with other base stations and/or core gateways) of the RAN. The gateway 20 may also include a processor circuit 1203 (also referred to as a processor) coupled to the transceiver circuit, and a memory circuit 1205 (also referred to as memory) coupled to the processor circuit. The memory circuit 1205 may include computer readable program code that when executed by the processor circuit 1203 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 1203 may be defined to include memory so that a separate memory circuit is not required.

[0079] As discussed herein, operations of the gateway 20 may be performed by processor 1203, network interface 1207, and/or transceiver 1201. For example, processor 1203 may control transceiver 1201 to transmit downlink communications through transceiver 1201 over a radio interface to one or more loT devices and/or to receive uplink communications through transceiver 1201 from one or more loT devices over a radio interface. Similarly, processor 1203 may control network interface 1207 to transmit communications through network interface 1207 to one or more other gateways and/or to receive communications through network interface from one or more other gateways.

[0080] Figure 12B is a block diagram illustrating functional modules of a gateway 20 according to some embodiments. These modules may be stored in memory 1205, and may provide instructions so that when instructions of a module are executed by processor 1203, processor 1203 performs respective operations discussed herein. As shown in Figure 12B, the functional modules may include a receiving module 1220, a command processing module 1222, an loT data processing module 1224 and a transmitting module 1226. The receiving module 1220 controls reception of signals using the transceiver 1201. The command processing module 1222 processes commands received from an loT controller and applies a command management policy to the commands. The loT data processing module 1224 processes data messages received from loT devices 10 and applies a data management policy to the data messages. The transmitting module 1226 controls transmission of signals using the transceiver 1201.

[0081] Figure 13A is a block diagram illustrating elements of a loT device 10 (also referred to as a wireless communication device, a wireless communication terminal, user equipment, UE, a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts. As shown, loT device 10 may include a transceiver circuit 1301 (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station eNB of a wireless communication network (also referred to as a radio access network RAN). Wireless terminal 10 may also include a processor circuit 1303 (also referred to as a processor) coupled to the transceiver circuit, and a memory circuit 1305 (also referred to as memory) coupled to the processor circuit. The memory circuit 1305 may include computer readable program code that when executed by the processor circuit 13003 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 1303 may be defined to include memory so that a separate memory circuit is not required. Wireless terminal 10 may also include an interface (such as a user interface) coupled with processor 1303, and/or loT device 10 may be an loT and/or MTC device.

[0082] As discussed herein, operations of loT device 10 may be performed by processor

1303 and/or transceiver 1301. For example, processor 1303 may control transceiver 1301 to transmit uplink communications through transceiver 1301 over a radio interface to a base station eNB of a wireless communication network and/or to receive downlink communications through transceiver 1301 from a base station eNB of the wireless communication network over a radio interface. [0083] Figure 13B is a block diagram illustrating functional modules of a loT device 10 according to some embodiments. These modules may be stored in memory 1305, and may provide instructions so that when instructions of a module are executed by processor 1303, processor 1303 performs respective operations discussed herein. As shown in Figure 13B, the functional modules may include a receiving module 1320, a measurement module 1322 and a transmitting module 1326. The receiving module 1320 controls reception of signals using the transceiver 1301. The measurement module 1322 obtains data at the request of an loT controller. The transmitting module 1326 controls transmission of signals using the transceiver 1301.

[0084] Figure 14A is a block diagram illustrating elements of an loT controller 30 according to embodiments of inventive concepts. As shown, the loT controller 30 may include a transceiver circuit 1401 (also referred to as a transceiver) including a transmitter and a receiver configured to provide uplink and downlink radio communications with wireless devices. The loT controller 30 may include a network interface circuit 1407 (also referred to as a network interface) configured to provide communications with other nodes (e.g., with other base stations and/or core gateways) of the RAN. The gateway may also include a processor circuit 1403 (also referred to as a processor) coupled to the transceiver circuit, and a memory circuit 1405 (also referred to as memory) coupled to the processor circuit. The memory circuit 1405 may include computer readable program code that when executed by the processor circuit 1403 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 1403 may be defined to include memory so that a separate memory circuit is not required.

[0085] As discussed herein, operations of the loT controller 30 may be performed by processor 1403, network interface 1407, and/or transceiver 1401. For example, processor 1403 may control transceiver 1401 to transmit downlink communications through transceiver 1401 over a radio interface to one or more loT devices and/or to receive uplink communications through transceiver 1401 from one or more loT devices over a radio interface. Similarly, processor 1403 may control network interface 1407 to transmit communications through network interface 1407 to one or more other gateways and/or to receive communications through network interface from one or more other gateways.

[0086] Figure 14B is a block diagram illustrating functional modules of a loT controller

30 according to some embodiments. These modules may be stored in memory 1405, and may provide instructions so that when instructions of a module are executed by processor 1403, processor 1403 performs respective operations discussed herein. As shown in Figure 14B, the functional modules may include a receiving module 1420, a policy module 1422, and a transmitting module 1426. The receiving module 1420 controls reception of signals using the transceiver 1401. The policy module 1422 establishes and manages command management policies and data management policies at a gateway 20. The transmitting module 1426 controls transmission of signals using the transceiver 1401.

[0087] FURTHER DEFINITIONS AND ABBREVIATIONS

[0088] In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be

interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0089] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

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

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

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

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

[0093] These computer program instructions may also be stored in a tangible computer- readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0094] It should also be noted that in some alternate implementations, the

functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the

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

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

[0095] The following abbreviations may be used in the foregoing detailed description:

3GPP Third Generation Partnership Project

CN Core Network eNB E-UTRAN Node B

E-UTRAN Evolved Universal Terrestrial Radio Access Network

gNB gNode B (a Node B supporting NR and connectivity to NGC)

HSPA High-Speed Packet Access

LTE Long Term Evolution

MDT Minimization of Drive Tests

NGC Next Generation Core

NR New Radio

O&M Operation and Maintenance

PS Packet Switched

QoE Quality of Experience

RAB Radio Access Bearer

RAN Radio Access Network

RANAP Radio Access Network Application Part

RNC Radio Network Controller

RRC Radio Resource Control

UE User Equipment

UMTS Universal Mobile Telecommunications System

UTRAN Universal Terrestrial Radio Access Network

XML Extensible Markup Language

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

Claims

CLAIMS:

1. A method of operating a gateway node (20) in a data communication network, comprising:

receiving (702) a command message from an internet of things, loT, controller (30), wherein the command message is addressed to an loT device (10) registered with the gateway node and includes a command for the loT device;

determining (704) based on the command message whether a command management policy applies to the command message; and

applying (706) the command management policy to the command message.

2. The method of Claim 1, further comprising:

receiving the command management policy from the loT controller prior to receiving the command message from the loT controller.

3. The method of Claim 1 or 2, further comprising:

determining to transmit, or not transmit, the command message to the loT device based on applying the command management policy.

4. The method of any previous claim, wherein the command management policy comprises a latest delivery delay time period, the method further comprising: waiting to transmit the command message to the loT device until after expiration of the latest delivery delay time period following receipt of the command message in accordance with the command management policy.

5. The method of Claim 4, further comprising:

after expiration of the latest delivery delay time period, transmitting a wake-up message to the loT device to cause the loT device to wake up; and

after transmitting the wake-up message to the loT device, transmitting the command message to the loT device.

6. The method of any of Claims 1 to 3, wherein the command management policy comprises a latest delivery delay time period, the method further comprising:

waiting to receive an awake message from the loT device before expiration of the latest delivery delay time period; and

after receiving the awake message, transmitting the command message to the loT device.

7. The method of any of Claims 1 to 3, wherein the command management policy comprises a delivery time-out period, the method further comprising:

waiting to receive an awake message from the loT device before expiration of the delivery time-out period; and in response to not receiving an awake message from the loT device before expiration of the delivery time-out period, discarding the command message.

8. The method of any of Claims 1 to 3, wherein the command message comprises a first command message, and wherein the command management policy comprises a latest delivery delay time period, the method further comprising:

receiving a second command message from the loT controller during the latest delivery delay time period following receipt of the first command message;

aggregating the first and second command messages into a combined command message; and

transmitting the combined command message to the loT device.

9. The method of Claim 8, wherein transmitting the combined command message is performed after expiration of the latest delivery delay time period.

10. The method of Claim 8, wherein transmitting the combined command message is performed in response to receiving an awake message from the loT device.

11. The method of any previous claim, wherein the command message comprises a message body and a message type, and wherein determining whether the command management policy applies to the command message comprises determining whether the command management policy applies to the command message based on the message type.

12. The method of Claim 11, wherein the message body comprises encrypted data that is not readable by the gateway node.

13. The method of Claim 11 or 12, wherein the command message further comprises a message digest of the message body and the message type.

14. The method of any of Claims 11 to 13, wherein the command message further comprises a gateway command that instructs the gateway node how to apply the command management policy to the command message.

15. The method of any previous claim, wherein communications between the gateway node and the loT controller are secured using a first transport layer security protocol connection and communications between the gateway node and the loT device are secured using a second transport layer security protocol connection.

16. A method of operating a gateway node (20) in a data communication network, comprising:

receiving (312) a sensor data message from an internet of things, loT, device (10), wherein the sensor data message is addressed to an loT controller (30);

determining (314) based on the sensor data message whether a sensor data management policy applies to the sensor data message; and applying (316) the sensor data management policy to the sensor data message.

17. The method of Claim 16, further comprising:

receiving the sensor data management policy from the loT controller prior to receiving the sensor data message from the loT device.

18. The method of Claim 16 or 17, further comprising:

determining to transmit, or not transmit, the sensor data message to the loT controller based on applying the sensor data management policy.

19. The method of any of Claims 16 to 18, further comprising:

discarding the sensor data message based on applying the sensor data management policy.

20. The method of any of Claims 16 to 18, further comprising:

transmitting the sensor data message to the loT controller based on applying the sensor data management policy.

21. The method of Claim 20, further comprising transmitting a wait message to the loT device based on applying the sensor data management policy, wherein the wait message instructs the loT device not to enter sleep mode until a response from the loT controller has been received.

22. The method of Claim 21, further comprising:

receiving a response message from the loT controller; and

transmitting the response message to the loT device.

23. The method of any of Claims 16 to 22, wherein the sensor data message comprises a message body and a message type, and wherein determining whether the sensor data management policy applies to the sensor data message comprises determining whether the sensor data management policy applies to the sensor data message based on the message type.

24. The method of Claim 23, wherein the message body comprises encrypted data that is not readable by the gateway node.

25. The method of Claim 23 or 24, wherein the sensor data message further comprises a message digest of the message body and the message type.

26. A gateway node (20), comprising:

a network interface (1207) configured to communicate with an internet of things, loT, controller (30);

a transceiver (1201) configured to communicate with an loT device (10) registered with the gateway node; and a processor (1203) coupled to the transceiver, wherein the processor is configured to perform operations according to any of Claims 1 to 25.

27. A gateway node (20), wherein the gateway node is adapted to perform operations according to any of Claims 1 to 25.

28. A method of operating an internet of things, loT, controller (30), comprising: transmitting (722) a command management policy to a gateway node (20) in a data communication network, wherein the gateway node is configured to receive command messages from the loT controller and forward the command messages to loT devices (10) that are registered with the gateway node, wherein the command management policy defines policies for handling command messages transmitted by the loT controller; and

transmitting (724) a command message to the gateway node, wherein the command message is addressed to an loT device managed by the gateway node and wherein the command message contains a command that is subject to the command management policy.

29. The method of Claim 28, wherein the command management policy defines a delivery delay time period for at least one type of command.

30. The method of Claim 28 or 29, wherein the command management policy defines a delivery time-out period for at least one type of command.

31. The method of any of Claims 28 to 30, wherein the command message comprises a gateway command field containing a gateway command that controls how the gateway node processes the command message in accordance with the command management policy.

32. The method of Claims 31, wherein the command message comprises a command parameters field containing command parameters that accompany the gateway command.

33. The method of any of Claims 28 to 32, wherein the command message comprises a message body that contains the command, wherein the message body is encrypted.

34. A method of operating an internet of things, loT, controller (30), comprising: transmitting (322) a sensor data management policy to a gateway node (20) in a data communication network, wherein the gateway node is configured to receive sensor data messages from loT devices (10) and forward the sensor data messages to loT controller, wherein the sensor data management policy defines policies for handling sensor data messages transmitted by the loT devices to the loT controller; and

receiving (324) a sensor data message from the gateway node in accordance with the sensor data management policy.

35. The method of Claim 34, wherein the sensor data management policy defines whether or not the gateway should forward a sensor data message based on sensor data contained in the sensor data message.

36. The method of Claim 34 or 35, wherein the sensor data management policy defines whether or not the gateway should forward a sensor data message based on a message type of the sensor data message.

37. The method of any of Claims 34 to 36, wherein the sensor data message comprises a message type field.

38. The method of any of Claims 34 to 37, wherein the sensor data message comprises a message body that contains the sensor data, wherein the message body is encrypted.

39. An internet of things, loT, controller (30), comprising:

a network interface (1407) configured to communicate with a gateway node and an loT device registered with the gateway node; and

a processor (1403) coupled to the network interface, wherein the processor is configured to perform operations according to any of Claims 28 to 38.

40. An internet of things, loT, controller (30), wherein the loT controller is adapted to perform operations according to any of Claims 28 to 38.