A method and system for dynamically allocating load based on service capability

By performing feature grouping and thread management on the IoT card operator channel, the problem of request failure and inefficiency caused by channel differences is solved, and more efficient data updates are achieved and server resource waste is reduced.

CN114217958BActive Publication Date: 2025-09-02SHENZHEN MENGWANG IOT TECH DEV CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202111445612.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-11-30
Publication Date
2025-09-02
Estimated Expiration
2041-11-30

AI Technical Summary

Technical Problem

The existing IoT card information update method is slow or request failure due to differences in channels among operators.

Method used

By grouping operator channel characteristics and establishing multiple threads under each group, dynamically allocating pending IoT cards to different channel groups for processing, controlling concurrent requests to avoid overselling the request frequency.

Benefits of technology

It improves the efficiency of IoT card information update and the timeliness of data updates, and reduces invalid server expenses.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114217958B_ABST
    Figure CN114217958B_ABST
Patent Text Reader

Abstract

The present invention provides a method for dynamically allocating load based on service capability, which comprises the following steps: S1, loading operator channels, grouping channels, and creating threads according to the number of valid requests; S2, reading to-be-processed messages Bn one by one, extracting channel unique identifiers An, and storing the associated relationship (An, Bn); S3, taking out the set number cn of Bn, comparing it with the number d of single requests, and if cn=d, executing S4; if cn<d, executing S2; S4, allocating the set Bn to the channel grouping for operator channel interface processing, and clearing the Bn message corresponding to An; S5, judging whether the request frequency parameter of the channel is exceeded, and if so, proceeding to the next step; and if so, waiting and processing; S6, judging whether there are idle threads in the channel grouping, and if so, proceeding to the next step; and if not, waiting and processing; and S7, executing the operator channel request for updating.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Things card interconnection, and in particular to a method and system for dynamically allocating load based on service capabilities. Background Art

[0002] In the IoT card operation support system, there is a large amount of IoT card information, which needs to be continuously updated from multiple operator channels through software interfaces (such as IoT card status, currently used traffic, etc.). A large amount of IoT card information needs to be updated through different operator channels, and the request frequency and number of single batch requests of multiple operators' channels are different. The existing sequential query method is easy to control due to the differences between the channels, resulting in slow efficiency or request failure.

[0003] In order to overcome the above shortcomings, we invented a method and system for dynamically allocating load based on service capabilities. Summary of the Invention

[0004] The present invention aims to solve the problem of existing sequential query methods, which are prone to poor control due to differences in channels, resulting in slow efficiency or request failure. The specific solution is as follows:

[0005] A method for dynamically distributing load based on service capabilities is performed in the following steps:

[0006] Step 1: Load all the operator channels in the system, group them according to the operator channel characteristics, and create the number of threads according to the number of valid requests of the request frequency;

[0007] Step 2: Read the pending messages Bn one by one from the storage unit, extract the channel unique identifier An in the message request, store it in the association relationship (An, Bn), and associate An with Bn;

[0008] Step 3, take out the number c of sets of Bn n , compared with the number of channel feature single requests d, if c n =d, then execute step 4, then c n <d, then go to step 2;

[0009] Step 4: Assign the set Bn to the corresponding channel group created in step 1 according to the channel characteristics for operator channel interface processing, and clear the Bn message corresponding to An in the association relationship;

[0010] Step 5: When processing messages in a channel group, determine whether the request frequency parameter of the channel group is exceeded. If not, proceed to the next step. If exceeded, wait and process again. After the waiting time T1 is completed, execute step 5 again.

[0011] Step 6: Determine whether there are idle threads in the channel group. If there are idle threads, proceed to the next step. If there are no idle threads, wait and process again. After the waiting time T2 is completed, execute step 6 again.

[0012] Step 7: Execute the operator channel request to update.

[0013] Furthermore, the request frequency in step 1 is the number of valid requests allowed within a limited time based on the capability of the operator's channel.

[0014] Furthermore, the message to be processed Bn in step 2 is a set [B1, B2, ...B n ], the unique identifier An is the set [A1, A2, ...A n ], n is a natural number greater than 1.

[0015] Furthermore, the single request number d in step 3 is the number of IoT card information that the interface allows to be processed simultaneously when a single request is made to the operator channel interface.

[0016] Furthermore, the messages to be processed in the set Bn in step 4 have the same channel characteristics.

[0017] Furthermore, the waiting time T1 in step 5 is: the limited time of the request frequency minus the actual time consumed in processing the number of valid requests, accurate to milliseconds.

[0018] Furthermore, the waiting time T2 in step 6 is: the limited time of the request frequency divided by the number of valid requests of the request frequency, accurate to milliseconds, rounded down.

[0019] A system for dynamically allocating loads based on service capabilities, used to implement the above-mentioned method for dynamically allocating loads based on service capabilities, includes a user end, an operator end radio-connected to the user end, and a server end electrically connected to the operator end, wherein the user end includes a mobile smart product and an Internet of Things card electrically connected to the mobile smart product, the operator end includes a network device, the server end includes a network module and a controller electrically connected to the network module, the controller includes a processing module, a storage module, a judgment module, and a log module electrically connected to the processing module respectively.

[0020] Furthermore, the storage module is used to store the user's pending messages and preset system programs.

[0021] Furthermore, the log module stores update data requested by users, real-time update data of operators and system logs.

[0022] In summary, the technical solution of the present invention has the following beneficial effects:

[0023] This solution addresses the existing sequential query method, which is prone to poor control due to differences in channels, resulting in slow efficiency or request failures. This solution categorizes and groups the characteristics of different operator channels and establishes multiple threads under each group. By assigning the channels of the IoT cards to be processed to different groups for processing, concurrency is controlled, avoiding request failures caused by triggering the request frequency control of the operator channel, effectively reducing ineffective server expenses and improving the timeliness of data updates on the operation support platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments of the present invention. Obviously, the drawings described below only represent a portion of the embodiments of the present invention, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0025] Figure 1 This is a system block diagram of the present invention for dynamically allocating load based on service capabilities.

[0026] Figure 2 The present invention is a flow chart of a method for dynamically distributing load based on service capabilities.

[0027] Description of reference numerals:

[0028] 10-Mobile smart product, 11-Internet of Things card, 20-Network, 30-Network module, 31-Controller, 32-Processing module, 33-Storage module, 34-Judgment module, 35-Log module, 100-User end, 200-Operator end, 300-Server end. DETAILED DESCRIPTION

[0029] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0030] like Figure 2 As shown, a method for dynamically distributing load based on service capabilities is performed according to the following steps:

[0031] S1: Load all carrier channels in the system, group them according to their characteristics, and create threads based on the number of valid requests per request frequency. (The request frequency is the number of valid requests allowed within a time limit based on the carrier channel's capabilities.)

[0032] S2, read the pending messages Bn one by one from the storage unit (e.g., storage module 33), extract the channel unique identifier An in the message request, store it in the association relationship (An, Bn), and associate An with Bn;

[0033] (The pending message Bn is a set [B1, B2, ...B n ], the unique identifier An is the set [A1, A2, ...A n ], n is a natural number greater than 1.)

[0034] S3, take out the number c of sets of Bn n , compared with the number of channel feature single requests d, if c n =d, then execute step 4, then c n <d, then execute S2;

[0035] (The single request number d is the number of IoT card information that the interface allows to be processed simultaneously when making a single request to the operator channel interface.)

[0036] S4: Assign the set Bn to the corresponding channel group created in step 1 according to the channel characteristics for operator channel interface processing, and clear the Bn message corresponding to An in the association relationship;

[0037] (The pending messages in set Bn have the same channel characteristics.)

[0038] S5: When processing messages in a channel group, S5-1 determines whether the request frequency parameter for the channel group is exceeded. If not, the process proceeds to the next step. If so, the process waits and then proceeds again. S5-2 waits for a time T1 before executing S5 again. (The waiting time T1 is the time limit for the request frequency minus the actual time spent processing the number of valid requests, accurate to milliseconds.)

[0039] S6, S6-1 determines whether there is an idle thread in the channel group, if there is an idle thread, proceeds to the next step, if there is no idle thread, waits and then processes again; S6-2 waits for time T2 and then executes S6 again;

[0040] (The waiting time T2 is: the request frequency limit time divided by the number of valid requests for the request frequency, accurate to milliseconds, rounded down.)

[0041] S7, executing the operator channel request to update.

[0042] like Figure 1 As shown, a system for dynamically allocating load based on service capabilities, used to implement the above-mentioned method for dynamically allocating load based on service capabilities, includes a user terminal 100, an operator terminal 200 wirelessly connected to the user terminal 100, and a server terminal 300 electrically connected to the operator terminal 200. The user terminal 100 includes a mobile smart product 10 and an Internet of Things card 11 electrically connected to the mobile smart product 10. The operator terminal 200 includes a network 20. The server terminal 300 includes a network module 30 (such as a network card or optical modem) and a controller 31 electrically connected to the network module 30. The controller 31 includes a processing module 32 (such as a commonly used 51 series single-chip microcomputer, which belongs to the prior art and the specific model and working principle are not described in detail here), a storage module 33, a judgment module 34, and a logging module 35 electrically connected to the processing module 32. The storage module 33 is used to store pending messages from the user terminal and preset system programs. The logging module 35 stores user-requested update data, operator real-time update data, and system logs. The judgment module 34 is used to compare (such as in step 3) or judge (such as in steps 5 and 6) the difference between the request parameters and the preset parameters in the system.

[0043] In summary, the technical solution of the present invention has the following beneficial effects:

[0044] This solution solves the problem of existing sequential query methods, which are prone to poor control due to differences in channels, resulting in slow efficiency or request failures. This solution classifies and groups the characteristics of different operator channels (i.e., channel grouping) and establishes multiple threads under each group (referred to as channel grouping). By assigning the channels of the IoT cards to be processed to different groups (referred to as channel grouping) for processing, concurrency is controlled to avoid request failures caused by triggering the request frequency control of the operator channel, effectively reducing ineffective server expenses and improving the timeliness of data updates on the operation support platform.

[0045] The above-described embodiments do not constitute a limitation on the scope of protection of this technical solution. Any modifications, equivalent replacements, and improvements made within the spirit and principles of the above-described embodiments shall be included in the scope of protection of this technical solution.

Claims

1. A method for dynamically distributing load based on service capability, characterized in that: Follow the steps below: Step 1: Load all the operator channels in the system, group them according to the operator channel characteristics, and create the number of threads according to the number of valid requests of the request frequency; Step 2: Read the pending messages Bn one by one from the storage unit, extract the channel unique identifier An in the message request, store it in the association relationship (An, Bn), and associate An with Bn; Step 3, take out the number c of sets of Bn n , compared with the number of channel feature single requests d, if c n =d, then execute step 4, then c n <d, then go to step 2; Step 4: Assign the set Bn to the corresponding channel group created in step 1 according to the channel characteristics for operator channel interface processing, and clear the Bn message corresponding to An in the association relationship; Step 5: When processing messages in a channel group, determine whether the request frequency parameter of the channel group is exceeded. If not, proceed to the next step. If exceeded, wait and process again. After waiting time T1 is completed, execute step 5 again; Step 6: Determine whether there are idle threads in the channel group. If there are idle threads, proceed to the next step. If there are no idle threads, wait and process again. After the waiting time T2 is completed, execute step 6 again. Step 7: Execute the operator channel request to update; The request frequency mentioned in step 1 is the number of valid requests allowed within a limited time based on the capabilities of the operator's channel; The waiting time T1 in step 5 is: the limit time of the request frequency minus the actual time taken to process the number of valid requests, accurate to milliseconds; The waiting time T2 in step 6 is: the limited time of the request frequency divided by the number of valid requests of the request frequency, accurate to milliseconds, rounded down.

2. The method for dynamically distributing load based on service capability according to claim 1, characterized in that: The message Bn to be processed in step 2 is a set [B1, B2, ... n ], the unique identifier An is the set [A1, A2, ...A n ], n is a natural number greater than 1.

3. The method for dynamically distributing load based on service capability according to claim 1, characterized in that: The single request number d mentioned in step 3 is the number of IoT card information that the interface allows to be processed simultaneously when a single request is made to the operator channel interface.

4. The method for dynamically distributing load based on service capability according to claim 1, characterized in that: The messages to be processed in the set Bn in step 4 have the same channel characteristics.

5. A system for dynamically allocating load based on service capabilities, for implementing the method for dynamically allocating load based on service capabilities as claimed in any one of claims 1 to 4, characterized in that: It includes a user end, an operator end radio-connected to the user end, and a server end electrically connected to the operator end. The user end includes a mobile smart product and an Internet of Things card electrically connected to the mobile smart product. The operator end includes network equipment. The server end includes a network module and a controller electrically connected to the network module. The controller includes a processing module, a storage module, a judgment module, and a log module electrically connected to the processing module respectively.

6. The system for dynamically distributing load based on service capabilities according to claim 5, characterized in that: The storage module is used to store the user's pending messages and preset system programs.

7. The system for dynamically distributing load based on service capabilities according to claim 5, characterized in that: The log module stores update data requested by users, real-time update data of operators and system logs.

Citation Information

Patent Citations

  • Message processing system and message processing method of enterprise service bus

    CN102025650A

  • Short and multimedia message sending method based on middleware platform

    CN102970662A

  • Internet of Things card operation platform, data updating method and device and storage medium

    CN110830548A