Equipment access scheduling method and related equipment

Abstract

The invention discloses an equipment access scheduling method and related equipment. The method comprises the following steps: receiving a registration request sent by a device end; determining a target access point for the device end by using the scheduling decision information, and sending related information of the target access point to the device end; wherein the scheduling decision information is cached in the Internet of Things cloud platform, the scheduling decision information comprises a candidate access point list corresponding to a plurality of attribute scheduling types, and the scheduling decision information is obtained by analyzing connection related data of a plurality of access points; and accessing the device end to the Internet of Things cloud platform through the related information of the target access point. According to the scheme, the stability and success rate of connection between the equipment end and the Internet of Things cloud platform can be improved.

Description

Technical Field

[0001] This application relates to the field of IoT cloud platform technology, and in particular to a device access scheduling method and related equipment. Background Technology

[0002] The Internet of Things (IoT) is a network that enables all ordinary physical objects that can be independently addressed to communicate with each other, based on information carriers such as the Internet and traditional telecommunications networks. In IoT applications, a large number of devices can be connected to IoT cloud platforms, which carry out key functions such as device access, data transmission, and command issuance.

[0003] Currently, device access scheduling mostly adopts fixed access methods, relying on static configuration strategies. However, due to factors such as changes in the network environment, device access may encounter problems such as excessively long access time and unstable connections, which may also affect the success rate of device access and may not meet the actual application needs of efficient and stable access for large-scale IoT devices. Summary of the Invention

[0004] The main technical problem addressed in this application is to provide a device access scheduling method and related equipment, which can improve the stability and success rate of the connection between the device and the IoT cloud platform.

[0005] The first aspect of this application provides a device access scheduling method, which includes: receiving a registration request sent by a device; determining a target access point for the device using scheduling decision information, and sending relevant information of the target access point to the device; wherein the scheduling decision information is cached in an IoT cloud platform, the scheduling decision information includes a list of candidate access points corresponding to several attribute scheduling types, and the scheduling decision information is obtained by analyzing connection-related data of several access points; and connecting the device to the IoT cloud platform using the relevant information of the target access point.

[0006] A second aspect of this application provides a device access scheduling method, the method comprising: sending a registration request to an Internet of Things (IoT) cloud platform; receiving relevant information of a target access point sent by the IoT cloud platform in response to the registration request, wherein the target access point is obtained by the IoT cloud platform performing the above-described device access scheduling method; and accessing the IoT cloud platform using the relevant information of the target access point.

[0007] A third aspect of this application provides a computer device including a memory and a processor coupled to each other, wherein the memory stores program data and the processor executes the program data to implement the steps of the device access scheduling method described above.

[0008] A fourth aspect of this application provides a computer-readable storage medium storing program data executable by a processor, the program data being used to implement the steps of the device access scheduling method described above.

[0009] The fifth aspect of this application provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the above-described device access scheduling method.

[0010] The above solution generates and caches scheduling decision information, including a list of candidate access points with different attribute scheduling types, by pre-analyzing connection-related data from several access points. Upon receiving a registration request from a device, it quickly matches the target access point to the device based on this scheduling decision information and feeds back relevant information. Ultimately, the device accesses the IoT cloud platform through the relevant information of the target access point. This not only accurately matches the device's access needs and improves access adaptability, but also reduces access decision-making time and optimizes access process efficiency. At the same time, it relies on the analysis results of access point connection data to ensure access stability, effectively improving the rationality of the IoT cloud platform's scheduling of device access and the overall access service quality. This enhances the stability and success rate of the connection between the device and the IoT cloud platform.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in this application, the accompanying drawings required in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Among them: Figure 1 This is a flowchart illustrating the first embodiment of the device access scheduling method of this application; Figure 2 This application Figure 1 A flowchart illustrating an embodiment of step S12; Figure 3 This is a flowchart illustrating the second embodiment of the device access scheduling method of this application; Figure 4 This is a flowchart illustrating the third embodiment of the device access scheduling method of this application; Figure 5 This is a schematic diagram of the structure of the first embodiment of the device access scheduling device of this application; Figure 6 This is a schematic diagram of the structure of the second embodiment of the device access scheduling device of this application; Figure 7This is a schematic diagram of the structure of an embodiment of the computer device of this application; Figure 8 This is a schematic diagram of the structure of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0014] The terms "first" and "second" in this application are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or apparatus.

[0015] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0016] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this document means two or more. Moreover, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0017] This application provides the following embodiments, and each embodiment is described in detail below.

[0018] Please see Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the device access scheduling method of this application. This embodiment is applied to an IoT cloud platform, and the method may include the following steps: S11: Receive the registration request sent by the device.

[0019] The device side can include various IoT devices with network connectivity, such as smart hardware, cameras, smart sensors, industrial control terminals, and smart home appliances. For example, it can be used to perform basic functions such as environmental data collection, control command execution, and device status feedback. The IoT (Internet of Things) cloud platform is a comprehensive service platform that supports IoT device connectivity, management, and data processing. It is used to build, deploy, and manage IoT applications, thereby achieving intelligent operation and services. It can monitor the operating status of the devices in real time to achieve efficient scheduling of device access and stable overall system operation.

[0020] The device can send a registration request to the IoT cloud platform to request access to the platform's domain name or access point. The registration request includes relevant information about the device. For example, the registration request may include at least a device identifier, such as a combination of one or more of the following: PID (Product ID), SN (Serial Number), and MAC address. This application does not limit the scope of the registration request.

[0021] Optionally, when the device is powered on or after the network is restored, it can send a registration request to the IoT cloud platform to conduct the first cloud interaction and initiate a registration request to the IoT cloud platform to obtain a target access point.

[0022] In some implementations, the device can send a registration request to the IoT cloud platform via a first communication protocol. Optionally, the first communication protocol may include, but is not limited to, at least one of the following: UDP (User Datagram Protocol), TCP (Transmission Control Protocol), TLS (Transport Layer Security), HTTP (Hypertext Transfer Protocol), and HTTPS (Hypertext Transfer Protocol Secure). For example, the first communication protocol may include, but is not limited to, proprietary protocols such as UDP, TCP, and TLS, or short-connection protocols based on HTTP or HTTPS. This application does not limit the scope of the first communication protocol.

[0023] S12: Using scheduling decision information, determine the target access point for the device and send the relevant information of the target access point to the device.

[0024] The IoT cloud platform can respond to registration requests from devices by using cached scheduling decision information to determine target access points for the devices and send relevant information about the target access points to the devices. The scheduling decision information, cached in the IoT cloud platform, includes a list of candidate access points corresponding to several attribute scheduling types. This scheduling decision information is obtained by analyzing connection-related data from several access points.

[0025] Scheduling decision information is obtained by analyzing connection-related data collected from several access points. This data can be continuously collected and updated asynchronously. The scheduling decision information includes a list of candidate access points corresponding to several attribute scheduling types. Each candidate access point list contains at least one candidate access point, and these lists can include the optimal or near-optimal access points for each attribute scheduling type—that is, the candidate access points that can be scheduled for that attribute scheduling type under the current network environment.

[0026] In some implementations, the candidate access point list corresponding to several attribute scheduling types includes the candidate access point list corresponding to each of the several attribute scheduling types, and / or, the candidate access point list corresponding to a combination of at least two attribute scheduling types. For example, a separate candidate access point list can be set for each attribute scheduling type, and a combination of at least two attribute scheduling types can be set in the same candidate access point list. This application does not limit the scheduling decision information.

[0027] Optionally, several attribute scheduling types include at least one of the following: device identifier, device type (such as device model), operator type (such as mobile communication, telecommunications communication), geographic information (such as a certain region), and network type (such as 4G, 5G). This application does not limit the attribute scheduling type.

[0028] Optionally, scheduling decision information can be pre-cached on an IoT cloud platform. A pre-defined database can be used to cache the scheduling decision information. Pre-defined databases include, but are not limited to, high-performance in-memory databases such as Redis and Memcached. The pre-defined database stores the scheduling decision information in the form of a pre-defined data structure mapping table. For example, the pre-defined data structure mapping table can be a key-value mapping table, storing scheduling decision information in key-value mapping table format. The key can contain any or a combination of several attribute scheduling types, and the value corresponding to the key can contain a list of candidate access points, i.e., storing information related to at least one candidate access point. This information includes the server IP, access port, validity period, and communication protocol of the candidate access point. This application does not restrict the information related to the candidate access point.

[0029] For example, the Key includes, but is not limited to, device identifier, device type, carrier type, geographical location, network type, etc., and the Value includes at least one candidate access point, i.e., a list of candidate access points. Taking a Value containing one candidate access point as an example, its value is {"ip": "1.2.3.4", "port":8883, "ttl":300}, indicating that the server IP (i.e., IP address) of the candidate access point is "1.2.3.4", the access port ("port") is 8883, and the validity period ("ttl") is 300 seconds. If the connection time of the device to the candidate access point exceeds the corresponding validity period, a new candidate access point needs to be rescheduled.

[0030] In some embodiments, please refer to Figure 2 This embodiment can further extend step S12 of the above embodiment. Using scheduling decision information to determine the target access point on the device side, this embodiment may include the following steps: S121: Based on the registration request, obtain the device attribute information from the device side.

[0031] The IoT cloud platform can analyze registration requests to obtain device attribute information, which can correspond to several attribute scheduling types. Optionally, the device attribute information includes at least one device attribute type, including but not limited to: device identifier, device type, operator type, geographic information, network type, etc. This application does not limit the device attribute information.

[0032] S122: Match the device attribute information and several attribute scheduling types to obtain the matching results.

[0033] The system can match analyzed device attribute information with several attribute scheduling types to obtain matching results. These results can include a matched attribute scheduling type (as the target attribute scheduling type) or no match. Specifically, if the device attribute information does not match any attribute scheduling type, the matching result is determined to be a no match; otherwise, the matching result is determined to be a matched attribute scheduling type.

[0034] S123: Using the matching results, select candidate access points from the candidate access point list corresponding to several attribute scheduling types and determine them as the target access points on the device side, wherein the candidate access point list contains at least one candidate access point.

[0035] Based on the matching results described above, the target access point on the device can be determined. Using the matching results, a candidate access point can be selected from at least one candidate access point in the candidate access point list corresponding to several attribute scheduling types, and this candidate access point can be determined as the target access point on the device.

[0036] In some implementations, for steps S122 to S123 above, the device attribute information and several attribute scheduling types can be matched according to a preset priority order to obtain the target attribute scheduling type as the matching result.

[0037] The preset priority order can be the matching order of several attribute scheduling types. The first matched attribute scheduling type can be determined as the target attribute scheduling type, or a combination of the first matched attribute scheduling types can be used as the target attribute scheduling type. This application does not restrict the matching method. Optionally, the target attribute scheduling type can include matched attribute scheduling types or a combination of at least two matched attribute scheduling types.

[0038] During the matching process, the target attribute scheduling type that is matched first is determined according to the preset priority order. The matching can be expanded according to the preset priority order to determine the target attribute scheduling type that is matched next.

[0039] Then, a candidate access point is selected from the candidate access point list corresponding to the target attribute scheduling type and determined as the target access point on the device side. Optionally, if the candidate access point list contains multiple candidate access points, one candidate access point can be randomly selected from the list as the target access point, or the candidate access point ranked first can be selected as the target access point. The multiple candidate access points in the candidate access point list are ranked according to the evaluation results.

[0040] For example, the preset priority order is: matching device identifier > matching device type > matching carrier type > matching geographical location > no match, etc. The preset priority order can be dynamically expanded; for example, it can be dynamically expanded and adjusted based on several attribute scheduling types. Based on the matching results, access point information (such as the value) is selected from the candidate access point list corresponding to the matched target attribute scheduling type and returned to the device.

[0041] If the matching result is not a match, a backup strategy can be used to select the target access point. For example, the target access point can be determined by a preset default decision or a preset polling decision, and then returned to the device.

[0042] In some implementations, for a preset default decision, in response to a mismatch result, a preset access point can be selected from a list of candidate access points corresponding to several attribute scheduling types and determined as the target access point on the device. Optionally, a default preset access point can be directly returned as the target access point. For example, in the case of no match, a pre-set default access point can be returned. Optionally, a preset access point can be selected as the target access point based on device attribute information. For example, multiple regions can be set as central regions, and candidate access points can be configured for the central regions. If the geographical information on the device is a first region, the candidate access points of the central region corresponding to the first region can be obtained as the preset access point. For example, candidate access points of neighboring regions of the first region can be obtained as the preset access point, etc. This application does not impose any limitations on this.

[0043] In some implementations, for a preset polling decision, in response to a mismatch result, a candidate access point can be selected from a list of candidate access points corresponding to several attribute scheduling types according to the preset polling decision, and determined as the target access point on the device. The preset polling decision includes selecting candidate access points as target access points in sequence according to the polling order or polling probability of each candidate access point (or candidate access point list), and returning the results to the device.

[0044] Continue reading Figure 1 Following step S12 above, the following steps are also included: S13: Connect the device to the IoT cloud platform using the relevant information of the target access point.

[0045] The target access point is used to connect to the device, enabling the device to access the IoT cloud platform. Specifically, after receiving relevant information from the target access point, the device can use this information to access the IoT cloud platform. In other words, the target access point can respond to the device's access request, connecting the device to the IoT cloud platform and communicating with it.

[0046] In some implementations, the device can obtain the address information of the target access point from relevant information of the target access point, and use this address information to establish a communication connection with the target access point using a second communication protocol, such as establishing a long-lived connection, so that the device can establish a long-lived connection with the IoT cloud platform. Optionally, the second communication protocol includes, but is not limited to, MQTT, WebSocket, or a custom TCP binary protocol, etc., and this application does not limit the second communication protocol.

[0047] In some implementations, after obtaining the address information of the target access point, the device sends a connection request to the IoT cloud platform. The IoT cloud platform receives the connection request and, in response, establishes a connection with the device using the target access point's address information, connecting the device to the regional management center to which the target access point belongs, thus enabling the device to access the IoT cloud platform. Optionally, a long-term connection is maintained between the device and the target access point, which can be achieved through methods such as heartbeats.

[0048] In some implementations, the target access point (or each access point, candidate access point) is a distributed access point, each with an independent public IP address and acting as a transparent proxy for access. The relevant business logic is implemented in the long connection management module (the regional management center to which the access point belongs), which is physically a server cluster deployed in different edge data centers around the world (such as AWS, Alibaba Cloud, self-built data centers).

[0049] In some implementations, the regional management center is responsible for handling connection establishment, heartbeats, message parsing, message publishing / subscription, and device control signaling transmission for specific long-connection protocols. Physically, it is primarily deployed in regional data centers, such as central regions. One regional management center may correspond to multiple distributed access points in different regions. For example, if the regional management center is located in a data center in Singapore, its corresponding distributed access points could be deployed in Vietnam, Malaysia, Thailand, etc. This application does not impose any restrictions on this. In some implementations, after the above steps, in response to the device meeting the reconnection conditions, the steps of receiving the registration request sent by the device and subsequent steps can be re-executed to reconnect the device and re-access the IoT cloud platform. The reconnection conditions include at least one of: the connection quality at the target access point being lower than a preset quality threshold, or the device disconnecting at the target access point. For example, if it is detected that the device disconnected at the target access point, or the connection quality of the current target access point is low, reconnection can be triggered, and the above steps can be re-executed to obtain a new target access point for reconnection. This method ensures that the device always attempts to connect to the currently optimal access point, rather than sticking to a failed or degraded access point.

[0050] In some implementations, after the above steps, an operation corresponding to a service request can be executed in response to the service request sent by the device. For example, the service request may include video playback or video recording playback. Optionally, a control command can be sent to the device, causing the device to execute a corresponding operation in response to the control command. This application does not impose any limitations on this.

[0051] The above solution generates and caches scheduling decision information, including a list of candidate access points with different attribute scheduling types, by pre-analyzing connection-related data from several access points. Upon receiving a registration request from a device, it quickly matches the target access point to the device based on this scheduling decision information and feeds back relevant information. Ultimately, the device accesses the IoT cloud platform through the relevant information of the target access point. This not only accurately matches the device's access needs and improves access adaptability, but also reduces access decision-making time and optimizes access process efficiency. At the same time, it relies on the analysis results of access point connection data to ensure access stability, effectively improving the rationality of the IoT cloud platform's scheduling of device access and the overall access service quality. It can cope with complex network environment changes, dynamically schedule access points, and improve the stability and success rate of the connection between the device and the IoT cloud platform.

[0052] In addition, scheduling decision information is pre-written into the IoT cloud platform for scheduling caching. When the device initiates a registration request, the IoT cloud platform can directly return the optimal target access point. The device can complete the access point selection in a short time and directly connect to the target access point, improving the continuity of business between the device and the IoT cloud platform.

[0053] For multiple access points, a cluster of distributed access points in multiple regions can be established. After the device registers successfully, it connects to the corresponding optimal access point according to the scheduling decision information. The target access point is responsible for maintaining a long connection with the device and supports rapid switching of the target access point when network conditions deteriorate, which can improve the stability and success rate of the connection between the device and the IoT cloud platform.

[0054] In addition, the registration and connection modules on the device side can be designed in a lightweight manner, without the need to execute complex detection algorithms or global routing selection logic, which reduces power consumption and computing power requirements, and can adapt to large-scale IoT scenarios, thus improving adaptability.

[0055] In some embodiments, before determining the target access point on the device using the scheduling decision information described above, the scheduling decision information can be obtained and cached in the IoT cloud platform. Optionally, the scheduling decision information can be obtained and updated according to a preset period or in real time.

[0056] Please see Figure 3 , Figure 3This is a flowchart illustrating the second embodiment of the device access scheduling method of this application. This embodiment is applied to an IoT cloud platform, and the method may include the following steps: S21: Obtain connection-related data between several access points and several devices.

[0057] The IoT cloud platform can acquire connection-related data between several access points and several devices according to a preset period or in real time.

[0058] In some implementations, the IoT cloud platform can receive connection-related data reported by several access points. The IoT cloud platform can subscribe to and consume the connection-related data reported by the access points. For example, the access points can report connection-related data, such as connection log data and metric data, to the IoT cloud platform. For example, after an access point establishes a connection with a device as a target access point, the access point can report connection-related data to the IoT cloud platform. For example, the access point can report connection-related data to the IoT cloud platform periodically or according to a preset cycle. This method can employ a passive collection approach to collect connection-related data between several access points and several devices.

[0059] In some implementations, the IoT cloud platform can perform connection tests between several access points and several devices, collecting connection-related data. Probe nodes can be deployed in several regions to simulate connection tests between several devices and several access points, thereby collecting connection-related data between the access points and devices during the connection test process. For example, probe nodes can be deployed globally to simulate devices performing connection tests on access points of all regional management centers (such as device login systems) at preset intervals, collecting connection-related data. This connection-related data may include TCP / TLS handshake latency, application connection latency, connection success rate, etc., and this application does not limit the types of connection-related data. This method can actively collect connection-related data between several access points and several devices.

[0060] S22: Utilize the connection-related data to determine scheduling decision information.

[0061] Analyze connection-related data, such as performing intelligent analysis and decision-making on connection-related data, to determine scheduling decision information.

[0062] In some implementations, connection-related data can be aggregated to obtain link quality data for access points corresponding to each attribute scheduling type. Aggregation can be performed at preset time intervals. For example, a stream processing model such as Flink can be used to aggregate the collected connection-related data and calculate the link quality data per minute for each attribute scheduling type's access point path. For instance, this could involve calculating the link quality data per minute for paths such as device identifier -> access point, operator type -> access point, and geographic information (e.g., region) -> access point. The link quality data includes key indicators such as connection success rate, network latency (e.g., average latency), and packet loss rate.

[0063] The quality data of each link is evaluated to obtain the evaluation results of each access point corresponding to each attribute scheduling type. An access point evaluation model can be established and used to evaluate the link quality data on each path. For example, for an access point corresponding to an attribute scheduling type, the link device identifier -> access point, operator type -> access point, or geographical information (such as region) -> access point can be evaluated and scored to obtain the evaluation results of each path, that is, the evaluation results of each access point corresponding to each attribute scheduling type.

[0064] Then, using the evaluation results, a list of candidate access points is determined for each attribute scheduling type, thus obtaining scheduling decision information. For example, using the evaluation results, the access point with the highest evaluation score for each attribute scheduling type can be selected as the optimal access point and added to the candidate access point list for the corresponding attribute scheduling type.

[0065] Optionally, for each attribute scheduling type, a predetermined number of access points ranked by evaluation results can be selected as candidate access points and added to the candidate access point list for the corresponding attribute scheduling type. For example, for each attribute scheduling type, the top 10 access points ranked by score can be selected as candidate access points and added to the candidate access point list for the corresponding attribute scheduling type.

[0066] Optionally, the evaluation results can be used to assign polling weights to each access point, and based on these weights, the polling order or probability of each access point in the preset polling decision can be determined. For example, different weights can be assigned to corresponding access points according to the magnitude of the evaluation results, serving as polling weights. Weighted random selection can be performed using these polling weights to represent the probability of each access point being selected in the preset polling decision. Alternatively, the access points can be sorted according to their polling weights to determine their polling order in the preset polling decision. Optionally, each access point (e.g., a preset number of access points selected before sorting by polling weights) can be added to the candidate access point list for the corresponding attribute scheduling type.

[0067] Optionally, a preset first access point can be determined for the first attribute scheduling type, and added to the candidate access point list corresponding to the first attribute scheduling type. The first attribute scheduling type can be at least one of several attribute scheduling types, and the preset first access point can be at least one of several access points. For example, a default access point can be set for a specified device identifier; for instance, a default access point can be set for a specified region, thereby setting a default access point for a specified attribute scheduling type. This application does not impose any limitations on this.

[0068] In some implementations, the corresponding evaluation result can be obtained based on the connection-related data acquired each time, and the scheduling decision information can be updated. Optionally, in response to a candidate access point in the candidate access point list corresponding to the second attribute scheduling type having an evaluation result for the second attribute scheduling type lower than a preset quality condition, the candidate access point can be removed from the candidate access point list corresponding to the attribute scheduling type. Optionally, in response to an access point having an evaluation result for the access point corresponding to the second attribute scheduling type not lower than a preset quality condition, the access point can be added to the candidate access point list corresponding to the attribute scheduling type. The second attribute scheduling type can be at least one of several attribute scheduling types or a preset attribute scheduling type. For example, when the evaluation result of an access point for a specific area is lower than a preset quality condition (e.g., when the connection quality is continuously lower than a preset quality threshold), a circuit breaker is triggered, temporarily removing the access point from the candidate access point list for that area, and re-adding it after the connection quality recovers.

[0069] In the above scheme, the optimization calculation of scheduling decision information is completed by the IoT cloud platform. The complex network access point optimization calculation is transferred from the device end to the IoT cloud platform end. The device end does not need to execute complex detection algorithms or global routing selection logic. It only needs to operate according to the instructions of the IoT cloud platform end, which reduces the power consumption and computing power burden on the device end and is suitable for massive low-power IoT applications.

[0070] In addition, based on the analysis of connection-related data, the access point can be dynamically scheduled. By actively / passively collecting link quality data (latency, packet loss rate, cross-carrier / cross-border link detection, etc.), the optimal access point decision can be generated, and the scheduling decision information can be obtained. The scheduling decision information is written into the IoT cloud platform for scheduling cache. When a device initiates registration, the optimal access point information after scheduling can be directly and dynamically distributed.

[0071] Please see Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the device access scheduling method of this application. This embodiment is applied to the device side, and the method may include the following steps: S31: A registration request sent to the IoT cloud platform.

[0072] S32: Receive the relevant information of the target access point sent by the IoT cloud platform in response to the registration request, wherein the target access point is obtained by the IoT cloud platform by executing the above-mentioned device access scheduling method.

[0073] S33: Utilize the relevant information of the target access point to access the IoT cloud platform.

[0074] The specific implementation process of this embodiment can be referred to the specific implementation process of the device side in the above embodiments, and will not be repeated here.

[0075] It is understood that in the above method of specific implementation, the order in which each step is written does not mean a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0076] In some embodiments, this application also provides a device access scheduling apparatus for implementing the device access scheduling method of any of the above embodiments.

[0077] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of the first embodiment of the device access scheduling device of this application. The device access scheduling device 40 includes a device terminal 41 and an Internet of Things (IoT) cloud platform 42. The device terminal 41 and the IoT cloud platform 42 can cooperate to execute the device access scheduling method of any of the above embodiments to schedule the access of the device terminal 41 to the IoT cloud platform 42.

[0078] In some embodiments, please refer to Figure 6 , Figure 6 This is a schematic diagram of the structure of the second embodiment of the device access scheduling device of this application. For the device access scheduling device 40, the device end 41 may include a device registration module, a device login module, and a business function module, etc., and the Internet of Things cloud platform 42 may include a data analysis system, a device registration system, and a device login system.

[0079] The device registration module of device terminal 41 is used to send registration requests to the IoT cloud platform 42. Specifically, it can be used to send registration requests to the device login system of the IoT cloud platform 42. The device registration system can receive the registration requests from device terminal 41 to obtain the optimal target access point for device login under the current network environment. That is, the device registration system receives the registration requests sent by device terminal 41, uses scheduling decision information to determine the target access point for device terminal 41, and sends the relevant information of the target access point to device terminal 41.

[0080] In some implementations, scheduling decision information is cached in the device registration system of the IoT cloud platform 42. The device registration system can be used to receive registration requests from the device terminal 41, authenticate the device terminal 41, dynamically schedule access points, and interact with the device terminal 41 through short connections.

[0081] In some implementations, the device registration system includes a caching module and a scheduling module. The caching module is used to cache scheduling decision information, and the scheduling module is used to respond to the registration request, use the scheduling decision information to determine the target access point for the device 41, and return the relevant information of the target access point to the device 41.

[0082] In some implementations, the scheduling module of the device registration system is used to obtain device attribute information of device terminal 41 based on the registration request; match the device attribute information with several attribute scheduling types to obtain a matching result; and use the matching result to select a candidate access point from the candidate access point list corresponding to several attribute scheduling types and determine it as the target access point of device terminal 41, wherein the candidate access point list contains at least one candidate access point.

[0083] The device attribute information includes at least one device attribute type, the candidate access point list corresponding to several attribute scheduling types includes the candidate access point list corresponding to each of the several attribute scheduling types, and / or, the candidate access point list corresponding to at least two of the several attribute scheduling types; and / or, the several attribute scheduling types include at least one of device identifier, device type, operator type, geographic information, and network type.

[0084] In some implementations, the scheduling module is used to match device attribute information and several attribute scheduling types according to a preset priority order to obtain a target attribute scheduling type as the matching result; and select a candidate access point from the candidate access point list corresponding to the target attribute scheduling type to determine it as the target access point of the device 41.

[0085] In some implementations, the scheduling module is used to select a preset access point from a list of candidate access points corresponding to several attribute scheduling types in response to a mismatch, and determine it as the target access point of the device 41; or, in response to a mismatch, it selects a candidate access point from a list of candidate access points corresponding to several attribute scheduling types according to a preset polling decision, and determines it as the target access point of the device 41.

[0086] In some implementations, the device registration module of device terminal 41 receives relevant information about the target access point sent by IoT cloud platform 42 in response to a registration request, and transmits this information to the device login module. The device login module parses the address information of the target access point from the relevant information and uses it to access IoT cloud platform 42. Specifically, a long-lived connection can be established with the device login system of IoT cloud platform 42 to indicate access to IoT cloud platform 42. The business function module is used to implement business functions between device terminal 41 and IoT cloud platform 42, such as receiving control commands from IoT cloud platform 42, video playback, and video recording playback. Device terminal 41 can communicate and interact with the device login system.

[0087] In some implementations, the device login system includes a long-connection management module, which corresponds to several access points. The long-connection management module is used to establish a long connection with device 41 through a target access point, connecting device 41 to the IoT cloud platform 42. Optionally, the device login system receives connection requests sent by device 41, and in response to the connection requests, uses the target access point to connect device 41 to the regional management center (long-connection management module) to which the target access point belongs, thus enabling device 41 to access the IoT cloud platform 42. The long-connection management module (i.e., the regional management center) is the core business logic processing part of the device login system, responsible for handling connection establishment, heartbeat, message parsing, message publishing / subscription, and device control operation signaling transmission for specific long-connection protocols. Physically, it is mainly deployed in regional data centers, such as central regions. One long-connection management module may correspond to multiple distributed access points in different regions. This application does not impose any restrictions on this. Optionally, the device registration system is used to respond to the device terminal 41 meeting the reconnection conditions by re-executing the step of receiving the registration request sent by the device terminal 41 and subsequent steps; wherein the reconnection conditions include at least one of: the connection quality at the target access point is lower than a preset quality threshold, or the connection at the target access point is disconnected.

[0088] In some implementations, the data analysis system is used to acquire connection-related data between several access points and several device terminals 41; and to determine scheduling decision information using the connection-related data.

[0089] Optionally, the data analysis system includes a data acquisition module and an analysis and decision module. The data acquisition module is used to acquire connection-related data between several access points and several device terminals 41, and the analysis and decision module is used to determine scheduling decision information using the connection-related data.

[0090] Optionally, the data acquisition module is also used to receive connection-related data reported by several access points; and / or to perform connection tests between several access points and several device terminals 41, and collect connection-related data.

[0091] Optionally, the analysis and decision module is also used to aggregate connection-related data to obtain link quality data for each access point corresponding to each attribute scheduling type; evaluate each link quality data to obtain evaluation results for each access point corresponding to each attribute scheduling type; and use the evaluation results to determine a list of candidate access points for each attribute scheduling type to obtain scheduling decision information.

[0092] Optionally, the analysis and decision module is also used to select the top preset number of access points ranked by evaluation results for each attribute scheduling type as candidate access points and add them to the candidate access point list for the corresponding attribute scheduling type; and / or, use the evaluation results to assign polling weights to each access point; and based on the polling weights, determine the polling order or polling probability of each access point in the preset polling decision.

[0093] Optionally, the analysis and decision module is further configured to determine a preset first access point for the first attribute scheduling type and add it to the candidate access point list corresponding to the first attribute scheduling type; and / or, in response to the evaluation result of the candidate access point in the candidate access point list corresponding to the second attribute scheduling type being lower than the preset quality condition, remove the candidate access point from the candidate access point list corresponding to the attribute scheduling type.

[0094] It should be noted that the device access scheduling device provided in the above embodiments and the device access scheduling method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the device access scheduling device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This application does not impose any limitations on this.

[0095] It is understood that the device access scheduling method in this application can be executed by a computer device, which can be any device with processing capabilities, such as a mobile device, computer, server, etc., and this application does not impose any restrictions on it. In some possible implementations, the device access scheduling method can be implemented by the processor calling program data stored in memory.

[0096] Please see Figure 7 , Figure 7This is a schematic diagram of the structure of a computer device according to an embodiment of this application. The computer device 50 includes a memory 51 and a processor 52 coupled to each other. The memory 51 stores program data, and the processor 52 executes the program data to implement the steps of any embodiment of the device access scheduling method described above. In a specific implementation scenario, the computer device 50 may include, but is not limited to, a microcomputer or a server. In addition, the computer device 50 may also include mobile devices such as laptops and tablets, which are not limited here.

[0097] In this embodiment, processor 52 can also be referred to as a CPU (Central Processing Unit). Processor 52 may be an integrated circuit chip with signal processing capabilities. Processor 52 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or processor 52 can be any conventional processor. Furthermore, processor 52 can be implemented using integrated circuit chips.

[0098] The methods described in the above embodiments can be implemented as computer programs; therefore, this application proposes a computer-readable storage medium. Please refer to [link to relevant documentation]. Figure 8 , Figure 8 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present application. The computer-readable storage medium 60 stores program data 61 that can be executed by a processor. The program data 61 can be executed by the processor to implement the steps of any embodiment of the device access scheduling method described above.

[0099] The computer-readable storage medium 60 in this embodiment includes: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., which can store program data 61. Alternatively, it may be a server storing the program data 61, which can send the stored program data 61 to other devices for execution, or it can run the stored program data 61 itself.

[0100] This application also provides a computer program product comprising a computer program that, when executed by a processor, can implement the steps of the methods described in any of the foregoing embodiments. Specifically, the computer program product can be a software or program product containing a computer program, capable of running on a computing device or stored on any available medium.

[0101] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments. For the sake of brevity, this application will not repeat the details here.

[0102] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to. For the sake of brevity, the present application will not repeat them here.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0104] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0105] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0106] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application.

[0107] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, and thus stored in a computer-readable storage medium for execution by a computing device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Therefore, this application is not limited to any particular hardware and software combination.

[0108] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A device access scheduling method, characterized in that, Applied to an IoT cloud platform, the method includes: Receive registration requests sent by the receiving device; Using scheduling decision information, a target access point is determined for the device, and relevant information of the target access point is sent to the device; wherein, the scheduling decision information is cached in the IoT cloud platform, the scheduling decision information includes a list of candidate access points corresponding to several attribute scheduling types, and the scheduling decision information is obtained by analyzing the connection-related data of several access points; The device is connected to the IoT cloud platform using the relevant information of the target access point.

2. The method according to claim 1, characterized in that, The step of using scheduling decision information to determine the target access point for the device includes: Based on the registration request, obtain the device attribute information of the device. The device attribute information and several attribute scheduling types are matched to obtain the matching results; Using the matching results, candidate access points are selected from the candidate access point list corresponding to the plurality of attribute scheduling types and determined as the target access point on the device side, wherein the candidate access point list contains at least one candidate access point.

3. The method according to claim 2, characterized in that, The matching of the device attribute information and several attribute scheduling types to obtain the matching result includes: According to a preset priority order, the device attribute information and several attribute scheduling types are matched to obtain the target attribute scheduling type, which is used as the matching result; The step of selecting candidate access points from the candidate access point list corresponding to the plurality of attribute scheduling types using the matching results and determining them as the target access points on the device side includes: Select a candidate access point from the list of candidate access points corresponding to the target attribute scheduling type, and determine it as the target access point on the device side.

4. The method according to claim 2, characterized in that, The step of selecting candidate access points from the candidate access point list corresponding to the plurality of attribute scheduling types using the matching results and determining them as the target access points on the device side includes: In response to a mismatch, a preset access point is selected from the list of candidate access points corresponding to the plurality of attribute scheduling types and determined as the target access point on the device; or... In response to a mismatch result, a candidate access point is selected from the list of candidate access points corresponding to the several attribute scheduling types according to a preset polling decision, and determined as the target access point of the device.

5. The method according to claim 2, characterized in that, The device attribute information includes at least one device attribute type, and the candidate access point list corresponding to the plurality of attribute scheduling types includes the candidate access point list corresponding to each attribute scheduling type in the plurality of attribute scheduling types, and / or, the candidate access point list corresponding to at least two attribute scheduling types in the plurality of attribute scheduling types. And / or, the plurality of attribute scheduling types include at least one of device identifier, device type, operator type, geographic information, and network type.

6. The method according to claim 1, characterized in that, After connecting the device to the IoT cloud platform using the relevant information of the target access point, the process includes: In response to the device meeting the reconnection conditions, the steps of the registration request sent by the receiving device and subsequent steps are re-executed; wherein, the reconnection conditions include at least one of: the connection quality at the target access point being lower than a preset quality threshold, or the connection being lost at the target access point.

7. The method according to claim 1, characterized in that, Before determining the target access point for the device using scheduling decision information, the process includes: Obtain connection-related data between several access points and several devices; The scheduling decision information is determined using the connection-related data. And / or, connecting the device to the IoT cloud platform using the relevant information of the target access point includes: The system receives a connection request from the device and, in response to the connection request, uses the relevant information of the target access point to connect the device to the regional management center to which the target access point belongs, so that the device can access the IoT cloud platform.

8. The method according to claim 7, characterized in that, The step of determining the scheduling decision information using the connection-related data includes: The connection-related data is aggregated to obtain link quality data for each access point corresponding to each attribute scheduling type; The quality data of each link is evaluated to obtain the evaluation results of each access point corresponding to each attribute scheduling type; Using the evaluation results, a list of candidate access points is determined for each attribute scheduling type, thus obtaining the scheduling decision information.

9. The method according to claim 8, characterized in that, The process of determining a candidate access point list for each attribute scheduling type using the evaluation results includes: For each attribute scheduling type, select the top preset number of access points ranked by the evaluation results as candidate access points and add them to the candidate access point list for the corresponding attribute scheduling type; and / or Using the evaluation results, polling weights are assigned to each access point; based on the polling weights, the polling order or polling probability of each access point in the preset polling decision is determined.

10. The method according to claim 7, characterized in that, The step of determining the scheduling decision information using the connection-related data further includes: A preset first access point is determined for the first attribute scheduling type, and added to the candidate access point list corresponding to the first attribute scheduling type; and / or, If the evaluation result of a candidate access point in the candidate access point list corresponding to the second attribute scheduling type is lower than a preset quality condition, the candidate access point is removed from the candidate access point list corresponding to the attribute scheduling type. And / or, the acquisition of connection-related data between several access points and several devices includes: Receive connection-related data reported by several access points; and / or, Connection tests were conducted on several access points and several devices to collect connection-related data.

11. A device access scheduling method, characterized in that, Applied to the device side, the method includes: A registration request sent to the IoT cloud platform; The system receives relevant information about the target access point sent by the IoT cloud platform in response to the registration request, wherein the target access point is obtained by the IoT cloud platform executing the device access scheduling method according to any one of claims 1 to 10; Using the relevant information of the target access point, access is made to the IoT cloud platform.

12. A computer device, characterized in that, The method includes a memory and a processor coupled to each other, the memory storing program data and the processor executing the program data to implement the steps of the method according to any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that, The system stores program data that can be executed by a processor, the program data being used to implement the steps of the method according to any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

Images