Management of IoT devices in wireless communication networks

Abstract

This document discloses a method for a network operator controller to manage multiple IoT devices associated with an Internet of Things (IoT) device owner and connected to a wireless network. The method includes: receiving a list of IoT devices scheduled for firmware updates, wherein the list indicates corresponding update data and an update process for each IoT device in the list; determining at least one network node serving a geographic area covering the corresponding location of each IoT device in the list; causing the corresponding update data to be cached; determining an update schedule instructing each IoT device when to receive its corresponding update data; and instructing the at least one network node to update the IoT device using the cached corresponding update data according to the update schedule and update process.

Description

Technical Field

[0001] This invention generally relates to the field of Internet of Things (IoT) devices in wireless communication networks. More specifically, it relates to the management of IoT devices in wireless communication networks. Background Technology

[0002] The Internet of Things (hereinafter referred to as IoT) is a system of interconnected computing devices. It is generally expected that billions of IoT devices may be deployed across various sectors around the world in the future. For example, an individual company or corporation may have thousands of IoT devices to manage. The sheer number of devices typically presents challenges in terms of security and vulnerability. For instance, if IoT devices are not updated when security vulnerabilities are discovered, they may be vulnerable to potential hacking attacks.

[0003] However, managing large fleets of IoT devices (including very large numbers, such as thousands, tens of thousands, or more) is becoming increasingly complex. This is often challenging in test lab environments, and even more so for unattended, remote IoT devices. It becomes particularly challenging over time and under various conditions for IoT devices.

[0004] Therefore, alternative methods for managing IoT devices are needed. Summary of the Invention

[0005] It should be emphasized that, when used in this specification, the term "comprising / including" (which may be replaced by "including / containing") is used to specify the presence of the stated feature, integer, step, or component, but does not exclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. As used herein, unless the context clearly indicates otherwise, the singular forms "a," "an," and "the" are intended to also include the plural forms.

[0006] Generally speaking, the arrangement mentioned in this article should be understood as a physical product; for example, a device. A physical product may include one or more parts, such as control circuits in the form of one or more controllers, one or more processors, etc.

[0007] Some embodiments are intended to address or mitigate, reduce or eliminate at least some of the above-mentioned disadvantages, and to provide methods and apparatus for IoT device management.

[0008] According to the first aspect, this is achieved through a method of network operator controllers for managing multiple Internet of Things (IoT) devices associated with IoT device owners and connected to wireless networks.

[0009] A network operator controller can be an entity associated with or belonging to a network operator. It can be, for example, a central server deployed within the network or a cloud implementation.

[0010] It should be noted that the terms network operator, network operator controller, and network operator server are used interchangeably in this disclosure.

[0011] According to the method of the first aspect, it includes receiving a list of IoT devices scheduled for firmware updates, wherein the list indicates the corresponding update data and update process for each IoT device in the list. The update data may, for example, be bound to an updated firmware and may include firmware upgrades. Furthermore, different IoT devices may require the same or different firmware updates, which may be specified in the list.

[0012] The method also includes identifying at least one network node serving a geographical area corresponding to the location of each IoT device in the list covering the devices. The devices in the list may be scattered across several different locations. The method may include finding network nodes serving the devices in the list. A single network node may serve multiple devices in the list.

[0013] The method also includes caching the corresponding updated data.

[0014] The method also includes determining an update schedule that indicates when each IoT device (in the list) will receive its corresponding update data, and further instructing the at least one network node to update the IoT device using the cached corresponding update data according to the update schedule and update process.

[0015] Therefore, the method described in the first aspect transfers the responsibility for updating IoT devices belonging to the device owner from the device owner to the network operator providing the IoT devices. The network operator can then assign the task of updating IoT devices to network nodes within the network serving the geographical area where the corresponding IoT device to be updated is located. Compared to a conventional setup, this setup provides device owners with better network transparency and reduces network traffic and load.

[0016] In some embodiments, the update process includes information instructing at least one process for performing a firmware update and at least one process for determining whether the firmware update was successfully performed. The update process may, for example, include instructions regarding which upgrades / updates / patches / firmware should be distributed, to whom they should be distributed, and in what order. The update process may further include control instructions or confirmation processes that should be performed to confirm that the update was performed correctly and that the device has been correctly upgraded / updated.

[0017] In some embodiments, the method may further include instructing at least one network node to keep the IoT device active for the entire duration during which it receives the corresponding update data according to the update schedule, and to return to its default sleep cycle upon completion of the firmware update. The update may be transmitted, for example, in multiple data transmissions that may span a certain amount of time (e.g., seconds, minutes, hours, etc.), and the network node may instruct the IoT devices it serves and those receiving the update to relay the update during that time period, and the IoT devices are not allowed to enter their default sleep cycle until the update has been received and / or successfully installed.

[0018] In some embodiments, the list of IoT devices may include a further list of vulnerable IoT devices. Therefore, in some embodiments, the method may further include instructing at least one network node to block vulnerable IoT devices from communicating with the network until they have received the required update data. Receiving (and installing) the required update data may cause the IoT device to enter the desired state, which may be a result of a successful update. In some embodiments, this further list may be merged with the list of IoT devices, and devices to be blocked are marked as such in the list of IoT devices.

[0019] In some embodiments, all IoT devices in this list can be considered vulnerable devices.

[0020] In some embodiments, the method may include instructing at least one network node to prevent vulnerable IoT devices from communicating using at least one of Wi-Fi, Bluetooth, Near Field Communication (NFC), or other short-range communication types.

[0021] In some embodiments, the method may include instructing at least one network node to block a vulnerable IoT device from communicating with any other entity besides the at least one network node. Therefore, in some embodiments, the blocking instruction may include preventing an external entity from communicating with the vulnerable device, and the vulnerable device may communicate only with the at least one network node (or network operator controller) until the blocking is lifted.

[0022] In some embodiments, the method may further include instructing at least one network node to push the required update data to the blocked vulnerable IoT device according to the update schedule, and determining whether the vulnerable IoT device has been successfully updated based on the update process.

[0023] In some embodiments, the method may further include notifying the IoT device owner of any unsuccessful updates, and when it is determined that a vulnerable IoT device has been successfully updated, instructing the at least one network node to unblock the vulnerable IoT device, and notifying the IoT device owner of the successful update.

[0024] In some embodiments, the update scheduling is based on at least one network condition that relates to at least one or more of the following: expected network load, expected load from network users, usage of the internal transport network, compute nodes, timing, IoT device sequence, IoT device activity, and IoT device priority.

[0025] In some embodiments, caching the corresponding update data includes: caching the corresponding update data at a central network server and / or instructing at least one network node to cache the corresponding update data. The update data (i.e., firmware updates) can be centrally cached at a network operator server, a central computing node, or an edge computing node (edge ​​data center), or it can be locally cached at a network node serving the IoT device to be updated. The location for caching data can be determined based on the size of the update, local and / or overall network load, the complexity of the update, the location of the IoT device to be updated, etc.

[0026] An edge data center can be, for example, a network node or server deployed within a network and close to a network cell, possessing storage and computing capabilities. An edge data center can, for example, store firmware updates and relay them directly or via another network node to IoT devices. Therefore, in this disclosure, an edge data center is understood as a general-purpose computing node located closer to the eNB / gNB in ​​the operator's infrastructure than a central data center. The size and location of data centers can vary considerably. Edge data centers typically enable storage and computing to be used for firmware caching and IoT device update processes, as well as interaction / feedback with device owners. It typically allows interaction with traditional network nodes responsible for device IoT connectivity.

[0027] In some embodiments, the method may further include determining, based on the update process, whether the IoT devices in the list have been successfully updated according to the update schedule, and notifying the IoT device owner server of any unsuccessful or successful updates.

[0028] In some embodiments, when it is determined that an IoT device in the list has failed to update successfully, the method may further include collecting information associated with the update and indicating the reason for the failure, and notifying the IoT device owner of the information collected by the server. This information may include, for example, information about what happened when the upgrade was completed (logs, received acknowledgments / negative acknowledgments, (un)successful control checks, timing, etc.). It may also include information about what happened from a network perspective (logs, processes, transmissions, responses, etc.). In some cases, geolocation may also be provided, for example, if the device owner must travel to the device in person for repair / update.

[0029] In some embodiments, at least one network node is a base station or a computing node. In some embodiments, at least one network node is an edge data center. In some embodiments, at least one network node is an eNb, gNb, or access node.

[0030] The second aspect is a computer program product comprising a non-transitory computer-readable medium. A computer program, including program instructions, is stored on the non-transitory computer-readable medium. The computer program is configured to be loaded into a data processing unit, which includes a processor and memory associated with or integrated into the data processing unit. When loaded into the data processing unit, the computer program is configured to be stored in the memory. When loaded into the processor and executed by the processor, the computer program is configured to cause the execution of the method steps according to the first aspect.

[0031] The third aspect is a network operator controller for managing multiple Internet of Things (IoT) devices associated with IoT device owners and connected to a wireless network. The device includes control circuitry configured to receive a list of IoT devices scheduled for firmware updates, wherein the list indicates corresponding update data and update procedures for each IoT device in the list.

[0032] The control circuit is also configured to identify at least one network node serving a geographic area of ​​the corresponding location for each IoT device in the list covering the device and cache the corresponding updated data.

[0033] The control circuit is also configured to determine an update schedule that indicates when each IoT device will receive its corresponding update data, and for each IoT device scheduled for update, instruct the at least one network node to update the IoT device using the cached corresponding update data according to the update schedule and update process.

[0034] The fourth aspect is a network node that includes the apparatus according to the third aspect.

[0035] In some embodiments, any of the foregoing aspects may additionally have the same or corresponding features as any of the various features explained above for any other aspect.

[0036] One advantage of some implementations is that they improve IoT device management by reducing network traffic and increasing network transparency for device owners.

[0037] One advantage of some implementations is enhanced security for IoT devices, as devices that are not adequately updated with the latest firmware and thus pose a risk may be prevented from communicating with the network.

[0038] Another advantage of some embodiments is that they can enhance control over IoT firmware updates.

[0039] Another advantage of some embodiments is that they increase the probability of successful updates for IoT devices, as IoT devices can be instructed to deviate from their default sleep cycles to remain awake throughout the entire duration of receiving updates. Attached Figure Description

[0040] Further objects, features, and advantages will become apparent from the following detailed description of embodiments, with reference to the accompanying drawings, in which:

[0041] Figure 1 This is a schematic diagram illustrating the network topology;

[0042] Figure 2 This is a schematic diagram illustrating the network topology;

[0043] Figure 3 This is a schematic diagram illustrating device management according to some embodiments;

[0044] Figure 4 This is a schematic diagram illustrating device management according to some embodiments;

[0045] Figure 5 This is a flowchart illustrating example method steps according to some embodiments;

[0046] Figure 6 This is a flowchart illustrating example method steps according to some embodiments;

[0047] Figure 7 These are flowcharts and signaling diagrams illustrating a combination of example methods / signaling steps according to some embodiments;

[0048] Figure 8 The illustration is a schematic diagram of a computer program product according to some embodiments; and

[0049] Figure 9 This is a block diagram illustrating an example arrangement according to some embodiments. Detailed Implementation

[0050] The following describes examples of enhancing network transparency and reducing vulnerabilities through improved IoT device management.

[0051] As mentioned earlier, the challenges of managing IoT devices increase with the number of connected devices. With IoT, billions of such devices are expected to be deployed globally across various sectors. Individual companies and corporations may manage thousands of IoT devices. Large-scale security and device management are often key to making IoT viable. Specifically, over-the-air (FOTA) firmware updates, which include security patches and functionalities, are typically required to keep IoT devices secure and highly functional. Failure to update after a security vulnerability is discovered leaves IoT devices vulnerable to hacking. However, IoT devices can be difficult to access, for example, due to mobility, power-saving algorithms, and limited connectivity, or simply because device owners cannot truly know the actual and / or exact location of their respective IoT devices.

[0052] Distributing new firmware to a large number of IoT devices typically requires sending the same firmware as the number of IoT devices, or sending even more firmware if a failure occurs during transmission or update. Large data transfers can lead to high loads on potentially critical systems during the time spent transmitting and performing updates.

[0053] Managing a large number of devices, tracking their current status, updating and confirming updates, handling situations where IoT devices are not performing one or more tasks during update periods, and handling error conditions become complex. This is challenging in test lab environments, and even more so for unattended remote IoT devices in real-world scenarios. It becomes particularly challenging over time and under various conditions of IoT devices.

[0054] A typical (albeit simplified) network topology containing IoT devices is as follows: Figure 1 As shown. In Figure 1 In this context, the owner of an IoT device, represented by or including the server or controller 110, is connected to the operator network 130 via a network cloud 120. The network cloud can be, for example, the Internet.

[0055] Multiple data server centers 140 communicate with the carrier network 130 and multiple network nodes 141 (1-N). Network nodes 141 (1-N) serve geographical areas 142 (1-N) (such as network cells) in which one or more IoT devices 143 (1-N) are deployed. The IoT devices 143 (1-N) are located in different physical locations and may be clustered. As described above, the device owner server 110 can access the carrier network 130 via the Internet. Furthermore, the IoT devices may use different carriers and exist in many countries. That is, the device owner server can typically access many different carrier networks via the Internet.

[0056] In some embodiments, the data server center 140 may be an edge DC (data center), but the features / services provided may also be handled by other compute nodes within the network, such as eNBs, gNBs, or, for example, evolved packet cores (EPCs). If there is an edge DC, it may be one edge DC per eNB, one edge DC for multiple eNBs, and so on, depending on the network requirements and layout.

[0057] like Figure 2 As shown, for IoT devices 143 (1-N) deployed in a conventional system, new firmware is typically stored in and distributed from a remote central server associated with the IoT device owner (e.g., device owner server 110; the terms device owner and device owner server are used interchangeably). Firmware updates typically require the IoT device to access the device owner's central server and retrieve the new firmware from it. When an update begins, the device owner 110 will need to provide sufficient bandwidth from the server containing the firmware.

[0058] Firmware updates are rolled out from a remote server of the device owner server 110 to the IoT devices 143 (1-N). Firmware typically needs to be propagated from the device owner's server to each IoT device 143 (1-N) via a connection / session across the entire network. Since firmware updates can be several megabytes in size, and the data sent from the devices to the base station / carrier controller / device owner can be several gigabytes, the rollout by the device owner typically requires significant resources, thus constituting a large overall network load. However, the data size should be considered as an example and may vary depending on the system, deployment, future needs, etc.

[0059] The IoT device owner server 110 sends update messages, and once the corresponding IoT device comes online to send any data it owns, it will also check if it has any pending messages from the device owner server 110. The device owner server 110 cannot know the exact time between sending and receiving a message, as it typically depends on network configuration and the communication scheduling of the IoT devices, all of which are controlled by the operator network 130.

[0060] Therefore, updates can take time to complete because there may be tens of thousands of IoT devices, and they are not typically updated simultaneously. This is due to server access and power-saving features that disconnect devices from the network for extended periods.

[0061] Updates, especially inconsistent updates (i.e., repeated attempts to send / receive and failures), will drain the power of IoT devices, which will typically shorten battery life.

[0062] Device owners typically lack knowledge and control over the connection to individual IoT devices, meaning they don't know when an update might be performed or how many attempts would be required. Connections to IoT devices may be impossible, for example, due to network congestion, lack of wireless coverage, or partial wireless coverage.

[0063] Therefore, outdated IoT devices with security vulnerabilities, critical errors, or API incompatibilities often continue to connect to the network and communicate until an update is released. In other words, there is no real way to disconnect an IoT device waiting for an update. Firmware updates are typically proportional to the size of individual data objects within an IoT device. Therefore, IoT devices may operate and / or communicate for extended periods while awaiting updates, potentially posing a serious security threat.

[0064] When using 3GPP technologies in IoT devices, the visibility of the network to IoT device owners is lower than they would typically have with other wireless technologies, because modems are often closed, networks are operated by network operators, and the internal workings of the network are often highly secretive to external participants. Finding suitable 3GPP stacks is also more difficult than with more open standards such as Wi-Fi.

[0065] Therefore, according to some embodiments of this document, it is suggested to utilize network operators to provide services for performing firmware updates and distributing them to the IoT devices of device owners, such as... Figure 3-4 It is shown schematically.

[0066] In short, Figure 3In this process, the network operator (i.e., the network operator server or controller) 330 can receive a list of IoT devices 143 (1-N) that should be updated, as well as other characteristics required to perform the update, from the IoT device owner 310 (e.g., the device owner server). The IoT devices can be presented in the list in association with their SIM card ID and / or the device's IMSI number.

[0067] It should be noted that when referring to an IoT device owner in this disclosure, it refers to the owner of the IoT device. A device owner can be, for example, a company, association, cooperative, natural person, legal person, etc., that has produced and / or deployed and / or used services related to IoT devices, and can be represented in the network, for example, through an associated device owner server. The server can be a physical implementation or a cloud implementation. Therefore, a device owner can include servers or other computing entities qualified to communicate with IoT devices and / or network operators / network nodes. Therefore, the terms IoT device owner, device owner, and IoT device owner server are used interchangeably in this disclosure.

[0068] Similarly, network operators can be considered as participants providing the network and its services. Network operators can be companies, associations, cooperatives, etc., and can be represented in the network through network operator servers and / or network operator controllers; therefore, the terms network operator server, network operator, and network operator controller are used interchangeably in this disclosure.

[0069] Network operator server 330 can receive a list and other necessary features from IoT device owner server 310 via Internet connection 320. New firmware to be updated is uploaded from device owner server 310, for example via a programmable application programming interface (API) or a graphical user interface (GUI), and is then distributed within the operator network to the nearest (or most suitable for access) IoT devices 143 (1-N) to be updated. The operator then executes the upgrade according to a calculated schedule (based on optimization objectives, taking into account, for example, time of day, device sequence, current device number, etc.).

[0070] Network operator server 330 can centrally cache firmware, for example, at operator servers and / or network nodes 340, 341, which will ultimately handle the actual updates for IoT devices. This will reduce the load on the device owner's infrastructure and reduce network load when collecting firmware, because compared to, for example Figure 2 and Figure 4 Instead of rolling out the same update across as many connections as possible with IoT devices on the entire network, it caches and distributes an update geographically close to the devices (e.g., within the same cell).

[0071] Figure 4 The illustration depicts an IoT device management scheme according to some embodiments, wherein the management of IoT devices has been transferred from a central IoT device owner server 310 to a network operator server 330, which then instructs network nodes serving the area where the IoT device to be updated is located to update the device. Figure 2 In comparison, it reduces the amount of network communication required, thereby reducing network load, and, as described below, achieves better device visibility for device owners.

[0072] Furthermore, network operators can enhance overall security by keeping track of which devices have successfully performed their updates and which have not. Devices that have failed to perform updates may be blocked from accessing the internet until they receive a full update. In the same way, network operators can receive information from IoT device owners indicating which IoT devices are vulnerable due to insufficient firmware updates, and network operators may temporarily block these devices from communicating with, for example, the internet and / or from communicating with external entities that are not network operators and / or network nodes performing updates.

[0073] Figure 5 An example method 500 according to some embodiments is illustrated. Method 500 can be derived from... Figure 3 and 4 The network operator server / controller 330 is executed.

[0074] Method 500 is a network operator controller used to manage multiple IoT devices associated with an Internet of Things (IoT) device owner and connected to a wireless network. Method 500 begins at step 510, receiving a list of IoT devices scheduled for firmware updates. This list indicates the respective update data and update process for each IoT device in the list. The update data may, for example, include one or more specific firmware updates to be distributed to the respective IoT devices. The update process may include information instructing at least one process for performing the firmware update and at least one process for determining whether the firmware update was successfully performed. Therefore, the update process may include instructions on how to perform the update and how to determine whether the update was successful. Furthermore, the update process may involve different tools executed on the network side.

[0075] The list, update process, and firmware / update data can be uploaded by the device owner to the network operator's controller, for example, through the device owner's server (e.g., Figure 3-4 The device owner server 310).

[0076] Method 500 then continues in step 520, determining at least one network node (with) serving the geographical area of ​​the corresponding location of each IoT device in the list covering the device. Figure 3 and Figure 4 (Compared to). In step 530, method 500 includes inducing caching of the corresponding update data. The network operator controller may, for example, cache the update data (i.e., the firmware for each corresponding IoT device to be updated) locally on an internal or external server, or closer to the device to be updated, for example by caching the update data at a network node serving a region including one or more IoT devices to be updated, or at a computing node / base station associated with the network node. Therefore, in some embodiments, causing the caching of the corresponding update data includes caching the corresponding update data at a central network server and / or instructing at least one network node to cache the corresponding update data.

[0077] Method 500 then continues in step 540, determining an update schedule instructing each IoT device when to receive its corresponding update data. In some embodiments, the update schedule may be based on at least one network condition. In some embodiments, the at least one network condition may relate to at least one or more of the following: expected network load, expected load from network users, usage of the internal transport network, compute nodes, timing, IoT device order, IoT device activity, and IoT device priority. For example, if it is expected that certain parts of the network may experience heavy load, updates for IoT devices served by network nodes expected to experience heavy load may be scheduled to occur at a time when the network load is not expected to be so high. In some embodiments, it may essentially be a group of devices receiving their updates quickly, and therefore they can be scheduled to receive their updates as soon as possible.

[0078] Then, method 500 continues in step 550, instructing at least one network node to update the IoT device with the cached corresponding update data according to the update schedule and update process. In some embodiments, the update schedule can be used to notify the IoT device when it should remain awake to receive updates. Thus, in some embodiments, method 500 may include instructing at least one network node to instruct the IoT device to remain active for the entire duration of receiving the corresponding update data according to the update schedule, and to return to the default sleep cycle when the firmware update is complete. In some embodiments, IoT devices scheduled for updates (i.e., on a list) but not yet received or in the process of installing updates can be placed in a more aggressive power-saving mode while waiting for their updates. They may, for example, be instructed to enter a sleep period that will end at some point, during which the device is completely unreachable. This may be feasible because any data that may be transmitted from the device may not be needed before it has been updated, and therefore this is considered safe. Another advantage of the aggressive power-saving mode is that network frequency / air / computing resources can be better utilized by not having to service IoT devices waiting for updates. The device is then kept active to ensure a smooth update, and once updated, it returns to the default sleep cycle.

[0079] Therefore, the probability of completing an update within a single session increases because the risk of the IoT device entering a sleep state while receiving an update is reduced. This can reduce the overall network load by minimizing the number of update transmission attempts. Security is also enhanced in the same way by reducing the risk of IoT devices partially updating or not updating at all.

[0080] In some embodiments, the list of IoT devices may further include another list of vulnerable IoT devices, and method 500 may further include an optional step 541 in step 540 of determining the update schedule, which includes instructing at least one network node to block vulnerable IoT devices from communicating with the network until they (IoT devices) have received the required update data (i.e., one or more IoT devices have entered the required state, which may be the result of a successful update / data transfer). Figure 6 A more detailed description of aspects that prevent vulnerable devices from being attacked.

[0081] In some embodiments, all IoT devices in this list can be marked as vulnerable and therefore should be blocked from communicating. This might be, for example, in some embodiments, preventing an IoT device from communicating if it lacks the latest available firmware. That is, it should not be allowed to communicate, and no entity other than the network operator or the network node performing the update should communicate with the outdated device. Therefore, in some embodiments, the alternative list could be a list in which all devices should be blocked until they are successfully updated.

[0082] Therefore, in some embodiments, all IoT devices in this list can be considered vulnerable devices.

[0083] In some embodiments, the method may include instructing at least one network node to prevent vulnerable IoT devices from communicating using at least one of Wi-Fi, Bluetooth, Near Field Communication (NFC), or other short-range communication types.

[0084] In some embodiments, the method may include instructing at least one network node to block a vulnerable IoT device from communicating with any other entity besides at least one network node / network operator. Therefore, in some embodiments, the blocking instruction may include preventing external entities from communicating with the vulnerable device, and the vulnerable device may communicate only with at least one network node (or network operator controller) until the block is lifted.

[0085] In some embodiments, method 500 may optionally include step 551, which determines, based on the update process, whether the IoT devices in the list have been successfully updated according to the update schedule. The update process may, for example, inform the network operator how to determine whether the update was successful. The update process may, for example, include the firmware version that the device should have if the update is installed correctly, and the network operator may request the current version from the IoT device and check whether the current version matches the firmware version of the process. The method may then continue in steps 552 and 554, notifying the IoT device owner server of any unsuccessful (No-path in steps 554, 551) or successful (Yes-path in steps 552, 551) updates.

[0086] In some embodiments, when it is determined that an IoT device in the list failed to update successfully (the No-path in 551), the method may further include step 553, collecting information associated with the update and indicating the reason for the failure, and notifying the IoT device owner server of the collected information (possibly in step 554 of method 500). This information may, for example, indicate what happened when the update was completed. It includes information from a network perspective about what happened. In some embodiments, this information may include the geographic location of the IoT device, which can help the IoT device owner physically locate the IoT device if the IoT device owner needs to travel to the IoT device in person.

[0087] Therefore, IoT device owners can always be aware of the current status and progress of firmware updates. Through the examples in this article, IoT device owners can see more than just failures. However, as discussed here, special care should be taken when an update failure is detected. Failures can result in anything from the device being "blocked" (i.e., it never comes back online), communication failures (i.e., the IoT device is now or has become inaccessible via the network), or the need for retrying, and so on. When a failure occurs, it can be important to communicate information to the IoT device owner to help modify their software or address problems during the update process, locate the device for physical inspection, and potentially leverage network operators to identify problems while performing the update.

[0088] IoT device owners may implement triggers on the updated progress status. Such triggers could, for example, notify the device owner and / or their associated users / customers of an update, initiate use of the IoT device, perform a post-upgrade check, and so on.

[0089] In some embodiments, method 500 can be combined with Figure 6 Method 600 can be combined with other methods. For example, in step 541 of method 500, a vulnerable IoT device is blocked from communicating with, for example, the Internet and / or a network because they pose a risk of potential attack. Step 550 of method 500 can then be combined with step 601 of method 600. In step 601, method 600 includes instructing at least one network node to push (or otherwise transmit) the required update data to the blocked vulnerable IoT device according to an update schedule, and in step 602, determining whether the vulnerable IoT device has been successfully updated based on the update process.

[0090] It should be noted that the term "push required update data" can have multiple meanings. For example, the term can refer to an actual push from a network operator (or network node), where the network operator instructs the device in a "This is the firmware, install it!" manner (i.e., as a command instruction). In some embodiments, a push could be the device periodically calling a server / network operator / network node and checking if new firmware is available before downloading it. In some embodiments, a push could be the network operator or device owner telling the device to retrieve an update package cached by the network operator when the device calls home to check for new firmware. Therefore, in some cases, the network operator may act as the place where the device checks for firmware updates.

[0091] In some embodiments, step 602 of method 600 may be combined with step 551 of method 500.

[0092] Method 600 can then continue in step 605 (the No-path in 602) to notify the IoT device owner server of any unsuccessful update, or continue in step 603 (the Yes-path in 602) to instruct at least one network node to unblock the vulnerable IoT device when it is determined that the vulnerable IoT device has been successfully updated. The method can then continue in step 604 to notify the IoT device owner server of the successful update.

[0093] In some embodiments, step 605 of method 600 may be combined with step 554 of method 500, and may further include step 553, collecting information associated with the reason for the update failure, and further notifying the device owner of the collected information.

[0094] In some embodiments, at least one network node is a base station or a computing node. In some embodiments, at least one network node is an edge data center, or an eNb, gNb, EPC, or access node.

[0095] The embodiments described herein require network operators to improve IoT device security and network efficiency by providing them with mechanisms to manage and update IoT device firmware. This eliminates the need for all IoT devices (estimated to be in the thousands) to obtain the same firmware from the device owner's server, thus putting pressure on both the device owner's and the operator's network.

[0096] The embodiments described herein minimize the vulnerability window of outdated IoT devices to malicious attacks by blocking connections from devices that have not yet been updated and request updates, and then allowing connections again once the devices have been updated.

[0097] In some implementations, network operators may become an integral part of the continuous integration / continuous deployment (CI / CD) processes of IoT device owners (manufacturers), thereby ensuring that IoT using 3GPP standards can maintain high quality and low cost without forcing device manufacturers to invest heavily in testing equipment and interoperability testing capabilities (people, organizations, and equipment). This will lower the barriers for small companies to produce devices for the global market, thereby stimulating innovation in the 3GPP IoT device ecosystem.

[0098] The embodiments described herein allow firmware and other necessary components to be distributed over a network operator’s distributed network, thereby reducing the load on servers and networks from repeatedly retransmitting the same firmware.

[0099] Figure 3 and 4 Scene and Figure 5 and 6 The method can be found in Figure 7 Visualize the combined flowchart and signaling diagram. Figure 7 In this configuration, the device owner (OWN) 710, network operator (OP) 720, compute node (CN) 730, network node (NW) 740, and IoT device (DEV) 750 are arranged to communicate. The device owner 710 can, for example, be combined with the preceding... Figure 3-6 The owner of any of the described devices (server / controllers). Similarly, network operator 720 could be... Figure 3-6 The network operator (server / controller), compute node 730 can be Figure 3-6 The computing node, network node 740 can be Figure 3-6 Network nodes and IoT devices 750 can be Figure 3-6 IoT devices. In some embodiments, compute node 730 and network node 740 refer to the same entity.

[0100] The device owner 710 may perform 711 authentication signaling to the network operator 720. Necessary credentials and one or more keys may be exchanged, for example, in a conventional manner. Then, the device owner 710 may upload firmware for one or more IoT devices of the device owner that should be used for updating. The network operator 720 may, for example, receive a list of IoT devices scheduled for firmware update, where the list indicates the corresponding update data (i.e., the uploaded firmware) and the update process for each IoT device in the list (compared to step 510 of method 500). It should be noted that the update data may indicate the same firmware update for all devices. That is, the list may include N devices and may indicate that devices 1 to N on the list (where N is an integer) will receive firmware X. Thus, for each device or subset of devices on the list, the corresponding firmware data may not have to be different. In some embodiments, the list may indicate that devices 1 to Y (Y < N) will receive firmware X, while devices (Y + 1) to N will receive firmware Y, so the corresponding firmware data may be different for different devices.

[0101] Then, the network operator may determine 721 at least one network node serving the geographical area corresponding to each IoT device in the list that covers the device (compared to step 520 of method 500), and cause the cache 723a, 723b to cache the corresponding update data (compared to step 530 of method 500). The network operator may, for example, distribute and cache the updated firmware at a computing node, which may then distribute it to network nodes serving the area including the corresponding IoT devices to be updated.

[0102] In Figure 7 , the network node 740 is shown as determining 741 an update schedule indicating when each IoT device will receive its corresponding update data. However, in some embodiments, this determination may also be performed by the network operator 720. The network operator may, for example, determine the schedule and relay it to the network node, or instruct the network node 740 to determine the schedule.

[0103] The network operator 720 may further instruct 742 at least one network node to update the IoT device with the cached corresponding update data according to the update schedule and the update process. In Figure 7 , the network node 740 performs 741 a firmware update on the IoT device.

[0104] The network node 740 may then be instructed by the network operator 720 to collect information 744 related to unsuccessful updates and notify the device owner 710 of the collected information and the unsuccessful and successful updates performed, possibly with the network operator 720 as an intermediary (compared to steps 551 - 554 of method 500 and steps 602 - 605 of method 600).

[0105] As described in methods 5 and 6, some embodiments herein enable network operators to receive information about vulnerable IoT devices lacking proper firmware updates. Therefore, network operators can block IoT devices 722 that have been marked as vulnerable (compared to step 541 of method 500). Network nodes can, for example, instruct network nodes to block vulnerable IoT devices from communicating with the network until they have received (and / or successfully installed) the required update data.

[0106] Then, once network node 740 has determined that the blocked IoT device has successfully updated the required firmware, network node 740 can unblock the IoT device 743, thereby allowing it to communicate freely with the network again (compared to steps 602-605 in method 600).

[0107] Therefore, in some embodiments, the device owner can upload firmware, lists, and other necessary information to the network operator via, for example, a Representation State Transition (REST) ​​API.

[0108] Network operators can then further distribute update tasks to eNBs, whose tasks are to schedule device upgrades when they have low load, handle blocking and unblocking, and report errors to eNBs and / or edge nodes associated with these devices. This is to prevent the same firmware from being retrieved repeatedly for each device or from each eNB performing the actual update.

[0109] Some of the embodiments described herein can be further implemented as network cloud implementations.

[0110] In some embodiments, authentication of IoT device owners is envisioned to be accomplished via the same interface and IoT device subscription used to manage IoT devices. That is, the network operator and device owner have an existing trust setup that can be automated via network / cloud services.

[0111] In some embodiments, the firmware upgrade service can be distributed to the operator from the device owner as a container or virtual machine (VM). The VM / container can contain all the components and configurations required to update devices owned by the device owner. Details regarding how to start and run the VM and configure it can be specified by the device owner. How to run VMs and containers is fairly standardized and can be done according to common and known methods. This provides portability across the operator's network, isolation from normal network operations, and security for the upgrade (the original firmware, keys, and processes used for the upgrade) against tampering or access by entities that should not have access to it.

[0112] The upgrade package can then be removed from the system from the VM or container (possibly in a secure container variant) to ensure it is not misused at a later stage.

[0113] In some embodiments, the operator-provided firmware update service can be integrated with the device manufacturer's CI / CD process via a REST (or similar) interface provided by the network operator. This allows the entire process to be automated efficiently, providing network operators and device manufacturers / owners with a streamlined and more modern way to deploy software / firmware to IoT devices.

[0114] Cloud-based implementations offer smaller companies a way to scale their businesses in a more cloud-native manner, allowing them to sell their devices without investing heavily in infrastructure to manage updates, and shortening delivery cycles for commissioning activities given the increasing volume of information and collaboration with network operators. Given that IoT devices should ideally be sold globally for cost-effectiveness, this service would facilitate testing across many different carriers and network configurations, eliminating the need for device owners to invest in large test setups for their firmware testing.

[0115] It is conceivable that operators could provide special test nodes where IoT device owners could place some devices for early testing, thereby further reducing the risk of disrupting live networks.

[0116] Figure 8 The illustration depicts a computer program product including a non-transitory computer-readable medium 800, wherein the non-transitory computer-readable medium 800 stores a computer program including program instructions. The computer program is configured to be loaded into a data processing unit 810, which includes a processor (PROC) 830 and a memory (MEM) 820 associated with or integrated into the data processing unit. When loaded into the data processing unit 810, the computer program is configured to be stored in the memory 820, wherein when the computer program is loaded into the processor 830 and executed by the processor 830, the computer program is configured to cause execution according to the combination Figure 5-7 The method steps of any of the methods described.

[0117] Figure 9 The illustration shows an arrangement of a network operator controller 900 for managing multiple IoT devices associated with an Internet of Things (IoT) device owner and connected to a wireless network, according to some embodiments. For example, the device may be included in a network operator server. For example, as in conjunction with the preceding... Figure 3-8 Any of the network operator servers described. Device 900 can be configured to perform combined... Figure 5-7Any method described herein. In some embodiments, the device 900 may be included in a network node, for example, as in conjunction with Figure 3-8 The network node. In some embodiments, device 900 may be included in an IoT device owner server, for example, in conjunction with... Figure 3-8 The described device owner server.

[0118] The apparatus 900 may include a control circuit 910 (CNTR) configured to receive a list of IoT devices scheduled for firmware updates, wherein the list indicates corresponding update data and an update procedure for each IoT device in the list. The control circuit 910 may be configured to determine at least one network node serving a geographic area covering the corresponding location of each IoT device in the list and caching the corresponding update data. The control circuit 910 may be configured to determine an update schedule indicating when each IoT device will receive its corresponding update data, and for each IoT device scheduled for an update, to instruct at least one network node to update the IoT device using the cached corresponding update data according to the update schedule and update procedure.

[0119] In some embodiments, the update schedule is based on at least one network condition, and the at least one network condition relates to at least one or more of the following: expected network load, expected load from network users, usage of the internal transport network, compute nodes, timing, IoT device sequence, IoT device activity, and IoT device priority.

[0120] In some embodiments, the control circuit 910 is configured to cache the corresponding update data at a central network server, and / or to instruct at least one network node to cache the corresponding update data.

[0121] In some embodiments, and as Figure 9 As shown, device 900 may also include a programming API module 911. The API can be used / accessed by the device owner to access some embodiments described herein and may include binary components and specifications (e.g., a device list) for upgrades.

[0122] The device 900 may also include a GUI module 912. GUI 912 can provide the same interface as a programming API in GUI form for exploration and manual interaction. It can also provide status and progress, as well as task management, in a more user-friendly manner.

[0123] In some embodiments, the control circuitry 910 may be configured to enable the API module 911 and / or the GUI module 912 to provide a list of IoT devices to be updated and the associated firmware upgrade and update process.

[0124] In some embodiments where the list of IoT devices includes another list of vulnerable IoT devices, the control circuitry 910 may be configured to instruct at least one network node to block vulnerable IoT devices from communicating with the network until they have received the required update data.

[0125] The device 900 may also include an authentication service module (CONF) 913. The authentication service can verify whether the device owner (and its server) is the person they claim to be (compared to step 711 of method 700).

[0126] The device 900 may also include an Authorization Service Module (AUT) 916. The Authorization Service 916 may be configured to check whether the device owner is authorized to do what it requests.

[0127] The device 900 may also include a log service module (LOG) 919. The log service 919 can be configured to collect, filter, translate, etc., logs from the system so that the device owner can understand how their device is performing.

[0128] In some embodiments, the control circuit 910 may be configured to cause the log service module 919 to collect information associated with the update indicating the reason for the failure to update when an IoT device in the determined list fails to update successfully, and the control circuit 910 may be configured to notify the IoT device owner of the collected information.

[0129] The device 900 may also include an update process module (PROC) 914. The update process can be configured to perform an actual update of the device. Therefore, it may result in blocking and unblocking, rolling upgrades, restarting, ensuring a certain percentage of devices are always operational, etc. Thus, in some embodiments, the control circuitry 910 may be configured to cause the update process module 914 to include an update process that includes information indicating at least one process for performing a firmware update and at least one process for determining whether the firmware update was successfully performed.

[0130] The device 900 may also include an update scheduling module (SCHED) 917. The update scheduling can be configured to determine when and how to update the device with additional degrees of flexibility for network optimization to reduce upgrade completion time.

[0131] In some embodiments, the control circuit 910 may be configured to (e.g., by causing the update scheduling module 917) instruct at least one network node to instruct the IoT device to remain active for the entire duration of receiving corresponding update data according to the update schedule, and to return to the default sleep cycle when the firmware update is complete.

[0132] In some embodiments, the control circuit may be configured to, for example, by causing the update scheduling module 917 and / or the update process module 914 to instruct at least one network node to push the required update data to the blocked vulnerable IoT device according to the update schedule, and to determine whether the vulnerable IoT device has been successfully updated based on the update process.

[0133] In some embodiments, the control circuit 910 may be configured to notify the IoT device owner server of any unsuccessful update, instruct at least one network node to unblock the vulnerable IoT device, and notify the IoT device owner of a successful update when it is determined that the vulnerable IoT device has succeeded.

[0134] In some embodiments, the control circuit 910 may be configured to, for example, determine whether an IoT device in the list has been successfully updated according to the update schedule by causing the update scheduling module 917 and / or the update process module 914 to determine based on the update process, and notify the IoT device owner of any unsuccessful or successful updates.

[0135] The device 900 may also include a location and debugging service module (DEBUG) 920. The location and debugging service can be configured to help device owners locate and debug their devices.

[0136] The device 900 may also include a storage module (MEM) 923. The storage can be configured to store new and old firmware versions for upgrades and rollbacks.

[0137] The device 900 may also include a distribution and caching module (DIST) 915. The distribution and caching module can be configured to determine where to cache firmware (which edge data centers, compute nodes, eNBs, network nodes, gNBs, etc.) to keep the load on the network to a minimum.

[0138] The device 900 may also include a Laboratory Services Module (LAB) 918. The Laboratory Services module can be configured to provide device owners with the possibility of accessing a limited set of devices in a network operator's laboratory setup. It may have extended / additional debugging and logging capabilities, such as device logging or power consumption measurement.

[0139] Device 900 may also include a Network Usage and Stability Characteristics module (NETW) 921. The Network Usage and Stability Characteristics module can be an internal service of the operator and is configured to ensure that devices providing network services are served without causing interference. It can be configured to examine data usage, data usage patterns, and the number and location of devices present in the network. It can be further configured to help determine how to update and expand IoT services / networks and predict future usage. The Network Usage and Stability Characteristics module allows operators to gain a deeper understanding of how their networks are being used, rather than simply acting as a bit pipe for communication between device owners and IoT devices.

[0140] The device 900 may also include a physical resource module (PHYS) 922. The physical resource can be configured to include references to all physical resources used for services such as eNBs, labs, networks, servers, etc.

[0141] Because all management of IoT devices is preferably fully automated, it can be done “anywhere,” thus shifting the responsibility from device owners to network operators. The update process can be packaged with cloud technologies (such as virtual machines (VMs) or containers, or a combination of these technologies) and delivered to network operators. Alternatively, using standardized (or de facto standard) methods for firmware updates, it is more effort for operators to provide services for different standard methods of firmware updates.

[0142] Update services may include upgrade components from a third party, which could be a partner implementing the device. This depends on how the different parts of the device are combined. IoT devices typically consist of a processor that performs tasks designed for the device and a modem for communication. Upgrading the modem component may require tools provided by the modem vendor and then used by the device owner. These external components may require additional components / steps to be updated.

[0143] Because IoT device use cases and solutions / implementations vary greatly, upgrade services are preferably pluggable and highly flexible in order to serve as many different device owners as possible.

[0144] As an alternative to rolling out new firmware from network nodes, one possibility is to partially push the firmware to the network (from the entity that created it) and then let the devices pull the firmware and update it when they are ready.

[0145] In some embodiments, the device 900 may be included in a network node. In some embodiments, the device may be included in a network operator server. In some embodiments, the network operator server may be a network node and / or a central server.

[0146] The embodiments described herein offer several advantages. For example, for IoT device developers / owners (using 3GPP standards), the network is no longer a black box, as device manufacturers / owners can now better understand the connectivity process and assist in debugging and development, as well as leveraging the network (operator's) knowledge and infrastructure, rather than simply knowing where the device is in the operator's network and working point-to-point with each device.

[0147] The embodiments described herein also enhance security because the window between discovering and releasing fixes for security vulnerabilities / critical bugs is closed or significantly reduced. Furthermore, in many cases, devices considered to have insecure firmware versions may not be permitted to communicate and / or operate.

[0148] Another advantage is the potential power savings for IoT devices, as they do not communicate while awaiting updates. Potential power savings can also be achieved because the network can schedule firmware updates and the specific services that constitute the updates in a timely manner.

[0149] Another advantage is that it makes the rollout smoother by potentially reducing the time required to fully roll out new firmware, as the work is distributed to network operators who can distribute it closer to the edge / eNB serving IoT devices.

[0150] Because the network can better schedule updates during periods of low load and better ensure connectivity, the success rate of updates can be further improved.

[0151] The embodiments described herein allow for faster problem identification and correction due to more detailed logs from the network side, as the physical location of the device can be attached to the logs when upgrades / updates fail to help fix non-working devices.

[0152] Furthermore, network operators have better control over network load planning because they can manage the timing of updates. Firmware upgrades / updates are typically much larger than normal operations and occur in the opposite direction (i.e., from the network to the device).

[0153] The embodiments described herein increase the scalability for IoT device owners without incurring costs for the device owners themselves, because the network infrastructure can be used to distribute firmware instead of repeatedly obtaining the same firmware over and over again.

[0154] The load on the carrier network is reduced in the same way because the firmware is cached closer to the device.

[0155] The embodiments described herein can also reduce the risk of network interference caused by faulty firmware upgrades in IoT devices.

[0156] The described embodiments and their equivalents can be implemented in software or hardware or a combination thereof. They can be executed by general-purpose circuitry associated with or integrated into communication devices, such as digital signal processors (DSPs), central processing units (CPUs), coprocessor units, field-programmable gate arrays (FPGAs) or other programmable hardware, or by special-purpose circuitry such as application-specific integrated circuits (ASICs). All of these forms are considered to be within the scope of this disclosure.

[0157] Various embodiments may appear in electronic devices (such as wireless communication devices) that include circuitry / logic or perform methods according to any embodiment. For example, the electronic device may be a portable or handheld mobile radio communication device, a mobile radio terminal, a mobile phone, a base station, a base station controller, a pager, a communicator, an electronic manager, a smartphone, a computer, a laptop computer, a USB flash drive, a memory card, an embedded drive, or a mobile gaming device.

[0158] According to some embodiments, a computer program product includes a computer-readable medium, such as, for example, a floppy disk or CD-ROM. The computer-readable medium may store a computer program including program instructions thereon. The computer program may be loaded into a data processing unit, which may, for example, be included in a mobile terminal. When loaded into the data processing unit, the computer program may be stored in a memory associated with or integrated into the data processing unit. According to some embodiments, when the computer program is loaded into and executed by the data processing unit, the computer program can cause the data processing unit to perform, for example... Figure 5-6 Method steps of any of the methods shown.

[0159] This document references various embodiments. However, those skilled in the art will recognize that many variations of the described embodiments will still fall within the scope of the claims. For example, the method embodiments described herein describe example methods by way of method steps performed in a particular order. However, it should be understood that these sequences of events may occur in another order without departing from the scope of the claims. Furthermore, some method steps may be performed in parallel, even if they have been described as being performed sequentially.

[0160] Similarly, it should be noted that the division of functional blocks into specific units in the description of the embodiments is not limiting. Rather, these partitions are merely examples. A functional block described herein as a single unit can be divided into two or more units. In the same manner, without departing from the scope of the claims, a functional block described herein as implemented as two or more units can be implemented as a single unit.

[0161] Where appropriate, any feature of any embodiment disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment may be applied to any other embodiment, and vice versa.

[0162] Therefore, it should be understood that the details of the described embodiments are for illustrative purposes only and are not intended to be limiting. Rather, all variations falling within the scope of the claims are intended to be included therein.

Claims

1. A method for managing multiple IoT devices associated with an Internet of Things (IoT) device owner and connected to a wireless network, the method comprising: - The network operator controller receives (510) a list of IoT devices scheduled for firmware updates, wherein the list indicates the corresponding update data and update process for each IoT device in the list; - The network operator controller determines (520, 721) at least one network node serving a geographic area covering the corresponding location of each IoT device in the device list; - The network operator controller causes the cache (530, 723a, 723b) to update the corresponding data. - An update schedule, determined by the network operator controller (540, 741), instructs each IoT device when it will receive its corresponding update data, wherein the update schedule is based on at least one network condition; and - The network operator controller instructs (550) the at least one network node to update the IoT device using the corresponding update data cached according to the update scheduling and update process; The update process includes information indicating at least one process for performing the firmware update and at least one process for determining whether the firmware update was successfully performed; The IoT device list includes a further list of vulnerable IoT devices, and the method further includes: - Instruct (541, 722) that at least one network node prevents the vulnerable IoT device from communicating with the network until the vulnerable IoT device has received the required update data; - Instruct (601, 742) that at least one network node pushes the required update data to the blocked vulnerable IoT device according to the update schedule, and determine (602) whether the vulnerable IoT device has been successfully updated based on the update process; - Notify the IoT device owner server of any unsuccessful updates (605, 744); collect information related to the reasons for the update failure and notify the IoT device owner server of the collected information; - When it is determined that the vulnerable IoT device has been successfully updated, instruct (603, 743) the at least one network node to unblock the vulnerable IoT device; and - Notification (604, 744) indicates that the IoT device owner server has been successfully updated.

2. The method according to claim 1, further comprising: - Instructs the at least one network node to instruct the IoT device to remain active for the entire duration of receiving the corresponding update data according to the update schedule, and to return to the default sleep cycle when the firmware update is complete.

3. The method according to claim 1, wherein, The at least one network condition relates to at least one or more of the following: expected network load, expected load from network users, usage of the internal transport network, computing nodes, timing, IoT device sequence, IoT device activity, and IoT device priority.

4. The method according to claim 1, wherein, The corresponding update data in the cache (530, 723a, 723b) includes: caching the corresponding update data at the central network server and / or instructing the at least one network node to cache the corresponding update data.

5. The method of claim 1, further comprising: - Based on the update process, determine (507) whether the IoT devices in the list have been successfully updated according to the update schedule; as well as - Notifications (508, 510, 744) to the IoT device owner regarding any unsuccessful or successful updates.

6. The method according to claim 5, wherein, When it is determined that the IoT devices in the list have failed to update successfully, the method further includes: - Collect information associated with the update and indicating the reason for the failure to update successfully (509); and - Notification (510, 744) states the information collected by the IoT device owner.

7. The method according to claim 1, wherein, The at least one network node is a base station or a computing node.

8. A computer program product comprising a non-transitory computer-readable medium (800), wherein, The non-transitory computer-readable medium (800) has stored thereon a computer program including program instructions, wherein the computer program is configured to be loaded into a data processing unit (810), the data processing unit including a processor (830) and a memory (820) associated with or integrated into the data processing unit, wherein, when loaded into the data processing unit (810), the computer program is configured to be stored in the memory (820), wherein, when loaded into the processor (830) and run by the processor (830), the computer program is configured to cause the execution of the steps of the method according to claim 1.

9. A network operator controller apparatus (900) for managing a plurality of IoT devices associated with an Internet of Things (IoT) device owner and connected to a wireless network, the apparatus including control circuitry (910) configured to: - Receive a list of IoT devices scheduled for firmware updates, where... The list indicates the corresponding update data and update process for each IoT device in the list; - Identify at least one network node serving a geographic area corresponding to the location of each IoT device covering the list of devices; - The corresponding updated data is cached; - Determine an update schedule that indicates when each IoT device receives its corresponding update data, wherein the update schedule is based on at least one network condition; as well as - For each IoT device scheduled for the update, the at least one network node is instructed to update the IoT device using the corresponding update data cached according to the update scheduling and update process; The update process includes information indicating at least one process for performing the firmware update and at least one process for determining whether the firmware update was successfully performed; The list of IoT devices includes a further list of vulnerable IoT devices, and the control circuitry is configured to cause: - Instruct the at least one network node to block the vulnerable IoT device from communicating with the network until the vulnerable IoT device has received the required update data; - Instruct the at least one network node to push the required update data to the blocked vulnerable IoT device according to the update schedule, and determine whether the vulnerable IoT device has been successfully updated based on the update process; - Notify the IoT device owner server of any unsuccessful updates; collect information related to the reasons for update failures and notify the IoT device owner server of the collected information; - When it is determined that the vulnerable IoT device has been successfully updated, instruct the at least one network node to unblock the vulnerable IoT device; and - Notify the owner of the IoT device that the server has successfully updated.

10. The apparatus according to claim 9, wherein, The control circuit (910) is further configured to cause - Instructs the at least one network node to instruct the IoT device to remain active for the entire duration of receiving the corresponding update data according to the update schedule, and to return to the default sleep cycle when the firmware update is complete.

11. The apparatus according to claim 9, wherein, The at least one network condition relates to at least one or more of the following: expected network load, expected load from network users, usage of the internal transport network, computing nodes, timing, IoT device sequence, IoT device activity, and IoT device priority.

12. The apparatus according to claim 9, wherein, The control circuit is configured to cause caching of the corresponding updated data at a central network server and / or to instruct at least one network node to cache the corresponding updated data.

13. The apparatus according to claim 9, wherein, The control circuit is configured to cause: - Based on the update process, determine (507) whether the IoT devices in the list have been successfully updated according to the update schedule; and - Notify the owner of the IoT device of any unsuccessful or successful updates.

14. The apparatus according to claim 13, wherein, When it is determined that an IoT device in the list has failed to update successfully, the control circuit is further configured to cause: - Collect information about why the indication associated with the update failed to update successfully; and - Inform the owner of the IoT device of the information collected.

15. A network node comprising the apparatus according to claim 9.

Images