Iot card resource scheduling method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of Internet of Things cards, and in particular to an Internet of Things card resource scheduling method and device, electronic equipment and a storage medium. The average bandwidth occupation amount, the bandwidth resource consumption coefficient and the network basic maintenance overhead of each Internet of Things card in a target resource allocation group are determined, the system resource overhead balance threshold value for maintaining the same bandwidth service quality after the card is migrated to other resource allocation groups is calculated, migration is triggered when the average bandwidth occupation amount is greater than the threshold value, the actual bandwidth occupation amount is obtained after migration, and the card is switched back to the original allocation group when the actual bandwidth occupation amount continuously deviates from the balance threshold value and exceeds the tolerance range within a dynamic tracking period, wherein the tracking period is dynamically adjusted according to the historical bandwidth fluctuation amplitude. The application realizes dynamic adaptive scheduling of the Internet of Things card among different resource allocation groups, balances the resource load distribution among the groups, and improves the system resource scheduling efficiency.

Description

Technical Field

[0001] This application relates to the field of IoT card technology, and in particular to an IoT card resource scheduling method, apparatus, electronic device and storage medium. Background Technology

[0002] In the field of the Internet of Things (IoT), the monitoring and management of massive IoT SIM card traffic places extremely high demands on the computing resources and signaling scheduling of communication platforms. Operator platforms typically employ a fixed, static group approach for centralized management of IoT SIM cards.

[0003] Existing group management mechanisms lack the ability to dynamically monitor and adaptively schedule the actual bandwidth usage of IoT cards. When the actual bandwidth usage of a card changes significantly, it remains in its initially assigned group and cannot automatically migrate to a more suitable resource allocation group based on real-time usage data. This results in an uneven distribution of resource load within the card's group, with some groups having excess resources while others are underutilized, thus affecting the overall system's resource scheduling efficiency and network service quality. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, the present invention provides an IoT card resource scheduling method, device, electronic device and storage medium, which can realize dynamic migration and load balancing between resource allocation groups based on the actual bandwidth usage characteristics of IoT cards while maintaining the consistency of bandwidth service levels of each group.

[0005] A first aspect of this application provides an IoT card resource scheduling method, the method comprising: The average bandwidth usage, first bandwidth resource consumption coefficient, and first network infrastructure maintenance overhead of each IoT card in the target resource allocation group to be optimized within a preset time period are determined; the target resource allocation group includes multiple IoT cards and belongs to the same bandwidth resource pool; Determine the system resource overhead balancing threshold required for each IoT card in the target resource allocation group to maintain the same bandwidth service quality after being migrated to other resource allocation groups; the other resource allocation groups are resource allocation groups with the same bandwidth service level as the target resource allocation group. Based on the system resource overhead balancing threshold, it is determined whether each IoT card in the target resource allocation group meets the migration trigger condition; the migration trigger condition is used to indicate that any IoT card is migrated from the current resource allocation group to the other resource allocation group in order to balance the resource load distribution among the groups. When a target IoT card in the target resource allocation group is transferred to another resource allocation group, the total amount of resource processing overhead saved by the system after the target IoT card is migrated is determined; the target IoT card is the set of IoT cards in the target resource allocation group that meet the migration triggering conditions and perform the migration operation; After the target IoT card is migrated to the other resource allocation group, the actual bandwidth usage of the target IoT card in the other resource allocation group is obtained; When it is determined that the actual bandwidth usage continuously deviates from the system resource overhead balance threshold within a preset tracking period, and the degree of deviation exceeds the preset tolerance range, a switchback operation is performed to switch the target IoT card back from the other resource allocation group to the target resource allocation group; The preset tracking period is a dynamically adjusted period, and the adjustment rules of the preset tracking period include: setting an initial tracking period based on the historical bandwidth fluctuation of the target IoT card; if the back-switch operation is triggered within the initial tracking period, the tracking duration of the next period is extended according to the first adjustment step size; if the back-switch operation is not triggered in multiple consecutive tracking periods, the tracking period is gradually shortened according to the second adjustment step size until a preset minimum tracking period threshold is reached.

[0006] In an optional implementation, determining the system resource overhead balancing threshold required for each IoT card in the target resource allocation group to maintain the same bandwidth quality of service after migration to other resource allocation groups includes: Determine the second bandwidth resource consumption coefficient and the second network infrastructure maintenance overhead for the other resource allocation groups; Based on the average bandwidth usage, the first bandwidth resource consumption coefficient, and the first network infrastructure maintenance overhead, the first system resource overhead index of the target IoT card in the current resource allocation group is determined. Based on the average bandwidth usage, the second bandwidth resource consumption coefficient, and the second network infrastructure maintenance overhead, the second system resource overhead index of the target IoT card in the other resource allocation group is determined; When the first system resource overhead indicator is determined to be equal to the second system resource overhead indicator, the target IoT card is transferred to the system resource overhead balance threshold corresponding to the other resource allocation group.

[0007] In an optional implementation, the system resource overhead balancing threshold for transferring the target IoT card to the other resource allocation group when the first system resource overhead index is equal to the second system resource overhead index includes: The system resource overhead balancing threshold is determined using the following formula: , ; make ,but ; have to ; in, The system resource overhead balancing threshold, This refers to the resource overhead index of the first system. The second system resource overhead indicator is L, where L is the average bandwidth usage. This is the first bandwidth resource consumption coefficient. The overhead of maintaining the primary network infrastructure. This is the second bandwidth resource consumption coefficient. This is the maintenance cost for the second network infrastructure.

[0008] In an optional implementation, the method further includes: Compare the average bandwidth usage with the system resource overhead balance threshold; When it is determined that the average bandwidth usage is greater than the system resource overhead balance threshold, the target IoT card is transferred to the other resource allocation group.

[0009] In an optional implementation, when a target IoT card in the target resource allocation group is transferred to another resource allocation group, determining the total amount of resource processing overhead saved for the system after the target IoT card migration includes: Determine the first cumulative system resource overhead value of the target IoT card in the target resource allocation group before the transfer, and the second cumulative system resource overhead value of the target IoT card in the other resource allocation group after the transfer; The total resource processing overhead is determined based on the difference between the first cumulative system resource overhead value and the second cumulative system resource overhead value.

[0010] A second aspect of this application provides an IoT card resource scheduling device, the device comprising: The determination module is used to determine the average bandwidth usage, first bandwidth resource consumption coefficient, and first network infrastructure maintenance overhead of each IoT card in the target resource allocation group to be optimized within a preset time period; the target resource allocation group includes multiple IoT cards belonging to the same bandwidth resource pool; and determines the system resource overhead balance threshold required for each IoT card in the target resource allocation group to maintain the same bandwidth service quality after being migrated to other resource allocation groups; the other resource allocation groups are resource allocation groups with the same bandwidth service level as the target resource allocation group. The judgment module is used to determine whether each IoT card in the target resource allocation group meets the migration trigger condition based on the system resource overhead balance threshold; the migration trigger condition is used to indicate that any IoT card is migrated from the current resource allocation group to the other resource allocation group in order to balance the resource load distribution among the groups. The migration module is used to determine the total amount of resource processing overhead saved by the system after the target IoT card is migrated from the target resource allocation group to the other resource allocation group; the target IoT card is the set of IoT cards in the target resource allocation group that meet the migration triggering conditions and perform the migration operation. The acquisition module is used to acquire the actual bandwidth usage of the target IoT card in the other resource allocation group after the target IoT card is migrated to the other resource allocation group; The rollback module is used to perform a rollback operation when it is determined that the actual bandwidth usage continuously deviates from the system resource overhead balance threshold within a preset tracking period, and the deviation exceeds a preset tolerance range, so as to roll back the target IoT card from the other resource allocation group to the target resource allocation group; wherein, the preset tracking period is a dynamic adjustment period, and the adjustment rules of the preset tracking period include: setting an initial tracking period based on the historical bandwidth fluctuation range of the target IoT card; if the rollback operation is triggered within the initial tracking period, the tracking duration of the next period is extended by a first adjustment step size; if the rollback operation is not triggered for several consecutive tracking periods, the tracking period is gradually shortened by a second adjustment step size until a preset minimum tracking period threshold is reached.

[0011] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the IoT card resource scheduling method.

[0012] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described IoT card resource scheduling method.

[0013] In summary, the IoT card resource scheduling method, apparatus, electronic device, and storage medium provided in this application collect the average bandwidth usage, bandwidth resource consumption coefficient, and network infrastructure maintenance overhead of each IoT card. They calculate the system resource overhead balance threshold after migrating the card to another resource allocation group and compare the actual average bandwidth usage with this threshold to trigger a migration decision. This allows the system to automatically decide whether migration is necessary based on the real-time bandwidth usage characteristics of each card, solving the problem of not being able to automatically migrate based on real-time usage data. Furthermore, after migration, the total resource processing overhead saved by the card for the system is quantified. Combined with the migration trigger condition and the setting of "balancing resource load distribution among groups," cards that meet the conditions are continuously migrated to more suitable resource allocation groups, dynamically adjusting the resource load among groups and solving the problem of uneven resource distribution. After migration, the system continuously acquires the actual bandwidth usage and performs a rollback when the bandwidth deviates from the balance threshold and exceeds the tolerance range. At the same time, the tracking period is dynamically adjusted adaptively based on the historical bandwidth fluctuation range, forming a closed-loop monitoring of "migration → tracking → rollback → period optimization". This ensures that the card bandwidth characteristics can be rolled back in a timely manner after drift, avoiding the continuous negative impact of migration decision failure on system scheduling efficiency and network service quality. This achieves dynamic adaptive scheduling and resource load balancing among resource allocation groups. Attached Figure Description

[0014] Figure 1 This is a schematic diagram illustrating an IoT card resource scheduling process according to an embodiment of this application; Figure 2 This is a functional block diagram of an IoT card resource scheduling device shown in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0015] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0016] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0017] Reference Figure 1 The diagram shown is a flowchart illustrating an IoT card resource scheduling process according to an embodiment of this application. The IoT card resource scheduling includes the following steps.

[0018] S11, determine the average bandwidth usage, first bandwidth resource consumption coefficient, and first network infrastructure maintenance cost of each IoT card in the target resource allocation group to be optimized within a preset time period.

[0019] The target resource allocation group includes multiple IoT cards that belong to the same bandwidth resource pool.

[0020] In some embodiments, the resource allocation group to be optimized is first marked as the target resource allocation group, and the average bandwidth usage of each card in the target resource allocation group is recorded and calculated in real time within a preset time period (e.g., 3 months). The bandwidth resource consumption coefficient and network infrastructure maintenance overhead of each card in the target resource allocation group are then determined. For ease of distinction, the bandwidth resource consumption coefficient of the card in the target resource allocation group is referred to as the first bandwidth resource consumption coefficient, and the network infrastructure maintenance overhead is referred to as the first network infrastructure maintenance overhead.

[0021] It should be noted that the bandwidth resource consumption coefficient characterizes the processing resource consumption rate of the IoT card on the bandwidth resource pool of the target resource allocation group under a unit bandwidth usage. This coefficient is a system-preset resource scheduling parameter, associated with the Service Level Agreement (SLA) configuration of the resource allocation group. Different resource allocation groups can be set with different coefficient values ​​to reflect the differences in system overhead required to process a unit bandwidth. Network infrastructure maintenance overhead characterizes the fixed amount of resources consumed by the system to maintain the connection state when the IoT card remains online and has a session connection with the resource allocation group. This fixed amount of resources is independent of the actual bandwidth usage of the IoT card and includes, but is not limited to, at least one of: session maintenance overhead, heartbeat detection overhead, signaling interaction overhead, and connection state maintenance overhead. Setting the preset time period to 3 months indicates that the traffic usage of IoT devices using the IoT card has basically reached a stable level for IoT card customers. The preset time period can be set according to other actual needs, such as 6 months, 12 months, etc.

[0022] S12, determine the system resource overhead balance threshold required for each IoT card in the target resource allocation group to maintain the same bandwidth service quality after being migrated to other resource allocation groups.

[0023] The other resource allocation groups are those that have the same bandwidth service level as the target resource allocation group.

[0024] In some embodiments, the system queries all candidate other resource allocation groups that have the same bandwidth service level as the target resource allocation group. For each candidate other resource allocation group, the system reads the corresponding bandwidth resource consumption coefficient and network infrastructure maintenance overhead from its resource configuration database. For ease of distinction, the bandwidth resource consumption coefficient of other resource allocation groups is referred to as the second bandwidth resource consumption coefficient, and the network infrastructure maintenance overhead is referred to as the second network infrastructure maintenance overhead. Next, based on the monthly average bandwidth usage of the IoT card in the target resource allocation group, the first bandwidth resource consumption coefficient, and the first network infrastructure maintenance overhead, the system determines the first system resource overhead index of the card in the current resource allocation group. This first system resource overhead index is used to quantitatively characterize the overall consumption level of system processing resources by the card in the current resource allocation group. Similarly, based on the monthly average bandwidth usage of the IoT card, the second bandwidth resource consumption coefficient, and the second network infrastructure maintenance overhead, the system obtains the second system resource overhead index of the card in other resource allocation groups. This second system resource overhead index is used to quantitatively characterize the overall consumption level of system processing resources by the card after it is migrated to other resource allocation groups. By setting the first system resource overhead index equal to the second system resource overhead index, the corresponding monthly average bandwidth usage value can be determined, and this value can be used as the system resource overhead balance threshold.

[0025] Specifically, suppose there is a target group A, which includes an IoT SIM card. Average monthly bandwidth usage L (in Mb) over the past 3 months, bandwidth resource consumption coefficient (RMB / 1024MB*month) Network infrastructure maintenance costs (Yuan / month); Also, assuming there are other resource allocation groups B with the same traffic type (directed traffic), the bandwidth resource consumption coefficient... (RMB / 1024MB*month) Network infrastructure maintenance costs (yuan / month); Among them, card The system resource overhead index for Group A (referred to as the first system resource overhead index) is: ,but ; Card The system resource overhead metric for Group B (referred to as the second system resource overhead metric) is: ,but ; Based on the equal system resource overhead indicators Calculation yields ; Therefore, we can obtain the cards for group A. The system resource overhead balancing threshold for transferring to Group B is: .

[0026] Following the same implementation method described above, assuming there are other resource allocation groups C with the same traffic type (directed traffic), the bandwidth resource consumption coefficient... (RMB / 1024MB*month) Network infrastructure maintenance costs (yuan / month); Zeka In Group A, the system resource overhead metric (referred to as the third system resource overhead metric) is: , ; Based on the equal system resource overhead indicators Calculation yields ; Therefore, we can obtain the cards for group A. The system resource overhead balancing threshold for transferring to Group C is : .

[0027] And so on.

[0028] S13, based on the system resource overhead balance threshold, determine whether each IoT card in the target resource allocation group meets the migration trigger condition.

[0029] The migration trigger condition is used to indicate that any IoT card is migrated from the current resource allocation group to the other resource allocation group in order to balance the resource load distribution among the groups.

[0030] In some embodiments, the system resource overhead balance threshold for transferring any IoT card to another resource allocation group, calculated in step S12 above, is used as a criterion. The average bandwidth usage of each IoT card in the target resource allocation group is calculated and compared with the balance threshold. When the average bandwidth usage is greater than the system resource overhead balance threshold, the IoT card is determined to meet the migration trigger condition and is marked as a target IoT card to be migrated; when the average bandwidth usage is less than or equal to the system resource overhead balance threshold, the IoT card is determined not to meet the migration trigger condition and is retained in the current resource allocation group.

[0031] Specifically, obtain the IoT card The average bandwidth usage L within a preset time period is compared with a system resource overhead balance threshold. If L is greater than the threshold, it indicates that the second system resource overhead index of the card after migrating to another resource allocation group is lower than the first system resource overhead index when it remains in the current resource allocation group. In other words, the system consumes fewer processing resources after migration, and the card is determined to meet the migration trigger condition. A migration tag is generated and the target resource allocation group identifier is recorded. If L is less than or equal to the threshold, it indicates that the system resource overhead of the card in the current resource allocation group is lower or equal. The card is determined not to meet the migration trigger condition, and no migration tag is generated.

[0032] The following combination of criteria determines whether any card in the target resource allocation group should be transferred to another resource allocation group. For ease of understanding, we will use cards in group A as an example. Let's take the transfer to Group B as an example: like When <L, meaning the actual average bandwidth usage of the card is greater than the balancing threshold, the following is calculated: This indicates that the system consumes fewer processing resources after the card is migrated to Group B, confirming that the card meets the migration triggering conditions, and marking the card as the target IoT card to be migrated to Group B; If 0 < L < When the actual average bandwidth usage of the card is less than or equal to the balancing threshold, the following calculation is performed. This indicates that the system consumes less or the same processing resources when the card is in group A, and it is determined that the card does not meet the migration trigger condition, so it is kept in group A. If L≤0, the bandwidth usage cannot be negative or zero, which does not meet the actual application requirements, so it is not suitable for transfer; The scheduling policy for group A is then set as follows: The actual average bandwidth usage is greater than At that time, the card can be used Move to Group B.

[0033] Following the same implementation method described above, the system resource overhead balance threshold for migrating cards from group A to group C is calculated as follows: Then the cards in group A The combination of conditions for determining whether to move to group C is as follows: like When <L, meaning the actual average bandwidth usage of the card is greater than the balancing threshold, the following is calculated: This indicates that the system consumes fewer processing resources after the card is migrated to group C, confirming that the card meets the migration triggering conditions, and marking the card as the target IoT card to be migrated to group C; If 0 < L < When the actual average bandwidth usage of the card is less than or equal to the balancing threshold, the following calculation is performed. This indicates that the system consumes less or the same processing resources when the card is in group A, and it is determined that the card does not meet the migration trigger condition, so it is kept in group A. like If the value is ≤0, then the transfer is not suitable; The scheduling policy for group A is then set as follows: The actual average bandwidth usage is greater than At that time, the card can be used Move to group C.

[0034] Similarly, for N other resource allocation groups (denoted as A, B, C, D, E, F, C, D, F ... Repeat the above judgment logic.

[0035] S14, when the target IoT card in the target resource allocation group is transferred to the other resource allocation group, determine the total amount of resource processing overhead saved by the system after the target IoT card is migrated.

[0036] The target IoT card is the set of IoT cards in the target resource allocation group that meet the migration triggering conditions and perform migration operations.

[0037] In some embodiments, after determining that a card in a target resource allocation group has been transferred to another resource allocation group, a first cumulative system resource overhead value of the target IoT card in the target resource allocation group before the migration, and a second cumulative system resource overhead value of the target IoT card in the other resource allocation group after the migration, can be determined. The difference between the second cumulative system resource overhead value and the first cumulative system resource overhead value is calculated, and this difference is determined as the total resource processing overhead saved for the system after the target IoT card is migrated. The total resource processing overhead is used to quantitatively characterize the amount of processing resources released for the system by this migration operation. This released resource amount can be redistributed to other IoT cards or other system tasks.

[0038] For ease of understanding, let's assume a card from group A is transferred to group B, specifically as follows: The card was transferred from Group A to Group B. , ... The corresponding average monthly bandwidth usage is , ... 'n' represents the number of cards transferred from group A to group B, which is also the target number of IoT cards. During system calculation, for each transferred card... First, calculate its second cumulative system resource overhead value in group B. Then calculate its first cumulative system resource overhead value in group A. Then subtract the two to get the difference in resource consumption before and after the card migration.

[0039] Let the total platform resource processing overhead be ,but: .

[0040] In the above formula, the cumulative system resource overhead difference before and after migration for each migrated card is summed up to obtain the total resource processing overhead saving for this batch of migration operations. If the calculation result is positive, it indicates that the migration operation has saved processing resources for the system overall, and this value is recorded in the resource scheduling log and output as a scheduling benefit evaluation indicator; if the calculation result is negative, it indicates that the migration operation has increased system resource consumption, triggering an alarm and initiating the switchback evaluation process.

[0041] Let's assume the card for transferring from group A to group C is... , ... The corresponding average monthly bandwidth usage is , ... ,but: .

[0042] Similarly, for each target IoT card in target resource allocation group A, the target IoT cards are migrated to N different other resource allocation groups (denoted as...). In the scenario of ), let the j-th other resource allocation group be... The bandwidth resource consumption coefficient is Network infrastructure maintenance costs are The set of IoT cards migrated in this batch is as follows: The corresponding average monthly bandwidth usage is (where m is the number of cards migrated in this batch), calculate the total resource processing overhead for the j-th batch according to the following general formula. : .

[0043] S15, after the target IoT card is migrated to the other resource allocation group, obtain the actual bandwidth usage of the target IoT card in the other resource allocation group.

[0044] In some embodiments, when the target IoT card (such as a card) After migrating from target resource allocation group A to another resource allocation group B, the actual bandwidth usage of the target IoT card in group B is obtained according to a preset sampling frequency (e.g., once per hour), in MB. Specifically, the uplink / downlink bandwidth usage data of the card is read in real time through the API interface of the operator platform to which the IoT card belongs or directly from the billing and data collection gateway of the core network (e.g., the traffic collection interface of PGW / GGSN). The raw data is preprocessed, including removing duplicate reported data packets, eliminating abnormal peak data caused by network jitter, and summing the uplink and downlink bandwidth usage per unit time to obtain the actual bandwidth usage of the card at the sampling time. The preprocessed actual bandwidth usage is compared with a preset tolerance range to determine whether the actual bandwidth usage level of the card is stable. If the actual bandwidth usage exceeds the tolerance range, the subsequent threshold judgment and back-off evaluation process is triggered.

[0045] S16, when it is determined that the actual bandwidth usage continues to deviate from the system resource overhead balance threshold within a preset tracking period, and the degree of deviation exceeds the preset tolerance range, a back-switch operation is performed to switch the target IoT card back from the other resource allocation group to the target resource allocation group.

[0046] The preset tracking period is a dynamically adjusted period, and the adjustment rules of the preset tracking period include: setting an initial tracking period based on the historical bandwidth fluctuation of the target IoT card; if the back-switch operation is triggered within the initial tracking period, the tracking duration of the next period is extended according to the first adjustment step size; if the back-switch operation is not triggered in multiple consecutive tracking periods, the tracking period is gradually shortened according to the second adjustment step size until a preset minimum tracking period threshold is reached.

[0047] In some embodiments, the target IoT card after migration is continuously monitored in units of a preset tracking period. Within each tracking period, the average bandwidth usage of the target IoT card within that period is calculated, and this average bandwidth usage is compared with the system resource overhead balance threshold calculated in step S12. If the average bandwidth usage is lower than the system resource overhead balance threshold, and the duration of the continuous deviation exceeds a preset tolerance range (e.g., below the threshold for 5 consecutive days, with a deviation exceeding ±20%), it is determined that the target IoT card no longer has a resource overhead advantage in the current other resource allocation group, triggering a switchback operation to switch the target IoT card back from the current other resource allocation group to the original target resource allocation group.

[0048] Specifically, a switchback instruction is generated, which includes the target IoT SIM card's card identifier, the source resource allocation group identifier (i.e., the other resource allocation group it is currently in), and the target resource allocation group identifier (i.e., the original target resource allocation group). By calling the operator platform's group management API interface, the target IoT SIM card is moved from the current resource allocation group back to the original target resource allocation group. After the switchback operation is completed, the system writes a switchback record to the resource scheduling log and updates the card's status identifier to "switched back".

[0049] To reduce false back-switching caused by occasional bandwidth fluctuations, the following confirmation logic is executed before triggering the back-switching operation. Specifically, the actual bandwidth usage time-series data of the target IoT card within the current tracking period is obtained, the variance and mean of the series are calculated, and it is determined whether the variance exceeds a preset fluctuation tolerance threshold. If the variance exceeds the fluctuation tolerance threshold, it indicates that the bandwidth fluctuation in the current period is significant, and the back-switching operation is not triggered temporarily; instead, the current tracking period is extended to collect more data samples. If the variance does not exceed the fluctuation tolerance threshold, and the mean continues to deviate from the system resource overhead balance threshold, then the back-switching operation is confirmed to be triggered.

[0050] In some embodiments, to optimize the efficiency and accuracy of IoT card resource scheduling, a dynamic adjustment mechanism for the tracking period is further optimized. This mechanism adaptively adjusts the monitoring granularity based on historical traffic data characteristics, ensuring that the observation period is extended when traffic fluctuations are abnormal to reduce the risk of misjudgment, and the period is shortened when traffic is stable to improve system response speed. Specifically, firstly, based on the historical bandwidth usage data of the target IoT card over the past 3 months, its historical bandwidth fluctuation amplitude (i.e., the ratio of the standard deviation to the mean of the historical daily average bandwidth usage) is calculated, and the initial tracking period is set accordingly. For example, if the historical daily average bandwidth fluctuation amplitude of the card exceeds 30%, it indicates that the card's bandwidth usage behavior is extremely unstable, and the initial tracking period is set to 10 days (a longer observation period to fully collect data); if the fluctuation amplitude is less than 15%, it indicates that the card's bandwidth usage behavior is stable, and the initial tracking period is set to 5 days (a shorter observation period to improve monitoring efficiency). For cards with fluctuation amplitudes between 15% and 30%, the initial tracking period is set using a linear interpolation method, with a value range of 5 to 10 days. Secondly, if a rollback operation is triggered within the initial tracking period (indicating that the current tracking period length is insufficient to accurately reflect the bandwidth usage pattern of the card, and occasional fluctuations cause erroneous rollbacks), the tracking duration of the next period is extended by the first adjustment step (e.g., by 50%). For example, if the initial period is 10 days, it is extended to 15 days due to the rollback trigger. The threshold is re-evaluated within the extended tracking period to increase the data sampling volume and reduce the interference of occasional fluctuations on the evaluation results. Thirdly, if no rollback operation is triggered for several consecutive tracking periods (e.g., two consecutive periods) (indicating that the bandwidth usage pattern of the card matches the balance threshold well within the current tracking period), the tracking period is gradually shortened by the second adjustment step (e.g., by 20% each time), for example, from 10 days to 8 days, then to 6 days, until the preset minimum tracking period threshold (e.g., 3 days) is reached. By gradually shortening the tracking period, the monitoring granularity is adapted to the bandwidth change characteristics of stable cards, improving monitoring efficiency and reducing system resource consumption.

[0051] It should be noted that the first adjustment step size and the second adjustment step size are independently configured. The first adjustment step size is used to extend the period after the back-cut trigger, and the second adjustment step size is used to shorten the period in a stable state. Both can use the same or different adjustment amplitude values. In actual operation, the system can dynamically adjust the specific values ​​of the first and second adjustment step sizes based on the historical back-cut trigger frequency of N consecutive tracking cycles to achieve optimal matching between the tracking cycle and the actual bandwidth usage characteristics of the IoT card.

[0052] By using a dynamic tracking cycle adjustment mechanism, the observation period is extended when bandwidth fluctuations are abnormal to reduce the risk of misjudgment, and the cycle is shortened when bandwidth is stable to improve system response speed, thus realizing an adaptive monitoring strategy of "long-cycle observation when fluctuations are large and short-cycle verification when stability is achieved".

[0053] To facilitate understanding of the inventive concept of this application, a specific example is provided below for detailed illustration: Assume target resource allocation group A (directed traffic, bandwidth quota 300MB / month, bandwidth resource consumption coefficient) =System resource consumption per 300MB / month, network infrastructure maintenance overhead =1 system resource consumption unit / month), transferable group B (directed traffic, unlimited bandwidth quota, bandwidth resource consumption coefficient) =10 system resource consumption units / 1024MB / month, network infrastructure maintenance overhead =0 System Resource Consumption Units / Month), Transferable Group C (Directed Traffic, Bandwidth Quota 2048MB / Month, Bandwidth Resource Consumption Coefficient) =15 system resource consumption units / 2048MB / month, network infrastructure maintenance overhead =0.8 system resource consumption units / month), and assuming that the average bandwidth usage of a certain IoT card in the past 3 months is L MB / month, the system, following the same embodiment in step S12, sets the first system resource consumption index of the card in group A to be equal to the second system resource consumption index of the card in groups B and C, respectively, to obtain the monthly average bandwidth usage thresholds for migration to groups B and C as follows: ; ; When the card's actual monthly average bandwidth usage L is greater than L1, the card's first system resource overhead index in group A is greater than its second system resource overhead index in group B, indicating that the system consumes fewer processing resources after the card is migrated to group B, and the system marks the card as eligible for migration to group B. When the card's actual monthly average bandwidth usage L is less than L2 and greater than 0, the card's first system resource overhead index in group A is greater than its second system resource overhead index (i.e., the third system resource overhead index) in group C, indicating that the system consumes fewer processing resources after the card is migrated to group C, and the system marks the card as eligible for migration to group C. When the card's actual monthly average bandwidth usage L is between L2 and L1, the card's system resource overhead index in group A is the lowest, and the system retains the card in group A.

[0054] Reference Figure 2 The diagram shown is a functional block diagram of an IoT card resource scheduling device according to an embodiment of this application.

[0055] In some embodiments, the IoT card resource scheduling device 20 may include multiple functional modules composed of computer program segments. The computer programs of each program segment of the IoT card resource scheduling device 20 may be stored in the memory of an electronic device and executed by at least one processor to perform (see details). Figure 1 (Description) The function of IoT card resource scheduling. Based on the functions it performs, it can be divided into multiple functional modules. These functional modules may include: a determination module 201, a judgment module 202, a migration module 203, an acquisition module 204, and a switchback module 205. The module referred to in this application is a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0056] The determining module 201 is used to determine the average bandwidth usage, first bandwidth resource consumption coefficient, and first network infrastructure maintenance overhead of each IoT card in the target resource allocation group to be optimized within a preset time period; the target resource allocation group includes multiple IoT cards and belongs to the same bandwidth resource pool; and determines the system resource overhead balance threshold required for each IoT card in the target resource allocation group to maintain the same bandwidth service quality after being migrated to other resource allocation groups; the other resource allocation groups are resource allocation groups with the same bandwidth service level as the target resource allocation group.

[0057] The judgment module 202 is used to determine whether each IoT card in the target resource allocation group meets the migration trigger condition based on the system resource overhead balance threshold; the migration trigger condition is used to indicate that any IoT card is migrated from the current resource allocation group to the other resource allocation group in order to balance the resource load distribution among the groups.

[0058] The migration module 203 is used to determine the total amount of resource processing overhead saved by the system after the target IoT card is migrated from the target resource allocation group to the other resource allocation group; the target IoT card is the set of IoT cards in the target resource allocation group that meet the migration triggering conditions and perform migration operations.

[0059] The acquisition module 204 is used to acquire the actual bandwidth usage of the target IoT card in the other resource allocation group after the target IoT card is migrated to the other resource allocation group.

[0060] The back-switching module 205 is used to perform a back-switching operation when it is determined that the actual bandwidth usage continuously deviates from the system resource overhead balance threshold within a preset tracking period, and the deviation exceeds a preset tolerance range, so as to switch the target IoT card back from the other resource allocation group to the target resource allocation group; wherein, the preset tracking period is a dynamic adjustment period, and the adjustment rules of the preset tracking period include: setting an initial tracking period based on the historical bandwidth fluctuation range of the target IoT card; if the back-switching operation is triggered within the initial tracking period, the tracking duration of the next period is extended according to a first adjustment step size; if the back-switching operation is not triggered for several consecutive tracking periods, the tracking period is gradually shortened according to a second adjustment step size until a preset minimum tracking period threshold is reached.

[0061] It should be understood that the various variations and specific embodiments of the IoT card resource scheduling method provided in the above embodiments are also applicable to the IoT card resource scheduling device of this embodiment. Through the foregoing detailed description of the IoT card resource scheduling method, those skilled in the art can clearly understand the implementation method of the IoT card resource scheduling device in this embodiment. For the sake of brevity, it will not be described in detail here.

[0062] See Figure 3 The diagram shown is a schematic representation of the structure of an electronic device according to an embodiment of this application. In a preferred embodiment of this application, the electronic device 3 includes a memory 31, at least one processor 32, and at least one communication bus 33.

[0063] Those skilled in the art should understand that Figure 3 The structure of the electronic device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The electronic device 3 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0064] In some embodiments, the electronic device 3 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The electronic device 3 may also include user equipment, which includes, but is not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0065] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

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

[0067] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0068] If the integrated module is implemented as a software functional module 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 the present invention, 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.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drive, portable hard drive, read-only memory (ROM). Various media that can store program code, such as only memory, random access memory (RAM), magnetic disks or optical disks.

[0069] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0070] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0071] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for scheduling IoT card resources, characterized in that, The method includes: The average bandwidth usage, first bandwidth resource consumption coefficient, and first network infrastructure maintenance overhead of each IoT card in the target resource allocation group to be optimized within a preset time period are determined; the target resource allocation group includes multiple IoT cards and belongs to the same bandwidth resource pool; Determine the system resource overhead balancing threshold required for each IoT card in the target resource allocation group to maintain the same bandwidth service quality after being migrated to other resource allocation groups; the other resource allocation groups are resource allocation groups with the same bandwidth service level as the target resource allocation group. Based on the system resource overhead balancing threshold, it is determined whether each IoT card in the target resource allocation group meets the migration trigger condition; the migration trigger condition is used to indicate that any IoT card is migrated from the current resource allocation group to the other resource allocation group in order to balance the resource load distribution among the groups. When a target IoT card in the target resource allocation group is transferred to another resource allocation group, the total amount of resource processing overhead saved by the system after the target IoT card is migrated is determined; the target IoT card is the set of IoT cards in the target resource allocation group that meet the migration triggering conditions and perform the migration operation; After the target IoT card is migrated to the other resource allocation group, the actual bandwidth usage of the target IoT card in the other resource allocation group is obtained; When it is determined that the actual bandwidth usage continuously deviates from the system resource overhead balance threshold within a preset tracking period, and the degree of deviation exceeds the preset tolerance range, a switchback operation is performed to switch the target IoT card back from the other resource allocation group to the target resource allocation group; The preset tracking period is a dynamically adjusted period, and the adjustment rules of the preset tracking period include: setting an initial tracking period based on the historical bandwidth fluctuation of the target IoT card; if the back-switch operation is triggered within the initial tracking period, the tracking duration of the next period is extended according to the first adjustment step size; if the back-switch operation is not triggered in multiple consecutive tracking periods, the tracking period is gradually shortened according to the second adjustment step size until a preset minimum tracking period threshold is reached.

2. The IoT card resource scheduling method according to claim 1, characterized in that, The system resource overhead balancing threshold required to maintain the same bandwidth service quality for each IoT card in the target resource allocation group after migration to other resource allocation groups includes: Determine the second bandwidth resource consumption coefficient and the second network infrastructure maintenance overhead for the other resource allocation groups; Based on the average bandwidth usage, the first bandwidth resource consumption coefficient, and the first network infrastructure maintenance overhead, the first system resource overhead index of the target IoT card in the current resource allocation group is determined. Based on the average bandwidth usage, the second bandwidth resource consumption coefficient, and the second network infrastructure maintenance overhead, the second system resource overhead index of the target IoT card in the other resource allocation group is determined; When the first system resource overhead indicator is determined to be equal to the second system resource overhead indicator, the target IoT card is transferred to the system resource overhead balance threshold corresponding to the other resource allocation group.

3. The IoT card resource scheduling method according to claim 2, characterized in that, The system resource overhead balancing threshold for transferring the target IoT card to the other resource allocation group when the first system resource overhead index is equal to the second system resource overhead index includes: The system resource overhead balancing threshold is determined using the following formula: ， ； make ,but ; have to ; in, The system resource overhead balancing threshold, This refers to the resource overhead index of the first system. This refers to the resource overhead metric of the second system. L This refers to the average bandwidth usage. This is the first bandwidth resource consumption coefficient. The overhead of maintaining the primary network infrastructure. This is the second bandwidth resource consumption coefficient. This is the maintenance cost for the second network infrastructure.

4. The IoT card resource scheduling method according to claim 2, characterized in that, The method further includes: Compare the average bandwidth usage with the system resource overhead balance threshold; When it is determined that the average bandwidth usage is greater than the system resource overhead balance threshold, the target IoT card is transferred to the other resource allocation group.

5. The IoT card resource scheduling method according to claim 1, characterized in that, When a target IoT card in the target resource allocation group is transferred to another resource allocation group, the total amount of resource processing overhead saved for the system after the target IoT card migration includes: Determine the first cumulative system resource overhead value of the target IoT card in the target resource allocation group before the transfer, and the second cumulative system resource overhead value of the target IoT card in the other resource allocation group after the transfer; The total resource processing overhead is determined based on the difference between the first cumulative system resource overhead value and the second cumulative system resource overhead value.

6. An IoT card resource scheduling device, characterized in that, The device includes: The determination module is used to determine the average bandwidth usage, first bandwidth resource consumption coefficient, and first network infrastructure maintenance overhead of each IoT card in the target resource allocation group to be optimized within a preset time period; the target resource allocation group includes multiple IoT cards belonging to the same bandwidth resource pool; and determines the system resource overhead balance threshold required for each IoT card in the target resource allocation group to maintain the same bandwidth service quality after being migrated to other resource allocation groups; the other resource allocation groups are resource allocation groups with the same bandwidth service level as the target resource allocation group. The judgment module is used to determine whether each IoT card in the target resource allocation group meets the migration trigger condition based on the system resource overhead balance threshold; the migration trigger condition is used to indicate that any IoT card is migrated from the current resource allocation group to the other resource allocation group in order to balance the resource load distribution among the groups. The migration module is used to determine the total amount of resource processing overhead saved by the system after the target IoT card is migrated from the target resource allocation group to the other resource allocation group; the target IoT card is the set of IoT cards in the target resource allocation group that meet the migration triggering conditions and perform the migration operation. The acquisition module is used to acquire the actual bandwidth usage of the target IoT card in the other resource allocation group after the target IoT card is migrated to the other resource allocation group; The rollback module is used to perform a rollback operation when it is determined that the actual bandwidth usage continuously deviates from the system resource overhead balance threshold within a preset tracking period, and the deviation exceeds a preset tolerance range, so as to roll back the target IoT card from the other resource allocation group to the target resource allocation group; wherein, the preset tracking period is a dynamic adjustment period, and the adjustment rules of the preset tracking period include: setting an initial tracking period based on the historical bandwidth fluctuation range of the target IoT card; if the rollback operation is triggered within the initial tracking period, the tracking duration of the next period is extended by a first adjustment step size; if the rollback operation is not triggered for several consecutive tracking periods, the tracking period is gradually shortened by a second adjustment step size until a preset minimum tracking period threshold is reached.

7. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the IoT card resource scheduling method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the IoT card resource scheduling method according to any one of claims 1 to 5.

Images