Device upgrade
By managing the equipment to allocate upgrade package distribution links and available bandwidth to each site, the problem of unreasonable IoT device upgrades in large-scale system integration projects is solved, realizing intelligent device upgrades and ensuring business stability.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- HANGZHOU HIKVISION SYST TECH CO LTD
- Filing Date
- 2025-12-31
- Publication Date
- 2026-07-09
Smart Images

Figure CN2025147707_09072026_PF_FP_ABST
Abstract
Description
Equipment upgrade Technical Field
[0001] This application relates to the field of Internet of Things (IoT) platform technology, and in particular to methods for upgrading IoT devices, as well as corresponding apparatus, devices, storage media, and systems. Background Technology
[0002] Many large-scale system integration projects require a Device Management Platform (DMP) capable of providing unified remote software upgrades for a large number of IoT devices. Examples include firmware upgrades, operating system upgrades, and application upgrades. Summary of the Invention
[0003] In view of the above, this application provides a device upgrade method, apparatus, equipment, storage medium and system.
[0004] According to a first aspect of the embodiments of this application, a device upgrade method is provided, applied to a management device for managing devices under at least one Internet of Things (IoT) site, comprising: for any site, determining the number of upgrade package distribution links for that site, wherein the upgrade package distribution links are used to distribute upgrade packages to devices under that site; determining the upgrade available bandwidth of that site; determining the upgrade available bandwidth of each device under that site to be upgraded based on the upgrade available bandwidth of that site and the number of upgrade package distribution links of that site; and upgrading each device under that site to be upgraded based on the upgrade available bandwidth of each device under that site.
[0005] According to a second aspect of the embodiments of this application, a device upgrade apparatus is provided, applied to a management device for managing devices under at least one Internet of Things (IoT) site, and includes: a first determining unit configured to determine, for any site, the number of upgrade package distribution links for that site, wherein the upgrade package distribution links are used to distribute upgrade packages to devices under that site; a second determining unit configured to determine the upgrade available bandwidth of that site; a third determining unit configured to determine the available bandwidth of each device under that site to be upgraded based on the upgrade available bandwidth of that site and the number of upgrade package distribution links of that site; and an upgrade unit configured to upgrade each device under that site based on the upgrade available bandwidth of each device under that site.
[0006] According to a third aspect of the embodiments of this application, an electronic device is provided, including one or more processors and one or more memories. The one or more memories are used to store computer programs and communicate with the one or more processors via a communication bus; when the one or more processors execute the computer programs stored in the one or more memories, they implement the method provided in the first aspect.
[0007] According to a fourth aspect of the embodiments of this application, a non-transitory computer-readable storage medium is provided, wherein a computer program is stored in the non-transitory computer-readable storage medium, and the computer program implements the method provided in the first aspect when executed by a processor.
[0008] According to a fifth aspect of the embodiments of this application, a device upgrade system is provided, including an electronic device provided in the third aspect and subordinate devices connected to the electronic device in at least one Internet of Things site.
[0009] According to embodiments of this disclosure, by determining the available upgrade bandwidth for each device under a site based on the site's available upgrade bandwidth and the number of links to which upgrade packets are sent, and then upgrading the devices accordingly, independent upgrade rate limiting for each site's downlink bandwidth bottleneck is effectively achieved. Since the bandwidth of the DMP central server is relatively ample, but the downlink bandwidth of each site is usually limited, compared to the implementation method of unified rate limiting at the DMP central server egress, the embodiments of this disclosure improve the rationality of upgrade rate limiting in DMP scenarios by independently implementing upgrade rate limiting for each site's downlink bandwidth bottleneck.
[0010] Furthermore, by determining the available bandwidth for each site's upgrade and generating and executing rate-limiting upgrade strategies based on the number of links to which upgrade packages are distributed for each site, intelligent rate-limiting upgrades can be effectively achieved while ensuring the stability of normal business operations. Attached Figure Description
[0011] Figure 1A is a schematic diagram of the architecture of an upgrade system provided in an embodiment of this application;
[0012] Figure 1B is a schematic flowchart of a device upgrade method provided in an embodiment of this application;
[0013] Figure 1C is a schematic diagram of a process for determining the number of links for issuing upgrade packages to a site, according to an embodiment of this application.
[0014] Figure 2 is a schematic diagram of a site example provided in an embodiment of this application;
[0015] Figure 3 is a schematic diagram of a site example provided in an embodiment of this application;
[0016] Figure 4 is a flowchart illustrating a device intelligent current limiting upgrade method provided in an embodiment of this application;
[0017] Figure 5 is a schematic diagram of a site example provided in an embodiment of this application;
[0018] Figure 6 is a schematic diagram of channel aggregation of binocular / multi-camera IPCs provided in an embodiment of this application;
[0019] Figure 7 is a schematic diagram of an upgrade package file download provided in an embodiment of this application;
[0020] Figure 8 is a schematic diagram of data reading based on a token bucket according to an embodiment of this application;
[0021] Figure 9 is a schematic diagram of a device upgrade apparatus provided in an embodiment of this application;
[0022] Figure 10 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0023] To enable those skilled in the art to better understand the technical solutions provided in the embodiments of this application, the system environment applicable to the embodiments of this application will first be described below in conjunction with the system architecture diagram.
[0024] Please refer to Figure 1A, which is a schematic diagram of the architecture of a device upgrade system provided in an embodiment of this application. As shown in Figure 1A, the system may include a management device 100 and one or more sites 200-1, 200-N (hereinafter collectively referred to as sites 200).
[0025] The management device 100 can be a network device or computing resource that has been deployed and is running specified management software. This specified management software integrates core capabilities such as site management, device management, and Device Upgrade Service (DUS). The form of the management device 100 is not limited and can include, but is not limited to, virtualized resources (such as virtual machines or container instances on a cloud platform), dedicated hardware servers, high-performance computing nodes or clusters, edge computing devices, or all-in-one machines.
[0026] According to one example of this disclosure, management device 100 can be deployed in the cloud or data center as shown in Figure 1A to uniformly manage multiple sites 200 and their subordinate devices 220. It should be noted that Figure 1A only shows a logical structure of management device 100 and each site 200-1…200-N and their subordinate devices 220, and does not intend to limit management device 100 to a physical device independent of each site 200. In fact, those skilled in the art should understand that with the development of distributed network technology, especially decentralized technology, management device 100 can be deployed at a site, such as site 200-1, as long as site 200-1 can establish a reliable communication connection with any other site, such as site 200-N. For ease of description, the following description will mainly be based on the network architecture shown in Figure 1A. Specifically, management device 100 can manage the device topology, service configuration, and site bandwidth thresholds of each site 200, and generate intelligent upgrade strategies accordingly. Then, the management device 100, with its built-in DUS module, is specifically responsible for distributing upgrade packages based on the generated intelligent upgrade strategy, thereby effectively achieving precise flow control based on the site.
[0027] Site 200, as the basic management unit of management device 100, is essentially a collection of devices sharing the same egress bandwidth resources. As shown in Figure 1A, this collection of devices 200 includes multiple IoT devices 220, which access management device 100 through site router (hereinafter referred to as router) 210 and share the egress bandwidth resources of router 210. This collection of devices 200 can encompass the IoT devices 220 required to complete their business within a specific area (such as a park, an intersection, or a subway station hall), including but not limited to front-end devices (such as Internet Protocol Cameras, IPCs), back-end devices (such as Network Video Recorders, NVRs), video analytics servers (VAs), switches, or other sensors (such as environmental monitoring sensors).
[0028] For example, the site 200 managed by the management device 100 may include sites of various scene types, such as HDB indoor scenes, HDB outdoor scenes, street scenes, subway station scenes, or highway ramp scenes.
[0029] In this system architecture, the management device 100 communicates with the routers 210 of each site 200 via a wide area network (WAN), while the various subordinate devices within the site 200 (i.e., the aforementioned IoT devices 220) are interconnected via a local area network (LAN) and access the router 210 of that site 200. According to the examples of this disclosure, the IoT devices 220 can be directly accessed by the router 210 as shown in FIG1A, or they can be accessed by the router 210 via a switch as shown in FIG5.
[0030] In other words, for each site 200, the IoT devices 220 within that site 200 can be directly or indirectly connected to the router 210. For example, as shown in sites 200-2 and 200-N of Figure 5, IoT devices 220 such as IPCs, NVRs, and VAs can be directly connected to the router 210; or, as shown in sites 200-1, 200-2, and 200-N of Figure 5, IoT devices 220 such as IPCs, NVRs, and VAs can be connected to the router 210 through other IoT devices 220, meaning that one or more other IoT devices and / or switches 230 are interposed between the lowest-level IoT devices 220 and the router 210. For example, in site 200-2, IPC 220 is connected to NVR 220, and NVR 220 is connected to router 210; or, in sites 200-1 and 200-2, IoT device 220 can be connected to router 210 through switch 230, and one or more other IoT devices can be spaced between the lowest-level IoT device 220 and switch 230.
[0031] For example, management device 100 can automatically discover IoT devices 220 in the local area network where site 200 is located through protocols such as device discovery protocol, device search protocol, multicast protocol or NETMAP (high-performance network packet I / O (input / output) framework) protocol.
[0032] Based on the above architecture, the management device 100 uses the site 200 as the basic management unit to perform policy calculations and resource allocation, thereby realizing intelligent rate limiting upgrades for sites.
[0033] To make the above-mentioned objectives, features and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be further described in detail below with reference to the accompanying drawings.
[0034] It should be noted that the sequence number of each step in the embodiments of this application does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0035] Please refer to Figure 1B, which is a flowchart illustrating a device upgrade method provided in an embodiment of this application. This device upgrade method can be applied to a management device that uniformly manages IoT devices at one or more sites, such as the management device 100 shown in Figure 1A. As shown in Figure 1B, the device upgrade method may include the following steps:
[0036] Step S110: For any site, determine the number of upgrade package distribution links for that site; wherein, the upgrade package distribution links are used to distribute upgrade packages to the subordinate devices of that site.
[0037] Among them, the upgrade package distribution link refers to the data channel used to distribute upgrade packages to subordinate devices of the site.
[0038] In one example, the number of upgrade package distribution links for a site can be the same as the number of devices among the site's subordinate devices that have an upgrade package acquisition requirement. That is, each device among the site's subordinate devices that has an upgrade package acquisition requirement corresponds to one upgrade package distribution link.
[0039] In another example, devices within a site that require upgrade packages can be aggregated or grouped. Multiple devices meeting certain conditions (referred to as aggregation conditions) are grouped into a single device group, which corresponds to a device aggregation chain. When a device in this group has a device awaiting upgrade, the device aggregation chain is used as the upgrade package distribution link, and the endpoint of this link depends on the interconnectivity of the devices within the group. For instance, if the device group includes a master device connected to the site's router via a switch or directly connected to the router, and at least one sub-device sharing a port of bandwidth from the router via the master device, the endpoint of the corresponding device aggregation chain as the upgrade package distribution link is the master device.
[0040] As an example, the determination of the number of upgrade package distribution links for the site can be as shown in Figure 1C, including: step S111, dividing the devices under the site into at least one subordinate device group according to predetermined aggregation conditions, wherein each subordinate device group includes at least one device; step S112, determining the device aggregation chain set of the site by assigning a device aggregation chain to any one of the subordinate device groups; and step S113, determining the total number of links in the device aggregation chain set, or the number of links in the device aggregation chain set related to each device to be upgraded, as the number of upgrade package distribution links for the site.
[0041] For example, for multiple subordinate devices that meet the aggregation conditions (which can be referred to as a subordinate device group), the subordinate device group corresponds to a device aggregation chain; for subordinate devices that do not meet the aggregation conditions, each device corresponds to a separate device aggregation chain.
[0042] For example, suppose a site has 5 subordinate devices, of which 3 devices meet the aggregation condition and the remaining 2 devices do not meet the aggregation condition. Then, among the subordinate devices of the site, the 3 devices that meet the aggregation condition correspond to one device aggregation chain; each of the remaining 2 devices corresponds to one device aggregation chain. The site has a total of 3 links in its set of device aggregation chains.
[0043] The aggregation conditions described above can be pre-configured based on the physical topology and / or service type of the devices under the site. For example, the aggregation conditions may include at least one of the following: forming a first subordinate device group with at least one device under the site that shares the bandwidth of a port of the router corresponding to the site; or forming a second subordinate device group with at least one device under the site that has the same device type.
[0044] Each first subordinate device group includes a master device connected to a port of the router and n sub-devices that share the bandwidth of that port of the router via the master device, where n is an integer greater than or equal to 0; and the master device is the endpoint device of the device aggregation chain corresponding to the first subordinate device group when the upgrade package is distributed.
[0045] In one example, if, based on the physical topology of the subordinate devices of a site, it is determined that multiple sub-devices share the bandwidth of a single port of the site's router through the same master device, then the multiple sub-devices and the master device satisfy the aggregation condition. Here, the master device is any device within site 200 other than router 210 that has subordinate devices connected to it, and these subordinate devices are also referred to as sub-devices of the master device; that is, the two constitute a master-sub-device relationship.
[0046] For example, the physical topology of each subordinate device at a site can be determined using SNMP (Simple Network Management Protocol), LLDP (Link Layer Discovery Protocol), and MAC (Media Access Control) address learning tables.
[0047] For example, SNMP can be used to obtain interface information of switches and routers (including interface status, description, and MAC address); LLDP can be used to obtain physical connection information between devices and their neighbors from the device's neighbor table; and the connection location of devices can be further confirmed using the switch's MAC address learning table. By summarizing the data obtained through SNMP, LLDP, and MAC address learning tables, a physical topology map can be constructed.
[0048] For example, interface information can be obtained via SNMP, and neighbor device information can be obtained via LLDP to establish connections between switches, routers, and hosts. The physical port mapping relationships of devices can be further confirmed using MAC address learning tables and LLDP data. It should be noted that if the topology obtained through the protocol is incomplete, topology nodes and relationships can be added manually.
[0049] For example, when multiple devices within a site are connected to the same device other than the site's router, these multiple devices can be referred to as sub-devices, and the same device to which they are all connected can be referred to as the master device. The multiple sub-devices and the master device satisfy the aggregation condition. The master and sub-devices are interconnected through internal connections (such as a local area network), and the interaction between the master and sub-devices does not consume the bandwidth of the site's router.
[0050] In one embodiment, when multiple IPCs are connected to the same NVR, these IPCs can be referred to as sub-devices, and the NVR can be referred to as the master device. The NVR and the multiple IPCs satisfy an aggregation condition. In other words, the NVR and the multiple IPCs connected to the NVR constitute a master-sub-device relationship. The NVR is the master device, and the multiple IPCs connected to the NVR are the sub-devices. For the NVR device, the list of sub-device IPCs can be obtained through the NVR interface to determine the topology relationship between the NVR and the IPCs.
[0051] For example, when multiple sensors (such as temperature sensors, humidity sensors, etc.) are connected to the same IoT gateway, these multiple sensors can be called sub-devices, the IoT gateway can be called the master device, and the multiple sensors and the IoT gateway satisfy the aggregation condition.
[0052] For example, when multiple fire sensors are connected to the same fire control panel, the multiple fire sensors can be called sub-devices, the fire control panel can be called the main device, and the multiple fire sensors and the fire control panel meet the aggregation condition.
[0053] For example, in real-world scenarios, there might be multiple sub-devices connected to the same master device via internal connections (such as a local area network), and this master device is connected to a router. For instance, multiple IPCs might be connected to a router and / or switch via the same NVR. In this case, during upgrades of these multiple IPCs, it's not necessary to send upgrade packages to each IPC individually. Instead, the upgrade package is sent to the NVR, which then distributes it to each IPC connected to it via the internal connection. This way, multiple IPCs connected to the site's router via the same NVR do not require separate upgrade packages from the management device.
[0054] Accordingly, when multiple sub-devices share the bandwidth of a single port of the site's router through the same master device, these multiple sub-devices and the master device correspond to the same upgrade package distribution link.
[0055] In one embodiment, multiple sub-devices of a router connected to the site via the same master device belong to the same device aggregation chain; one device aggregation chain corresponds to one upgrade packet distribution link. It is not necessary to send upgrade packets to each sub-device separately; instead, upgrade packets are sent to the master device, which then distributes the upgrade packets to each sub-device connected to it via internal connections. Since the master and sub-devices are interconnected via a local area network (LAN), sending upgrade packets between the master and sub-devices does not consume the site's bandwidth.
[0056] For example, when multiple IPCs are connected to the same NVR, the multiple IPCs and the NVR belong to the same device aggregation chain.
[0057] For example, devices connected to different ports of a router can be grouped into different device aggregation chains.
[0058] For example, as shown in Figure 2, suppose that site 200-1 has 6 IoT devices, including 5 IPC devices 222-1 to 222-5 and 1 NVR 221. Among them, IPC 222-1 to IPC 222-3 are connected to the router 210 of site 200 through NVR 221, and IPC 222-4 and IPC 222-5 are connected to different ports of the router 210 of the site. In site 200-1, IPC 222-1 to IPC 222-3 and the NVR 221 belong to the same device aggregation chain and correspond to one upgrade package distribution link. IPC 222-4 and IPC 222-5 belong to different device aggregation chains and each corresponds to one upgrade package distribution link. In other words, in site 200-1 as shown in Figure 2, router 210 corresponds to three upgrade packet distribution links, namely IPC 222-4, IPC 222-5 and NVR 221.
[0059] It should be noted that when a binocular IPC / multi-camera IPC is directly connected to the site's router, the binocular IPC / multi-camera IPC corresponds to one upgrade package distribution link.
[0060] For example, in an upgrade package distribution link that includes a master device and multiple sub-devices, when the upgrade package is distributed through this upgrade package distribution link, the endpoint device of the upgrade package distribution link is the master device. That is, the upgrade package can be distributed to the master device through this upgrade package distribution link, and the master device distributes the upgrade packages of each sub-device to the corresponding sub-device through internal connections.
[0061] Taking the scenario shown in Figure 2 as an example, for the upgrade package distribution link corresponding to IPC 222-1 to IPC 222-3 and NVR 221, when the upgrade package is distributed through this upgrade package distribution link, the upgrade package can be uniformly distributed to NVR 221, and NVR 221 will distribute the upgrade packages of each IPC 222-1 to 222-3 to the corresponding IPC through internal connection.
[0062] It should be noted that aggregating upgrade package distribution links based on master-slave device relationships is merely a specific and efficient example of determining the number of upgrade package distribution links for a site in this application embodiment, and is not a limitation on the scope of protection of this application. Those skilled in the art will understand that the method for determining the number of upgrade package distribution links in this application embodiment is not limited to this; the number of upgrade package distribution links can also be determined by grouping subordinate devices of a site according to network management policies, device types, or other logical relationships.
[0063] Taking the grouping of subordinate devices of a site according to device type as an example, subordinate devices with the same device type can be identified as subordinate devices that meet the aggregation conditions, that is, subordinate devices of the same type are divided into the same group.
[0064] For example, as shown in Figure 3, suppose that site 200-2 has 5 IoT devices, including 3 IPCs 222-1 to 222-3 and 2 VAs 223-1 to 2232. Then the 3 IPCs can be divided into a group, which will correspond to one upgrade package distribution link; the 2 VAs can be divided into a group, which will correspond to one upgrade package distribution link.
[0065] For example, when grouping subordinate devices of a site according to device type, one group corresponds to one device aggregation chain, and the endpoint device of this device aggregation chain when serving as the upgrade package distribution link can be a designated device. Specifically, the designated device can be a device within the group, or a specific device within the site that has an internal connection with each device in the group. During the upgrade package distribution process via this upgrade package distribution link, the upgrade package can be distributed to the designated device, which then distributes the upgrade package to each device in the group through the internal connection; where the designated device is a device within the group, there is no need to forward the upgrade package for this device itself.
[0066] Step S120: Determine the available bandwidth for the upgrade of the site.
[0067] Step S130: Determine the available upgrade bandwidth for each device to be upgraded under the site based on the available upgrade bandwidth of the site and the number of links for which upgrade packages are sent to the site.
[0068] In this embodiment of the application, after determining the number of upgrade package distribution links and the available upgrade bandwidth of the site in the manner described above, the available upgrade bandwidth of the site can be allocated according to the number of upgrade package distribution links, thereby determining the available upgrade bandwidth of the upgrade package distribution links of the site.
[0069] In one example, the available bandwidth for site upgrades can be evenly distributed to each upgrade package delivery link.
[0070] For example, given the available upgrade bandwidth (P) for a site and the number of links (N) for upgrade package distribution, the available upgrade bandwidth allocated to each upgrade package distribution link can be P / N.
[0071] For example, for any upgrade package distribution link, once the upgrade available bandwidth of the upgrade package distribution link is determined, the upgrade available bandwidth of each device to be upgraded corresponding to the upgrade package distribution link can be determined based on the upgrade available bandwidth of the upgrade package distribution link.
[0072] Step S140: Based on the available bandwidth for upgrading each device under the site, upgrade each device under the site.
[0073] In this embodiment of the application, after determining the available upgrade bandwidth for each device to be upgraded within the site in the manner described above, the devices to be upgraded within the site can be upgraded based on the determined available upgrade bandwidth for each device.
[0074] For example, for any device to be upgraded, during the upgrade process, an upgrade package can be sent to the device through the upgrade package sending link, and the upgrade package sending rate can be controlled according to the available upgrade bandwidth of the device during the upgrade package sending process.
[0075] For example, assuming that the available bandwidth for upgrading a certain device is 8Mbps, the upgrade packet download rate will not exceed 1MB / s during the process of sending the upgrade packet to the device through the upgrade packet download link.
[0076] It should be noted that, in this embodiment of the application, when an upgrade instruction for any subordinate device of the site is detected, the available upgrade bandwidth of each device under the site can be determined in accordance with the manner described in steps S110 to S130 above, and the upgrade can be performed based on the determined available upgrade bandwidth of the device.
[0077] Alternatively, the available upgrade bandwidth for each device under the site can be determined in advance according to the method described in steps S110 to S130. Thus, for any device under any site, if an upgrade is required, the device can be upgraded based on the pre-determined available upgrade bandwidth.
[0078] As can be seen from the method flow shown in Figure 1B, for any given site, on the one hand, the number of upgrade package distribution links for that site is determined; on the other hand, the available upgrade bandwidth for that site is determined. Then, based on the available upgrade bandwidth and the number of upgrade package distribution links for that site, the available upgrade bandwidth for each device under that site can be determined, and each device within that site is upgraded based on the determined available upgrade bandwidth for each device. In this way, since the bandwidth of the DMP central server is relatively ample, but the downlink bandwidth of each site is usually limited, compared to the implementation method of unified rate limiting at the DMP central server egress, this embodiment improves the rationality of upgrade rate limiting in DMP scenarios by independently implementing upgrade rate limiting for the downlink bandwidth bottleneck of each site. Furthermore, by determining the available upgrade bandwidth for each site and generating and executing a rate limiting upgrade strategy based on the number of upgrade package distribution links for each site, intelligent rate limiting upgrades can be effectively achieved while ensuring the stability of normal business operations.
[0079] In some embodiments, determining the number of upgrade package distribution links for the site may include: determining the device aggregation chain to which each device to be upgraded belongs in the site; and determining the number of upgrade package distribution links for the site based on the device aggregation chain to which each device to be upgraded belongs.
[0080] For example, for any site, when counting the number of upgrade package distribution links for that site, the device aggregation links with devices to be upgraded can be counted, while the device aggregation links without devices to be upgraded are not counted. Thus, in the subsequent process of allocating available upgrade bandwidth, only the device aggregation links with devices to be upgraded can be used as upgrade package distribution links to allocate available upgrade bandwidth, so that the device aggregation links without devices to be upgraded do not participate in the allocation of available upgrade bandwidth, thereby improving the rationality of the allocation of available upgrade bandwidth.
[0081] In some embodiments, determining the number of upgrade package distribution links for the site may include: determining the device aggregation chain to which each subordinate device in the site belongs; and determining the number of upgrade package distribution links for the site based on the device aggregation chain to which each subordinate device belongs.
[0082] For example, for any site, in the process of counting the number of upgrade package distribution links for that site, the device aggregation chains of all subordinate devices of that site can be counted. Thus, in the subsequent process of allocating available upgrade bandwidth, the device aggregation chains corresponding to each subordinate device will participate in the allocation of available upgrade bandwidth as upgrade package distribution links, without having to distinguish whether the device aggregation chain corresponds to the device to be upgraded, thereby improving the allocation efficiency of available upgrade bandwidth.
[0083] In some embodiments, determining the upgradeable bandwidth of the site may include: determining the service bandwidth consumption of the site; and determining the upgradeable bandwidth of the site based on the service bandwidth consumption of the site and the bandwidth threshold of the site.
[0084] For example, in order to reduce the impact of equipment upgrades on normal business operations, it is necessary to determine the available bandwidth for equipment upgrades based on the bandwidth required for normal business operations at the site.
[0085] Accordingly, during the batch upgrade of equipment, for any given site, the bandwidth consumption of that site can be determined, and based on that bandwidth consumption and the site's bandwidth threshold, the available bandwidth for the upgrade can be determined.
[0086] For example, the bandwidth threshold for a site can be the bandwidth threshold of the site's router's external wide area network (WAN) port.
[0087] In one example, the total available bandwidth of a site can be determined based on the site's bandwidth threshold and the preset available bandwidth ratio, and the upgrade available bandwidth of the site can be determined based on the total available bandwidth of the site and the site's service bandwidth consumption.
[0088] For example, the upgradeable bandwidth of a site can be the difference between the total available bandwidth of the site and the bandwidth consumed by the site's services.
[0089] For example, based on the site's bandwidth consumption and bandwidth threshold, the available bandwidth for the site's upgrade can be determined as follows: P = M * X% - W
[0090] Where P is the available bandwidth for upgrade, M is the bandwidth threshold, X% is the percentage of available bandwidth (the remaining bandwidth can be used to cope with special situations such as network fluctuations), and W is the bandwidth consumption of site services.
[0091] In some embodiments, determining the service bandwidth consumption of the site may include: collecting the service bandwidth consumption of the router by specifying a bandwidth information collection protocol, and determining the collected service bandwidth consumption as the service bandwidth consumption of the site.
[0092] For any given site, in determining the site's service bandwidth consumption, it can be determined whether the site's router supports protocol-based bandwidth consumption collection, such as whether it supports collecting router bandwidth consumption via SNMP or a proprietary protocol.
[0093] If the router at this site supports protocol-based bandwidth consumption collection, the service bandwidth consumption of the router can be collected by specifying a bandwidth information collection protocol (such as SNMP or a private protocol), and the collected service bandwidth consumption can be determined as the service bandwidth consumption of this site.
[0094] In some embodiments, determining the bandwidth consumption of the site may include: determining the service type of each subordinate device of the site; determining the service set of the site based on the service type of each subordinate device of the site; wherein the service set of the site includes the service types existing at the site and the quantity of each type of service; and determining the bandwidth consumption of the site based on the service set of the site and the preset bandwidth consumption corresponding to each service type.
[0095] For example, the service bandwidth consumption of a site can also be determined based on the service type of each subordinate device of the site and the preset bandwidth consumption corresponding to each service type.
[0096] For example, if the site's router does not support protocol-based bandwidth consumption collection, the site's service bandwidth consumption can be determined based on the service types of each subordinate device at the site and the preset bandwidth consumption corresponding to each service type.
[0097] For any given site, the service type of the subordinate devices can be determined based on the device type of the subordinate devices at that site.
[0098] For example, for any given site, different types of subordinate devices can be pre-defined for their business types.
[0099] For example, for IPC, the corresponding service types can include video streaming preview and image capture.
[0100] In one example, the service type of a subordinate device can be determined based on the scenario type of the site and the device type of the subordinate device.
[0101] For example, for a site with a scenario type of "urban traffic checkpoint", the subordinate devices of the device type IPC can have the following service types: video streaming preview, vehicle photo capture, and vehicle body feature recognition.
[0102] For example, for any given site, the types of services present in the site and the quantity of each type of service can be determined based on the service types of the subordinate devices of the site, thereby determining the service set of the site.
[0103] For any given service type, the bandwidth consumption corresponding to that service type can be preset. Given a set of services for a site, the bandwidth consumption of that site can be determined based on the set of services for that site and the preset bandwidth consumption for each service type.
[0104] For example, suppose a site includes two IPCs and one temperature sensor. The service types corresponding to the IPCs include video streaming preview and image capture, and the service type corresponding to the temperature sensor includes temperature data upload. The preset bandwidth consumption for video streaming preview is 3Mbps per device, the preset bandwidth consumption for image capture is 0.5Mbps per device, and the preset bandwidth consumption for temperature data upload is 0.01Mbps per device. Then the service bandwidth consumption of this site is: (3+0.5)*2+0.01=7.01Mbps.
[0105] It should be noted that, in the process of determining the service set of a site, for devices with multiple channels such as binocular IPCs / multi-camera IPCs, each independent service channel should be counted as an independent service instance.
[0106] For example, a stereo IPC that performs the "video streaming preview" service should be counted as 2 instances of this service type, that is, the number of "video streaming preview" type services corresponding to one stereo IPC is 2.
[0107] For example, suppose a site includes one IPC (default is a monocular IPC), one binocular IPC, and one temperature sensor. The IPC's service types include video streaming preview and image capture, and the temperature sensor's service type includes temperature data upload. The preset bandwidth consumption for video streaming preview is 3Mbps per device, the preset bandwidth consumption for image capture is 0.5Mbps per device, and the preset bandwidth consumption for temperature data upload is 0.01Mbps per device. Then the site's service bandwidth consumption is: (3+0.5)*3+0.01=10.51Mbps.
[0108] In some embodiments, the bandwidth threshold of the site is determined by: obtaining site management information; wherein the site management information includes the bandwidth threshold of each site; and determining the bandwidth threshold of the site based on the site management information.
[0109] For example, the bandwidth threshold of a site can be pre-configured in the management device through batch import.
[0110] For example, network administrators or system maintenance personnel can import a list containing the bandwidth thresholds of the sites managed by the management device as site management information into the management device.
[0111] For example, a list containing the bandwidth thresholds for the sites managed by the management device can be a site management information file, which can record the bandwidth thresholds for each site in a structured format. Administrators can upload this file through the management interface or configuration tools provided by the management device. The management device can determine the bandwidth thresholds for each site by parsing this file.
[0112] It should be noted that, in this embodiment of the application, the bandwidth threshold of the site can also be set manually by relevant personnel. For example, the administrator can navigate to the detailed configuration page of the target site through the graphical management system interface provided by the management device and configure the bandwidth threshold of the site on the configuration page.
[0113] For example, the above batch import method can be combined with manual settings. Batch import is used for large-scale, standardized initial deployments or batch updates, while manual settings are used for special adjustments to individual sites, temporary site configurations, or small-scale operation and maintenance scenarios, ensuring that management strategies can cover various actual operation and maintenance needs.
[0114] In some embodiments, determining the upgrade-available bandwidth of each device to be upgraded at a site based on the site's upgrade-available bandwidth and the number of upgrade package distribution links at the site may include: determining the upgrade-available bandwidth of each upgrade package distribution link at the site according to a pre-configured first upgrade bandwidth allocation strategy for the site, based on the site's upgrade-available bandwidth and the number of upgrade package distribution links at the site; wherein the first upgrade bandwidth allocation strategy indicates the allocation of upgrade-available bandwidth among upgrade package distribution links in the site; for any upgrade package distribution link, determining the upgrade-available bandwidth of each upgrade package corresponding to that upgrade package distribution link according to a pre-configured second upgrade bandwidth allocation strategy, based on the upgrade-available bandwidth of that upgrade package distribution link; wherein the second upgrade bandwidth allocation strategy indicates the allocation of upgrade-available bandwidth among each upgrade package in the same upgrade package distribution link in the site.
[0115] For example, for any site, an upgrade bandwidth allocation strategy (which may be called the first upgrade bandwidth allocation strategy) can be configured according to the needs of the upgrade package distribution links in the site, and upgrade available bandwidth can be allocated to each upgrade package distribution link in the site according to the first upgrade bandwidth allocation strategy.
[0116] For example, the first upgrade bandwidth allocation strategy includes an equal allocation strategy or a priority weight allocation strategy.
[0117] In one example, if the first upgrade bandwidth allocation strategy is an equal distribution strategy, the available upgrade bandwidth of the site can be evenly distributed to each upgrade package delivery link to obtain the upgrade available bandwidth of each upgrade package delivery link.
[0118] Taking the equal distribution strategy for site upgrade bandwidth allocation as an example, the available upgrade bandwidth of the site can be evenly distributed to each upgrade package delivery link.
[0119] For example, taking the scenario shown in Figure 2 as an example, this scenario includes 3 upgrade package distribution links, one corresponding to IPC 222-1 to IPC 222-3 and NVR 221, another corresponding to IPC 222-4, and the last corresponding to IPC 222-5. When the upgrade bandwidth allocation strategy of this site is an equal distribution strategy, the upgrade available bandwidth of each upgrade package distribution link is P / 3; where P is the upgrade available bandwidth of this site.
[0120] In one example, when the first upgrade bandwidth allocation strategy is a priority weight allocation strategy, the upgrade available bandwidth of the site can be allocated to each upgrade package distribution link according to the priority weight of each upgrade package distribution link, so as to obtain the upgrade available bandwidth of each upgrade package distribution link.
[0121] For example, different priority weights can be assigned to the links of different upgrade packages according to device type, service type, etc., and upgrade available bandwidth can be allocated to the links of different upgrade packages according to the priority weights of the links of each upgrade package.
[0122] For example, taking the scenario shown in Figure 3, this scenario includes two upgrade package distribution links. The first upgrade package distribution link corresponds to three IPCs 222-1 to 222-3, and the second upgrade package distribution link corresponds to two VAs 223-1 and 223-2. These IPCs 222-1 to 222-3 carry real-time video streaming services, while VAs 223-1 and 223-2 carry non-real-time intelligent analysis services. The real-time video streaming service has a higher priority and is allocated 70% of the upgrade bandwidth (priority weight 0.7); the non-real-time intelligent analysis service has a lower priority and is allocated 30% of the upgrade bandwidth (priority weight 0.3). Therefore, the available upgrade bandwidth for the first upgrade package distribution link is 0.7P, and the available upgrade bandwidth for the second upgrade package distribution link is 0.3P; where P is the available upgrade bandwidth for that site.
[0123] For example, for any upgrade package distribution link, the upgrade-available bandwidth of each upgrade package corresponding to that upgrade package distribution link can be determined according to the pre-configured second upgrade bandwidth allocation strategy, based on the upgrade-available bandwidth of that upgrade package distribution link. Here, the upgrade-available bandwidth of an upgrade package refers to the available bandwidth during the process of obtaining the upgrade package through the upgrade package distribution link.
[0124] The second upgrade bandwidth allocation strategy can include single-path rate limiting or multi-path rate limiting. For example, the upgrade package distribution links for the same site can be uniformly configured to use a single path, or uniformly configured to use multi-path rate limiting.
[0125] Under the second upgrade bandwidth allocation strategy of single-path rate limiting, the upgrade package for one device is downloaded at a time, meaning that only one device is allowed to download the upgrade package at any given time.
[0126] Under the second upgrade bandwidth allocation strategy of multi-path flow limiting, multiple devices are allowed to download the upgrade package at the same time.
[0127] In one example, the above-mentioned determination of the upgrade available bandwidth of each upgrade package corresponding to the upgrade package distribution link based on the upgrade available bandwidth of the upgrade package distribution link and according to the pre-configured second upgrade bandwidth allocation strategy may include: for an upgrade package distribution link corresponding to multiple subordinate devices, when the second upgrade bandwidth allocation strategy is single-path rate limiting, the upgrade available bandwidth of the upgrade package distribution link is determined as the upgrade available bandwidth of each upgrade package corresponding to the upgrade package distribution link; when the second upgrade bandwidth allocation strategy is multi-path rate limiting, the upgrade available bandwidth of each upgrade package corresponding to the upgrade package distribution link is determined based on the upgrade available bandwidth of the upgrade package distribution link and the upgrade package type of each upgrade package corresponding to the upgrade package distribution link.
[0128] For example, for an upgrade package distribution link corresponding to multiple subordinate devices, if the upgrade package distribution link is a single-path rate-limited link, the upgrade available bandwidth of the upgrade package distribution link is determined as the upgrade available bandwidth of each upgrade package corresponding to the upgrade package distribution link.
[0129] For example, the available bandwidth for device upgrades can correspond to the maximum download rate of the upgrade package for that device.
[0130] For example, assuming that the available bandwidth for an upgrade package distribution link is 8Mbps and that the upgrade package distribution link is single-path rate limited, then the maximum download speed for each upgrade package corresponding to this upgrade package distribution link during the upgrade package download process is 1MB / s. That is, the maximum download speed for each subordinate device during the download process through this upgrade package distribution link is 1MB / s.
[0131] In one example, determining the available upgrade bandwidth of each upgrade package corresponding to the upgrade package distribution link based on the available upgrade bandwidth of the upgrade package distribution link and the upgrade package type of each upgrade package corresponding to the upgrade package distribution link may include: determining the number of different upgrade package types corresponding to the upgrade package distribution link based on the upgrade package type of each upgrade package corresponding to the upgrade package distribution link; allocating the available upgrade bandwidth of the upgrade package distribution link to each type of upgrade package according to a pre-configured allocation rule to obtain the available upgrade bandwidth of each upgrade package corresponding to the upgrade package distribution link.
[0132] For example, for an upgrade package distribution link corresponding to multiple subordinate devices, if the upgrade package distribution link is subject to multi-path rate limiting, the upgrade package type of each upgrade package corresponding to the upgrade package distribution link can be determined, the number of upgrade package types corresponding to the upgrade package distribution link can be determined, and the upgrade available bandwidth of the upgrade package distribution link can be allocated to each type of upgrade package according to the pre-configured allocation rules, so as to obtain the upgrade available bandwidth of each upgrade package corresponding to the upgrade package distribution link.
[0133] For example, assuming that the number of upgrade package types corresponding to the upgrade package distribution link is K (K≥2), then K-way rate limiting can be applied to the upgrade package distribution link (one type of upgrade package corresponds to one rate limiting channel), and the available upgrade bandwidth corresponding to each type of upgrade package can be determined respectively.
[0134] For example, pre-configured allocation rules include average allocation rules or priority weight rules.
[0135] For example, priority weights can be determined based on business importance, real-time requirements, etc.
[0136] As an example, the above-mentioned allocation of the available upgrade bandwidth of the upgrade package distribution link to each type of upgrade package according to the pre-configured allocation rules may include: when the pre-configured allocation rule is an average allocation rule, the available upgrade bandwidth of the upgrade package distribution link is allocated equally to each type of upgrade package; when the pre-configured allocation rule is a priority weight rule, the available upgrade bandwidth of the upgrade package distribution link is allocated to each type of upgrade package according to the priority weight of each type of upgrade package.
[0137] For example, suppose an upgrade package distribution link corresponds to 4 types of upgrade packages, and the upgrade package distribution link adopts a multi-path rate limiting average allocation rule, with an upgrade available bandwidth of 8Mbps. Then, for any type of upgrade package, its download speed limit is 0.25MB / s. Correspondingly, during the download of each upgrade package corresponding to the upgrade package distribution link, the maximum download speed is 0.25MB / s.
[0138] For example, an upgrade package distribution link may have two types of upgrade packages. This upgrade package distribution link uses a multi-path rate limiting priority weight rule, and the available upgrade bandwidth is 16Mbps. The two types of upgrade packages include an emergency security patch type upgrade package (denoted as upgrade package A) and a user interface optimization type upgrade package (denoted as upgrade package B). Upgrade package A has a higher priority and is allocated 80% of the upgrade bandwidth (priority weight of 0.8), while upgrade package B has a lower priority and is allocated 20% of the upgrade bandwidth (priority weight of 0.2). Therefore, the download speed limit for upgrade package A is 1.6MB / s, and the download speed limit for upgrade package B is 0.4MB / s.
[0139] In some embodiments, upgrading each device under a site based on the available upgrade bandwidth of each device under the site may include: determining the maximum download rate of the upgrade package for each device under the site based on the available upgrade bandwidth of each device under the site; for any device under the site, when the management device receives an upgrade package download request sent by the device, controlling the first rate of reading the upgrade package file from the management device's disk into the management device's memory and the second rate of writing the upgrade package file from the management device's memory into the management device's kernel buffer based on the maximum download rate of the upgrade package for the device, and sending the data in the management device's kernel buffer to the subordinate device.
[0140] For example, the maximum download speed of the upgrade package for each device to be upgraded under the site can be determined based on the available upgrade bandwidth of each subordinate device under the site.
[0141] During the device upgrade process, the management device can send upgrade signaling to the corresponding device through the upgrade package distribution link. For example, for any device to be upgraded, the management device can send upgrade signaling to the endpoint device of the upgrade package distribution link corresponding to the device to be upgraded.
[0142] For example, multiple IPCs are connected to the same NVR. These multiple IPCs and the NVR can correspond to the same upgrade package distribution link. If any of the multiple IPCs needs to be upgraded, the management device can send an upgrade signaling to the NVR.
[0143] For example, the upgrade signaling may include upgrade package download address information, such as a URL (Uniform Resource Locator) for downloading the upgrade package.
[0144] For example, relevant personnel can access the device upgrade management interface of the management device, select the device to be upgraded (i.e., the device to be upgraded) and the software to be upgraded in the interface, and determine the target version of the software. The management device can determine the upgrade package of the device to be upgraded based on the device type of the device to be upgraded, the current version of the software to be upgraded, and the target version, and send upgrade signaling to the endpoint device of the upgrade package distribution link through the upgrade package distribution link. The upgrade signaling can carry the device identifier of the device to be upgraded and the URL of the upgrade package.
[0145] For example, as shown in Figure 2, assuming IPC222-1 and IPC 222-2 are connected to the same NVR 221, that is, IPC 222-1, IPC 222-2, and NVR 221 correspond to the same device aggregation chain, relevant personnel select to upgrade the firmware of IPC 222-1 and IPC 222-2 in the device upgrade management interface of the management device, and the target firmware versions are the same. The management device can determine the current firmware versions of IPC 222-1 and IPC 222-2 respectively. Assuming that the current firmware versions of IPC 222-1 and IPC 222-2 are the same, the management device can determine that the upgrade packages of IPC 222-1 and IPC 222-2 are the same, and send an upgrade signaling to NVR 221. This upgrade signaling can carry the device identifiers of IPC 222-1 and IPC 222-2 and the URL of the upgrade package.
[0146] When the endpoint device of the upgrade package distribution link receives the upgrade signaling sent by the management device, it can download the upgrade package according to the upgrade package download address information.
[0147] For any device to be upgraded under any site, when the management device receives a download request for the upgrade package for that device, it can control the first rate at which the upgrade package file is read from the management device's disk into the management device's memory, and the second rate at which the upgrade package file is written from the management device's memory into the management device's kernel buffer, based on the maximum download rate of the upgrade package for that device, and then send the data in the management device's kernel buffer to the subordinate device.
[0148] In one example, the above-mentioned control of the rate at which the upgrade package file is read from the management device's disk into the management device's memory based on the device's maximum upgrade package download rate may include:
[0149] The token generation rate is determined based on the maximum download rate of the upgrade package for the device; the number of tokens generated per unit time is consistent with the maximum number of bytes of the upgrade package downloaded per unit time, and the maximum capacity of the token bucket used to store the tokens is consistent with the number of tokens generated per unit time.
[0150] If the token bucket contains a number of tokens corresponding to the number of bytes of the upgrade package file to be read, the corresponding number of tokens are retrieved from the token bucket, and the upgrade package file of that number of bytes is read from the disk of the management device into the memory of the management device.
[0151] For example, the read rate control of the upgrade package file from the management device's disk to the management device's memory can be achieved through a token bucket mechanism.
[0152] In one example, controlling the rate at which the upgrade package file is written from the memory of the management device to the kernel buffer of the management device based on the maximum download rate of the upgrade package for the device may include: determining the current average transmission rate based on the execution time of writing the upgrade package file from the memory of the management device to the kernel buffer of the management device and the amount of data already written; and pausing data writing for a preset time if the current average transmission rate is greater than the maximum download rate of the upgrade package for the device.
[0153] For example, during the process of the management device writing the upgrade package file from the management device's memory to the management device's kernel buffer, the write rate can be determined based on the write time and the amount of data written.
[0154] In particular, if the write speed exceeds the maximum download speed of the upgrade package, the download speed of the upgrade package can be controlled by pausing the write operation.
[0155] If the endpoint device of the upgrade package distribution link is not the device to be upgraded, the endpoint device of the upgrade package distribution link can forward the downloaded upgrade package to the device to be upgraded through an internal connection after completing the download of the upgrade package according to the upgrade package download address.
[0156] Using the previous example, if NVR 221 has completed the download of upgrade packages for IPC 222-1 and IPC 222-2 based on the URL in the upgrade signaling, it can forward the upgrade packages to IPC 222-1 and IPC 222-2 respectively through internal connections based on the identification information of IPC 222-1 and IPC 222-2.
[0157] In some embodiments, upgrading each device under the site based on the upgrade available bandwidth of each device under the site may include: updating the upgrade available bandwidth of each device under the site when it is determined that the conditions for updating the upgrade rate limiting policy are met, and upgrading each device under the site based on the updated upgrade available bandwidth of each device under the site.
[0158] The conditions for meeting the upgrade rate limiting policy update include one or more of the following: the current upgrade rate limiting policy has expired, the preset upgrade rate limiting policy update cycle has been reached, or the business set of the site has changed.
[0159] For example, in order to make the upgraded rate limiting strategy more in line with the actual scenario and optimize the rate limiting effect, the upgraded rate limiting strategy can be updated as needed.
[0160] For example, for an upgrade rate limiting policy determined in the above manner, an expiration time or a refresh cycle can be set for it. When the current upgrade rate limiting policy expires or the preset upgrade rate limiting policy update cycle is reached, it is determined that the conditions for updating the upgrade rate limiting policy are met, and the upgrade rate limiting policy is updated.
[0161] Furthermore, it can also be determined that the upgrade rate limiting policy is met when the service set of a site changes. In one example, determining that the service set of a site has changed can include: determining that the service set of a site has changed when a service configuration modification operation instruction for the site is detected; or, determining that the service set of a site has changed based on the real-time status and records of the service operations queried for the site.
[0162] For example, the management device can determine that the service set of a site has changed when it detects an operation command to modify the service configuration of the site. Alternatively, the management device can provide an operation status management center that can automatically query the real-time status and records of service operations, determine which devices at the current site are performing what kind of service operation, and thus determine whether the service set of the site has changed.
[0163] For example, if it is determined that the conditions for updating the rate limiting policy are met, the available bandwidth for each device to be upgraded at the site can be updated, and the subordinate devices at the site can be upgraded based on the updated available bandwidth of each device to be upgraded at the site.
[0164] In one example, updating the available upgrade bandwidth for each device to be upgraded under the site when the conditions for updating the upgrade rate limiting policy are met can include: determining the updated available upgrade bandwidth for the site based on the changed service set when the service set of the site is determined to be changed; and determining the updated available upgrade bandwidth for each device to be upgraded under the site based on the updated available upgrade bandwidth of the site and the number of upgrade packet distribution links of the site.
[0165] For example, for any site, if it is determined that the service set of the site has changed, the service types included in the changed service set of the site and the quantity of each type of service can be determined. Based on the service types included in the changed service set of the site, the quantity of each type of service, and the preset bandwidth consumption corresponding to each type of service, the updated service bandwidth consumption of the site can be determined. Furthermore, based on the bandwidth threshold of the site and the updated service bandwidth consumption of the site, the updated upgrade available bandwidth of the site can be determined.
[0166] Once the available bandwidth for the upgrade after the site's update is determined, the available bandwidth for each device to be upgraded under the site is determined based on the available bandwidth for the upgrade after the update and the number of links for the upgrade package distribution at the site.
[0167] The specific implementation of determining the upgrade available bandwidth of each device to be upgraded under the site based on the updated upgrade available bandwidth of the site and the number of links for which the upgrade package is distributed at the site can be found in the relevant description in the above embodiments, and will not be repeated here in the embodiments of this application.
[0168] To enable those skilled in the art to better understand the technical solutions provided in the embodiments of this application, the technical solutions provided in the embodiments of this application are described below with reference to specific examples.
[0169] Taking the management device as a DMP (i.e., the aforementioned management software is deployed in the DMP) as an example, considering that the bandwidth of the DMP's central server is relatively sufficient in this scenario, while the downlink bandwidth of the routers of each site managed by the DMP is usually limited, the traditional central rate limiting scheme is not suitable for the DMP scenario.
[0170] Considering the above issues, in this embodiment, a site model is constructed to discover site devices and topology, a site device aggregation chain is built, and the site service bandwidth consumption is determined. Then, by combining the bandwidth threshold and service bandwidth consumption, the available upgrade bandwidth of the site is determined. Finally, based on the device aggregation chain, the available upgrade bandwidth of each device is determined, a rate limiting upgrade strategy is generated and executed, so as to achieve the purpose of intelligent rate limiting upgrade.
[0171] The process of the intelligent current limiting upgrade scheme for devices provided in this application embodiment will be described below with reference to Figure 4.
[0172] 1. Establish a site model: The site model is a digital infrastructure model, which mainly describes the site's attributes and its self-description. This includes key attributes such as site type and site bandwidth threshold.
[0173] For example, sites of the same type may have the same set of services.
[0174] 2. Populate site instances: Automatically generate site management forms based on site attributes, and allow manual entry or batch import of site instances.
[0175] 3. Discover devices under the site: For any site instance, devices (i.e. devices under the site) in the local area network can be automatically discovered through protocols such as device discovery protocol, device search protocol, multicast protocol or NETMAP protocol, and automatically added to the site.
[0176] 4. Establish the physical topology of devices under the site: Calculate and obtain the physical topology of devices under the site through SNMP protocol, LLDP protocol and MAC address learning table.
[0177] For example, if the topology obtained through the protocol is incomplete, topology nodes and relationships can be manually edited and added.
[0178] For example, for an NVR device, the list of sub-device IPCs can be obtained through the NVR interface to determine the topological relationship between the NVR and the IPCs.
[0179] For example, a site topology diagram can be shown in Figure 5.
[0180] 5. Obtain the latest version of the site's rate limiting upgrade strategy: The system is set to refresh the site's rate limiting strategy periodically.
[0181] For example, a rate limiting upgrade policy update can be triggered when a change in the set of services for a site is detected.
[0182] For example, if the current rate-limiting upgrade policy expires, an update to the rate-limiting upgrade policy can be triggered.
[0183] 6. Generate site device aggregation chain: When it is necessary to generate a rate limiting upgrade strategy, the master-slave device relationship of the site's subordinate devices can be determined based on the site's physical topology, and a set of device aggregation chains for the site can be generated. The set of device aggregation chains includes at least one device aggregation chain, and each device aggregation chain can be used as a link for distributing upgrade packages when upgrading related devices.
[0184] For example, a device aggregation chain can be used to determine the available bandwidth for upgrading each subordinate device of a site.
[0185] For example, generating a rate limiting upgrade policy may include: generating a rate limiting upgrade policy for the first time or meeting the conditions for updating the rate limiting upgrade policy.
[0186] For example, during the generation of a site device aggregation chain, it can be determined whether there are multiple sub-devices connected to the same master device based on the physical topology of each subordinate device of the site.
[0187] When it is determined that multiple sub-devices are connected to the same master device, it can be determined that the multiple sub-devices and the master device belong to the same device aggregation chain, such as a device aggregation chain consisting of routers, switches, and master devices. This device aggregation chain will be used as the upgrade packet distribution link when the corresponding master device and / or any sub-device is upgraded. The endpoint device of this upgrade packet distribution link is the master device.
[0188] For example, when multiple IPCs are connected to the same NVR, these IPCs and the NVR are grouped into the same device aggregation chain, such as a device aggregation chain consisting of routers, switches, and NVRs. This chain will be used as the upgrade package distribution link when upgrading any of the IPCs or the NVR, and the NVR will be the endpoint of this upgrade package distribution link. In other words, during the upgrade process, the upgrade package for each IPC can be distributed to the NVR, which will then perform the firmware upgrade on the IPC. This means that instead of sending the upgrade package sequentially to each IPC, the NVR aggregates the upgrade packages for multiple IPCs.
[0189] For the same device aggregation chain, if it is determined that there is a sub-device in the device aggregation chain that is connected to the main device through multiple channels, the multiple channels of the same sub-device connecting to the main device can be aggregated into one aggregation channel.
[0190] For example, a stereo IPC / multi-camera IPC has multiple channels that are individually mapped to NVR channels. These multi-camera channels need to be aggregated into a single IPC. When the NVR sends an upgrade packet to the IPC connected to it, only one upgrade packet needs to be sent for that stereo / multi-camera IPC, instead of sending an upgrade packet for each channel of that stereo / multi-camera IPC. Therefore, multiple channels corresponding to a stereo / multi-camera IPC can be aggregated.
[0191] As shown in Figure 6, assuming that IPC 222-2 is a stereo camera, channels 21 and 22 of IPC 222-2 are connected to channels 13 and 1m of NVR 221, respectively. Channels 13 and 1m of NVR 221 can be aggregated with channels 21 and 22 of IPC 222-2 to generate a device aggregation chain.
[0192] It should be noted that since the business objects such as device stream acquisition and capture data upload are each channel of the NVR, that is, each channel of the IPC, when performing business aggregation calculation, the multi-channel level rather than the device level will be used as the default configuration for business mapping (that is, the business aggregation calculation does not perform channel aggregation).
[0193] 7. Remotely collect bandwidth consumption of the root node router device: Collect the port bandwidth consumption of the router via SNMP, proprietary protocols, etc. If the router does not support protocol-based bandwidth consumption collection, proceed to steps 8 and 9, or step 10.
[0194] 8. Obtain the preset service set and bandwidth preset mapping table: This mapping table can be obtained by comprehensively calculating the preset service types and data volumes of each site device.
[0195] 9. Calculate the real-time bandwidth consumption of the site: Different service sets under different scenario types correspond to different service bandwidth consumption.
[0196] For each site, the service set of the site can be determined based on the service types of its subordinate devices, and the service bandwidth consumption of the site can be determined based on the service set of the site and the preset bandwidth consumption of each service type.
[0197] For example, in scenario type A site: the service set includes: 2 real-time streaming service instances + 2 target image capture service instances + 1 sensor data upload service instance, with a preset average bandwidth consumption of: W = 2*W1 + 2*W2 + W3.
[0198] Among them, W1, W2, and W3 represent the peak bandwidth consumption of the three types of services. Therefore, W can be determined as the real-time bandwidth consumption of the site.
[0199] For example, the preset service set and bandwidth preset mapping are shown in Table 1: Table 1
[0200] 10. Obtain the site bandwidth threshold M: The site bandwidth threshold is an attribute set in the site model and is imported during instance entry.
[0201] 11. Determine the available bandwidth P for site upgrade: P = M * X% - W.
[0202] 12. Determine the available upgrade bandwidth of the device aggregation chain (i.e., the available upgrade bandwidth of the upgrade package distribution link): Based on the available upgrade bandwidth of the site and the device aggregation chain, determine the available upgrade bandwidth of each device aggregation chain according to the pre-configured upgrade bandwidth allocation strategy (i.e., the first upgrade bandwidth allocation strategy mentioned above).
[0203] For example, the first upgrade bandwidth allocation strategy may include an equal allocation strategy or a priority weight allocation strategy.
[0204] For example, taking the scenario shown in Figure 2, this scenario includes three device aggregation chains: one corresponding to IPC 222-1 to IPC 222-3 and NVR 221, another corresponding to IPC 222-4, and the last corresponding to IPC 222-5. When all three device aggregation chains are used as upgrade package distribution links and the upgrade bandwidth allocation strategy for this site is an equal-sharing strategy, the available upgrade bandwidth for each upgrade package distribution link is P / 3, where P is the available upgrade bandwidth for this site.
[0205] For example, taking the scenario shown in Figure 3, this scenario includes two device aggregation chains. The first chain corresponds to three IPCs (222-1 to 222-3), and the second chain corresponds to two VAs (223-1 and 223-2). These IPCs carry real-time video streaming services, while the VAs carry non-real-time intelligent analysis servers. The real-time video streaming service has a higher priority, allocating 70% of the upgrade bandwidth (priority weight 0.7); the non-real-time intelligent analysis service has a lower priority, allocating 30% of the upgrade bandwidth (priority weight 0.3). Therefore, when both device aggregation chains are used as upgrade package distribution links, the available upgrade bandwidth for the first upgrade package distribution link is 0.7P, and the available upgrade bandwidth for the second upgrade package distribution link is 0.3P, where P is the available upgrade bandwidth for that site.
[0206] 13. Determine the available upgrade bandwidth for each device to be upgraded based on the upgrade bandwidth available in each device aggregation chain: During batch upgrades, calculate the available upgrade bandwidth for each upgrade package according to the pre-configured upgrade bandwidth allocation strategy of the device aggregation chain (i.e., the second upgrade bandwidth allocation strategy).
[0207] For example, the second upgrade bandwidth allocation strategy may include single-path rate limiting or multi-path rate limiting.
[0208] For multi-path rate limiting device aggregation chains, bandwidth allocation rules may include average allocation rules or priority weight rules.
[0209] 14. Implement rate-limiting upgrade strategy: For any device to be upgraded, when the DMP detects an upgrade command for that device, its built-in DUS module queries the available upgrade bandwidth for that device as determined in the above steps, and sends an upgrade signaling message to the corresponding device through the upgrade package distribution link. This upgrade signaling message includes the URL of the upgrade package for that device. The device receiving the upgrade signaling message sends an upgrade package download request to the DMP based on the URL of the upgrade package and downloads the corresponding upgrade package. During the upgrade package download process, the maximum download rate does not exceed the download rate corresponding to the available upgrade bandwidth of the device to be upgraded.
[0210] For example, assuming the available bandwidth for upgrading the device is 8Mbps, the maximum download speed for the device to download the upgrade package is 1MB / s.
[0211] For example, for an upgrade package distribution link corresponding to a single device, the DUS module can send upgrade signaling to that device.
[0212] For upgrade package distribution links corresponding to multiple devices, the DUS module can send upgrade signaling to a specified device among these multiple devices.
[0213] For example, in a scenario where multiple IPCs are connected to a router via an NVR, these multiple IPCs and NVRs together correspond to an upgrade packet distribution link (belonging to a device aggregation chain). When the device to be upgraded is any one of these multiple IPCs or an NVR, the DUS module can send upgrade signaling to the NVR.
[0214] As shown in Figure 7, the process for implementing rate limiting for upgrade package downloads may include the following.
[0215] 1) When DMP receives an upgrade package download request, the DUS module can read the target file from DMP's disk into DMP's memory.
[0216] For example, the upgrade package download request is initiated by the device that received the upgrade signaling and the URL carried in the upgrade signaling to the DMP; when the DMP receives the upgrade package download request, it can determine the upgrade package file (which can be called the target file) to be downloaded based on the URL of the upgrade package.
[0217] 2) The DUS module writes the target file data in DMP's memory to DMP's kernel buffer using the write method. For example, it writes the target file data in DMP's memory to DMP's kernel buffer using Tomcat (a web application server).
[0218] For example, for any device to be upgraded, the DUS module can ensure that its download rate does not exceed the maximum download rate through two-stage collaborative rate limiting: i) Rate limiting during data reading.
[0219] For example, for any device to be upgraded, during the process of reading target file data from the DMP's disk into the DMP's memory, the token bucket algorithm can be used to implement rate limiting. The specific rate limiting algorithm process can be designed as shown in Figure 8.
[0220] As shown in Figure 8, assuming a rate limit of 1MB / s, 1024*1024 tokens are generated per second, and the token bucket can store a maximum of 1,048,576 tokens. This means that only 1,048,576 bytes of data are allowed to be read per second, thus achieving the rate limit.
[0221] During the upgrade package download process, determine the number of bytes to be downloaded (e.g., the number of bytes to be downloaded per second, i.e., 1,048,576 bytes), and check if the corresponding number of tokens exists in the token bucket. If they exist, retrieve the corresponding number of tokens from the token bucket and read the data; otherwise, wait for the download to complete until the corresponding number of tokens exists in the token bucket.
[0222] After data reading has been performed, it can be determined whether the upgrade package download has finished. If not, proceed to the step of determining the number of bytes to be downloaded. Otherwise, end the current process.
[0223] The above methods limit the rate at which data is read from the disk into memory, setting a rate cap for subsequent processing stages (not exceeding the maximum download rate of the device to be upgraded). ii) Rate limiting during data writing.
[0224] For example, during the process of writing data from memory to the kernel buffer, for any device to be upgraded, the DUS module can control the rate at which target file data is written from the DMP's memory to the DMP's kernel buffer based on the maximum download rate of the device to be upgraded.
[0225] For example, the execution time of the current method and the amount of data transmitted (i.e., the execution time and the amount of data written by the DUS module to the kernel buffer) can be recorded to calculate the current average transmission rate. It is then determined whether the current average transmission rate is greater than the maximum download rate of the upgrade package. If it is, the thread is paused for a time T (e.g., 50 milliseconds), delaying transmission and increasing the interval between data packets, thereby slowing down the download speed.
[0226] 3) The operating system sends the data in the kernel buffer to the device that requested the download.
[0227] For example, after precise control through the two stages described above, the data to be sent (such as target file data) enters the kernel buffer at a controlled rate. The operating system can then assemble the data in the kernel buffer into network packets and send them to the requesting device. Although this step is completed asynchronously and automatically by the operating system, it can only send data already present in the kernel buffer, and the rate at which the kernel buffer is written is precisely limited by the DUS module. Therefore, controlling the "write" rate to the kernel buffer is equivalent to achieving ultimate control over the network "send" rate, i.e., achieving ultimate control over the upgrade package download rate.
[0228] The method provided in this application has been described above. The apparatus provided in this application is described below:
[0229] Please refer to Figure 9, which is a structural schematic diagram of a device upgrade apparatus provided in an embodiment of this application. This apparatus can be applied to a management device that manages devices under at least one IoT site. As shown in Figure 9, the device upgrade apparatus may include: a first determining unit 910, configured to determine the number of upgrade package distribution links for any given site, wherein the upgrade package distribution links are used to distribute upgrade packages to devices under the site; a second determining unit 920, configured to determine the available upgrade bandwidth of the site; a third determining unit 930, configured to determine the available bandwidth of each device under the site to be upgraded based on the available upgrade bandwidth and the number of upgrade package distribution links of the site; and an upgrade unit 940, configured to upgrade each device under the site based on the available upgrade bandwidth of each device under the site.
[0230] The specific implementation process of each unit in the equipment upgrade device to upgrade the equipment can be found in the relevant descriptions in the above method embodiments.
[0231] Please refer to Figure 10, which is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device may include a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004. The processor 1001, communication interface 1002, and memory 1003 communicate with each other via the communication bus 1004. The memory 1003 stores a computer program; the processor 1001 can execute the device upgrade method described above by executing the program stored in the memory 1003.
[0232] The memory 1003 mentioned in this document can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, the memory 1003 can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid-state drive, any type of storage disk (such as optical disc, DVD, etc.), or similar storage media, or combinations thereof.
[0233] This application also provides a non-transitory machine-readable storage medium storing a computer program, such as the memory 1003 in FIG10, which can be executed by the processor 1001 in the electronic device shown in FIG10 to implement the device upgrade method described above.
[0234] This application also provides a computer program stored in a non-transitory machine-readable storage medium, such as the memory 1003 in FIG10, and when the processor executes the computer program, it causes the processor 1001 to execute the device upgrade method described above.
[0235] This application also provides a device upgrade system, including the electronic device shown in FIG10, and at least one subordinate device connected to the electronic device in an Internet of Things site.
[0236] In some embodiments, the device upgrade system further includes: a site router, wherein subordinate devices of each site are directly or indirectly connected to the site router and access the electronic device through the site router.
[0237] For example, the electronic device may be a device independent of each site, or integrated into any of the sites.
[0238] For example, the specific implementation process of the device upgrade system for device upgrades can be found in the relevant descriptions in the above method embodiments.
Claims
1. A device upgrading method applied to a management device for managing devices under at least one Internet of Things (IoT) site, the method comprising: determining, for any site, a number of upgrade package delivery links of the site, wherein the upgrade package delivery links are used to deliver upgrade packages to devices under the site; determining an upgrade available bandwidth of the site; determining, according to the upgrade available bandwidth of the site and the number of upgrade package delivery links of the site, an upgrade available bandwidth of each device to be upgraded under the site; upgrading each device to be upgraded under the site according to the upgrade available bandwidth of each device to be upgraded under the site.
2. The method of claim 1, wherein, The determination of the number of upgrade package delivery links of the site comprises: grouping devices under the site into at least one device group according to predetermined aggregation conditions, wherein each device group comprises at least one device; determining a device aggregation chain set of the site by aggregating each device group in the at least one device group into a device aggregation chain; determining the number of links in the device aggregation chain set or the number of links related to each device to be upgraded in the device aggregation chain set as the number of upgrade package delivery links of the site.
3. The method of claim 2, wherein, The predetermined aggregation conditions comprise at least one of the following: grouping at least one device under the site sharing a port bandwidth of a router corresponding to the site into a first device group; or grouping at least one device under the site having the same device type into a second device group.
4. The method of claim 3, wherein, For each first device group, the first device group comprises a master device connected to a port of the router and n slave devices sharing the port bandwidth of the router via the master device, wherein n is an integer greater than or equal to 0, and the master device is the end device of the device aggregation chain corresponding to the first device group when the device aggregation chain is used as an upgrade package delivery link.
5. The method according to any one of claims 1 to 4, characterized in that, The determination of the upgrade available bandwidth of the site comprises: determining a service bandwidth consumption of the site; determining the upgrade available bandwidth of the site according to the service bandwidth consumption of the site and a bandwidth threshold of the site.
6. The method of claim 5, wherein, The determination of the service bandwidth consumption of the site comprises any of the following: determining a service bandwidth consumption of a router of the site collected through a specified bandwidth information collection protocol as the service bandwidth consumption of the site; or determining the service bandwidth consumption of the site according to a service set of the site and a preset bandwidth consumption corresponding to each service type in the service set, wherein the service set comprises service types of devices under the site and a number of devices corresponding to each service type. The bandwidth threshold of the site is determined by:
7. The method according to claim 5 or 6, characterized in that, obtaining site management information of the at least one IoT site, wherein the site management information comprises bandwidth thresholds of sites; and determining the bandwidth threshold of the site according to the site management information. The determination of the upgrade available bandwidth of each device to be upgraded under the site according to the upgrade available bandwidth of the site and the number of upgrade package delivery links of the device to be upgraded under the site comprises:
8. The method according to any one of claims 1 to 7, characterized in that, According to the upgrade available bandwidth of the site and the number of upgrade package delivery links of the site, the upgrade available bandwidth of each upgrade package delivery link of the site is determined according to a preconfigured first upgrade bandwidth allocation strategy. For any upgrade package delivery link, the upgrade available bandwidth of each upgrade package corresponding to the upgrade package delivery link is determined according to the upgrade available bandwidth of the upgrade package delivery link and a preconfigured second upgrade bandwidth allocation strategy.
9. The method of claim 8, wherein, The determination of the upgrade available bandwidth of each upgrade package delivery link of the site according to the upgrade available bandwidth of the site and the number of upgrade package delivery links of the site and the preconfigured first upgrade bandwidth allocation strategy comprises: In the case that the first upgrade bandwidth allocation strategy is an equal distribution strategy, the upgrade available bandwidth of the site is evenly distributed to each upgrade package delivery link; or In the case that the first upgrade bandwidth allocation strategy is a priority weight distribution strategy, the upgrade available bandwidth of the site is distributed to each upgrade package delivery link according to the priority weight proportion of each upgrade package delivery link.
10. The method according to claim 8 or 9, characterized in that, The determination of the upgrade available bandwidth of each upgrade package corresponding to the upgrade package delivery link according to the upgrade available bandwidth of the upgrade package delivery link and the preconfigured second upgrade bandwidth allocation strategy comprises any of the following: If the upgrade package delivery link corresponds to multiple subordinate devices, in the case that the second upgrade bandwidth allocation strategy is single-channel flow limiting, the upgrade available bandwidth of the upgrade package delivery link is determined as the upgrade available bandwidth of each upgrade package corresponding to the upgrade package delivery link; or In the case that the second upgrade bandwidth allocation strategy is multi-channel flow limiting, the upgrade available bandwidth of each upgrade package corresponding to the upgrade package delivery link is determined according to the upgrade available bandwidth of the upgrade package delivery link and the upgrade package type of each upgrade package corresponding to the upgrade package delivery link. The determination of the upgrade available bandwidth of each upgrade package corresponding to the upgrade package delivery link according to the upgrade available bandwidth of the upgrade package delivery link and the upgrade package type of each upgrade package corresponding to the upgrade package delivery link comprises: According to the upgrade package type of each upgrade package corresponding to the upgrade package delivery link, the number of different upgrade package types corresponding to the upgrade package delivery link is determined; 11. The method of claim 10, wherein, According to a preconfigured distribution rule, the upgrade available bandwidth of the upgrade package delivery link is distributed to each type of upgrade package to obtain the upgrade available bandwidth of each upgrade package corresponding to the upgrade package delivery link. The distribution of the upgrade available bandwidth of the upgrade package delivery link to each type of upgrade package according to the preconfigured distribution rule comprises any of the following: In the case that the preconfigured distribution rule is an average distribution rule, the upgrade available bandwidth of the upgrade package delivery link is evenly distributed to each type of upgrade package; or 12. The method of claim 11, wherein, In the case that the preconfigured distribution rule is a priority weight rule, the upgrade available bandwidth of the upgrade package delivery link is distributed to each type of upgrade package according to the priority weight proportion of each type of upgrade package. The upgrading of each to-be-upgraded device of the site according to the upgrade available bandwidth of each to-be-upgraded device of the site comprises: 13. The method according to any one of claims 1 to 12, characterized in that, The maximum upgrade package download rate of each device to be upgraded under the site is determined according to the upgrade available bandwidth of each device to be upgraded under the site; For any device to be upgraded under the site, when a download request for the upgrade package of the device is received, the first rate and the second rate are controlled according to the maximum upgrade package download rate of the device, wherein the first rate is the rate of reading the upgrade package file from the disk of the management device to the memory of the management device, and the second rate is the rate of writing the upgrade package file from the memory of the management device to the kernel buffer of the management device; If the terminal device of the upgrade package distribution link is a device to be upgraded, the data in the kernel buffer of the management device is distributed to the device to be upgraded through the upgrade package distribution link; If the terminal device of the upgrade package distribution link is not a device to be upgraded, the data in the kernel buffer of the management device is distributed to the terminal device through the upgrade package distribution link, and then forwarded to the device to be upgraded by the terminal device.
14. The method of claim 13, wherein, The first rate is controlled according to the maximum upgrade package download rate of the device, including: The token generation rate is determined according to the maximum upgrade package download rate of the device, wherein the number of tokens generated per unit time is consistent with the maximum download byte number of the upgrade package per unit time, and the maximum capacity of the token bucket for storing the tokens is consistent with the number of tokens generated per unit time; When there are a corresponding number of tokens in the token bucket corresponding to the byte number of the upgrade package file, the corresponding number of tokens are taken out from the token bucket, and the upgrade package file with the byte number is read from the disk of the management device to the memory of the management device.
15. The method according to claim 13 or 14, characterized in that, The second rate is controlled according to the maximum upgrade package download rate of the device, including: The current transmission average rate is determined according to the execution time and the amount of data written of writing the upgrade package file from the memory of the management device to the kernel buffer of the device; When the current transmission average rate is greater than the maximum upgrade package download rate of the device, the data writing is suspended for a preset time.
16. The method of any one of claims 1 to 15, wherein the determining the upgrade available bandwidth of each device to be upgraded under the site further comprises: When it is determined that the upgrade throttling policy update condition is met, updating the upgrade available bandwidth of each device to be upgraded under the site; The upgrade throttling policy update condition comprises one or more of the following: the current upgrade throttling policy is expired, a preset upgrade throttling policy update period is reached, or the service set of the site is changed.
17. The method of claim 16, wherein, The determination that the service set of the site is changed comprises: When a service configuration modification operation instruction for the site is detected, it is determined that the service set of the site is changed; or According to the queried real-time state and record of the service operation of the site, it is determined that the service set of the site is changed.
18. A device upgrade apparatus applied to a management device for managing devices under at least one Internet of Things site, comprising: a first determining unit configured to determine, for any site, a number of upgrade package distribution links of the site, wherein the upgrade package distribution links are used to distribute upgrade packages to subordinate devices of the site; a second determining unit configured to determine an upgrade available bandwidth of the site; a third determining unit configured to determine, according to the upgrade available bandwidth of the site and the number of upgrade package distribution links of the site, an available bandwidth of each device to be upgraded subordinate to the site; an upgrading unit configured to upgrade each device to be upgraded subordinate to the site according to the upgrade available bandwidth of each device to be upgraded subordinate to the site.
19. An electronic device, comprising: one or more processors; and one or more memories for storing a computer program and communicating with the one or more processors through a communication bus; characterized in that the one or more processors execute the computer program stored in the one or more memories to implement the method of any one of claims 1 to 17.
20. A non-transitory machine-readable storage medium, comprising: The non-transitory machine-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the method of any one of claims 1 to 17.
21. A device upgrading system, comprising: the electronic device of claim 19; and at least one subordinate device of an Internet of Things site accessing the electronic device.
22. The device upgrade system of claim 21, wherein, Further comprising: a site router, the subordinate devices of each site being directly or indirectly connected to the router of the site and accessing the electronic device through the router of the site, wherein the electronic device is a device independent of each site or integrated on any of the sites.