Algorithm dynamic migration system and method for radio monitoring cloud edge collaboration architecture

Abstract

The application discloses an algorithm dynamic migration system and method for a radio monitoring cloud-edge collaborative architecture. It comprises a cloud management layer, a cloud-edge communication layer, an end-side execution layer and a migration control layer. The cloud management layer has container scheduling capability, and uniformly manages node labels, resource portraits, device capability portraits, algorithm images, hierarchical configuration and migration tasks. The cloud-edge communication layer realizes safe interaction of data between the cloud and the end side. The end-side execution layer receives cloud instructions, completes image pulling, container starting, hardware docking and state reporting. Through a business context snapshot technology, monitoring related parameters and data processing progress are completely retained. A multi-dimensional adaptive scoring mechanism is used to screen target nodes. A hierarchical configuration mode realizes automatic matching and distribution of configuration files. The application has the beneficial effect of realizing stable migration of radio monitoring related algorithms among cloud nodes, edge end stations and different edge end stations, and guaranteeing continuous operation of monitoring business.

Description

Technical Field

[0001] This invention relates to the field of radio monitoring and management technology, and in particular to an algorithm dynamic migration system and method for a cloud-edge collaborative architecture for radio monitoring. Background Technology

[0002] Radio monitoring services are characterized by a large number of monitoring stations, a wide geographical distribution, highly unpredictable monitoring tasks, high real-time data processing requirements, and a large proportion of unattended monitoring stations. Monitoring stations need to continuously collect spectrum data, IQ data, equipment operating status, and alarm information over extended periods, and run various radio monitoring-related algorithms such as signal identification, interference analysis, illegal emission source detection, and spectrum occupancy analysis.

[0003] In existing radio monitoring systems, radio monitoring algorithms are mostly deployed in a fixed manner, residing on a central server or designated end-devices. When end-device node resource usage exceeds limits, network quality deteriorates, nodes go offline, temporary tasks occur in the monitoring area, algorithm versions are upgraded, or hardware malfunctions, staff typically need to remotely log in to the device and manually perform operations such as program deployment, parameter modification, and service restart. This approach not only has high maintenance costs but also cannot guarantee continuous monitoring work by unattended end stations under abnormal conditions.

[0004] While some current cloud-edge collaboration and container orchestration solutions can deploy algorithm containers to edge nodes, they still have many shortcomings. Conventional container scheduling only considers general resource indicators such as CPU and memory, failing to select nodes based on the regional attributes, frequency band attributes, device models, hardware access capabilities, and task priorities of radio monitoring tasks. During the migration of radio monitoring algorithms, specific business contexts such as monitoring frequency bands, sampling rates, bandwidth, IQ data processing progress, intermediate identification results, and device binding relationships are not saved and restored. Algorithm configuration relies heavily on manual maintenance, making it difficult to adapt to the differentiated operational needs of different regions, device models, and endpoints. When migration failures occur, there is a lack of complete control logic for source node keep-alive, target node retry, reselection, and rollback recovery, which can easily cause monitoring task interruptions. Furthermore, the triggering reasons, version information, and failure causes throughout the migration process are not recorded in a complete system, making full-process auditing and traceability impossible. Summary of the Invention

[0005] This invention aims to overcome the shortcomings of existing technologies, such as fixed algorithm deployment, insufficient rationality in migration node selection, inability to recover business context, reliance on manual maintenance for terminal station configuration, and easy task interruption due to migration failures. It provides a dynamic algorithm migration system and method for a cloud-edge collaborative architecture for radio monitoring that can ensure the continuous operation of monitoring services.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: The algorithm dynamic migration system for a cloud-edge collaborative architecture for radio monitoring comprises four main modules: a cloud management layer, a cloud-edge communication layer, an edge execution layer, and a migration control layer. The cloud-based management layer enables unified management of the entire wireless edge device, and is responsible for maintaining algorithm images, version information, configuration files, node tags, node resource profiles, device capability profiles, and migration task status. The cloud-edge communication layer establishes a secure transmission channel between the cloud and the edge, enabling bidirectional synchronization of deployment instructions, configuration files, migration snapshots, container running status, radio monitoring-related algorithm running status, and abnormal alarm information. The edge execution layer receives migration tasks from the cloud, completes algorithm image retrieval, configuration file and data volume mounting, algorithm container startup, and interface docking with local radio monitoring hardware. The migration control layer is responsible for determining migration conditions, storing the source node's runtime context, filtering and verifying the target node, synchronizing migration data, restoring the target node's state, and handling abnormal retries and fault rollback operations.

[0007] The overall architecture of this invention mainly includes a cloud management layer, a cloud-edge communication layer, an edge execution layer, and a migration control layer. The cloud management layer has container scheduling capabilities and uniformly manages node tags, resource profiles, device capability profiles, algorithm images, layered configurations, and migration tasks. The cloud-edge communication layer enables secure data interaction between the cloud and the edge. The edge execution layer receives instructions from the cloud and completes image retrieval, container startup, hardware integration, and status reporting.

[0008] As a preferred option, after the edge node deploys the edge execution layer, it completes the registration on the cloud platform with a preset identity token. The cloud configures node tags for the registered nodes, continuously collects node-related data, and builds node resource profiles and device capability profiles.

[0009] As a preferred approach, the cloud creates standardized algorithm images for each radio monitoring-related algorithm, labels the image version number and verification information, and stores them uniformly in the algorithm image repository in the cloud management layer. The configuration center in the cloud management layer divides the algorithm configuration into five categories: global public configuration, regional configuration, device model configuration, end node-specific configuration, and sensitive configuration. It synchronously records the version number, applicable tags, update time, and verification information of each type of configuration. After receiving the migration task, the target node automatically matches the corresponding configuration file based on its own tags, task attributes, and algorithm type.

[0010] As a preferred option, the migration control layer generates migration tasks based on multiple triggering conditions. Triggering types include resource triggering, fault triggering, business triggering, version triggering, and manual triggering. Resource triggering occurs when the resources of the end node exceed a preset threshold; fault triggering occurs when the end node malfunctions; business triggering occurs when related business is carried out; version triggering occurs when the algorithm image or configuration file completes a version upgrade; and manual triggering occurs when administrators specify the source node, target node, and radio monitoring related algorithms to be migrated through the cloud console or external interface.

[0011] This invention also provides a method for dynamic algorithm migration for a cloud-edge collaborative architecture for radio monitoring, the specific steps of which are as follows: (1) After the migration task is created, it enters the waiting state. The migration control layer generates migration tasks based on multiple trigger conditions. After the migration task is officially started, the source node selection algorithm processes the frozen state to save the context and generates a migration snapshot. (2) The cloud selects online nodes from all candidate nodes, calculates the adaptation score of each candidate node, and selects the target node according to the score. (3) The cloud or source node will transfer the migration snapshot, intermediate data and supporting configuration files to the target node through the cloud-edge communication layer; (4) The target node pulls or reuses the locally cached algorithm image according to the deployment strategy issued by the cloud, and sequentially mounts the global public configuration, regional configuration, device model configuration, end node exclusive configuration, sensitive configuration and migration data volume, creates and starts the algorithm container, and reads the migration snapshot data after the algorithm container runs, and continues to carry out radio data processing work from the breakpoint position. (5) After the target node completes state recovery and runs stably, it sends the execution layer status back to the cloud. The cloud continuously performs health checks on the target node. After confirming that it is running normally, it updates the migration task status and sends a release command to the source node to clean up the original container or switch the source node to standby status.

[0012] This method utilizes business context snapshot technology to fully retain monitoring-related parameters and data processing progress, effectively preventing the loss of monitoring status during migration. It employs a multi-dimensional adaptation scoring mechanism to screen target nodes, improving the rationality of node selection and migration success rate. The hierarchical configuration mode enables automatic matching and distribution of configuration files, reducing the workload of manual configuration on the end side and adapting to differentiated usage scenarios of multiple regions and multiple device models. Relying on mechanisms such as source node keep-alive, fault retry, reselection, and rollback recovery, it significantly reduces the risk of business interruption caused by migration failures.

[0013] Preferably, in step (2), the candidate node's compatibility score consists of resource score, network score, region score, device compatibility score, image cache score, and task priority score; the resource score is determined based on the candidate node's relevant resources; the network score is determined based on the network situation between the cloud and the candidate node; the region score is determined based on the matching relationship between the node's relevant regions; the device compatibility score is determined based on whether the node can be compatible with the device; the image cache score is determined based on whether the node locally stores the corresponding version of the algorithm image; and the task priority score is determined based on the importance level of the radio monitoring task.

[0014] As a preferred option, in step (3), before the target node loads the data, a consistency check is performed on the algorithm image version, configuration version, task number, snapshot verification value and snapshot validity period. If the check result is abnormal, the recovery operation is refused and the fault information is reported to the cloud.

[0015] As a preferred approach, the entire migration process is monitored in real time. If a migration failure occurs, the migration control layer will perform a retry operation, reselect the target node, or perform a rollback operation based on the fault type. Before the target node is confirmed to be running normally, the source node will always maintain the original algorithm instance running or retain a recoverable state. When the number of retries reaches the upper limit, or when all candidate nodes do not meet the running conditions, the migration task enters the rollback state, and the source node continues to perform the monitoring task.

[0016] The beneficial effects of this invention are: effectively avoiding the loss of monitoring status during migration; improving the rationality of node selection and migration success rate; reducing the workload of manual configuration on the end side, and adapting to the differentiated use scenarios of multiple regions and multiple models of equipment; significantly reducing the risk of service interruption caused by migration failure; and realizing the stable migration of radio monitoring-related algorithms between cloud nodes, edge stations, and different edge stations, ensuring the continuous operation of monitoring services. Attached Figure Description

[0017] Figure 1 This is the overall system architecture diagram of the present invention; Figure 2 This is a flowchart of the method of the present invention; Figure 3 This is a schematic diagram of the hierarchical configuration matching and distribution of the present invention; Figure 4 This is a schematic diagram of the transition state machine of the present invention; Figure 5 This is a schematic diagram of the target node adaptation scoring of the present invention. Detailed Implementation

[0018] The present invention will now be further described with reference to the accompanying drawings and specific embodiments.

[0019] To facilitate understanding of this invention, the main technical terms used in this specification are explained below. Unless otherwise specified, the following terms have the following meanings in this specification. This invention relates to the technical field of integrated platforms for radio monitoring, cloud-edge collaborative computing, containerized algorithm scheduling, and radio management. In particular, it relates to a system and method that, under an architecture of unified cloud management and distributed execution on the edge, combines the status of radio monitoring tasks, the resource status of edge nodes, network status, and the adaptation status of radio equipment, to realize dynamic migration, status recovery, anomaly rollback, and audit traceability of radio monitoring-related algorithms.

[0020] This invention provides a dynamic migration system and method for algorithms adapted to radio monitoring services. Relying on a cloud-edge collaborative architecture, and combining service context snapshots, node adaptation scoring, hierarchical configuration, migration state machine, and fault rollback mechanism, it enables stable migration of radio monitoring-related algorithms between cloud nodes, edge stations, and different edge stations, ensuring the continuous operation of monitoring services.

[0021] like Figure 1 In the described embodiments, the algorithm dynamic migration system for a cloud-edge collaborative architecture for radio monitoring includes four main modules: a cloud management layer, a cloud-edge communication layer, an edge execution layer, and a migration control layer. The cloud-based management layer enables unified management of the entire wireless edge device, and is responsible for maintaining algorithm images, version information, configuration files, node tags, node resource profiles, device capability profiles, and migration task status. The cloud-edge communication layer establishes a secure transmission channel between the cloud and the edge, enabling bidirectional synchronization of deployment instructions, configuration files, migration snapshots, container running status, radio monitoring-related algorithm running status, and abnormal alarm information. The edge execution layer receives migration tasks from the cloud, completes algorithm image retrieval, configuration file and data volume mounting, algorithm container startup, and interface docking with local radio monitoring hardware. The migration control layer is responsible for determining migration conditions, storing the source node's runtime context, filtering and verifying the target node, synchronizing migration data, restoring the target node's state, and performing operations such as retrying in case of anomalies and rolling back from failures.

[0022] After the endpoint execution layer is deployed, it completes registration on the cloud platform using a preset identity token. The cloud configures node tags for registered nodes, including unique identifier, region, monitoring facility number, geographical location, device model, types of wireless devices that can be accessed, supported frequency bands, available computing power, image cache status, and network quality. It continuously collects relevant data such as node CPU, memory, disk, computing hardware, link latency, packet loss rate, device online status, container running status, and the running status of wireless monitoring related algorithms to build node resource profiles and device capability profiles.

[0023] For each radio monitoring algorithm, a standardized algorithm image is created in the cloud, labeled with the image version number and verification information, and stored uniformly in the algorithm image repository in the cloud management layer. The configuration center in the cloud management layer divides algorithm configurations into five categories: global public configuration, regional configuration, device model configuration, end-node specific configuration, and sensitive configuration, synchronously recording the version number, applicable tags, update time, and verification information of each type of configuration. After receiving the migration task, the target node automatically matches the corresponding configuration file based on its own tags, task attributes, and algorithm type.

[0024] The migration control layer generates migration tasks based on various trigger conditions, including resource triggers, fault triggers, service triggers, version triggers, and manual triggers. Resource triggers occur when the CPU, memory, disk, computing hardware, or container load of the endpoint node exceeds a preset threshold; fault triggers occur when the endpoint node is offline, network quality deteriorates, hardware devices malfunction, or the endpoint execution layer malfunctions; service triggers occur when monitoring key frequency bands, handling sudden interference, prioritizing regional tasks, or changing related services in the monitoring area; version triggers occur when the algorithm image or configuration file completes a version upgrade; and manual triggers occur when administrators specify the corresponding source node, target node, and radio monitoring-related algorithms for migration through the cloud console or external interfaces.

[0025] like Figure 2 As shown, this invention also provides a dynamic algorithm migration method for a cloud-edge collaborative architecture for radio monitoring, with the following specific steps: (1) After the migration task is created, it enters a waiting state. The migration control layer generates migration tasks based on multiple trigger conditions. After the migration task is officially started, the source node selects the algorithm processing batch boundary, time window boundary, or IQ data block boundary to enter a frozen state to save the context and generates a migration snapshot. The migration snapshot includes the task number, algorithm name, algorithm version, configuration version, current monitoring frequency band, sampling rate, bandwidth, algorithm running parameters, IQ data processing offset, processed data location, intermediate identification results, cache queue information, container running status, device binding relationship, log index, snapshot generation time, snapshot validity period, and snapshot verification value.

[0026] (2) The cloud selects online nodes from all candidate nodes, and calculates the adaptation score of each candidate node by comprehensively considering the remaining hardware resources, network transmission indicators, regional matching degree, device adaptability, frequency band support capability, image cache status, and task priority. The target node is selected according to the score. The target node must meet the minimum resource requirements, device access conditions, and configuration matching requirements before the subsequent migration process can be executed.

[0027] (3) The cloud or source node will transfer the migration snapshot, intermediate data and supporting configuration files to the target node through the cloud-edge communication layer or shared storage system. Before loading the data, the target node will perform consistency checks on the algorithm image version, configuration version, task number, snapshot verification value and snapshot validity period. If the verification result is abnormal, the recovery operation will be refused and the fault information will be reported to the cloud.

[0028] (4) The target node pulls or reuses the locally cached algorithm image according to the deployment strategy issued by the cloud, and sequentially mounts the global public configuration, regional configuration, device model configuration, end-node-specific configuration, sensitive configuration, and migration data volume, creating and starting the algorithm container. After the algorithm container runs, it reads the migration snapshot data, restores the monitoring frequency band, sampling rate, bandwidth, algorithm parameters, cache queue, intermediate recognition results, and IQ data processing offset, and resumes radio data processing from the breakpoint. Figure 3 As shown, the configuration is divided into global public configuration, regional configuration, device model configuration, end node-specific configuration, and sensitive configuration. The global public configuration includes the mirror repository address, log level, heartbeat cycle, and monitoring address. The regional configuration includes the region code, regional frequency range, and regional service parameters. The device model configuration includes the interface parameters, sampling parameters, and driver adaptation parameters of the radio monitoring device and signal receiving device. The end node-specific configuration includes the node number, site geographical location, device serial number, resource limit parameters, and dedicated algorithm parameters. The sensitive configuration includes the mirror repository authentication information, communication certificate, and algorithm authorization key.

[0029] (5) After the target node completes state recovery and stabilizes, it sends back to the cloud the container status, radio monitoring algorithm running status, resource usage, device connection status, snapshot loading results, and algorithm output status, etc., as the end-side execution layer status. The cloud continuously performs health checks on the target node. After confirming that it is running normally, it updates the migration task status and sends a release command to the source node to clean up the original container or switch the source node to standby status.

[0030] The entire migration process is monitored in real time. If migration failures occur, such as image retrieval failure, configuration loading failure, snapshot verification anomalies, target node offline, device access failure, container startup failure, or abnormal state recovery, the migration control layer will perform retry operations, reselect target nodes, or perform rollback operations based on the fault type. Before the target node is confirmed to be running normally, the source node will always maintain the original algorithm instance running or retain a recoverable state. When the number of retries reaches the limit, or all candidate nodes do not meet the running conditions, the migration task enters a rollback state, and the source node continues to execute the monitoring task.

[0031] The cloud records the migration task creation time, triggering reason, source node information, candidate node scoring data, target node information, algorithm version, configuration version, snapshot number, snapshot verification value, migration result, fault cause, number of retries, rollback execution status, and operator information in a complete audit chain, providing data support for fault investigation, version tracing, and platform operation and maintenance supervision.

[0032] As shown in the table below, the candidate node's compatibility score consists of resource score, network score, region score, device compatibility score, image cache score, and task priority score. The resource score is determined based on the candidate node's relevant resources; the network score is determined based on the network conditions between the cloud and the candidate node; the region score is determined based on the matching relationship between the node and its relevant region; the device compatibility score is determined based on whether the node can be compatible with the device; the image cache score is determined based on whether the node locally stores the corresponding version of the algorithm image; and the task priority score is determined based on the importance level of the radio monitoring task. Figure 5 shows the selection and scoring logic of target nodes. Candidate nodes must first meet hard conditions such as online status, basic resources, device access, and configuration matching. Then, the results are combined with multi-dimensional scoring results to sort the nodes and comprehensively match the general computing power requirements and the specific requirements of radio monitoring services.

[0033] like Figure 4 As shown, this invention sets up a dedicated migration state machine, including seven states: waiting, snapshot generation, data transmission, state recovery, normal operation, operational failure, and failure rollback. After the migration task is created, it enters the waiting state; when the source node generates a business context snapshot, it enters the snapshot generation state; during the transmission of the migration snapshot and configuration file, it enters the data transmission state; when the target node loads the snapshot and restores the algorithm's running state, it enters the state recovery state; after the target node passes the health check, it enters the normal operation state; if any link fails, it enters the operational failure state, and performs retry, reselection, or switches to the failure rollback state according to the failure type.

[0034] Implementation Example 1: Migrating the edge-side algorithm to the cloud node A radio monitoring station in a certain region deployed an IQ signal analysis algorithm. Cloud monitoring detected that the station's hardware resource load consistently exceeded a preset threshold, while multiple monitoring tasks were running concurrently in the area. The migration control layer automatically generated a migration task. The source station created a migration snapshot at the IQ data block boundary. This snapshot included the current monitoring frequency band, sampling rate, algorithm parameters, IQ data processing offset, intermediate identification results, cache information, and container status, along with annotations for the algorithm version, configuration version, and verification information. Cloud nodes pulled an image of the same algorithm version, loaded the global configuration and corresponding regional configuration, and after snapshot verification, restored the radio monitoring-related algorithm's running status. After confirming stable algorithm operation in the cloud, the original algorithm container at the source station was cleaned up.

[0035] Implementation Example 2: Migrating Cloud Algorithms to Edge Nodes When a sudden interference investigation task occurs in a monitoring area, the cloud-based dispatch center calculates the suitability score of each candidate terminal station based on the task location, node online status, equipment operational capabilities, and task priority. The center selects a terminal station geographically adjacent to the monitoring area, with sufficient resources, and capable of connecting to local radio monitoring hardware as the target node. The cloud then sends the interference identification algorithm image, regional configuration, equipment model configuration, and terminal-specific configuration to the target node. The target node starts the algorithm container and directly connects to the local monitoring equipment, transmitting the radio monitoring algorithm's operational status and analysis results back to the cloud in real time. This reduces the data transmission pressure on the central side and improves the speed of on-site response.

[0036] Implementation Example 3: Algorithm Migration Between End-Side Nodes When the source node experiences network quality degradation or hardware failure alarms, the cloud selects candidate nodes as migration targets within the same or adjacent regions. After the source node generates a migration snapshot, the cloud synchronizes the snapshot data, algorithm version information, and associated configurations to the target node. After the target node completes version and data verification, it resumes the operation of the radio monitoring algorithms and continues to execute monitoring tasks. If the target node malfunctions, the cloud selects a backup node; if no backup node is available, the source node continues to run its original algorithm and triggers a device maintenance alarm.

[0037] Implementation Example 4: Algorithm Version Upgrade and Migration When a new version of a radio monitoring algorithm is released, the cloud image repository updates the algorithm image and version verification information, and the configuration center synchronously updates the corresponding configuration version. The migration control layer selects some end stations as canary migration nodes and distributes the new version algorithm image and configuration file to the canary nodes. The target node starts the new version algorithm container and loads the migration snapshot generated by the old version algorithm. If the running status, recognition results, and resource consumption of the new version algorithm meet the preset requirements, the migration scope is gradually expanded; if the new version runs abnormally, a rollback operation is performed to restore the use of the old version algorithm and old configuration.

[0038] The method proposed in this invention can automatically complete the migration of radio monitoring-related algorithms, state recovery, anomaly rollback and audit traceability in various scenarios such as insufficient end-side resources, node failure, temporary monitoring tasks, monitoring area adjustment, and algorithm version upgrade. It effectively improves the continuity of radio monitoring tasks, operational reliability and automated operation and maintenance capabilities in unattended scenarios.

[0039] In summary, this invention utilizes business context snapshot technology to fully retain monitoring-related parameters and data processing progress, effectively preventing the loss of monitoring status during migration. It employs a multi-dimensional adaptation scoring mechanism to screen target nodes, comprehensively considering business characteristics such as computing power, network, region, and equipment, thereby improving the rationality of node selection and migration success rate. The hierarchical configuration mode enables automatic matching and distribution of configuration files, reducing the workload of manual configuration on the end-user side and adapting to differentiated usage scenarios across multiple regions and device models. Relying on mechanisms such as source node keep-alive, fault retry, reselection, and rollback recovery, it significantly reduces the risk of service interruption caused by migration failures. The end-to-end audit chain enables full traceability of algorithm versions, configuration versions, and migration records, meeting the unified operation and maintenance and supervision needs of the radio management platform.

Claims

1. A dynamic migration system for algorithms in a cloud-edge collaborative architecture for radio monitoring, characterized by: It includes four main modules: cloud management layer, cloud-edge communication layer, edge execution layer, and migration control layer. The cloud-based management layer enables unified management of the entire wireless edge device, and is responsible for maintaining algorithm images, version information, configuration files, node tags, node resource profiles, device capability profiles, and migration task status. The cloud-edge communication layer establishes a secure transmission channel between the cloud and the edge, enabling bidirectional synchronization of deployment instructions, configuration files, migration snapshots, container running status, radio monitoring-related algorithm running status, and abnormal alarm information. The edge execution layer receives migration tasks from the cloud, completes algorithm image retrieval, configuration file and data volume mounting, algorithm container startup, and interface docking with local radio monitoring hardware. The migration control layer is responsible for determining migration conditions, storing the source node's runtime context, filtering and verifying the target node, synchronizing migration data, restoring the target node's state, and handling abnormal retries and fault rollback operations.

2. The algorithm dynamic migration system for a cloud-edge collaborative architecture for radio monitoring according to claim 1, characterized in that, After the edge execution layer is deployed, the edge node completes the registration on the cloud platform with the preset identity token. The cloud configures node tags for the registered node, continuously collects node-related data, and builds node resource profiles and device capability profiles.

3. The algorithm dynamic migration system for a cloud-edge collaborative architecture for radio monitoring according to claim 1, characterized in that, For each radio monitoring-related algorithm, a standardized algorithm image is created in the cloud, labeled with the image version number and verification information, and uniformly stored in the algorithm image repository in the cloud management layer. The configuration center in the cloud management layer divides the algorithm configuration into five categories: global public configuration, regional configuration, device model configuration, end node-specific configuration, and sensitive configuration. It synchronously records the version number, applicable tags, update time, and verification information of each type of configuration. After receiving the migration task, the target node automatically matches the corresponding configuration file based on its own tags, task attributes, and algorithm type.

4. The algorithm dynamic migration system for a cloud-edge collaborative architecture for radio monitoring according to claim 1, characterized in that, The migration control layer generates migration tasks based on multiple triggering conditions, including resource triggering, fault triggering, business triggering, version triggering, and manual triggering. Resource triggering occurs when the resources of the end node exceed a preset threshold; fault triggering occurs when the end node malfunctions; business triggering occurs when relevant business operations are carried out; and version triggering occurs when the algorithm image or configuration file completes a version upgrade. Manual triggering involves administrators specifying the corresponding source node, target node, and radio monitoring algorithms for migration via a cloud console or external interface.

5. The algorithm dynamic migration method for a cloud-edge collaborative architecture for radio monitoring according to claim 1, 2, 3, or 4, characterized in that, The specific steps are as follows: (1) After the migration task is created, it enters the waiting state. The migration control layer generates migration tasks based on multiple trigger conditions. After the migration task is officially started, the source node selection algorithm processes the frozen state to save the context and generates a migration snapshot. (2) The cloud selects online nodes from all candidate nodes, calculates the adaptation score of each candidate node, and selects the target node according to the score. (3) The cloud or source node will transfer the migration snapshot, intermediate data and supporting configuration files to the target node through the cloud-edge communication layer; (4) The target node pulls or reuses the locally cached algorithm image according to the deployment strategy issued by the cloud, and sequentially mounts the global public configuration, regional configuration, device model configuration, end node exclusive configuration, sensitive configuration and migration data volume, creates and starts the algorithm container, and reads the migration snapshot data after the algorithm container runs, and continues to carry out radio data processing work from the breakpoint position. (5) After the target node completes state recovery and runs stably, it sends the execution layer status back to the cloud. The cloud continuously performs health checks on the target node. After confirming that it is running normally, it updates the migration task status and sends a release command to the source node to clean up the original container or switch the source node to standby status.

6. The algorithm dynamic migration method for a cloud-edge collaborative architecture for radio monitoring according to claim 5, characterized in that, In step (2), the candidate node's compatibility score consists of resource score, network score, region score, device compatibility score, image cache score, and task priority score. The resource score is determined based on the candidate node's relevant resources. The network score is determined based on the network conditions between the cloud and the candidate node. The region score is determined based on the matching relationship between the node's relevant regions. The device compatibility score is determined based on whether the node can be adapted to the device. The image cache score is determined based on whether the node stores the corresponding version of the algorithm image locally. The task priority score is determined based on the importance level of the radio monitoring task.

7. The algorithm dynamic migration method for a cloud-edge collaborative architecture for radio monitoring according to claim 5, characterized in that, In step (3), before the target node loads the data, it performs a consistency check on the algorithm image version, configuration version, task number, snapshot verification value and snapshot validity period. If the verification result is abnormal, it refuses to perform the recovery operation and sends the fault information to the cloud.

8. The algorithm dynamic migration method for a cloud-edge collaborative architecture for radio monitoring according to claim 5, characterized in that, The entire migration process is monitored in real time. If a migration failure occurs, the migration control layer will perform a retry operation, reselect the target node, or perform a rollback operation according to the fault type. Before the target node is confirmed to be running normally, the source node always keeps the original algorithm instance running or retains a recoverable state; when the number of retries reaches the limit, or when all candidate nodes do not meet the running conditions, the migration task enters the rollback state, and the source node continues to execute the monitoring task.

Images