A cloud card resource dynamic scheduling method and device and electronic equipment

Abstract

The embodiment of the application provides a cloud card resource dynamic scheduling method and device and electronic equipment, the method comprises the following steps: monitoring a main link state, and acquiring a link quality score of the main link; when the link quality score of the main link meets a first preset condition or a specific service is monitored, a cloud card starting instruction carrying a resource configuration parameter is sent to a cloud card module, triggering the cloud card resource state of the cloud card module to switch to a preheating state; when the key service traffic of the main link meets a second preset condition, triggering the cloud card resource state of the cloud card module to switch from the preheating state to a bearing state, and switching the key service traffic to a cloud card network. The embodiment of the application performs on-demand loading and on-demand release on the cloud card resource based on link state sensing, the cloud card does not stay in a high-cost standby state for a long time in a non-fault period, reduces signaling traffic and power consumption, and significantly reduces the cost and standby power consumption of the backup side while ensuring the continuity of the key service.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and more specifically, to a method, apparatus, and electronic device for dynamic scheduling of cloud card resources. Background Technology

[0002] Currently, most traditional devices or systems provide backup networks through dual-mode devices in order to maintain network stability when encountering network failures, meaning that broadband and mobile networks coexist.

[0003] Existing dual-mode devices generally adopt a hot standby approach of "cloud SIM card always online, cellular module continuously attached". To ensure that the backup link is always available, the mobile cellular module usually needs to be kept online. Even if the main broadband is normal, the backup mobile network resources are always occupied. In other words, the cloud SIM card is in a high-cost standby state for a long time during non-fault periods, continuously generating channel service fees and heartbeat traffic fees, which makes the contradiction between high service availability and tariffs and energy consumption increasingly prominent. Moreover, the mobile network module needs to maintain signaling interaction with the base station, which will continuously generate signaling traffic and power consumption, such as location updates and paging monitoring. The radio frequency circuit cannot enter deep sleep. For power-sensitive industrial terminals, this hot standby mode significantly increases the power consumption of the whole device, affecting the device's battery life or heat dissipation design. Summary of the Invention

[0004] The cloud card resource dynamic scheduling method, device, and electronic device provided in this application provide a control strategy for on-demand activation and complete release of cloud card resources in the cloud, which significantly reduces the cost and standby power consumption on the backup side while ensuring the continuity of critical services.

[0005] In a first aspect, embodiments of this application provide a method for dynamic scheduling of cloud card resources, applied to a main control unit, the method comprising: Monitor the status of the main link and obtain the link quality score of the main link; When the link quality score of the main link meets the first preset condition or a specific service is detected, a cloud card start command carrying resource configuration parameters is sent to the cloud card module, triggering the cloud card resource status of the cloud card module to switch to the preheating state. When the critical service traffic of the main link meets the second preset condition, the cloud card resource status of the cloud card module is triggered to switch from the preheating state to the carrying state, and the critical service traffic is switched to the cloud card network.

[0006] Secondly, embodiments of this application provide a method for dynamic scheduling of cloud card resources, applied to a cloud card module, the method comprising: When the link quality score of the main link meets the first preset condition or the main control unit detects a specific service, the cloud card start command carrying resource configuration parameters sent by the main control unit is received, and the cloud card resource status of the cloud card module is switched to the preheating state. When the critical service traffic of the main link meets the second preset condition, the cloud card resource status of the cloud card module switches from the preheating state to the carrying state, and the critical service traffic is switched to the cloud card network.

[0007] Thirdly, this application provides a cloud card resource dynamic scheduling device, which is located in the main control unit and includes: a monitoring module, a triggering module, and a switching module; The monitoring module is used to monitor the status of the main link and obtain the link quality score of the main link; The triggering module is used to send a cloud card start command carrying resource configuration parameters to the cloud card module when the link quality score of the main link meets the first preset condition or a specific service is detected, thereby triggering the cloud card resource status of the cloud card module to switch to the preheating state. The switching module is used to trigger the cloud card resource status of the cloud card module to switch from the preheating state to the carrying state when the critical service traffic of the main link meets the second preset condition, and to switch the critical service traffic to the cloud card network.

[0008] Fourthly, this application provides a cloud card resource dynamic scheduling device, which is located in the cloud card module and includes a startup module and a switching module. The startup module is used to receive a cloud card startup command carrying resource configuration parameters sent by the main control unit when the link quality score of the main link meets the first preset condition or the main control unit detects a specific service, and to switch the cloud card resource status of the cloud card module to a preheating state. The switching module is used to switch the cloud card resource status of the cloud card module from the preheating state to the carrying state when the critical service traffic of the main link meets the second preset condition, and to switch the critical service traffic to the cloud card network.

[0009] Fifthly, embodiments of this application provide an electronic device, the electronic device comprising: A processor, a memory, and a computer program stored in the memory and executable on the processor; the processor, when executing the computer program, implements the methods provided in the first or second aspect described above.

[0010] In a sixth aspect, embodiments of this application provide a machine-readable storage medium having executable instructions stored thereon, which, when executed by a machine, cause the methods provided in the first or second aspect to be implemented.

[0011] In a seventh aspect, embodiments of this application also provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the methods provided in the first or second aspect of embodiments of this application described above.

[0012] This invention implements on-demand loading and release of cloud card resources based on link status awareness. The cloud card will not be in a high-cost standby state for a long time during non-fault periods. Reducing signaling traffic and power consumption significantly reduces the cost and standby power consumption on the backup side while ensuring the continuity of critical services. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. However, those skilled in the art should understand that the drawings described below are merely some examples of this application and do not limit its scope.

[0014] Figure 1 This is a schematic diagram of a cloud card resource dynamic scheduling method applied to a main control unit, according to an embodiment.

[0015] Figure 2 This is another flowchart illustrating a cloud card resource dynamic scheduling method applied to a main control unit, according to one embodiment.

[0016] Figure 3 This is a schematic diagram of a dynamic scheduling method for cloud card resources applied to a cloud card module, provided according to one embodiment.

[0017] Figure 4 This is another flowchart illustrating a cloud card resource dynamic scheduling method applied to a cloud card module, according to one embodiment.

[0018] Figure 5 This is a schematic diagram of the structure of a cloud card resource dynamic scheduling device according to one embodiment; Figure 6 This is another structural schematic diagram of a cloud card resource dynamic scheduling device provided according to one embodiment; Figure 7 This is a schematic block diagram of the structure of an electronic device provided according to one embodiment. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Those skilled in the art should understand that the described embodiments are only some, not all, of the embodiments of this invention. Based on the embodiments in this application, those skilled in the art can make any appropriate modifications or variations to obtain all other embodiments.

[0020] Currently, dual-mode devices generally adopt the hot standby approach of "cloud SIM card being online for a long time and cellular module being continuously attached". During non-faulty periods, the cloud SIM card is in a high-cost standby state for a long time, continuously generating channel service fees and heartbeat traffic fees. Moreover, the mobile network module needs to maintain signaling interaction with the base station, which will continuously generate signaling traffic and power consumption. The radio frequency circuit cannot enter deep sleep. For power-sensitive industrial terminals, such as IoT sensors and wireless data acquisition devices, this not only significantly increases the overall power consumption, but also affects the device's battery life or heat dissipation design.

[0021] The above technical solution will be described in detail below with reference to specific embodiments.

[0022] In a first aspect, embodiments of the present invention provide a dynamic scheduling method for cloud card resources, applied to a main control unit, such as... Figure 1 As shown, the method includes: Step 101: Monitor the status of the main link and obtain the link quality score of the main link; Step 102: When the link quality score of the main link meets the first preset condition or a specific service is detected, send a cloud card start command carrying resource configuration parameters to the cloud card module to trigger the cloud card resource status of the cloud card module to switch to the preheating state. The main control unit sends a cloud card startup command carrying resource configuration parameters to the cloud card module, switching the cloud card resource lifecycle status to a preheating state. In the preheating state, the cloud card module requests and loads basic resources from the cloud server, completes IP address allocation and control plane connection establishment, but does not carry business data for the time being.

[0023] Step 103: When the critical service traffic of the main link meets the second preset condition, the cloud card module's cloud card resource status is triggered to switch from the preheating state to the carrying state, and the critical service traffic is switched to the cloud card network.

[0024] The cloud card resource dynamic scheduling scheme provided in this embodiment of the invention starts cloud card resources on demand based on link status awareness. In this way, the cloud card module does not need to be in standby mode during non-fault periods, which significantly reduces the cost and standby power consumption on the backup side while ensuring the continuity of critical services.

[0025] The following details the dynamic scheduling method for cloud card resources provided in this proposal, such as... Figure 2 As shown, the method includes: Step 201: Monitor the status of the main link and obtain the link quality score of the main link; In this embodiment of the invention, the main control unit monitors the status of the main link. The main control unit can be the main control terminal of a CPE (Customer Premise Equipment) system, an industrial IoT gateway terminal, or other terminals. The main control unit monitors the status of the main link based on LQS (Link Quality Score) and an adaptive anti-jitter mechanism. LQS is related to packet loss rate, round-trip time, latency jitter, throughput, and historical stability weights. Each indicator is normalized to the [0,1] range.

[0026] In this embodiment of the invention, the LQS of the main link is positively correlated with round-trip latency, throughput, and historical stability weight, and negatively correlated with packet loss rate and latency jitter.

[0027] As one example, LQS = w1×(1-packet loss rate) + w2×RTT_norm + w3×(1-Jitter_norm) + w4×throughput_norm + w5×historical stability index, where RTT_norm represents normal round-trip time, Jitter_norm represents normal latency jitter, each index is normalized to the [0,1] interval, and w1-w5 represent the corresponding weights, which are pre-configured according to the service type or determined through offline training.

[0028] This invention provides an adaptive anti-shake mechanism, specifically, a dynamic anti-shake observation period is obtained by superimposing the number of link oscillations on the base observation period.

[0029] As one implementation, the dynamic stabilization observation period T_obs = T_base × (1 + α × N_flap), where T_base is the base observation period, T_obs is the dynamic stabilization observation period, representing the actual observation duration, N_flap is the number of link oscillations detected within the most recent sliding window, representing the number of cycles in which the LQS drops below the threshold and recovers within the most recent sliding window, directly determining how many times the dynamic stabilization observation period is extended, and α is a positive coefficient that always satisfies T_obs ≥ T_base. When the link is stable for a long time, such as when the LQS is higher than the threshold for M consecutive cycles, T_obs will gradually decrease back to T_base.

[0030] Step 202: When the LQS of the main link meets the first preset condition or detects a specific service, it sends a cloud card start command carrying resource configuration parameters to the cloud card module, triggering the cloud card resource status of the cloud card module to switch to the preheating state.

[0031] In this embodiment of the invention, the cloud card module's cloud card resource lifecycle states include multiple states: unloaded state, preheating state, bearing state, low-power standby state, and release state.

[0032] The unloaded state is the initial state of cloud card resources. The cloud card module is completely turned off or dormant, does not occupy any cloud resources, and does not incur any fees. In the unloaded state, there is no IP address, no signaling connection, and the radio frequency is turned off.

[0033] The preheating state is a new state proposed in this embodiment of the invention, which can be understood as an intermediate state between fully off and fully on for the cloud SIM card module. In the preheating state, network registration and authentication, as well as IP address allocation, are completed, but the data channel is suspended and no service data is transmitted. That is, in the preheating state, the cloud SIM card module requests and loads basic resources from the cloud server, completes IP address allocation and control plane connection establishment, but does not yet carry service data. This eliminates the slowest authentication process, shortening the switching time and avoiding premature traffic charges.

[0034] The bearer status is the working state of the cloud card module, which carries critical business traffic. In the bearer status, the data channel is activated, the routing table points to the cloud card interface, and billing begins.

[0035] Low-power standby mode refers to a state where the service has just switched back to the main link, but the cloud card has not yet been fully released and remains in a ready-to-use state. In low-power standby mode, the IP remains unchanged, the session context is retained, only a very small number of heartbeats are maintained, the radio frequency enters a power-saving mode of discontinuous reception, and the cloud card module is in low-power standby mode. This can prevent the main link from being interrupted again after being restored, avoid repeated time-consuming cloud card application processes, and utilize the remaining time within the usage period for tasks such as log transmission.

[0036] The "Release" state indicates that the cloud SIM network has been completely deactivated, returning to its initial state. In the Release state, the virtual SIM identifier is deactivated, billing ceases, and the module's radio frequency is turned off.

[0037] In this embodiment of the invention, the cloud card module's cloud card resource status is switched to a preheating state if and only if any of the following conditions are met: (1) Predictive preheating: Although the main link LQS is not lower than Th_low, it shows a rapid downward trend, that is, the slope is less than the preset threshold, and it is predicted that it will fall below the threshold within the T_preheat time. Th_low is the main link fault threshold, and T_preheat is the preheating prediction time window.

[0038] (2) Fault response warm-up: The main link LQS is lower than Th_low, T_pred is greater than the minimum overhead time for cloud card module startup, and the cloud card link LQS is higher than the threshold Th_high, Th_high≥Th_low, where Th_high is the cloud card availability threshold and T_pred is the predicted interruption duration.

[0039] (3) Business-driven warm-up: When a high-priority business is detected, such as an emergency alarm initiating a connection request, warm-up is forcibly started regardless of the current status of the main link in order to prepare for unforeseen circumstances.

[0040] As one embodiment, corresponding to the above-described predictive preheating or fault response preheating, the LQS of the main link satisfies a first preset condition, specifically including: The LQS of the main link is not less than the preset Th_low, and the decreasing trend of the LQS of the main link satisfies the third preset condition, or... Based on the current time and fault type when the main link fails, the T_pred of the main link is predicted. The LQS of the main link is less than the preset Th_low, and the T_pred is greater than the preset threshold. The LQS of the cloud card link is greater than the preset Th_high, and Th_high ≥ Th_low.

[0041] Specifically, the third preset condition is that the slope of the main link LQS is less than the preset threshold, and it is predicted that it will fall below the threshold within the T_preheat time; the T_pred of the main link is greater than the preset threshold, specifically T_pred is greater than the minimum overhead time for the cloud card module to start.

[0042] Among them, Th_low is the primary link failure threshold. When the primary link LQS is lower than the threshold Th_low, it means that the current primary link quality is so poor that the network must be switched. Th_high is the cloud card link threshold. When the backup link LQS is higher than the threshold Th_high, it means that the cloud card quality is good enough to be used. The condition Th_high≥Th_low is to prevent switching to a worse backup link. T_preheat is the preheating prediction time window, which represents the time range of the system's forward prediction. In other words, it indicates that the link may break within T_preheat. The actual optimal value can be 10-15 seconds. In order to give the cloud card enough lead time to start up, T_pred is the duration of the primary link failure.

[0043] Based on the current time and fault type when the main link failure occurred, predict the duration T_pred of this main link failure, including: Based on the current time and fault type, the average duration of the corresponding historical records is obtained by matching them in the preset historical fault feature library; based on the average duration of the matched historical records, the maximum historical duration of the main control unit, and the confidence weight, the duration of the current fault in the main link is predicted.

[0044] Specifically, the main control unit maintains a historical fault feature database, which records the feature information of the past N main link faults. This feature information includes at least the time period of the fault, the fault type, and / or the duration.

[0045] When this fault is detected, based on the current time and fault type, multiple similar historical records are matched in the historical fault feature database. The duration of each matched historical record is obtained, and the average duration of the matched historical records is calculated based on the duration of each historical record.

[0046] The predicted downtime of the main link, i.e. the duration of the current failure of the main link, is T_pred = β×T_avg + (1 -β)×T_max, where T_avg is the average duration of the matched historical records, T_max is the maximum duration of the matched historical records, and β is the confidence weight, 0 <β < 1.

[0047] If T_pred is less than the minimum usage unit or minimum billing unit of the cloud card, then the short-cycle package will be used first or only preheating will be performed; if T_pred is longer, then the long-cycle preferential package will be used.

[0048] In practice, the LQS score range is usually normalized to 0-100 points. The optimal value of Th_low can be 60 points, the optimal value of Th_high can be 70 points, and Th_high≥Th_low; the optimal value of Th_back can be 80 points, and Th_back>Th_low. By providing Th_back, a hysteresis interval is constructed to avoid the system from repeatedly jumping when the LQS score fluctuates around 60 points.

[0049] In practical applications, different service types correspond to different main link failure thresholds and anti-jitter observation periods. For real-time control services, a higher Th_low and a shorter T_obs are used; for large file transfer services, a lower threshold and a longer observation period are used; for transaction payment services, a high Th_low and a short T_obs are used; and for streaming media / video surveillance services, a medium Th_low and a medium T_obs are used.

[0050] Preferably, if the duration of the main link failure T_pred is less than the minimum usage unit or minimum billing unit of the cloud card, a short-cycle package or only preheating is used; otherwise, a long-cycle preferential package is used.

[0051] As one example, in the case of the above-mentioned business-driven preheating, the specific business detected is: high-priority business, such as an emergency alarm initiating a connection request.

[0052] The specific operation of the main control unit of this invention sending a cloud card start command carrying resource configuration parameters to the cloud card module, triggering the cloud card module to switch the cloud card resource status to the preheating state, is as follows: The main control unit selects the corresponding cloud card resource configuration parameters based on the usage granularity information or billing granularity information from the cloud card operation side, as well as the predicted duration of the main link failure. These cloud card resource configuration parameters include, but are not limited to, bandwidth level, usage period, and service priority. The main control unit sends a cloud card startup command carrying resource configuration parameters to the cloud card module, triggering the cloud card module's cloud card resource status to switch to a preheating state. In other words, the cloud card resource lifecycle state is switched from an unloaded state to a preheating state. In the preheating state, the cloud card module requests and loads virtual SIM resources from the cloud server, completes network registration and authentication, establishes an RRC signaling connection, and completes IP address allocation and control plane connection establishment. Afterward, it proactively suspends data bearer activation or issues a flow table policy at the gateway that only allows management messages, ensuring that no billing traffic is generated even with a physical connection, and that service data is not carried temporarily. The module then sends a Preheat_Ready signal to the main control unit, entering a standby mode to await the activation command.

[0053] Step 203: When the critical service traffic of the main link meets the second preset condition, the cloud card module's cloud card resource status is triggered to switch from the preheating state to the carrying state, and the critical service traffic is switched to the cloud card network.

[0054] As one example, the critical service traffic of the main link meets the second preset condition, specifically including: the queuing length of the critical service on the main link or the proportion of real-time service traffic reaches a preset ratio.

[0055] The cloud card module is triggered to switch its cloud card resource status from the preheating state to the bearer state, and critical service traffic is switched to the cloud card network. Specifically, the main control unit triggers the cloud card module to switch its cloud card resource status from the preheating state to the bearer state. The cloud card module establishes cellular data bearer based on the resource configuration parameters. The main control unit switches critical service traffic to the cloud card network first by modifying the system routing table or policy routing.

[0056] Step 204: When the LOS of the main link is greater than the preset main link back-off threshold, determine whether the critical business traffic should continue to be carried on the cloud card network based on the LOS of the main link, the preset main link failure threshold Th_low, the preset main link back-off threshold Th_back, and whether the main link has experienced an oscillation event.

[0057] As one example, when the main link LQS is detected to rise and exceed the preset main link back-off threshold Th_back, the main control unit does not immediately release cloud card resources, but instead initiates an adaptive anti-jitter observation period: Based on the aforementioned T_obs as the current observation period for stabilization, multi-dimensional LQS testing is continuously performed on the main link within T_obs. Link oscillation events are identified by statistically analyzing LQS variance and threshold crossing counts based on a sliding time window. Oscillation events include situations where LQS repeatedly crosses between Th_low and Th_back. Th_back is the main link back-cut threshold, indicating the extent to which the main link quality must recover before a switchback is allowed. It must satisfy Th_back > Th_low. The optimal value for Th_back is 80 points to avoid repeated system jumps caused by fluctuations in the main link's LQS around Th_low.

[0058] Determine whether critical business traffic should continue to be carried on the cloud SIM card network, including: During the preset anti-shake observation period, if an oscillation event occurs on the main link, or if no oscillation event occurs on the main link and the link quality score of the main link is less than the preset main link failure threshold, the anti-shake observation period is reset to ensure that critical business traffic continues to be carried on the cloud card network. During the preset anti-shake observation period, when no oscillation event occurs on the main link and the link quality score of the main link is continuously greater than the preset main link back-switch threshold, the critical business traffic is carried on the main link.

[0059] In practical applications, when the main link LQS is detected to fall below Th_low again or a new link oscillation event occurs within T_obs, T_obs is reset to ensure that critical business traffic continues to be carried on the cloud card network and the cloud card resource status remains in the carrying state. The main control unit initiates the lossless back-switch process only when the main link LQS remains higher than Th_back throughout the entire T_obs and no new oscillations are detected. In other words, critical business traffic is no longer carried on the cloud card network, but is switched back to the main link.

[0060] The lossless rollback process specifically includes: sending critical business data simultaneously through the main link and the cloud card network within a preset parallel carrying time T_mbb; the receiving side discards duplicate data packets based on the data packet sequence number or deduplication mark, thereby achieving a smooth rollback without the business being aware of it.

[0061] Step 205: After critical business traffic is no longer carried on the cloud SIM card network, but on the main link, the main control unit will downgrade the cloud SIM card resource status from the carrying state to the low-power standby state. In the low-power standby state, only the necessary session context and a small number of heartbeat connections are retained.

[0062] Step 206: Continuously monitor the link quality score of the main link and the usage time of the cloud card. Based on the link quality score of the main link, the usage time of the cloud card, the preset first time threshold of the main link, and the preset usage cycle of the cloud card, determine whether to send a release command to the cloud card module.

[0063] Specifically, determining whether to send a release command to the cloud card module includes: Within a preset first time threshold, if the usage time of the cloud card is not less than the preset cloud card usage cycle, a cloud card release command is sent to the cloud card module, and the cloud card module releases cloud resources, or... If, within the preset first time threshold, the usage time of the cloud card is less than the preset cloud card usage period, and the link quality score of the main link is continuously greater than the preset first time threshold of the main link, after completing the upload of non-critical business traffic based on the remaining bandwidth within the cloud card usage period, a cloud card release command is sent to the cloud card module, and the cloud card module releases cloud resources.

[0064] In this step, if the main link LQS remains above the preset first time threshold T_release and no new faults occur within the preset first time threshold, and the current cloud card usage period has not yet ended, the main control unit can choose to use the remaining bandwidth to complete the data retransmission or log upload for non-critical services within this usage period, based on the remaining usage time and cloud card bandwidth. When the current cloud card usage period ends (i.e., the cloud card usage time is not less than the preset cloud card usage period, i.e., the current cloud card billing period ends (i.e., the cloud card billing time is not less than the preset cloud card billing period), a cloud card release command is sent to the cloud card module, and the cloud card module releases cloud resources.

[0065] When the main link is detected to be stable within T_release and the current cloud card usage cycle is about to end, the main control unit sends a cloud card release command to the cloud card module, switching the cloud card resource lifecycle state from low-power standby state to release state. The cloud card module responds to the control command and completely releases the cloud resources, and the terminal device no longer incurs continuous tariffs and power consumption overhead related to the cloud card.

[0066] In this embodiment of the invention, T_release represents the first time threshold of the main link, which can be called the stable time threshold, i.e., the stable release duration. It means that after switching back to the main link, it continues to observe for a period of time to confirm that the switchback is successful before completely shutting down the cloud card. The optimal value of T_release can be 5 minutes to 10 minutes to avoid the cloud card having to be restarted from scratch if the main link is quickly disconnected after shutdown, which would consume time and power.

[0067] The cloud card resource dynamic scheduling method provided in this invention loads cloud card resources on demand based on link status awareness. During non-fault periods, cloud cards will not remain in a high-cost standby state for extended periods, reducing signaling traffic and power consumption. This significantly reduces backup-side costs and standby power consumption while ensuring the continuity of critical services. In practice, this invention reduces power consumption by approximately 90% or more, while billing is only incurred during fault periods, resulting in a reduction of approximately 80% or more in traffic costs during non-fault periods.

[0068] Secondly, based on the same inventive concept, embodiments of the present invention provide a dynamic scheduling method for cloud card resources, applied to cloud card modules, such as... Figure 3 As shown, the method includes: Step 301: When the link quality score of the main link meets the first preset condition or the main control unit detects a specific service, receive the cloud card start command carrying resource configuration parameters sent by the main control unit, and switch the cloud card resource status of the cloud card module to the preheating state. In this embodiment of the invention, the cloud card module's cloud card resource lifecycle states include multiple states: unloaded state, preheating state, bearing state, low-power standby state, and release state.

[0069] The unloaded state is the initial state of the cloud card resources. The cloud card module is completely turned off or dormant, does not occupy any cloud resources, and does not incur any fees. In the unloaded state, there is no IP address, no signaling connection, and the radio frequency is turned off.

[0070] The preheating state is a new state proposed in this embodiment of the invention, which can be understood as an intermediate state between fully off and fully on for the cloud SIM card module. In the preheating state, network registration and authentication, as well as IP address allocation, are completed, but the data channel is suspended and no service data is transmitted. That is, in the preheating state, the cloud SIM card module requests and loads basic resources from the cloud server, completes IP address allocation and control plane connection establishment, but does not yet carry service data. This eliminates the slowest authentication process, shortening the switching time and avoiding premature traffic charges.

[0071] The bearer status is the working state of the cloud card module, which carries critical business traffic. In the bearer status, the data channel is activated, the routing table points to the cloud card interface, and billing begins.

[0072] Low-power standby mode refers to a state where the service has just switched back to the main link, but the cloud card has not yet been fully released and remains in a ready-to-use state. In low-power standby mode, the IP remains unchanged, the session context is retained, only a very small number of heartbeats are maintained, the radio frequency enters a power-saving mode of discontinuous reception, and the cloud card module is in low-power standby mode. This can prevent the main link from being interrupted again after being restored, avoid repeated time-consuming cloud card application processes, and utilize the remaining time within the usage period for tasks such as log transmission.

[0073] The "Release" state indicates that the cloud SIM network has been completely deactivated, returning to its initial state. In the Release state, the virtual SIM identifier is deactivated, billing ceases, and the module's radio frequency is turned off.

[0074] In this embodiment of the invention, the cloud card resource status of the cloud card module is switched to the preheating state if and only if any of the following conditions are met: (1) Predictive preheating: Although the main link LQS is not lower than Th_low, it shows a rapid downward trend, that is, the slope is less than the preset threshold, and it is predicted that it will fall below the threshold within the T_preheat time. Th_low is the main link fault threshold, and T_preheat is the preheating prediction time window.

[0075] (2) Fault response warm-up: The main link LQS is lower than Th_low, T_pred is greater than the minimum overhead time for cloud card module startup, and the cloud card link LQS is higher than the threshold Th_high, Th_high≥Th_low, where Th_high is the cloud card availability threshold and T_pred is the predicted interruption duration.

[0076] (3) Business-driven preheating: When a high-priority business is detected, such as an emergency alarm initiating a connection request, preheating is forcibly started regardless of the current status of the main link in order to prepare for unforeseen circumstances.

[0077] As one embodiment, corresponding to the above-described predictive preheating or fault response preheating, the LQS of the main link satisfies a first preset condition, specifically including: The LQS of the main link is not less than the preset Th_low, and the decreasing trend of the LQS of the main link satisfies the third preset condition, or... Based on the current time and fault type when the main link fails, the T_pred of the main link is predicted. The LQS of the main link is less than the preset Th_low, and the T_pred is greater than the preset threshold. The LQS of the cloud card link is greater than the preset Th_high, and Th_high ≥ Th_low.

[0078] Specifically, the third preset condition is that the slope of the main link LQS is less than the preset threshold, and it is predicted that it will fall below the threshold within the T_preheat time; the T_pred of the main link is greater than the preset threshold, specifically T_pred is greater than the minimum overhead time for the cloud card module to start.

[0079] Among them, Th_low is the primary link failure threshold. When the primary link LQS is lower than the threshold Th_low, it means that the current primary link quality is so poor that the network must be switched. Th_high is the cloud card link threshold. When the backup link LQS is higher than the threshold Th_high, it means that the cloud card quality is good enough to be used. The condition Th_high≥Th_low is to prevent switching to a worse backup link. T_preheat is the preheating prediction time window, which represents the time range of the system's forward prediction. In other words, it indicates that the link may break within T_preheat. The actual optimal value can be 10-15 seconds. In order to give the cloud card enough lead time to start up, T_pred is the duration of the primary link failure.

[0080] Based on the current time and fault type when the main link failure occurred, predict the duration T_pred of this main link failure, including: Based on the current time and fault type, the average duration of the corresponding historical records is obtained by matching them in the preset historical fault feature library; based on the average duration of the matched historical records, the maximum historical duration of the main control unit, and the confidence weight, the duration of the current fault in the main link is predicted.

[0081] Specifically, the main control unit maintains a historical fault feature database, which records the feature information of the past N main link faults. This feature information includes at least the time period of the fault, the fault type, and / or the duration.

[0082] When this fault is detected, based on the current time and fault type, multiple similar historical records are matched in the historical fault feature database. The duration of each matched historical record is obtained, and the average duration of the matched historical records is calculated based on the duration of each historical record.

[0083] The predicted downtime of the main link, i.e. the duration of the current failure of the main link, is T_pred = β×T_avg + (1 -β)×T_max, where T_avg is the average duration of the matched historical records, T_max is the maximum duration of the matched historical records, and β is the confidence weight, 0 <β < 1.

[0084] If T_pred is less than the minimum billing unit of the cloud card, a short-term package will be applied for first, or only a pre-heating period will be implemented; if T_pred is longer, a long-term preferential package will be applied for.

[0085] In practice, the LQS score range is usually normalized to 0-100 points. The optimal value of Th_low can be 60 points, the optimal value of Th_high can be 70 points, and Th_high≥Th_low; the optimal value of Th_back can be 80 points, and Th_back>Th_low. By providing Th_back, a hysteresis interval is constructed to avoid the system from repeatedly jumping when the LQS score fluctuates around 60 points.

[0086] In practical applications, different service types correspond to different main link failure thresholds and anti-jitter observation periods. For real-time control services, a higher Th_low and a shorter T_obs are used; for large file transfer services, a lower threshold and a longer observation period are used; for transaction payment services, a high Th_low and a short T_obs are used; and for streaming media / video surveillance services, a medium Th_low and a medium T_obs are used.

[0087] Preferably, if the duration of the main link failure T_pred is less than the minimum billing unit of the cloud card, a short-cycle package or only preheating is used; otherwise, a long-cycle preferential package is used.

[0088] As one example, in the case of the above-mentioned business-driven preheating, the specific business detected is: high-priority business, such as an emergency alarm initiating a connection request.

[0089] The specific operation of receiving the cloud card startup command carrying resource configuration parameters sent by the main control unit in this embodiment of the invention, and switching the cloud card resource status of the cloud card module to the preheating state, is as follows: The receiving main control unit selects the corresponding cloud card resource configuration parameters based on the billing granularity information from the cloud card operation side and the predicted duration of the main link failure. These cloud card resource configuration parameters include, but are not limited to, bandwidth level, usage period, and service priority. Upon receiving the cloud SIM card activation command carrying resource configuration parameters from the main control unit, the cloud SIM card resource status is switched to preheating state. In other words, the cloud SIM card resource lifecycle state is switched from unloaded to preheating. In preheating state, the cloud SIM card module requests and loads virtual SIM resources from the cloud server, completes network registration and authentication, establishes an RRC signaling connection, and completes IP address allocation and control plane connection establishment. Afterward, it proactively suspends data bearer activation or issues a flow table policy at the gateway that only allows management messages, ensuring that no billing traffic is generated even with a physical connection, and that service data is not carried temporarily. The module then sends a Preheat_Ready signal to the main control unit, entering standby mode to await the activation command.

[0090] Step 302: When the critical service traffic of the main link meets the second preset condition, the cloud card resource status of the cloud card module is switched from the preheating state to the carrying state, and the critical service traffic is switched to the cloud card network.

[0091] As one example, the critical service traffic of the main link meets the second preset condition, specifically including: the queuing length of the critical service on the main link or the proportion of real-time service traffic reaches a preset ratio.

[0092] The cloud card module switches its cloud card resource status from the preheating state to the bearer state, switching critical service traffic to the cloud card network. Specifically, the main control unit triggers the cloud card module to switch its cloud card resource status from the preheating state to the bearer state. The cloud card module establishes cellular data bearer based on the resource configuration parameters. The main control unit switches critical service traffic to the cloud card network first by modifying the system routing table or policy routing.

[0093] The cloud card resource dynamic scheduling scheme provided in this embodiment of the invention starts cloud card resources on demand based on link status awareness. In this way, the cloud card module does not need to be in standby mode during non-fault periods, which significantly reduces the cost and standby power consumption on the backup side while ensuring the continuity of critical services.

[0094] like Figure 4 As shown below, the cloud card resource dynamic scheduling method provided in this proposal is described in detail. The method includes: Step 401: When the link quality score of the main link meets the first preset condition or the main control unit detects a specific service, receive the cloud card start command carrying resource configuration parameters sent by the main control unit, and switch the cloud card resource status of the cloud card module to the preheating state. Step 402: When the critical service traffic of the main link meets the second preset condition, the cloud card resource status of the cloud card module is switched from the preheating state to the bearing state, and the critical service traffic is switched to the cloud card network.

[0095] For details of steps 401-402, please refer to steps 301-302 above, and they will not be repeated here.

[0096] Step 403: During the preset anti-shake observation period, if the link quality score of the main link is found to be less than the preset main link failure threshold or if the main link experiences an oscillation event, the service will continue to be carried on the cloud card network. During the preset anti-shake observation period, if the link quality score of the main link is consistently not less than the main link back-switch threshold and no oscillation event occurs in the main link, the service will be back-switched to the main link without loss.

[0097] In this step, during the preset anti-shake observation period, if an oscillation event occurs on the main link, or if no oscillation event occurs on the main link and the link quality score of the main link is less than the preset main link failure threshold, the anti-shake observation period is reset to ensure that critical business traffic continues to be carried on the cloud card network. During the preset anti-shake observation period, if no oscillation event occurs on the main link and the link quality score of the main link continues to be greater than the preset main link back-switch threshold, the critical business traffic will continue to be carried on the main link.

[0098] In practical applications, when the main link LQS is detected to fall below Th_low again or a new link oscillation event occurs within T_obs, T_obs is reset to ensure that critical business traffic continues to be carried on the cloud card network and the cloud card resource status remains in the carrying state. The main control unit initiates the lossless back-switch process only when the main link LQS remains higher than Th_back throughout the entire T_obs and no new oscillations are detected. In other words, critical business traffic is no longer carried on the cloud card network, but is switched back to the main link.

[0099] The lossless rollback process specifically includes: sending critical business data simultaneously through the main link and the cloud card network within a preset parallel carrying time T_mbb; the receiving side discards duplicate data packets based on the data packet sequence number or deduplication mark, thereby achieving a smooth rollback without the business being aware of it.

[0100] Step 404: Within the preset first time threshold, if the usage time of the cloud card is not less than the preset cloud card usage period, receive the cloud card release command and release cloud resources; or, within the preset first time threshold, if the usage time of the cloud card is less than the preset cloud card usage period, and the link quality score of the main link is continuously greater than the preset main link first time threshold, after completing the upload of non-critical business traffic based on the remaining bandwidth within the cloud card usage period, receive the cloud card release command and release cloud resources.

[0101] In this step, if the main link LQS remains above the preset first time threshold T_release and no new faults occur, and the current cloud card usage period has not yet ended, the main control unit can choose to use the remaining bandwidth to complete the data retransmission or log upload for non-critical services within this usage period, based on the remaining billing time and cloud card bandwidth. When the current cloud card usage period ends (i.e., the cloud card usage time is not less than the preset cloud card usage period, i.e., the current cloud card billing period ends (i.e., the cloud card billing time is not less than the cloud card billing period), a cloud card release command is sent to the cloud card module, and the cloud card module releases cloud resources.

[0102] When the main link is detected to be stable within T_release and the current cloud card usage cycle is about to end, the main control unit sends a cloud card release command to the cloud card module, switching the cloud card resource lifecycle state from low-power standby state to release state. The cloud card module responds to the control command and completely releases the cloud resources, and the terminal device no longer incurs continuous tariffs and power consumption overhead related to the cloud card.

[0103] In this embodiment of the invention, T_release represents the first time threshold of the main link, which can be called the stable time threshold, i.e., the stable release duration. It means that after switching back to the main link, it continues to observe for a period of time to confirm that the switchback is successful before completely shutting down the cloud card. The optimal value of T_release can be 5 minutes to 10 minutes to avoid the cloud card having to be restarted from scratch if the main link is quickly disconnected after shutdown, which would consume time and power.

[0104] The cloud card resource dynamic scheduling method provided in this invention loads cloud card resources on demand based on link status awareness. During non-fault periods, cloud cards will not remain in a high-cost standby state for extended periods, reducing signaling traffic and power consumption. This significantly reduces backup-side costs and standby power consumption while ensuring the continuity of critical services. In practice, this invention reduces power consumption by approximately 90% or more, while billing is only incurred during fault periods, resulting in a reduction of approximately 80% or more in traffic costs during non-fault periods.

[0105] Thirdly, based on the same inventive concept, embodiments of the present invention provide a cloud card resource dynamic scheduling device, wherein the device is located in the main control unit, such as... Figure 5 As shown, the device includes: a monitoring module 501, a triggering module 502, and a switching module 503; Monitoring module 501 is used to monitor the status of the main link and obtain the link quality score of the main link; Trigger module 502 is used to send a cloud card start command carrying resource configuration parameters to cloud card module when the link quality score of the main link meets the first preset condition or a specific service is detected, thereby triggering the cloud card resource status of cloud card module to switch to preheating state. The switching module 503 is used to trigger the cloud card module's cloud card resource status to switch from the preheating state to the carrying state when the critical service traffic of the main link meets the second preset condition, thereby switching the critical service traffic to the cloud card network.

[0106] The cloud card resource dynamic scheduling scheme provided in this embodiment of the invention enables the main control unit to start cloud card resources on demand based on link status awareness. In this way, the cloud card module will not be in a high-cost standby state for a long time during non-fault periods, which significantly reduces the cost and standby power consumption of the backup side while ensuring the continuity of critical services.

[0107] Fourthly, based on the same inventive concept, embodiments of the present invention provide a cloud card resource dynamic scheduling device, wherein the device is located in the cloud card module, such as... Figure 6 As shown, the device includes: a startup module 601 and a switching module 602; The startup module 601 is used to receive a cloud card startup command carrying resource configuration parameters sent by the main control unit when the link quality score of the main link meets the first preset condition or the main control unit detects a specific service, and to switch the cloud card resource status of the cloud card module to the preheating state. The switching module 602 is used to switch the cloud card resource status of the cloud card module from the preheating state to the carrying state when the critical service traffic of the main link meets the second preset condition, and to switch the critical service traffic to the cloud card network.

[0108] The cloud card resource dynamic scheduling scheme provided in this embodiment of the invention receives instructions from the main control unit to start cloud card resources on demand based on link status awareness. In this way, the cloud card module will not be in a high-cost standby state for a long time during non-fault periods, reducing signaling traffic and power consumption. While ensuring the continuity of critical services, it significantly reduces the cost and standby power consumption on the backup side.

[0109] Figure 7 This is a schematic block diagram of an electronic device 700 according to one embodiment. The electronic device 700 includes a processor 701, a memory 702, and a computer program stored in the memory and executable on the processor. When the processor 701 executes the computer program, it implements the cloud card resource dynamic scheduling method in the above embodiment.

[0110] For example, processor 701 may be a central processing unit (CPU), etc. Memory 702 may include random access memory, flash memory, read-only memory, programmable read-only memory, non-volatile memory, or registers, etc. Memory 702 may store executable instructions. Processor 701 may execute the executable instructions stored in memory 702 to implement the various processes described herein.

[0111] Furthermore, embodiments of this application also provide a machine-readable storage medium. This machine-readable storage medium may store executable instructions, which, when executed by a machine, cause the machine to implement the specific processes described in the above-described method embodiments.

[0112] For example, machine-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), hard disks, flash memory, etc.

[0113] Furthermore, this application also provides a computer program product containing instructions, which, when run on a computer, causes the computer to execute the steps in the above-described cloud card resource dynamic scheduling method.

[0114] These computer-executable instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0115] These computer-executable instructions can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0116] Those skilled in the art will understand that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described functions in different ways for each specific application, but such implementation should not be considered beyond the scope of this application.

[0117] In the embodiments of this application, the disclosed cloud card resource dynamic scheduling method can be implemented in other ways. For example, the division of units is only a logical functional division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system. In addition, the coupling between the various units can be direct coupling or indirect coupling. Furthermore, the functional units in the embodiments of this application can be integrated into a processing unit, or they can exist as separate physical entities, etc.

[0118] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a machine-readable storage medium. Therefore, the technical solution of this application can be embodied in the form of a software product, which can be stored in a machine-readable storage medium. This software product may include several instructions to cause an electronic device to execute all or part of the processes of the technical solution described in the embodiments of this application. The aforementioned storage medium may include various media capable of storing program code, such as ROM, RAM, removable disk, hard disk, magnetic disk, or optical disk.

[0119] The above description is merely a specific embodiment of this application, and the scope of protection of this application is not limited thereto. Those skilled in the art can make changes or substitutions within the technical scope disclosed in this application, and all such changes or substitutions should be within the scope of protection of this application.

Claims

1. A method for dynamic scheduling of cloud card resources, characterized in that, Applied to the main control unit, the method includes: Monitor the status of the main link and obtain the link quality score of the main link; The main control unit determines the cloud card resource configuration parameters based on the usage granularity information or billing granularity information from the cloud card operation side, as well as the predicted duration of the main link failure. The cloud card resource configuration parameters include bandwidth level, usage period, and service priority. When the link quality score of the main link meets the first preset condition or a specific service is detected, a cloud card start command carrying the cloud card resource configuration parameters is sent to the cloud card module, triggering the cloud card resource status of the cloud card module to switch from an unloaded state to a preheating state. In the preheating state, the cloud card module applies for and loads virtual SIM resources from the cloud server according to the cloud card resource configuration parameters. In the preheating state, the activation of data bearer is actively suspended, or a flow table policy that only allows management messages is issued to the gateway to ensure that no billing traffic is generated even if there is a physical connection, and no service data is carried temporarily. When the critical service traffic of the main link meets the second preset condition, the cloud card module's cloud card resource status is triggered to switch from the preheating state to the bearer state. In the bearer state, the cloud card module establishes cellular data bearer based on the cloud card resource configuration parameters. In the bearer state, the data channel is activated, the routing table points to the cloud card interface, and billing begins. The main control unit switches the critical service traffic from the main link to the cloud card network by modifying the system routing table or policy routing.

2. The method as described in claim 1, characterized in that, The method further includes: when the link quality score of the main link is greater than the preset main link back-off threshold, determining whether the critical service traffic should continue to be carried on the cloud card network based on the link quality score of the main link, the preset main link fault threshold, the preset main link back-off threshold, and whether the main link has experienced an oscillation event.

3. The method as described in claim 2, characterized in that, Determining whether the critical service traffic should continue to be carried on the cloud SIM card network includes: During the preset anti-shake observation period, if the main link experiences an oscillation event, or if the main link does not experience an oscillation event and the link quality score of the main link is less than the preset main link failure threshold, the anti-shake observation period is reset to ensure that the critical service traffic continues to be carried on the cloud card network. During the preset anti-shake observation period, when no oscillation event occurs on the main link and the link quality score of the main link is continuously greater than the preset main link back-switch threshold, the critical service traffic is back-switched to the main link, and the main control unit downgrades the cloud card resource status from the bearer status to the low-power standby status. In the low-power standby status, only the necessary session context and a small number of heartbeat connections are retained.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: continuously monitoring the link quality score of the main link and the usage time of the cloud card; and determining whether to send a release command to the cloud card module based on the link quality score of the main link, the usage time of the cloud card, the preset first time threshold of the main link, and the preset usage cycle of the cloud card, thereby switching the life cycle state of the cloud card resource from a low-power standby state to a release state. The cloud card module responds to the control command, completely releases the cloud resources, cancels the virtual SIM resources, stops billing, and shuts down the radio frequency.

5. The method as described in claim 4, characterized in that, Determining whether to send a release command to the cloud card module includes: Within the preset first time threshold of the main link, if the usage time of the cloud card is not less than the preset cloud card usage cycle, a release command is sent to the cloud card module, and the cloud card module releases cloud resources, or... If, within a preset first time threshold, the usage time of the cloud card is less than the preset cloud card usage cycle, and the link quality score of the main link is continuously greater than the preset first time threshold of the main link, after completing the upload of non-critical business traffic based on the remaining bandwidth within the usage cycle of the cloud card, a cloud card release command is sent to the cloud card module, and the cloud card module releases cloud resources.

6. The method as described in claim 1, characterized in that, The link quality score of the main link meets the first preset condition, specifically including: The link quality score of the main link is not less than the preset main link failure threshold, and the downward trend of the link quality score of the main link satisfies the third preset condition, or... Based on the current time and fault type when the main link fails, the duration of the current main link failure is predicted. If the link quality score of the main link is less than a preset main link failure threshold, the duration of the current main link failure is greater than a preset threshold, and the link quality score of the cloud SIM card link is greater than a preset cloud SIM card link threshold, and the cloud SIM card link threshold is greater than or equal to the main link failure threshold.

7. The method as described in claim 1, characterized in that, The Link Quality Score (LQS) of the main link is positively correlated with round-trip delay, throughput, and historical stability weights, and negatively correlated with packet loss rate and latency jitter.

8. The method as described in claim 1 or 7, characterized in that, The link quality score (LQS) of the main link is calculated as follows: LQS = w1×(1-packet loss rate) + w2×RTT_norm + w3×(1-Jitter_norm) + w4×throughput_norm + w5×historical stability index, where RTT_norm represents normal round-trip time, Jitter_norm represents normal latency jitter, and w1-w5 represent the corresponding weights.

9. The method as described in claim 6, characterized in that, The step of predicting the duration of the current main link failure based on the current time and failure type when the main link status failure occurs includes: Based on the current time and fault type, the average duration of the corresponding historical records is obtained by matching them in the preset database; Based on the average duration of the matched historical records, the maximum historical duration of the master control unit, and the confidence weight, the duration of the current failure of the main link is predicted.

10. The method as described in claim 9, characterized in that, The duration of the current failure of the main link is T_pred = β × T_avg + (1 - β) × T_max, where T_avg is the average duration of the matched historical records, T_max is the maximum duration of the matched historical records, and β is the confidence weight, 0 < β < 1.

11. A method for dynamic scheduling of cloud card resources, characterized in that, Applied to cloud card modules, the method includes: When the link quality score of the main link meets the first preset condition or the main control unit detects a specific service, the cloud card module receives a cloud card start command carrying cloud card resource configuration parameters sent by the main control unit, and switches the cloud card resource status of the cloud card module to a preheating state. The cloud card resource configuration parameters include bandwidth level, usage period, and service priority. The cloud card resource configuration parameters are determined by the main control unit based on the usage granularity information or billing granularity information of the cloud card operation side, as well as the predicted duration of the main link failure. In the preheating state, the cloud card module applies for and loads virtual SIM resources from the cloud server according to the cloud card resource configuration parameters. In the preheating state, the activation of data bearer is actively suspended, or a flow table policy that only allows management messages is issued at the gateway to ensure that no billing traffic is generated even if there is a physical connection, and service data is not carried temporarily. When the critical service traffic of the main link meets the second preset condition, the cloud card resource status of the cloud card module is switched from the preheating state to the bearer state. In the bearer state, the cloud card module establishes cellular data bearer based on the cloud card resource configuration parameters. In the bearer state, the data channel is activated, the routing table points to the cloud card interface, and billing begins. The main control unit switches the critical service traffic from the main link to the cloud card network by modifying the system routing table or policy routing.

12. The method as described in claim 11, characterized in that, The method further includes: During the preset anti-shake observation period, if the link quality score of the main link is found to be less than the preset main link failure threshold or if the main link experiences an oscillation event, the service will continue to be carried on the cloud card network. If, during the preset anti-shake observation period, the link quality score of the main link is consistently not less than the main link back-switch threshold, and no oscillation event occurs on the main link, the service will be losslessly switched back to the main link.

13. The method as described in claim 12, characterized in that, The method further includes: Within the preset first time threshold of the main link, if the usage time of the cloud card is not less than the preset usage cycle of the cloud card, a cloud card release command is received, releasing cloud resources, or... If, within the preset first time threshold of the main link, the usage time of the cloud card is less than the preset usage period of the cloud card, and the link quality score of the main link is continuously greater than the preset first time threshold of the main link, after the non-critical business traffic is uploaded based on the remaining bandwidth within the usage period of the cloud card, the cloud card release instruction is received to release cloud resources.

14. The method as described in claim 11, characterized in that, The link quality score of the main link meets the first preset condition, specifically including: The link quality score of the main link is not less than the preset main link failure threshold, and the downward trend of the link quality score of the main link satisfies the third preset condition, or... Based on the current time and fault type when the main link fails, the duration of the current main link failure is predicted. If the link quality score of the main link is less than a preset main link failure threshold, the duration of the current main link failure is greater than a preset threshold, and the link quality score of the cloud SIM card link is greater than a preset cloud SIM card link threshold, and the cloud SIM card link threshold is greater than or equal to the main link failure threshold.

15. A cloud card resource dynamic scheduling device, characterized in that, The device is located in the main control unit, and the device includes: a monitoring module, a triggering module, and a switching module; The monitoring module is used to monitor the status of the main link and obtain the link quality score of the main link; The triggering module is used to send a cloud card start command carrying cloud card resource configuration parameters to the cloud card module when the link quality score of the main link meets the first preset condition or a specific service is detected, triggering the cloud card resource status of the cloud card module to switch to a preheating state. The cloud card resource configuration parameters include bandwidth level, usage period, and service priority. The cloud card resource configuration parameters are determined by the main control unit based on the usage granularity information or billing granularity information of the cloud card operation side and the predicted duration of the main link failure. In the preheating state, the cloud card module applies for and loads virtual SIM resources from the cloud server according to the cloud card resource configuration parameters. In the preheating state, it actively suspends the activation of data bearer or issues a flow table policy that only allows management messages to the gateway to ensure that no billing traffic is generated even if there is a physical connection, and no service data is carried temporarily. The switching module is used to trigger the cloud card module's cloud card resource status to switch from the preheating state to the bearer state when the critical service traffic of the main link meets the second preset condition. In the bearer state, the cloud card module establishes cellular data bearer based on the cloud card resource configuration parameters. In the bearer state, the data channel is activated, the routing table points to the cloud card interface, and billing begins. The main control unit switches the critical service traffic from the main link to the cloud card network by modifying the system routing table or policy routing.

16. A cloud card resource dynamic scheduling device, characterized in that, The device is located in the cloud card module, and the device includes: a startup module and a switching module; The startup module is used to receive a cloud card startup command carrying cloud card resource configuration parameters sent by the main control unit when the link quality score of the main link meets the first preset condition or the main control unit detects a specific service. This command switches the cloud card resource status of the cloud card module to a preheating state. The cloud card resource configuration parameters include bandwidth level, usage period, and service priority. These parameters are determined by the main control unit based on the usage granularity information or billing granularity information from the cloud card operation side, as well as the predicted duration of the main link failure. In the preheating state, the cloud card module applies for and loads virtual SIM resources from the cloud server according to the cloud card resource configuration parameters. In this preheating state, it actively suspends the activation of data bearer activation or issues a flow table policy that only allows management messages at the gateway, ensuring that no billing traffic is generated even if there is a physical connection, and that service data is not carried temporarily. The switching module is used to switch the cloud card resource status of the cloud card module from the preheating state to the bearer state when the critical service traffic of the main link meets the second preset condition. In the bearer state, the cloud card module establishes cellular data bearer based on the cloud card resource configuration parameters. In the bearer state, the data channel is activated, the routing table points to the cloud card interface, and billing begins. The main control unit switches the critical service traffic from the main link to the cloud card network by modifying the system routing table or policy routing.

17. An electronic device, the electronic device comprising: A processor, a memory, and a computer program stored in the memory and executable on the processor; characterized in that, when the processor executes the computer program, it implements the cloud card resource dynamic scheduling method as described in any one of claims 1-10 or 11-14.

18. A machine-readable storage medium, characterized in that, It stores executable instructions, which, when executed by a machine, enable the cloud card resource dynamic scheduling method according to any one of claims 1-10 or 11-14.

19. A computer program product containing instructions, characterized in that, When it is run on a computer, it causes the computer to perform the steps in the cloud card resource dynamic scheduling method according to any one of claims 1-10 or 11-14.

Images